L’équipe en charge de l’exploration chez Google a commencé à signaler directement des bugs auprès de développeurs de plugins WordPress lorsqu’elle détecte un important gaspillage de crawl à grande échelle.

Gary Illyes, analyste chez Google, a détaillé ces démarches lors du dernier épisode du podcast Search Off the Record. Son équipe a déposé un rapport de problème contre WooCommerce après avoir identifié certains paramètres d’action générés par le plugin comme l’une des principales sources de gaspillage de crawl. L’éditeur de WooCommerce a corrigé le comportement rapidement.

Toutefois, tous les éditeurs de plugins ne se montrent pas aussi réactifs. Une signalisation similaire adressée à un autre plugin ajoutant des paramètres d’action reste sans réponse, et les tentatives de contact auprès de l’éditeur d’un calendrier commercial, responsable de la création de chemins d’URL quasi-infinites, seraient restées sans suite.

Ce que Google a observé

Ces constats sont extraits du rapport interne annuel de Google sur les problèmes d’exploration, que Gary Illyes a expliqué pendant le podcast avec Martin Splitt, un autre membre de l’équipe Search Relations de Google.

Selon les chiffres présentés, les paramètres d’action représentaient environ 25% de l’ensemble des problèmes d’exploration signalés en 2025. La navigation à facettes arrivait en tête, avec près de 50%. Ensemble, ces deux catégories constituaient aux alentours de trois quarts des problèmes documentés par Google l’année précédente.

Le nœud du problème tient au fait que chaque paramètre ajouté à une URL peut être interprété comme une nouvelle page par les robots d’indexation : des chaînes telles que ?add_to_cart=true modifient la URL et peuvent se cumuler, multipliant ainsi l’espace d’URL explorables d’un site — doublant, triplant, voire plus — sans offrir de contenu réellement distinct.

Selon Illyes, ces paramètres sont souvent injectés par la couche des plugins du système de gestion de contenu plutôt que conçus intentionnellement par les propriétaires de sites.

Comment WooCommerce a été corrigé

L’équipe chargée du crawl chez Google a ouvert un ticket contre le plugin, signalant que le comportement lié au paramètre d’ajout au panier (add-to-cart) générait un volume important de gaspillage de crawl touchant de nombreux sites.

Voici comment l’équipe a décrit sa méthode d’investigation :

Ils expliquent qu’ils ont cherché l’origine de ces paramètres d’action et que, compte tenu de la popularité de WordPress comme CMS, il était fréquent d’identifier des plugins responsables — par exemple ceux gérant l’ajout au panier ou aux listes de souhaits. Lorsqu’un plugin était open source et disposait d’un dépôt public, Google déposait alors un signalement pour que le bug soit traité.

Dans le cas de WooCommerce, cette procédure a porté ses fruits : le correctif a été développé et déployé rapidement. Illyes a souligné la rapidité de la réaction, tout en précisant que d’autres plugins présentant des comportements semblables n’ont pas donné suite — il n’a pas nommé ces derniers.

Illyes a d’ailleurs insisté sur le caractère appréciable de la réactivité : il a salué l’intervention prompte des équipes derrière WooCommerce qui ont su corriger le problème.

Pourquoi cela a une réelle importance

Ce type de problème d’URL paramétrées n’est pas nouveau : Illyes l’avait déjà évoqué par le passé et Google a depuis publié des directives relatives à la navigation à facettes et à la gestion des paramètres d’URL. Pourtant, les données montrent que ces mises en garde et ces documents de bonnes pratiques n’ont pas suffi à enrayer le phénomène, puisque les mêmes catégories continuent de dominer les rapports d’exploration.

Le problème est fréquemment introduit au niveau du plugin, ce qui place les propriétaires de sites dans une position délicate : même si la cause provient d’un composant tiers, la charge et les conséquences pèsent sur le site exploité. En d’autres termes, votre site peut subir un volume d’exploration élevé et des tensions serveur sans que vous soyez l’auteur direct du code générant ces paramètres.

Illyes a rappelé un point technique important : Googlebot ne peut pas déterminer si un grand espace d’URL est utile tant qu’il n’a pas crawlé une part significative de cet espace. Autrement dit, le robot doit parfois parcourir une grande quantité d’URL — y compris celles sans valeur — avant d’écarter les chemins inutiles. À ce stade, le serveur peut déjà subir des conséquences visibles.

