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.

  How to verify: Request one production URL per template with curl -sI, then view its source.

  Pass when: No noindex in the X-Robots-Tag header or the robots meta tag, and every page returns 200 without a login prompt.

• 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.

  How to verify: Open /robots.txt and the sitemap on the production host, crawl the sitemap’s URLs, and submit it in Search Console.

  Pass when: No Disallow: / for all user agents, the sitemap is referenced in robots.txt, Search Console reports it as Success, and every listed URL returns 200 and is self-canonical.

• Decide AI crawler access on purpose, at every layer that enforces it. robots.txt is one layer; a CDN or WAF bot rule is another, and the two can disagree — a crawler the file allows can still be refused at the edge. Write the policy down, then check each layer: robots.txt groups for the AI crawlers you care about (a named user-agent group replaces the * group entirely, so repeat every rule in it), an llms.txt if you publish one, and the bot settings of whatever sits in front of the site. The three layers of AI crawler access walks through each one.

  How to verify: Read each robots.txt group against the written policy, then check the CDN or WAF security events for requests from verified crawlers. A spoofed user agent from your own machine is only an approximation.

  Pass when: Verified crawlers the policy allows receive 200s, and every named group repeats the rules of the * group.

• Verify Search Console and Bing Webmaster Tools before launch, not after. Verify a domain property by DNS so data accrues from the first crawl, submit the sitemap on launch day, and deploy the IndexNow key file with the site. IndexNow reaches Bing and several other engines but not Google, which keeps discovering through the sitemap and Search Console.

  How to verify: On launch day, open both tools and request the IndexNow key file URL.

  Pass when: Both properties show as verified with the sitemap submitted, and the key file returns 200 with the key as its only content.

• 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.

  How to verify: Request the http, www or non-www, trailing-slash, and uppercase variants of a few URLs, and read each page’s canonical tag.

  Pass when: Every variant 301s in one hop to the chosen form, and the chosen form’s canonical points to itself.

• Map and test 301 redirects from old URLs. Redirect to the closest equivalent page, not the home page — a redirect to an irrelevant destination can be treated as a soft 404, which passes nothing. Test the full list after deploy, not before, and check for chains: each hop adds latency, and Google’s crawlers follow at most ten, so keep every old URL to a single redirect.

  How to verify: After the deploy, run the full list of old URLs through a crawler in list mode or a curl loop.

  Pass when: Every old URL returns a single 301 to a 200 page that is its closest equivalent: no chains, and no blanket redirects to the home page.

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.

  How to verify: Run Lighthouse on one URL per template and read the LCP element and the image audits.

  Pass when: Images are served as WebP or AVIF, every image has width and height set, and the LCP image is not lazy-loaded.

• Check LCP, CLS, and INP on representative templates. The “good” thresholds are LCP within 2.5 seconds, INP of 200 ms or less, and CLS of 0.1 or less, 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.

  How to verify: Test one URL per template in PageSpeed Insights, on mobile.

  Pass when: Every template meets the LCP and CLS thresholds in the lab. INP is confirmed later from field data, because lab tools cannot measure it.

• 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.

  How to verify: Read the Cache-Control and CDN cache-status headers on HTML and on static assets, then edit a page and purge.

  Pass when: HTML is not cached longer than intended, fingerprinted assets are cached long, and the edit appears right after the purge.

Security and infrastructure

• Serve everything over HTTPS, with HSTS and baseline security headers. Redirect HTTP to HTTPS in a single hop, and add Strict-Transport-Security only once every subdomain serves HTTPS — browsers cache it, so a mistake is slow to undo. Write the content security policy for the tags as well as the site: a CSP that does not list the analytics and tag endpoints is a common reason measurement dies on launch day.

  How to verify: Request http:// on every hostname, read the response headers of an HTTPS page, and open the console on a page where every tag fires.

  Pass when: A single 301 to HTTPS, a Strict-Transport-Security header, and no content security policy violations in the console.

• Lower DNS TTLs before the cutover and write the rollback plan. Drop the TTL on the records you will change at least one old-TTL period ahead, so the switch propagates in minutes rather than hours. Then write the rollback down: what triggers it, who decides, how long it takes, and whether the old environment stays reachable until the new one is accepted.

  How to verify: Query the records with dig the day before the cutover, and read the rollback document.

  Pass when: The records show the lowered TTL, for example 300 seconds, and the rollback plan names a trigger, a decision-maker, and a time to restore.

