Migration9 min read

How to migrate a website without losing your rankings

Migrations that lose traffic are not unlucky. They almost always skipped the same two steps: a complete inventory of existing URLs, and an explicit decision for each one.

This is the checklist we work through on every migration, whatever the platform. It is not complicated. It is just unglamorous enough that cheap quotes leave it out, and you generally do not find out until three weeks after launch when the enquiries stop.

Before: build the URL inventory

Three sources, and you need all three because each misses something the others catch:

  • Search Console → Pages. Everything Google has indexed. Export the full list, not the first thousand rows.
  • Analytics. Every URL that received a visit in the last twelve months. Catches pages Google has not indexed but people reach through links or email.
  • A crawl of the live site. Screaming Frog or similar. Catches pages nobody visits and Google has not indexed, which you can then deliberately retire.

Combine and deduplicate. On a typical small business site this is a few hundred URLs. On a content site it can be thousands, and that number is the real driver of migration cost — not the page count of the new design.

Before: decide what happens to every URL

Every URL gets exactly one of three outcomes:

  • Kept identical. Best case. No redirect, no equity loss, nothing to go wrong.
  • 301 to a specific equivalent. A permanent redirect to the closest matching new page. Specific — the actual replacement, not a category page.
  • 410 Gone. For pages you are deliberately retiring with no equivalent. This tells Google it is intentional, and it drops cleanly instead of lingering as a soft 404.

The spreadsheet with these three columns is the migration plan. Everything else is implementation.

Never bulk-redirect old URLs to the homepage. Google treats a redirect to an irrelevant page as a soft 404, drops the page, and transfers nothing. It looks tidy in the redirect file and destroys the rankings you were trying to preserve.

Also before launch

Less dramatic, equally capable of causing damage:

  • Self-referencing canonicals on every new page. A canonical still pointing at the old domain or the staging URL will deindex the page.
  • Check the staging site is noindexed — and then check it is not still noindexed after launch. Shipping with `noindex` in the header is the fastest way to remove a site from Google, and it happens more often than anyone admits.
  • robots.txt must not block anything the old one allowed.
  • Structured data carried across. If the old pages had FAQ, Product or Article schema and the new ones do not, you lose whatever rich results they were earning.
  • Title tags and meta descriptions preserved where pages rank. A redesign is a bad moment to also rewrite every title, because if traffic drops you will not know which change caused it.
  • Internal links updated to point at new URLs directly, not through redirect chains.

Launch day

In order: deploy, then immediately spot-check ten to twenty of your highest-traffic URLs and confirm each returns 200 or lands on the right page through a single 301. Not a chain, not a 302.

Then submit the new XML sitemap in Search Console. Keep the old sitemap available for a few weeks — it gives Google a list of old URLs to recrawl and discover the redirects, which speeds up the transfer.

Use Search Console's URL Inspection on a handful of important pages and request indexing. It will not process thousands, but it gets the important ones looked at quickly.

The four weeks after

Expect a dip. A two to four week wobble while Google recrawls and reassesses is normal on any migration and is not a sign something is broken.

What to watch: the Coverage report for a spike in 404s — that means URLs you missed, and the report tells you exactly which. Rankings for your top twenty terms, tracked weekly rather than daily, because daily noise will make you panic. And Core Web Vitals field data, which takes 28 days to reflect the new site at all.

Keep the redirects. Permanently. They cost nothing and links to your old URLs will keep arriving for years. Removing them a year later to 'tidy up' is a self-inflicted traffic loss we have been called in to diagnose more than once.

Common questions

How long do rankings take to recover after a migration?

Two to four weeks for most sites, longer for large ones, assuming the redirects are correct. If traffic has not recovered after about six weeks, something is wrong — usually missed URLs or a canonical pointing at the old site — rather than Google being slow.

Should I redirect old URLs to the homepage?

No. Google treats a redirect to an irrelevant page as a soft 404 and transfers no authority. Redirect each URL to its closest genuine equivalent, and use a 410 for pages with no equivalent so the removal is read as deliberate.

Can I change my URL structure during a migration?

You can, and if the old structure is genuinely poor it is the right time. But every change is a redirect and every redirect is a small risk, so change only what is worth changing. Restructuring URLs purely for tidiness is a real cost for no return.

Do I need to keep the redirects forever?

Yes. They are cheap to keep and expensive to remove. External links to old URLs keep arriving for years, and every one of them relies on the redirect to reach a live page.

Want us to look at your site?

We will tell you whether the problem is hosting, plugins, architecture or something else entirely — including when the answer is that you should not rebuild and should spend the money on traffic instead. No charge for the assessment.

Run the free audit tool

Pricing: US clients (USD) · India clients (INR)

Related guides

All 21 guides