How to Do a Site Migration Without Losing SEO

Deep breath. I know the feeling: the new site is nearly ready, everyone’s excited, and somewhere in the back of your mind a small voice is whispering “what if we lose all our rankings?” Let’s answer the big question first, plainly. Here’s how to do a site migration without losing SEO: inventory every URL you have before you touch anything, map each old URL to its closest new equivalent with one-to-one 301 redirects, benchmark your rankings and traffic so you can diagnose later, launch with the redirects tested and the noindex tags off, and then watch crawl errors and traffic against that benchmark for weeks — keeping the redirects in place for a year or more. The traffic you keep is proportional to the inventory you took and the redirects you shipped. That’s the whole philosophy; the rest of this guide is the execution.

And one honesty note before we start, because I’d rather you hear it from a friend: even a flawless migration usually comes with some temporary turbulence. Rankings wobble, traffic dips and recovers, crawlers take time to re-learn your site. Some fluctuation over a period of weeks is normal and expected. What’s not normal is a permanent cliff — traffic that falls and stays fallen means something actually broke, and the whole point of this guide is making sure you can tell the difference and fix it fast. I won’t promise you a percentage either way, because anyone who quotes you a precise “you’ll keep X% of your traffic” number is making it up. Carefulness is the variable you control.

What actually counts as a site migration?

“Migration” gets used loosely, so let’s name the flavors — because each one carries its own specific risk, and knowing yours tells you where to concentrate your care.

• Domain change. Same site, new address (rebrand, merger, shorter name). The risk: every external link on the internet points at the old domain, and search engines have to re-learn that your entire identity moved. This is the flavor where Search Console’s change-of-address step matters most.
• HTTPS or URL-structure change. Same domain, different URLs — moving to HTTPS, dropping “www,” flattening folders, or rewriting slugs. The risk: it feels minor, so people skip the inventory, and every changed path is a potential 404 wearing a disguise.
• Platform or CMS change. Moving from one system to another. The risk: the new platform generates URLs its own way — different slugs, different category paths, different pagination — and quietly drops features the old one had (tag pages, image URLs, feed URLs). The gap between “what the old CMS served” and “what the new one serves” is where traffic disappears.
• Redesign with URL changes. A new look that also moves pages around. The risk: the redesign gets all the attention and the URL changes get none, because “it’s just a redesign.” If URLs change, it’s a migration, full stop.
• Site consolidation. Folding two or more sites into one. The risk: duplicated topics competing for the same mapping, and the temptation to point entire sites at one landing page instead of mapping page-to-page.

One rule covers all five: if URLs change, it’s a migration, and migrations get the full process. A redesign that keeps every URL identical is the only version of this that gets a lighter touch — and even then, benchmark first, because templates change internal links and page speed, and you’ll want to know what moved.

Phase 1: how do you prepare for a site migration without losing SEO?

This is the measure-twice phase, and it’s where migrations are actually won. Everything that goes wrong on launch day was skippable work in this phase. Here’s the preparation sequence, in order.

Step 1: Build the full URL inventory

Before anything else, you need a complete list of every URL your current site has — and “complete” is the operative word. Pull from three sources and merge them:

• Crawl your own site. Run a crawler over the live site and capture every URL it can reach: pages, images if they rank for you, PDFs, pagination, parameter variants. This catches what’s linked.
• Export from analytics. Every URL that received traffic over the past year. This catches pages that earn visits even if your crawl missed them.
• Export from Search Console. Every URL with impressions or clicks, plus the indexed-pages data. This catches what search engines actually know about — which is often a longer list than you expect.

Merge, dedupe, and don’t prune yet. The reason you cast this wide: the pages you forgot exist are the pages you’ll lose. Every migration horror story I’ve heard starts the same way — an old landing page, a resource PDF, a blog post from four years ago that quietly earned links and traffic, left out of the redirect map because nobody remembered it existed. The inventory is your defense against your own memory.

Step 2: Draw the value map

