Site migration SEO: how to migrate a website without losing rankings

Most of the traffic you lose in a migration, you lose to yourself. A site migration done with discipline keeps the rankings; one done in a rush quietly bins them.

A site migration is any major change to your site that affects its URLs, structure, platform, or domain, and site migration SEO is the discipline of carrying your rankings, authority, and indexed pages through that change without losing them. Done carelessly, a migration can wipe out years of organic performance overnight. Done with discipline, it barely registers as a dip.

The scary stories are real. Businesses do lose half their organic traffic to a redesign, and some never fully recover. But here is the part the horror stories leave out: those losses are almost always self-inflicted and preventable. A missing redirect, a staging block left live, a page silently dropped in the rebuild. None of these are acts of God. They are process failures, and the right process stops them.

This is the method we actually run when we migrate a client’s site, written out so you can run it yourself. If you would rather we run it or de-risk one already underway, that is what our SEO services are for. Either way, you will get further reading this than you will from any gated checklist that asks for your email before it tells you anything.

What is an SEO migration?

An SEO migration is the work of preserving and transferring your organic rankings, authority, and indexed pages while your website undergoes a major change. The change might be a new platform, a new domain, a restructured set of URLs, or a redesign that touches all three. The SEO part is everything you do to make sure Google can still find, crawl, index, and rank the new version as well as it ranked the old one.

People use a few terms for this and they mean the same thing in practice: seo migration, website migration seo, and site migration seo all describe the same discipline. The reason it matters is mechanical. When your URLs change, Google has to re-discover the new addresses, re-crawl them, re-index the content, and re-attribute the authority that pointed at the old ones. Every gap in that chain leaks rankings. A page that returns a 404 instead of redirecting loses its position and the links pointing to it. A page that loads but no longer carries the content that earned its rank slips down the results.

The revenue-first lens applies from the very first step. Not all pages are equal, and treating them as if they are is how businesses pour effort into URLs nobody visits while the pages that actually generate enquiries get the same casual treatment as a five-year-old blog post. The discipline is to know which pages pay and protect those hardest.

The 6 types of site migration (and what makes each risky)

“Migration” covers a wide range of changes, and the risk profile is completely different at each end of that range. Forcing HTTPS on a site that already uses clean URLs is low-stakes housekeeping. Changing your domain and your platform and your URL structure in one launch is three high-risk migrations stacked on top of each other. Before you plan anything, you need to know which type you are actually doing, because the type dictates the plan.

Migration type	Risk	What breaks	The fix that matters most
HTTPS (HTTP to HTTPS)	Low to medium	Mixed content, canonicals, HSTS	Update canonicals and internal links to https, force the redirect
URL restructure (same domain)	Medium	Internal links, redirect gaps	Complete redirect map plus updated internal links
Domain change	High	Authority transfer, brand signals, GBP	Redirect map, GSC Change of Address, backlink reclaim, GBP update
CMS replatform (same URLs)	Medium	Template parity, schema, render and speed	Match templates, rebuild schema, validate rendering on staging
CMS replatform (new URLs)	High	Full URL change plus content parity	Full redirect map, content-parity audit, internal-link rebuild
Consolidation or site merge	Very high	Competing content, equity split	Per-domain redirect maps, canonical and noindex strategy

The two that demand the most care are the domain change and the replatform with new URLs. A domain change moves every signal Google has associated with your old address to a new one, and the platform handles that transfer imperfectly even when you do everything right. You need the redirect map, but you also need to fire a Change of Address in Google Search Console, reclaim the backlinks pointing at the old domain where you can, and update your Google Business Profile and citations so your local signals do not fragment.

A replatform with new URLs is really a URL restructure and a platform change at once, so it carries the failure modes of both: every URL needs a redirect, and the new platform has to render the same content the old one did. This is where ecommerce gets caught out. WooCommerce lets you nest category URLs however you like, but Shopify enforces its own structure, with products at /products/{slug} and categories at /collections/{slug}. You cannot keep your old URL structure on Shopify, so the constraint has to be mapped before you choose the platform, not discovered after you have migrated. If you run an online store, plan the replatform around those structural rules from the start; getting it wrong on a revenue-generating store is one of the more expensive ways to learn this lesson. Our SEO team handles replatform migrations where the URL structure changes underneath the catalogue.

How to migrate a website without losing SEO: the phased process

Every credible migration follows the same four phases. The competitors agree on the spine. Where they fall short is the discipline inside each phase, the unglamorous detail that is the actual difference between a clean migration and a costly one.

