Technical launch checklist: from staging to production without losing SEO

The vast majority of launch-day SEO disasters don't come from a complex technical problem, but from a checklist step nobody ticked because there was no checklist. A staging environment with an inherited noindex, a redirect verified after the DNS cutover instead of before, a canonical still pointing at the staging domain: these are trivial mistakes to fix individually, but devastating if discovered days after launch, once Google has already started processing the broken version. This guide is a concrete checklist, in the order it should run, not a conceptual explanation of why each point matters (that's already covered in the topic-specific guides, linked where relevant).

Before launch: what to check on staging

By far the most common launch mistake is leaving in production the crawl block that protected the staging environment. Most staging environments, as good practice, carry a Disallow: / in robots.txt or a global noindex tag, precisely so Google doesn't index a test copy of the real site. The problem shows up when that block gets accidentally carried over into production (because staging and production share the same configuration file, or because nobody remembers to disable it in the final deployment) and the entire site is invisible to Google from day one, sometimes for weeks before anyone notices.

Mandatory check before considering the launch complete:
curl -s https://www.yourdomain.com/robots.txt
# Must NOT contain: Disallow: /
# Must point to the correct production sitemap

curl -sI https://www.yourdomain.com/ | grep -i x-robots-tag
# Must NOT return: noindex

# And review the  of the actually served HTML, not just the editor template:
#  inherited from staging
# is the most common and most expensive launch-day mistake

Redirects: verify them before the DNS cutover, not after

When a launch involves a domain change, a URL structure change, or both, the redirects from old URLs to new ones have to be tested and working before pointing DNS at the new destination, not after. The usual mistake is assuming "the redirects will get set up once the site is live," which leaves a window (sometimes hours, sometimes days) where old URLs return 404 instead of redirecting, precisely the period when Google, drawn in by the detected content change, tends to check those URLs more often than usual. Verifying redirects against the staging environment before the DNS cutover, by simulating the final domain with a temporary entry in the local hosts file, confirms every relevant old URL redirects correctly before the change goes public.

Sitemap, robots.txt and canonical: pointing at production, not staging

Three related checks worth doing together because they share the same usual root cause (a configuration value copied from staging and never updated): the submitted XML sitemap must contain production-domain URLs, not staging or some intermediate version; production's robots.txt must declare the production sitemap, not leave the reference to the staging sitemap that sometimes gets forgotten; and every page's <link rel="canonical"> tag must resolve to the final domain, an especially frequent mistake when the site was developed and tested for weeks under a staging subdomain and that URL got hardcoded into some component instead of being generated dynamically from the request's real domain.

SSL and HSTS: certificate live and no accidental access blocks

The production domain's SSL certificate has to be live, valid and correctly chained (no intermediate trust-chain errors) before launch, not as a follow-up task: an "unsafe connection" warning on a real user's first visit is as damaging to trust as it is to SEO. A nuance that causes serious problems if overlooked: if the site enables HSTS (HTTP Strict Transport Security, which forces the browser to remember that domain must only ever be visited over HTTPS) with a long duration (max-age of months or years), and especially if the preload variant is enabled (which bakes it into a list preloaded into browsers themselves), any later certificate problem leaves the domain completely unreachable for anyone who already has it cached, with no way to "fall back" to HTTP while it's fixed, because the browser itself refuses the insecure connection without even attempting it.

# Reasonable HSTS header for a recent launch:
Strict-Transport-Security: max-age=86400; includeSubDomains
# (24 hours: lets you raise the duration progressively
# once the certificate is confirmed stable,
# instead of committing upfront to a year-long max-age or preload)

The correct order of operations on launch day

The sequence that minimizes risk isn't "switch DNS and then check," but checking everything above first against the final environment already deployed (accessing it by direct IP or via a temporary entry in the local hosts file): no robots blocks, redirects working, valid SSL, correct canonical and sitemap. Only once those checks pass against the real destination does the DNS cutover happen, and only after DNS propagation has completed (verifiable with public propagation tools) is the launch considered technically finished, though active monitoring keeps going.

The first 48 hours: what to watch and how often

The launch doesn't end when DNS propagates: the first 48 hours are the window where most problems not caught in earlier checks surface, because that's when Google starts re-crawling the domain normally and exposing discrepancies. The minimum recommended routine during that window: check Search Console's coverage report several times a day looking for sudden spikes in exclusions (URLs marked as blocked, erroring, or excluded via canonical to another page); check the crawl stats report to confirm Google is still crawling normally and hasn't detected server errors; and turn on 404 monitoring in the server logs or via a log analysis tool, to quickly catch any old un-redirected URL that slipped through the earlier check.

Frequently asked questions