Récemment, Google a supprimé de la documentation certaines pages relatives aux **données structurées**, mais au lieu de répondre par une **réponse 404**, l’équipe a opté pour une **redirection 301** vers un **changelog**. Le résultat : pour certaines URL, un lien dans le changelog renvoie vers la page supprimée qui, elle-même, redirige de nouveau vers le changelog — générant une **boucle infinie** entre deux pages. Techniquement, ce comportement n’est pas un **soft 404**, pourtant il illustre une utilisation atypique de la **redirection 301** pour une page disparue. Est-ce une erreur de la part de **Google** ?

Si l’on se limite au seul changelog, cela ressemble effectivement à une maladresse. Il existe par ailleurs un article publié en juin 2025 qui expliquait la suppression du support pour ces types de données structurées et qui renvoie vers la documentation encore valable pour les types non obsolètes. Pourtant, le traitement des anciennes URL est inégal : certaines redirigent vers le changelog — déclenchant la **boucle infinie** — tandis qu’une page renvoie un 404, ce qui est la réponse attendue pour une ressource définitivement retirée.

Google a retiré des pages de documentation sur les données structurées

En coulisses, Google a ajouté une note au changelog signalant la suppression de certaines pages jugées obsolètes dans la documentation des **données structurées**. L’annonce initiale date de juin 2025, et la suppression effective des pages a été constatée récemment.

Les pages supprimées concernent les types de données structurées suivants :

• Course info
• Estimated salary
• Learning video
• Special announcement – 404 Error Response
• Vehicle listing

Ces pages ont été entièrement retirées. Elles sont, pour l’instant, introuvables et probablement destinées à ne pas être rétablies. Dans la majorité des cas, la procédure normale lorsqu’une page disparaît est d’émettre une **réponse 404** (Page Not Found) ou parfois une **410** (Gone) pour indiquer de façon explicite la suppression définitive. Mais ce n’est pas ce qui se passe ici.

Au lieu d’un 404, certaines de ces anciennes URL renvoient une **redirection 301** vers le changelog. Ce qui complique encore la situation, c’est que le changelog contient des liens pointant vers ces mêmes URL supprimées, ce qui crée une **boucle** : le lien du changelog mène à l’ancienne page qui renvoie au changelog, etc. Une autre page (le billet de juin 2025) explique la suppression, mais dès que l’on suit le lien vers le changelog, la **boucle de redirections** démarre.

Capture d’écran du changelog

Sur la capture ci‑dessus, j’ai souligné en rouge le lien vers la donnée structurée Course Info.

Le texte « course info » pointe vers cette URL :
https://developers.google.com/search/docs/appearance/structured-data/course-info

Qui redirige immédiatement vers le changelog suivant :
https://developers.google.com/search/updates#september-2025

Ce changelog contient, à son tour, des liens vers les cinq URLs désormais supprimées, ce qui crée littéralement une **boucle infinie**. Ce comportement n’améliore ni l’**expérience utilisateur**, ni l’efficacité du crawling pour les **crawlers**.

Pourquoi une redirection 301 au lieu d’un 404 ?

Une **redirection 301** est techniquement une option acceptable pour des pages supprimées lorsque l’on souhaite rediriger vers une ressource de remplacement. Par définition, une 301 indique que la ressource a été déplacée de façon permanente vers une autre URL et que les moteurs devraient transmettre le crédit d’indexation (et une partie du « link equity ») à la nouvelle URL. Cependant, l’usage le plus fréquent d’une 301 est de pointer vers une page de remplacement pertinente, qui fournit des informations équivalentes ou proches de l’ancienne.

Dans ce cas précis, la 301 renvoie vers un changelog dont le rôle est de documenter la suppression, mais le changelog contient lui‑même un lien vers l’ancienne URL supprimée. Au lieu d’offrir une destination claire et utile, la combinaison crée un chemin circulaire que ni l’utilisateur ni le robot d’indexation ne devraient rencontrer.

Conséquences possibles pour le crawling et l’indexation

Plusieurs effets négatifs peuvent découler de cette approche :