Pour limiter l’impact, Google recommande de manière récurrente l’usage de robots.txt pour bloquer de manière proactive les chemins de paramètres indésirables, car cela prévient l’exploration inutile avant qu’elle ne devienne problématique.

Que peuvent faire les propriétaires de site et les développeurs de plugins ?

La situation révèle une série d’actions concrètes à mettre en place, tant du côté des éditeurs de plugins que des administrateurs de sites. Voici une synthèse des bonnes pratiques, classées par rôle.

Pour les administrateurs de sites (propriétaires / responsables techniques)

• Analyser les logs serveur et les rapports d’exploration pour repérer les schémas d’URL contenant des paramètres d’action (par exemple ?add_to_cart= ou d’autres chaines répétées). Une hausse anormale de requêtes vers des URL paramétrées est un signal d’alerte.
• Ajouter des règles dans le fichier robots.txt pour bloquer les motifs d’URL qui ne doivent pas être crawlé(e)s. Bloquer préventivement les espaces de paramètres inutiles évite un gaspillage de ressources d’exploration.
• Utiliser des balises rel= »canonical » lorsque le contenu reste identique malgré des paramètres différents, afin d’indiquer la version principale à indexer.
• Lorsque le comportement le permet, empêcher l’indexation des pages générées par des paramètres via noindex (meta robots) ou X-Robots-Tag côté serveur.
• Privilégier l’envoi d’actions (comme l’ajout au panier) via des requêtes POST plutôt que des liens GET contenant des paramètres, ou utiliser des mécanismes JavaScript qui n’exposent pas des URL indexables.
• Mettre à jour et surveiller régulièrement les plugins utilisés ; appliquer les correctifs dès qu’ils sont disponibles.
• Surveiller Google Search Console (rapports d’exploration, couverture, statistiques de crawl) pour détecter précocement les variations et identifier les zones problématiques.
• Limiter l’exposition publique des chemins qui n’ont pas d’intérêt SEO (par ex. pages action, filtres temporaires, sessions), en évitant de les inclure dans les sitemaps XML.

Pour les développeurs de plugins et éditeurs

• Éviter de générer des liens GET publics comportant des paramètres d’action dans le HTML rendu, sauf si ces liens correspondent à des contenus réellement distincts et indexables.
• Si une action doit être accessible, préférer les requêtes POST ou utiliser des endpoints non-attachés à l’indexation (par exemple via des API REST où la réponse n’est pas une page HTML indexable).
• Ajouter des en-têtes ou des attributs qui empêchent l’indexation des pages d’action (meta robots, X-Robots-Tag, ou des entêtes HTTP pour les réponses des endpoints).
• Documenter les implications SEO des comportements du plugin et fournir des options de configuration permettant aux administrateurs de contrôler la façon dont les paramètres sont exposés.
• Maintenir un dépôt public et un canal d’assistance actif : lorsqu’un acteur tel que Google signale un bug, une réaction rapide limite l’impact sur l’écosystème.
• Pour les plugins open-source, accepter et traiter les signalements de sécurité/qualité provenant de la communauté ou d’organisations extérieures.

Mesurer et diagnostiquer le gaspillage de crawl

Avant d’agir, il est utile de quantifier l’étendue du phénomène :

• Consulter les logs serveur pour calculer la proportion de requêtes faites vers des URL contenant des paramètres et identifier les motifs récurrents.
• Analyser les exports de Google Search Console (rapports d’exploration et couverture) pour repérer les pages qui reçoivent beaucoup de visites de Googlebot mais qui n’apportent pas de trafic organique utile.
• Utiliser des outils d’analyse de site (crawl locaux) pour simuler un crawl et repérer les chemins paramétrés en masse.
• Comparer la consommation de crawl avant et après modifications pour valider l’efficacité des mesures prises.

Aspects techniques : pourquoi les paramètres posent-ils problème ?

Du point de vue d’un robot d’exploration, une URL est une entrée distincte. Lorsque des paramètres sont ajoutés, même si le contenu renvoyé n’est pas différent de la page canonique, le robot doit décider s’il s’agit d’une ressource nouvelle. Tant qu’il n’est pas certain que ces variations sont inutiles, il peut continuer à explorer ces chemins, augmentant le volume global d’exploration.

Quelques mécanismes aggravants :