Now rank the inventory. For each URL, note three things: how much organic traffic it gets, what external links point at it, and what it ranks for. Sort by value. The top of this list — the URLs carrying your traffic, your backlinks, your rankings — are the pages you protect first and verify hardest. If launch day goes sideways and you can only check fifty redirects by hand, these are the fifty. The value map turns an overwhelming inventory into a priority order, and it’s also your argument when someone suggests “simplifying” a section: now you can see exactly what that section is worth before anyone deletes it.

Step 3: Build the redirect map

The redirect map is the single most important document in the entire migration: a spreadsheet with two columns, old URL and new URL, covering every row of your inventory. The discipline that makes it work:

• One-to-one wherever possible. Each old URL points to the new URL that serves the same intent. The old pricing page goes to the new pricing page. The old guide to topic X goes to the new guide to topic X.
• Closest equivalent when there’s no twin. If a page has no direct counterpart on the new site, redirect it to the nearest relevant page — the parent category, the closest sibling topic. Nearest relevant, not “whatever’s convenient.”
• Never the homepage dump. Pointing dozens of old category and content pages at the homepage is the classic value incinerator. A visitor who clicked a link about a specific topic lands on your front door with no idea where to go, and search engines treat a redirect to an unrelated page as roughly a dead end. Every homepage-dump row in your map is value you chose to burn.
• Decide the genuinely-dead pages honestly. Some old URLs deserve to die — no traffic, no links, no equivalent. Letting those return a clean 404 or 410 is fine and honest. The crime isn’t removing dead weight; it’s removing live weight without a redirect.

Get this map reviewed by someone who knows the content. A second pair of eyes catches the mapping that’s technically fine and semantically wrong.

Step 4: Benchmark everything

Before launch, capture the before-picture: your rankings for the keywords that matter, your organic traffic by page and by section, and your indexed-page counts from Search Console. Screenshot it, export it, date it. This benchmark is your diagnostic instrument for the entire post-launch period — it’s how you’ll distinguish “normal settling” from “the blog section is down 90% because its redirects are broken.” You can’t diagnose what you didn’t measure, and you cannot take this measurement retroactively. Benchmarks are cheap before launch and impossible after.

Step 5: Run the staging checklist

While the new site sits on staging, verify the things that kill migrations silently:

• The noindex kill-switch. Staging sites are (rightly) set to noindex so the unfinished site doesn’t get indexed. The single most classic migration disaster is launching with that noindex still on — the new site goes live politely asking search engines to forget it exists. Make “remove noindex / unblock robots” an explicit, named, owned launch-day task. Not implied. Named.
• Crawlability at launch. Check robots.txt on staging and confirm what the launch version will allow. Confirm the new site’s pages are reachable through internal links, not orphaned.
• Internal links point at final URLs. Every internal link on the new site should point directly at new URLs — not at old URLs that bounce through your own redirects. A site that redirect-chains itself on every click wastes crawl efficiency and slows everything down. Fix internal links at the source, on staging, before launch. If you want the deeper fundamentals behind these checks, my guide on how to do a technical SEO audit is the full pre-flight inspection — running one on staging is the strongest version of this step.

What do you actually do on launch day?

If Phase 1 was done properly, launch day is execution, not improvisation. Here’s the sequence.

First: redirects live, then tested. The moment the new site is up, your redirect map goes live with it — ideally in the same deploy. Then test it: take a healthy sample across the whole map, and hand-verify the top of your value map one URL at a time. You’re checking three things: the redirect fires, it lands on the right destination, and it’s a 301 — the permanent kind — not a 302 temporary redirect, which is the wrong signal for a permanent move. (Redirect handling evolves; it’s worth a quick check of current search-engine guidance when you build your plan. But the discipline doesn’t change: permanent moves get permanent redirects.)

Second: swap and submit the sitemap. The new site’s XML sitemap — new URLs only — replaces the old one, and you submit it in Search Console so crawlers get the fresh map immediately rather than discovering it at their leisure.

Third: file the change of address if your domain changed. For domain moves specifically, Search Console has a change-of-address flow that formally tells Google the site has moved. Use it — it exists precisely for this. (Console features get renamed and reshuffled over time, so verify the current steps in Google’s documentation when you’re ready; the principle — formally notify the engine of a domain move — is stable.)

