Pourquoi les pages indexées persistent-elles dans site: après la fermeture d'un service ?

Que signifie vraiment cette déclaration de Google ?

La commande site: est l'un des réflexes les plus ancrés chez les SEO. On tape site:mondomaine.com et on s'attend à voir l'état réel de l'index. Sauf que Google nous rappelle ici une vérité inconfortable : ce que vous voyez dans site: n'est pas un miroir fidèle de l'index canonique.

Quand un service ferme ou qu'une migration intervient, des centaines (voire milliers) de pages peuvent rester affichées dans site: alors que leur URL canonique a déjà changé côté Google. Le moteur a choisi la nouvelle URL comme référence, mais l'ancienne continue de s'afficher dans les résultats de la commande. C'est contre-intuitif, mais c'est la réalité technique de cette fonction.

Pourquoi site: ne montre-t-il pas uniquement les canoniques ?

La commande site: n'a jamais été conçue comme un outil de diagnostic précis. Elle renvoie un échantillon d'URLs indexées, sans garantie que ce soient les versions canoniques. Google peut afficher des variantes, des doublons, des anciennes versions — tout ce qui a été crawlé et reste techniquement dans l'index, même si ce n'est plus la version de référence.

Concrètement, si vous migrez un site de ancien.com vers nouveau.com, vous pouvez voir pendant des semaines les URLs de ancien.com dans site:ancien.com, alors que Google a déjà basculé sur nouveau.com pour le classement réel. L'affichage dans site: ne suit pas instantanément la logique canonique.

Faut-il ignorer complètement les résultats de site: ?

Non, mais il faut relativiser. La commande site: reste utile pour une vue macro rapide : combien de pages Google voit environ, est-ce qu'il y a des sections inattendues, des patterns bizarres. Mais ne vous fiez jamais à site: pour valider une migration, diagnostiquer un problème de canonicalisation ou mesurer l'indexation fine.

Pour ça, vous avez Search Console, les rapports de couverture, les données de trafic organique. Si vos nouvelles URLs génèrent du trafic et apparaissent dans les rapports de performance, c'est qu'elles sont bien reconnues comme canoniques. Le reste, c'est du bruit résiduel dans l'affichage de site:.

• site: affiche un échantillon d'URLs indexées, pas nécessairement les canoniques
• Après une migration ou fermeture, les anciennes URLs peuvent rester visibles pendant des semaines
• Google choisit souvent la nouvelle URL comme canonique en interne, même si l'ancienne s'affiche encore
• Search Console et le trafic organique sont les seuls indicateurs fiables pour valider la canonicalisation
• Ne paniquez pas si site: affiche encore des dizaines de pages d'un ancien service — vérifiez d'abord le trafic réel

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

Oui, et c'est même un soulagement que Google le dise enfin explicitement. Pendant des années, on a vu des migrations propres — redirections 301 impeccables, sitemap à jour, Search Console clean — avec des centaines d'anciennes URLs qui traînaient dans site: pendant 2-3 mois. Ça générait de l'anxiété côté client, des alertes inutiles, des heures de diagnostic pour rien.

La réalité : le trafic avait basculé sur les nouvelles URLs en quelques jours, les anciennes n'apparaissaient plus dans les SERPs pour des requêtes réelles. Mais site: continuait d'afficher l'ancien inventaire. Google confirme ici que c'est normal, que ce n'est pas un bug, et qu'il ne faut pas s'alarmer.

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

Attention : Google dit « il n'y a pas besoin de s'inquiéter », mais ça ne veut pas dire « ignorez tout signal d'alerte ». Si les anciennes URLs restent dans site: et que vous constatez une chute de trafic, c'est un problème réel. Si elles génèrent encore des impressions dans Search Console, c'est que Google ne les a pas correctement redirigées ou que les redirections ne sont pas suivies.

