Website Migration SEO: How to Move Your Site Without Losing Rankings (Free Checker)

Published: 25 October 2026 | Last updated: 25 October 2026 | 20 min read

By Graeme Whiles

The new site looks brilliant.

Faster pages, a cleaner design, a platform the team actually likes using. Everyone signs off, the old site goes dark, and launch day passes without a single complaint.

Then the traffic graph starts to slide.

Not on day one. On day ten, and day twenty, and day forty, while everyone assumes Google is 'just adjusting'.

However, most of the time, Google isn't adjusting.

It's doing exactly what the redirect map told it to do.

In April 2026, I was brought in three weeks after REHAUS moved its Shopify store from rehaus.co.uk to rehaus.co. The site looked perfect. Behind it, 82% of its 5,270 redirects pointed at the dead domain, and 530 product URLs had changed with no redirects at all.

Nothing on the front end gave it away.

That's what makes migration SEO so expensive to get wrong.

In this guide, I'll show you what counts as a website migration, why migrations lose rankings, the checklist I use before, during and after launch, how to build a redirect map that holds up, how long recovery really takes, and what changes now that AI search tools are reading your site too. There's also a free redirect map checker that finds chains, loops, homepage dumps and staging links in your map before launch day.

Short on time? Here are the key takeaways

• Most migrations fail in the redirect map: missing redirects, redirects to the homepage and chains of redirects lose more rankings than anything that happens on launch day.
• Redirect one to one: every old URL that has traffic, links or rankings should 301 to its closest equivalent. Google says pages with no replacement should return a 404, not redirect to the homepage.
• Change one big thing at a time: a new domain, a new platform and a new URL structure in the same week makes problems far harder to find and fix.
• Keep content parity: titles, headings, body copy, internal links and structured data should move across intact. A migration is not the moment to rewrite everything.
• Expect a wobble, not a collapse: Google says rankings can fluctuate temporarily during a move, and a small to medium site can take a few weeks for most pages to move. A steep, lasting drop means something is broken.
• Check your map before launch: the free redirect map checker below flags the mistakes I see most often, and gives you a cleaned map and server rules to go with it.

What is a website migration?

First, let me explain what I mean by the term, because 'migration' gets used for everything from a new logo to a new domain.

In SEO, a website migration is any change to a site's domain, platform, URL structure, content or design that's big enough to change how search engines find, read or rank it.

An SEO migration is simply a migration where somebody has planned for that.

The test I use is simple.

If the change alters a URL, the content on a page, the links between pages or what a crawler can see, it's a migration, and it needs an SEO plan.

Types of website migration, and how risky each one is

Not every migration carries the same risk. Here are the ones I see most, from the safest to the riskiest.

A platform change almost always becomes a URL restructure too.

Shopify, for example, forces /products/ and /collections/ into its URLs, so a move from WordPress or Magento changes nearly every address on the site. My guide to Shopify migration SEO covers the Shopify-specific steps.

Does a website migration affect SEO?

Yes, every time.

The question is whether the effect is a short wobble or a long decline.

Google is open about the wobble. Its own guide to site moves with URL changes tells you to expect temporary fluctuation in rankings while it recrawls and reindexes the site, and says rankings settle down over time.

A long decline is different.

It almost always means Google has been told, through redirects, content or technical signals, that the old pages have gone and nothing equivalent has replaced them.

Why website migrations lose rankings

When I'm called in after a migration, the cause is nearly always one of five leaks.

• Redirects that are missing or wrong: old URLs that 404, redirect to the homepage, redirect through chains, or use temporary 302s. This is the big one.
• Content that changed in the move: new templates that drop paragraphs, headings, FAQs or product details, so the new page is thinner than the one it replaced.
• Internal links and structure that broke: navigation, breadcrumbs and in-content links that still point at old URLs, or important pages that end up buried several clicks deeper.
• Technical blocks: a noindex tag or robots.txt rule left over from staging, canonical tags pointing at the old domain, or content that only appears after JavaScript runs.
• Signals that reset: on a domain change, Google has to connect the new domain to everything the old one earned. That only works if the redirects, Change of Address and external references all line up.