• Perte d’indexation : si le crawler rencontre une boucle de redirections, il pourrait décider d’abandonner la chaîne ou de ne pas indexer correctement les ressources impliquées ;
• Gaspillage du budget de crawl : les bots consacrent du temps et des ressources à suivre des redirections inutiles ;
• Mauvaise interprétation des signaux : une 301 implique permanence — or la destination n’est pas une ressource équivalente, ce qui peut fausser l’évaluation par les moteurs ;
• Expérience utilisateur confuse : un visiteur qui suit un lien et est renvoyé en boucle risque d’abandonner la page et de perdre confiance dans la documentation ;
• Complexité pour les outils d’analyse : les rapports d’erreurs (ex. Search Console) peuvent retourner des signaux contradictoires, rendant le diagnostic plus difficile pour les webmasters et les SEO.

Qu’est‑ce qu’un soft 404 et pourquoi ce n’en est pas un ?

Un **soft 404** survient lorsqu’un serveur retourne un code 200 (OK) pour une page qui en réalité n’existe plus — par exemple une page « aucune donnée trouvée » qui affiche un message d’erreur mais renvoie 200. Les moteurs interprètent alors cette page comme une page valide même si elle n’a pas de contenu utile, et peuvent la traiter comme une page supprimée.

Dans la situation décrite ici, Google n’a pas renvoyé de 200 camouflé ; il renvoie une **301**. Si la chaîne redirectionnelle n’était pas circulaire, on pourrait au moins comprendre la logique (rediriger vers une page de remplacement). Mais la boucle rend la logique très discutable. Techniquement, ce n’est donc pas un **soft 404**, mais c’est un comportement tout aussi peu souhaitable.

Pourquoi Google aurait‑il procédé ainsi ? Hypothèses raisonnables

Plusieurs explications plausibles peuvent être envisagées :

• Automatisation de la suppression : un script automatisé a peut‑être appliqué une règle de redirection 301 à un ensemble d’URL supprimées sans vérifier les liens présents dans le changelog ;
• Préservation de l’équité des liens : l’intention aurait pu être de transférer une partie du « link juice » vers le changelog plutôt que de perdre complètement la valeur des liens entrants ;
• Mise à jour incrémentale : les équipes ont d’abord retiré les pages, puis ajouté les liens dans le changelog, sans synchroniser les deux opérations ;
• Erreur humaine : une petite erreur de configuration lors du déploiement a produit ces redirections circulaires ;
• Choix éditorial : l’équipe documentation a jugé que rediriger vers le changelog était préférable à afficher des 404 « nus », afin de fournir un contexte sur la dépréciation — mais la mise en œuvre a entraîné la boucle.

Quelle que soit la cause, le résultat reste problématique pour la navigation et pour les robots d’indexation.

Que serait une gestion plus adaptée des pages supprimées ?

Pour une suppression propre et compréhensible par les moteurs et les utilisateurs, les options usuelles comprennent :

• Retourner une 404 quand la page n’a pas d’équivalent — cela indique clairement que la ressource n’existe plus ;
• Retourner une 410 si la suppression est volontaire et définitive — 410 précise que la page est intentionnellement partie et que cela ne relève pas d’une erreur temporaire ;
• Utiliser une 301 uniquement si une page de remplacement pertinente existe (même thématique et valeur informative proche) ;
• Fournir une page explicative statique (ex. : une page « Cette fonction n’est plus supportée ») qui sert de destination utile pour les utilisateurs, sans renvoyer en boucle ;
• Mettre à jour le changelog pour qu’il ne pointe pas vers des URL qui redirigent vers lui, mais vers la page explicative ou le billet détaillant la dépréciation (par ex. l’article de juin 2025).

Conséquences pratiques pour les SEO et les webmasters

Si vous administrez un site, voici les points à surveiller quand des pages disparaissent ou sont redirigées :

Surveillance et diagnostic

• Contrôler les réponses HTTP : utilisez curl ou un outil de vérification HTTP pour examiner précisément les codes renvoyés par vos pages et les chaînes de redirections ;
• Analyser les logs serveur : identifiez les patterns de crawl, les erreurs 4xx/5xx et les redirections répétées ;
• Vérifier Search Console : consultez les rapports de couverture et d’indexation pour détecter des anomalies (pages exclues, erreurs de redirection) ;
• Tester avec des crawlers tiers : Screaming Frog, Sitebulb ou autres outils permettent de simuler le comportement des bots et d’identifier les boucles ;
• Auditer les liens internes : assurez‑vous que votre documentation et votre changelog renvoient vers des destinations pertinentes et non vers des URL mortes ou redirigées en boucle.

