How to Migrate a Website to a New Domain Without Losing SEO

Successful website migrations come down to one principle: preserve URL-level continuity. Before launch, crawl and inventory the old domain, map every valuable old URL to its closest equivalent on the new one, put permanent 301 redirects in place, update internal references, verify both domains in Search Console, use Change of Address where it applies, submit the new sitemap, and monitor the transition afterward. A migration can still cause temporary ranking fluctuations even when every step goes as planned. “Without losing SEO” is about minimizing unnecessary loss and preserving what already exists – that’s the realistic shape of a site migration without losing SEO, day-one perfection aside.

Why a Domain Migration Can Affect Rankings

The content can stay word-for-word identical, and it still doesn’t matter to a search engine – oldsite.com/page/ and newsite.com/page/ are different URLs as far as Google is concerned, full stop. The old URLs likely already carry backlinks, ranking history, internal links, indexed status, and established search traffic, and none of that follows the content automatically just because the words on the page didn’t change. Google doesn’t simply copy authority over to a new domain on launch day. It has to recrawl, reprocess, and reassociate signals with the new addresses, and that takes real time – in our experience, this is the single most common thing clients underestimate going into a migration. The actual job of a migration – the real answer to how to change domain without losing SEO – is making the relationship between old and new URLs as explicit and consistent as possible, so reprocessing has as little ambiguity to resolve as it can.

Domain Migration vs Other Website Migrations

Not every change that gets called a “migration” carries the same risk – a CMS switch, a redesign, an HTTP-to-HTTPS move, or folding a subdomain into a folder can all technically qualify, but changing every hostname across a site at once is a different order of risk than moving to a new server while every URL stays identical. This article focuses specifically on domain migration, the riskiest version of the bunch, though several of the safeguards below apply to any migration that touches URLs.

Before Migrating, Record Exactly What You Need to Preserve

The first real step isn’t picking redirect software – it’s building a complete baseline of what currently exists, which in practice is exactly what a technical audit covers before any migration starts. Crawl the old domain and pull every indexable URL, the XML sitemap, organic landing pages, clicks and impressions from Search Console, pages carrying important rankings, pages with backlinks pointing at them, pages generating conversions where that data exists, canonical URLs, internal links, and any redirects already in place. On larger sites, don’t skip PDFs or other assets if they’ve picked up external backlinks or organic visibility of their own – we’ve seen a client’s whitepaper PDF quietly hold more backlinks than half the blog.

Not every URL on that list carries equal weight, though, and treating them all identically wastes attention that should go where it matters most. The highest-traffic pages, the strongest backlink targets, commercial landing pages, high-ranking informational content, and anything generating leads or revenue directly are where a redirect mistake costs the most – that doesn’t mean a low-traffic page gets ignored entirely, since it can still be holding a useful internal link or supporting the site’s structure in ways the traffic number alone doesn’t show.

Change as Little as Possible During the Domain Move

If the actual task is changing the domain, the strongest move is keeping everything else stable – content, URL paths, page templates, navigation, the major internal linking structure, titles and key on-page elements, the CMS where that’s practical. We’ve noticed this holds true even on small projects: the more variables move at once, the harder it gets to read what actually happened afterward. If rankings fall after a domain change bundled with a redesign, a URL rewrite, a CMS migration, and a content rewrite all at the same time, there’s no clean way to isolate which piece caused the drop.

Can You Redesign at the Same Time?

A redesign can go through quickly and without losing search positions – that’s been our own experience often enough to say it plainly. The condition attached to it matters just as much: it holds when the SEO-sensitive elements are deliberately preserved and the whole thing is planned around continuity rather than bolted onto a domain change as an afterthought. A redesign that also rewrites URLs, restructures hierarchy, and swaps templates carries real added risk on top of the domain move itself. Where possible, we tend to recommend splitting major changes into separate phases; if a redesign genuinely has to happen alongside the domain move, document every SEO-relevant change and test it before launch rather than discovering the interactions live.

