Website Migration SEO

A migration is survivable when the plan includes going backwards

Changing domain, platform, protocol or URL structure is the one piece of search work where the downside is bigger than the upside. The outcome is decided before launch — by the inventory, the map, the staging checks and whether anybody wrote down how to reverse it.

Book a Strategy Call See how we work

Definitions

More projects are migrations than people realise

A migration is any change that alters the addresses search engines have already learned, or the content those addresses return. Changing domain is the obvious one. So is moving from one platform to another, moving from a subdomain to a subfolder, restructuring the navigation, consolidating two companies onto one site, splitting one site into two, or switching to a new templating system that renames every page.

The reason it matters is that search visibility is attached to URLs, not to businesses. Every signal a page has accumulated — the links pointing at it, the queries it has been shown for, the behaviour of people who landed on it — is held against an address. Change the address without telling anyone, and you are asking search engines to start again.

The good news is that this is one of the few areas of search work with a genuine playbook. The steps are known, the failure modes are known, and almost all of the risk is concentrated in decisions made before anything goes live.

Before anything moves

The inventory nobody enjoys building

A redirect map is only as complete as the list of addresses it was built from, and a single crawl of the live site is never that list.

A full crawl of the current site, including pages that are linked from nowhere but still receive visits
Every XML sitemap, including the stale ones nobody has regenerated in two years
Server logs, which reveal the addresses search engines actually request rather than the ones you think exist
Search Console pages by clicks and by impressions, exported before the property changes
Analytics landing pages by session and by revenue, so commercial priority is visible in the map
External links grouped by the page they point at, so nothing valuable is redirected carelessly
Non-HTML addresses: images, PDFs, product feeds, RSS, downloadable assets, API endpoints the front end calls
Parameterised and paginated addresses, and any faceted combinations that were deliberately indexed
Existing redirects, so new rules are appended to the source rather than stacked on top of old hops
robots.txt, canonical tags, hreflang clusters and structured data as they currently stand
The internal link graph, because internal links have to be rewritten to the new addresses rather than left to redirect

How the risk compounds

Every stage can only work on what the last one passed it

A migration narrows as it goes. An address left off the inventory can never be mapped, and a mapping decision cannot be reconsidered once the old environment is gone.

1URL inventory — Every address the site has ever been asked for, gathered from crawls, sitemaps, server logs, Search Console and analytics.
2Redirect map — One legacy address to one destination, decided page by page rather than by a bulk rule pointing at the home page.Cannot map what the inventory never listed
3Staged rollout — The new build crawled the way a search engine would see it: staging block, canonicals, rendering, redirects resolving in one hop.Defects found too late to fix before the date
4Launch day — The runbook — deploy, remove the block, submit sitemaps, register the change of address, hand-check a sample of redirects.Steps with no named owner against them
5First 72 hours — Response codes, chains introduced by caching or edge rules, crawl volume, indexing, and the pages that carry the revenue.The window where the cheap fixes still exist

Timeline

The sequence, counted backwards from launch

Six weeks out — benchmark
Record what normal looks like. Visibility by template, by URL and by query group; crawl statistics; index coverage; conversion rate by landing page. Without this, every argument after launch is opinion.
You get: A dated benchmark you can point at later
Four weeks out — map
Match every legacy address to exactly one destination. Where no equivalent exists, decide deliberately: closest relevant page, parent category, or a genuine 410. Bulk rules to the home page are not a mapping decision.
You get: A one-to-one redirect map, reviewed line by line at the top
Two weeks out — validate on staging
Crawl the staging build as a search engine would. Check that the environment is blocked from indexing, that canonicals point at production addresses, that templates render server-side, and that the redirect rules resolve in one hop.
You get: A staging crawl report with defects assigned to developers
Launch day — run the book
A written runbook with named owners: deploy, remove the staging block, confirm robots.txt, submit the new sitemaps, register the change of address where the domain is moving, and spot-check a sample of redirects by hand.
You get: A completed runbook with times and initials against each step
First 72 hours — watch a short list
Server errors and response codes, redirect chains introduced by caching or edge rules, crawl volume, indexing of the new addresses, and the handful of commercial pages that matter most. This window is where cheap fixes still exist.
You get: Daily exception report for three days
Weeks two to twelve — judge it honestly
Compare against the benchmark rather than against last year. Separate URLs that are recovering from URLs that were never picked up, and hold the rollback decision open for as long as the agreed window says it stays open.
You get: A hold-or-revert recommendation with the evidence behind it

