Le trafic de robots est souvent considéré comme un problème de sécurité ou de référencement. Mais sur l’infrastructure d’hébergement WordPress, il apparaît comme un problème de performance, spécifiquement concentré sur un ensemble très particulier d’URL.

Toutes les requêtes n’ont pas le même coût. La différence entre une page statique mise en cache et un point d’accès dynamique n’est pas une légère nuance de performance. C’est la différence entre une requête qui ne coûte presque rien et une requête qui réserve un thread PHP, déclenche une requête complète de la base de données et génère des frais généraux de session, que le visiteur soit un vrai client ou un robot qui ne convertit jamais.

Comprendre pourquoi certains points de terminaison sont beaucoup plus coûteux que d’autres est ce qui différencie une stratégie de gestion des robots qui fonctionne réellement d’une stratégie qui bloque trop ou pas assez.

Toutes les requêtes ne sont pas égales

Lorsqu’un visiteur arrive sur une page WordPress typique, comme un article de blog, une liste de produits ou une page « à propos », le serveur sert presque toujours la réponse à partir du cache.

Accès au cache Kinsta pour les pages statiques
Accès au cache Kinsta pour les pages statiques

Le cache pleine page de Kinsta gère cela à la périphérie (edge), de sorte que la requête ne déclenche jamais le PHP d’un serveur ou sa base de données.

Mais lorsqu’une requête arrive sur un point de terminaison non cachable, le serveur doit effectuer un véritable travail. Un thread PHP est alloué et maintenu pendant toute la durée de la requête, et votre base de données est interrogée. Si la page implique l’état du panier, les sessions de l’utilisateur ou un contenu personnalisé, la gestion des sessions ajoute une couche supplémentaire. Rien de tout cela ne peut être mis en cache, car la réponse est unique pour chaque requête.

Contournement du cache Kinsta pour les pages dynamiques
Contournement du cache Kinsta pour les pages dynamiques

Sur un site sain avec des visiteurs essentiellement humains, c’est parfait. Vos points de terminaison dynamiques servent de vrais clients qui ajoutent des articles à leur panier, les commandent et recherchent des produits. La charge est proportionnelle à l’utilisation réelle.

Le trafic de robots ne correspond pas à ce modèle. Un robot n’ajoute pas d’articles au panier et ne convertit pas, mais il déclenche la même exécution côté serveur qu’un vrai client, à un rythme qu’aucun humain ne pourrait maintenir.

Les points de terminaison spécifiques où cela se produit

Sur une boutique WooCommerce, les modèles d’URL et les points de terminaison suivants ne peuvent pas être mis en cache par conception, et ce sont exactement ceux que le trafic de robots a tendance à toucher le plus durement.

?add-to-cart=

Il s’agit de l’exemple le plus gourmand en ressources que nous ayons documenté dans notre rapport sur l’IA et le trafic de robots. L’ajout d’un produit au panier nécessite une exécution PHP, une écriture dans la base de données et la création ou la validation d’une session. Il n’y a pas de version mise en cache de cette réponse, car chaque réponse est un nouveau travail.

Pour replacer l’échelle dans son contexte : les données de l’infrastructure de Kinsta ont enregistré 7,67 millions de visites d’ajout au panier de la part de cinq robots en l’espace de 24 heures.

7,67 millions de requêtes ont été effectuées sur les URL d'ajout au panier en 24 heures.
7,67 millions de requêtes ont été effectuées sur les URL d’ajout au panier en 24 heures.

Cela représente environ une requête toutes les 11 millisecondes, toute la journée et toute la nuit, chacune exigeant l’exécution complète de PHP et de la base de données, chacune ne générant aucun résultat significatif pour le robot d’exploration, et aucune ne servant un client.

/cart et /checkout

Ces pages sont exclues du cache par défaut dans WooCommerce. Elles contiennent des données de session, l’état du panier personnalisé, et (dans le cas d’une commande) la logique de traitement du paiement.

Un robot qui frappe /checkout de manière répétée ne fait rien d’utile, mais le serveur ne le sait pas. Il traite chaque requête comme s’il s’agissait d’une véritable transaction.

?s= (Requêtes de recherche)

Les requêtes de recherche de WordPress et WooCommerce s’exécutent dans votre base de données à chaque requête. Il n’y a pas de couche de cache qui puisse absorber une chaîne de recherche unique.

Un crawler qui travaille avec des variations d’URL paramétrées ou qui suit simplement chaque lien de recherche qu’il trouve peut générer une longue queue de requêtes de base de données uniques et coûteuses.

Navigation à facettes et paramètres de filtrage

C’est ici que le problème s’aggrave. Un catalogue de produits WooCommerce typique génère des URL comme :

/shop/?color=blue
/shop/?color=blue&size=M
/shop/?color=blue&size=M&orderby=price
/shop/?color=blue&size=M&orderby=price&paged=2