• Protect forms from spam without breaking them. Add a honeypot field or a low-friction challenge before launch, because bots find new forms quickly. Then re-test a real submission end to end: a filter that silently rejects legitimate leads costs more than the spam it stops.

  How to verify: Submit each form as a real user, then once with the honeypot field filled in.

  Pass when: The real submission reaches the CRM or inbox, and the honeypot submission is rejected.

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.

  How to verify: Complete each conversion on the production site in an ordinary browser session, with the network tab and the analytics real-time view open.

  Pass when: Every conversion appears exactly once in real time, with the expected parameters.

• 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.

  How to verify: In a clean browser, deny consent and watch the network tab; repeat with consent granted.

  Pass when: Before a choice, no analytics or advertising request is sent beyond the cookieless pings your consent mode allows, and after it, tags follow the choice.

• 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.

  How to verify: Compare one full day of conversions in analytics with the CRM or order system.

  Pass when: Analytics records slightly fewer conversions than the source system, within roughly 5%, and never more.

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.

  How to verify: Crawl the site, export titles and descriptions, and test one URL per template in the Rich Results Test.

  Pass when: No duplicate or placeholder titles or descriptions, and no structured data errors.

• 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.

  How to verify: Tab through each template without a mouse, and run an automated accessibility check such as axe or Lighthouse.

  Pass when: Every control is reachable with a visible focus, each page has one H1, and the check reports no missing alt text or heading-order errors.

• 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.

  How to verify: Submit each form with invalid input, twice in a row, and with the network throttled or offline.

  Pass when: Each failure shows a clear message, keeps what the user typed, and records no conversion.

• Set social preview images and the favicon. Give every template an og:image with an absolute URL, and check the preview in each platform’s sharing debugger before announcing — they cache the first scrape. Google shows the favicon beside your results: it must be square, at least 8×8 px (larger than 48×48 is recommended), and crawlable, along with the home page.

  How to verify: Paste one URL per template into each platform’s sharing debugger, and request the favicon URL.

  Pass when: Every preview shows the intended image and title, and the favicon returns 200 and is not blocked by robots.txt.

• Ship real 404 and 500 pages. A missing page must return a 404 status, not a 200 with “not found” text, which Google treats as a soft 404. Give it a way back into the site, and make sure the server-error page exists before the first outage needs it.

  How to verify: Request a made-up URL and read the status code, then simulate a server error.

  Pass when: The made-up URL returns 404 with a way back into the site, and the error page renders with a 5xx status.

• Publish the privacy policy and match the consent banner to the jurisdictions you serve. The policy has to be live before collection starts, and the banner’s defaults have to follow the strictest rule that applies — Québec’s Law 25 and CASL do not behave like US defaults. Then confirm the banner’s promises match what the tags actually do, using the consent checks in the measurement section.

  How to verify: Read the policy and the banner against the tag inventory, under each jurisdiction’s default.

  Pass when: Every tag that fires is disclosed in the policy, and none fires before the choice the banner asks for.

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.

  How to verify: Check the Page indexing report weekly for the first month.

  Pass when: Indexed pages climb toward the sitemap count, and “Crawled – currently not indexed” is not growing.

• 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.

  How to verify: Set up an uptime monitor, and filter server logs or analytics for 404s with their referrers.

  Pass when: Downtime alerts reach a named person, and every 404 with an external referrer gets a redirect.

• 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.

  How to verify: About 28 days after launch, open the Core Web Vitals report and the field data in PageSpeed Insights.

  Pass when: Every URL group is rated Good for LCP, INP, and CLS on mobile.

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

Sources

Factual claims on this page were checked against these primary sources on October 10, 2026:

• web.dev — Web Vitals (updated October 31, 2024) — supports the LCP, INP, and CLS thresholds and the 75th percentile.
• Search Console Help — Core Web Vitals report — supports grouping of similar URLs in the assessment.
• Chrome for Developers — CrUX API (updated February 11, 2025) — supports the 28-day rolling window of field data.
• Google Search Central — Site moves with URL changes (updated August 20, 2026) — supports irrelevant redirects being treated as soft 404s.
• Google — HTTP status codes and Google’s crawlers (updated February 4, 2026) — supports the limit of ten redirect hops.
• Google Search Central — General structured data guidelines (updated July 10, 2026) — supports testing with the Rich Results Test and marking up visible content only.
• Google Search Central — Favicon in search results (updated August 28, 2026) — supports the favicon size and crawlability requirements.
• Search Console Help — Page indexing report — supports the crawled-not-indexed and discovered-not-indexed statuses.