Reading the first month

Telling a normal dip from a real problem

Both look like a fall in a graph. They behave completely differently underneath, and the difference is visible within days if you know what to check.

How expected post-migration settling differs from an actual migration failure
Dimension	Expected settling	Something is genuinely wrong
Shape of the fall	A dip that begins to flatten and lift within a few weeks	A fall that continues, or a cliff edge on the day of launch that does not move at all
Which pages	Spread broadly across templates in rough proportion to the site	Concentrated in one section, one template, or the pages with the most links pointing at them
Indexing	New addresses being discovered and indexed steadily	New addresses not indexed, or old addresses still indexed and serving alongside them
Response codes	Clean single-hop redirects from legacy addresses	Chains, loops, soft 404s or unexpected 302s
Impressions versus clicks	Impressions holding while clicks lag slightly behind	Impressions collapsing, which means the pages are no longer being shown at all
What to do	Nothing dramatic. Keep monitoring and resist the urge to change more variables	Diagnose within days, fix the specific defect, and check the rollback window before it closes

Failure modes

What actually goes wrong, in the order we see it

Everything that moved was redirected to the home page.: It is quick, it clears the error report, and it destroys the specific relevance each page had. A redirect is a statement that this address has become that address. Pointing four hundred product pages at the home page says something no search engine can act on usefully.
The redirects chain.: New rules get added on top of rules from the last two migrations, so a legacy address goes through three or four hops before arriving. Each hop is a place for something to go wrong, and some of them will be dropped. Chains should be flattened to a single hop at the source.
The staging site was indexed.: A staging environment left open, or a production launch that ships with the staging block still in place, are the same mistake at different ends of the process. Both are avoidable with one check, and both are surprisingly common.
Content and addresses changed at the same time.: When the URL structure and the page content both change, no post-launch analysis can attribute a movement to either. Where the schedule allows, move the addresses first and change the content afterwards, so each change can be judged on its own.
Nobody kept the old environment.: Reverting is only possible while the previous build is still deployable and the DNS change is still reversible. Deciding on day nine that you would like to go back, and discovering the environment was decommissioned on day two, is a bad conversation.

Questions

What clients ask before a site move

How long does it take for traffic to settle after a migration?

It varies with the size of the site and how much changed. A small site with a clean one-to-one redirect map often looks normal within a few weeks; a large catalogue with a new URL structure can take considerably longer because everything has to be recrawled and reassessed.

We will not give you a fixed number, because the number would be invented. What we will do is tell you at each checkpoint whether the shape of the recovery looks like settling or like a fault.

The developers are handling redirects. What is left to do?

Redirect implementation is the last step, and it is the easy one. The work before it is deciding what maps to what — which is a content and search judgement, not a deployment task.

The failures we see most often are bulk rules that send whole sections to the home page, chains built by stacking new rules on old ones, and non-HTML URLs such as images, PDFs and feeds that nobody put on the list.

We are keeping our URLs. Do we still need this?

Less of it, but not none. If templates, internal linking, headings or on-page content change substantially, the pages are different even at the same address, and it is worth benchmarking so you can tell what caused any movement.

The parts you can usually skip are the redirect map and the change of address process. The benchmarking, the staging checks and the first-week monitoring still earn their place.

What does a rollback actually mean?

A written, agreed answer to three questions: what evidence would make us revert, who decides, and how long the old environment stays available and deployable.

It is rarely used. Its value is that it turns launch from an irreversible event into a decision you can take back, which changes how calmly everyone behaves in the first week.

Can you join a project that launches in two weeks?

Often, yes, but the scope changes. With two weeks we prioritise the inventory, the redirect map and the benchmark, because those are the things that cannot be reconstructed after launch.

We will tell you plainly if we think the date is the wrong risk to take, and what specifically we would want moved.

Bring us in before the launch date, not after it

Tell us what is moving and when. We will tell you what has to happen before that date, what can safely happen afterwards, and whether the date itself is the thing we would change.

Book a Strategy Call

Where to go next

Last updated September 7, 2026 · Reviewed by Zubair Afzal

Six weeks out — benchmark

Four weeks out — map

Two weeks out — validate on staging

Launch day — run the book

First 72 hours — watch a short list

Weeks two to twelve — judge it honestly