How to migrate a domain without tanking your search rankings

Changing domains is one of the few SEO projects where a technically small mistake can become very visible very quickly. A missing redirect, a blocked crawl path, or a forgotten canonical can turn a straightforward rebrand into weeks of ranking volatility.

Some movement is normal. Search engines need time to crawl the old URLs, discover the redirects, process signals, and settle the new domain into the index. The goal is not to avoid every dip. The goal is to make the migration boring: one old URL points to one equivalent new URL, the server responds clearly, and nothing important disappears.

Start with an inventory, not a redirect rule

The most common migration failure is treating it as a server configuration task. It is not. It is an information architecture task that happens to end in server configuration.

Before touching DNS, build a list of URLs that matter:

• URLs that receive organic traffic
• URLs with external backlinks
• URLs that convert, generate leads, or support campaigns
• Canonical URLs currently in your XML sitemap
• PDFs, images, and downloadable files that are linked externally
• High-value legacy URLs that may not appear in current navigation

For each old URL, assign a destination on the new domain. In most cases, that destination should be the same page with the same intent. If /pricing becomes https://newdomain.com/pricing, that is simple. If three old product pages are being merged into one new guide, document that decision deliberately.

Avoid the lazy pattern: redirecting everything to the new homepage. It is convenient, but it throws away relevance. Search engines and users both expect the destination to answer the same need as the original URL.

Preserve URL structure where you can

A domain migration is easier when paths remain stable. Moving from oldsite.com/blog/example to newsite.com/blog/example is much cleaner than changing domain, CMS, slugs, folder structure, and content at the same time.

Sometimes a redesign or CMS migration makes URL changes unavoidable. If so, separate the decisions:

1. What is changing because the domain is changing?
2. What is changing because the site structure is changing?
3. What is being deleted, merged, or rewritten?

The more variables you introduce, the harder it becomes to diagnose problems later. If the migration is important and the current site is performing well, consider moving the domain first and redesigning later.

Use permanent, one-hop redirects

For a true domain migration, use server-side 301 or 308 redirects from old URLs to their new equivalents. Temporary redirects are for temporary situations. JavaScript redirects, meta refreshes, and soft redirects are weaker signals and easier to break.

Your redirect goals are simple:

• Every important old URL returns a permanent redirect.
• Each redirect goes directly to the final destination.
• HTTP redirects to HTTPS cleanly.
• www and non-www variants are handled consistently.
• Redirects do not depend on fragile query-string behavior unless necessary.

A bad chain looks like this:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

That may eventually land on the right page, but it is slow, harder to crawl, and more likely to hide mistakes. Aim for one hop from every old variant to the final new URL.

When validating behavior, inspect the actual HTTP responses rather than trusting what the browser shows. Our guide to debugging redirects and HTTP headers in production is useful here because browsers are too polite: they follow the chain and hide the messy parts.

Prepare DNS and certificates before launch

DNS does not directly transfer rankings, but bad DNS can make a migration look broken. Lower TTL values before the launch window so changes propagate more predictably. Confirm that the new domain has correct records for web traffic, email, and any required subdomains.

You also need valid TLS certificates for both domains. This is easy to overlook. The old domain still needs to serve HTTPS redirects after migration. If its certificate expires, users and crawlers may hit browser warnings before they ever reach the new site.

If the move affects email, do not treat that as an afterthought. Domain changes often break SPF, DKIM, DMARC, MX records, tracking links, and transactional mail. For a refresher on the records that matter, see our developer-friendly guide to MX, SPF, DKIM, and DMARC.

Check canonicals, internal links, and sitemaps

After launch, the new domain should behave as if it has always been the canonical home of the content.

That means:

• Canonical tags point to the new URLs, not the old domain.
• Internal links use the new domain or root-relative paths.
• XML sitemaps contain only final, indexable new URLs.
• hreflang annotations, if used, reference the new URLs.
• Open Graph, structured data, and alternate links are updated.
• Robots.txt does not block important sections.

Do not publish a sitemap full of old URLs and expect redirects to clean it up. A sitemap should be a list of URLs you want indexed. After a migration, that means final URLs on the new domain.