The REHAUS migration, which I cover in full in the REHAUS case study, hit three of these at once.

The DNS for the old domain had never been updated, so redirects that everyone assumed were firing simply weren't. The old domain was connected to Shopify as a redirect domain, which sent every historical URL to the homepage. And 530 product URLs had switched from numeric IDs to descriptive slugs before the move, with no redirects at all.

Sixteen months of search history, including 42,593 clicks across the old site's top pages, was draining into a dead end.

Before you migrate: the pre-launch checklist

Almost everything that decides whether a migration works happens before launch day.

Here's the order I work in.

1. Decide what's changing, and don't change everything at once

Write down exactly what this migration changes: the domain, the platform, the URLs, the design, the content, or several of those.

Then try to remove some of them.

Every extra change makes it harder to work out what went wrong if traffic drops. If you can move platform first and rebrand the domain three months later, do it. If you can keep the URLs the same on the new platform, that's the single biggest risk you'll remove.

Google makes a similar point about scale. For small and medium sites, it recommends moving all URLs at the same time rather than section by section. For large sites, moving one section first can be a useful test, although Google notes one section isn't fully representative of a whole-site move.

2. Benchmark everything

You can't prove a migration worked, or diagnose one that didn't, without a baseline.

Before anything changes, save:

• Search Console performance: clicks, impressions, CTR and average position by page and by query, for at least the last 12 months. Export it, because the old property's data won't help you much once the domain changes.
• Analytics: organic sessions, conversions and revenue by landing page in GA4.
• Rankings: positions for your most valuable keywords, tracked daily from a few weeks before launch.
• A full crawl: every URL with its status code, title, meta description, H1, canonical and word count. Keep this file forever. It's the only record of the old site you'll have once it's gone.
• Backlinks: the pages other sites link to, from Ahrefs, Semrush or Search Console's Links report. These carry your authority.
• Indexing: how many pages Search Console says are indexed.

3. Build the URL inventory

The redirect map can only be as complete as the list of old URLs behind it.

A crawl alone won't find everything. Pages that aren't linked internally, old campaign URLs, PDFs and pages with backlinks from years ago often don't show up in a crawl.

So I combine several sources: a crawl of the live site, the XML sitemaps, every URL with impressions in Search Console, every landing page in analytics, every page with backlinks, and, on bigger sites, server log files. De-duplicate the list, and you have the inventory.

4. Map every URL that matters

This is the heart of migration SEO.

For every old URL, decide where it goes. The rules are simple, and they're the ones most migrations break.

• Redirect one to one: each old URL goes to its direct replacement. Not to a category, and not to the homepage.
• Use permanent redirects: Google recommends permanent server-side redirects (301 or 308) for a site move. Temporary redirects (302 or 307) tell Google the old URL may come back.
• Go straight to the final URL: Google advises redirecting to the final destination rather than through a chain, and keeping any unavoidable chain short. Its crawlers follow up to 10 redirect hops, but every hop slows the page down for users too.
• Let dead pages die properly: if a page has no replacement and nothing closely related, Google's help page on 404 errors says returning a 404 is the right thing to do, and advises against redirecting missing pages to the homepage.
• Don't fake relevance: redirecting lots of unrelated pages to one category or to the homepage doesn't save their value. Glenn Gabe documented redirects to less relevant pages being treated as soft 404s, and I saw the same thing at REHAUS.
• Use pattern rules carefully: rules that redirect a whole folder in one line save time on big sites, but test them against your full URL list, because one wrong pattern can redirect thousands of pages to the wrong place.

Chains also build up quietly after a migration, as each redesign adds another layer. At 6sense, links from other sites to high-value pages were landing on 301 redirect chains that ended at irrelevant pages, so the authority those links should have passed on was being diluted. The 6sense case study shows how we fixed it.

At REHAUS, rebuilding the 530 missing product redirects meant matching old numeric URLs to new slugs through Shopify product IDs, because the slugs no longer matched anything. It took roughly 7,000 spreadsheet checks.

That's the unglamorous reality of a redirect map.

It's also where the free checker further down earns its place.

5. Keep content parity

Content parity means the new version of each page says at least as much as the old one did.

