Domain Migration SEO: The 2026 Move-Without-Loss Playbook

A bad domain migration can wipe out months of SEO progress in a single cutover. The patterns repeat across every migration we audit: rankings lost on day one, traffic down 40% by week two, full recovery taking six to twelve months when it comes at all.

The reason is not Google punishing migrations. Google has stated plainly that a site can move to a new domain without losing rankings — when the moves are right. The reason migrations fail is that the moves are almost never done right. The redirect file is shipped with gaps. The change-of-address tool is clicked before production is staged. The internal links still point at the old domain a year later. Every one of those is a place ranking signals leak out.

This is the working playbook we run on every migration: the four migration types, the URL mapping step most teams botch, the redirect rules that actually pass equity, and the four mistakes that quietly destroy traffic. It is written for SEOs running the cutover, not for the executive deciding whether to do one.

Key takeaways

• A domain migration is a sequence, not an event. Skipping any step in the sequence is what costs the traffic — not the move itself.
• Four migration types exist (domain-only change, protocol change, subdomain-to-subfolder, full platform move). Each has a different risk profile and a different playbook.
• URL mapping is the foundation. Every redirect, every internal link, every Search Console setting is downstream of the URL map. Get it wrong and nothing downstream can save you.
• 301 redirects pass equity in 2026 — but only when they are 1:1, server-side, permanent, and chain-free. Redirect chains, soft-301s, and meta-refresh redirects leak.
• The change-of-address tool is the last step, not the first. Teams that treat it as the migration get the worst of both worlds.
• Recovery takes 6–12 weeks for clean migrations, 6–12 months for botched ones. The difference is the discipline of the cutover.

What is a domain migration in SEO?

A domain migration in SEO is any move that changes the URL a search engine has to fetch to reach your content. It includes a brand-new domain, a switch from HTTP to HTTPS, a shift from a subdomain to a subfolder (blog.example.com to www.example.com/blog), and a full replatform that moves URLs to new paths. The unifying feature: every URL the search engine knows about stops existing in its old form.

That single fact is why migrations are dangerous. A search engine’s index, a backlink profile, and a user’s bookmarks all reference the old URLs. If the new URLs do not map cleanly to them — and if the redirects do not honour that mapping — every reference becomes a 404, a redirect chain, or a soft redirect. Each one of those is a place ranking signals leak out, and once they have leaked, recovery is measured in months, not days.

When should you migrate a domain — and when should you not?

Most teams should not. Migrate when there is a structural reason that pays back the risk — a rebrand, a protocol security mandate, a subfolder architecture you cannot get any other way, a platform that no longer supports the SEO surface you need. Do not migrate because a competitor has a nicer domain, because a new TLD looks on-trend, or because the agency that pitches you promised “no traffic loss.”

The decision framework:

• Brand change (acquisition, rename): migrate. The risk is unavoidable.
• HTTP to HTTPS: migrate. Google has used HTTPS as a lightweight signal for years, and the security floor is now table stakes.
• Subdomain to subfolder (blog.example.com to www.example.com/blog): migrate only when the hosting situation forces it. The legacy cost on the subdomain setup is often higher than the migration cost.
• Platform change (new CMS, new framework): treat as a migration if URLs change. If URLs are stable, treat as a hosting move — far less risk.
• Domain name change for branding: migrate only when the new domain earns back the migration cost in the first year. Most rebrands do not.

The last point is the one most teams get wrong. A prettier domain is not a strategy. The traffic loss during a botched migration is, on the data we have seen, roughly 8–14 weeks of organic traffic compounded — easily a six-figure opportunity cost for any mid-sized publisher.

The four migration types SEOs handle

Each type has a different risk profile, and the playbook adjusts accordingly.

Domain-only change. Old domain to new domain, same content, same URLs. The cleanest move; the redirect rules are simple. The big risks are the change-of-address sequence and backlink recovery.