• Les paramètres s’empilent facilement — un site combinant filtres, tris et actions peut générer une combinatoire massive d’URL.
• Les liens générés par les plugins peuvent être présents dans des pages largement crawlées (catalogues, pages catégories), ce qui propage l’exploration de ces paramètres à l’ensemble du domaine.
• Si les pages paramétrées sont accessibles sans signe clair d’inutilité (pas de noindex, pas de canonical), le robot n’a pas d’indication explicite et poursuit l’exploration.

Solutions techniques recommandées

Plusieurs approches techniques permettent de réduire durablement l’impact :

• Bloquer les motifs paramétriques indésirables via robots.txt (ex. Disallow: /*?add_to_cart=).
• Déclarer une rel= »canonical » vers la version propre de la page pour toutes les variantes sans valeur ajoutée.
• Utiliser noindex pour les pages générées par des paramètres procéduraux et non destinées à l’indexation.
• Mettre en place des redirections ou des réponses 410/404 pour des chemins d’action non pertinents (en faisant attention aux conséquences pour l’expérience utilisateur).
• Générer des actions côté serveur via APIs ou POST en évitant des liens publics indexables.

Exemples concrets et conséquences opérationnelles

Imaginons un site e-commerce utilisant un plugin de panier qui ajoute systématiquement ?add_to_cart=true à des liens de produits présents sur des pages catégorie très populaires. Si ces liens restent indexables et accessibles, Googlebot peut être amené à crawler des milliers d’URL contenant ce paramètre, multipliant les requêtes vers le serveur. Résultat : augmentation de la charge serveur, quota de crawl consommé inutilement, latence accrue pour le rendu des pages importantes et, potentiellement, délais dans l’indexation de contenus utiles.

Dans un autre cas, un calendrier mal conçu qui encode des identifiants de session ou des dates dans le chemin des URL peut produire des centaines de milliers d’entrées distinctes au fil du temps. Sans blocage, l’indexation devient chaotique et le moteur doit trier un volume massif d’entrées sans valeur SEO.

Que fait Google de son côté ?

L’initiative de l’équipe d’exploration de Google consistant à déposer des signalements auprès des dépôts open-source représente un changement pragmatique : plutôt que de se limiter aux alertes publiques et aux guidelines, Google intervient directement sur la chaîne de production des plugins lorsqu’il en identifie la source et que la correction est réalisable via le dépôt du code.

Cette approche est particulièrement efficace avec des projets à source ouverte et une bonne gouvernance des contributions, car elle permet aux mainteneurs d’identifier rapidement le problème et d’appliquer un correctif. Le cas de WooCommerce en est un exemple : le correctif a été appliqué rapidement après l’ouverture du signalement.

Cependant, dès lors que l’éditeur est fermé, non réactif ou que le plugin est commercial sans processus public de signalement, l’efficacité de ce canal est limitée. Google l’a confirmé : certaines démarches de contact seraient restées sans réponse.

Perspectives et bonnes pratiques à long terme

Les mesures correctives techniques sont nécessaires à court terme, mais une stratégie durable implique :

• Une meilleure sensibilisation des développeurs de plugins aux implications SEO de leurs choix d’implémentation.
• Des options de configuration claires dans les plugins, permettant aux administrateurs de contrôler l’exposition des paramètres et leur comportement vis-à-vis des moteurs de recherche.
• Des tests automatisés et des revues de code intégrant des vérifications sur la génération d’URL indexables.
• La mise en place d’indicateurs de performance (KPIs) autour du budget de crawl et de la consommation de ressources d’exploration par catégorie d’URL.

En pratique, l’effort combiné des mainteneurs de CMS, des développeurs de plugins et des administrateurs de sites est nécessaire pour éviter que des comportements non optimaux au niveau du code tiers n’affectent l’évolutivité et la santé SEO d’un grand nombre de sites.

Ressources et références

Pour aller plus loin, l’épisode complet du podcast avec Gary Illyes et Martin Splitt, qui présente le rapport de fin d’année et ces investigations, est disponible (avec transcription) ici : transcription de l’épisode.

En synthèse, le message central est le suivant : la prolifération de paramètres d’action et la mauvaise gestion de la navigation à facettes continuent de constituer la majeure partie des problèmes d’exploration signalés par Google. Les propriétaires de sites doivent donc combiner détection (logs, rapports) et action (fichiers robots.txt, canonical, noindex, correctifs de plugins) pour protéger leur budget de crawl et préserver la performance globale de leur plateforme face à une exploration automatisée intensive.