Faut-il vraiment utiliser l'outil de changement d'adresse pour migrer entre sous-domaines ?

Pourquoi Google fait-il cette distinction entre domaines et sous-domaines ?

L'outil de changement d'adresse a été conçu pour gérer les signaux au niveau du domaine racine. Quand vous passez de ancien-site.com à nouveau-site.com, vous changez complètement d'identité aux yeux de Google.

Les signaux historiques — autorité, backlinks, trust — doivent être transférés explicitement. C'est là que l'outil intervient : il accélère le processus en signalant à Google que les deux domaines sont liés et que l'ancien doit être remplacé par le nouveau dans l'index.

En revanche, les sous-domaines partagent déjà le même domaine racine. Google les traite comme des entités distinctes pour le crawl et l'indexation, mais ils bénéficient d'une reconnaissance commune au niveau du domaine principal. Une migration entre m.domain.com et www.domain.com reste dans la même « famille » — pas besoin d'outil supplémentaire.

Qu'est-ce que cela change concrètement pour une migration mobile ?

La plupart des migrations entre sous-domaines concernent l'abandon d'un site mobile séparé (m.example.com) au profit d'un design responsive (www.example.com). C'est un scénario classique que beaucoup de sites ont traversé.

Dans ce cas, les redirections 301 permanentes suffisent amplement. Chaque URL de m.example.com/page doit rediriger vers www.example.com/page. Google suivra ces redirections, consolidera les signaux page par page, et mettra à jour son index progressivement.

L'outil de changement d'adresse n'accélère rien ici. Il ne fait que compliquer inutilement le processus en ajoutant une couche administrative qui n'a aucun impact technique réel sur le transfert des signaux entre sous-domaines.

Quels sont les signaux transférés automatiquement avec de simples redirections ?

Google suit les redirections 301 et consolide la plupart des signaux de classement vers la nouvelle URL. Ça inclut le PageRank transmis par les backlinks, les signaux comportementaux, l'ancienneté de la page, et même une partie de l'historique de performance.

Ce processus est automatique et ne nécessite aucune intervention manuelle via Search Console. La seule condition : que les redirections soient propres, permanentes (301) et en place suffisamment longtemps pour que Google recrawle toutes les anciennes URLs.

• Les redirections 301 suffisent pour transférer les signaux entre sous-domaines du même domaine racine
• L'outil de changement d'adresse est réservé aux migrations complètes de nom de domaine (ancien-site.com → nouveau-site.com)
• Aucun impact SEO négatif à ne pas utiliser l'outil lors d'une migration m.domain.com → www.domain.com
• Le crawl et la consolidation se font naturellement via les redirections, sans accélération particulière de l'outil
• Search Console traite chaque sous-domaine comme une propriété séparée, mais le domaine racine reste commun

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est même rassurant. Des centaines de migrations entre sous-domaines ont été réalisées sans utiliser l'outil de changement d'adresse, avec des résultats parfaitement normaux. Pas de perte de ranking anormale, pas de délai supplémentaire dans la consolidation des signaux.

En revanche, certains SEO ont tenté d'utiliser l'outil « par précaution » lors de migrations m. → www. et ont constaté… strictement aucune différence. L'outil ne renvoie d'ailleurs aucune erreur ni confirmation spécifique dans ce contexte — il semble simplement ignoré par Google.

Ce qui compte réellement, c'est la qualité des redirections, la mise à jour des sitemaps, et la vérification que toutes les anciennes URLs renvoient bien un code 301 propre. Le reste est cosmétique.

Dans quels cas cette règle pourrait-elle poser problème ?

Soyons honnêtes : cette déclaration reste assez générale. Elle ne couvre pas explicitement certains cas limites. Par exemple, que se passe-t-il si vous migrez simultanément de m.ancien-domain.com vers www.nouveau-domain.com ? Changement de sous-domaine ET de domaine racine.

Dans ce scénario hybride, [À vérifier] si l'outil de changement d'adresse doit pointer l'ancien domaine racine vers le nouveau, ou si les redirections 301 suffisent encore. Google ne précise pas ce cas précis, et les retours terrain sont rares.

