Récemment, Google – via John Mueller – a répondu à une question sur la manière dont Google gère les migrations de site réalisées par étapes, c’est‑à‑dire lorsqu’un site est partiellement déplacé d’un nom de domaine vers un autre. Sa première réponse indiquait qu’un déplacement de site standard n’était généralement pas problématique, mais il a précisé sa position lorsqu’il s’est agi de déplacements partiels.

Un déplacement total, ou seulement en surface ?

La question initiale donnait l’impression qu’il s’agissait de transférer l’intégralité du site. L’auteur s’interrogeait sur l’utilisation de l’outil Change of Address de la Search Console pour notifier Google du transfert vers un nouveau domaine.

La personne avait publié ce message et demandé des précisions :

Voir le post de John Mueller

La question posée portait sur l’opportunité d’activer l’outil de changement d’adresse si certaines anciennes URL continuent de recevoir du trafic et ne sont pas encore redirigées. Faut‑il attendre que toutes les redirections soient en place ?

Dans un premier temps, Mueller a indiqué que cela pouvait généralement fonctionner :

Il a expliqué qu’un déplacement de site global était souvent accepté, en donnant l’exemple où le fichier robots.txt de l’ancien domaine autorisait encore l’exploration via « allow: / ». Toutefois, il a précisé que l’outil vérifie la redirection de la page d’accueil.

Pourquoi un transfert partiel complique les choses selon Google

La situation a été clarifiée quand l’auteur a précisé que la page d’accueil allait être transférée vers le nouveau domaine, tandis qu’une grande partie des pages produits et catégories resterait sur l’ancien domaine pour le moment. Autrement dit : une partie du site déménage tout de suite, l’autre partie restera en place pendant une période indéterminée.

Cela change complètement la nature de l’opération. Sans surprise, la position exprimée par Mueller a évolué.

Il a expliqué que, dans la pratique, Google ne considérerait pas l’opération comme un déplacement de site complet. On peut toujours utiliser l’outil de Change of Address, mais la situation restera compliquée tant que toutes les ressources n’auront pas été transférées et correctement redirigées.

Concrètement, cela ne sera pas perçu comme une migration totale. L’outil peut être utilisé, mais la situation sera désordonnée jusqu’à ce que le transfert soit finalisé. Si vous êtes contraints d’agir ainsi, sachez que le résultat ne sera pas « propre ». Vous aurez des difficultés à suivre l’évolution, et Google aura du mal à comprendre l’organisation de vos sites. Mon conseil est d’assainir la situation dès que possible. Même les migrations bien planifiées et exécutées peuvent être délicates ; les opérations fragmentées rendent l’ensemble beaucoup plus complexe.

Related : Google : ne combinez pas un déplacement de site avec d’autres changements majeurs

Comment Google « comprend » un site

Un point intéressant est la façon dont Mueller parle de la « compréhension » qu’a Google d’un site. Il utilise ce concept dans plusieurs contextes : il couvre à la fois des éléments de qualité, et une notion plus large liée à la pertinence du site et à sa place sur le web.

Dans l’exemple présent, il semble que la « compréhension » fasse référence à la manière dont Google relie le contenu au domaine : si certaines parties restent sur l’ancien domaine et d’autres sont sur le nouveau, l’indexation, le classement et la corrélation des signaux peuvent devenir flous.

Voir aussi : il faut des mois à Google pour évaluer la qualité d’un site sur l’ensemble du web

Décomposer la problématique : pourquoi un transfert partiel pose-t-il problème ?

Pour bien comprendre les risques d’un déplacement partiel, il faut examiner plusieurs aspects techniques et sémantiques :

• Signalisation contradictoire : si la page d’accueil pointe vers le nouveau domaine mais que des pages importantes restent sur l’ancien, Google reçoit des signaux incohérents sur la structure du site et la relation entre domaines.
• Indexation fragmentée : certaines pages seront indexées sur l’ancien domaine et d’autres sur le nouveau, ce qui complique la consolidation des signaux de pertinence et d’autorité (backlinks, signaux utilisateurs, etc.).
• Suivi et analytics : séparer l’expérience utilisateur entre deux domaines rend l’analyse du trafic, du comportement et des conversions plus difficile, surtout si les tags et les données de suivi ne sont pas uniformes.
• Gestion des redirections : l’absence de redirections 301 systématiques provoque des pertes de trafic organique et fragilise la confiance de Google dans la continuité du contenu.
• Durée d’incertitude : tant que l’état final n’est pas atteint, Google peut hésiter à transférer tous les signaux de ranking au nouveau domaine, allongeant la période de fluctuation des positions.

