Lorsque l’utilisation des ressources sur le site d’un client commence à augmenter sans que le nombre de visites n’augmente réellement, passer à un plan supérieur semble être la bonne décision. C’est un principe judicieux lorsque la croissance provient d’un trafic réel qui accroît la charge et les besoins en capacité.
Cependant, si la mise à l’échelle ajoute des ressources, elle ne réduit pas pour autant le nombre de requêtes qui parviennent au serveur. Si le trafic généré par les robots vient s’ajouter à ces requêtes et à la charge du serveur, une capacité accrue ne fait que leur donner davantage d’espace pour opérer.
En conséquence, les coûts d’exploitation augmentent, mais les problèmes de performances restent les mêmes. L’outil de protection robot de Kinsta est conçu pour ce type de situation, car il vous permet de contrôler ce qui parvient à votre serveur, plutôt que d’élargir la surface d’attaque qui l’absorbe.
Pourquoi les robots ne se comportent-ils pas comme du trafic réel ?
Un visiteur humain confronté à une page lente peut attendre, la recharger ou simplement quitter le site. À l’inverse, un robot continue d’envoyer le même volume de requêtes, quelle que soit la réponse de votre serveur. Ce problème fondamental, à savoir que le trafic généré par les robots ne peut pas s’autoréguler lorsque vous ajoutez des ressources, signifie que la mise à niveau de votre plan offre aux robots davantage de capacité à consommer.
La situation se complique lorsque l’on tient compte de la manière dont les sites WordPress modernes traitent les requêtes. La plupart du trafic généré par les robots n’atteint pas les pages statiques que votre cache peut absorber. Au contraire, il cible des points de terminaison qui contournent les systèmes de mise en cache et obligent le serveur à fournir davantage d’efforts. Sur tout site utilisant WooCommerce, la fonction de recherche ou les filtres, cela signifie que les robots ciblent plusieurs éléments :
- Les actions du panier et les variantes du réglage
?add-to-cart=. - Les pages de produits filtrées avec différentes combinaisons de chaînes de requête.
- Les requêtes de recherche.
- Les étapes de commande et les actions liées à la liste de souhaits.
- Les interactions basées sur AJAX.
Aucun de ces éléments ne peut être mis en cache de la même manière qu’une page statique. Pour chaque requête qui arrive sur l’un de ces points de terminaison, plusieurs opérations se produisent côté serveur :
- Exécution de PHP. Un thread PHP est réservé pour toute la durée de la requête. En cas de charge soutenue due aux robots, les threads s’épuisent et vos visiteurs doivent patienter.
- Requêtes de base de données. Les pages dynamiques interrogent la base de données à chaque chargement, car il n’existe pas de couche de mise en cache pour absorber ces requêtes.
- Gestion des sessions. Les pages de panier et de commande créent ou valident des sessions à chaque requête, ce qui ajoute une charge supplémentaire, même pour les robots qui ne génèrent pas de conversion.
D’après les données de notre propre infrastructure, un seul robot a pu générer 3,75 millions de requêtes vers des URL d’ajout au panier en l’espace de 24 heures. Cela équivaut à environ une requête toutes les 23 millisecondes, 24 heures sur 24. Par ailleurs, une seule règle de détection de boucles a filtré 550 millions de requêtes sur l’ensemble de la plateforme au cours d’une période de 30 jours.
Cependant, il ne s’agit pas là de volumes d’attaques au sens traditionnel du terme. Ils résultent de robots conçus pour suivre toutes les URL qu’ils trouvent, y compris certaines variations de chaînes de requête et certains chemins basés sur des réglages.
« Du point de vue de l’infrastructure, il n’existe pas de « simple trafic de robots ». Chaque requête représente un travail réel. À grande échelle, un exploration inefficace cesse d’être un problème de trafic pour devenir un problème de ressources. » – Daniel Pataki, directeur technique, Kinsta
À quoi ressemble le coût du trafic généré par les robots ?
Les agences sont souvent confrontées à un schéma récurrent : dès que l’utilisation des ressources augmente, les clients passent à un forfait supérieur, puis l’utilisation des ressources augmente à nouveau. Pendant ce temps, les performances ne s’améliorent pas, car le volume de requêtes sous-jacent n’a pas changé.
Comme la facturation de Kinsta exclut le trafic de robots de l’utilisation de votre plan, vous disposez d’un moyen rapide de déterminer si les robots constituent un problème. Les agents utilisateurs de robots reconnus sont déjà filtrés de l’écran Visites dans la section Analyses de MyKinsta. Si ces statistiques semblent normales alors que votre serveur est sous pression, le trafic automatisé en est probablement la cause.
La vue Analyse du trafic des robots et du trafic automatisé dans MyKinsta fournit une ventilation plus claire du trafic atteignant votre site, notamment les robots vérifiés, les robots potentiels, les robots d’indexation IA, les robots d’indexation agressifs, le trafic automatisé et les visiteurs probablement humains.
Cela permet d’identifier plus facilement les cas où le trafic automatisé est à l’origine d’une utilisation accrue des ressources. Par exemple, les pics d’activité des robots d’indexation agressifs ou du trafic automatisé indiquent souvent que des robots accèdent de manière répétée à des points de terminaison non mis en cache.
Le graphique des résultats de la protection contre les robots montre également comment les requêtes sont traitées après classification, y compris le trafic autorisé, contesté ou bloqué. Cela vous donne une image plus claire de la manière dont vos réglages de protection actuels affectent le trafic entrant.
Le rapport Requêtes les plus fréquentes par nombre de vues reflète également ce qui génère de la charge sur votre serveur, et il inclut l’ensemble du trafic, et pas seulement les visites facturables. L’écart entre ces deux chiffres correspond à la partie de vos coûts qui s’accumule sans explication claire.
Voici comment interpréter cet écart :
- Vérifiez d’abord le nombre de visites dans Sites >
sitename> Analyses > Utilisation du plan. Si le nombre de visites semble normal, vous n’êtes pas confronté à une véritable augmentation du trafic humain. - Ouvrez la section Top des requêtes par vues pour afficher l’ensemble du trafic, y compris celui des robots. Un regroupement de requêtes à fort volume visant des chemins non mis en cache (URL d’ajout au panier, variations de chaînes de requête ou étapes de paiement) confirme que les robots consomment des ressources auxquelles votre cache n’a pas accès.
- Jetez un coup d’œil rapide au rapport Performance. C’est là que la charge générée par les robots se traduit par une sollicitation excessive du serveur, notamment par des temps de réponse PHP élevés ou le dépassement des limites de threads.
Si vous gérez des portefeuilles de clients, chaque site affecté par une charge générée par des robots représente un coût difficile à justifier, en particulier lorsque les performances ne se sont pas améliorées après une mise à niveau. Le trafic des bots IA a augmenté de 300 % au cours de l’année écoulée, tandis qu’une visite Web sur 31 est le fait d’un robot IA. Ce volume ne se résout pas de lui-même.
La sécurité au niveau de la plateforme de Kinsta bloque déjà le trafic entrant classé comme malveillant avant qu’il n’atteigne votre site, ce qui inclut la protection contre les attaques DDoS et les requêtes provenant d’adresses IP associées à des sources d’attaques connues. Entre ce trafic et celui que vous souhaitez recevoir, il existe une catégorie de requêtes automatisées non vérifiées, à fort volume et gourmandes en ressources, qui parviennent malgré tout jusqu’à votre serveur. Les contrôles de la protection anti-robots de Kinsta permettent de réduire ce volume.
Fonctionnement de la protection contre les robots de Kinsta
Les contrôles de protection contre les robots dans MyKinsta opèrent au niveau de l’infrastructure, et le filtrage s’effectue avant même que WordPress n’intervienne. Il n’y a donc aucun plugin à installer ni aucune configuration WordPress à modifier.
Kinsta classe chaque requête en combinant sa propre analyse du trafic et le système d’apprentissage automatique de Cloudflare, qui attribue à chaque visiteur un score de robot compris entre 1 et 99. Un score élevé indique que la requête provient très probablement d’un humain ; un score faible signifie qu’il s’agit d’une activité automatisée.
Le trafic est regroupé en catégories telles que les robots vérifiés, les robots probables, les robots d’indexation IA, les robots d’indexation agressifs, le trafic automatisé et les visiteurs probablement humains. Le niveau de protection que vous sélectionnez détermine la manière dont chaque catégorie est traitée.
Vous pouvez gérer la protection contre les robots dans MyKinsta, sous Sites > nom du site > Protection contre les robots.
Choisir un niveau de protection
Vous avez le choix entre quatre niveaux dans le panneau Niveau de protection de l’écran Protection contre les robots :
- Bloquer le trafic malveillant est le niveau par défaut ; il gère l’atténuation des attaques DDoS et bloque le trafic provenant d’adresses IP et de terminaux associés à des sources d’attaques connues.
- Bloquer les automatisations s’appuie sur le réglage par défaut pour bloquer également le trafic automatisé confirmé, tout en laissant passer les robots vérifiés et les visiteurs réels.
- Défier les robots bloque le trafic automatisé et malveillant et ajoute une étape de vérification pour les robots potentiels. Les visiteurs qui réussissent cette vérification ne sont plus soumis à cette épreuve pendant dix jours sur le même navigateur et la même adresse IP.
- Défier tout le monde applique également des vérifications aux utilisateurs susceptibles d’être des humains. Ce niveau convient à une utilisation à court terme lors de pics de trafic.
Pour modifier le niveau, accédez à Sites > sitename > Protection contre les robots, puis cliquez sur Modifier. Depuis la section Sites, vous pouvez sélectionner les sites concernés et utiliser Actions > Modifier la protection contre les robots.
Toutefois, lorsque vous passez au niveau Défier les robots ou à un niveau supérieur, tout outil se connectant à votre site par programmation et ne figurant pas dans le répertoire des robots vérifiés de Cloudflare sera bloqué ou soumis à une vérification. Cela concerne les intégrations personnalisées, les scripts de déploiement et les outils de surveillance de disponibilité auto-hébergés. Si vous utilisez l’un de ces outils, il est recommandé de vérifier qu’il figure bien dans la liste avant d’augmenter le niveau de protection.
Blocage des robots d’indexation IA
Le bouton Bloquer les robots d’exploration IA cible spécifiquement les robots d’exploration IA. Il s’agit de robots qui collectent du contenu à des fins d’entraînement de modèles, de génération augmentée par la récupération et de fonctionnalités de recherche basées sur l’IA. Cela n’affecte pas les robots d’exploration des moteurs de recherche, mais inclut les robots dédiés tels que GPTBot. Googlebot et Bingbot continuent d’indexer votre site, que ce commutateur soit activé ou désactivé.
En général, 80 % de l’ensemble de l’activité d’exploration par l’IA est destinée à l’entraînement de modèles plutôt qu’à des requêtes déclenchées par les utilisateurs. Cela ne génère aucun trafic de référence vers votre site. Il est donc judicieux d’activer cette option. Pour l’activer, rendez-vous dans Sites > sitename > Protection contre les robots, puis cliquez sur le curseur situé à côté de Bloquer les robots d’exploration IA. Si vous gérez plusieurs sites, utilisez Actions > Modifier le blocage des robots d’exploration IA depuis la vue Sites.
Cependant, cela a pour contrepartie une visibilité réduite dans les aperçus et les résumés de contenu générés par l’IA. Si cette visibilité est importante pour votre stratégie de contenu, il est recommandé d’évaluer l’impact avant de laisser cette option activée de manière permanente.
Si votre priorité est de gérer la charge du serveur, il s’agit d’une option plus simple que de modifier le fichier robots.txt ou de rédiger des règles spécifiques à chaque robot. Contrairement à ces approches, cette fonctionnalité intervient au niveau de l’infrastructure avant même qu’une requête n’atteigne WordPress.
Gérer la protection au sein d’un portefeuille de clients
Chaque site nécessite des niveaux de protection différents ; ainsi, une boutique WooCommerce dont les pages de produits sont filtrées ne se compare pas à une plateforme de contenu. De plus, chaque site d’un portefeuille de clients présente un profil de trafic, un ensemble d’intégrations et une tolérance aux étapes de vérification qui lui sont propres. Cela signifie qu’appliquer une politique unique à l’ensemble d’un portefeuille entraînera une restriction excessive pour certains sites ou laissera d’autres sites insuffisamment protégés.
Lorsque vous constatez des signes indiquant que le trafic généré par les robots fait grimper les coûts sur le site d’un client, voici une procédure pratique à suivre :
- Commencez par consulter la vue Analyse du trafic des robots et du trafic automatisé dans MyKinsta. Si le trafic humain reste stable tandis que le trafic automatisé, les robots d’indexation agressifs ou l’activité des robots d’indexation basés sur l’IA augmentent, la charge générée par les robots en est probablement la cause.
- Ensuite, ouvrez la section Top des requêtes par vues sous Analyses et recherchez des volumes de requêtes élevés sur des chemins non mis en cache. Un pic d’activité sur les URL add-to-cart, les pages de produits filtrées, les étapes de commande, les requêtes de recherche ou les variations de chaînes de requête est un indicateur fort d’une utilisation des ressources générée par des robots.
- Le rapport Performance permet de confirmer cet impact. L’allongement des temps de réponse PHP, l’augmentation du débit ou l’atteinte des limites de threads sont autant de signes indiquant que le trafic automatisé commence à se traduire par une surcharge du serveur.
- À partir de là, appliquez le niveau de protection adapté au site. L’option Bloquer les automatisations constitue généralement le bon point de départ, tandis que Défier les robots ajoute une couche supplémentaire de vérification pour le trafic susceptible de provenir de robots qui continue d’atteindre l’origine.
- Pour les sites qui s’appuient sur des intégrations, des API ou des fonctionnalités automatisées de WordPress, des réglages tels que Autoriser les automatisations WordPress courantes et Toujours autoriser les exceptions permettent de réduire le risque de blocage de services légitimes.
- Les modifications prennent effet sans aucun temps d’arrêt et vous pouvez les annuler immédiatement si un réglage s’avère plus restrictif que ne le permettent les intégrations du site. Comme les contrôles se situent en dehors de WordPress, le site lui-même ne court aucun risque pendant que vous procédez à l’évaluation.
Pour les agences gérant de vastes portefeuilles sur des hébergements WordPress, cela devient une simple tâche plutôt qu’un projet. Lorsque les réglages de protection correspondent au profil de trafic réel de chaque site, l’utilisation des ressources peut refléter l’activité réelle des utilisateurs. Les indicateurs de performance correspondent à ce que vivent les véritables visiteurs :
« L’idée fausse consiste à penser que le trafic de robots est un simple problème de « blocage ou d’autorisation ». En réalité, il s’agit de politique, de visibilité et de maîtrise économique. » – Cristian Lopez, rédacteur en chef, HostingAdvice
L’explication que vous donnez à un client concernant les coûts doit se rapporter aux décisions que vous avez prises au sujet de son trafic, et non à la capacité que vous avez ajoutée en réponse à une charge que vous ne pouvez pas identifier.
Cessez d’adapter votre infrastructure en fonction d’un problème que vous pouvez contrôler
L’adaptation de votre infrastructure augmente la charge que votre serveur peut absorber. La protection contre les robots réduit la charge qui l’atteint. Il ne s’agit pas de réponses équivalentes à un même problème : l’une ajoute de la capacité, tandis que l’autre élimine la pression qui avait rendu cette capacité supplémentaire nécessaire au départ.
Grâce aux outils d’analyse de MyKinsta, vous pouvez identifier les moments où le trafic automatisé contribue à l’augmentation de l’utilisation des ressources, même lorsque le trafic humain reste stable. À partir de là, la protection contre les robots vous offre les outils nécessaires pour classer, vérifier et bloquer le trafic indésirable avant qu’il n’atteigne WordPress, PHP ou la base de données.
Pour les sites confrontés à une activité excessive des robots d’indexation, le bouton Bloquer les robots d’indexation IA réduit également le trafic généré par l’IA sans affecter les robots d’indexation traditionnels des moteurs de recherche tels que Googlebot ou Bingbot.
Si vous souhaitez exercer un contrôle accru sur la manière dont le trafic automatisé atteint votre infrastructure, la protection contre les robots de Kinsta vous offre la visibilité et les outils de filtrage nécessaires pour réduire la charge inutile directement depuis MyKinsta.
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.
