A domain migration is no longer just a redirect map and a single Search Console form. Google now wants every old-domain variant accounted for, including subdomains and both www and non-www versions.
That raises the bar for one of the riskiest technical SEO projects a business can take on.
Google added the new direction to its Search Central site move documentation on June 17, confirming that domain migrations should include Change of Address requests for all subdomain variants, even when some versions are not actively used. The company’s explanation was brief: “The domain migrations work best when all variants of a site are migrated properly,” according to Google’s Search Central documentation updates.
The Forgotten Versions of a Domain Now Matter More
The update applies to domain-to-domain moves, such as shifting from example.com to new-example.net, merging domains, or changing hostnames in a way that affects existing URLs.
Google’s revised site move documentation now tells site owners to submit Change of Address requests for all subdomains and the www and non-www variants of the old domain name. Its example includes en.example.com, www.example.com, and example.com moving to a new domain.
That detail matters because many migration plans focus only on the primary canonical domain.
A company may use example.com publicly while treating www.example.com as legacy infrastructure. A regional subdomain may have been retired years ago. A language subdomain may still collect links from old campaigns, directories, partner profiles, PDFs, email signatures, or forgotten landing pages.
Google is now making those variants part of the migration workflow.
For SEO teams, the practical risk is not that unused hostnames suddenly become important on their own. The risk is that Google may still discover signals, links, redirects, or crawl paths connected to those variants. If they are left outside the migration process, the move may be less clean than the team assumes.
Change of Address Is Not for Every Site Move
Google’s Change of Address tool has a narrow purpose. It is designed for domain migrations, not every technical update that changes how a site is served.
Google’s guidance still says the tool is not needed for HTTP-to-HTTPS migrations. It is also not the mechanism for changing URL paths, switching between www and non-www alone, moving hosts, or changing CDN providers when the URLs remain the same.
That distinction is important.
A site that moves from http://example.com to https://example.com needs redirects and HTTPS configuration, but not a Change of Address request. A site that changes from example.com/products/widget to example.com/shop/widget needs mapping, redirects, canonicals, and monitoring, but the tool is not meant to handle that path-level restructure.
A site that moves from example.com to new-example.net is different.
That is where Google now wants the old domain’s variants verified in Google Search Console and submitted through the Change of Address process. For marketers tracking Google Search Console reporting changes, this update reinforces a broader pattern: Search Console is increasingly where Google wants site owners to formalize ownership, visibility, and transition signals.
Verification Becomes a Pre-Launch Migration Task
The new requirement pushes Search Console verification earlier in the site migration timeline.
Google says all relevant old-domain variants should be verified in Search Console before the Change of Address requests are submitted. That can create extra work for teams that treated Search Console setup as a launch-day item.
It also creates a governance issue.
Large organizations often have fragmented domain ownership. Marketing may control the main website. IT may control DNS. Regional teams may have subdomains. Legacy microsites may sit in older CMS installations. Agencies may have access to some properties but not all. Legal or brand teams may own domains that redirect quietly in the background.
A migration can look ready in a redirect spreadsheet while Search Console ownership remains incomplete.
That gap is easier to miss than a broken redirect. It does not always show up in staging QA. It may not appear in a visual site review. It sits in the ownership layer, where SEO, development, DNS, and analytics access overlap.
The update also fits Google’s broader technical SEO advice: verify both old and new sites, review Search Console settings, keep redirects active for at least one year, submit new sitemaps, and monitor both old and new URL performance after launch. Google also recommends server-side permanent redirects, such as 301 or 308 redirects, where technically possible.
Redirects Still Carry the Main Load
The Change of Address tool does not replace a migration plan.
Google’s documentation still centres the process on accurate URL mapping, permanent redirects, canonical checks, sitemap submission, and post-launch monitoring. The new variant guidance adds another layer to that workflow; it does not remove the work underneath it.
That distinction will matter for businesses planning rebrands, acquisitions, international consolidations, or platform moves.
A Change of Address request can help Google understand that a domain has moved. It will not fix homepage-only redirects, irrelevant destination mapping, noindex tags left on the new site, blocked crawling, canonical tags pointing back to the old domain, or broken internal links.
It also does not eliminate ranking volatility.
Google continues to warn that significant site changes may cause temporary ranking fluctuations while pages are recrawled and reindexed. For small and medium-sized websites, Google generally recommends moving all URLs simultaneously when feasible, while larger sites may need staged migrations to monitor and fix problems more carefully.
That makes the new domain-variant step another migration control point, not a silver bullet.
The practical implication for marketers and SEOs is straightforward: domain migration SEO checklists should now include a property inventory before launch. Teams should identify every old-domain version, verify each relevant property in Google Search Console, confirm the redirect logic for those variants, submit Change of Address requests where appropriate, and monitor old-versus-new URL performance after the move. This is standard migration hygiene, but Google’s update makes the variant layer harder to ignore.
Migration Risk Is Shifting Into the Details
For years, the visible part of a site migration got the most attention: new design, new CMS, new URL structure, new brand, new analytics dashboard.
The failure points are usually quieter.
A redirect chain that adds latency. A canonical tag that points to the wrong host. A disavow file not re-uploaded to the new property. A high-value backlink still landing on an old subdomain. A staging noindex rule left behind. A domain variant no one remembered to verify.
That is where this update lands.
The guidance also arrives during a period when SEO measurement is becoming more fragmented across classic web results, AI features, Discover, and other Search surfaces. TechWyse has covered that measurement pressure in reports on Google’s May 2026 core update review process and Google’s recent clarification that SEO fundamentals still apply in AI search.
Domain migrations cut through all of it.
If Google receives mixed or incomplete signals during a move, every downstream performance report becomes harder to interpret. Was the traffic dip caused by ranking changes, recrawl timing, AI visibility shifts, a redirect issue, or an unhandled domain variant?
A cleaner migration does not guarantee a flat traffic line. It does reduce the number of avoidable variables.
Google’s latest documentation change is small on the page, but operationally meaningful. Domain moves now require a wider inventory of the old site’s identity, not just the version users see in the browser today.
