Mueller: set up Change of Address for both www and non-www

for both the www and non-www versions of…

Summary

Change of Address appears to be processed per verified property, not per domain, so a move filed only from the version you treat as canonical leaves the other version unmigrated and the old domain available as a canonical choice.

The check costs a minute. Open Search Console, list every verified variant of the old domain, and confirm a move is filed from each one to its match on the new domain.

Google’s John Mueller, asked why a domain move came undone four months after it had finished, pointed at a configuration check rather than a timeline: make sure Change of Address is set up in Search Console for both the www and non-www versions of the old domain. Search Engine Journal’s write-up carries the exchange, from a Reddit thread about a move Google had already processed and then reversed.

The site owner reported changing domain at the start of 2026, with the redirects, the Change of Address and the internal name changes all done at once. Traffic was back by April, at around 5,000 impressions a day. Four months after that, by their account, Google restored the old domain’s visibility and dropped the new one. More than 5,000 pages on the new domain switched to “Crawled - currently not indexed”. The new domain now gets 20 impressions a week, and the old domain’s Search Console property shows the clicks instead.

Mueller’s reply named one specific check. “One thing which we noticed (and adjusted in the documentation a while back) that can help is to make sure that you have change of address set up in search console for both www and non-www, so that it can fully migrate the domain.” He also said that things sometimes take a particularly long time to be fully processed, which fits the recrawl ranges Google has given for site moves, and offered to look at the domains if the owner sent them by DM.

The documentation change is live. Google’s site move guidance now says to submit Change of Address requests for all verified variants of the old domain, including subdomains and the www and non-www versions. Mueller does not spell out why one request is not enough, but the likelier explanation is that Search Console processes the move per verified property rather than per domain. A request filed from the version you treat as canonical says nothing about the other version, and inbound links do not care which one you prefer. Search Engine Journal’s piece makes the same point, noting that external links to one variant or the other could contribute to Google choosing the old domain as canonical, and treats a stalled migration as a canonicalization problem.

The owner also asked whether any of this needs fixing, since old-domain results still redirect to the new pages and the visits still arrive. It does. Analytics will look healthier than Search Console, because the click lands on an old-domain result and the user ends up on the new page anyway. The indexed URL is still the old one, so every new page, every new link and every report keeps attaching to a domain that was supposed to be retired. A redirect that works is not the same as a migration that completed.

Other causes to rule out

Search Engine Journal lists what the Reddit post does not say, and each item is worth ruling out before settling on slow processing as the explanation:

  • Absolute internal links that still carry the old domain. They survive in navigation, footers and contextual links in body copy, and a full crawl of the site is what finds them.
  • A registrar-level forward instead of URL-to-URL redirects. Registrar forwarding may not preserve the path, and HTTPS forwarding can fail when the old domain has no SSL certificate.
  • Chained redirects, where an old URL passes through one or more hops before reaching its destination.
  • Navigation or URL structure changes on the new site, which quietly break the targets the redirect map was written against.
  • A submitted XML sitemap still listing old-domain URLs, which hands Google conflicting canonical preferences during the window when it is deciding.

What to do

  1. List every verified property for the old domain in Search Console (www, non-www, any subdomains, and the http prefix if it is verified as a separate property) and file a Change of Address from each one to its matching new property. A move already filed from one property does not cover the rest.
  2. Spot-check redirects end to end: old URL to its exact new counterpart, one hop, over HTTPS, path intact.
  3. Crawl the new site for links and canonical tags that still contain the old domain, and fix the sitemap so it lists new-domain URLs only.
  4. If the properties are all filed and the redirects are clean, judge the gap on lost revenue rather than traffic dips before undoing anything.

Mueller offering to look at individual domains is a favour, not a support channel. The properties check is the part any in-flight migration can run today.