It's the leak I see most after redesigns, because nobody thinks of a new template as an SEO change.

Check that each important page keeps its title tag, meta description, H1, body copy, FAQs, images and alt text, internal links, structured data, canonical tag and, on international sites, its hreflang tags. If you want to improve the content, do it after the migration has settled, so you can tell the two effects apart.

My on-page SEO checklist is a useful way to compare old and new templates side by side, and my free schema markup generator helps rebuild any structured data the new templates dropped.

6. Test the new site on staging

Your staging site needs to be hidden from search engines and open to your crawler.

Password protection does both. A robots.txt block or noindex tag on staging works too. However, they're exactly the settings that get copied to the live site by accident, so they go on the launch-day checklist.

Then crawl staging and compare it with the crawl of the old site: status codes, titles, headings, word counts, internal links, canonicals and structured data. If your new site is built on a JavaScript framework, view the page source as well as the rendered page, because some crawlers only read the raw HTML.

Free redirect map checker

I built this checker because the same handful of mistakes turns up in almost every redirect map I review.

Paste in your old and new URLs, straight from a spreadsheet if you like. It checks every line for conflicting redirects, loops, chains, homepage redirects, temporary redirects, staging and test domains, http targets, tracking parameters and a few other things that cause trouble after launch.

Then it gives you a cleaned map with chains flattened and duplicates removed, plus the server rules for Apache, Nginx, Shopify or Netlify.

It runs in your browser.

Nothing you paste is sent anywhere.

Press 'Load example' to try it with a made-up agency rebrand that has the mistakes I see most often.

How to use the results

Fix everything marked 'Fix before launch' first. Those are the redirects that will actively break pages or send users and search engines in circles.

'Worth fixing' items won't break the site, but each one leaks a little value. Homepage redirects matter most here. If more than a handful of your important pages end up on the homepage, stop and map them properly.

Then remember what the checker can't see.

It checks the map itself, not whether your server is actually returning those redirects. After launch, crawl your list of old URLs and confirm every one returns a single 301 to a page that loads.

Launch day checklist

Launch day should be boring.

If the preparation is right, it mostly is. Here's what I check, in this order.

• Staging blocks are gone: no noindex tags, no robots.txt rules blocking the site and no password protection on the live domain.
• Redirects are live: test a sample of old URLs from every section, including your top pages by traffic and by backlinks. Each should return one 301 to the right page.
• Canonicals and hreflang point at the new URLs: not the old domain, and not staging. My free hreflang generator helps if you need to rebuild them.
• Internal links point straight at new URLs: navigation, footers, breadcrumbs and links in content shouldn't rely on redirects. My guide to internal linking strategy covers how to audit them.
• A new XML sitemap is submitted: submit it in Search Console and Bing Webmaster Tools. Google notes that submitting a sitemap can make discovery of the new URLs quicker.
• Change of Address is filed (domain moves only): Search Console's Change of Address tool is only for moving from one domain or subdomain to another, and you need to own both properties. You don't need it for an HTTP to HTTPS move.
• Tracking works: GA4, conversion tags and any CRM forms fire on the new site, and there's an annotation for the launch date.
• External profiles are updated: Google Business Profile, social profiles, review sites, directories and your most valuable backlinks, where you can reach the site owner.

After launch: the first 90 days

The work doesn't stop when the new site goes live.

The first fortnight is when you catch the problems that are cheap to fix. Leave them for three months and they're expensive.

• Days 1 to 14: crawl your full list of old URLs every few days. Watch Search Console's Page indexing report for spikes in 404s, soft 404s and 'Redirect error', and check Crawl stats for server errors.
• Weeks 2 to 6: compare clicks and impressions for your top 50 pages against the benchmark, one by one. Averages hide the pages that have fallen off a cliff. My guide to SEO reporting shows how to annotate the launch so the expected dip doesn't cause panic.
• Months 1 to 3: track rankings for your priority keywords and watch for pages where the old URL is still indexed instead of the new one. Fix broken backlinks to old URLs that were missed in the map.
• Month 12 and beyond: keep the redirects in place. Google recommends keeping them for as long as possible, and generally at least a year. Keep the old domain registered too, so nobody else can buy it.

