Website Launch Checklist

A website launch checklist is a pre-release QA control for crawlability, redirects, performance, analytics, accessibility, metadata, and structured data. It reduces the chance that a visually finished launch goes live with broken measurement or search visibility problems.

Indexing and crawl

• Remove staging noindex directives and password protection. This is the most expensive launch mistake because nothing in a visual QA pass reveals it. A leftover noindex keeps pages out of the index until it is removed and the pages are recrawled, which can take weeks on a low-authority site.
• Verify robots.txt and the XML sitemap are correct and submitted. A staging Disallow: / shipped to production blocks crawling entirely. Check that the sitemap lists canonical URLs only — not redirects, not noindexed pages — because a sitemap full of non-indexable URLs slows discovery of the ones that matter.
• Set canonical URLs and resolve duplicate paths. Decide one form for trailing slashes, uppercase, www, and protocol, then redirect the rest rather than canonicalising them. Query parameters from campaigns and filters are the usual source of duplicates nobody planned for.
• Map and test 301 redirects from old URLs. Redirect to the closest equivalent page, not the home page — a redirect to an irrelevant destination is treated as a soft 404 and passes nothing. Test the full list after deploy, not before, and check for chains: each hop adds latency and a chain longer than a few hops may not be followed.

Performance and Core Web Vitals

• Optimize images and serve modern formats. Images are the most common LCP element. Set explicit width and height so the browser reserves space — missing dimensions are a leading cause of layout shift — and preload the hero image rather than lazy-loading it.
• Check LCP, CLS, and INP on representative templates. The thresholds are LCP under 2.5s, INP under 200ms, and CLS under 0.1, each measured at the 75th percentile. Test a page from every template, not just the home page: Core Web Vitals are assessed per URL group, so a fast home page hides a slow product or article template.
• Confirm caching and CDN behavior in production. Cache headers that worked in staging often differ behind a production CDN. Verify that HTML is not cached longer than intended and that a purge actually propagates, or the first content fix after launch will appear to do nothing.

Measurement

• Confirm analytics, tag manager, and conversions fire in production. Test in the live environment, not preview mode. Preview bypasses consent, ad blockers, and production CSP headers — all three of which silently drop tags for a meaningful share of real traffic.
• Verify consent management is live and enforced. Check the denied state as carefully as the granted one. The failure worth catching is tags that fire before consent is given, which is a compliance problem rather than a data problem.
• Reconcile key conversions against source systems. Compare a day of analytics conversions against the CRM or order system. A gap under roughly 5% is normal attrition from blockers and consent; a larger or one-directional gap means something is broken. Do this before anyone reports on the numbers, not after.

Content and accessibility

• Validate titles, meta descriptions, and structured data. Check for template defaults that escaped — duplicated titles and untouched placeholder descriptions are the usual survivors. Validate structured data against the Rich Results Test, and make sure it describes what the page actually shows.
• Check headings, alt text, and keyboard navigation. One H1 per page in a logical order, alt text that conveys purpose rather than repeating the filename, and every interactive element reachable and operable by keyboard with a visible focus state.
• Test forms, error states, and confirmation pages. Test the failure paths: an invalid submission, a duplicate, a timeout. Error states are the least-tested part of most launches and the most likely to lose a conversion silently.

Post-launch monitoring

• Watch Search Console for crawl and indexing errors. Expect ranking movement for a few weeks after a URL change; that is recrawl and reprocessing, not necessarily a problem. What warrants action is a rising count of pages excluded as crawled-not-indexed or discovered-not-indexed.
• Monitor uptime, 404s, and redirect chains. Watch referrer data on 404s to find inbound links pointing at URLs the redirect map missed — those are the ones costing traffic.
• Re-check Core Web Vitals with field data after a few weeks. Lab tools measure one run on one connection. Field data reflects real devices and networks, and the Chrome UX Report needs about 28 days of collection before the post-launch numbers mean anything.

If a launch is part of a platform change, the headless CMS decision guide below covers the architecture trade-offs.