A website migration is any change that alters the URLs search engines have already indexed: a replatform, a domain change, a redesign that restructures navigation, an HTTPS or subdomain move, or a content consolidation. SEO migration work exists to carry ranking signals across that change instead of resetting them.
Most migration losses are not caused by the new site being worse. They are caused by signals failing to transfer, usually through incomplete redirect mapping, URLs that were never inventoried, or changes that shipped without a pre-launch check.
This page covers what a migration engagement involves, at which point it should start, what gets produced, and how to tell whether a migration has actually succeeded.
Migrations that need SEO involvement
Not every site change is a migration in the SEO sense. The test is whether indexed URLs, their content, or their internal relationships change.
- Replatforming, for example WordPress to Shopify, Magento to WooCommerce, or a custom build.
- Domain changes, including rebrands and moving between country domains.
- Redesigns that alter URL structure, navigation or template logic, even on the same platform.
- Consolidating several sites into one, or splitting one into several.
- Moving to HTTPS, changing www conventions, or restructuring subdomains and subfolders.
- Large-scale content pruning or merging that removes or redirects indexed pages.
A visual redesign that leaves URLs, copy and internal links untouched carries far less risk. Where any of the above applies, treat it as a migration.
When to bring SEO in
The single biggest determinant of migration outcome is timing. Involvement during planning, while URL structure is still negotiable, is worth more than any amount of remediation afterwards.
- Best: during planning, before the new URL structure is finalised. Structural decisions can still be influenced.
- Workable: during build, while staging exists and redirects can be tested before launch.
- Expensive: after launch. The work becomes recovery, and some signals may already have decayed.
If a migration has already gone live and traffic has fallen, that is recovery work rather than migration planning, and the diagnostic sequence is different.
What the work involves
Pre-launch inventory
Everything begins with a complete picture of what exists today. Migrations fail on the URLs nobody remembered.
- A full crawl of the current site, reconciled against XML sitemaps.
- Indexed URLs from Search Console, which routinely include pages absent from any crawl.
- Analytics landing pages over at least twelve months, to catch seasonal entry points.
- Backlink data, so externally linked URLs are prioritised in mapping.
- A ranking and traffic baseline stored before anything changes.
Redirect mapping
Every old URL needs a decision, not just the ones that are easy to match. Redirect mapping is the deliverable that determines most of the outcome.
- One-to-one mapping to the closest equivalent, using 301 redirects.
- Explicit decisions for pages with no equivalent: redirect to the nearest relevant parent, or return 410 deliberately.
- No redirect chains or loops, and no hops through intermediate URLs.
- Redirects applied at server level rather than through client-side JavaScript.
- Parameterised, paginated and filtered URLs handled as named cases rather than left to a catch-all.
Avoid the common shortcut of redirecting everything unmatched to the homepage. It is treated as a soft 404 and discards the signal you were trying to preserve.
Staging validation
Staging is the last point at which problems are cheap. It should be crawled as though it were production, with access restricted by authentication rather than by robots directives that risk being carried live.
- Crawl staging and compare templates, titles, headings and canonical tags against the current site.
- Confirm no blanket noindex or Disallow rule is present in the launch build.
- Test the redirect map against a sample of every URL pattern, not just the top pages.
- Verify structured data, hreflang and pagination survive the template rewrite.
- Check rendering if the new build depends on client-side JavaScript.
Launch and the days after
The launch window is a monitoring exercise. Problems found within hours are usually trivial to fix; the same problems found in week three are not.
- Re-crawl production immediately and compare against the staging baseline.
- Submit updated sitemaps and confirm the old ones are retired rather than deleted abruptly.
- Watch server logs and error rates for crawl failures.
- Monitor index coverage daily at first, then weekly.
- Keep the change log current, so any later movement can be attributed.
What you should receive
A migration engagement should leave you with artefacts your developers can act on, not a narrative report.
- A complete URL inventory with the source of each URL recorded.
- A redirect map in a format that can be implemented directly.
- A pre-launch checklist with pass or fail against each item.
- A prioritised issue list from the staging crawl, separating blockers from improvements.
- A stored baseline plus an agreed monitoring window and review points.
Where migrations usually go wrong
- The redirect map covers only pages someone remembered, so long-tail URLs 404 silently.
- A staging noindex or robots Disallow ships to production.
- Redirects are chained through several hops, diluting and slowing the transfer.
- Content is quietly shortened during the rebuild, so pages lose the depth that earned rankings.
- Internal links still point at old URLs, forcing every internal path through a redirect.
- Tracking changes at the same time, making the before-and-after comparison unreadable.
- The migration is judged after one week, before recrawling has meaningfully progressed.
Judging whether it worked
Expect a dip. A short, shallow decline that recovers over several weeks is normal. What matters is depth, duration and direction.
- First days: crawl activity on new URLs, redirects resolving in one hop, no spike in errors.
- First weeks: new URLs replacing old ones in the index, impressions stabilising.
- Following months: rankings and organic sessions returning toward the stored baseline.
A decline that is still deepening after the new URLs have demonstrably been recrawled is a signal to re-open diagnosis rather than to wait longer.
Frequently asked questions
Will we lose rankings during a migration?
A temporary dip is common while search engines recrawl and reassess the new URLs. A well-mapped migration typically recovers over weeks. Permanent loss is usually traceable to a specific fault, most often incomplete redirects, rather than to the migration itself.
How long should redirects stay in place?
Keep them for at least a year, and indefinitely where the old URL still attracts external links or direct traffic. Removing redirects early reintroduces the loss you avoided at launch.
Can we migrate and redesign the content at the same time?
You can, but it costs you diagnostic clarity. If URLs and content both change and something drops, isolating the cause is much harder. Where the timeline allows, migrate the structure first and revise content afterwards.
What if the new platform cannot reproduce our URL structure?
That constraint should surface during planning, not after launch. Where structure genuinely cannot be preserved, the redirect map carries the whole burden and needs proportionally more attention and testing.
Do we need help if our developers are experienced?
Capable development teams handle the build well. The gap is usually the URL inventory and redirect map, which depend on search and analytics data that sits outside the development process. That is normally the part worth bringing in.
How long does a migration engagement take?
It follows your build timeline. Inventory and mapping typically need two to four weeks depending on site size, staging validation runs alongside development, and monitoring continues for several weeks after launch.
Consulting CTA
If you are planning a replatform, redesign or domain change, book an SEO consultation before the URL structure is finalised, and we can work through inventory, redirect mapping and a pre-launch checklist while changes are still inexpensive.
Guides in this section
Planning a migration
- Pre-migration audit — what to record before anything changes.
- Building a redirect map — the artefact that decides whether value carries across.
- Staging site SEO — testing the new build without it being indexed.
- Consultant vs developer — who owns which part of the migration.
By migration type
- Changing domain — the highest-risk move, and the clearest process.
- CMS platform migration — when the platform dictates your URLs.
- Ecommerce migration — why stores fail differently from brochure sites.
- Website redesign — same URLs, lost rankings — and why.
- Hosting migration — moving servers without changing addresses.
- Merging websites — consolidating two sites into one.
After launch
- Post-migration audit — verifying what actually shipped.
- Migration timeline — how long recovery normally takes.
- Old URLs still indexed — when the previous site will not go away.
- Search Console change of address — using the tool properly.
- How long redirects should stay — keeping them long after the migration is done.