The website migration SEO checklist: keep your rankings through a rebuild

Most of the traffic disasters I get called into started as a website migration. A rebuild, a replatform, a rebrand with a new domain, sometimes just a "quick redesign" that quietly changed every URL on the site. The pattern is always the same. The new site looks better, the launch felt smooth, and six weeks later organic traffic is down forty per cent and nobody can say why.

The frustrating part is that migrations are one of the most controllable risks in SEO. Rankings are lost to a small set of predictable mistakes, and every one of them is checkable in advance. This is the checklist I work through when I run a migration, in the order I work through it.

The phases, and where each one goes wrong

A migration is really five jobs in sequence. It's worth seeing the whole shape before getting into the detail, because the classic failure in each phase is different.

Phase	The job	The classic failure
Benchmark	Record what you have while you still have it	Nobody kept the old URL list, so nobody knows what was lost
Mapping	Decide where every old URL goes	Redirecting everything to the homepage
Staging checks	Test the new site before it's public	Staging blocked from crawlers, so problems surface only at launch
Launch day	Flip the switch and verify	The noindex tag from staging comes along for the ride
Aftercare	Watch the data for a month	Everyone moves on the day after launch

1. Benchmark before you touch anything

You cannot check what you never recorded. Before the build starts in earnest, export a full crawl of the current site, your top pages by organic traffic from GA4 or similar, and your query and page data from Search Console. Keep the lot somewhere safe.

The single most important asset is a complete list of every URL that exists now, including the odd ones. Old campaign pages, PDFs, pages you'd forgotten about that still rank. On most sites I audit, a surprising share of organic entries come from pages nobody has looked at in years.

2. The redirect map is most of the job

Every old URL needs a decision, and "redirect it to the homepage" is not a decision, it's a shrug. Google treats mass redirects to the homepage as soft 404s, which means the equity those pages earned evaporates.

• Map every old URL to its closest equivalent on the new site, one to one wherever possible.
• Where a page genuinely has no successor, let it return a clean 404 rather than a misleading redirect. That's an honest signal and it's fine.
• Use 301s, keep chains to a single hop, and preserve redirects from any previous migration. Legacy redirect rules getting dropped during replatforming is one of the quietest ways equity leaks away.
• Pay particular attention to your money pages and your top organic entry pages from the benchmark. Those mappings deserve individual review, not a spreadsheet formula.

If URLs aren't changing at all, most of this section falls away, and your risk drops enormously. Keeping URL structure stable is the single best migration decision available, and it's worth pushing back on new structures that exist for tidiness rather than any user or business reason.

3. Test on staging like it's the real thing

The new site should be crawled and checked before launch, on a staging environment that behaves like production.

• Crawl staging and compare it against your benchmark crawl. Missing pages, changed titles, and thinned-out content should all surface here, not in six weeks of declining Search Console graphs.
• Check that templates render their content server-side, especially if the rebuild moved to a JavaScript framework. What Google sees should match what users see, a point I cover in more depth in my technical SEO checklist, and one I design for from the start on the websites I build.
• Verify the redirect map actually works by testing a sample of old URLs against the staging rules, including the weird legacy ones.
• Confirm analytics and Search Console verification will survive the switch.

4. Launch day is a checklist, not a celebration

The launch itself is short work if the preparation was done, but the checks need doing within hours, not days.

• Remove the staging noindex and the robots.txt block. Yes, really. Sites launch behind a noindex often enough that this line deserves its place at the top of the launch-day list, and it's the first thing I look for when a freshly migrated site's traffic falls off a cliff.
• Spot-check the redirect map against live URLs, money pages first.
• Submit the new XML sitemap in Search Console, and keep the old sitemap available temporarily so Google can process the redirects faster.
• Crawl the live site the same day and fix anything structural immediately, because problems found on day one are cheap and problems found in week six are not.

5. Aftercare, the part everyone skips

Some ranking movement in the first couple of weeks is normal while Google re-processes the site. A sustained slide is not, and the difference only shows if someone is watching.

• Check Search Console's indexing report weekly for the first month. Rising "not found" errors and unexpected exclusions are your early warning system.
• Compare organic landing page traffic against the benchmark, page by page for your top performers, not just in aggregate.
• Watch Core Web Vitals once real-user data accumulates on the new templates, since replatforms change performance characteristics in both directions.

If something has dropped, the cause is almost always in one of the earlier phases, a missed redirect, a template rendering issue, or content that was quietly cut during the rebuild. This is also the point where a proper audit earns its keep, because it works through those causes systematically instead of guessing.

Website migration SEO FAQs

How long does it take rankings to settle after a migration?

For a well-executed migration with stable URLs, often two to four weeks. With changed URLs and a good redirect map, expect some turbulence for one to three months. A sustained decline beyond that point means something specific is wrong, and it's findable.

Will I always lose some traffic in a migration?

No. A migration done properly, especially one that keeps URLs stable, can hold or even improve traffic (new sites are usually faster and better structured). The expectation of an unavoidable "migration dip" mostly comes from migrations that skipped the steps above.

Should I redesign and migrate platforms at the same time?

Ideally not, because when traffic drops you won't know which change caused it. If the project demands both at once, as many do, keep URLs stable if at all possible. That single constraint removes most of the risk of doing both together.