Change of Address Now Covers Every Subdomain Variant

A domain migration that stalls halfway is rarely missing its redirects. It is usually missing a signal on a property nobody thought counted — an old www variant, a legacy subdomain that has not served real content in years, a staging host that was verified once and forgotten. On 17 June 2026 Google updated its site move documentation with a changelog entry titled “Site move guidance now includes information on domain variants”, and the clarification closes exactly that gap.

What the tool does, and what it does not replace

Change of Address tells Google that a site has moved from one domain or subdomain to another. Google’s documentation frames the trigger narrowly: use it when moving from one domain or subdomain to another, such as one domain to a different domain, or one subdomain to a different subdomain. It is a declaration, not a mechanism. The redirects still do the work of moving users and consolidating signals, and the documentation is explicit that Change of Address is not needed for an HTTP to HTTPS move, a switch between www and non-www on the same domain, or a move between paths within the same domain.

That last set is where a lot of wasted effort goes. A site owner who has just moved to HTTPS goes looking for the tool, cannot find a reason it applies, and concludes something is broken. Nothing is broken; the move does not qualify.

The 17 June clarification

The guide to a site move with URL changes, which now carries a last-updated date of 2026-08-20 UTC, says to submit Change of Address requests for all verified variants of the old domain, including subdomains and www and non-www versions, pointing at the new domain — and adds that this holds even where those variants are not actively in use. That second half is the part that changes behaviour. A verified property you stopped using still represents a set of signals Google holds, and leaving it unaddressed leaves part of the old site logically unmoved.

The practical consequence is that the migration checklist has to start from your Search Console property list rather than from your sitemap. Every verified variant of the old host is an item. Variants you have never verified are not, which creates an incentive to verify them first rather than to ignore them.

Property type decides your options

A domain property covers every subdomain and both protocols under one verification, which makes it the cleaner starting point for a move but also means the variant question is answered at a different level. A URL-prefix property covers one protocol and one host exactly, so https://www.example.com/ and https://example.com/ are two properties with two sets of data and two Change of Address submissions. Neither type is wrong. The mistake is running a migration without knowing which one you have, because the number of submissions you owe depends entirely on that answer.

The order of operations

Google’s own sequencing for a site move is to prepare the new site, prepare the URL mapping, start the move by putting the redirects in place, then monitor. Its strongest piece of advice is procedural rather than technical: change only one thing at a time, and avoid stacking a domain migration on top of a CMS change or a redesign. The redirect documentation, last updated 2026-04-14 UTC, adds the detail that matters for signal transfer — Google ranks redirect methods by how likely it is to interpret them correctly, and a server-side redirect has the highest chance of being read the way you intended. Permanent redirects show the new target in search results; temporary redirects show the source page. Choosing between 301 vs 308 redirects in migrations is a smaller decision than choosing server-side versus client-side redirects, and only one of those two is reliably interpreted.

Redirects go live before the Change of Address submission, not after. The tool checks that the old home page redirects to the new one before it will accept the request, so a submission attempted first is rejected.

What moves first afterwards, and what lags

The reports do not update in step, and expecting them to produces a fortnight of unnecessary alarm. Crawl activity on the new host rises first, usually within days. Indexed URLs shift across gradually as Google recrawls and processes each redirect, which on a large site is a function of crawl rate rather than of anything you can accelerate. Performance data splits across the two properties for the duration, which is the single most common reason a completed migration looks like a traffic collapse — the traffic is intact, it is just being reported in two places.

Submit a fresh sitemap on the new property and leave the old sitemap reachable rather than deleting it, because it gives Google a list of the URLs that need recrawling to discover the redirects. On a large catalogue that discovery step is the whole timeline, which is why the same sitemap best practices for large sites that govern ordinary indexing govern the pace of a migration too.