Sort the list by recoverability, not by importance
Every pre-launch SEO checklist you can find online is sorted by category — technical, on-page, content, analytics. That's a useful way to write a checklist and a useless way to run a launch week, because it gives a missing alt tag the same visual weight as a Disallow: / that will cost you a month of indexing.
Sort by recoverability instead. Ask one question of every item: if we ship this wrong and notice in two weeks, can we get back to where we'd have been? For most of the list the answer is yes. For a small handful it's a flat no, and those are the ones that deserve a named owner before the launch date is set.
| What ships wrong | Recoverable? | What it costs if you notice late |
|---|---|---|
| Analytics not firing on the live domain | No — the data never existed | You can't reconstruct launch-week behaviour, ever. The only truly permanent loss on this list |
| No frozen baseline of the old site's numbers | No | Every later argument about whether the launch hurt you is unwinnable, in both directions |
| The old site's URLs and titles never exported | No, once the old build is gone | You can't diff what you never recorded, so you can't find what broke |
Disallow: / shipped to production | Yes | Two to four weeks of lost crawling, recovered on Google's schedule rather than yours |
Site-wide noindex inherited from staging | Yes, but slower | Worse than the robots.txt version — pages already indexed get removed, then have to be re-earned |
| Both www and non-www returning 200 | Yes | Signals split across two hosts and months of muddled consolidation |
| Redirects from the old URLs missing | Yes, decreasingly | Every week they're absent, more external links point at 404s and more rankings decay |
| Meta descriptions, alt text, image compression | Yes, trivially | A Tuesday. Genuinely — ship without them rather than delaying a launch |
The four checks that catch most launch disasters
Run these on the production domain in the first hour after deployment, before anyone announces anything. Between them they cover the overwhelming majority of launches we've been called in to rescue.
One — the robots directive, in all three places
It can block you from three different files, and teams usually check one. Load /robots.txt on the live host. Run curl -sI against three URLs and read the headers for X-Robots-Tag. Then view source on three different templates and check the <meta name="robots"> tag.
The reason staging's file ends up in production is structural: robots.txt rules live at the top-level path of each host, so staging and production have genuinely separate files that a deploy pipeline is happy to copy over each other.
One nasty interaction worth knowing: if you block a URL in robots.txt *and* set noindex on it, Google never sees the noindex, because it can't crawl the page to find it. Blocked pages can still be indexed from external links. If you need something out of the index, let it be crawled. The full mechanics are on our robots.txt page.
Two — the canonical host resolves once
Request all four variants: http:// and https://, with and without www. Three of them should return a single 301 to the fourth. If two of them return 200, you've launched two websites.
Then check the rel=canonical hostname on three templates. Hardcoded staging hostnames in canonical tags are quietly one of the most damaging launch bugs there is — every page tells Google the real version lives on a domain Google can't reach, and view-source looks fine unless you're specifically reading the hostname.
Three — the sitemap and the navigation agree
Take the XML sitemap and assert four things about every URL in it: it returns 200, it isn't noindexed, its canonical points at itself, and a crawler can reach it from the homepage in three clicks or fewer.
Then check the reverse. Anything commercially important that appears in the sitemap but nowhere in the navigation is an orphan, and a sitemap entry is a weak substitute for an internal link. Disagreement between the two is the commonest sign that a new template silently dropped a link block.
Four — analytics fires on the real domain
This is the unrecoverable one, so it gets tested rather than assumed. Confirm the measurement ID on production isn't the staging property. Confirm the tag fires on every template, including the thank-you page nobody remembers exists. Then submit a real enquiry through a live form and watch it appear.
Verify Search Console on the production property before launch, not after — verification takes minutes and the data only starts when you do it. And export your trailing-90-day organic sessions, conversions and enquiries to a spreadsheet stored outside the analytics platform, because if you end up arguing about the size of a drop, you don't want to be arguing inside a tool whose tagging also changed on launch day.
Canonical host and trailing slash: decide before, not after
These two get treated as details and they're actually decisions, because reversing either one after launch means a second round of redirects and a second consolidation delay.
Pick https and one hostname, and be boring about it. Every internal link, every canonical tag, every sitemap entry and every hreflang reference should use that exact form. Google does prefer HTTPS pages over the equivalent HTTP page as canonical, but you shouldn't be relying on a preference when a 301 is available.
- Trailing slash.
/pricingand/pricing/are two different URLs as far as any crawler is concerned. Pick one, make the server 301 the other, and make your framework's setting agree — Next.js, most static hosts and most CDNs each have their own default and they don't always match. - The failure isn't dramatic, it's corrosive. Get it wrong and you ship a site where every internal link takes an extra hop, the sitemap disagrees with the navigation, and every report is split across two rows of the same page.
- Lowercase everything.
/Pricingand/pricingare also different URLs, and case sensitivity depends on the server. Enforce lowercase at the routing layer rather than hoping. - Decide what happens to query parameters — filters, tracking, session IDs — before the first crawl, not after 40,000 parameter URLs are in the index. The canonical tag is the instrument, but the decision is a product one.
- Write the rule down. One paragraph in the repo saying "https, non-www, no trailing slash, lowercase" prevents more launch bugs than any tool, because the next developer inherits the decision instead of guessing at it.
Redirects from the old site: what must exist on day one
If you're replacing an existing site rather than launching a first one, this is the section that decides whether the launch is a wobble or a hole. The full method is in the anatomy of a replatform that wiped 60% off organic traffic; here's what has to be live on day one.
Every old URL that earned a click or an impression in Search Console, every URL with a referring domain pointing at it, every URL in the old sitemap and every URL in a crawl of the old site — deduplicated into one list. Export the Search Console history before you launch; it's a rolling window and it doesn't wait for you.
- Map each one to its closest equivalent. Bulk-redirecting everything to the homepage is worse than a 404 — Google generally treats those as soft 404s and you lose the signal anyway, plus the user.
- Use server-side permanent redirects, one hop, no chains. Google's migration guidance recommends HTTP permanent redirects such as 301 or 308, and advises redirecting straight to the final destination rather than chaining.
- Keep them. Google's own documentation on site moves says to keep redirects in place for as long as possible, generally at least a year, so the signals have time to move across. The temptation to clean up the redirect map in month three is how people lose a launch twice.
- Test the whole map against staging before go-live: feed the old URL list at the staging host and assert a 301 landing on a 200 in a single hop. If you're doing this on more than a few thousand URLs, it's a migration project rather than a launch task.
- Brand-new domain with no history? This section is one line: make sure a "coming soon" placeholder or a developer's parked page isn't already indexed on the same URLs.
The 48-hour watch list, and what a normal dip looks like
Launches don't fail loudly. They fail as a chart that looks slightly wrong for three weeks and then obviously wrong in the quarterly review. Watch these in order.
- Hour one. The four checks above. Plus one URL Inspection in Search Console on a commercially important page, which tells you what Google actually sees rather than what your browser renders.
- Hours 2–24. Submit the new sitemap. Watch server logs or Search Console crawl stats for 5xx responses — a new build under first-crawl load is where hosting limits surface. Check your 404 volume; a spike means the redirect map has holes.
- Day two. Spot-check twenty old URLs by hand and confirm each returns a single 301 to a live page. Check the index coverage report for anything newly excluded.
- Days 3–14. Nothing else changes. Resist every temptation to also update copy, re-theme templates or re-do the navigation in the same fortnight. If three things change at once, nothing that follows can be attributed to any of them.
What genuinely can wait until Tuesday
The other half of a useful checklist is permission to launch. These are real improvements and none of them is worth delaying a date for, because every one can be fixed after go-live at exactly the same cost as before it.
- Meta descriptions. They don't affect ranking and Google rewrites them constantly anyway. Write them in week two.
- Alt text on decorative images. Do it for accessibility, which is the better reason. It isn't a launch blocker.
- Schema beyond the basics. Get
OrganizationandBreadcrumbListin if they're cheap;FAQPage,Productand the rest can follow. - Image compression below the fold, and most Core Web Vitals work. Fix the largest contentful element on your two most important templates and leave the rest for a proper pass.
- Blog taxonomy, category structure and tag pages. These almost always get rebuilt once you have real data on what people actually search for.
- Hreflang, if you only publish in one language. Adding it wrongly is considerably worse than not having it.