How to Migrate a Site Without Losing Rankings

Site migrations are where good rankings go to die. A redesign, a platform switch, a domain change, an HTTP-to-HTTPS move — each is a chance to accidentally throw away years of accumulated SEO equity in a single afternoon. The traffic drop usually shows up two weeks later, once everyone has moved on and nobody connects the dots.

It doesn’t have to be that way. Migrations are risky, but the risk is almost entirely manageable. Here’s the playbook we follow — and, at the end, what to do if you’re reading this after the fact.

First, know which migration you’re actually doing

“Migration” covers five quite different jobs, and the risk profile of each is not the same:

• Domain change — the highest risk. Every URL changes, and you’re asking Google to move authority from one hostname to another.
• Replatform — new CMS or e-commerce system, same domain. Risk depends entirely on whether the new platform forces a new URL structure.
• Redesign — new templates, same URLs and same content. Usually the safest, until someone quietly drops half the copy for aesthetic reasons.
• URL restructure — same site, new information architecture. Medium risk, and the one most often done without a plan.
• HTTP to HTTPS — technically a migration, and still worth a redirect map, though it’s the most forgiving of the five.

Plenty of projects are two or three of these at once. That’s fine, but do the accounting: a replatform and a domain change and a content rewrite is three risks stacked, and if traffic drops you won’t know which one caused it. Where you can, separate them by a few weeks.

What actually transfers — and what doesn’t

People ask whether you can “transfer SEO” as though it were a file. You can’t, but you can preserve nearly all of it, because what makes a page rank is mostly attached to things you control.

Transfers cleanly, if you redirect properly: the authority of links pointing at old URLs, the relevance signals from the content itself, your internal linking structure, and your history of satisfying searchers for a given query.

Does not transfer: anything you delete. Cut a page and its rankings go with it, redirect or not. Google gives a 301 the benefit of the doubt only when the destination genuinely covers the same ground — redirecting a detailed guide to a thin category page is treated as a soft 404, and you lose the lot.

Transfers slowly: trust in a brand-new domain. A domain change carries your links over, but a hostname with no history takes time to be treated as an equal.

Preserve URLs whenever you can

The single best redirect is the one you never have to write. Before anything else, ask a blunt question: does this URL actually need to change? Often the answer is no, and the whole project gets safer.

If you’re changing platform or design but the content is staying, fight to keep the existing URL structure. Every URL you preserve is one less redirect to map, one less chance of a chain, one less thing to break. Only change URLs where there’s a real reason — a genuinely better structure, a language path, a consolidation.

When URLs must change, map every old URL to its closest new equivalent. Not the homepage — the closest matching page. A lazy blanket redirect to / is one of the fastest ways to lose rankings, because Google treats it as a soft 404 and drops the old page’s authority entirely.

Build the redirect map before launch

Export a full list of your current indexed URLs — from your sitemap, your analytics, and a crawl of the live site. Add anything with backlinks, even if it’s been dead for years: those are the URLs that carry the most value and the ones nobody remembers. That combined list is your source of truth. For each URL, decide its fate:

• Stays the same → nothing to do.
• Moves → 301 redirect to the new URL.
• Gone for good → let it 404 (or 410) deliberately, don’t fake it.

Use 301 (permanent) redirects, not 302s — a 302 tells Google the move is temporary and it hangs on to the old URL. Avoid redirect chains (A → B → C); point every old URL straight to its final destination. And double-check you’re not redirecting into pages that are themselves blocked or noindexed.

A migration is only as good as its redirect map. Everything else is detail.

Run pre-launch checks on staging

Never discover problems in production. On the staging site, verify the things that silently kill migrations:

• Indexability — make sure the staging noindex and robots.txt disallow rules are removed at launch. Shipping a site that tells Google “don’t index me” is the classic catastrophic mistake.
• Canonicals and hreflang — confirm they point to the new URLs, not the staging domain or the old site, and that they match the URL the server actually serves. A canonical pointing at a URL that redirects splits your signals between two versions of the same page.
• Metadata and structured data — titles, descriptions and schema should carry over, not reset to defaults.
• Content parity — compare word counts page by page. Redesigns lose content silently, and a page that ranked on 1,200 words won’t hold its position on 400.
• Internal links — update them to point at the new URLs directly, so you’re not relying on redirects internally. This is where solid technical foundations built in from day one pay off.

Crawl the staging site with a tool like Screaming Frog and compare it against the old one, page for page.

Monitor obsessively after go-live

The work isn’t done at launch — that’s when it starts. In the first hours, crawl the live site and check that redirects resolve in a single hop and return 200s at the destination. Submit the new sitemap in Google Search Console, keep the old property verified if the domain changed, and use the Change of Address tool. Watch Coverage and Crawl Stats for spikes in errors.

The most useful report in the first month is Search Console’s page-level comparison: put the four weeks after launch against the four weeks before, sorted by lost impressions. The pages at the top of that list are your redirect map’s holes, ranked by how much they cost you.

The dip: how big, how long, when to worry

Some drop is normal. Google has to re-crawl everything, follow every redirect and re-evaluate every page, and on a large site that takes weeks. What’s normal looks like this:

• A dip of 10–20% for two to four weeks, recovering steadily. On a same-domain replatform with URLs preserved, often barely noticeable.
• A domain change takes longer — expect six to eight weeks before things settle, sometimes more on large sites.

What is not normal: a fall of more than half, a drop that keeps getting worse after three weeks, or pages disappearing from the index entirely. Those aren’t Google being slow. Those are bugs.

The tell is in the pattern. Traffic that declines gradually and recovers is re-processing. Traffic that falls off a cliff on launch day and stays flat is a technical fault — usually a noindex left on, a robots.txt blocking the site, or redirects that don’t resolve.

Rescuing a migration that already went wrong

If you’re reading this after a bad launch, work through it in this order. Resist the urge to change things at random — that makes the diagnosis harder.

1. Check indexability first. Fetch the live site as Google sees it and look for noindex, a blocking robots.txt, or an accidental Disallow: /. This is the single most common cause and the fastest fix.
2. Test the redirects properly. Take the top 100 old URLs by past traffic and request each one. You’re looking for 404s, chains, loops, and redirects landing somewhere generic. Every one of those is lost equity.
3. Find the orphans. Compare your old URL list against what’s actually being redirected. The URLs that appear in the first list and nowhere in the second are your holes.
4. Check content parity on your best pages. If a page that ranked well came out of the redesign with a third of its content, that’s why it dropped — and no redirect will fix it.
5. Then wait. Once the faults are genuinely fixed, recovery takes weeks, not days. Making further changes while you wait only muddies the signal.

Most migrations that “failed” didn’t fail mysteriously. They failed for one of those five reasons, and all five are fixable.

Migrations reward the meticulous. If you’re planning a replatform, a redesign or a domain move — or trying to recover from one — that’s exactly the kind of website development work we do. Request a free audit and we’ll pressure-test the plan before anything ships.