SEO Launch Checklist for New Websites (Agency Edition)

Most SEO damage on a new site happens in the 48 hours around launch, not months later. A staging noindex tag that never gets removed. A redirect map that covers 80% of old URLs and quietly drops the rest. A sitemap that still points at the staging domain. None of these show up in a design review. All of them show up in Search Console three weeks later as a traffic graph that falls off a cliff — and by then it's a lot more expensive to fix than it would have been to check before go-live.

This is the checklist we run on every client launch, in order, with the reasoning for each item so it's not just a list to tick blindly.

Why launches are the highest-risk moment for SEO

A site that's ranked for years can absorb a bad week. A brand-new site, or a redesign replacing an indexed one, cannot — there's no accumulated trust to fall back on while you fix a mistake. Three failure patterns account for most of the damage we see:

1. Staging leaks into production behavior. A noindex meta tag, a password gate, or a Disallow: / in robots.txt that was correct on staging ships to production unchanged.
2. Migrations lose URLs. Old pages return 404 instead of 301-redirecting to their new equivalent, and the site loses years of accumulated link equity and rankings in one deploy.
3. Nobody owns verification. The developer assumes marketing checked the redirects; marketing assumes the developer did. Neither did.

The checklist below exists to remove the ambiguity — every item has an owner and a way to verify it's actually done, not just assumed.

Before launch: technical basics

Production URL and canonical host. Confirm the final domain and whether it's www or non-www, https (always). Pick one canonical version and make sure every internal link, the sitemap, and the canonical tag all agree — mixed signals here split ranking signals between two URLs that both technically work.

XML sitemap. Generate it from the live content, not a static file someone edited once. It should contain only indexable, 200-status URLs — no redirects, no noindex pages, no 404s. A sitemap full of noise is worse than no sitemap; it teaches Google not to trust it.

robots.txt. Explicitly allow crawling of content paths. Block admin, API, and any staging-only paths that might still be reachable. Check this file after deploy — a Disallow: / copied from staging config is the single most common launch-day mistake we see, and it's invisible until you check Search Console and wonder why nothing is indexing.

Redirect map. If this is a migration or redesign, every old URL that had any organic traffic or backlinks needs a 301 to its closest new equivalent — not a blanket redirect to the homepage, which passes almost no value and creates a poor user experience. Pull the old URL list from Search Console (Performance report, last 16 months) and analytics, not just a sitemap crawl, since some valuable old pages may no longer be linked internally.

Status codes. Crawl the full site pre-launch (Screaming Frog or similar) and confirm every intended page returns 200. Fix or intentionally redirect anything returning 4xx or 5xx before go-live, not after.

Mobile and Core Web Vitals. Run PageSpeed Insights on the homepage and one or two representative templates. You don't need a perfect score at launch, but LCP over 4 seconds or a broken mobile layout are the kind of thing that's much cheaper to fix in staging than in a post-launch fire drill.

Metadata and indexing

Titles and descriptions. Every page that matters has a unique title and meta description — no template leaking "Untitled" or a default placeholder into production. Titles under ~60 characters, descriptions under ~155, both written for the human reading the search result, not stuffed with keywords.

Structured data. Add JSON-LD where it's genuinely applicable — Organization and WebSite sitewide, Article on blog posts, FAQPage where there's real FAQ content, Product where relevant. Validate every type with Google's Rich Results Test before launch; broken structured data is worse than none, since Search Console will start flagging errors against pages that otherwise look fine.

Noindex the right things, and only those things. Thank-you pages, internal search results, filtered/faceted URLs that create near-duplicate content, and any staging or preview URLs that are still reachable should carry noindex. Don't noindex anything else — we've seen sites accidentally noindex their own blog category pages because a template default was too aggressive.

Search Console and analytics

Verify ownership in Google Search Console (and Bing Webmaster Tools if the client cares about Bing traffic — often worth doing, it takes five minutes). Submit the sitemap directly in Search Console rather than relying on robots.txt discovery alone; it gets picked up faster.

Install and verify analytics before launch, not after — you cannot go back and measure launch-day traffic if the tag goes live a week late. If there's conversion tracking (form submits, calls, purchases), test each event manually before the client's first report is due.

Keep staging out of the index. This deserves its own line because it's the mistake that's hardest to reverse: if a staging domain gets indexed and later reused for a different project, or if a client's old staging subdomain has been silently accumulating indexed pages for years, cleaning it up is its own project. Password-protect or noindex staging environments from day one, permanently, not just around launch.

Post-launch: the first two weeks matter most

Monitor Search Console daily for the first week. Watch Coverage for a spike in "Excluded" or "Error" pages — that's usually a redirect or noindex problem, not a Google problem. Watch Core Web Vitals under Experience once enough field data accumulates (this takes about 28 days to populate meaningfully).

Re-check Core Web Vitals with real traffic. Lab data from before launch (Lighthouse on a good connection) is optimistic. Field data (CrUX, which populates in Search Console after enough traffic) reflects what actual visitors experience, including on real networks and real devices — and it's what affects rankings, not the lab score.

Confirm the sitemap matches reality. Spot-check that key landing pages and the blog archive are live and match what's declared in the sitemap. A sitemap that references pages that 404, or omits pages that exist, undermines trust in every future crawl.

Document known limitations. If paginated archives are intentionally noindexed, if certain filter combinations are blocked, write it down somewhere the client and future developers can find it. Six months later, "why is this page noindexed" should have an answer on file, not require someone to reverse-engineer the decision.

Launch checklist, condensed

The one thing that saves the most pain

If we had to cut this list to a single item: build the redirect map from Search Console's actual indexed URL list, not from a sitemap crawl of the old site. Sitemaps only show what the previous developer remembered to include. Search Console shows what Google actually has indexed and sending traffic to — including old campaign landing pages, orphaned blog posts, and URLs nobody remembers exist. Missing those is how a "clean" migration quietly loses 15–20% of organic traffic that nobody notices until the monthly report.

We run this exact checklist on every launch we ship, whether it's a new build or a replatform — it's part of the launch phase on every project, not an optional add-on. If you're planning a launch or migration and want a second set of eyes on the technical SEO before you go live, get in touch — a pre-launch review takes a day, and it's a lot cheaper than a redirect cleanup project three months in.