Website Launch Checklist

Everything to verify before you push a site live: SEO, analytics, accessibility, performance, legal, forms, redirects, and a 24-hour post-launch monitoring plan.

Everything that must be verified before a site goes live, grouped by the order you should verify it in, plus the 24 hour watch that catches what testing missed. Most launch damage is not caused by the new site being wrong. It is caused by the old site's URLs, tracking, and forms quietly disappearing.

Reach for this when

You are replacing an existing site and the old URLs already have search rankings and inbound links.
You are launching a new site or a major section and want one authoritative pre flight list.
Multiple parties are involved, such as an agency, a developer, and an internal marketer, and nobody owns the handover.
A previous launch lost traffic or leads and you want a repeatable process this time.

Redirects and URL continuity

Do this first and treat it as the highest risk item on the list. A perfect new site with broken redirects loses rankings and referral traffic that took years to earn.

Export every URL from the old site: the sitemap, the crawl, the analytics landing page report, and the search console page report.
Map every old URL to its closest new equivalent. Map to the most relevant page, not to the homepage.
Use 301 permanent redirects. Avoid chains, and never redirect through more than one hop.
Test the top 50 old URLs by traffic manually after the switch, not just in staging.
Keep the redirect map in version control. You will need it again in a year.
Verify that URLs referenced in printed material, QR codes, email templates, and ad accounts still resolve.

SEO

Two of these have ended more launches than every other item on this page combined: the staging noindex tag left in place, and the robots.txt disallow that was never removed.

Remove any noindex tag and any robots.txt disallow used during staging. Check the live site, not the codebase.
Submit the new sitemap in search console and confirm it parses.
Verify title tags and meta descriptions render server side on every template, not only after JavaScript executes.
Confirm canonical tags are self referencing and use the final protocol and host.
Choose one canonical host, with or without www, and redirect the other. Same for http to https.
Validate structured data on one page of every template type.
Crawl the staging site and fix every 404 and every redirect chain before launch, not after.

Analytics and tracking

If tracking is wrong on day one, you lose the baseline you need to prove the launch worked. Verify with real events, not with the presence of a tag.

Analytics tag present on every page including error pages, thank you pages, and any subdomain.
Conversion events fire and appear in real time reporting. Submit a real form and watch it arrive.
Ad platform tags and server side endpoints verified with live test traffic.
Search console and Bing webmaster tools verified for the final host, with the old property retained.
Consent banner behaves correctly: tags hold until consent, and the reject path genuinely rejects.
Annotate the launch date in every analytics property, so future you can explain the discontinuity.

Forms, email, and integrations

Test the whole path, not the submit button. Broken form routing is invisible for weeks because failure looks exactly like a quiet week.

Submit every form with a real address and confirm the record reaches the CRM or inbox it should.
Confirm autoresponders send, render on mobile, and come from an authenticated domain.
Check spam protection is active and is not blocking legitimate submissions.
Verify newsletter signups land in the right list with the right source and tags.
Test payment, registration, or booking flows end to end with a real transaction where possible.
Confirm error states: what a user sees when a submission fails should be a message, not a blank page.

Performance, accessibility, and content

The quality layer. These rarely block a launch but they are far cheaper to fix before traffic arrives than after.

Core Web Vitals measured on mobile on a real device, not only in a desktop lab test.
Images compressed, correctly sized, and lazy loaded below the fold.
Keyboard navigation works through the entire primary journey, and focus is always visible.
Colour contrast meets the standard, images have alt text, and form fields have real labels.
Proofread every page. Check placeholder text, sample content, and the year in the footer.
Test at mobile, tablet, and desktop widths, and in both light and dark system settings if the site responds to them.

Legal, access, and infrastructure

The unglamorous block that becomes urgent at the worst possible moment.

Privacy policy, terms, and cookie notice published and linked in the footer.
SSL certificate valid, auto renewing, and covering every host you serve.
DNS records confirmed, with TTL lowered ahead of the switch and raised again afterwards.
Backups running and a restore actually tested once.
Access documented: who holds the domain, the host, the CDN, the CMS, and the analytics accounts.
A staging environment that remains available after launch, and is blocked from indexing.

The 24 hour watch

Launch is the start of the work. Assign one person to watch, and give them a clear escalation path.

Hour 1: crawl the live site, confirm 200 responses on the top 50 URLs, submit a test form.
Hour 4: check analytics real time traffic against the same hour last week.
Hour 12: check server error logs and the 404 report for patterns.
Hour 24: check search console coverage for new errors and confirm indexing has begun.
Day 7: compare organic landing pages against the previous week and investigate any URL that lost all its traffic.
Day 30: full post launch review against the pre launch baseline you captured.

How to use it

Capture a baseline before you launch: traffic by landing page, rankings for your top queries, conversion rate, and form volume. Without it you cannot tell whether the launch worked.
Assign an owner to each block. Blocks without a name attached are the ones that get skipped at midnight.
Work the redirect block first and complete it before anything else begins.
Launch on a Tuesday or Wednesday morning. Friday launches mean nobody is watching when the problem appears.
Run the checklist twice: once on staging a week out, and once on production within the first hour.
Keep the completed checklist. It becomes the launch record and the starting point for the next one.

Common mistakes

Redirecting the whole old site to the homepage, which discards the accumulated value of every ranking page.
Leaving the staging noindex tag or robots.txt disallow in place, which removes the site from search results without any visible symptom.
Verifying tracking by confirming the tag is present rather than by generating a real conversion and watching it arrive.
Launching without a pre launch baseline, which makes every later discussion about impact an argument about opinions.