The Website Launch Checklist: 20 Checks Before (and After) You Go Live

Quick answer

Most website problems discovered in month three were checkable in hour one. This is the launch checklist we run on every build, twenty checks across six areas, sequenced so the traffic-critical items (redirects, indexing, forms) come first. Print it (or use the printable 40-point version), and don’t let “we’ll fix it after launch” past the forms test: a website whose contact form silently fails is a shop with a locked door and no way of knowing.

Content & conversion (the door handles)

1. Every form tested end-to-end: submit each one, confirm the email arrives (and to the right inbox), check the thank-you state. Test from a phone on mobile data, not just the office wifi.
2. Phone numbers tap-to-call and email addresses clickable on mobile.
3. One clear action per page, so a visitor landing anywhere should see what to do next without scrolling twice.
4. Placeholder purge. Search the site for “lorem”, “TBC”, “[insert” and the template’s demo text. Something always survives.
5. 404 page exists and helps: branded, with navigation back to services and contact.

SEO & redirects (the traffic protectors)

6. Redirect map live, if replacing an old site: every old URL 301s to its successor, not the homepage. This is the single most expensive check to skip; the reasoning is covered in website redesign without losing rankings.
7. Indexing unblocked, with the “discourage search engines” tick and any staging noindex/robots block removed. Sites have stayed invisible for months over this checkbox.
8. Titles and meta descriptions on every page: unique, written for the click, not stuffed.
9. XML sitemap submitted in Google Search Console, and Search Console verified in your account (ownership matters; same logic as domains).
10. One canonical domain: www or non-www, http→https, one version reachable, the rest redirecting.

Performance & mobile

11. Real-device mobile pass, not the browser’s responsive mode: an actual phone, on mobile data. Half of UK traffic is this experience.
12. Images sized and compressed. The classic launch-day sin is 4MB photos straight from the camera. Aim for pages under ~2MB total.
13. Speed sanity check: PageSpeed Insights on the homepage and one service page; fix anything scoring red before launch, not after. Slow hosting can cap everything. See what hosting should cost.

Security & resilience

14. HTTPS everywhere: padlock on every page, no mixed-content warnings.
15. Admin accounts hardened, with unique passwords, 2FA, no “admin” username, agency accounts removed or downgraded post-handover.
16. Backups running and tested: one restore test before launch; the full regime is in the WordPress maintenance guide.

Legal (the UK bits)

17. Privacy policy and cookie consent, matching what the site actually sets; analytics and marketing pixels need consent under UK rules.
18. Business details where required: limited companies must show registered name, number and office on the site (the same Companies Act rules as stationery); VAT number if registered, and terms for e-commerce.

Measurement

19. Analytics live and receiving: GA4 (or your choice) firing on all pages, goals/conversions configured for form sends and calls, and verified with a real test event.
20. Search Console + analytics linked, baseline noted. You’ll want the before/after in three months.

The 30-day watch

Launch isn’t the end state. Weekly for the first month: Search Console coverage report (crawl errors, unexpected noindex), form submissions vs analytics events (leaks show here), 404 log for missed redirects, and speed on the pages that matter. Most launch defects surface in these four places within a fortnight. Caught then, they’re ten-minute fixes. And once stable, the site moves onto its maintenance rhythm, a launch checklist gets you live; the maintenance habit keeps you that way. If the build itself is still ahead of you, what a website costs and our WordPress design service cover the road to this point.

Who does what: a launch-day responsibility split

Half of failed launches are not technical failures but ownership failures: everyone assumed the other party had done it. Agree this table in writing a fortnight before go-live, not on the morning itself.

The account-ownership rows matter beyond launch day. Domains, analytics and hosting registered in a supplier’s name are the single most common cause of expensive stand-offs when a business changes agency, the ownership discipline set out in choosing and holding a UK domain applies to every account in that column.

The seventy-two hours before go-live

Sequence matters more than effort. Run the launch in this order and the risky steps happen while someone is awake to fix them.

• T-72 hours: lower DNS TTL to 300 seconds so the switch propagates in minutes rather than a day. This one step turns a scary irreversible moment into something you can roll back over a coffee.
• T-48 hours: content freeze. No new pages, no last-minute copy edits. Every launch that overruns overran because someone added “one more page” on the final evening.
• T-24 hours: full crawl of the staging site with a free crawler. You are hunting broken internal links, missing titles, orphan pages and any URL that will not exist on the live domain.
• T-2 hours: take a full backup of the old site, files and database, and keep it somewhere that is not the hosting account you are about to change.
• Go-live: switch DNS, then immediately re-test forms, HTTPS and the redirect map on the real domain. Staging passing means nothing; the live domain is a different environment.
• T+2 hours: restore the TTL, submit the sitemap, and request indexing on the ten pages that matter commercially.

Never launch on a Friday afternoon or the day before a holiday. The defects you cannot foresee surface within about six working hours, and you want someone available for them.

The redirect check nobody does properly

Everyone maps the URLs they remember. The rankings you lose are on the pages you forgot. Before launch, build the old-URL list from three sources rather than one: your existing site’s XML sitemap, the Search Console performance report exported by page for the last sixteen months, and your server or analytics logs. Sitemaps miss old pages that were unpublished but still hold links; Search Console shows what actually earned impressions; logs catch the PDF, the old landing page and the campaign URL nobody documented.

Then test the map rather than trusting it. Run the full old-URL list through a crawler after go-live and check three things: every URL returns a single 301 (not a chain of three), every destination returns a 200 rather than a 404, and no URL quietly lands on the homepage. Redirect chains and homepage dumping are the two habits that turn a routine migration into a six-month traffic dip, which is why they get their own treatment in redesigning without losing rankings.

Costed extras people forget to budget

Photography and copy are the two line items most often cut at the end of a build, and they are the two that decide whether the site converts. If the budget is tight, launch with fewer pages done properly rather than more pages half-filled, and keep a small contingency for the fortnight after go-live, because something always needs a designer’s hand once real traffic arrives. Any fixed-fee website design quote should tell you before you commit exactly which of these rows sit inside the price and which do not.

The first ninety days, measured

Once the four weekly checks in the watch period settle, switch to a monthly rhythm and keep an eye on a small set of numbers rather than a dashboard nobody opens: enquiries per month, the proportion arriving by phone versus form, which five pages bring the most entrances, and how many visitors leave without a second page. Those are the same figures that make sense of everything else in website analytics for beginners. Two habits belong in the same rhythm: check that backups are still running and restorable, and check that plugin and core updates are being applied, because an unpatched site three months after launch is a far more likely disaster than a design flaw. Finally, re-run a speed test on a real phone after eight weeks; sites get slower as content is added, and the day-one score is not a permanent result: a page that passed at launch with four images rarely still passes with forty.

Sources & Further Reading

• Google SEO Starter Guide, Google
• Core Web Vitals, web.dev
• Cookies Guidance, Information Commissioner's Office