[A vérifier] : La déclaration ne précise pas combien de temps cet affichage résiduel peut durer. En pratique, on observe entre 3 semaines et 3 mois selon la taille du site et la fréquence de crawl. Mais Google ne donne aucune garantie chiffrée. Si ça dure 6 mois avec des anciennes URLs qui génèrent encore du trafic, il y a probablement un souci de redirections ou de canonicals mal configurés.

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

Si vous voyez dans site: des pages sensibles qui auraient dû être supprimées (données personnelles, pages en noindex, contenus sous embargo), ne les ignorez pas. Le fait qu'elles apparaissent dans site: signifie qu'elles sont techniquement accessibles au crawl. Utilisez l'outil de suppression d'URL dans Search Console pour forcer le retrait immédiat.

De même, si vous constatez que des pages 404 ou des contenus obsolètes continuent de recevoir du trafic organique (pas juste d'apparaître dans site:, mais vraiment de ranker et de générer des clics), c'est anormal. Ça indique que Google n'a pas encore basculé sur la nouvelle URL canonique, et qu'il faut investiguer les redirections, les canonicals, ou la structure du sitemap.

Que faut-il vérifier concrètement après une migration ou une fermeture ?

D'abord, oubliez site: comme métrique de validation. Allez dans Search Console, section Performance, et filtrez par URL. Regardez quelles pages génèrent des impressions et des clics sur les 28 derniers jours. Si ce sont les nouvelles URLs, parfait. Si ce sont encore majoritairement les anciennes, vous avez un problème de redirections ou de canonicals.

Ensuite, vérifiez le rapport de couverture dans Search Console. Les anciennes URLs doivent apparaître comme « Redirigées » ou « Exclues par balise noindex ». Si elles sont toujours en « Valide », c'est que Google n'a pas détecté la redirection ou qu'elle ne fonctionne pas correctement. Testez manuellement quelques URLs avec curl ou un outil comme Screaming Frog pour confirmer le code de statut HTTP.

Quelles erreurs éviter quand on constate ce type de situation ?

Ne demandez pas une réindexation massive via Search Console pour « forcer » le retrait des anciennes URLs. Ça ne marche pas comme ça. La réindexation ne supprime pas les URLs de l'index, elle demande juste un recrawl. Si la redirection est en place, Google finira par comprendre tout seul. Forcer le crawl peut même ralentir le processus en saturant votre budget crawl.

Évitez aussi de paniquer et de modifier les redirections en cours de route. Si vous avez mis en place des 301, laissez-les en place au minimum 6 mois, idéalement 1 an. Changer les redirections ou basculer en 302 en pensant « accélérer » le processus crée plus de confusion qu'autre chose.

Comment surveiller que tout se passe bien ?

Mettez en place un suivi hebdomadaire du trafic organique par groupe d'URLs (anciennes vs nouvelles). Si le trafic sur les anciennes URLs décroît régulièrement et celui sur les nouvelles augmente, c'est bon signe. Si au contraire le trafic stagne sur les anciennes après 4-6 semaines, creusez : redirections cassées, canonicals contradictoires, sitemap qui pointe encore sur les anciennes URLs.

Utilisez aussi Google Analytics (ou votre outil de tracking) pour identifier les pages d'atterrissage organiques. Si des utilisateurs arrivent encore sur ancien.com/page au lieu de nouveau.com/page, c'est un problème réel, pas juste un artefact d'affichage dans site:. Dans ce cas, vérifiez que les redirections sont bien en place côté serveur, testées avec un vrai user-agent Google.

• Valider les redirections 301 avec curl ou Screaming Frog, pas juste dans le navigateur
• Vérifier dans Search Console > Performance que les nouvelles URLs génèrent des clics
• Contrôler le rapport de couverture : les anciennes URLs doivent être « Redirigées »
• Mettre à jour le sitemap XML pour ne référencer que les nouvelles URLs
• Surveiller le trafic organique par groupe d'URLs pendant au moins 3 mois
• Ne pas demander de réindexation massive ni modifier les redirections en cours de route