Domain Migration SEO: How to Move to a New Domain Safely

A Domain Change Is Not Every Kind of SEO Migration

It helps to define the job before building a checklist. A domain migration is a specific type of site move in which the domain or subdomain changes. A CMS replacement, redesign, hosting move or URL restructure can create migration risks too, but they are not automatically domain migrations.

This distinction matters because Google’s Change of Address tool is not used for every URL change. Google says it is intended for moves from one domain or subdomain to another after the site has been moved and redirected.

If your project also changes the CMS, design, URL paths or information architecture, use the broader SEO migration checklist as the main planning document. For this page, the focus is narrower: what changes because the domain itself changes.

Decide What Must Stay Stable Before You Move

A domain change already gives Google a large set of new URLs to process. Adding a redesign, CMS replacement and major content rewrite at the same time makes it harder to tell whether a later problem comes from the new domain or from something else. Google’s site-move guidance recommends changing one major thing at a time where practical.

That makes the first migration decision surprisingly simple: decide what does not need to change.

Keep page purpose and URL relationships recognisable

If a page still serves the same purpose after the move, its new URL should normally be the direct counterpart of the old one. A domain migration is easier to process when the old and new site architecture remain recognisable. If content is also being consolidated or removed, document those exceptions instead of treating them as ordinary domain replacements.

For a straightforward domain-only change where every path remains the same, a server rule may be able to redirect the old host to the matching path on the new host. More complex projects need a page-level mapping. Either way, test the result rather than assuming a wildcard rule covers every important URL.

Check the new domain before it becomes the production domain

Google recommends verifying both old and new sites in Search Console and checking a newly acquired domain for inherited issues such as manual actions or outstanding removals. Ownership verification also needs to remain valid after launch.

Before the switch, confirm that the production version of the new site will be crawlable and indexable. Development environments are often protected with robots rules or noindex. Those controls are useful only if they are removed from the URLs that should enter search when the migration starts.

Record the baseline that will matter after launch

A useful baseline is smaller than an export of every available metric. Record the URLs that matter most because they receive organic clicks, conversions, backlinks or important internal links. Add the current status code, canonical target, indexability and intended new destination. A crawl from a tool such as Screaming Frog SEO Spider can help collect the technical side, while Search Console and analytics provide the search and usage context.

This is also the point to separate migration risk from pre-existing weakness. If a page was already losing traffic or was not indexed before the move, the domain change should not be blamed for creating a problem that was already there.

Build Redirects Around Equivalence, Not Convenience

For a permanent domain move, Google recommends server-side permanent redirects where possible, including HTTP 301 and 308. The important decision is not whether every URL receives a redirect at any cost. It is whether each old URL reaches the most appropriate new destination.

Google’s current redirect guidance treats permanent redirects as a signal that the destination should become canonical. Its site-move documentation also states that 301 and other permanent redirects do not cause a loss of PageRank. That is a better basis for planning than older percentage-based claims about how much authority a redirect supposedly passes.

If you need the basic distinction between temporary and permanent redirects, see MOCOBIN’s guide to 301 and 302 redirects. During a permanent domain change, avoid using a temporary redirect merely because it is easier to reverse.

Directness matters too. Googlebot can follow redirect chains, but Google advises pointing the old URL to the final destination rather than sending it through several intermediate addresses. Internal links on the new site should also point to the final new URLs, not back through the old domain.

Canonical tags need to tell the same story. Each new page should normally use the intended new-domain URL as its self-referencing canonical. If the template still outputs the old domain, the redirect and canonical are giving Google different instructions. MOCOBIN’s canonical tags guide explains how this signal interacts with other duplicate-URL controls.

Launch in an Order That Leaves One Clear Set of Signals

The launch should make the new domain usable first, then make the relationship from old to new explicit. A practical sequence is:

1. Confirm that important new URLs return the intended status code and are not blocked by migration-only noindex or robots rules.
2. Activate permanent redirects from old URLs to their final new equivalents and test representative patterns at scale.
3. Check that canonicals, hreflang annotations where used, navigation and contextual internal links reference the new domain.
4. Verify the relevant old and new Search Console properties and submit Change of Address requests for the applicable old-domain variants.
5. Submit the new-domain sitemap in Search Console and check that the URLs in it use the new canonical host.
6. Update high-value external references you control or can reasonably influence, including major referring links, social profiles and advertising destinations.

The Change of Address step deserves special care. Google requires ownership of both the old and new properties and says the tool should be used after the site has been moved and redirected. It is not a substitute for the redirects themselves.

Google also clarified its domain-variant guidance in 2026. If several old-domain variants or subdomains are being moved, verify the relevant variants in Search Console and submit the applicable changes rather than assuming one request automatically covers every separately addressed property.

Do not use Change of Address for the wrong migration

Do not use the tool for an HTTP-to-HTTPS switch on the same domain, a www-to-non-www change, an internal path change or a hosting move where the visible URLs stay the same. Those cases use other migration signals, such as redirects and canonical consistency, without a Change of Address request.

For teams that are less familiar with Search Console property setup and reports, MOCOBIN’s Google Search Console guide provides the wider product context.

Diagnose the Migration by Pattern, Not by One Traffic Graph

Some volatility is expected while Google recrawls and reprocesses moved URLs. Google says medium-sized sites can take a few weeks or more for new URLs to replace old ones in Search, while larger sites may take longer. That makes a day-to-day ranking change a poor diagnosis on its own.

Start with implementation evidence, then connect it to search performance. The pattern of the loss usually tells you where to look.

Monitor the old and new Search Console properties rather than looking only at the destination domain. Google expects activity on the old site to decline while the new site gains search activity. Server logs and analytics can add another view of whether crawlers and users are reaching the intended destinations.

For a URL shown as Discovered – currently not indexed, remember what the status says: Google knows the URL exists but has not crawled it yet. It is not, by itself, proof that one on-page element is broken. Check discovery paths, crawl accessibility and broader site signals before treating a content rewrite as the only possible fix.

Keep the old domain and redirects long enough

Google’s current site-move guide recommends keeping redirects for as long as possible, generally at least one year, and notes that keeping them indefinitely can still benefit users who reach old URLs. The Change of Address help page separately describes a 180-day processing period for the tool and recommends keeping the old domain registered for at least a year. For operational planning, the longer one-year redirect horizon is the safer minimum.

Do not let the old domain expire as soon as traffic appears to have moved. It may still receive visits from bookmarks, external links, old emails, documents and search results. Keeping ownership and redirect service in place protects those routes and reduces the chance that an abandoned brand domain is acquired by someone else.