Website Migration SEO: The Complete Guide to Moving Without Losing Rankings

A pattern I run into a lot: a company is weeks from launching a shiny new site, the design is approved, the dev team is heads-down, and nobody has written down a single old URL. The redesign is treated as a visual project. The search consequences are treated as something to deal with later. Later is usually the day organic traffic falls off a cliff.

That's the gap this guide closes. Website migration SEO isn't a step you bolt on at the end. It's the thing that decides whether your rankings survive the move.

I wrote this as a map, not a manual. It covers the types of migration, the phases of a safe one at a strategic level, and a risk map of what tends to break. Where you need the granular how-to or a recovery plan, I'll hand you off to the post that already covers it in depth rather than cramming all of it in here. That keeps each piece focused and keeps you from reading the same advice three times.

Two quick handoffs up front. If you want the step-by-step migration process, including what to ask your dev team, that post is the manual. If you've already launched and your rankings are gone, skip to diagnosing and recovering lost rankings. This piece is the strategy that sits above both.

What is a website migration?

A website migration is any change to where your site lives, how it's structured, what platform runs it, or what's on it that forces search engines to re-understand the site. That's a broader definition than most people use, and the breadth is the whole point.

Most people hear "migration" and think "moving to a new domain." That's one kind. So is switching your CMS. So is changing your URL structure from /blog/ to /insights/. So is a redesign that keeps every URL identical but rebuilds the templates underneath. Each of those is a migration in the way that matters to Google, because each one changes something Google has to crawl, render, and re-process.

Here's the mechanical reason it matters. When you move or restructure a site, Google has to reprocess your content under its new circumstances. Google's own Crawl Budget documentation, updated December 2025, puts it plainly: "Site-wide events like site moves may trigger an increase in crawl demand in order to reprocess the content under the new URLs." That recrawl is normal. It's also the window where things go wrong, because everything Google re-reads during that window is either set up to transfer your signals or set up to lose them.

A redesign is not automatically a migration in the narrow sense, and a migration is not always a redesign. Sometimes the look stays and the structure moves. Sometimes the look changes and the URLs don't. The trouble starts when you assume a project is "just a redesign" and skip the migration planning, when under the hood the URLs, the platform, and the templates are all changing at once.

The types of website migration

This is the part most checklists skip, and it's the part that actually tells you how much risk you're taking on. Different migration types break different things. Naming the type you're doing is the first real decision.

Domain or brand change. You move from one domain to another. Everything about your URLs changes at the hostname level. The main SEO risk is that authority, backlinks, and ranking history tied to the old domain don't carry over unless every URL is redirected and the move is signaled to Google.

HTTP to HTTPS. You move from an unsecured protocol to a secure one. The paths can stay identical, but every URL technically changes from http:// to https://. The main risk is accidental duplicate URLs, where Google sees both the http and https versions and has to pick a canonical on its own.

Replatform or CMS change. You move from one content system to another. URL patterns, page templates, and how content is rendered often all change together. The main risk is that the new platform silently resets metadata, alters URLs, or renders key content with JavaScript that's slower to index.

URL-structure change. You keep the same domain and platform but rewrite the URL paths. The main risk is the most direct one in SEO: every rewritten URL becomes a brand-new page to Google unless it's redirected, which means the backlinks and ranking history pointing at the old path evaporate.

Redesign (visual or template). You rebuild the look and the templates, sometimes keeping every URL. The main risk is quieter: titles, headings, structured data, internal links, and content depth get changed during the rebuild without anyone tracking what was lost.

Site consolidation or merge. You fold multiple sites or sections into one. The main risk is mapping. Many old URLs now have to point somewhere sensible, and the lazy move of sending them all to the homepage backfires.

Hosting move with no URL change. You change servers or hosting with the URLs left exactly as they are. The main risk is infrastructure-level: a staging block, a robots.txt rule, or a noindex tag riding along to production and quietly cutting Google off.

Migration type	What changes	Main SEO risk
Domain or brand change	The hostname on every URL	Authority and backlinks don't transfer unless every URL is redirected and the move is signaled to Google
HTTP to HTTPS	The protocol on every URL	Duplicate http and https versions Google has to canonicalize on its own
Replatform or CMS change	URL patterns, templates, rendering	New platform silently resets metadata, changes URLs, or hides content behind JavaScript
URL-structure change	The URL paths, same domain	Each rewritten URL becomes a new page; backlinks and ranking history are lost without redirects
Redesign (visual or template)	Templates, layout, sometimes content	Titles, headings, schema, links, and content depth quietly dropped during the rebuild
Site consolidation or merge	Multiple sites or sections combined	Bad URL mapping, especially redirecting many old URLs to the homepage
Hosting move, no URL change	Server or hosting, URLs unchanged	A staging noindex or robots.txt block surviving to production

Real migrations rarely come as a single clean type. A replatform usually drags a URL-structure change and a redesign along with it. That's exactly why Google's guidance is to change one thing at a time. When the domain, the CMS, and the layout all move on the same launch day and rankings drop, you have no way to isolate which change caused it.

The phases of a safe migration

I'm going to walk the phases at altitude, which means what each phase is, why it matters, and what breaks if you skip it. For the granular checklist and the exact questions to put to your dev team, that's the job of the step-by-step migration process post linked above. This section is the why, not the how.

