Key takeaways:
A website relaunch SEO checklist exists to protect link equity you already built. A brand-new site skips this problem entirely because there's nothing yet to lose.
Broken redirect maps, on-page elements that didn't survive the move to new templates, and a staging no-index tag someone forgot about, these three cause most relaunch disasters.
Core Web Vitals (LCP under 2.5s, INP under 200ms, CLS under 0.1) work as a hard pass/fail line inside Google's page experience signals.
The first 72 hours after go-live decide most of what happens next. Redirect gaps and index coverage errors need same-day fixes, not a spot on next week's sprint board.
Baseline everything before touching code. URLs, titles, H1s, schema, backlinks, CWV field data, you cannot defend a number you never wrote down.
Nobody's relaunch is really a fresh start. It's a handoff, moving years of ranking signal from one codebase to another with almost zero room to get it wrong. Most SEO managers already know the theory cold going into a redesign. What actually sinks these projects is one small thing nobody flagged in time: a category URL pattern that never made it into the map, a robots.txt line lifted straight from staging, or an INP regression sitting inside a new hero component that the dev team swears is "snappy enough." This is for whoever answers for it when traffic falls off on day three. Think of it as doubling for a website redesign SEO checklist too, since the pre-flight work is identical either way.
Why Relaunches Kill Rankings?
A relaunch fails when the new site can't cleanly pick up where the old one's authority left off. Google has to re-crawl thousands of pages, chase down every redirect, re-render templates, and reassess relevance from the ground up. Miss one link in that chain and rankings slide, sometimes within hours.
Three symptoms show up almost every time in the first month. URLs that vanish and start throwing 404s. Redirect chains that leak PageRank across three or four unnecessary hops. Index coverage errors piling up in Search Console as it tries to recrawl a site that no longer resembles what it remembers. A first-time launch never hits any of this; there's simply nothing built up to lose. A relaunch drags that history along for the ride, and it cuts both ways: your biggest advantage and your biggest exposure at once.
Core Web Vitals: a threshold, not a tiebreaker
Google folds Core Web Vitals into its page experience signals, and per Google Search Central, "good" currently means LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, all at the 75th percentile. The web.dev CWV guidance is where that pass line actually gets drawn. Drop below "good" on a template that used to clear it fine, and the visibility hit tends to land before you've even worked out what broke.
The 72-hour window
Sites that close redirect gaps and coverage errors inside three days of launch recover measurably faster than sites treating the same errors as a two-week backlog item. Crawlers hit hardest right after a change ships. Catch the problem in that window and it never makes it into the index at all.
Phase 1: Pre-Relaunch Baseline Audit
You cannot protect a number you never measured. Two or three weeks out, crawl the live site fully, Screaming Frog, Sitebulb, whatever your team already trusts, and pull every indexable URL, status code, and canonical. Export it somewhere permanent. Version it.
From there, pull your top 20% of pages by organic traffic and backlinks out of Search Console and analytics. These URLs cannot break, full stop. Write down the ranking-relevant elements for each one: title, H1, meta description, body copy, schema, alt text, internal links, and leave room to check off each item against the new URL post-launch. Do the same for Core Web Vitals using current field data as your number to beat. A product page loading at 2.1 seconds LCP today needs to hit that mark or better on the new site, not just come close.
Phase 2: URL Architecture and the 301 Redirect Map
Every URL that's moving needs a 301 pointed at its replacement, finalized before the dev build locks, not stitched together the night before launch. Google's own site moves documentation doesn't leave much wiggle room here: permanent redirects, one hop, kept live for at least a year.
Teams usually map the obvious top-level pages fine and lose the long tail entirely. Cover:
Category and subcategory URLs
Blog pagination in both flavors?page=2 query strings and /page/2/ path segments
Faceted filters and parameter URLs that were quietly pulling in real search traffic
Old campaign landing pages, even ones with no internal links to anymore
Legacy image and PDF URLs that picked up backlinks over the years
Run the finished map through a crawler on staging. Chains, loops, any old URL landing on a soft 404 or dumped onto the homepage, catch it now. Sending everything to the homepage might look like a fast fix, but it's exactly the kind of shortcut Google warns against, because it torches equity rather than transferring it.
Back up the old codebase and database before you touch production. If something collapses in the first 72 hours and nobody can pinpoint why yet, a rollback plan turns a bad week into something survivable instead of a lost quarter.
Phase 3: On-Page SEO Preservation on Staging
"Cleaner, more modern, less clutter" is basically every redesign brief ever written. What that quietly means in practice: 800 words of ranking content shrinking to 300 because the new template only fits a hero and three feature blocks. Catch that before it ships.
Every ranking-relevant element needs to survive the move intact, titles, H1s, meta descriptions, body copy, schema, alt text. If the design genuinely can't hold what's there, that's a conversation to have before the build starts, not a surprise after launch. Confirm staging is properly blocked with noindex and robots.txt, then set a reminder for go-live day specifically to check that block came off. A staging noindex accidentally left on production might be the single most common way a relaunch turns into a disaster, and it's invisible right up until the traffic graph falls off a cliff.
Check canonical tags, hreflang where multi-language applies, and internal link structure in the new templates against your baseline. Run everything through Google's Rich Results Test and clear the warnings too, not just what it flags as hard errors.
Phase 4: Technical SEO and Core Web Vitals on Staging
Test Lighthouse and PageSpeed Insights against every key template, not just the homepage, and compare each one to your pre-launch numbers.
Metric | "Good" threshold | Where to measure |
LCP | Under 2.5s | Field data (GSC) + lab (Lighthouse) |
INP | Under 200ms | Field data (GSC) |
CLS | Under 0.1 | Field data + lab |
TTFB* | Under 800ms | Lab tools, server logs |
*A quick caveat: TTFB is a solid diagnostic number, but Google doesn't count it among its three official Core Web Vitals. It earns a place here as an early warning sign, not as an official ranking threshold.
Check crawl budget risk on the new stack specifically. Faceted filters missing noindex, duplicate parameter pages from a new tracking layer, content hubs over-tagged during migration, sort these out before launch rather than after Search Console dumps 40,000 duplicate URLs on your desk. Make sure the XML sitemap only contains the new URL set. No old URLs. No noindexed pages that slipped through. No staging domains.
WCAG 2.2 AA is the accessibility bar if that's part of the redesign scope. It won't move rankings directly, but clean semantic HTML tends to come with it, and crawlers notice that either way.
Go-Live Day Checklist
Go-live isn't a two-hour meeting, whatever the calendar says. Block out the full day with SEO and dev both on standby, and settle rollback triggers ahead of time, a homepage 404, a site-wide noindex, or a broken sitemap means revert immediately and debug afterward.
Deploy, pull the staging noindex or "discourage search engines" setting, then confirm it's actually gone with a URL Inspection fetch.
Flip on the full redirect map and spot-check 10% of it live with a bulk redirect checker.
Submit the new sitemap in GSC and request indexing on the top 20 URLs directly.
Verify robots.txt is genuinely the production file, not a stray staging copy.
Write down the exact go-live timestamp somewhere. You'll want it in a week to line up crawl, coverage, and Performance shifts.
Publish the on-call rota so it's clear who owns what if something starts moving the wrong way.
Post-Launch Monitoring: Days 1 to 30
Go-live is the start, not the finish line.
Days 1 to 7. Check Search Console daily. Watch Coverage for 404 spikes or "discovered, not indexed" surges, and Crawl Stats for anything odd. Fix redirect gaps in hours here, not days. Any top-20% URL that starts 404ing is a P0, no exceptions. Keep half an eye on AI answer engines too, ChatGPT, Google's AI Overviews, since they pull from a lot of the same crawled content Search Console reports on, and a relaunch can quietly cost you AI-citation visibility at the same moment it's costing you classic rankings.
Days 7 to 14. Compare CWV field data against baseline. It runs on a 28-day rolling window, so early readings are noisy, but a clear regression on a key template shouldn't wait; send it to engineering now. Break the Performance report down by page group rather than just eyeballing the site total. A category page tanking while the homepage stays flat means the problem lives in that template specifically, and needs a fix scoped the same way.
Days 14 to 30. Track your top 50 keywords with whatever rank tracker your team runs already. Some dip is normal while Google recrawls and reweights the new URLs. A steep or sustained one is different; that's your signal to dig into the redirect map, the on-page baseline, and template-level CWV together as one investigation. If it's still stuck after that, sometimes the fastest path is bringing in outside eyes rather than burning another sprint on it, our IT consulting vs. in-house IT guide covers how to think through that call.
Run a full crawl again around day 21. Look for orphan pages the new CMS created on its own, internal links still pointing at the old URL structure buried in body copy, and any duplicate-content patterns coming out of tag pages or filtered listings nobody meant to introduce.
Planning a relaunch and want a second opinion on the redirect map before you flip the switch? Book a discovery call, and we'll go through the baseline audit with you and flag whatever's most likely to cost rankings in that first week.
Related service: Technical SEO Consulting
Frequently Asked Questions
How long does it take to recover rankings after a website relaunch?
Mid-competition sites that handle redirect gaps and coverage errors inside 72 hours generally settle within four to eight weeks, depending on how much the URL structure changed and how much authority the site had going in. A large domain with millions of URLs can take a full quarter to fully resettle. Miss the 72-hour window and recovery usually drags out longer simply because crawlers already logged the damage.
Should I launch a new sitemap or update the existing one?
Keep the existing sitemap URL where possible so Google doesn't lose its crawl reference point. Swap in the new URL set only, no old URLs, no noindexed pages, no staging paths, and resubmit through GSC. Changing the sitemap URL itself risks signaling a full site move when really only the internal structure changed.
How many redirect hops is too many?
One. A 301 goes straight from old URL to final destination, nothing in between.
Do I need to keep the old redirects forever?
Google says at least a year, longer if the old URLs still pull traffic or backlinks. Pull them too early and any external link still pointing there breaks, which quietly undoes the equity transfer you worked to protect.
Is a staging noindex really that dangerous?
Yes. A noindex tag or X-Robots-Tag header left running in production can deindex the whole domain within days. It's arguably the single worst relaunch mistake, and also one of the simplest to catch, run a curl request against the live URL right after deployment, then again 24 hours later just to be sure.
Where should I get outside help on a relaunch?
A second set of eyes on the redirect map and baseline audit tends to pay for itself past 10,000 URLs. When a team's already stretched, a scoped technical review before go-live tends to catch things internal teams miss simply from staring at the same spreadsheet for six weeks straight.