Changing your website without losing what it had earned
Migration SEO protects search visibility through a site change. The work is almost entirely preparation: mapping every existing URL to its replacement, planning single-hop redirects, and recording a baseline before launch so any loss afterwards can be measured rather than argued about.
The most expensive week in a website's life is the one after a migration goes wrong. Traffic drops, nobody can say by how much because no baseline was recorded, and the diagnosis happens under pressure while the business loses enquiries daily. Almost all of it is preventable by work done weeks earlier, and almost none of that work is glamorous enough to get scheduled.
Migrations fail in a narrow and predictable set of ways. URLs change and old ones return 404, so every link and every accumulated ranking signal pointing at them is discarded. Redirects are added but chain through two or three hops. The new site blocks crawling because a staging robots.txt shipped to production. Content is trimmed during the rebuild and pages that ranked lose the substance they ranked for. And nobody recorded what traffic looked like beforehand, so the argument about whether it dropped becomes unresolvable.
When this work makes sense
Questions worth asking any supplier
Is there a URL map? Every old address needs a decision before development, not after launch.
Has a baseline been recorded? Without it, nobody can prove whether the migration cost anything.
Are redirects single-hop? Chains are the most common avoidable fault.
Is content being carried over in full, or trimmed? Pages rank for what is on them.
Who is checking the staging site's robots directives before it goes live? A staging block shipped to production is a total outage in search terms.
Deliverables
A complete crawl of the existing site, capturing every live URL before anything changes
A URL map assigning every old address a destination, or a documented decision to retire it
Redirect registry with single-hop 301s, implemented and crawled before launch
A traffic, ranking and indexation baseline recorded before go-live
Pre-launch checks: robots directives, canonicals, sitemaps, structured data, analytics
Post-launch monitoring against the baseline for the weeks that matter
A documented rollback position, so a serious problem has an answer other than panic
Built with
Process
Migration work runs in reverse to most projects: the largest effort happens before anything is built. We crawl and archive the existing site first, because once it is replaced that information is gone and reconstructing it is guesswork. The URL map is agreed before development starts, which means the new site is built to a known address structure rather than having redirects retrofitted to whatever it ended up with.
The standard nine stages — discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement, continuous improvement — apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Preserve URLs, remap them, or consolidate
Preserve the URL structure
Fits: Redesigns where the existing structure is sound
Limits: Carries forward any structural problems the old site had
Remap to a new structure
Fits: Sites whose URLs are keyword-stuffed, inconsistent or deeply nested
Limits: Every URL needs a redirect, and the risk scales with how many there are
Consolidate several sites
Fits: Businesses with microsites or duplicate properties splitting their authority
Limits: Highest risk — multiple sources, overlapping content, and decisions about what survives
Case studies
No published migration case study. Migration outcomes are meaningful only against a baseline, and we will not publish one until we can show both sides with permission.
MBGDesk operates from 4 offices — India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Will we lose rankings when we redesign?
Not necessarily, and the variable is preparation rather than luck. Migrations that keep URLs or map them carefully usually hold position. Migrations where URLs change without redirects usually do not. Some short-term fluctuation while search engines recrawl is normal even when everything is done correctly.
Can you fix a migration that already went wrong?
Usually. We crawl what the old site had — from archives, analytics, Search Console and any backup — identify what is now 404ing, and build the redirects that were missing. Recovery is rarely instant and rarely complete, which is the argument for doing it beforehand.
How long before traffic recovers after a migration?
Weeks, typically, while search engines recrawl and reprocess. If it has been months with no recovery, something is still wrong rather than slow, and it is worth diagnosing rather than waiting.
Do we need to keep the old content?
Keep what earns traffic. A page ranking well is ranking for what is on it, and a rebuild that trims it to fit a new design frequently loses the position. Content decisions should be made against the data, not against the layout.
What about changing domain?
It is manageable and adds risk. Every URL redirects, Search Console needs the change-of-address process, and there is a settling period while signals transfer. It should be a decision with a business reason behind it, not a preference.
What is the single most common mistake?
Shipping the staging site's robots.txt to production. It blocks everything, it is invisible to anyone not checking, and it can cost weeks before someone notices the traffic is not returning.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.