Éléments techniques à prendre en compte lors d’un déplacement de site

Pour minimiser les risques pendant une migration, il est essentiel de maîtriser les éléments suivants :

Redirections 301 cohérentes

Les redirections permanentes (301) restent la méthode recommandée pour indiquer que des URL ont changé de localisation. Si vous procédez par étapes, veillez à :

• planifier quelles URLs seront redirigées et quand ;
• mettre en place des redirections sur l’intégralité des pages déplacées vers leurs équivalents sur le nouveau domaine ;
• éviter les chaines de redirection longues qui diluent le signal.

Fichier robots.txt et accès des bots

Certaines équipes laissent temporairement l’ancien robots.txt accessible avec « allow: / » pour permettre aux robots de suivre les URLs restantes. Cela peut aider à maintenir l’exploration, mais n’ignorez pas :

• la nécessité d’autoriser l’accès aux sitemaps mis à jour ;
• à informer Google via la Search Console des changements de sitemap ou des redirections.

Page d’accueil et vérification de l’outil

L’outil Change of Address vérifiera en premier lieu la redirection de la page d’accueil. Si celle‑ci pointe vers le nouveau domaine mais que le reste du site reste sur l’ancien, l’outil pourra être utilisé, mais la transition ne sera pas « propre » et générera des incohérences.

Canonicalisation

L’usage de balises rel= »canonical » peut aider Google à comprendre la version préférée d’une page. Toutefois, dans un contexte de déplacement partiel, il ne faut pas compter uniquement sur les canonicals pour remplacer des redirections 301.

Sitemaps

Mettez à jour vos sitemaps pour refléter la structure finale du site. Si vous migrez par étapes, maintenez des sitemaps distincts ou indiquant l’état réel des URLs et soumettez‑les via la Search Console pour chaque domaine.

Conséquences SEO possibles d’une migration effectuée par étapes

En pratique, une migration partielle peut engendrer :

• des fluctuations de positionnement sur les mots‑clés ciblés ;
• des baisses temporaires de trafic organique sur les pages non redirigées ;
• une lente propagation des signaux d’autorité vers le nouveau domaine (liens entrants, signaux sociaux, etc.) ;
• des complications supplémentaires si parallèlement vous changez d’architecture d’URL, de CMS ou effectuez d’autres modifications structurelles.

Bonnes pratiques pour une migration par étapes (si vous n’avez pas d’autre choix)

Parfois, il est matériellement impossible de transférer l’intégralité d’un site en une seule fois. Si vous êtes contraint d’opérer une migration progressive, voici des recommandations pour réduire les risques :

1. Documenter et planifier chaque phase

Élaborez un plan détaillé indiquant les lots d’URLs à déplacer, les dates prévues, les responsables et les critères de validation. Incluez :

• les mappings d’URL (ancienne → nouvelle) ;
• la stratégie de redirections ;
• les mises à jour des sitemaps ;
• les vérifications post‑migration (statuts HTTP, contenus dupliqués, tags analytiques).

2. Harmoniser le tracking et les analytics

Assurez‑vous que vos balises analytiques et vos systèmes de suivi (par exemple Google Analytics, outils d’attribution) sont correctement configurés pour suivre le trafic à travers les deux domaines. Sans cela, vous perdrez en visibilité sur l’impact réel des changements.

3. Prioriser les redirections sur les pages stratégiques

Commencez par rediriger les pages qui génèrent le plus de trafic ou qui reçoivent le plus de backlinks. Cela aide Google à transférer plus rapidement les signaux de valeur vers le nouveau domaine.

4. Maintenir une communication claire entre équipes

SEO, développement, contenu et IT doivent être alignés. Les erreurs techniques (mauvaises redirections, pages orphelines, robots.txt bloquant) sont souvent liées à un manque de coordination.

5. Surveiller étroitement les indicateurs

Suivez l’indexation, le crawl, les erreurs 404, les positions sur les mots‑clés et le trafic organique. Prévoyez une fenêtre de surveillance intensive juste après chaque phase du transfert.

6. Limiter les changements simultanés

Évitez d’effectuer d’autres modifications majeures (changement de CMS, refonte importante du contenu, suppression massive de pages) durant la période de migration. Combinées, ces actions rendent l’analyse des causes d’un éventuel problème beaucoup plus difficile.

7. Préparer des règles de rollback

Si un lot de redirections provoque des problèmes graves, il faut pouvoir revenir rapidement en arrière. Définissez des procédures de rollback pour chaque phase, avec des sauvegardes et un plan d’action clair.

Comment interpréter les recommandations de Mueller