1. 1 Phase 1: benchmark and document before you touch anything. Capture current rankings, traffic, indexed pages, and backlinks so you can prove what you had and detect what you lose.
2. 2 Phase 2: build the redirect map and test the new site on staging. Map every old URL to its match and keep the staging environment blocked from indexing while you do it.
3. 3 Phase 3: launch, then immediately verify redirects, robots.txt, sitemap, and tracking. Launch day is a verification exercise, not a celebration.
4. 4 Phase 4: monitor Search Console and rankings closely for the first weeks. Expect a dip, watch for errors, and track recovery back to your baseline.

Phase 1: benchmark and crawl (before)

Document your current rankings and traffic before you change anything. This is a non-negotiable house rule for us, because if you do not know what you had, you cannot tell whether the migration cost you anything. Pull rankings for your top keywords, organic sessions by landing page from GA4, your click and impression data from Search Console, and a snapshot of your referring domains.

Then build a complete inventory of every URL on the site, from every source you have. A single export will always miss pages. Crawl the live site with Screaming Frog, pull the XML sitemap, export your indexed pages from Search Console, list your top organic landing pages from GA4, pull your best pages by backlinks from Ahrefs, and where you can, mine the server logs for URLs that still get crawled. Merge those into one master list. The pages that exist in your server logs but not in your sitemap are exactly the ones a developer rebuilding “the site” will forget, and a forgotten page is a 404 waiting to happen.

This is also where the revenue-first move happens: tier every URL as High, Medium, or Low priority by its traffic, its conversions, and its backlinks. Your High tier is the set you defend hardest, individually map, and individually test. A single master list that everyone works from, kept as the source of truth, is what stops the “the dev guessed the URLs” failure that sinks so many migrations. If you want a structured way to capture the baseline before you start, our guide to SEO benchmarking walks through the metrics worth recording.

Phase 2: redirect map plus staging

Phase 2 is where the redirect map gets built, and it is important enough to have its own section below. The discipline that belongs here is the staging environment. Build and test the new site somewhere Google cannot see it, which means the staging site is either password-protected or blocked with a site-wide noindex and a robots disallow. Test the redirects on staging before launch, not after. The single most common self-inflicted disaster is launching a site that still carries the staging block, telling Google to deindex the entire thing the moment it goes live.

Phase 3: launch day

Launch day is a checklist, run in order. Remove the staging blocks (the noindex, the password, the robots disallow) so the live site is crawlable. Switch the redirects on and confirm they fire. Submit the new XML sitemap in Search Console and verify the property. For a domain change, fire the Change of Address tool. Confirm your analytics and conversion tracking still record. Then spot-check your top 20 revenue pages by hand: load each one, confirm it resolves, confirm the old URL redirects to it, and confirm the content is intact. The pages that pay get checked individually, every time.

Phase 4: monitor and recover

Expect a dip. A migration almost always causes a temporary drop while Google re-crawls and re-attributes, and panicking at a week-one decline leads to changes that make things worse. Watch Search Console daily for the first fortnight for 404s, server errors, and redirect problems, and track the positions of your top 50 keywords. As a rough, not-guaranteed guide, traffic often sits within around 20% of baseline in week one, recovers to roughly 70 to 85% by weeks two to three, and approaches its old level by about week four if the migration was clean. If it is not recovering on that kind of curve, something is broken, and the diagnostic later in this guide tells you where to look.

Redirect mapping is the step that makes or breaks it

If you take one thing from this guide, take this: the redirect map is the load-bearing step, and it is the one competitors mention in a sentence and move past. Every old URL must point to one server-side 301 redirect to its closest matching new URL. No chains (a redirect that points to another redirect), no loops, and no soft 404s where a dead page returns a 200 status.

How you implement the redirect matters as much as whether you implement it. Server-level redirects are the most reliable, edge or CDN redirects are the next best, and a CMS plugin is a workable fallback. What you never use is a JavaScript redirect or a meta-refresh, because they pass authority poorly and Google treats them as second-class signals. Set them at the most robust level your stack allows.

The revenue rule on top: never redirect more than roughly 20% of your URLs to the homepage. Lazily pointing every retired page at the homepage is the hallmark of a low-quality migration, and Google reads it as exactly that, treating those redirects as soft 404s that pass little to no value. Any page that has backlinks or real traffic deserves a genuine match, a page about the same thing, not a dumping ground. For the long tail of near-identical URLs (paginated archives, old tag pages), pattern-based wildcard rules handle the volume; for your High-priority pages, you write explicit one-to-one maps and test each by hand.

What actually breaks rankings in a migration (and how to prevent it)

Here is the challenger thesis made concrete. When a migration tanks a site’s rankings, it is almost never because “Google does not like the new site.” It is because one of six specific things broke, and each one is preventable. We diagnose failed migrations in this exact order, fixing the lowest failing layer first, because a problem low in the stack makes everything above it irrelevant. Run the same order as a prevention checklist before you launch.