Meilleures pratiques techniques

• Utiliser le code approprié : 404 pour page introuvable temporairement, 410 pour page définitivement supprimée, 301 pour déplacement permanent vers une ressource équivalente ;
• Éviter les redirections en chaîne et les boucles : chaque redirection supplémentaire augmente la latence et le risque d’erreur pour les bots ;
• Mettre à jour les sitemaps : retirez les URL obsolètes et assurez‑vous que les sitemaps pointent vers des pages actives ;
• Documenter la dépréciation : si vous retirez une fonctionnalité, publiez une page explicative stable (avec une URL dédiée) et redirigez les anciennes pages pertinentes vers cette explication, si nécessaire ;
• Communiquer clairement : autant que possible, fournissez un contexte utilisateur quand du contenu disparaît (dates, raisons, alternatives).

Comment tester si vous êtes confronté à une boucle de redirection

Procédez méthodiquement :

1. Exécutez une requête curl pour suivre les en‑têtes HTTP : curl -I -L [URL] ;
2. Regardez la chaîne de redirections renvoyée et notez les statuts ;
3. Si vous observez des redirections qui retournent vers une URL déjà visitée, vous êtes face à une boucle infinie ;
4. Testez en tant que robot : certains crawlers permettent de simuler différents user agents ;
5. Corrélez avec vos logs serveur pour voir si les crawlers (Googlebot, Bingbot) ont rencontré des erreurs lors des visites.

Outils utiles

• Screaming Frog SEO Spider — pour détecter les redirections en chaîne et les boucles ;
• curl — pour des analyses en ligne de commande ;
• Search Console — pour les rapports d’indexation et d’erreurs ;
• Outils de monitoring des performances — pour repérer les ralentissements causés par les redirections ;
• Analyseur de logs — pour étudier le comportement des bots sur vos URL.

Recommandations pratiques en cas de découverte d’un problème similaire

Si vous identifiez une boucle de redirection sur votre propre domaine, procédez ainsi :

• Arrêtez la redirection problématique dès que possible ;
• Remplacez la 301 par un 410 si la page est définitivement supprimée et qu’aucune alternative cohérente n’existe ;
• Si une page alternative existe, redirigez directement vers elle via une 301, sans passer par un changelog qui renvoie en arrière ;
• Corrigez le changelog ou les pages qui contiennent des liens pointant vers des URL redirigées circulairement ;
• Surveillez l’évolution dans Search Console pour vérifier la disparition des erreurs et la stabilisation de l’indexation.

Scénarios concrets et impacts

Exemple 1 — redirection vers une page d’explication : si chaque URL supprimée redirigeait vers une page d’explication dédiée (ex. /docs/deprecation/course-info), l’utilisateur comprendrait immédiatement le contexte. Les bots indexeraient la nouvelle page explicative et le signal serait cohérent.

Exemple 2 — redirection vers le changelog (cas actuel) : le changelog contient des liens vers l’ancienne page supprimée, qui renvoie vers le changelog. Les bots s’arrêtent, le trafic se perd, les rapports montrent des comportements anormaux et les webmasters peinent à déterminer la cause exacte.

Résumé et conclusions

La pratique observée — rediriger des pages supprimées vers un changelog qui, à son tour, pointe vers les pages supprimées — crée une **boucle de redirections** nuisible. Bien que l’usage d’une **redirection 301** soit techniquement permis, son impact dépend fortement du contexte : lorsqu’aucune page de remplacement pertinente n’existe, une 404/410 plus explicite est généralement préférable. Pour les équipes techniques et SEO, l’enseignement est simple : aligner la stratégie d’URL, la communication éditoriale et les règles de redirection afin d’éviter d’introduire des pièges pour les utilisateurs et les moteurs.

Dans l’affaire spécifique évoquée, la manière dont Google a orchestré ces suppressions laisse penser à une erreur de mise en œuvre ou à une automatisation trop brute. Quelle que soit l’explication, le résultat est un exemple utile pour rappeler l’importance de gérer proprement les URL retirées et de vérifier les chaînes de redirections avant déploiement.

Featured Image by Shutterstock/Kues