SEO Site Migration: How to Move Without Losing Rankings
A migration is the easiest way to accidentally tank a site in search - and one of the most avoidable. With a full URL map, clean 301 redirects and careful monitoring, you can replatform or move domains without losing rankings.
- An SEO site migration only loses rankings when URLs change without a plan to carry their value across, which makes ranking loss avoidable rather than inevitable.
- Most of the work happens before launch: crawl and inventory every current URL, map each old URL to a single new destination, and rehearse on a staging site kept out of the index.
- The mechanics are unglamorous - one-to-one 301 redirects, preserved content and metadata, a fresh sitemap, an open robots.txt, and disciplined Search Console monitoring after go-live.
- Change one variable at a time: separate the technical move from any content rewrite so that if rankings shift, you can tell which change caused it.
An SEO site migration keeps rankings when every valuable old URL points, cleanly and permanently, at its correct new home. Search engines rank individual URLs, not "your website" as a whole, so the risk in any migration comes from changing those addresses. Get the mapping right and the equity carries across; get it wrong and pages Google ranked simply stop existing where it knows to look for them.
The reassuring part is that ranking loss is almost entirely avoidable. Migrations tank traffic not because moving a site is dangerous, but because the SEO work gets treated as an afterthought to the design and the deadline. Inventory every current URL, map old to new one-to-one, redirect with permanent 301s, preserve content and metadata, then monitor Search Console closely after launch. This is the playbook for doing exactly that.
What an SEO Site Migration Is and Why Moves Lose Rankings
An SEO site migration is any move - a replatform, redesign, domain change, HTTP to HTTPS switch, URL restructure or consolidation - executed so that the site's search rankings and traffic survive it. The defining feature is not the new design or the new stack; it is the discipline of carrying each page's accumulated search value onto its new address instead of stranding it.
Search engines rank individual URLs, each with its own history of links, relevance signals and accumulated trust. When you migrate, you are often changing those URLs, and if an old address returns a 404 or redirects to the wrong place, the signal attached to it is lost. The new page starts again from nothing, even when the content is identical.
That is why migrations show up as the cause of sudden ranking loss more often than penalties or algorithm changes do. It is rarely something exotic - it is missing redirects, redirect chains, a blocked crawl, or a long tail of deep pages that quietly stopped resolving. Every one of those is a decision that could have been made correctly before launch, which is why the goal of the whole exercise is simple to state: every valuable old URL should point, cleanly and permanently, at its correct new home.
Search engines rank URLs, not sites. If an old URL 404s or redirects to the wrong page after a move, the links and trust attached to it are stranded - which is exactly why the URL map is the single most important deliverable of any migration.
Types of Migration and What Actually Changes
"Migration" covers several different projects, and knowing which one you are running tells you what is at risk. Most real moves combine more than one of these. The table below sorts them by what changes and how much exposure they carry.
| Migration type | What changes | Primary risk |
|---|---|---|
| Replatform / CMS change | URL formats, template markup, metadata handling | URL patterns shift underneath visually identical content |
| Redesign | Templates, navigation, on-page content and headings | Internal links and content move rankings even if URLs stay |
| Domain change | Every URL changes host | Whole site must be signalled as relocated |
| HTTP to HTTPS | Every URL changes protocol | Treated as a flip of a switch instead of a full migration |
| URL restructure | Path pattern, folder structure or slug format | Looks like a small internal change, high actual risk |
| Consolidation | Many pages merge into fewer, stronger ones | Many-to-one mapping and merge decisions are hard to get right |
The Pre-Migration Plan: Inventory Everything First
The single most important phase happens before anything moves, because you cannot preserve what you have not measured. Build a complete picture of the current site while it still exists, and work through the inventory in order.
- Run a full crawl and export every indexable URL, then cross-check it against your XML sitemap, server logs and analytics so you catch pages the crawler alone might miss.
- Pull each URL's search traffic, impressions and ranking queries from Search Console and analytics, so you know which pages carry real value and which are safe to retire.
- Identify the pages that have earned external links - those are your highest-value URLs, because a broken redirect there loses signal you cannot easily rebuild.
- Build a complete old-to-new URL map: for every old URL, define its new URL, and where a page is being removed, decide deliberately where it redirects instead of letting it 404.
- Stand up the new site on a staging environment and keep it out of the index (noindex or authentication) so Google never treats the draft as duplicate content.
Treat the URL map as the deliverable everything else depends on. If you get one thing right in a migration, it is a complete, one-to-one mapping from every valuable old URL to a live new one. For the build-side foundations that keep the new site crawlable, see our guide to technical SEO for developers.
The Core Mechanics: Redirects, Metadata and Sitemaps
With the plan in hand, the move itself is largely about preservation. The new site should inherit as much of the old site's search identity as possible and redirect the rest cleanly.
- 301 redirects, one-to-one - use permanent (301) redirects to send each old URL to its exact new equivalent, never a blanket redirect that dumps everything on the homepage, which tells search engines the pages are gone rather than moved.
- No redirect chains or loops - a redirect should go straight from old URL to final new URL in one hop; chains waste crawl budget and dilute signal, and loops break entirely.
- Preserve titles, metadata and content - keep them intact where you can, so you are not changing two variables at once and losing the ability to tell what moved a ranking.
- Keep internal links pointing at final URLs - update navigation, in-content links and footers to hit the new URLs directly, not through a redirect they should not need.
- Canonical tags - point each new page's canonical at itself and remove any canonical still referencing an old address, or a mismatch can undo the redirects you just set up.
- Update the XML sitemap - publish a fresh sitemap listing only new, canonical URLs; some teams keep a temporary sitemap of old URLs briefly to help Google discover the redirects, then retire it.
- Do not block the new site in robots.txt - shipping the staging robots.txt to production is the most common launch-day disaster, so confirm the live file allows crawling of everything that should rank.
Launch and Post-Launch: The Monitoring Checklist
Launch is the middle of the process, not the end. The days and weeks after go-live are when problems surface, and fast fixes are what separate a clean migration from a slow decline. Work through this list at launch and keep watching.
- Spot-check a sample of high-value old URLs and confirm each returns a single 301 to the correct new page, with no chain and no 404.
- Confirm the production robots.txt is not blocking the site and that no stray noindex tag survived from staging on pages that should rank.
- Submit the new XML sitemap in Google Search Console and Bing Webmaster Tools so the new URLs are discovered quickly.
- For a domain move, use the Change of Address tool in Search Console to tell Google the whole site has relocated - alongside the redirects, not instead of them.
- Watch the coverage and crawl reports for a spike in 404s, redirect errors or pages dropping out of the index, and fix the causes as they appear.
- Compare rankings, impressions, clicks and traffic against your pre-migration baseline; a small temporary dip is normal, a sustained slide points at a real problem.
- Leave the redirects live long-term, because removing them early strands any signal that had not fully transferred and any external link still pointing at an old URL.
Google's migration guidance and the Search Console tools change over time, so treat the current documentation as the source of truth rather than any fixed rule of thumb. The steps here match Google's live advice: keep URLs stable where you can, redirect one-to-one when you cannot, and give search engines time to reprocess.
What Drives the Cost and Timeline of a Migration
Migration effort scales with the size and messiness of the current site, not with the polish of the new design. These are the qualitative factors that move the timeline and the cost, so you can gauge scope before committing to a date.
None of these are dollar figures, and no honest estimate is one until the crawl is done. The inventory is what turns a vague quote into a real one, because it exposes how many URLs actually need mapping and how much of the site is worth carrying forward at all.
Common Mistakes and a Post-Launch Diagnostic
Almost every migration that loses rankings does so through a short list of avoidable mistakes. Knowing them in advance is half the defence.
- Redirect chains and loops - old URLs bouncing through several hops, or redirecting in circles, instead of going straight to the final destination.
- Missing redirects - old URLs that simply 404 because they were never mapped, most often the long tail of deep pages nobody thought to check.
- Leaving staging noindex on production - the noindex tag or Disallow rule that protected the staging site gets deployed to the live site and quietly deindexes it.
- Blocking the crawl - a robots.txt that disallows crawling, or a login wall left in front of pages that should be public.
- Changing too much at once - redesigning, replatforming, moving domains and rewriting content in a single release, so when rankings move there is no way to isolate the cause.
- Redirecting everything to the homepage - a lazy catch-all that treats moved pages as gone and throws away their accumulated value.
- Forgetting internal links, canonicals and sitemaps - leaving the new site pointing at old URLs through redirects, or advertising stale URLs to search engines.
When something does look wrong after launch, most symptoms trace straight back to one of those mistakes. This table maps what you see to the likely cause and the fix.
| Symptom | Likely cause | Fix |
|---|---|---|
| Whole site drops out of the index | Staging noindex or robots.txt block shipped to production | Remove the noindex tag; open up robots.txt; request reindexing |
| Specific pages return 404 after launch | Old URLs not included in the redirect map | Add one-to-one 301 redirects for the missing URLs |
| Rankings slip slowly over weeks | Redirect chains, homepage catch-alls, or lost internal links | Collapse chains to single hops; redirect page-to-page; fix internal links |
| New URLs slow to appear in search | Sitemap not updated or not submitted | Publish the new sitemap of canonical URLs and submit it in Search Console |
| Duplicate content warnings | Old canonicals left in place or both HTTP and HTTPS resolving | Point canonicals at new URLs; force one protocol and host via redirects |
| Domain move not being recognised | Change of Address not used alongside redirects | Use the Search Console Change of Address tool and keep 301s live |
The teams that migrate cleanly tend to share one habit: they change one thing at a time. Where you can, separate the technical move from the content rewrite - replatform and preserve the content first, confirm rankings hold, then improve the content in a second phase, so if something moves you know which change caused it. Deciding what content survives the move, and how it is structured, is itself an SEO exercise; our note on SEO content strategy covers how to prioritise and consolidate pages so the migration makes the site stronger, not just different.
Planning a Move Without Losing Rankings?
If you are replatforming, redesigning or changing domains, we can build the URL map, set up clean redirects and monitor the launch so your rankings come across with you.
How Acqurio Tech Approaches Migrations
We plan and run migrations with search continuity built into the process, so a replatform, redesign or domain move does not cost you the rankings you have earned. We deliver remotely from India with an engineered overlap window, so the plan, the redirects and the launch monitoring stay coordinated with your team.
- Web development - new builds and replatforms delivered with a full URL map, clean 301 redirects and search access designed in from the start.
- Pre-migration audits - a complete crawl and inventory of your current URLs, rankings and links, so nothing valuable is left behind.
- Post-launch monitoring - watching Search Console for crawl errors, index coverage and ranking drops after go-live, and fixing issues fast while they are still cheap to fix.
Conclusion
A migration does not have to cost you rankings. The sites that lose traffic are the ones that treated URLs as an implementation detail; the sites that keep it are the ones that mapped every old URL to a new one, redirected cleanly with permanent one-to-one 301s, preserved their content and metadata, and watched Search Console closely after launch.
None of it is exotic. It is inventory, mapping, clean redirects and disciplined monitoring - unglamorous work that protects years of accumulated search equity. Plan it properly and a migration becomes what it should be: a fresh, faster, better-structured site that keeps everything it earned. If you would rather not gamble your rankings on getting every redirect right, contact us and we will run the move with you.
Frequently asked questions
What is an SEO site migration and how do I keep my rankings through one?
An SEO site migration is the process of moving a website - a replatform, redesign, domain change, HTTP to HTTPS move, URL restructure or consolidation - in a way that preserves its search rankings and traffic. You keep rankings by mapping every old URL to its new equivalent and using permanent 301 redirects so the value each page earned carries across to the new address instead of being lost.
How do I avoid losing rankings when I migrate a site?
Plan before you move. Crawl and inventory every current URL along with its rankings, traffic and backlinks; build a complete one-to-one map from each old URL to its new one; rehearse on a staging site kept out of the index; then launch with clean 301 redirects, preserved content and metadata, an updated sitemap and an open robots.txt. After launch, monitor Search Console for crawl errors, index coverage and ranking drops, and fix issues quickly.
Why are 301 redirects so important in a migration?
A 301 is a permanent redirect, and it tells search engines that a page has moved for good and to transfer its accumulated signal to the new URL. One-to-one 301s - each old URL going straight to its correct new page in a single hop - are how ranking value survives the move. Redirect chains, loops, or a blanket redirect to the homepage waste that value, so the redirect map is the most important part of the whole project.
Do I need to tell Google I moved to a new domain?
For a domain change, yes. Set up one-to-one 301 redirects from the old domain to the new one, then use the Change of Address tool in Google Search Console to tell Google the whole site has relocated. The tool works alongside the redirects, not instead of them, and it helps Google reprocess the move faster. Submit the new domain's sitemap so the new URLs are discovered quickly.
How long does it take to recover rankings after a migration?
It varies with the size of the site and how cleanly the move was executed. A small, temporary dip while Google recrawls and reprocesses the new URLs is normal and often recovers within a few weeks. A sustained slide usually signals a real problem - missing redirects, chains, a blocked crawl or a stray noindex - so treat a lasting drop as something to diagnose and fix rather than wait out. Keep the redirects in place long-term.
Should I redesign the content at the same time as the migration?
Where you can, no. Changing the platform and rewriting the content in a single release changes two variables at once, so if rankings move you cannot tell which change caused it. The lower-risk sequence is to replatform while preserving content and metadata, confirm rankings hold, then improve the content in a second phase. If a content rewrite is unavoidable in the same release, document exactly what changed so you can diagnose any drop.
How do I handle old URLs I no longer want to keep?
Do not simply let them 404. For each retired page, decide deliberately where it should redirect - usually to the closest relevant surviving page - so any links and signal it earned pass to a live URL. Only pages with no relevant destination and no external links should be allowed to return a 404 or 410, and even then it is a conscious choice made from the URL inventory, not an accident of an incomplete redirect map.