Also watch for canonical contradictions. A page that redirects from old to new but has a canonical pointing back to the old domain sends mixed signals. Search engines can usually work through some inconsistency, but you should not ask them to.

Do not change everything on launch day

A migration is already a large enough event. If possible, avoid combining it with major content pruning, template rewrites, navigation changes, JavaScript rendering changes, or a new performance profile.

This is not superstition. It is debugging discipline. If rankings fall after launch, you need to know whether the cause is redirect mapping, crawl access, changed content, slower rendering, missing structured data, or something else.

Keep the initial launch as close to the old site as practical. Once the new domain is stable, make larger editorial and design changes in smaller batches.

Tell search engines what changed

In Google Search Console, verify both the old and new domains. Then use the Change of Address tool when the move is a domain-level change and the content is moving to a new domain. Submit the new sitemap after launch.

This does not replace redirects. It supports them. Search engines still need crawlable, persistent redirects to understand the URL-level mapping.

For Bing and other search engines, use their webmaster tools where available. Also update the places you control: social profiles, business listings, ad destinations, email footers, documentation, partner links, and canonical references in syndicated content.

External links will not all be updated, and that is fine. But the most important ones should be. If a major partner, app marketplace, documentation portal, or press page links to the old domain, ask for an update.

Monitor the right things after launch

The first few days after migration should be active monitoring, not celebration.

Check:

• Server logs for crawl activity on old and new domains
• 404s and unexpected 5xx errors
• Redirect chains and loops
• Indexing status in Search Console
• Sitemap discovery and processing
• Organic landing pages and query patterns
• Conversion paths that depend on old URLs
• Analytics filters and referral exclusions

Expect reporting noise. Some analytics tools treat the new domain as a new property unless configured properly. Some dashboards compare old-domain traffic to new-domain traffic and make the migration look worse than it is.

Search visibility can fluctuate for a few weeks. What you do not want is a pattern where high-value old URLs are being crawled repeatedly but not redirected properly, or where new pages are discovered but marked as duplicates of the old domain.

Performance should not be ignored either. If the new domain launches with heavier templates, broken caching, or unoptimized assets, users may feel the migration as a slowdown. If you are using Lighthouse as part of your checks, read it with priorities in mind; our piece on how to read a Lighthouse report without panicking explains how to separate meaningful issues from noise.

Keep the old domain for a long time

Do not let the old domain expire after the migration “works.” Keep it registered, keep certificates valid, and keep redirects running for as long as possible. In practice, that often means years.

Old links keep existing in blog posts, bookmarks, documentation, PDFs, emails, and social posts. Redirects are the bridge between that historical footprint and the new domain. Turning them off too early breaks users’ paths and wastes accumulated signals.

Also keep a copy of your redirect map and launch notes. Six months later, when someone asks why a legacy URL behaves a certain way, you will be glad you documented it.

<!-- tool-cta:start -->

💡 Try this: After cutover, trace your old URLs through the Redirect Checker to confirm each one resolves in a single 301 hop to the right new page.

<!-- tool-cta:end -->

A sensible migration checklist

Before launch:

• Verify both domains in Search Console.
• Crawl the current site and export important URLs.
• Build a one-to-one redirect map.
• Lower DNS TTLs.
• Prepare TLS certificates for old and new domains.
• Update canonicals, internal links, hreflang, structured data, and sitemaps.
• Test redirects in staging or a controlled environment.

On launch day:

• Deploy redirects.
• Confirm HTTP to HTTPS behavior.
• Test important URL samples from every template type.
• Submit the new sitemap.
• Use the Change of Address tool where appropriate.
• Watch server errors, redirect loops, and blocked resources.

After launch:

• Monitor crawl errors and indexing reports.
• Update important external links where you can.
• Compare traffic by landing page intent, not just domain totals.
• Keep redirects live indefinitely.
• Delay unrelated redesign or content experiments until the move stabilizes.

Domain migrations are not risk-free, but they are manageable. Rankings usually suffer when the migration sends unclear signals: missing redirects, changed content, contradictory canonicals, blocked crawlers, or a forgotten old domain. Give search engines and users a clean map, and the move becomes much less dramatic.