Pourquoi votre migration de site reste bloquée en 'pending' dans Search Console ?

Que signifie concrètement ce statut 'pending' ?

Google conserve une trace de chaque changement d'adresse de site déclaré via Search Console. Ce suivi interne reste actif longtemps après que la migration ait été techniquement digérée par les algorithmes. Le statut 'pending' ne reflète pas un blocage ou un ralentissement du processus de migration.

Il s'agit d'une simple mention archivistique : Google garde l'historique du déménagement dans ses bases, sans pour autant afficher un quelconque statut de finalisation. Aucune interface ne basculera jamais ce flag sur 'completed' ou 'done'. C'est une particularité de l'outil, pas un indicateur de performance.

Comment Google traite-t-il réellement une migration ?

Le moteur gère les migrations de site en réévaluant progressivement les URLs : il recrawle l'ancien domaine, suit les redirections 301, indexe les nouvelles URLs, puis transfère progressivement les signaux de classement. Ce processus s'étale sur plusieurs semaines, parfois plusieurs mois pour les gros sites.

La déclaration d'un changement d'adresse dans Search Console accélère la prise en compte, mais ne modifie pas fondamentalement le processus. Google continuera de crawler l'ancien domaine pendant des mois pour vérifier la persistance des redirections. Le statut affiché dans GSC n'a strictement aucun lien direct avec l'état d'avancement réel de cette migration côté index.

Quels signaux indiquent une migration aboutie ?

Les vrais indicateurs sont ailleurs : la provenance du trafic organique, la disparition progressive des anciennes URLs des SERP, le transfert des positions de classement vers les nouvelles pages. Si Google affiche encore massivement vos anciennes URLs dans les résultats de recherche plusieurs mois après la migration, c'est que vos redirections sont défaillantes ou que le crawl budget est insuffisant.

Le trafic provenant de l'ancien domaine est un signal d'alarme clair : cela signifie soit que certaines redirections échouent (erreurs 404, boucles, chaînes de redirections), soit que Google n'a pas encore complètement réindexé votre nouveau site. Dans ce cas, il faut auditer la qualité technique des 301, vérifier les sitemaps, et éventuellement forcer le recrawl des URLs critiques.

• Le statut 'pending' dans GSC est un artefact d'interface, pas un diagnostic technique
• Une migration réussie se mesure au transfert effectif du trafic vers le nouveau domaine
• Des redirections 301 propres (1:1, sans chaîne, sans boucle) sont la seule garantie d'une migration fluide
• Google peut mettre 3 à 6 mois pour finaliser complètement une migration sur un site moyen ou large
• La déclaration dans Search Console accélère la détection, mais ne remplace pas la rigueur technique des redirections

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

Absolument. Depuis des années, les SEO constatent que ce statut 'pending' persiste indéfiniment, sans corrélation avec la réussite effective de la migration. Google a toujours été flou sur le cycle de vie exact de cet indicateur. Cette confirmation officielle met fin à des années d'inquiétude inutile chez les praticiens qui surveillaient compulsivement ce statut.

Sur le terrain, les migrations bien exécutées (redirections 301 propres, sitemap à jour, structure 1:1) montrent un transfert de trafic quasi-complet en 4 à 8 semaines, bien avant que le statut GSC ne change — puisqu'il ne change jamais. Ce décalage entre perception et réalité technique génère beaucoup d'anxiété inutile chez les clients et les juniors.

Quelles nuances faut-il apporter à cette affirmation ?

Mueller évoque un contrôle de la provenance du trafic, mais reste évasif sur les seuils critiques. [A vérifier] : à partir de quel pourcentage de trafic résiduel sur l'ancien domaine doit-on s'inquiéter ? 5% ? 20% ? Google ne donne aucun chiffre, alors que c'est précisément ce dont les SEO ont besoin pour diagnostiquer une anomalie.

Autre point flou : la distinction entre un trafic résiduel normal (Google continue de crawler l'ancien domaine par précaution) et un trafic pathologique (redirections cassées). Sans métriques claires, on reste dans l'interprétation. Un outil comme les rapports de couverture d'index ou les logs serveur devient indispensable pour trancher.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si vous avez déclaré plusieurs migrations successives (test raté, rollback, puis nouvelle tentative), le statut 'pending' peut devenir franchement trompeur. Google garde trace de tous les changements d'adresse, et l'interface peut afficher un statut ancien ou ambigu. Dans ce cas, ignorez complètement GSC et fiez-vous uniquement aux métriques de trafic et aux rapports d'indexation.

Les migrations partielles (sous-répertoire vers sous-domaine, refonte d'une section seulement) ne devraient pas utiliser l'outil de changement d'adresse, qui est conçu pour les migrations complètes de domaine. Dans ces cas, le statut 'pending' n'a strictement aucun sens — et Google ne le dit pas assez clairement.

Que faut-il surveiller pendant une migration de site ?

Oubliez le statut 'pending' dans Search Console. Concentrez-vous sur trois métriques clés : la répartition du trafic organique entre ancien et nouveau domaine (via Google Analytics ou votre outil d'analyse), l'évolution du nombre d'URLs indexées sur chaque domaine (rapports de couverture GSC), et la position moyenne de vos requêtes stratégiques (Google Search Console ou outil de suivi de positions).

Configurez des alertes automatiques si le trafic sur l'ancien domaine dépasse un seuil que vous jugez anormal (par exemple 10% du trafic total après 8 semaines). Surveillez aussi les erreurs 404 ou 5xx dans les rapports GSC : elles signalent souvent des redirections cassées ou manquantes.

Quelles erreurs critiques éviter lors d'une migration ?

La plus fréquente : des chaînes de redirections (ancienne URL → URL intermédiaire → nouvelle URL). Google suit ces chaînes, mais avec perte de temps et de signal. Visez des redirections 1:1 directes. Autre erreur classique : rediriger toutes les anciennes URLs vers la homepage du nouveau site, au lieu de mapper chaque page vers son équivalent.

Ne déclarez jamais un changement d'adresse dans GSC avant que vos redirections ne soient en place et testées. Google commencera immédiatement à recrawler l'ancien domaine — si les 301 ne sont pas prêtes, vous créez de la confusion dans l'index. Testez au moins 20-30 URLs représentatives avec un outil comme Screaming Frog ou OnCrawl avant de lancer la déclaration officielle.

Comment vérifier que la migration se déroule correctement ?

Exportez chaque semaine les données de trafic organique par hostname depuis votre outil d'analytics. Vous devez voir une courbe décroissante nette pour l'ancien domaine et une courbe symétrique croissante pour le nouveau. Si les deux courbes stagnent ou si l'ancien domaine reste dominant après 6-8 semaines, auditez immédiatement vos redirections et vos canonicals.

Analysez vos logs serveur : Googlebot doit progressivement réduire son activité sur l'ancien domaine et intensifier son crawl du nouveau. Si Googlebot continue de crawler massivement l'ancien site plusieurs mois après la migration, c'est que quelque chose bloque le transfert de signals — souvent des canonicals mal configurés ou des liens internes résiduels pointant vers l'ancien domaine.

• Mapper chaque ancienne URL vers sa nouvelle équivalente avant de lancer la migration
• Implémenter des redirections 301 propres, sans chaîne, testées URL par URL
• Déclarer le changement d'adresse dans Search Console uniquement après validation technique
• Surveiller hebdomadairement la répartition du trafic organique entre les deux domaines
• Auditer les rapports de couverture d'index et les erreurs 404/5xx dans GSC
• Analyser les logs serveur pour vérifier le comportement de Googlebot