Fourth: the old-sitemap trick, with honesty. A technique many practitioners use: temporarily keep a sitemap of the old URLs submitted alongside the new one, so crawlers re-visit the old addresses quickly, hit the redirects, and process the move faster. The logic is sound — you’re inviting the crawler to discover your redirects instead of waiting for it to wander by. It’s a short-term discovery aid, not a permanent fixture, and guidance on it has shifted over the years — so verify current practice before relying on it. I mention it because you’ll encounter it, and it’s better to understand it than to be confused by it.

On that last line: your audience shouldn’t discover the move by accident, and the announcement doubles as a wave of fresh visits to the new URLs. If you schedule your social posts through SocialBlaze, queue the announcement across your channels ahead of launch morning so it goes out the moment you flip the switch — one less thing to remember on the most distracting day of the project.

What do you watch after a site migration?

Here’s the part most guides on how to do a site migration without losing SEO quietly skip: launch isn’t the finish line; it’s the start of the watch phase. This is where you catch the problems that survived your preparation — and where you resist the urge to panic at normal turbulence.

The watch rotation

Daily, for the first week: crawl errors and 404s. Search Console’s indexing and page reports will show you exactly which old URLs are hitting 404 instead of redirecting — each one is a hole in your redirect map, found for you. A 404 spike in week one isn’t a disaster, it’s a to-do list. Work it daily while the signal is fresh. (This is the same muscle as routine error triage, and my companion guide on how to fix crawl errors covers the full diagnosis-and-fix workflow — post-migration, it becomes your most-used reference.)

Weekly, for the first couple of months: rankings and traffic against the benchmark. Compare like with like — this page’s traffic now versus the benchmark, this section versus that section. The benchmark is what turns “traffic looks lower?” into “the product pages are fine, the blog is down, and the blog’s redirects are the ones written by hand at 11pm.”

The triage rules

• 404s with history get redirects. Any 404ing old URL that had traffic or links gets added to the redirect map and shipped. Today, not next sprint.
• Soft 404s get real destinations. If a redirect lands users on an empty or near-empty page, search engines may treat it as a dead end anyway. Re-map to a page with actual substance.
• Chains get flattened. Any old URL that now takes two or more hops to reach its destination gets its map entry updated to point directly at the final URL.

The patience window

Here’s the part that saves your sanity: weeks of settling is normal. Rankings fluctuate while search engines re-crawl, re-evaluate, and transfer signals to the new URLs. The way to stay calm is to let the benchmark arbitrate. Turbulence looks like broad, shallow wobble — a little down here, a little up there, trending back toward baseline over weeks. A real break looks like a cliff that doesn’t recover — especially one concentrated in a specific section, which almost always traces to a specific cause: a batch of broken redirects, a template that shipped with noindex, a section the new sitemap forgot. Wobble gets patience. Cliffs get investigation, that day.

Keep the redirects. No, longer than that.

There’s a persistent myth that redirects only need to live for three months or so, after which the move has been “processed” and you can delete them. Please don’t. Two reasons the myth fails:

• External links point at your old URLs forever. That article that linked you in 2021 will never update its link. The day you remove the redirect, every one of those links — and every human who clicks one — hits a dead end.
• Signal transfer isn’t instant or uniform. Search engines process moves over extended periods, and deep or rarely-crawled pages take longest. Pulling redirects early can cut the transfer off mid-move.

The grown-up policy: redirects from a migration stay in place for a year or more, and honestly, if they’re not causing you maintenance pain, just leave them. A redirect map is nearly free to keep and expensive to have deleted.

What can’t you control — and what should you never combine?

Time for the honesty sections, because a guide that implies perfect execution guarantees perfect outcomes is lying to you politely.

Some reshuffling happens even in perfect migrations

When search engines re-evaluate a site wholesale — new URLs, new templates, new internal link graph — some rankings land in slightly different places than before, even when every redirect is flawless. New page layouts emphasize different content; a changed internal-link structure shifts how value flows between pages. Most of it settles; some of it settles differently than before. This isn’t failure and it isn’t fate — it’s re-evaluation. What the process in this guide controls is the part carelessness would have lost. The remainder is weather, and you dress for weather with benchmarks and patience, not panic.

The don’t-combine rule