Build a One-to-One Redirect Map

This is the technical core of the whole migration, and it’s worth building carefully rather than rushing through.

The mapping rule is simple to state and easy to get lazy about in practice: old URL goes to its closest equivalent new URL. If a page stays essentially the same and only the hostname changes, keep the same path wherever that’s practical – Google reads that continuity directly. What we’d avoid entirely: sending every old URL to the new homepage, funneling unrelated pages into one generic category, or redirecting to content with a different intent just to dodge a 404. Broad many-to-one redirects into a homepage tend to read to search engines as content loss rather than content that moved, which defeats the purpose of redirecting at all.

What If There Is No Equivalent New Page?

Don’t force a redirect purely because the old URL used to exist somewhere. If the page still carries real business or SEO value, build a genuine equivalent on the new domain. If a close, honest replacement exists, redirect there. And where the content has genuinely gone away with nothing sensible to replace it, a 404 or 410 is the right answer – redirecting a discontinued article about one topic to an unrelated commercial page about something else does more harm than a clean 404 ever would.

Use 301 Redirects for a Permanent Domain Migration

If SEO carries real weight in the decision, a 301 redirect is the right choice for this kind of move – that applies to drop-domain merging, www-to-non-www changes, and other permanent technical redirects just as much as it does to a full domain migration. None of that guarantees every signal transfers perfectly – but for a permanent move, 301 is the correct semantic signal to send, and 302 or 307 simply say the wrong thing to Google about intent.

Avoid Redirect Chains

A bad pattern looks like old.com/page → old.com/new-page → new.com/new-page. A better one sends that same URL straight to its final destination in a single hop. Every legacy URL should resolve in one step where at all possible – chains slow crawling down and dilute whatever signal was supposed to transfer cleanly. Worth testing across HTTP, HTTPS, www, non-www, and trailing-slash variants too, since a chain can hide inside any of those combinations even when the main redirect map looks clean on paper.

Update Internal Links Instead of Leaving Them Behind Redirects

Once the new domain is live, its own internal links should point straight at new-domain URLs, not rely on the redirect to catch them:

• navigation and breadcrumbs
• contextual links inside content
• footer links
• image links
• hreflang references
• structured-data URLs

A 301 exists as a fallback for old references still floating around the internet. We’ve caught more than one project still routing its own navigation through the old domain months after launch, purely because nobody went back and updated the links once the redirect started working. The redirect masked the problem instead of solving it.

Update Canonicals, Sitemap and Other URL Signals

After migration, a short list of signals needs to point at the new domain consistently:

• canonical tags referencing the correct new URLs
• the XML sitemap listing new-domain addresses only
• robots.txt pointing at the right sitemap
• hreflang clusters updated to the new URLs
• structured-data URL properties
• Open Graph and social URLs
• any hardcoded old-domain references buried in the code

One mistake we see often enough to call out specifically: copying the whole site over to the new domain and leaving canonicals still pointing back at the old one. It’s easy to miss because the site looks completely fine to a human visitor, while quietly telling Google the wrong story underneath.

Configure Google Search Console for the Domain Change

Before or right at launch:

1. Verify ownership of the old domain.
2. Verify ownership of the new domain.
3. Confirm the 301s are actually live and working – don’t assume the deployment went through cleanly.
4. Use the Change of Address tool where it applies to the move.
5. Submit the new XML sitemap in the new property.
6. Keep both properties available for monitoring rather than archiving the old one.

Change of Address doesn’t replace redirects. It’s a notification layer sitting on top of them – the redirects themselves stay the primary signal doing the actual work at the URL level.

Keep the Old Domain and Redirects Active

Don’t let the old domain lapse just because Google has started indexing the new one. Old URLs keep pulling in backlinks, bookmarks, direct traffic, crawler requests, and references buried in old PDFs and articles for a long time after launch. In our experience, this window runs longer than most teams expect going in.