Autre zone grise : les sous-domaines complètement indépendants (blog.domain.com, shop.domain.com) qui fusionnent vers www.domain.com/blog et www.domain.com/shop. Techniquement, c'est toujours une migration entre sous-domaines, mais la structure de l'information change radicalement. Les redirections doivent être ultra-précises, et un suivi rigoureux dans Search Console devient indispensable.

Quelles nuances faut-il apporter à cette déclaration ?

Mueller parle de « signaux au niveau du domaine », mais il ne détaille pas lesquels exactement. On sait que le trust, l'autorité globale, et certains signaux historiques sont attachés au domaine racine. Mais quid des pénalités manuelles ? Des actions anti-spam ?

Si un sous-domaine a été pénalisé, cette pénalité ne se transfère pas automatiquement via l'outil de changement d'adresse de toute façon — c'est attaché à l'URL, pas au domaine racine. Mais Google ne clarifie jamais ce point dans ce contexte.

Autre élément absent : le délai de consolidation. Mueller ne dit pas si utiliser l'outil accélère ou non le transfert lors d'un vrai changement de domaine. Des tests montrent que l'impact est marginal, mais Google ne publie aucune donnée chiffrée là-dessus.

Que faut-il faire concrètement lors d'une migration entre sous-domaines ?

Première étape : mettre en place des redirections 301 permanentes pour chaque URL de l'ancien sous-domaine vers son équivalent sur le nouveau. Pas de redirections temporaires (302), pas de redirections en chaîne (m. → temp. → www.), et surtout pas de pages orphelines qui renvoient 404.

Ensuite, soumettez un nouveau sitemap XML dans Search Console pour le nouveau sous-domaine. Supprimez ou désindexez l'ancien sitemap du sous-domaine source. Google doit comprendre que le contenu se trouve désormais ailleurs.

Vérifiez que les anciennes URLs ne génèrent aucune erreur de crawl dans Search Console. Les redirections doivent être immédiates, renvoyer un code HTTP 301, et pointer vers la bonne URL finale — pas vers une page générique ou une homepage.

Quelles erreurs éviter absolument ?

Ne laissez jamais les anciennes URLs accessibles en parallèle des nouvelles. C'est la duplication de contenu garantie. Si m.domain.com/page et www.domain.com/page répondent toutes les deux en 200, Google doit choisir laquelle indexer — et ce choix ne sera pas toujours celui que vous souhaitez.

Évitez aussi de supprimer brutalement l'ancien sous-domaine avant que Google n'ait eu le temps de recrawler toutes les redirections. Laissez les redirections en place au minimum 6 mois, idéalement 12 mois, pour que les backlinks externes soient bien consolidés.

Dernière erreur fréquente : ne pas mettre à jour les liens internes qui pointent encore vers l'ancien sous-domaine. Même avec des redirections en place, c'est du crawl budget gaspillé et un signal de qualité dégradé.

Comment vérifier que la migration s'est bien déroulée ?

Surveillez le rapport de couverture dans Search Console. Les anciennes URLs doivent progressivement passer en « Redirigée » et disparaître de l'index. Les nouvelles URLs doivent être indexées sans erreur.

Comparez les positions moyennes et le trafic organique avant/après migration. Une baisse temporaire de 10-15% est normale le temps que Google consolide les signaux. Si la chute dépasse 30% ou persiste au-delà de 4-6 semaines, il y a un problème structurel à identifier.

Enfin, vérifiez les logs serveur pour confirmer que Googlebot crawle bien les nouvelles URLs et suit correctement les redirections. Un pic de crawl sur l'ancien sous-domaine suivi d'un transfert progressif vers le nouveau est le comportement attendu.

• Mettre en place des redirections 301 permanentes pour chaque URL de l'ancien sous-domaine
• Soumettre un nouveau sitemap XML pour le nouveau sous-domaine dans Search Console
• Vérifier que toutes les anciennes URLs renvoient bien un code 301 et aucune erreur 404
• Mettre à jour tous les liens internes pour pointer directement vers les nouvelles URLs
• Surveiller le rapport de couverture dans Search Console pendant au moins 3 mois
• Comparer le trafic organique et les positions avant/après migration pour détecter toute anomalie