Website launch checklist: the 30 items we verify before go-live

The thirty items we confirm before a business website goes live, across eight areas, each with how it is verified.

6 minread 1,224words last updated

The short answer

A website launch is a checklist followed in a quiet window with rollback ready, not a moment of courage. The thirty items below cover the eight areas where launches go wrong: ownership and accounts, content, technical setup, performance, accessibility, security, search visibility and measurement. Each is verified with evidence on the final preview, then again on the live site after the DNS switch. Most launch problems come from items nobody thought of as technical: the domain registered in a supplier’s name, a contact form that emails nobody, placeholder text left on a page, old addresses left to return not-found, analytics that never fired. An item that cannot be verified is not done. The launch waits, or the item is consciously deferred with a date and an owner. The completed list with evidence becomes the launch report and the first document any future audit reads.

The thirty items

#AreaItemVerified by
1OwnershipDomain registered in the business’s name, locked, auto-renewing, two-factor onRegistrar account checked
2OwnershipHosting project, repository and every service account in the business’s name or organisationOwnership pages checked
3OwnershipAccess register current; per-person access; no shared loginsRegister reviewed
4ContentEvery page has final content; no placeholder text or imagesFull-site search for placeholder patterns; manual read
5ContentLegal pages present and reviewed: privacy, cookies if applicable, terms, imprint as requiredBusiness sign-off recorded
6ContentContact details, opening hours, addresses correct on every occurrenceManual check; structured data matches
7ContentEvery image has meaningful alt text or is marked decorativeAutomated check plus sample review
8ContentInternal links resolve; no broken linksCrawl of the preview clean
9TechnicalForms submit, validate, reach the right inbox and CRM, and confirm to the senderTest submissions end to end
10TechnicalAnti-spam, rate limits and honeypot on every formTest with a script; limit hit
11TechnicalNot-found page returns the correct status and is helpfulNonsense address tested; status checked
12TechnicalRedirect map complete and tested; every old address maps to its equivalentAutomated redirect test against the list
13TechnicalCustom domain configured; HTTPS with valid certificate; www and bare domain resolve to oneBrowser and certificate check
14TechnicalEnvironment variables set for production; secrets in secret storage onlyPlatform settings; repository scan
15TechnicalBrowser support policy met; tested on real phones, desktops, in-app browsersDevice test log
16PerformanceCore Web Vitals lab targets met on key pages on a simulated mid-range phonePipeline report
17PerformanceImages optimised, responsive and lazy-loaded; fonts self-hosted and preloadedNetwork panel review
18PerformanceThird-party scripts registered, minimal, consent-gated where requiredRegister matches network panel
19AccessibilityAutomated accessibility checks clean on every pagePipeline report
20AccessibilityKeyboard navigation through every page and form; visible focus; no trapsManual test
21AccessibilityScreen reader pass on key pages and the main formManual test on phone and desktop
22AccessibilityColour contrast meets the standard everywhere; reduced motion respectedAutomated plus manual
23SecuritySecurity headers, content security policy, HSTS set and verifiedHeader scan clean
24SecurityDependency scan clean; no known vulnerabilities outstandingPipeline report
25SecurityNetwork layer in front; origin not directly reachableDirect origin request fails
26SearchTitles, descriptions and social preview images on every pageCrawl report
27SearchSitemap generated and submitted; robots file correct; preview environments not indexableSearch console; robots checked
28SearchStructured data valid for the organisation and key page types; canonicals setValidation tool
29MeasurementAnalytics installed, goals defined, verified firing; consent respected; search console verifiedTest visit visible; consent test
30MeasurementMonitoring for uptime, certificate, domain and key forms with alerts to named peopleTest alert received

Running it

  1. On the final preview: every item verified, evidence recorded, business sign-offs collected.
  2. Fix or consciously defer any failure; a deferral has an owner and a date.
  3. Lower the DNS time-to-live a day before; confirm rollback works.
  4. Switch DNS in the quiet window; the platform serves the site and the redirects.
  5. On the live site: items 9 through 13, 23, 25, 27, 29 and 30 verified again, because they depend on the real domain.
  6. Watch monitoring, forms and the not-found log for the first days; add redirects for anything missed.
  7. Write the launch report with the completed list and evidence.

After launch

The first month completes the launch: the not-found log reveals addresses the redirect map missed, real-user data replaces lab estimates, forms are checked against the CRM, and the month-end review confirms the list still holds. Items on this list that drift, accounts, dependencies, scripts, monitoring, then move into the monthly checklist for the life of the site.

What this means for you

Treat launch as thirty verified items across ownership, content, technical setup, performance, accessibility, security, search and measurement, run on the final preview and again on the live site, in a quiet window with rollback ready. Most of the items take a minute on a well-built site, the afternoon they take together prevents the weeks of discoveries that follow an unverified launch, and the completed list is the record you will be glad to have.

Written by the CivSec S.M.A.R.T team

We build and run websites, software and AI systems for businesses. We write about what we see in that work, in plain language, and we update articles when things change.

Last checked . Spotted something outdated? Tell us.

Frequently asked questions

Why thirty items? Is that not excessive for a business website?

Each item is a way a launch has gone wrong for someone. Most take a minute to verify when the site was built properly, and the whole list takes an afternoon on the preview and an hour on the live site. The alternative is discovering the missing item from a customer, a search engine or an attacker in the weeks after launch, which costs more than the afternoon.

What if an item fails on launch day?

Either it is fixed on the preview before the switch, or the launch is deferred, or the item is consciously deferred with a date and an owner if it is genuinely non-blocking, such as a secondary language. What does not happen is launching with a failing blocking item and hoping. The switch itself is reversible within minutes, which removes the pressure to gamble.

Who runs the checklist?

The partner runs it and records the evidence; the business confirms the items that are theirs: content approved, accounts in their name, legal pages reviewed, the launch window agreed. The completed list, with evidence and dates, is part of the launch report and the first document a future audit reads.