How to Change Domains Without Losing Your Search Rankings

Changing your domain is the single riskiest move in SEO, because the asset you're moving is the rankings. Years of links, trust, and indexed pages are anchored to your old hostname, and a careless switch can wipe out organic traffic overnight — a drop that takes months to claw back, if it comes back at all. Yet the move is often unavoidable: a rebrand, an upgrade from a compromise name to the .com you finally bought, or consolidating three sites into one.

The takeaway up front: a domain migration done right loses very little and recovers fully, because search engines are designed to follow a site that moves cleanly. The whole game is telling them, unambiguously and page by page, "this URL is now that URL." Get the redirect map right and the rest is execution. Get it wrong — or skip it — and you're not migrating, you're starting over.

What actually carries your rankings — and what breaks it

Your rankings don't live in your content; they live in the signals pointing at your URLs. Backlinks point at specific old URLs, the index stores those old URLs, and your internal links and sitemap reference them. When you change domains, every one of those pointers now aims at an address that no longer exists. Do nothing and you get a sea of 404s, the backlinks dangle into dead pages, and the engine drops the old URLs from the index without ever learning where they went.

A 301 redirect is the fix, and it's not a courtesy — it's the mechanism that transfers signals. A 301 ("moved permanently") tells engines the old URL has a permanent new home, so they pass the old page's accumulated authority to the new one and swap it in the index. That's the load-bearing concept of the whole migration: 301s are how link equity travels from the old domain to the new one. A 302 ("temporary") does not reliably pass equity and tells the engine to keep the old URL — exactly wrong for a permanent move. The difference between a 301 and a 302 is the difference between a migration and a disaster.

Build the redirect map before you touch anything

The most important deliverable of a migration is a spreadsheet, not a deployment. Before you move a single file, build a complete 1:1 map of every old URL to its new URL. This is the work; everything else is mechanical.

1. Inventory every live, valuable URL on the old domain. Merge three sources: your XML sitemap, a full crawl, and your analytics/search-console list of pages that actually receive traffic and links. The last source is non-negotiable — it catches orphaned pages that still rank and earn links but aren't linked internally anymore.
2. Map each one to its new-domain equivalent. Same path on the new host is ideal (old.com/pricing → new.com/pricing), because a 1:1 same-path move is the cleanest signal. Where the structure changes, map to the closest matching page.
3. Never bulk-redirect everything to the home page. This is the most common and most damaging shortcut. Redirecting all old URLs to the new home page tells the engine those pages are gone, not moved — it treats a redirect to an irrelevant page as a soft 404 and passes little to no equity. A blog post must redirect to that post's new URL, or its links and rankings evaporate.
4. Decide what to retire deliberately. If a page genuinely shouldn't survive the move, let it 404 (or 410) on purpose — a migration is a fine time to prune, but make it a choice, not an accident.

Keep the map flat: redirect old URLs directly to their final new URL. Chains and loops leak equity and waste crawl budget. One hop, every time.

Execute the move as one clean cutover

With the map built and the new site staged and tested, migrate in a tight sequence rather than a slow drift. A long period where both domains serve the same content invites duplicate-content confusion and split signals.

• Stage and verify the new site fully first — every page reachable, no leftover noindex from the staging environment (a noindex that ships to production is a classic migration killer), internal links updated to new-domain URLs, and canonical tags referencing the new domain.
• Put the 301s live at the cutover. Implement them server-side (web server or CDN config) so every old URL returns a real 301 pointing at its mapped new URL. Spot-check with your browser's network tab or curl -I that you see 301 and the correct Location:, not a 302 or a chain.
• Mind the DNS and infrastructure. The new domain needs correct DNS and a valid TLS certificate, and the old domain must stay resolving so the 301s keep firing — the redirect only works while the old domain still answers. This is exactly the registrar and DNS hygiene covered in the domain management guide: keep the old domain registered, locked, and pointed for years, not weeks.
• Update your sitemaps. Publish a fresh XML sitemap of the new-domain URLs. Briefly keeping the old sitemap available can even help engines rediscover the old URLs and see their 301s faster.

Tell the search engines directly: Change of Address

Redirects do the heavy lifting, but you can hand the engines an explicit signal. Google Search Console's Change of Address tool lets you formally notify Google that your site has moved from the old property to the new one. It accelerates the swap and helps consolidate signals — but it has prerequisites you must meet first: verify both the old and new domains as properties in Search Console, and have the 301s already live and working. Change of Address is a confirmation of a move you've already executed correctly; it is not a substitute for the redirects. Set up Bing Webmaster Tools' equivalent site-move signal too, so you're not optimizing for one engine.

Expect a dip — and know what's normal versus what's broken

Here's the part that causes panic: even a flawless migration usually shows a temporary ranking and traffic dip. The engine has to recrawl the old URLs, see the 301s, follow them, and re-evaluate the new URLs in their new context. That takes time — typically a few weeks to a couple of months for a substantial site to fully settle.

The skill is distinguishing the normal settling dip from a real failure:

• Normal: a modest dip that begins recovering within weeks as the new URLs replace the old ones in the index. Watch the new domain's impressions climbing in Search Console even while positions wobble — that's the index swapping over.
• Broken: traffic that craters and stays down, old URLs returning 404 instead of 301, redirect chains, the new site accidentally noindex'd, or everything redirecting to the home page. These are fixable causes — find them in the crawl and the page-indexing report.

Resist the urge to "fix" rankings during the dip by changing content or chasing links. Mid-migration, the highest-value thing you can do is verify the mechanics are clean and then wait. Watch the old domain's index count fall as the new domain's rises; when they've crossed over, the move is done.

FAQ

Will I lose rankings when I change domains?

Usually only temporarily, if you do it right. A complete 1:1 set of 301 redirects passes your link equity to the new URLs, so most rankings recover within weeks to a couple of months. You lose rankings permanently mainly when redirects are missing, point everything to the home page, or use 302s instead of 301s.

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

For a small site, often a few weeks; for a large or slowly-crawled one, up to a couple of months to fully settle. The engine has to recrawl old URLs, follow the 301s, and re-evaluate the new ones. Watch the new domain's impressions rising in Search Console as the signal that recovery is underway.

Do I need to keep the old domain after migrating?

Yes — for as long as you can, ideally years. The 301 redirects only work while the old domain still resolves, so keep it registered, renewed, and pointed at your redirect rules. Letting the old domain lapse breaks every redirect and undoes the migration.

Is Change of Address in Search Console enough on its own?

No. Change of Address is a notification that accelerates a move you've already executed with working 301s; it doesn't move anything by itself. You must have both domains verified and the redirects live first. Treat it as a confirming signal layered on top of the redirects, not a replacement for them.

Should I redirect old URLs to the new home page to keep it simple?

No — this is the most damaging shortcut in migrations. Redirecting unrelated old URLs to the home page reads as a soft 404, so the engine treats those pages as gone and passes little equity. Each old URL must 301 to its specific matching new URL.

Next step

Don't move anything yet. Open a spreadsheet and build the old-to-new URL map first — pulled from your sitemap, a full crawl, and your search-console traffic list, so nothing valuable is missed. That map is your migration. Once it's complete and the new site is staged and verified, cut over once with direct 301s in place, file your Change of Address, and watch the index swap. Plan your move carefully at MyQSD, and a domain change becomes a controlled transfer of authority instead of a gamble with your traffic.