Benchmarked in Advance
Rankings, indexed URLs and traffic captured before anything moves, so the comparison afterwards is real.
SEO Migration Services
SEO Migration Services That Protect What Already Ranks
Most traffic lost in a redesign is lost on the day it launches, to causes that were all preventable. A URL changed without a redirect. A staging noindex left in place. Navigation rebuilt in JavaScript. SEO migration services work the problem before the launch rather than diagnosing it afterwards — full inventory, mapped redirects, benchmarks recorded, and a rollout that can be checked rather than hoped about.
We Benchmark Before, Not After
Without a record of what ranked before launch, nobody can say what a migration cost. That record has to exist first.
Every URL Mapped
The full inventory, not the pages someone remembered. Old URLs with links attached are the ones that hurt when missed.
Redirects Tested First
The map is verified on staging. A redirect chain found after launch has already cost something.
The Usual Suspects Checked
Staging noindex, robots.txt, canonicals and analytics — the four things that most often ship wrong.
Watched Afterwards
Index coverage and rankings monitored for weeks, because problems surface as pages are re-crawled.
What gets verified before, during and after a migration
A migration is the single most reliable way to lose visibility that took years to build, and almost every loss is preventable. These checks exist because each one corresponds to a way migrations have gone wrong.
Pre-migration URL inventoryEvery existing URL captured before the old site stops existing
Traffic and link mappingWhich URLs earn organic visits and which carry external links
Redirect map completenessEvery old URL mapped to its closest genuine equivalent
One-hop redirectsNo chains — each old URL resolves in a single step
Status code correctness301 for permanent moves; 302 only where the move is genuinely temporary
Canonical alignmentNew canonicals point at new URLs, not at the retired ones
Template parityTitles, headings and copy carried across rather than regenerated
Internal link rewritingSite links point at new URLs directly, not through redirects
Sitemap replacementNew sitemap submitted; old URLs removed once redirects are live
Robots and staging directivesNo `noindex` or staging disallow surviving the launch
Structured data continuitySchema present on the new templates, not lost in the rebuild
Post-launch crawlFull crawl within days, comparing against the pre-migration inventory
The pre-migration inventory is the one item that cannot be recovered later. Once the old site is gone there is nothing left to crawl, and the redirect map has to be reconstructed from archives and logs — which is always incomplete. If only one thing is done before a rebuild, it is this.
SEO Migration, Explained
Why Do Redesigns Lose Traffic?
Almost never the design. Three technical causes account for most of it.
Get a Free Migration Review →- 1
URLs Changed Silently
A new CMS producing different paths, with no redirects. Every ranking on those URLs starts again from nothing.
- 2
The Staging Block Ships
A noindex or a robots.txt disallow that protected the staging site goes live with it. The site disappears within days.
- 3
Content Quietly Dropped
Pages that ranked did not make it into the new build, usually because nobody counted them.
What a Migration Engagement Covers
Most of the work happens before launch. That is the point.
The build and cutover side is website migration; platform-specific cases are covered by Shopify migration and WordPress migration.
Any Change That Moves a URL
The trigger is not the redesign. It is whether addresses change.
Website Redesigns
Where the CMS or the structure changes even if the content does not.
Replatforming
Moving between platforms, each with its own URL conventions.
Domain Changes
Rebrands and consolidations, the highest-risk category.
Structural Changes
Reorganising a large site, which is a migration whether or not it is called one.
From Inventory to a Launch That Holds
Three of the four stages happen before the new site is visible to anyone.
- Step 1
Inventory and Benchmark
Every URL, and a record of what currently ranks.
Tasks Involved- Full crawl
- Search Console export
- Ranking benchmark
- Backlink inventory
- Step 2
Map and Test
Redirects written and verified on staging.
Tasks Involved- Redirect map
- Chain testing
- Staging crawl
- Parity check
- Step 3
Launch
The checks that matter in the first hours.
Tasks Involved- Robots and noindex
- Redirect verification
- Sitemap submission
- Analytics check
- Step 4
Monitor
Weeks of index coverage and ranking comparison against the benchmark.
Tasks Involved- Index monitoring
- Ranking comparison
- Error fixes
- Reporting
What kind of migration this is
The word covers several different projects with different risks. Which one applies determines what has to be protected and what can safely change.
Platform changes with URLs preserved
The lowest-risk case and still not risk-free. Addresses stay the same while templates, markup and rendering all change, so the exposure is in structured data, headings, internal linking and whether content is present without JavaScript.
Redesigns that change URL structure
Where the redirect map is the entire project. Every old address needs a genuine equivalent, and mapping large sections to a category page or the homepage is treated as a soft 404 rather than a redirect.
Domain changes and rebrands
The highest-risk migration, because branded search demand, external links and directory citations all point somewhere that is about to stop existing. This should be sequenced alongside the naming work rather than discovered after it.
Consolidating several sites into one
Where two or more properties merge and overlapping content has to be resolved. The decision about which page survives each collision is a content decision with lasting consequences, and it should be made deliberately rather than by whoever migrates last.
HTTP to HTTPS and hostname normalisation
Mechanically simple and easy to leave half-finished — mixed content, canonicals still on the old scheme, or both hostnames resolving. Worth verifying rather than assuming, since the symptoms are quiet.
Migrations, Explained
Preventable Losses, and How They Happen
Almost every migration loss traces to a small number of omissions, all of which are cheaper to prevent than to recover from.
The inventory has to exist before the old site does not
A site that has earned visibility carries it in specific URLs: the pages that rank, the pages other sites link to, the pages that receive organic visits. That value is attached to addresses, and a rebuild that changes addresses without mapping them discards it.
The inventory is a crawl of the existing site joined to whatever performance data is available, producing one list: every URL, whether it earns organic traffic, and whether anything external links to it. That list becomes the redirect map and, later, the checklist that proves nothing was lost.
Reconstructing it afterwards is possible and always incomplete. Archived copies miss pages, log files cover a limited window, and external link data depends on tools that may not be authorised. Some proportion of the previous equity simply cannot be recovered, which is why this step is worth insisting on before development starts.
Redirects fail in specific, repeated ways
Chains are the most common: old URL redirects to an interim URL which redirects again. Each hop adds latency and risks the chain being truncated, and they accumulate silently when a site is migrated more than once. Every old address should reach its destination in one step.
The second is redirecting too broadly. Mapping a retired section to the homepage looks tidy and is treated as a soft 404, because the destination does not answer what the original page answered. A redirect is a statement that the content moved here; where nothing equivalent exists, a 410 is more honest than a redirect to something unrelated.
The third is leaving internal links pointing at old URLs. The redirects work, so nothing appears broken, and every internal link now costs an extra hop. Rewriting internal links to the new addresses is part of the migration rather than a later tidy-up.
What to watch after launch
A full crawl within the first days, compared against the pre-migration inventory, answers the only question that matters: is every old URL resolving to something appropriate, and is every new URL reachable, indexable and canonicalised correctly.
Server logs, where available, show what crawlers are actually requesting — frequently still the old URLs for some time, which is expected. What is not expected is crawlers hitting errors, or spending their requests on parameter URLs the new platform started generating.
Some fluctuation after a migration is normal and recovery is not instant, because search engines have to recrawl and reprocess a large number of URLs. What distinguishes normal fluctuation from a genuine problem is whether the technical checks pass. If redirects are correct, canonicals are right and content is present, the usual answer is to wait rather than to start changing things.
Where migration sits in the wider programme
A migration is a preservation exercise rather than an improvement one. Done well, the site ends up roughly where it started, having changed platform or structure without paying for it. That is the realistic goal, and treating it as an opportunity to also improve rankings usually means doing two things badly at once.
Improvements belong either side of it. A technical SEO pass before the move identifies problems worth fixing in the new build rather than carrying across. Content and authority work resume afterwards, once the new structure is stable and measurable.
This is also why migration planning is normally the first thing raised when a rebuild is proposed anywhere in the SEO programme. Development timelines are set early, and the pre-migration inventory has to happen before the old site is switched off — which is a date somebody else usually controls.
Questions, answered.
An SEO migration is the work of moving a site — redesign, replatform or domain change — without losing the rankings and traffic it already had. It is mostly URL mapping, redirect implementation and verification.
Some short-term movement is normal while pages are re-crawled and re-evaluated. Lasting loss is not normal, and is usually traceable to a specific mistake: a missing redirect, a blocked crawl, or content that did not make it across.
Before the new site is built, ideally. The URL inventory and benchmark have to be taken from the current site, and the structural decisions are much cheaper to influence early than to repair after launch.
They should be collapsed to one hop. Chains dilute the signal passed and slow crawling, and they accumulate quietly across successive migrations if nobody checks.
It depends on site size and how thoroughly the mapping was done. Search engines need to re-crawl everything before the picture settles, which takes weeks on a large site. Having the benchmark is what lets you tell recovery from decline.
It varies with the size of the site and the extent of the change, and no honest date can be given. Search engines have to recrawl and reprocess every affected URL, which takes longer on large sites. What matters more than the timeline is whether the technical checks pass — if redirects, canonicals and content are correct, waiting is usually the right response to early fluctuation.
You can, and it should be a deliberate decision rather than a byproduct of the new platform. Changing addresses means every old URL needs a genuine equivalent and a one-hop redirect, and some equity is lost even when it is done well. Where the existing structure is sound, keeping URLs is the cheaper and safer choice.
Then they should not be redirected to something unrelated. A redirect asserts that the content moved to the destination, and pointing a retired page at the homepage is treated as a soft 404 anyway. Where nothing equivalent exists, returning a proper removal status is more honest and produces a cleaner result than a redirect that misleads.
Yes, once the new URLs are live and the redirects are in place. Keeping the old sitemap available briefly can help search engines find the retired URLs and follow their redirects, but it should be replaced rather than left indefinitely. Sitemap submission requires Search Console — REQUIRES GSC ACCESS.
It depends on the size of the site and how much can be verified at once. A phased move reduces the blast radius of any single mistake and extends the period in which two structures coexist, which brings its own complexity. What matters more than the choice is that each phase has a complete redirect map and a post-launch crawl before the next one begins.
Still deciding if seo migration services is right for you?
Talk to UsFree Migration Review
Find Out What a Move Would Put at Risk
Tell us what is changing. We will inventory what currently ranks, show you which URLs carry the most, and what has to be mapped before launch.
Claim Your Free Marketing Audit
Enhance Your Brand Potential At No Cost!
- Expect a response within 24 hours
- NDA available upon request
- Dedicated product specialists