Site Migrations Without Losing Your Rankings

The most dangerous project in marketing

A site migration is the single highest-risk thing most marketing teams will do all year, and almost nobody treats it that way. A replatform, a redesign, a domain change, or an HTTPS move touches every URL, every redirect, every signal a search engine has spent years learning about you. Done well, nobody notices. Done badly, you wake up to a traffic chart that fell off a cliff and a CEO asking why.

Site migration SEO is the discipline of moving a site without bleeding the organic equity you built. I have steered migrations on large, revenue-critical properties, and the lesson is always the same: the teams that lose rankings did not get unlucky, they skipped steps. This is the playbook that protects you, and the good news is that none of it requires genius. It requires a checklist and the discipline to actually run it.

Why migrations bleed rankings in the first place

To protect equity, you have to understand what equity even is in this context. Search engines associate signals (links, relevance, history, trust) with specific URLs. A migration is, at its core, the act of telling those engines that the signals attached to old URLs should now apply to new ones. Rankings drop when that handoff is incomplete or unclear.

The usual failure modes:

• Broken or missing redirects. Old URLs return 404s instead of redirecting, and the equity attached to them evaporates.
• Redirect chains and loops. Equity leaks through multi-hop redirects, or worse, circular ones that resolve to nothing.
• Mapping gaps. Pages that had value on the old site have no clear home on the new one, so their signals have nowhere to go.
• Changed content and structure. The new page is so different that the engine no longer sees it as relevant to the queries the old one ranked for.
• Blocked crawling. A staging robots.txt or noindex tag survives the launch and quietly delists the whole site.

Every one of these is preventable. Most migrations that fail, fail on the first three.

The four phases of a safe migration

I run every migration in four phases. Skip a phase and you are gambling.

Phase one: benchmark everything before you touch anything

You cannot prove you held rankings if you never recorded where they were. Before any change goes live:

• Crawl the entire current site and export every indexable URL. This is your source of truth for the mapping.
• Pull your top pages by organic traffic, rankings, and links. These are the URLs that matter most; they get the most scrutiny in mapping and testing.
• Record current performance baselines: organic sessions, rankings for your priority terms, indexed page count, Core Web Vitals, and conversions. You will compare against these obsessively after launch.
• Export your backlink profile. The pages that earned the most links are the ones whose redirects you absolutely cannot get wrong.

This is also the moment to be ruthless about what should not migrate at all. A migration is the perfect time to prune dead weight, as I argue in the case for content pruning to grow traffic. Do not carry forward pages that add nothing; just make a deliberate decision about each one rather than losing them by accident.

Phase two: map old URLs to new ones, one to one

The redirect map is the heart of the whole project. Every old URL needs a defined destination on the new site.

• Aim for one-to-one, like-for-like redirects. The new destination should be the closest equivalent in content and intent, not just the homepage. Redirecting everything to the homepage is the classic equity-killing shortcut.
• Use permanent 301 redirects, not 302s or JavaScript redirects, so engines transfer signals fully.
• Eliminate chains. Redirect old URLs directly to the final new URL in one hop. If you are also changing protocol or domain, collapse it all into a single redirect.
• Handle the orphans deliberately. For old pages with no obvious equivalent, decide consciously: redirect to the most relevant parent, or let it 404 if it truly has no value and no links.

Have a second person review the map against the top-pages and top-links exports from phase one. The expensive mistakes hide in the long tail you stopped checking.

Phase three: preserve the on-page and technical signals

Redirects move equity to the new URL, but the new page still has to earn its keep. Carry the signals forward:

• Preserve titles, headings, and core content on priority pages. If you are also rewriting content, do it as a separate change after the migration stabilizes, not on the same day. Change one variable at a time.
• Migrate metadata, canonical tags, and structured data. Schema in particular is easy to drop in a replatform; it is your translation layer for machines, as I cover in why schema markup is the translation layer, and losing it makes you harder to read and cite.
• Rebuild internal linking intentionally. Internal links are how authority flows and how structure is signaled; treat them as a growth lever during the rebuild, not an afterthought, the way I describe in the piece on internal linking as a growth lever.
• Keep your XML sitemaps current for both the old and new URL sets so engines discover the changes fast.

Phase four: launch, verify, and watch like a hawk

Launch is not the finish line. It is the start of the most important week.

• Pre-launch on staging: confirm robots.txt allows crawling, no stray noindex tags survive, redirects resolve correctly, and the site renders for crawlers.
• At launch: submit the new sitemaps, monitor server logs to confirm crawlers are finding and following redirects, and spot-check your priority URLs by hand.
• In the first days: watch crawl stats, index coverage, and 404 reports. Fix broken redirects within hours, not weeks. The faster engines re-crawl clean signals, the smaller the dip.
• Over the first weeks: compare against your phase-one baselines. Expect a short, shallow wobble even on a clean migration. Expect, and act on, anything deeper.

The migration readiness checklist

Before anyone clicks deploy, every one of these should be a confident yes:

• Full crawl and URL inventory of the current site, exported and saved.
• Performance, ranking, and backlink baselines recorded.
• A complete, peer-reviewed one-to-one redirect map using 301s with no chains.
• Titles, content, metadata, canonicals, and schema preserved on priority pages.
• Internal links and navigation rebuilt deliberately.
• Staging verified for crawlability with no leftover noindex or blocking rules.
• New and old XML sitemaps ready to submit.
• A monitoring plan and an owner assigned for the first 30 days.

If a migration is happening on a fixed deadline and any of these is not ready, that is the conversation to have with leadership before launch, not after the traffic drops.

What "success" actually looks like

A well-run migration does not produce a triumphant traffic spike. It produces a non-event: a brief, shallow dip that recovers within a few weeks as engines re-crawl and re-attribute signals. That flatness is the win. The goal was never to gain from the move itself; it was to carry everything you built across the gap intact, so you can get back to growing.

This is also why migrations are worth treating as part of a broader technical foundation rather than a one-off fire drill. The same discipline that protects a migration, clean redirects, valid schema, deliberate architecture, is what keeps a site healthy and retrievable the rest of the year, including for AI engines, as I discuss in the generative engine optimization playbook.

Numbers over noise, honest over hype: a migration is the one project where the best outcome is that nobody can tell it happened. Plan it like the high-stakes operation it is, run the checklist without shortcuts, and you keep everything you earned.

I write one of these every week, working through what actually moves the numbers in modern marketing. If you have a migration on the horizon and want a second set of eyes before launch, the channel is open by introduction.