Once the REHAUS chain was repaired, average position moved from 24.2 to 10.7, and monthly impressions went from 37,123 in April to 218,042 in July. The REHAUS case study covers the full rebuild, phase by phase.

How long does it take to recover from a website migration?

For a clean migration, Google says a small to medium site can take a few weeks for most pages to move, and larger sites take longer.

In my experience, that's about right for a well-planned move. Expect a dip in the first few weeks, then a return to the benchmark.

A failed migration is different.

If the redirects were wrong, recovery starts the day they're fixed, not the day you launched. That's why REHAUS took months rather than weeks, and why the Change of Address window matters: Google says the tool's actions continue for 180 days after you start the move.

Website migrations and AI search

This is the part almost every migration checklist still leaves out.

Your site isn't only read by Googlebot any more. ChatGPT, Perplexity, Claude and Google's AI features all read and cite web pages, and a migration can quietly cut you off from them.

• Keep your content in the raw HTML: when Vercel analysed crawler traffic, it found none of the major AI crawlers rendered JavaScript. Move to a JavaScript-heavy front end without server-side rendering, and AI tools may see empty pages. At Practice Better, a CSS implementation issue left 86% of the blog hidden from AI crawlers, so template changes matter too.
• Allow AI search crawlers: OpenAI's crawler documentation says sites that block OAI-SearchBot won't be shown in ChatGPT search answers, and recommends allowing it in robots.txt. Check the new robots.txt doesn't block it by accident.
• Don't forget Bing: OpenAI says ChatGPT search may share queries with third-party search providers such as Bing. Verify the new site in Bing Webmaster Tools, submit the sitemap, and use IndexNow, which Bing supports, to tell it about changed URLs quickly.
• Carry over llms.txt and structured data: if your old site had an llms.txt file or Organization schema, make sure the new site does too, with the new URLs. My guide to llms.txt on Shopify covers the file itself.
• Update the profiles AI tools learn from: on a domain change, update your LinkedIn page, review sites, directories and Wikipedia or Wikidata entries, so AI tools connect your brand to the new domain.

The upside is real.

Once the REHAUS migration was fixed and the AI layer was rebuilt, with an llms.txt file, clean schema and consistent brand information, ChatGPT started naming it the best overall place to buy second-hand designer furniture. My guide to ranking in ChatGPT covers how that works, and an AI visibility audit shows where you stand before and after a move.

Platform-specific notes

The principles are the same everywhere. The mechanics change by platform.

• Shopify: URL redirects only work for URLs that return a 404 on Shopify, and you can import them in bulk from a CSV. The /products/ and /collections/ prefixes can't be removed, so plan for nearly every URL to change. My guides to Shopify migration SEO and Shopify site structure go deeper.
• WordPress: redirects can live in the server config, a plugin or the hosting dashboard. Pick one place and keep them all there, because rules split across several places are how chains and conflicts creep in.
• Headless and JavaScript frameworks: make sure pages are server-rendered or pre-rendered, and that redirects happen on the server rather than in JavaScript. Google's redirects guide recommends JavaScript redirects only when server-side or meta refresh redirects aren't possible.
• Site mergers: decide which site's URLs win before you map anything, and watch for two old pages competing to redirect to the same new one. That's often keyword cannibalisation waiting to happen.

Common website migration mistakes

• Treating SEO as a launch-week task: by launch week, the URL structure, templates and content decisions have already been made.
• Redirecting everything to the homepage: the fastest way to tell Google that hundreds of pages have been deleted.
• Leaving the staging noindex in place: I check this first on every post-migration audit, because it's so common.
• Using 302s because they were the default: some platforms and plugins create temporary redirects unless you change the setting.
• Forgetting the old domain's DNS: if the old domain doesn't resolve, none of its redirects fire, however good the map is.
• Changing content and URLs at the same time: if traffic drops, you won't know which change caused it.
• Removing redirects after a few months: backlinks, bookmarks and old emails keep sending people to old URLs for years.
• Not keeping the old crawl: without it, you can't rebuild a missed redirect once the old site is gone.

Should you get help with a website migration?