Les commentaires de John Mueller soulignent deux idées majeures :

• la possibilité technique d’indiquer un déplacement partiel via la Search Console existe, mais
• la qualité et la clarté de la transition importent plus que la simple utilisation d’un outil : un transfert fragmenté crée une « zone grise » qui complique la compréhension qu’a Google de votre site.

Autrement dit, l’outil ne remplacera pas une exécution complète et ordonnée : il facilite le signalement, mais ne règle pas les incohérences qui découlent d’un transfert incomplet.

Exemples concrets de confusion pour Google

Voici quelques scénarios où la compréhension de Google peut être perturbée :

• la page d’accueil redirige vers le nouveau domaine, mais des pages produits restent sur l’ancien : Google pourrait indexer certaines pages sous le nouveau domaine et d’autres sous l’ancien, ce qui dilue la perception de cohérence du site ;
• des liens entrants pointent vers des pages qui ne sont pas redirigées : le « jus de lien » n’est pas correctement transféré ;
• des signaux d’expérience utilisateur (taux de rebond, temps passé) sont mesurés séparément et ne donnent pas une image unifiée de la qualité du site.

Durée des effets et attente des résultats

Même pour une migration complète, il faut souvent plusieurs semaines à mois pour que Google stabilise pleinement sa vision du nouveau domaine et transfère la plupart des signaux de ranking. Dans un contexte de déplacement partiel, ce délai peut être plus long et plus incertain :

• les fluctuations sont normales et attendues ;
• la synchronisation des redirections et des mises à jour de sitemaps accélère la convergence, mais ne la garantit pas ;
• le suivi des indicateurs clés permettra d’évaluer si la stratégie par phases fonctionne ou s’il faut accélérer le transfert complet.

Que faire si vous observez une chute de trafic après un lot de redirections ?

Si le trafic diminue après une étape, procédez ainsi :

1. vérifiez que les redirections 301 sont correctement configurées (pas d’erreurs 302 temporaires, pas de chaînes multiples) ;
2. analysez les logs de crawl pour détecter des blocages ou des erreurs 5xx ;
3. revoyez les sitemaps et leur soumission dans la Search Console ;
4. contrôlez la configuration du robots.txt sur les deux domaines ;
5. vérifiez la cohérence des balises canoniques et des métadonnées ;
6. comparez les pages perdantes avec les pages qui ont bien performé pour identifier des différences techniques ou de contenu.

Alternatives à une migration partielle

Si une migration progressive semble risquée pour votre trafic organique, envisagez les approches suivantes :

• planifier une « grosse » fenêtre de migration et déployer l’ensemble en une seule fois (avec ressources et tests dédiés) ;
• utiliser des sous‑domaines plutôt que des domaines entièrement distincts si l’objectif est organisationnel ;
• répliquer le contenu sur le nouveau domaine mais laisser les redirections en place jusqu’à basculement complet (en veillant aux risques de contenu dupliqué et en informant Google par canonicalisation correctement paramétrée) ;
• si la contrainte est purement technique, résoudre d’abord les verrous qui empêchent une migration complète (capacité serveur, dépendances applicatives, etc.).

Quand utiliser l’outil Change of Address

L’outil de Change of Address dans la Search Console est destiné à notifier Google d’un transfert complet d’un domaine A vers un domaine B. Son utilisation est la plus pertinente lorsque :

• la majorité, voire l’intégralité, des pages ont été redirigées vers leurs équivalents sur le nouveau domaine ;
• la page d’accueil et les pages principales renvoient correctement via des 301 ;
• les sitemaps et la configuration technique pour le nouveau domaine sont prêtes à être indexées.

Si ces conditions ne sont pas réunies, l’outil peut encore être lancé, mais il ne fera pas disparaitre les problèmes évoqués précédemment.

Récapitulatif et recommandations pratiques

Pour synthétiser :

• Un déplacement de site complet, correctement préparé et exécuté, est la solution la plus nette pour transférer l’ensemble des signaux SEO vers un nouveau domaine.
• Un déplacement partiel est possible mais crée une période d’ambiguïté pendant laquelle Google pourra avoir du mal à interpréter la relation entre l’ancien et le nouveau domaine, ce qui peut impacter le classement et l’indexation.
• Si vous ne pouvez pas éviter une migration par étapes, documentez, priorisez les redirections, unifiez le suivi, et surveillez de près les métriques clé.
• Enfin, utilisez l’outil de Change of Address lorsque la configuration technique et les redirections le justifient ; l’outil aide à notifier Google, mais ne remplace pas une exécution complète et propre.

Image de couverture : Shutterstock / Here