Pourquoi Google affiche-t-il encore les anciennes URL après une migration de domaine ?

Que signifie concrètement cette déclaration de John Mueller ?

Lorsque vous migrez un site vers un nouveau domaine, l'opérateur site: appliqué à l'ancien domaine peut continuer à afficher les anciennes URL dans les résultats de recherche. Google précise que cette présence temporaire ne signifie pas que ces pages sont toujours activement indexées ou qu'elles apparaissent dans les résultats organiques classiques.

La nuance est capitale : les résultats d'une requête site: ne sont pas synonymes d'indexation active. Google conserve en mémoire l'historique du domaine et peut afficher ces URL par "compréhension" (understanding) qu'elles ont été déplacées, même si le moteur redirige déjà les utilisateurs vers le nouveau domaine pour des recherches normales.

Pourquoi Google maintient-il cette visibilité des anciennes URL ?

Le moteur conserve une trace des anciennes URL pour comprendre la continuité entre l'ancien et le nouveau domaine. Cette mémoire aide Google à transférer les signaux de ranking : autorité, backlinks, historique de contenu. Le maintien temporaire dans les résultats site: fait partie du processus interne de consolidation.

Cela ne reflète ni un dysfonctionnement ni un retard dans le traitement des redirections 301. C'est simplement un artefact de la manière dont Google gère les requêtes diagnostiques versus les requêtes utilisateurs réelles. Les deux circuits de traitement ne sont pas synchronisés en temps réel pendant une migration.

Combien de temps cette situation peut-elle durer ?

Google ne donne aucun délai précis. D'après les observations terrain, les anciennes URL peuvent rester visibles dans les résultats site: pendant plusieurs semaines, voire quelques mois, selon la taille du site et la fréquence de crawl. Le moteur procède par vagues : certaines pages disparaissent rapidement, d'autres traînent.

Cette variabilité dépend de multiples facteurs : budget crawl, nombre de pages migrées, qualité des redirections, vitesse d'indexation du nouveau domaine. Un site de 10 000 pages ne se nettoie pas au même rythme qu'un site de 100 pages. La patience est requise, mais surtout l'utilisation des bons outils de monitoring.

• L'opérateur site: n'est pas un indicateur fiable de l'état réel d'indexation pendant une migration
• Google conserve temporairement l'historique de l'ancien domaine pour transférer les signaux de ranking
• La durée d'affichage des anciennes URL varie selon la taille du site et le budget crawl alloué
• Les redirections 301 fonctionnent correctement même si les anciennes URL apparaissent encore dans site:
• Seules les données de la Search Console pour le nouveau domaine reflètent la réalité de l'indexation

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

Absolument. Cette clarification de Mueller rejoint ce que les praticiens SEO expérimentés constatent depuis des années lors de migrations de domaine. Le décalage entre les résultats site: et l'indexation réelle est un classique qui génère une anxiété inutile chez les clients. Trop de SEO juniors paniquent en voyant l'ancien domaine encore présent dans site: alors que le trafic organique transite déjà majoritairement par le nouveau domaine.

La vraie question reste : pourquoi Google n'améliore-t-il pas la précision de cet opérateur ? Si site: n'est pas fiable pendant une migration (et Mueller le confirme ici), à quoi sert-il exactement ? Pour un audit rapide, certes, mais avec une marge d'erreur que beaucoup sous-estiment. Ce flou entretient la confusion entre présence dans l'index et performance dans les résultats.

Quelles données faut-il réellement surveiller lors d'une migration ?

La Search Console du nouveau domaine reste l'unique source de vérité. Monitore l'évolution des pages indexées dans le rapport de couverture, le volume de clics organiques, et les requêtes qui génèrent des impressions. Si ces métriques progressent rapidement après la migration, les redirections fonctionnent correctement, peu importe ce qu'affiche site:.

Vérifie aussi les logs serveur : le crawl de Googlebot doit basculer massivement vers le nouveau domaine dans les premières semaines. Si Googlebot continue à crawler intensivement l'ancien domaine après 3-4 semaines, là il y a un problème structurel (redirections cassées, chaînes de redirections, crawl traps). Mais ces signaux n'apparaissent pas dans site:, qui reste un indicateur superficiel.

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

Si l'ancien domaine continue à afficher ses anciennes URL dans les résultats organiques classiques (pas site:, mais lors de vraies recherches par mots-clés), là il y a un problème réel. Cela signifie que Google n'a pas traité les redirections ou que le nouveau domaine rencontre un obstacle à l'indexation : robots.txt bloquant, noindex accidentel, pénalité algorithmique transférée.

[A vérifier] Mueller ne précise pas combien de temps ce décalage entre site: et indexation réelle peut durer avant de considérer qu'il y a dysfonctionnement. Un délai de 2 mois semble excessif, mais Google ne communique aucun SLA. Si après 90 jours l'ancien domaine domine encore site: ET les résultats organiques, investigue les redirections et les signaux de qualité du nouveau domaine.

Que faut-il faire concrètement lors d'une migration de domaine ?

Oublie l'opérateur site: comme outil de validation post-migration. Configure immédiatement la Search Console pour le nouveau domaine et surveille quotidiennement le rapport de couverture. Les pages indexées doivent progresser rapidement, idéalement à hauteur de 70-80% du volume de l'ancien site dans les 4 premières semaines pour un site bien préparé.

Parallèlement, soumets un changement d'adresse via la Search Console de l'ancien domaine. Cette notification accélère le transfert des signaux de ranking et réduit le délai de migration. Sans cette étape, Google peut traiter la migration plus lentement, car il doit découvrir les redirections par lui-même au fil du crawl.

Quelles erreurs éviter absolument ?

Ne panique pas si site: affiche encore l'ancien domaine après 2-3 semaines. Ce comportement est normal. Ne multiplie pas les resoumissions de sitemap XML de l'ancien domaine en pensant forcer Google à comprendre la migration : cela ne sert à rien et consomme du budget crawl inutilement. Le moteur a déjà compris, il ne synchronise simplement pas site: en temps réel.

Évite surtout de modifier les redirections 301 en cours de route par peur que "ça ne marche pas". Si les redirections sont correctement configurées et que le nouveau domaine est crawlable, laisse faire le temps. Changer la structure de redirection en pleine migration casse les signaux déjà transférés et rallonge le processus. Valide une fois, puis ne touche plus.

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

Utilise les logs serveur pour comparer le volume de crawl Googlebot entre ancien et nouveau domaine semaine après semaine. Le crawl doit basculer progressivement vers le nouveau domaine. Si après 3 semaines Googlebot crawle encore majoritairement l'ancien domaine, inspecte les chaînes de redirections et les erreurs 4xx/5xx sur le nouveau domaine.

Surveille aussi le trafic organique global : il doit rester stable ou connaître une légère baisse temporaire (10-15% maximum) avant de se stabiliser. Une chute de 40-50% signale un problème structurel : perte de contenu, redirections cassées, cannibalisation, ou désindexation accidentelle. Ces signaux apparaissent dans Analytics et la Search Console, pas dans site:.

• Configurer la Search Console pour le nouveau domaine avant la migration
• Soumettre un changement d'adresse via la Search Console de l'ancien domaine
• Monitorer quotidiennement le rapport de couverture du nouveau domaine
• Analyser les logs serveur pour vérifier le basculement du crawl Googlebot
• Ignorer les résultats de l'opérateur site: pendant au moins 60 jours post-migration
• Vérifier que le trafic organique reste stable ou ne baisse pas de plus de 15%