Pièges à crawl SEO : les espaces qui épuisent Googlebot

Un piège à crawl (crawler trap) est une zone d'un site qui génère un nombre d'URL pratiquement infini : le robot d'exploration peut continuer à récupérer des pages indéfiniment dans cette zone sans jamais l'épuiser ni atteindre le reste du contenu. Ce n'est pas un lien cassé ponctuel : c'est un mécanisme qui produit une nouvelle URL valide à chaque page explorée, créant une boucle que le crawler ne peut interrompre de lui-même puisque, de son point de vue, chaque nouvelle page ressemble à une page légitime qu'il n'a pas encore vue.

Le symptôme le plus visible est un budget de crawl qui se vide sans que les pages importantes soient explorées à temps. Mais le piège existe indépendamment de la notion de budget : même avec des ressources d'exploration illimitées, indexer des dizaines de milliers de variantes sans valeur dilue la pertinence de tout le domaine aux yeux des signaux de qualité qui s'évaluent au niveau du site. Comprendre le mécanisme qui génère ces URL est la seule façon de le couper à la racine plutôt que d'en gérer les symptômes indéfiniment.

Ce qui distingue un piège à crawl d'un simple problème d'exploration

Un piège à crawl a une caractéristique précise : la génération est structurelle, pas accidentelle. Une page cassée ou une erreur 404 ponctuelle n'en est pas une, parce qu'elle ne produit rien de nouveau à explorer ensuite. Un piège, lui, fabrique une URL supplémentaire à chaque page visitée, souvent en ajoutant un paramètre, un segment de chemin ou une date à ce qui existe déjà. Le crawler suit un lien légitime en apparence, atterrit sur une page légitime en apparence, qui contient elle-même un lien vers une nouvelle variante — et ainsi de suite sans qu'aucune règle interne au site ne vienne fermer la boucle.

Cette distinction compte parce que les deux problèmes ne se corrigent pas de la même façon. Une erreur d'exploration isolée se répare lien par lien. Un piège se répare au niveau du mécanisme qui produit les URL, sans quoi corriger une occurrence n'empêche pas la suivante d'apparaître le mois suivant, ou pour la combinaison de filtres suivante.

Les pièges liés à la navigation et aux fonctionnalités du site

La plupart des pièges à crawl viennent de fonctionnalités qui, prises isolément, sont utiles pour l'utilisateur mais n'ont jamais reçu de limite côté exploration.

• Calendriers avec lien « mois suivant » perpétuel : chaque page de calendrier contient un lien vers le mois d'après, qui contient lui-même un lien vers le mois d'après, sans date de fin. Un crawler qui suit ces liens peut atterrir sur des pages datées de plusieurs décennies dans le futur, chacune techniquement valide et chacune générant la suivante.
• Combinaisons de filtres et de tri : sur une page catégorie e-commerce, croiser couleur, taille, prix et tri croissant ou décroissant produit un nombre de combinaisons qui croît de façon multiplicative avec le nombre de filtres disponibles, alors que le contenu réel derrière chaque combinaison est souvent identique ou vide.
• Navigation à facettes sans plafond : proche du point précédent mais propre aux sites à catalogue profond, où chaque facette supplémentaire ouvre un nouveau niveau de croisement possible, sans qu'aucune règle ne limite le nombre de facettes cumulables sur une même URL.
• Identifiants de session dans l'URL : quand un site propage un identifiant du type sessionid dans chaque lien plutôt que dans un cookie, la même page devient une URL différente à chaque visite du crawler, qui la traite alors comme un contenu jamais vu.
• Résultats de recherche interne qui pointent vers d'autres résultats : une page de recherche qui suggère des requêtes proches, des corrections orthographiques ou des recherches associées, elles-mêmes explorables, peut générer une chaîne de requêtes construites automatiquement sans rapport avec une intention de recherche réelle.
• Pagination sans fin : quand une page numérotée au-delà du contenu réel renvoie quand même un code de succès avec un lien vers la page suivante, au lieu d'un signal clair de fin de liste, rien n'arrête le crawler d'avancer indéfiniment dans les numéros de page.

Les pièges d'origine technique : erreurs de code plutôt que de conception

Un second groupe de pièges ne vient pas d'une fonctionnalité voulue mais d'un bug d'implémentation, souvent plus difficile à repérer parce qu'aucune page listant les combinaisons possibles n'existe nulle part dans l'interface.

Le cas le plus connu est l'erreur de lien relatif qui imbrique les chemins à l'infini. Une page située à /a/b/ contient un lien relatif vers « b/ » : le navigateur ou le crawler le résout en /a/b/b/. Si le gabarit de cette nouvelle page contient exactement le même lien relatif mal construit, la résolution suivante donne /a/b/b/b/, puis /a/b/b/b/b/, sans limite naturelle. Chaque niveau supplémentaire est une URL distincte, syntaxiquement valide, que le serveur accepte sans erreur puisque rien dans le code ne vérifie la profondeur du chemin.