Protocol change. HTTP to HTTPS, or a www-to-non-www canonicalisation. URLs change shape but the path stays. Often bundled with a domain change for branding reasons. The risk is mixed-content errors and HSTS misconfiguration.

Subdomain to subfolder (or vice versa). A re-architecture that affects how search engines split authority between hostnames. Higher risk because search engines treat subdomain and subfolder signals differently — moving between them is a re-balancing act, not a rename.

Platform migration. New CMS, new framework, often a re-architecture that produces thousands of URL changes. The highest-risk move because the URL map is usually the casualty — and the URL map is the foundation.

How to plan a domain migration that protects rankings

The plan is a sequence, not a checklist. Each step produces the input for the next.

1. Inventory every URL that ranks. Pull six months of Search Console data, export every URL with more than 50 impressions, and tag each one by template (blog post, product page, landing page, category, etc.).
2. Inventory every URL that has backlinks. Use a backlink crawler or your log files to find URLs with external links — these are the ones that cannot be lost to a 404.
3. Build the URL map. For each old URL, write the new URL — one-to-one, with zero ambiguity. Every page on the new site gets a target. Every page on the old site has a destination. If a page has no destination, decide before launch whether it 301s to the closest equivalent, 301s to the new homepage, or returns 410.
4. Map hreflang and structured data alongside URLs. International sites need the new URL set reflected in hreflang. Sites with rich results need the new URLs in the JSON-LD on every page.
5. Stage the redirects. Ship the URL map as a redirect file at the server or platform layer, in the staging environment, and verify every URL with a crawler before touching production.
6. Cut production. Move DNS, ship the redirects, and update the change-of-address tool last — in that order.
7. Watch for 14 days. Crawl the new site daily, watch Search Console for coverage drops, and verify that the redirects fire from a real browser (not just curl).

The sequence is not negotiable. Teams that run steps in parallel skip a dependency; teams that skip a step rebuild the URL map under time pressure; teams that rebuild under time pressure ship a redirect file with gaps. The traffic decline is the same in every case.

The URL mapping step most teams get wrong

URL mapping is where most migrations fail. The pattern is consistent: a marketing team ships a redirect file with 80% of URLs covered and the missing 20% returning 404. Search engines treat the 404s as content removal, the redirect chains as soft signals, and the rankings slide for months.

The fix is mechanical. Three rules:

