Should you use the address change tool when switching from m. to www.?

Why is there confusion surrounding the address change tool?

The address change tool in Search Console has always been a source of misunderstandings. Many SEOs thought it had to be used systematically whenever a URL migration occurred, regardless of its nature.

However, John Mueller clarifies that this tool is intended for moves between distinct domains — typically when you switch from exemple.fr to nouveausite.fr. Not for changes in subdomains or internal structure within the same root domain.

What exactly does Google automatically detect?

When you implement 301 redirects from m.exemple.com to www.exemple.com, Googlebot discovers them during its regular crawl. It follows the redirect, understands that the old URL no longer exists, and gradually transfers ranking signals to the new one.

This process occurs without any manual intervention on your part in Search Console. The bot can follow the chain of redirects, identify the final canonical URL, and reassign backlinks and crawl history. This works for mobile to desktop subdomain migrations, as well as for other types of internal restructuring.

In what context is this tool still relevant?

The tool remains useful when you entirely change your domain name. If you move from anciensite.com to nouveausite.com, the tool helps speed up detection by Google and transfer some Search Console data from the old to the new.

It also explicitly informs Google of your intention to migrate, which can smooth the process and limit temporary fluctuations in organic traffic. But for a simple switch from m. to www., this formal signal brings nothing — Google doesn’t need it to understand what is happening.

• The address change tool is only for migrations between distinct domains, not for subdomains or internal restructurings
• 301 redirects are sufficient: Google automatically detects them during crawling and transfers signals
• No impact on crawl budget or SEO if the redirects are correctly configured
• The tool can expedite domain migration detection and transfer certain Search Console data
• In any case, monitor coverage and performance reports to ensure the transition goes smoothly

Is this statement consistent with observed practices on the ground?

Yes, overall. Mobile to desktop subdomain migrations generally go well if the redirects are clean and the internal linking is adjusted. SEOs who have attempted to use the address change tool in this context report that it had no measurable effect — which confirms Mueller's statements.

That said, the speed of detection and signal transfer varies greatly depending on the site's crawl frequency. On a small site with low crawl rates, the transition can take several weeks. On a large site with a high crawl budget, it can happen very quickly. [To verify]: Mueller does not clarify whether Google can prioritize crawling old redirected URLs to expedite the transition — it's a gray area.

What nuances need to be added to this statement?

The statement "this change has no effect on crawl budget or SEO" deserves clarification. What Mueller means is that not using the tool has no negative effect. But the migration itself, if poorly managed, can certainly impact SEO.

For example, if you leave redirect chains hanging (m.site → temporaire.site → www.site), or if you forget to update canonical tags and the XML sitemap, you will dilute signals and slow down the transfer of authority. Google will detect the redirects, but that doesn’t mean it will handle them optimally if the structure is shaky.

In what cases does this rule not apply?

If your site has a complex architecture — multiple subdomains, international versions, partial migrations — there can be ambiguities for Google. In these cases, an explicit signal via the tool could theoretically help, even if Mueller says it is not necessary.

Another case: if you have historically used mobile annotations (rel="alternate" and cross rel="canonical" between m. and www.), and you transition to a responsive site, the transition may cause temporary confusion. Google will need to understand that the old annotations no longer apply. Again, the tool changes nothing, but it’s important to closely monitor coverage reports to detect any potential indexing errors.

What should you concretely do during a migration from m. to www.?

First, set up permanent 301 redirects from all m.site URLs to their www.site equivalents. Check for redirect chains or loops. Use a crawler (Screaming Frog, Oncrawl) to audit all migrated URLs.

Next, update your XML sitemap to include only the new www URLs. Remove or disable the old m. sitemap in Search Console. Resubmit the new sitemap and force a revalidation via the URL inspection tool on a few key pages to speed up detection.

What mistakes should be avoided during the transition?

Do not leave old URLs accessible with a 200 status alongside the new ones — it is the perfect recipe for duplicate content. If you had mobile rel="alternate" annotations, remove them completely once the site is responsive.

Avoid also modifying other technical elements (changing CMS, redesigning templates, altering URL structures beyond m. → www.) at the same time as this migration. One migration at a time. If you combine changes, you won’t be able to isolate the cause of any potential traffic drop.

How to check that the migration is going smoothly?

Closely monitor the coverage report in Search Console. You should see the old m. URLs gradually disappearing from the index (status “Redirected”) and the new www. appearing. If any m. URLs remain indexed several weeks after the redirects are set up, force a reindex via the inspection tool.

Also compare the organic traffic performance before/after over a rolling period of 4 to 6 weeks. A slight temporary decrease (5-10%) is possible while Google consolidates signals, but a sharp drop indicates a technical problem — broken redirects, erroneous canonicals, loss of internal linking.

• Set up permanent 301 redirects from m.site to www.site, without chains or loops
• Update the XML sitemap to retain only the new www URLs.
• Remove mobile rel="alternate" annotations if the site becomes responsive
• Do not use the address change tool in Search Console (useless for this type of migration)
• Monitor the coverage report: old URLs should change to “Redirected” status
• Compare organic traffic before/after over 4 to 6 weeks to detect any anomalies