Site Migration SEO Guide 2026
How to Move a Website Without Losing Rankings

1. What Counts as a Site Migration

People use "migration" for everything from a hosting switch to a full rebrand. For SEO purposes, the question that matters is simple: will any URL change, and will what search engines see on those URLs change? The answer decides how much can go wrong.

Risk doesn't add up neatly when you stack these. It multiplies. A new domain plus a new CMS plus a new URL structure plus a redesign gives you four sets of variables, and if traffic drops you won't know which one caused it.

When the business allows it, I push to split the work. Move the platform first on the same URLs, let it settle, then change the structure. It's slower on paper and nearly always faster to recover from.

2. Why Site Migrations Lose Traffic

Google has said for years that 30x redirects don't lose PageRank. So a clean migration shouldn't cost you anything long term. When one does, the cause is almost always on this list.

That last row deserves a moment. I've seen teams spend a week investigating a "60% traffic drop" that turned out to be a missing analytics tag. Search Console clicks were flat the whole time. Always confirm a drop in Search Console before you start debugging the migration itself.

3. Phase 1: Planning and Benchmarks

Most of the work that decides a migration's outcome happens weeks before launch. This phase is about knowing exactly what you have, so you can prove afterwards that you still have it.

Pick the timing deliberately

Every migration causes some turbulence, so launch when a temporary dip costs the least. For most businesses that means avoiding peak season, big campaigns and the end of a financial quarter. Avoid Friday launches too. If something breaks, you want developers around the next morning, not on Monday.

Also check Google's recent update history before you commit to a date. Launching in the middle of a core update makes it very hard to separate migration effects from algorithm effects. The algorithm updates guide covers how to read those overlaps.

Crawl the current site, all of it

Run a full crawl of the live site and save it. You'll use this crawl as the source of truth for URL mapping and for comparing titles, meta descriptions, headings, canonicals, schema and internal link counts after launch.

A crawler only finds what's linked, though. Orphan pages, old campaign landing pages and URLs that live only in backlinks won't show up. Pull extra URL lists from other sources and merge them in.

Export performance baselines

Before launch, save exports you can compare against. Once the migration is live, some of this data becomes harder to pull cleanly, especially on a domain move where the old Search Console property stops accumulating data.

• Search Console: clicks, impressions and average position by page and by query, for the last 16 months
• GA4: organic sessions, conversions and revenue by landing page
• Rankings: positions for your priority keywords, recorded on a fixed date
• Core Web Vitals: field data from CrUX or your real-user monitoring, by template
• Indexing: the count of indexed pages and the main exclusion reasons
• AI visibility: a snapshot of where your pages are cited in AI answers for your core topics

Rank your URLs by value

Not every URL deserves the same attention. Tag each one by organic clicks, conversions and referring domains. The top 10 to 20% usually carries most of the value, and those pages get manual review at every stage. The long tail gets pattern-based rules and spot checks.

4. Phase 2: URL Mapping and Redirects

This is the core of any migration with URL changes. The rule is short: every old URL with value goes to the single new URL that best replaces it, with a permanent redirect, in one hop.

Build the map as a spreadsheet first

Don't write redirect rules straight into server config. Build the map somewhere the whole team can review it, and only turn it into rules once it's signed off.

Rules I don't bend

What the rules look like

Pattern rules handle predictable changes, like a folder rename. One-to-one rules handle everything else. Here's the shape of both on Nginx and Apache:

# Folder rename: /blog/post-name → /guides/post-name
location ~ ^/blog/(.*)$ {
    return 301 https://www.example.com/guides/$1;
}

# One-to-one map for everything else
map $request_uri $migrate_to {
    /old-services.html   /services/;
    /about-us.php        /about/;
}
if ($migrate_to) {
    return 301 https://www.example.com$migrate_to;
}

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://www.new-domain.com/$1 [R=301,L]

These are starting points, not copy-paste config. Put one-to-one rules before broad pattern rules so specific matches win, and test the full map before launch rather than trusting rule order.

5. Phase 3: Staging and Pre-Launch QA

Staging is where you find problems while they're still cheap. It's also where one of the most damaging migration bugs gets created.

Protect staging with a password, not a noindex

Staging sites leak into Google all the time, usually through a shared link or a sitemap that references them. Put staging behind HTTP authentication or an IP allowlist. That keeps crawlers out without any tag that could survive into production.

If you must use a noindex or a robots.txt block on staging, add "remove staging blocks" as a named launch-day task with an owner. And verify it on the live site afterwards, not just in the deploy log.

Compare old and new, page by page

Crawl staging with your crawler set to use the staging credentials, then compare it against the crawl of the live site. For your priority URLs, check each of these by hand:

• Title tag, meta description and H1
• Body copy length and key sections (FAQs, specifications, reviews, comparison tables)
• Canonical tag, pointing at the new production URL and not at staging
• Structured data: same types, same key properties, still valid
• Internal links in and out of the page, including breadcrumbs
• Hreflang annotations, if the site is international (see the hreflang guide)
• Images: alt text, file names, and width and height attributes
• Mobile layout: nothing important hidden or removed on smaller screens

Check what Google actually renders

If the new platform uses a JavaScript framework, compare the raw HTML with the rendered DOM. Main content, links and meta tags should be present in the initial HTML wherever possible. The JavaScript SEO guide and the headless CMS guide cover the rendering options in detail.

Test the redirect map against staging

Load every old URL from your map into a crawler in list mode, pointed at staging, and check three things: each returns a single 301 or 308, lands on the intended destination, and that destination returns a 200. Fix every exception before launch. It's much easier now than when the logs are full of real traffic.

6. Phase 4: Launch Day

If the earlier phases went well, launch day should feel almost boring. Here's the order I follow.