Where a change of structure or a section move is involved, we generally recommend planning the 301 immediately and keeping it working for as long as the old URLs might still need to resolve. That keeps telling search engines the address moved permanently, rather than sending mixed signals partway through.

Our own practical stance runs more conservative than a fixed expiration date: where it’s feasible, keep the old domain and its important redirects running indefinitely, rather than treating them as temporary launch code to clean up later.

Update Important External Backlinks Where Possible

A 301 preserves the relationship between old and new URLs, but there’s still real value in updating the strongest external references directly rather than leaning on the redirect forever. Worth prioritizing:

• high-authority editorial links
• partner sites
• industry directories
• profiles the company controls
• Google Business Profile where it applies
• social profiles and high-value citations

We wouldn’t spend months chasing down every historical backlink. Start with the links already under your control, or the strongest ones worth a direct outreach email. A working 301 and a direct link aren’t measurably different in ranking terms most of the time – the real benefit of updating them is cleaner architecture and one less dependency on a legacy redirect doing the work forever.

Test the Migration Before and Immediately After Launch

Before launch, test the redirect map against the staging or planned environment wherever that’s possible.

Right after launch, work through this in order:

1. Crawl the old URLs and confirm they return 301s.
2. Confirm the final destination actually returns 200.
3. Check for redirect loops.
4. Look for chains that slipped through.
5. Crawl the new site on its own.
6. Check whether old-domain links are still buried in the new site’s internal linking.
7. Verify canonicals, indexability, and the sitemap.
8. Manually test the pages that matter most, rather than trusting the crawl alone for everything.

Building a redirect file is not the same thing as proving it works in production. We’ve seen a technically correct redirect map fail in practice over one server config detail nobody tested against the live environment.

What Our Subdomain-to-Folder Migration Shows

One of our US information projects moved sections that had been living on subdomains into folders on the main domain. The migration happened in November 2024, and an expected decline followed right after – the kind of dip we’d flagged as likely going in.

By January 2025, organic traffic had recovered, and growth continued from there. Roughly two months from migration to recovery, on this project specifically.

Two things worth taking from it. A temporary decline right after a migration doesn’t automatically mean the migration failed – we’d have been wrong to call it a failure in December, a month before the recovery showed up. And the real test of a successful migration is what happens over the following weeks.

What Our Old-Domain-to-New-Domain 301 Test Shows

In one of our experiments, an old domain got redirected with a 301 straight into a newly registered one. Traffic rose immediately after the switch – enough that it would have been easy to call the migration an instant success. Part of that initial boost rolled back over the following weeks. What stuck, though, was real: the new domain kept meaningfully transferred organic traffic and held onto some of the positions it had picked up during the spike.

That combination is the useful part. Signal transfer can produce a visible response fast, but the first jump after a migration isn’t automatically the stable baseline it looks like. The new domain still needs time to settle into the index before that early number means much of anything.

A 301 Can Transfer Value – But Do Not Measure Success on Day One

Watch sustained clicks, impressions, ranking pages, query coverage, and conversions over weeks. A number pulled the morning after launch tells you almost nothing about where the site will actually settle.

What Ranking Fluctuations Are Normal After a Domain Change?

Some volatility is simply expected, because Google has to crawl the old URLs again, follow the redirects, process the new URLs, swap old ones out of the index, and reassociate every signal that used to point at the old address. We wouldn’t repeat a competitor’s specific “3-7 weeks” or “20-40% decline” figure as if it were a Google guarantee.

A safer way to frame it: small sites with frequent crawling tend to stabilize relatively fast, while large sites or poorly crawled sections can take considerably longer – the same logic covered in more depth in our piece on how long SEO takes for a new site. Our own subdomain-to-folder project needed roughly two months to return to, and then exceed, where it had been before the move. 

How to Tell Normal Migration Volatility from a Problem

Common Website Migration Mistakes That Cost Rankings