• Widgets réutilisés (calendrier, fil d'Ariane, menu de filtre) qui se réinjectent eux-mêmes à chaque niveau de profondeur au lieu de pointer vers une racine fixe
• Redirections en boucle qui alternent entre deux ou plusieurs variantes d'une même URL sans jamais se stabiliser
• Générateurs de liens qui construisent l'URL à partir du chemin courant plutôt que d'une valeur fixe, ce qui rend l'erreur invisible tant que personne n'explore le site plus profondément que quelques niveaux

Les dégâts concrets sur le référencement

Un piège à crawl ne provoque pas une pénalité au sens strict, mais une série de dommages indirects qui, cumulés, pèsent sur la visibilité du site entier.

• Budget de crawl consommé sur du contenu sans valeur : chaque requête que le robot passe dans le piège est une requête qu'il ne passe pas sur une page produit, un article ou une page catégorie qui mériterait d'être explorée ou réexplorée.
• Pages réelles explorées en retard ou pas du tout : sur un grand site, un crawler qui boucle dans un piège peut tout simplement ne jamais atteindre certaines sections légitimes lors d'un même passage, retardant la découverte de nouveau contenu ou la mise à jour de contenu modifié.
• Gonflement de l'index (index bloat) : des dizaines de milliers de variantes de faible valeur indexées diluent la proportion de pages utiles dans l'ensemble du domaine, ce qui pèse sur la façon dont les signaux de qualité évalués au niveau du site perçoivent l'ensemble.
• Dilution du maillage interne : le PageRank interne se répartit sur un nombre d'URL qui explose, au lieu de se concentrer sur les pages qui comptent réellement, ce qui affaiblit la force de lien envoyée aux pages piliers.

Comment repérer un piège avant qu'il ne creuse le budget de crawl

Un piège à crawl laisse des traces avant même de devenir un problème visible dans les classements, à condition de regarder aux bons endroits.

• Dans les journaux serveur, un motif d'URL qui concentre une part disproportionnée des requêtes du robot par rapport à ce que représente ce motif dans le contenu réel du site est le signal le plus direct qu'un crawler passe un temps anormal dans une zone donnée.
• Dans un rapport de profondeur d'exploration généré par un outil de crawl, un piège se manifeste par une exploration qui ne se termine jamais dans la limite de profondeur fixée, ou qui continue de découvrir de nouvelles URL à chaque niveau supplémentaire au lieu de converger vers un nombre stable de pages.
• Dans la console de recherche, une croissance soudaine et inexpliquée du nombre d'URL connues ou indexées, sans qu'aucun contenu nouveau n'ait été publié à cette échelle, pointe presque toujours vers une génération automatique d'URL quelque part sur le site.

Les solutions possibles, et ce que chacune coûte réellement

Il existe plusieurs leviers pour traiter un piège à crawl, et ils ne se valent pas : certains sont rapides à poser mais limités, un seul règle le problème à la source.

• Robots.txt sur le motif entier : bloquer un chemin ou un paramètre récurrent est la solution la plus rapide à mettre en place et elle stoppe l'exploration dès la prochaine visite du robot. La contrepartie est qu'elle empêche aussi toute exploration légitime qui tomberait dans le même motif, et qu'elle ne transmet aucune force de lien au-delà du blocage : les URL bloquées deviennent des impasses pour le maillage interne.
• Nofollow sur les liens qui génèrent le piège : retirer le suivi sur le lien « mois suivant » ou sur les combinaisons de filtres empêche le crawler de découvrir de nouvelles instances depuis cette page précise. C'est plus fin qu'un blocage entier, mais Google traite l'attribut comme une indication et non comme une interdiction stricte, et il n'empêche pas la découverte de ces mêmes URL par un autre chemin, comme un plan de site mal généré ou un lien externe.
• Balise canonique là où les doublons sont réels : quand plusieurs URL de tri ou de session pointent vers un contenu identique, une balise canonique vers la version de référence consolide les signaux sur une seule URL. Elle ne fait cependant pas économiser de budget de crawl de la même façon qu'un blocage, puisque le robot doit tout de même récupérer chaque variante au moins une fois pour lire la balise et comprendre vers quoi elle pointe.
• Corriger la génération d'URL elle-même : plafonner la pagination, arrêter d'émettre des liens de calendrier au-delà d'une fenêtre raisonnable, faire passer l'identifiant de session en cookie plutôt qu'en paramètre d'URL, corriger le gabarit responsable du lien relatif mal construit. C'est le seul remède qui traite la cause plutôt que la conséquence, mais c'est aussi le seul qui demande une intervention côté développement plutôt qu'un simple fichier de configuration, donc le seul qui ne peut pas être posé le jour même.

Ce que le blocage par robots.txt ne fait jamais : retirer une URL déjà indexée

Robots.txt contrôle l'exploration, pas l'indexation. Si des URL issues du piège ont déjà été indexées avant que le blocage ne soit posé — parce qu'elles ont été atteintes via un lien externe, un plan de site ou une exploration antérieure — les bloquer via robots.txt ne les retire pas de l'index. Pire : cela empêche le robot de revenir sur ces URL pour constater qu'elles portent désormais une balise noindex, puisqu'il n'a plus le droit de les explorer du tout. Le résultat concret est une URL qui reste visible dans l'index, affichée sans description parce que le contenu n'est plus accessible pour être lu, ce que confirme le rapport Indexation des pages de la console de recherche sous une mention de type « indexée bien que bloquée par robots.txt ».

L'ordre des opérations compte donc. Pour retirer un lot d'URL déjà indexées, il faut d'abord les laisser explorables tout en leur ajoutant une balise noindex, attendre que le robot repasse dessus et retire les pages de l'index, puis seulement à ce moment-là poser un blocage robots.txt pour empêcher toute nouvelle exploration future du même motif et récupérer le budget de crawl. Pour un besoin de retrait plus rapide et temporaire pendant que ce nettoyage se fait, l'outil de suppression d'URL de la console de recherche masque une adresse des résultats pour une durée limitée, le temps que la correction de fond prenne effet.