The technical SEO checklist we actually run before every launch

Every single item on this particular checklist exists because it went genuinely wrong on a real client launch at some point, either one of ours directly or a project we inherited and had to fix afterward. It's deliberately not a theoretical best-practices list assembled from a blog post somewhere. It's the specific, battle-tested set of checks that has actually, demonstrably prevented a repeat of a real, expensive mistake we've personally seen happen.

The single most common launch-day disaster we've encountered is a staging environment's noindex meta tag accidentally shipping straight through to the production site, or a robots.txt file still blocking the entire site from crawling because it was carried over unchanged from a staging configuration. We check this manually, by hand, not just by trusting the deploy pipeline to handle it correctly, because we've personally watched an entire site silently deindex itself over the course of a week before anyone on the team even noticed something was wrong.

A sitemap that still references old, now-removed URLs, or that's simply missing new ones entirely, meaningfully slows down how quickly Google actually discovers and re-crawls a changed site structure after launch. We regenerate and formally resubmit the sitemap as an explicit, required part of the launch checklist itself, rather than treating it as a separate follow-up task someone might reasonably forget to do afterward once the excitement of launch day has passed.

A staging environment's canonical tags occasionally get accidentally carried over wholesale into production, quietly telling Google that the real, live page's canonical version actually lives on a staging URL that isn't even publicly accessible to anyone. This is a genuinely subtle issue that doesn't throw any obvious visible error anywhere, it just slowly and quietly costs rankings over subsequent weeks while everything otherwise looks completely fine on the surface.

We run every single page template's structured data through Google's own Rich Results Test tool before every launch, rather than just visually eyeballing the raw JSON and assuming it's correct. A single malformed or missing required field can silently invalidate an entire schema block, quietly losing rich result eligibility that took genuine real effort and content work to properly earn in the first place.

A launch-day check catches most problems, and some issues only surface once real crawling and indexing activity actually begins, a day or two after the site goes fully live. We run a lighter version of the same checklist again roughly a week later specifically to catch anything that only shows up once Google's own systems have had time to actually process the new site.

This second pass has caught real issues the first one missed more than once, usually something related to crawl budget or an indexing anomaly that simply wasn't visible until real crawler activity had accumulated.

Spot-checking a handful of redirects manually feels thorough and reliably misses real gaps, since the URLs someone thinks to check by hand are rarely the ones actually causing a problem. We run a full automated crawl of the entire old URL list against the live new site as a standard, required checklist item, flagging every redirect that returns anything other than a clean single-hop 200, whether that's a 404, a redirect chain, or a redirect pointing somewhere unexpected.

This full-crawl approach has caught redirect gaps on nearly every launch we've run it against, even ones where the team doing the manual spot-check was confident everything looked fine. The gap between "looks fine on a sample" and "is actually fine across every URL" is exactly where a real ranking loss quietly hides.

A site that tested fast on a staging server can behave meaningfully differently once it's live on production infrastructure, with a different CDN configuration, different caching rules, or real production traffic load that a staging environment never experiences. We re-run Core Web Vitals testing specifically against the live production URLs after launch, not just against staging beforehand, because we've seen real performance regressions appear only once a site moved to its actual production environment.

Catching this within the first day or two of launch, while it's still fresh and easy to trace back to a specific configuration change, is considerably easier than discovering it weeks later through a slow, unexplained decline in rankings or user engagement metrics.

A checklist that exists but doesn't have a single named owner responsible for actually running it, item by item, tends to quietly get skipped under launch-day time pressure, when everyone assumes someone else already handled it. We assign one specific person per launch as the checklist owner, with explicit sign-off required before a launch is considered complete, rather than treating it as a shared, informal responsibility that in practice belongs to nobody in particular.

This single change, naming an actual owner rather than leaving it as a team responsibility, has been the biggest single factor in how consistently this checklist actually gets run in full, especially on launches happening late in the day or under real deadline pressure when it's easiest to justify skipping a step.

The checklist today is considerably longer than the version we started with several years ago, and we've also actively removed a few older items once they stopped being relevant, an old AMP-specific check, for instance, once that particular format stopped mattering for most client sites. We treat the list as a living document that needs occasional pruning as much as occasional addition, since a checklist that only ever grows eventually becomes long enough that people start skimming it instead of genuinely running through it.

Reviewing the list itself once a year, asking honestly whether each item still reflects a real, current risk, has kept it useful rather than letting it quietly become a relic of problems that stopped being relevant years ago.