7. Phase 5: Post-Launch Monitoring

A migration isn't done at launch. Google has to recrawl the old URLs, see the redirects, and move signals across. Its own guidance says a medium-sized site can take a few weeks for most pages to move, and larger sites take longer.

When to worry

Some volatility is expected, so the question is direction, not size. A dip that bottoms out in the first two or three weeks and then starts climbing is a normal migration. A drop that keeps widening after four to six weeks, or one concentrated in a single template or folder, points to a specific fault.

When that happens, segment the loss before you guess. Group the affected URLs by template, folder and match type from your redirect map. A problem limited to one template is almost always a template issue. A problem across everything tends to be a crawling or indexing block.

For building a reporting view that separates migration effects from normal seasonality, the SEO reporting guide is a good place to start.

8. Notes by Migration Type

The phases above apply to every migration. Each type also has a few details of its own.

Domain change or rebrand

Use the Change of Address tool in Search Console after redirects are live. It needs verified domain-level properties for both the old and new sites, and it runs pre-move checks before accepting the request. Google says the tool keeps forwarding signals for 180 days.

Keep paying for the old domain for years, not months. Google itself suggests holding it at least a year so nobody else can buy it and misuse your old traffic and links. In Bing Webmaster Tools, the Site Move feature does a similar job, so file it there too.

A rebrand is also an entity change. Update your social profiles, business listings, sameAs links in Organization schema, and major directory entries. Reach out to the sites sending you the most valuable links and ask them to update the URL. Redirects pass value, but a direct link is always cleaner.

HTTP to HTTPS

Treat this as a small migration, not a checkbox. Every HTTP URL needs a single 301 to its HTTPS version. Canonicals, hreflang, sitemaps and internal links should all use HTTPS directly. Add HSTS only once you're sure everything works, because it's hard to undo in browsers.

CMS replatform

This is where the most things change at once. New platforms often come with their own URL patterns, pagination, faceted navigation and default templates. Decide early whether the new platform can match the old URL structure. If it can, keep it. A replatform with no URL changes is far safer than one with.

For ecommerce, check product variants, filters and out-of-stock handling closely. The ecommerce SEO guide covers the patterns that tend to break.

Subdomain to subfolder

Moving blog.example.com to example.com/blog is a common consolidation. The Change of Address tool doesn't support it, so you rely on redirects, updated internal links and a fresh sitemap. Update robots.txt on both hosts and confirm the old subdomain's robots.txt doesn't block crawling of the redirects.

International sites

Every hreflang cluster has to be rebuilt around the new URLs, with correct return tags. Missing return tags after a migration are one of the most common reasons regional versions start swapping places in results.

9. Core Web Vitals During a Migration

Performance regressions are one of the quietest ways a migration costs you. New themes ship heavier, third-party scripts get reinstalled wholesale, and hosting or CDN settings don't always carry across. None of that breaks a redirect, so it often gets missed.

Something that catches people out: Chrome UX Report data is based on a rolling 28-day window of real visits. After a domain change or URL restructure, the new URLs start with little or no field data. For several weeks, what you see in Search Console's Core Web Vitals report may be thin or missing.

That's why lab testing on staging matters. Test your main templates before launch, compare them with the old site, and treat a regression as a launch blocker. After launch, real-user monitoring will show problems much faster than waiting for CrUX to fill in. The site speed guide covers fixes for each metric.

10. Protecting AI Search Visibility (AEO & GEO)

Most migration checklists were written before AI answers were a real traffic source. Now there's a second set of systems that need to find your content at its new address: the crawlers behind ChatGPT, Perplexity, Claude, Gemini and Copilot, plus Google's AI Overviews and AI Mode.

Check AI crawler access on the new infrastructure

New CDNs, firewalls and bot-management settings often come with their own defaults, and some providers now offer one-click blocking of AI crawlers. If your old setup allowed them and the new one doesn't, your AI visibility can fade with no error anywhere in Search Console.

After launch, check robots.txt and your CDN or firewall bot settings for the user agents you care about, such as GPTBot, OAI-SearchBot, ClaudeBot and PerplexityBot. Also note that Google-Extended is a control token in robots.txt, not a separate crawler. The robots.txt and AI crawlers guide has the full list and the rules for each.

Keep the extractable parts of your templates

The parts of a page that AI systems quote most easily are short answer paragraphs, definition boxes, clear headings, comparison tables and FAQ sections. These are exactly the blocks that tend to get "simplified" in a redesign. Put them on the same parity checklist as titles and headings.

Keep your entity signals consistent

For a rebrand or domain move, update Organization schema with the new name, URL and logo, and add the old brand name as an alternateName for a while so the connection is explicit. Keep sameAs links pointing at the same social and knowledge profiles. If you publish an llms.txt file, update every URL in it.

Don't forget Bing

Microsoft Copilot is built on Bing's index, so a messy migration in Bing hurts more than it used to. File the Site Move in Bing Webmaster Tools, submit the new sitemap there, and consider IndexNow to push URL changes quickly. The Bing SEO guide covers the setup.

Measure citations before and after

AI answers can keep citing your old URLs for a while. Redirects mean those clicks still land, but you'll want to know when the new URLs start appearing. Take a snapshot of citations for your core topics before launch and repeat it monthly afterwards. The AI citation rate guide explains how to track this consistently.

11. Mistakes I Keep Running Into

None of these are exotic. They're all simple, and they all happen on projects with competent teams, usually because nobody owned that particular task.

12. The Full Migration Checklist

Use this as a working list. Assign an owner to every line, because tasks without an owner are the ones that get skipped.

13. Site Migration FAQs

14. Documentation and Sources

📚 What This Guide Is Checked Against