Change Domains Without Throwing Away Your SEO Signals

Changing a domain does not automatically erase a site’s search history, but a careless migration can make search engines rediscover the site as if its URLs were unrelated. The safest approach is to treat the move as a URL migration, not a branding task.

The short version is: keep the page structure stable where possible, map every important old URL to its closest new equivalent, use permanent server-side redirects, update canonical signals and sitemaps, then monitor both domains until the move settles. Do not change the domain, CMS, information architecture, and content strategy all at once unless you have a strong reason.

That sequence matters because search engines need consistent signals that an old URL and a new URL represent the same resource.

Start With a URL Map, Not DNS

DNS only determines where a hostname resolves. It does not explain that old.example.com/guides/android has moved to new.example.com/guides/android.

Before touching production, export the URLs that matter and create a mapping table:

Old URL	New URL	Action
/	/	301
/guides/android	/guides/android	301
/blog/old-slug	/articles/new-slug	301
/obsolete-page	closest relevant replacement, or 404/410	deliberate decision

Preserving paths is usually the simplest migration because the redirect rule can remain predictable. If paths must change, map them explicitly. Avoid sending every old page to the new homepage. A redirect should lead users and crawlers to the most equivalent destination.

This is also why a portable publishing stack helps. If the content model already separates URLs, metadata, and deployment configuration, a migration becomes a controlled infrastructure change rather than a rewrite. The same principle appears in our guide to choosing a publishing stack for a technical blog.

Use Permanent Redirects for a Permanent Move

Google documents HTTP 301 and 308 as permanent server-side redirects. For a domain migration that you do not plan to reverse, a permanent redirect is the clearest signal.

A simple Nginx host redirect can preserve the path and query string:

server {
    listen 443 ssl;
    server_name old.example.com;

    return 301 https://new.example.com$request_uri;
}

The exact configuration differs across Nginx, Apache, Cloudflare, managed hosts, and application frameworks, but the invariant is the same: an old URL should resolve in one hop to the correct new URL.

Test the response itself, not just what the browser displays:

curl -I https://old.example.com/guides/android

You want to see a permanent redirect and the expected Location header. Then test the destination:

curl -I https://new.example.com/guides/android

The destination should return a healthy response rather than another avoidable redirect.

Keep Canonical Signals Consistent

Redirects are only one signal. The new site should stop telling crawlers that the old domain is canonical.

After the cutover, check at least these locations:

• rel="canonical" tags
• XML sitemaps
• internal links
• hreflang URLs, if used
• structured data containing absolute URLs
• Open Graph and other share metadata
• feeds and API responses that publish absolute URLs

Google recommends consistent canonical signals. A new page that redirects correctly but still declares the old URL as canonical creates unnecessary ambiguity.

For a page on the new domain, a self-referencing canonical is a sensible default:

<link rel="canonical" href="https://new.example.com/guides/android">

Generate a sitemap containing the new canonical URLs and submit that sitemap after the move. Keep the old-domain redirects active while crawlers and users continue to encounter old links.

Use Search Console After the Technical Move

For a full domain or subdomain migration, Google’s Change of Address tool can help communicate the move after the redirects and other migration work are already in place. It is not a substitute for redirects.

Verify both the old and new properties first. Then use Search Console to watch whether Google can fetch the new URLs, whether old URLs are being replaced, and whether indexing errors are appearing.

The important distinction is operational: Search Console reports and communicates the migration; your HTTP behavior performs it.

For partial moves, path-only changes, or HTTP-to-HTTPS migrations, follow the relevant site-move guidance rather than assuming the Change of Address tool applies.

Do Not Stack Unrelated Changes Into the Same Cutover

A domain change already forces crawlers to process a large set of URL transitions. Combining it with a redesign, new framework, new navigation, rewritten content, and different URL structure makes failures harder to diagnose.

Prefer two phases:

1. Move the existing site to the new domain with minimal content and URL changes.
2. After redirects, indexing, and traffic stabilize, make the larger product or content changes.

This reduces the number of variables when something goes wrong. If traffic falls, you can investigate the migration instead of guessing whether the cause was redirects, rendering, content edits, or navigation.

Build a Migration Test Matrix

A migration should be testable before and after DNS changes. Sample URLs from different page types and states.

Check	Expected result
Old homepage	301/308 to new homepage
Old article	301/308 to equivalent new article
Old URL with query parameters	intended parameters preserved or deliberately normalized
New canonical page	200 and self-canonical
Removed content	intentional 404/410 or relevant replacement
Sitemap URL	new domain only
Internal navigation	no old-domain links
Redirect chain	ideally one hop

Automate the boring part. A small script can read the migration map, request every old URL without automatically following redirects, and compare the returned Location header with the expected destination.

For example:

import csv
import requests

with open("migration.csv", newline="") as file:
    for row in csv.DictReader(file):
        response = requests.get(row["old_url"], allow_redirects=False, timeout=10)
        assert response.status_code in (301, 308)
        assert response.headers["Location"] == row["new_url"]

Run the same test from CI or an external machine after the cutover. That catches rules that worked locally but were not deployed at the edge.

Keep the Old Domain Under Your Control

A migration is not finished when the new homepage loads.

Old URLs may remain in bookmarks, documentation, backlinks, email campaigns, mobile apps, and search indexes for a long time. Keep the old domain registered and keep the redirects running. Google recommends maintaining redirects for at least 180 days and recommends retaining control of the old domain for at least a year.

In practice, keeping a low-cost domain registered longer can be worthwhile when it still receives meaningful links or traffic. The operational cost is usually much smaller than the cost of breaking every old reference at once.

Monitor the Migration Like a Release

Create a baseline before cutover so you have something to compare against. Useful signals include:

• indexed pages on both properties
• organic clicks and impressions
• crawl and server errors
• top landing pages
• redirect failures
• 404 volume
• sitemap processing
• external traffic still reaching the old domain

Do not interpret normal transition noise as proof that the migration failed. Google notes that site moves can cause temporary ranking fluctuations while URLs are recrawled and reindexed.

What matters is whether the migration signals remain coherent: old URLs redirect permanently, new URLs are crawlable and canonical, internal links point to the new domain, and indexing gradually shifts.

A Safer Domain Migration Sequence

A durable runbook looks like this:

1. Verify ownership of both domains.
2. Inventory important URLs and backlinks.
3. Create an old-to-new URL map.
4. Prepare the new domain with equivalent content.
5. Update canonicals, internal links, sitemaps, and absolute metadata.
6. Deploy permanent redirects from old URLs to their mapped destinations.
7. Test status codes, destinations, chains, TLS, robots rules, and rendering.
8. Submit the new sitemap.
9. Use Search Console’s Change of Address tool when the move qualifies.
10. Monitor both properties and server logs.
11. Keep the old domain and redirects active.
12. Make unrelated redesigns only after the migration stabilizes.

The goal is not to guarantee identical rankings on a particular day. No migration can promise that. The goal is to preserve identity signals so users and crawlers can follow each old resource to its new home with as little ambiguity as possible.

A domain is replaceable. A clean URL history is much harder to rebuild. Treat the redirect map, canonical metadata, and monitoring plan as production infrastructure, and changing domains becomes a controlled migration instead of an SEO reset.