Pour un humain, il s’agit de variations mineures de la même page. Pour un robot qui suit les liens, chacune est une URL unique qui mérite d’être explorée, et chacune exige du serveur qu’il exécute une requête de base de données filtrée à partir de zéro.

La documentation de Google identifie explicitement la navigation à facettes comme une source d’inefficacité du crawl, où les robots explorent des variations quasi infinies du même contenu. Mais le problème n’est pas seulement que cela gaspille le budget d’exploration. Chaque variation coûte des ressources serveur réelles pour être générée.

Interactions alimentées par AJAX

De nombreuses extensions WordPress, telles que les listes de souhaits, les vérifications de disponibilité, les mises à jour de prix en direct et les affichages de calendrier, reposent sur des requêtes AJAX qui contournent entièrement le cache de la page.

Un bot qui déclenche ces interactions, même indirectement en chargeant une page qui les déclenche, crée une charge côté serveur qui n’apparaît pas comme une « requête de page » dans vos analyses, mais qui apparaît dans votre utilisation des threads PHP.

Que se passe-t-il lorsque les threads PHP sont épuisés ?

Chaque point de terminaison dynamique utilise un thread PHP pendant toute la durée de la requête. Ce détail semble mineur pris isolément, mais la capacité des threads est limitée et les robots ne font pas la queue poliment.

Kinsta alloue un nombre fixe de threads PHP par site WordPress, et chaque requête non mise en cache en réserve un pour toute sa durée.

Limite de performance PHP dans Mykinsta
Limite de performance PHP dans Mykinsta

Dans des conditions normales de trafic, il s’agit rarement d’une contrainte. Les requêtes arrivent, sont traitées rapidement et les threads se libèrent.

En cas de charge soutenue de robots sur des points de terminaison dynamiques, les threads sont réservés et conservés. Lorsque tous les threads sont occupés, les nouvelles requêtes entrantes attendent dans une file d’attente. Les clients réels qui essaient d’ajouter un produit à leur panier ou d’effectuer un paiement sont confrontés à des chargements de page lents, à des délais d’attente ou à des erreurs HTTP 504.

Erreur 504 de délai d'attente de la passerelle
Erreur 504 de délai d’attente de la passerelle

Telle est la réalité infrastructurelle qui fait que le trafic de robots sur les points de terminaison dynamiques est matériellement différent du trafic de robots sur les pages pouvant être mises en cache.

Le problème de la boucle : lorsque les robots sont bloqués

Une grande partie du trafic de robots que l’équipe d’infrastructure de Kinsta observe n’est pas le résultat d’une attaque intentionnelle. C’est le résultat de robots d’indexation qui suivent tous les liens de toutes les pages sans aucun mécanisme leur permettant de reconnaître qu’ils tournent en rond.

Voici à quoi ressemble une boucle de chaîne de requêtes dans la pratique :

  1. Un robot arrive sur la page /shop/
  2. La page contient un lien vers /shop/?color=blue (une vue filtrée)
  3. Cette page contient un lien vers /shop/?color=blue&size=M
  4. Cette page contient un lien vers /shop/?color=blue&size=M&orderby=price
  5. Cette page contient un lien pour ajouter quelque chose au panier : /shop/?add-to-cart=123
  6. Chacune de ces pages génère des liens légèrement différents que le robot n’a pas encore visités

Le robot suit tout le monde. Il n’a aucune notion de « j’ai déjà vu cette page produit dans un état de filtrage différent » Chaque URL semble nouvelle, est demandée et frappe le serveur fraîchement.

Ce schéma précis de robots parcourant des variations de chaînes de requête à travers des points de terminaison dynamiques est l’un des problèmes les plus courants que nous avons relevés dans notre rapport. Une seule règle de boucle déclenchée par un modèle de comportement erroné a filtré 550 millions de requêtes en 30 jours sur l’infrastructure de Kinsta. Il ne s’agit pas d’une attaque, mais d’une automatisation inefficace à grande échelle, qui s’aggrave parce que rien n’a été détecté à temps.

Ce à quoi ressemble une bonne gestion des robots au niveau des points de terminaison