• Available. Is the page still there at all? Pages get silently dropped in a rebuild when the developer works from an incomplete URL list. This is why Phase 1’s complete inventory exists. If the page is gone, nothing else matters.
• Crawlable. Can Googlebot reach it? The classic failure is the staging noindex or robots disallow left live after launch, but a new platform also ships with its own default robots.txt that may block paths the old one allowed. Check the live robots.txt on launch day.
• Indexable. Is the page allowed into the index? A stray noindex meta tag from the staging build, or a canonical tag pointing at the wrong URL, quietly keeps a perfectly good page out of the results.
• Renderable. Can Google see the content? If your new platform only loads the body copy and internal links after JavaScript runs, and the renderer does not execute it, Google sees an empty page. Validate that the content is in the rendered HTML.
• Interpretable. Can Google understand the page? Headings used for visual styling rather than structure, and schema markup that broke in the rebuild, both strip away the signals that helped the page rank. Rebuild the schema as part of the migration, not as an afterthought.
• Clickable. Does the page still deserve the rank? If the rebuild thinned the content or changed it substantially, the page may simply no longer be the answer Google rewarded. Content parity is part of the migration, not a separate project.

Walk those six layers before launch and you have eliminated the overwhelming majority of preventable losses. If a migration has already gone wrong, walk them in the same order afterwards and fix the lowest failing layer first; there is no point rewriting content (Clickable) on a page that Google cannot even crawl (Crawlable).

Your site migration SEO checklist (copy and use)

Here is the complete checklist, on the page, no email gate. Copy it, paste it into your project tracker, and tick each item as you go. It pulls together the phased process above into one runnable seo migration checklist, organised by stage so the whole team can work from a single source of truth. This is the site migration checklist and website migration checklist competitors put behind a download form.

SITE MIGRATION SEO CHECKLIST

PRE-LAUNCH
   [ ] Document baseline rankings (top keywords), traffic (GA4), GSC clicks/impressions
   [ ] Snapshot referring domains and top pages by backlinks
   [ ] Build complete URL inventory (crawl + sitemap + GSC + GA4 + Ahrefs + server logs)
   [ ] Tier every URL High / Medium / Low by traffic, conversions, backlinks
   [ ] Build redirect map: every old URL to one 301, closest match
   [ ] No redirect chains, no loops, no more than ~20% to the homepage
   [ ] Explicit 1:1 maps for High-tier pages; pattern rules for the tail
   [ ] Confirm content parity on key pages (no silent thinning or removal)
   [ ] Rebuild schema markup on the new templates
   [ ] Block staging from indexing (password or noindex + robots disallow)
   [ ] Test redirects on staging before launch
   [ ] Prepare new XML sitemap

LAUNCH DAY
   [ ] Remove all staging blocks (noindex, password, robots disallow)
   [ ] Confirm live robots.txt allows the right paths
   [ ] Switch redirects on and confirm they fire (301, server-side)
   [ ] Submit new XML sitemap in Search Console
   [ ] Fire Change of Address (domain changes only)
   [ ] Confirm analytics and conversion tracking record
   [ ] Spot-check top 20 revenue pages by hand (resolve + redirect + content)

POST-LAUNCH
   [ ] Week 1: watch GSC daily for 404s, 5xx, redirect errors
   [ ] Week 1: monitor top 50 keyword positions, expect a dip
   [ ] Weeks 2-4: track recovery curve back toward baseline
   [ ] Reclaim backlinks pointing at old URLs where possible
   [ ] Update Google Business Profile + citations (domain changes)
   [ ] Months 2-3: confirm full recovery or diagnose what broke

Get this in your inbox

One AI search tactic, every Friday.

AI On Fire: a working note from the Firewire desk, sent to a few thousand Australian search marketers every Friday.

Subscribe

No spam. Unsubscribe anytime.

When you should not migrate (or should phase it)

No competitor says this, so it is worth saying plainly: sometimes the right answer is do not migrate, or at least not yet, and not all at once. A migration is a risk you take for a reason. If there is no real upside, the safest migration is the one you postpone.

A few situations should make you stop and reconsider the timing or the scope. Migrating in your peak season trades a controllable risk for an uncontrollable cost, so move the launch to your quiet period. Migrating multiple variables at once (a new domain and a new platform and a new design in one launch) compounds the risk and, worse, makes diagnosis nearly impossible when something breaks, because you cannot tell which change caused it. Where you can, phase those changes so each one launches and stabilises before the next. Migrating with no baseline data means you are flying blind and will never be able to prove whether you lost anything. And migrating a site that is already mid-recovery from a ranking drop stacks instability on instability. The revenue-first honesty is simple: weigh the upside of the change against the very real cost of getting it wrong, and if the upside is thin, wait.

DIY or hire a pro?

You can run this yourself. The framework is right here, and a careful business owner or a competent developer who works through the phases properly will get a clean result on a straightforward migration. That is the point of writing it out.