A small site moving to HTTPS, or a redesign that keeps every URL, is very manageable in-house with this checklist and the checker above.

Bring in specialist help when the stakes are higher: a domain change, a platform change on a site with years of organic traffic, a site merger, or any migration where organic search drives a big share of revenue.

And bring them in early.

The most useful hour of migration SEO happens before anyone builds a template, not the week after launch. If you're not sure where your site stands now, my technical SEO audit checklist is the place to start.

Final Thoughts

A website migration is one of the few SEO projects where you can lose years of work in a week.

It's also one of the most predictable.

Build the inventory, benchmark everything, map every URL that matters one to one, keep the content intact, and test the redirects rather than assume them. Then watch the old URLs closely for the first few weeks, and keep the redirects in place for years, not months.

The migrations that hold their rankings aren't the ones with the best new design. They're the ones where someone checked every old URL had somewhere sensible to go.

That's work I do for businesses across the UK from my base in Leeds, from pre-launch redirect maps to rescuing migrations that have already gone wrong, and my SEO migration services page sets out exactly what's included. Start with a free SEO audit, read the REHAUS case study, or look at my technical SEO audit if you'd like a full review before you move.

Get in touch and tell me what you're moving, and when.

Author Bio

Graeme Whiles is an independent SEO and AEO consultant at GWContent. He has worked with enterprise and SaaS brands, including Originality.ai, Connecteam, 6sense, Practice Better, and Peppr, growing organic traffic and AI search visibility across some of the most competitive categories in B2B. He also built Three Putt Golf Clothing from a blank domain as a live proof of concept for his methodology.

Website Migration SEO Frequently Asked Questions

Does a website migration affect SEO?

Yes. Google says rankings can fluctuate temporarily while it recrawls and reindexes a site after a move. A well-planned migration usually recovers within weeks. A migration with missing redirects, redirects to the homepage or lost content can cause a long decline, because Google treats the old pages as gone with nothing equivalent to replace them.

How long does it take to recover after a website migration?

Google says a small to medium site can take a few weeks for most pages to move, and larger sites take longer. If the migration went wrong, recovery starts when the problems are fixed rather than on launch day, which can mean several months. REHAUS took four months to go from a failed migration to 5.9 times the monthly impressions.

How long should I keep 301 redirects after a migration?

Google recommends keeping redirects for as long as possible, and generally at least a year. For domain moves, the Change of Address tool's actions last 180 days, but backlinks, bookmarks and old emails keep sending people to old URLs for years, so there's rarely a good reason to remove redirects at all.

Should I redirect deleted pages to the homepage?

No. Google advises against redirecting missing pages to the homepage, and says returning a 404 is right for pages with no replacement. Redirect a deleted page only if a genuinely equivalent or closely related page exists. Redirects to irrelevant pages are often treated as soft 404s, so they don't pass on the old page's value anyway.

What is a redirect map?

A redirect map is a spreadsheet that lists every old URL on a site and the new URL it should redirect to after a migration, usually with the redirect type. It's built before launch from a crawl, sitemaps, Search Console, analytics and backlink data, and it's the single most important document in a website migration.

Do I need to use the Change of Address tool?

Only when moving from one domain or subdomain to another, such as .co.uk to .com. You don't need it for an HTTP to HTTPS move or for switching between www and non-www. You need to own both properties in Search Console and have a 301 redirect from the old homepage to the new one in place first.

Should I redesign and migrate my website at the same time?

Avoid it if you can. Every extra change makes it harder to work out what caused a traffic drop. If you have to do both, keep URLs and content as close to the old site as possible, and save content improvements for a few months after launch, once rankings have settled against your benchmark.

What's the difference between a 301 and a 302 redirect?

A 301 is a permanent redirect, which tells Google the page has moved for good and the new URL should be treated as the main version. A 302 is temporary, so Google may keep the old URL in its index. Use 301 or 308 redirects for a website migration.

What should be on a website migration checklist?

Before launch: decide what's changing, benchmark performance, build a full URL inventory, map redirects one to one, check content parity and test on staging. On launch day: remove staging blocks, test redirects, update canonicals and submit sitemaps. After launch: crawl old URLs, watch Search Console and keep redirects for at least a year.