Most of the damage we see traces back to a short list of repeat offenders: forgetting URLs that weren’t in the current sitemap but still had links or traffic pointing at them, redirecting everything to the homepage, using a temporary redirect for what’s actually a permanent move, redirect chains and loops, changing the domain plus the CMS plus the structure plus the content all at once, canonicals left on the old domain, old-domain URLs still sitting in internal links, staging noindex rules accidentally left live after launch, forgetting Change of Address where it applies, letting the old domain expire, pulling redirects too early, and simply not monitoring the old property once the new one is live. None of these are exotic failures – they’re the same handful of oversights showing up project after project.

Website Migration Checklist

Here’s how to migrate a website end to end, laid out as one sequence rather than scattered advice – the same order we’d actually follow with a client. 

Before migration: crawl the old domain, export Search Console, analytics, and backlink data, identify priority URLs, finalize the new URL structure, build the one-to-one redirect map, check the new domain’s own history if it was previously used for something else, prepare canonicals, sitemap, and internal-link updates, and test the setup before going live.

Launch: make the new domain crawlable and indexable, activate the 301s, test the old-to-new mappings directly, update internal links and canonicals, verify both Search Console properties, submit Change of Address where relevant, and submit the new sitemap.

After migration: crawl both domains, watch for 404s, chains, and loops, monitor old versus new clicks and impressions in Search Console, update the important backlinks and profiles worth updating, keep the old domain and redirects active, and avoid stacking on unrelated major changes while things are still stabilizing.

A migration succeeds when the old and new sites tell Google the same story – equivalent content, one-to-one 301s, direct internal links, consistent canonicals, updated sitemaps, the right Search Console signals, and redirects built to last rather than expire on some arbitrary date. One of our structural migrations recovered in roughly two months and kept growing from there; a separate old-to-new domain test produced an immediate boost, a partial rollback, and a real, lasting core of transferred visibility underneath both. That’s why migration success gets judged over weeks. If you’re planning a domain move and want a migration plan or audit before you touch anything, reach out on Telegram at @yandowski or book a consultation on the website.

FAQs

Will changing my domain name hurt SEO?
It can cause temporary volatility, but it doesn’t have to cause lasting damage if the migration is planned properly. Google needs time to recrawl and reprocess the new URLs regardless of how well the move is executed. The real risk isn’t the domain change itself – it’s missing redirects, broken canonicals, or bundling the move with several other major changes at once.

How long does SEO take to recover after a domain migration?
It varies by site size and how well the migration was executed, typically anywhere from a few weeks to a couple of months. Our own subdomain-to-folder migration took roughly two months to fully recover and then continue growing. Persistent loss well beyond that window usually points to an unresolved technical issue rather than normal reprocessing.

Should every old URL have a 301 redirect?
Every URL with real traffic, rankings, or backlinks should, but not necessarily every URL that technically existed. Pages with no meaningful history and no close equivalent on the new site can go to a clean 404 instead of forcing an irrelevant redirect.

Can I redirect the entire old domain to the new homepage?
Not without real risk. Search engines tend to read broad many-to-one redirects to a homepage as content loss rather than content that moved. Each meaningful URL should redirect to its closest actual equivalent.

Should I keep the old domain after the migration?
Yes, generally for as long as it’s feasible to maintain. Old URLs keep receiving backlinks, bookmarks, and direct traffic well after the move, and letting the domain lapse cuts that off abruptly instead of letting it fade out naturally.

Do I need Google Search Console Change of Address?
Where it applies to the type of move, yes, though it works alongside the redirects rather than replacing them. It’s a notification to Google, not a substitute for the actual 301 mapping doing the URL-level work.

Can I redesign my website while changing domains?
Yes, and it can go smoothly when the SEO-sensitive elements are deliberately preserved and the whole thing is planned around continuity. Doing both at once without that planning makes it much harder to tell which change caused any ranking movement afterward.

Should I update backlinks after a domain change?
Where it’s practical, yes, starting with the highest-authority and most important ones rather than trying to chase every historical link down. The 301 already preserves the relationship technically – updating the strongest links directly just means less long-term reliance on that redirect.