Here’s the rule I wish someone had tattooed on every project plan: don’t combine migrations. A redesign, a URL restructure, a platform change, and a rebrand are each a migration-grade event. Stacking them into one launch feels efficient — “we’re touching everything anyway!” — and it creates an undebuggable launch. When traffic drops after a combined launch, was it the new design? The new URLs? The new platform’s rendering? The lost internal links? You cannot tell, because you changed every variable at once. Four careful phases beat one chaotic big bang every time it’s possible to stage them. Change the platform with identical URLs first, then restructure URLs later — or redesign on the current structure, then migrate the structure next quarter. Whatever you can decouple, decouple. Each isolated phase is diagnosable; the combined one is a mystery novel where you’re also the victim.

When should you hire help?

Real talk: if the site is large, or organic traffic is a meaningful revenue line, a migration is one of the highest-stakes technical events in a site’s life — and a botched one can take months to claw back. If that sentence made your stomach drop, that’s your answer. An experienced migration specialist has watched dozens of these and knows where the bodies are buried: the parameter URLs nobody inventoried, the pagination the new CMS handles differently, the hreflang tags that didn’t survive the move. For a small site, this guide plus care is genuinely enough. For a site where a bad quarter of organic traffic is a bad quarter of business, a specialist’s fee is cheap insurance. There’s no shame in it — the measure-twice mindset includes measuring your own capacity honestly.

The phase-by-phase migration checklist

Here’s the whole system in one place — the centerpiece. If you only bookmark one thing, bookmark this.

Zoom out for a second, because this connects to the bigger picture: a migration done well protects more than rankings — it protects the compounding asset you’ve been building. Every piece of content, every internal link, every earned backlink is part of the authority your site has accumulated, and the redirect map is how that accumulated trust travels to the new address intact. If you’re playing that longer game deliberately, my pillar guide on how to build topical authority is the companion read — the migration guide protects the asset; that one grows it.

So when someone asks you how to do a site migration without losing SEO, you now have the honest answer: take the complete inventory, map every URL to its closest equivalent, benchmark before, launch with the kill-switches off, watch daily and then weekly, and keep the redirects longer than feels necessary. Measure twice. Cut once. Then hold your nerve through the turbulence, because you did the work that makes turbulence temporary.

Frequently asked questions

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

Expect a settling period measured in weeks, sometimes stretching longer for large sites — search engines need time to re-crawl the old URLs, process the redirects, and transfer signals to the new ones. There’s no reliable universal number, and anyone quoting a precise one is guessing. The useful signal is direction: broad shallow wobble trending back toward your benchmark is normal; a sharp drop that doesn’t recover means something specific broke and needs investigation.

Should I use 301 or 302 redirects for a site migration?

301s. A migration is a permanent move, and a 301 is the permanent-move signal; a 302 says “temporary,” which is the wrong message for URLs that are never coming back. Redirect handling has evolved over the years, so it’s worth checking current search-engine guidance when you build your plan — but the principle is stable: permanent moves get permanent redirects.

How long should I keep redirects after migrating a website?

At least a year, and ideally indefinitely. The old “three months is enough” idea is a myth: external sites that linked to your old URLs will never update those links, so removing redirects breaks them forever, and search engines process moves over extended periods — especially for deep, rarely-crawled pages. Redirects cost almost nothing to keep and real traffic to delete.

Will I lose traffic during a site migration?

Some temporary fluctuation is normal even in well-executed migrations — rankings wobble for a period of weeks while search engines re-evaluate the site. What a careful migration prevents is permanent loss: the complete URL inventory, one-to-one redirect map, and pre-launch benchmark are what keep temporary turbulence from becoming a lasting cliff. No one can honestly promise you an exact retention percentage; carefulness is the variable you control.

Can I redirect all my old pages to the homepage?

Please don’t — it’s the classic value incinerator. Visitors who clicked a link about a specific topic land on your front door with no path forward, and search engines tend to treat redirects to irrelevant pages as roughly equivalent to dead ends. Map each old URL to its closest new equivalent: the matching page where one exists, the nearest relevant category or sibling where one doesn’t. Reserve 404s for pages that genuinely have no equivalent and no value.