Where a professional earns the fee is the judgement and the time. The judgement is knowing which URLs are the revenue pages and tiering accordingly, deciding what counts as a genuine redirect match versus a lazy one, and reading Search Console honestly in the nervous fortnight after launch without overreacting to a normal dip. The time is the unglamorous reality that building a complete redirect map and testing it by hand is hours of work most owners do not have spare. And the stakes scale hard with the migration type. Forcing HTTPS, you can probably manage alone. A domain change or a replatform onto new URLs for a site that generates real revenue is where getting it wrong is genuinely expensive, and where having someone who has done it many times before is worth what it costs. If that is your situation, our SEO team runs and de-risks migrations as a core part of the work.

What a disciplined migration looks like (case study)

The clearest proof we have is Burke Mead Lawyers, a Newcastle personal injury firm. In January 2024 the firm closed its Family Law department, and overnight a large slice of the website’s content had to come off the site. Traffic and rankings dropped sharply; the site was effectively cut in half. The instinct in that moment is to patch the gap. Instead, we treated it as a rebuild: more than 700 accumulated blog posts were pruned to roughly 80 high-authority pages, every removed URL was 301-redirected to its closest surviving match to preserve the link equity, and the content was restructured around the two practice areas that actually generated enquiries.

The narrower, cleaner site did not just recover. It surpassed its old peak, because a specialist site with tight topical focus is exactly what Google rewards. It is the discipline in this guide applied under pressure: protect the equity with planned redirects, defend the pages that pay, and let the focus compound.

Case study · Burke Mead Lawyers

A site halved overnight, rebuilt as the category leader.

When a department closure cut the site in half, planned 301-redirects and a content rebuild turned the loss into record-high rankings.

Read the case study

+1,817%

Organic traffic

+2,078%

Top 3 rankings

+145%

Qualified leads

Frequently asked questions

What is migration in SEO?

Migration in SEO is any major change to a website (its URLs, structure, platform, or domain) handled so that organic rankings, authority, and indexed pages carry over intact. The SEO work is everything that preserves visibility through the change: a complete redirect map, content parity, and post-launch monitoring in Search Console.

How do you migrate a website without losing SEO?

Work in four phases. Benchmark your rankings, traffic, and full URL list before you start; build a server-side 301 redirect map from every old URL to its closest match and test it on a staging site blocked from indexing; launch and immediately verify redirects, robots.txt, sitemap, and tracking; then monitor Search Console and rankings for several weeks. The redirect map is the step that matters most.

How long does it take to recover after a site migration?

It varies, and nobody can promise a date. A clean migration often sees traffic within roughly 20% of baseline in week one, recovering to around 70 to 85% by weeks two to three, and approaching its old level by about week four. A messy one may never fully recover. Recovery speed depends on the migration type, your site’s authority, and how clean the redirect map was.

Do I need a 301 redirect for every page?

Yes for every indexable, valuable URL. The practical move is to tier first: your High-priority pages (traffic, conversions, backlinks) get individually mapped one-to-one and tested by hand, while the long tail of near-duplicate URLs is handled with pattern-based rules. What you do not do is leave any ranking or linked page returning a 404.

Is a website redesign the same as a migration?

For SEO purposes, a redesign that changes your URLs, structure, or platform is a migration and carries the same risks. A pure reskin that keeps every URL identical is lower risk, but it still needs a baseline snapshot and a content-parity check, because rebuilds quietly thin content and break schema more often than people expect.

Will a site migration hurt my rankings?

Done with discipline, you should see a temporary dip and then a recovery. Done carelessly, you can lose rankings permanently. The difference is almost entirely preparation: a complete redirect map, a staging test, content parity, and proper monitoring. The losses people fear are real, but they are self-inflicted and preventable.

Can I migrate my own website?

Yes, with the checklist above and some care. The risk scales with the migration type and the revenue at stake: an HTTPS move is manageable solo, while a domain change or a replatform onto new URLs for a revenue-generating site is where the cost of a mistake justifies bringing in help.

Migrate to keep the rankings you have earned

The fear around migrations is justified, but the losses are not inevitable. They are preventable, and the prevention is a process: benchmark before you touch anything, map every redirect to its closest match, test on staging, launch as a verification exercise, and monitor honestly while the dip recovers, with the pages that pay protected hardest at every step. That is the whole discipline.

If you would rather we run your migration or pressure-test a plan already in motion, that is exactly what our SEO team does. For the wider context on why protecting organic search is worth the care, our guide to SEO ROI shows how to value the rankings you are defending. Google’s own site move documentation is the authoritative reference for the technical mechanics, and it is worth reading alongside this guide.

Migrate like the rankings matter, because they do. They are the queries that pay.