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.
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
| # | Area | Item | Verified by |
|---|---|---|---|
| 1 | Ownership | Domain registered in the business’s name, locked, auto-renewing, two-factor on | Registrar account checked |
| 2 | Ownership | Hosting project, repository and every service account in the business’s name or organisation | Ownership pages checked |
| 3 | Ownership | Access register current; per-person access; no shared logins | Register reviewed |
| 4 | Content | Every page has final content; no placeholder text or images | Full-site search for placeholder patterns; manual read |
| 5 | Content | Legal pages present and reviewed: privacy, cookies if applicable, terms, imprint as required | Business sign-off recorded |
| 6 | Content | Contact details, opening hours, addresses correct on every occurrence | Manual check; structured data matches |
| 7 | Content | Every image has meaningful alt text or is marked decorative | Automated check plus sample review |
| 8 | Content | Internal links resolve; no broken links | Crawl of the preview clean |
| 9 | Technical | Forms submit, validate, reach the right inbox and CRM, and confirm to the sender | Test submissions end to end |
| 10 | Technical | Anti-spam, rate limits and honeypot on every form | Test with a script; limit hit |
| 11 | Technical | Not-found page returns the correct status and is helpful | Nonsense address tested; status checked |
| 12 | Technical | Redirect map complete and tested; every old address maps to its equivalent | Automated redirect test against the list |
| 13 | Technical | Custom domain configured; HTTPS with valid certificate; www and bare domain resolve to one | Browser and certificate check |
| 14 | Technical | Environment variables set for production; secrets in secret storage only | Platform settings; repository scan |
| 15 | Technical | Browser support policy met; tested on real phones, desktops, in-app browsers | Device test log |
| 16 | Performance | Core Web Vitals lab targets met on key pages on a simulated mid-range phone | Pipeline report |
| 17 | Performance | Images optimised, responsive and lazy-loaded; fonts self-hosted and preloaded | Network panel review |
| 18 | Performance | Third-party scripts registered, minimal, consent-gated where required | Register matches network panel |
| 19 | Accessibility | Automated accessibility checks clean on every page | Pipeline report |
| 20 | Accessibility | Keyboard navigation through every page and form; visible focus; no traps | Manual test |
| 21 | Accessibility | Screen reader pass on key pages and the main form | Manual test on phone and desktop |
| 22 | Accessibility | Colour contrast meets the standard everywhere; reduced motion respected | Automated plus manual |
| 23 | Security | Security headers, content security policy, HSTS set and verified | Header scan clean |
| 24 | Security | Dependency scan clean; no known vulnerabilities outstanding | Pipeline report |
| 25 | Security | Network layer in front; origin not directly reachable | Direct origin request fails |
| 26 | Search | Titles, descriptions and social preview images on every page | Crawl report |
| 27 | Search | Sitemap generated and submitted; robots file correct; preview environments not indexable | Search console; robots checked |
| 28 | Search | Structured data valid for the organisation and key page types; canonicals set | Validation tool |
| 29 | Measurement | Analytics installed, goals defined, verified firing; consent respected; search console verified | Test visit visible; consent test |
| 30 | Measurement | Monitoring for uptime, certificate, domain and key forms with alerts to named people | Test alert received |
Running it
- On the final preview: every item verified, evidence recorded, business sign-offs collected.
- Fix or consciously defer any failure; a deferral has an owner and a date.
- Lower the DNS time-to-live a day before; confirm rollback works.
- Switch DNS in the quiet window; the platform serves the site and the redirects.
- On the live site: items 9 through 13, 23, 25, 27, 29 and 30 verified again, because they depend on the real domain.
- Watch monitoring, forms and the not-found log for the first days; add redirects for anything missed.
- 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.
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.