Phase 1: Plan and baseline

Before you touch anything, record where you stand. Crawl the current site, capture the existing URLs, and note current rankings. Verify both the old and the new site in Search Console before you start. Skip this and you lose your reference point. When something drops later, you won't be able to tell what changed because you never wrote down what "before" looked like.

Phase 2: Inventory and URL mapping

Every old URL needs a defined new home. This is the spine of the whole migration. Skip it and URLs fall through the cracks, turning into 404s that strand the backlinks and ranking history they used to carry.

Phase 3: Redirects

This is where the mapping becomes real. Every changed URL gets a permanent redirect to its mapped destination. Use 301 redirects for permanent moves. The reassuring part, from Google: "Permanent redirects don't result in a loss of PageRank," per its site-move documentation. The mistake to avoid is redirecting a batch of unrelated old URLs to the homepage, which Google warns "may trigger soft 404 errors." A redirect only transfers signals if it points to the genuinely equivalent page. Pointing everything at the homepage throws those signals away.

Phase 4: Metadata and schema migration

Titles, H1s, meta descriptions, and structured data have to be carried over deliberately, not left to chance. A CMS change is the classic place these get silently reset. Title tags feed both how your result displays and how Google reads relevance. Schema feeds rich result eligibility. Lose them in the move and you can hold rankings for a beat, then watch click-through and visibility erode.

Phase 5: Staged crawl check before launch

Before the new site ships, crawl the staging build and check what's actually configured. The thing you're hunting for is a leftover staging block: a robots.txt Disallow or a noindex meta tag that protected the test environment and is about to ride along to production. Google's documentation is blunt that this kills crawling and indexing, and a robots.txt block can even stop Google from seeing a noindex rule at all. Catch it on staging and it's a one-line fix. Catch it after launch and you've already lost days or weeks of visibility.

Phase 6: Launch

The move goes live. Redirects are active, metadata is in place, the staging block is gone, sitemaps point at the new URLs. Expect some movement here; the next phase is about reading it correctly.

Phase 7: Monitor and recover

After launch, watch the recrawl. Google's documentation is direct: "Expect temporary fluctuation in site ranking during the move." Some wobble is normal and expected. What you're watching for is the difference between normal fluctuation and a sustained decline that signals a real problem. If it's the latter, that's a diagnosis job, and it routes to the recovery post.

What can break (and where to read about each)

When a migration costs you rankings, it's usually one of a short list of failures. Here's the risk map, with each failure routed to the post that covers it in depth.

Pages dropping out of Google's index. A staging noindex or robots.txt block that survives to production tells Google to stop crawling or indexing, and pages start falling out of the index within days to weeks. If you're seeing pages dropping out of Google's index after a launch, that post covers what causes deindexing and how to read it.

Orphan pages. A redesign that strips navigation or in-content links can leave important pages with no internal link pointing at them. Google has a harder time discovering them, and they lose the internal link equity that supported their rankings. More on orphan pages and how to find them in that post.

A brand-new site or section that won't index. Sometimes the move is clean but the new pages just sit there, not showing up in search. That's its own pattern with its own causes. If that's what you're seeing, why new websites don't show up in search is the one to read.

Rankings already gone and traffic down. If the move already happened and the decline is real and sustained, you're past prevention and into recovery. That's the diagnosis-and-fix post, linked at the top and again here.

SEO is GEO is AEO: the double consequence

One beat worth its own line, because it changes how I weigh migration risk now. A migration that blocks crawling doesn't just cost you organic rankings. It also makes your pages ineligible for AI answers. Google's AI optimization guide, updated June 2026, is explicit that generative AI features need content that's crawlable, indexed, and snippet-eligible. So a leftover robots.txt Disallow or a stray noindex isn't a single-channel problem anymore. The same root cause that drops you out of Google's blue links also drops you out of AI Overviews. One mistake, two losses. For CMM that's not two separate fixes. Search visibility and AI visibility are one job, and a botched migration threatens both at once.

How long does recovery take?

Honest expectation-setting here, because this is where people either panic too early or wait too long.

Google's site-move documentation, updated March 2026, gives the realistic frame: "A medium-sized website can take a few weeks for most pages to move in our index; larger sites can take longer." That same doc is clear on what to expect: "Expect temporary fluctuation in site ranking during the move." So some post-launch movement isn't a sign of failure. It's the recrawl doing its job.

There's also a duration rule for the redirects themselves. Google's guidance: "Keep the redirects for as long as possible, generally at least 1 year." Pulling them too soon undoes the signal transfer you set up.

The line I draw is this. Fluctuation in the first few weeks is normal, and a medium site needs that long for most pages to settle. A decline that keeps deepening over multiple weeks, with no sign of recovery, is not normal fluctuation. That's a signal to diagnose, and it routes to the recovery post. The trick is knowing which one you're looking at, and the honest answer is that a baseline taken in Phase 1 is what lets you tell the difference.

If you're planning a move, or you're staring at a launch date and a redesign that nobody has pressure-tested for search, that's the kind of question an engagement answers. Search and AI visibility are one discipline, not a bolt-on you handle after the new site is live. If you want to protect what you've built before you move it, let's talk.

A migration is a re-introduction of your site to search and AI. The whole job is making sure the introduction goes well enough that nothing you already earned gets left behind.