• One-to-one only. A redirect rule like old.com/* -> new.com/* is a global rewrite, not a redirect map, and it silently reorders URLs that should be preserved. Build explicit per-URL redirects for every URL that has impressions or backlinks.
• No orphan destinations. Every URL on the new site has at least one old URL pointing at it. If no old URL maps to a new page, the new page is not in the redirect file — and search engines will struggle to find it via the redirect chain.
• Decide 410 versus 301 before launch. URLs with no equivalent get a 410 (gone, intentional) — not a 404 (broken) and not a 301 to the homepage (which leaks signals). The audit at the end checks for any 301 to the homepage that is not the homepage itself. Our canonical tag mistakes post covers the related failure pattern, where every page canonicalises to / and long-tail signals collapse onto the brand page.

A useful self-check: open the URL map in a spreadsheet, pick 20 random rows, and manually verify the redirect on the staging origin. The exercise takes 30 minutes and catches every class of error the build process misses.

301 redirect rules that actually pass equity

A 301 redirect passes ranking signals in 2026 — when implemented correctly. Three rules decide whether your redirects transfer equity or burn it:

• Server-side, not meta-refresh. A 301 at the server, CDN, or platform layer is the canonical signal. Meta-refresh and JavaScript redirects are not — Google treats them as soft signals and may not pass equity through them. Google’s official guidance on 301 redirects covers the same rules from the search engine’s perspective — useful when justifying the redirect design to a dev team that pushes back.
• Permanent, not temporary. A 302 says “this might change.” A 301 says “this is the new address.” Use 302 only when the redirect is genuinely temporary. Leaving a migration on 302 months after cutover is one of the most common errors we see in audits.
• No chains. A redirect from URL A to URL B to URL C is a chain. Each hop leaks a small amount of equity, and Googlebot may stop following after the second hop. The fix is to ship the redirect file with direct A-to-C rules. Our redirect chains audit walks through the cleanup.

Beyond the rules themselves, two implementation details decide whether the redirects survive launch:

• Keep the redirect file indefinitely. Migrations are not “set and forget.” A page redirected on day one should still redirect on day 365. Many platform migrations overwrite the redirect file on the next deploy — a bug that quietly undoes the migration six months later.
• Audit the redirect file quarterly. URLs get added, broken, and orphaned. A 90-day check catches redirect rot before it shows up in coverage reports. The deeper crawl-side audit lives in our technical SEO guide.

Search Console change-of-address: the sequence

The change-of-address tool in Search Console is the signal that tells Google the move is intentional and the new domain is canonical. Used wrong, it forces a re-evaluation of every URL on the new site — which costs weeks of indexing latency. Used right, it accelerates indexing by weeks.

The order matters:

1. Verify both properties. Add and verify the new domain in Search Console before doing anything else. Without verification on both sides, the tool refuses to fire.
2. Ship the redirects. Make sure production serves them before you flip the switch.
3. Use the change-of-address tool last. Once you click the button, Google treats the move as canonical and starts the re-evaluation. Any redirect not in place becomes a hard 404.
4. Submit the new sitemap. Right after the change-of-address click, submit the new domain’s sitemap from the new property. Coverage reports shift to the new property within 24–48 hours.

The hidden gotcha: the change-of-address tool does not migrate historical data. Coverage reports, performance reports, and backlink data on the old property stay on the old property. You cannot get historical performance back from the new property — the data lives where the URLs lived. Plan the reporting move in parallel with the technical move. Our Search Console hidden reports guide has the field-by-field breakdown.

Sitemaps, robots.txt, and the cutover window

The cutover window — the 48 hours around the DNS move — is where most teams fumble. Three files need attention:

• Sitemap. Submit the new sitemap in the new property right after the change-of-address click. Resubmit if the indexation count does not match the URL count within seven days.
• robots.txt. Check that the new site does not inherit a Disallow: / from a staging config. A staging-blocked robots.txt shipped to production is the kind of bug that costs a site six weeks of indexing.
• Canonical tags. Verify that every page on the new site self-canonicals to the new URL, not the old. The classic migration bug is a copy-paste of the old canonical URL into the new page head.

For international sites, the same cutover applies to hreflang annotations — every reference in the cluster must point to the new URL set. Our hreflang 101 guide walks through the validation. Run the sitemap file through our Sitemap & Robots Validator before launch — it catches redirect chains, stale entries, and accidental noindex patterns that the redirect file alone does not cover.

Backlinks: recovering the ones you cannot redirect

Most backlinks live on URLs that you control — pages on your own domain that you have redirected. A redirect handles those. The remaining 10–20% — links from forums, archived pages, comment sections, social platforms — point at URLs you do not control. Three recovery paths:

• Update the link. If the linking site is reachable, ask for a direct edit. High-value links (news sites, industry publications) get a personal email. Low-value links (forums, old comments) often cannot be updated.
• 301 the unreachable link to the new URL. If the linking page is reachable but the link itself is uneditable, a 301 from the unreachable URL to the new URL still passes equity — the redirect file does the work.
• Let it go. Links from low-quality sites, deleted pages, and abandoned directories rarely carry meaningful equity. Chasing them costs more time than the recovery is worth.

The audit step is the same as the URL mapping step: pull your backlink profile, sort by referring-domain authority, and identify the top 100 URLs. Verify each one redirects. Anything that does not is your recovery list.

The four mistakes that quietly destroy migration traffic

Across every migration we audit, four patterns show up in 95% of the failed cases. None of them look like mistakes until the traffic drop.

1. Treating the change-of-address tool as the migration. The tool is the last step. Teams that click it before the redirects are in place hand Google a new URL with no path to the old content, and indexing collapses. Re-fixable, but not in days — in weeks.

2. Shipping a global rewrite instead of a URL map. A rewrite that pattern-matches old.com/(.*) to new.com/$1 sounds efficient and breaks every URL with parameters, every URL with case differences, and every URL whose path semantics changed. The result is a wave of soft-404s that look like redirects to a crawler.

3. Removing the old redirects after a month. The instinct is to clean up the redirect file once traffic stabilises. The problem is that search engines still discover old URLs months later — from backlinks, from archive snapshots, from cached SERP snippets. Removing the redirect file undoes the migration at exactly the moment you thought you had finished it.

4. Forgetting to update internal links. Search engines discover new URLs through the redirect file, but users navigate by clicking. Internal links still pointing at the old domain create a confusing experience, slow down the crawl of the new site, and hand Google mixed signals about which domain is canonical.

The first two are caught by an afternoon of staging. The third is caught by a quarterly audit. The fourth is caught by a five-minute site:old-domain.com check that finds every internal link the redirect file is silently carrying.

Auditing a migration you inherited

Not every migration is one you ran. The audit on an inherited migration is the same shape as the build: verify the redirects, verify the Search Console setup, verify the canonical signals, verify the indexation of the new URLs.

A useful check: pick ten URLs that ranked in the top three for their query on the old property. Crawl the same URLs on the new property. If the new property returns them at rank 20 or worse, the migration is incomplete. The fix is rarely “submit the URLs again” — it is usually a redirect or canonical bug that needs surgical correction.

For a wider audit, the technical SEO guide walks the crawl-to-index pipeline end to end, and the sitemap audit should also run through the Sitemap & Robots Validator — it ships with a per-URL check that catches redirect chains and stale entries in minutes.

Frequently asked questions

How long does a domain migration take to recover rankings?

A clean migration recovers 80–90% of rankings within 6–12 weeks. A botched one can take 6–12 months, and some signals never fully return. The difference is redirect discipline and the order of the change-of-address sequence.

Do 301 redirects pass all link equity?

In 2026, a server-side 1:1 301 transfers substantially all link equity. Chains, soft redirects, and 302s leak — sometimes a lot. The audit that catches the leaks is a redirect file review, not a backlink check.

Should I migrate one section of my site or the whole site at once?

Migrate the whole site in one cutover. Partial migrations create a long tail of mixed signals — some URLs on the new domain, some on the old, some on both — and Google treats the inconsistency as unstable. The one exception is a rebrand where the old brand has equity you want to preserve; in that case, run two parallel sites for a quarter before cutting over.

Can I migrate without losing backlinks?

Yes, in the sense that every backlink can be redirected. No, in the sense that some signals decay. The most authoritative links matter most; low-authority backlinks decay whether you redirect or not. The audit that matters is: which of your top 100 linking domains are reachable for a direct update, and which rely on the redirect file.

What is the change-of-address tool in Search Console?

A setting on the old property that tells Google the new domain is canonical and to migrate indexing signals. It is the last step in the migration sequence, not the first, and it does not migrate historical Search Console data.

The verdict

A domain migration is a sequence of steps, not a single move. Skipping any step in the sequence is what costs the traffic — not the migration itself. The four-step discipline — inventory, URL map, server-side redirects, change-of-address last — recovers 80–90% of rankings within 6–12 weeks on a clean cutover.

The teams that get migrations right treat them like a deployment: version-controlled, staged, audited, and watched for two weeks. The teams that get them wrong treat them like a marketing campaign — a launch, a press release, and a prayer. The traffic outcome separates the two within a month.

Run the migration as a deployment. The redirects are the deployment. The change-of-address is the post-deployment signal. The two weeks after are the rollout. Anything else is rolling the dice on your organic traffic.