Should you really avoid the address change tool when merging multiple ccTLDs?

Why does the address change tool pose issues in this scenario?

The address change tool in Google Search Console was designed to notify Google of a simple site move: domain A becomes domain B. It operates on a logic of strict one-to-one mapping, meaning that a source URL corresponds to a single destination URL.

When merging multiple ccTLDs (country-code Top Level Domains, like .fr, .de, .co.uk) into a single domain with language subdirectories (/fr/, /de/, /uk/), this logic falls apart. Each ccTLD potentially contained thousands of URLs, and consolidating them into a single subdirectory creates multiple matches that the tool cannot handle.

What exactly is one-to-one mapping?

One-to-one mapping means that every URL from the old site must point to only one URL on the new site, without duplication or grouping. For example: example.fr/page-a → example.com/fr/page-a works. But if example.fr and example.de redirect to example.com/fr/, the tool no longer understands.

This technical constraint arises because the tool must transfer ranking signals (PageRank, crawl history, authority) cleanly. When multiple domains converge to a single space, Google cannot automate this transfer without risking confusion or loss of signals. Thus, manual 301 redirects remain the preferred method as they allow for granular control over the flow of authority.

Are redirects really enough to manage this type of migration?

Yes, if they are correctly configured. 301 redirects pass most of the PageRank and ranking signals according to Google. The real challenge lies in planning the mapping URL by URL, especially when the content structures differ between ccTLDs.

A ccTLD may have organized its content differently (categories, taxonomies, URLs) than another. Without a rigorous and tested mapping file, there is a risk of chained redirects, loops, or worse, massive 404s. Google recommends redirects because they force the practitioner to document and validate each match before migration, reducing errors.

• The address change tool only works for simple domain-to-domain migrations with strict one-to-one mapping.
• Merging multiple ccTLDs into subdirectories creates multiple matches incompatible with this tool.
• Manual 301 redirects remain the preferred method as they allow for granular control and custom mapping.
• A rigorous URL mapping file is essential to avoid traffic loss and authority dilution.
• Google transfers ranking signals through 301 redirects, but monitoring the transfer in Search Console remains crucial for 6 to 12 months post-migration.

Is this recommendation truly applicable in all cases of merging?

Let's be honest: Mueller's statement is technically correct but practically incomplete. Yes, the address change tool does not handle multi-domain mergers. But simply saying "use redirects" overlooks the real complexity of these migrations.

In practice, merging multiple ccTLDs requires much more than redirects. It necessitates managing hreflang tags (which become critical for signaling new language matches), reviewing information architecture, anticipating cannibalization between similar content from different countries, and monitoring the transfer of authority domain by domain. [To be verified]: Google has never published data on the success rate of these migrations or the proportion of authority actually transferred.

What risks does this approach fail to mention?

The statement glosses over the risks of authority dilution when multiple referring domains merge. Each ccTLD likely developed its own backlink profile and geographic authority. Consolidating all of this into a single domain does not guarantee a simple addition of authorities.

Second point: the transfer timeline. Google claims that 301 redirects pass PageRank, but the consolidation time varies greatly according to field observations. Some sites regain visibility in 3-4 months, while others stagnate for a year. Mueller does not give any indication of the factors influencing this timing or how to accelerate it. Practitioners must therefore navigate uncertainly.

In which cases does this rule not apply or become counterproductive?

If the ccTLDs have very uneven performance (one strong domain, three weak domains), it may be counterproductive to merge blindly. Migrating a weak ccTLD to the main domain can introduce low-quality content and dilute overall authority. In this case, it may sometimes be better to abandon certain ccTLDs rather than merge everything.

Another edge case: ccTLDs with toxic backlink profiles or historical manual penalties. Merging these domains without prior auditing can transfer negative signals to the main domain. Google never specifies whether redirects also transfer penalties, but observations show that it can sometimes be the case. So caution is warranted.

How do you concretely plan a multi-ccTLD migration to subdirectories?

First step: create a comprehensive mapping file listing every URL from each ccTLD and its exact destination in the new structure. This file must be manually validated to avoid mapping errors. Use tools like Screaming Frog or Oncrawl to crawl each ccTLD and export the URLs.

Second step: implement 301 redirects on the server side (Apache, Nginx, or via CDN). JavaScript or meta refresh redirects do not reliably pass ranking signals. Configure redirects by geographic block (all .fr URLs to /fr/, all .de URLs to /de/) while managing exceptions page by page if necessary.

What errors should you absolutely avoid during the migration?

A classic mistake: launching the migration without configuring hreflang tags on the new domain. Google needs to understand that /fr/ replaces .fr for French-speaking users. Without hreflang, Google may continue to index the old ccTLDs or create geographic confusion.

Another pitfall: not monitoring the crawl budget post-migration. When Google recrawls the old ccTLDs, follows the redirects, and discovers the new structure, it consumes a tremendous budget. If your server slows down or Google crawls too slowly, the transfer of authority can take months. Check server logs and adjust the crawl speed in Search Console if needed.

How do you verify that the migration is proceeding correctly?

Monitor daily in Search Console the number of indexed URLs for each old ccTLD (which should decrease) and for the new domain (which should increase). Use coverage reports to detect 404 errors or chained redirects that break the transfer.

Also monitor organic traffic performance by country in Google Analytics or Search Console. If a specific country loses traffic disproportionately, it signals that the hreflang or redirects for that segment have an issue. React immediately rather than waiting for Google to "figure it out on its own".

• Create a comprehensive URL mapping file validated manually before any redirects
• Implement server-side 301 redirects (Apache/Nginx), never via JavaScript or meta refresh
• Configure hreflang tags on the new domain before migration to avoid geographic confusion
• Monitor crawl budget and server logs to detect slowdowns post-migration
• Check Search Console daily: indexed URLs, 404 errors, chained redirects
• Analyze organic traffic performance by country to detect abnormal losses in specific segments