Pour les boutiques WooCommerce et les sites WordPress avec des fonctionnalités dynamiques, quelques principes s’appliquent indépendamment de votre configuration spécifique.

  1. Robots.txt est un signal, pas un bouclier. Vous pouvez (et devez) interdire aux robots d’explorer les chemins /cart, /checkout et ?add-to-cart= dans votre fichier robots.txt. Googlebot respecte cette règle. Toutefois, le respect du fichier robots.txt est volontaire. Un nombre croissant de robots d’entraînement à l’IA ne le vérifient pas ou ne le respectent pas. L’interdiction d’un chemin dans le fichier robots.txt communique votre intention ; son application nécessite une règle de niveau WAF.
  2. Resserrez la génération des réglages d’URL. La configuration par défaut de WooCommerce génère une longue queue de variantes d’URL à travers les jetons de session, les réglages de quantité et les combinaisons de filtres. Réduire la prolifération des réglages à la source grâce aux balises canoniques, aux structures des permaliens consolidées et aux règles robots.txt Disallow sur les variantes de réglages réduit le nombre de boucles dans lesquelles les robots d’indexation peuvent s’enliser.
  3. Surveillez les points de terminaison, et pas seulement le volume total des requêtes. Un pic du trafic global peut correspondre à une campagne. Un pic dans les requêtes vers ?add-to-cart= provenant d’un agent utilisateur autre qu’un navigateur est un problème de robot. Les journaux de serveur et les outils d’analyse qui vous montrent la distribution des requêtes par modèle d’URL et par agent utilisateur font la différence entre une prise en charge en quelques heures et une prise en charge en quelques jours.
  4. Protégez la capacité des threads PHP en tant que mesure principale. Si vos threads PHP fonctionnent régulièrement à pleine capacité et que vous n’avez pas de pic correspondant dans les sessions d’utilisateurs réels, le trafic de robots sur les points de terminaison dynamiques est presque certainement un facteur contributif. L’outil APM de Kinsta affiche les transactions PHP les plus lentes par point de terminaison, de sorte que si les chemins de panier ou de commande sont coupables, vous le voyez directement plutôt que de le deviner.

A quoi cela ressemble pour différents types de sites

Le problème des points de terminaison dynamiques est le plus aigu pour les boutiques WooCommerce, mais il apparaît sous diverses formes sur différents types de sites.

  1. Les boutiques WooCommerce sont les plus exposées car leurs points de terminaison les plus coûteux, tels que le panier, la commande et les pages de produits filtrés, sont exactement ceux que les robots ont tendance à trouver par le biais d’un suivi de lien normal. Les conséquences sont directes : L’épuisement des threads PHP lors des pics d’activité des robots dégrade les performances de paiement pour les clients réels.
  2. Les sites de contenu et les blogs sont moins exposés du point de vue du paiement, mais ils peuvent être considérablement affectés par les robots qui parcourent les archives paginées, les pages d’étiquettes et les résultats de recherche. Chaque requête de recherche unique est une nouvelle entrée dans la base de données. Un robot d’exploration agressif qui parcourt systématiquement une grande archive peut générer une charge soutenue de la base de données, même sans toucher à aucune fonctionnalité de la « boutique ».
  3. Les sites d’entreprises et de services sont plus exposés aux points de terminaison des formulaires (formulaires de contact, formulaires de demande de devis et flux de réservation), qui impliquent la gestion de sessions et souvent l’écriture de données dans la base de données. Les données de formulaires envoyées par des robots constituent un problème différent (pollution du CRM, gaspillage des efforts de vente), mais le mécanisme sous-jacent est le même : des points de terminaison dynamiques qui coûtent des ressources réelles à chaque fois qu’ils sont sollicités.
  4. Les applications Web et les produits SaaS sont les cas les plus sensibles. Leurs points de terminaison API, leurs itinéraires de tableau de bord et leur logique d’application ne peuvent pas être mis en cache, et tout trafic de robots qui atteint la couche d’application contourne entièrement l’infrastructure de mise en cache. La réponse appropriée ici est généralement un blocage dur de tout le trafic non authentifié vers les chemins /api et /app, avec une liste explicite d’autorisations pour les intégrations légitimes.

Pour aller plus loin : Tout savoir sur le trafic des robots

Le problème des points de terminaison dynamiques fait partie d’un changement plus large dans la façon dont le trafic de robots affecte l’infrastructure de WordPress. Les crawlers d’IA ont augmenté de manière significative en volume et ont changé de comportement, avec un suivi de lien plus agressif, une plus grande volonté d’ignorer les directives de crawl, et un trafic plus important atteignant précisément les points de terminaison qui coûtent le plus cher à desservir.

Pour un regard complet sur ce qui a changé, les données qui le sous-tendent, et un cadre pour prendre des décisions de gestion des robots en fonction de votre type de site spécifique et de vos priorités, le rapport complet de Kinsta sur The AI & Bot Traffic Reality Check couvre tout cela, y compris l’analyse de plus de 10 milliards de requêtes sur l’infrastructure gérée par Kinsta.

Si vous êtes prêt à agir en fonction de ce que vous avez lu ici, la protection contre les robots de Kinsta gère automatiquement les modèles les plus courants, y compris la protection des points de terminaison dynamiques à coût élevé. Activez le niveau de protection que vous souhaitez une fois dans MyKinsta, et le système s’occupe du reste.

Vous pouvez également contacter l’équipe du support si vous avez besoin d’éclaircissements.

Joel Olawanle Kinsta

Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.