Service · Site migration SEO
Site migration SEO that protects the traffic you already have
A site migration is any change to a site significant enough that search engines have to relearn it: a new platform, a new domain, a new URL structure, or several sites merged into one. Done carelessly it can drop a large share of organic traffic overnight. Handled in phases, with real pre-launch QA, it usually holds. This service is built around those phases.
The shape of a migration
Three phases, three very different risks
Migrations fail at predictable points. The work changes completely depending on where you are in the timeline, which is why a flat checklist misses so much.
| Phase | Main risk | What we do |
|---|---|---|
| Pre-launch | Wrong URL decisions and untested redirects baked into the build | Redirect mapping, staging crawl, indexability and render QA, sitemap prep |
| Launch day | Redirect errors, 404 spikes, accidental noindex, robots.txt blocking everything | Live monitoring, redirect verification, sitemap submission, rollback checklist |
| Post-launch | Slow recrawl, ranking drift, chains forming, orphaned old URLs | Log monitoring, index coverage tracking, redirect chain cleanup, verification report |
Scroll table horizontally →
Pre-launch
This is where migrations are won. We take a full crawl of the current site while it still exists, because once it is gone the old URL set is hard to reconstruct. That crawl becomes the source for the redirect map.
The redirect map is a spreadsheet with one row per old URL: the old path, the new path it should point to, the status code, and a note on any URL that has no clean equivalent. We map to the single best destination, never to a generic category or the homepage, because bulk redirects to the home page are treated as soft 404s.
On staging we confirm the new site is crawlable, that canonicals and meta robots are correct, that primary content renders in the initial HTML, and that the XML sitemaps are ready. This is the QA pass that prevents most launch-day disasters.
Redirect rule, kept simple
# Good: one hop to the final URL
/old-category/blue-widgets -> /widgets/blue [301]
# Bad: a chain Google has to follow
/old-category/blue-widgets -> /category/blue [301]
/category/blue -> /widgets/blue [301]Every extra hop wastes crawl, slows users, and risks a link in the chain breaking later. We collapse everything to a single hop before launch.
Launch day
Launch day is monitoring, not building. The build should already be tested. We watch the redirects fire correctly against the map, check that robots.txt did not ship in its staging state blocking the whole site, and confirm no noindex tag survived from the staging environment. Those two mistakes alone cause a large share of migration losses.
We submit the new XML sitemaps, keep the old sitemaps available briefly so Google rediscovers the redirects, and use the URL Inspection tool to spot check high-value pages. If something is badly wrong, we have a rollback checklist agreed in advance so the decision is fast rather than panicked.
Launch-day checks
- Redirects resolve in a single hop to the mapped URL
- robots.txt allows crawl and points to the sitemap
- No stray noindex or canonical pointing at staging
- New XML sitemaps submitted, old ones kept temporarily
- High-value URLs inspected and rendering correctly
- Analytics and Search Console still receiving data
Post-launch
After launch the job is watching and cleaning. We track index coverage in Search Console as Google reprocesses the new URLs, monitor the logs for 404 spikes and for pages Googlebot cannot reach, and catch redirect chains forming as the team ships follow-up changes. Rankings often wobble for a few weeks; the question is whether they recover to baseline, and we watch that against the pre-launch numbers.
You get a verification report at the end: what was migrated, what broke and was fixed, and where index coverage and traffic landed against the baseline we captured before launch. If you want the underlying method, our site migration SEO checklist lays out the phase-by-phase steps, and our guide to auditing redirect chains at scale covers the cleanup work that keeps a migration healthy afterwards.
FAQ
Migration questions, answered
When should we bring you into a migration?
As early as possible, and before the URL structure is finalised. The cheapest migration problems to fix are the ones caught on staging. The most expensive are the ones found in the logs a week after launch. If you are already mid-project, we can still join, but earlier is always better.
What kinds of migration do you handle?
Replatforms, for example WordPress to headless or a custom build to Shopify Plus, domain changes, HTTP to HTTPS clean-ups left half-done, URL structure changes, site consolidations where several sites merge into one, and internationalisation projects that add hreflang and regional URLs.
How do you prevent traffic loss on launch day?
A verified redirect map from every old URL to its single best new equivalent, staging QA that confirms indexability and rendering before launch, and a launch-day monitoring plan that watches for redirect errors, 404 spikes, and accidental noindex tags. Most launch-day losses come from a small number of preventable mistakes.
Our migration already went wrong. Can you help?
Yes, and this is a common reason people call. We crawl the old and new URL sets, find broken and chained redirects, check for lost canonicals and noindex tags shipped by accident, and sequence the recovery by traffic impact. Recovery is usually possible and it is faster the sooner we look.
How long before traffic recovers after a migration?
A clean migration should hold most of its traffic through launch, with normal fluctuation for a few weeks as Google recrawls and reprocesses signals on the new URLs. A migration that shipped with errors takes longer, and the timeline depends on how quickly the errors are fixed and how large the site is.
Related reading
A migration touches crawl, rendering, and indexation at once, which is why it sits at the centre of what a tech SEO agency exists to handle. Bring us in before the URLs are locked.
Start here
Migrating soon, or already lost traffic to one?
Tell us where you are in the timeline. If it has not launched we will help you protect it. If it has, we will help you get it back.