En 2025, les robots représentaient 53 % de l’ensemble du trafic Web ; c’était la première fois que le trafic automatisé dépassait celui généré par les humains au cours d’une année civile. En juin 2026, Cloudflare Radar estimait ce chiffre à 57,5 %, un renversement de tendance qui, selon le PDG de Cloudflare lui-même, s’est produit plusieurs années avant ses prévisions.
Pour la plupart des administrateurs WordPress, rien de tout cela n’est visible. Leurs tableaux de bord semblent normaux. Le nombre de visites est en hausse. Mais une part croissante de ce qui alimente ces chiffres n’est pas le fait d’un client, d’un lecteur ou d’un prospect, mais d’un robot d’indexation basé sur l’IA qui extrait du contenu pour alimenter un modèle linguistique, et ce à un rythme et à un volume que les robots des moteurs de recherche n’ont jamais atteints.
Cet article explique pourquoi cela affecte les sites WordPress différemment de l’exploration traditionnelle, et comment l’identifier et y répondre directement depuis MyKinsta.
Qu’est-ce qu’un robot d’exploration IA ?
Les robots d’exploration IA sont des bots automatisés qui lisent les pages web accessibles au public et collectent leur contenu pour l’utiliser dans des systèmes d’IA. À première vue, ils ressemblent à un robot d’exploration de moteur de recherche traditionnel, mais leur objectif est différent.
Un robot d’indexation, tel que Googlebot, lit une page afin de l’indexer et de la classer, ce qui permet aux visiteurs de vous trouver. En revanche, un robot d’indexation basé sur l’IA lit la même page pour l’intégrer à un modèle linguistique ou à un modèle d’apprentissage. Cela se produit de plusieurs manières :
- Les robots d’entraînement (tels que GPTBot et ClaudeBot) collectent du texte pour entraîner de grands modèles linguistiques.
- Les robots de récupération extraient des pages en temps réel lorsqu’un utilisateur pose à un outil d’IA une question nécessitant des informations d’actualité.
- Les robots d’indexation construisent la base de données de recherche propre à un fournisseur afin de réduire sa dépendance vis-à-vis de tiers.
Le point commun est qu’aucune de ces méthodes ne vous renvoie de visiteur. L’identification rend la situation imprévisible. Certains robots d’IA utilisent des agents utilisateur nommés et restent dans des plages d’adresses IP publiées. D’autres empruntent l’agent utilisateur d’un navigateur légitime, font tourner les adresses sources ou n’offrent aucune identification fiable.
En résumé, ce trafic est à la fois plus difficile à attribuer et en forte croissance : le rapport « 2025 Radar Year in Review » de Cloudflare estime que les robots d’IA autres que Googlebot représentent en moyenne 4,2 % des requêtes HTML, un chiffre qui a oscillé entre 2,4 % en avril et 6,4 % en juin. Si l’on ajoute Googlebot, qui effectue désormais des explorations à la fois pour l’indexation de recherche et l’entraînement de l’IA, le total des explorations liées à l’IA a atteint environ 8,7 % des requêtes HTML en 2025.
Les normes de crawl établies par les robots d’indexation des moteurs de recherche
Pour comprendre cette évolution, il est utile de se rappeler en quoi consistait réellement l’ancien « contrat ». L’exploration des moteurs de recherche reposait sur un ensemble de conventions partagées qui permettaient aux propriétaires de sites de s’organiser en conséquence. Le protocole d’exclusion des robots (Robots Exclusion Protocol) est apparu en 1994 et a été officialisé en tant que norme Internet en 2022. Quatre principes se sont développés autour de ce protocole, faisant des robots d’exploration traditionnels un élément pour lequel il était possible de mettre en place une infrastructure :
- Le respect du fichier «
robots.txt». Un robot d’exploration lisait ce fichier, identifiait les chemins d’accès interdits et s’en abstenait. - Une limitation automatique du débit. Les robots d’indexation dominants ralentissaient lorsqu’un serveur montrait des signes de surcharge ; ainsi, un site en difficulté recevait moins de requêtes, et non davantage.
- Une identification cohérente. Un agent utilisateur stable permettait de vérifier l’identité d’un robot d’exploration et de décider comment le traiter.
- Fonctionnement dans le cadre d’un « budget d’exploration ». Google définit le budget d’exploration d’un site comme l’ensemble des URL que Googlebot peut et souhaite explorer. Cela empêche tout site d’être exploré sans limite.
À cela s’ajoute le « délai d’exploration » : le temps qu’un robot d’exploration attend entre deux requêtes de page. Il s’agit toutefois d’une directive non officielle ; Google ne l’a donc jamais prise en charge et l’a exclue de la norme officielle. À la place, Googlebot ajuste dynamiquement son propre rythme d’exploration en fonction de la rapidité de réponse de votre serveur. On attend d’un robot d’exploration qu’il « s’adapte au contexte » et qu’il modère lui-même son activité.
Ces conventions sont intégrées au fonctionnement même de l’hébergement. Par exemple, les couches de mise en cache existent parce que les robots d’exploration « bien élevés » demandent les mêmes pages de manière suffisamment prévisible pour que celles-ci puissent être servies à partir du cache. L’ensemble du modèle repose sur l’hypothèse que les robots d’exploration respectent les règles.
En quoi les robots d’indexation basés sur l’IA enfreignent-ils ces normes ?
Les robots d’indexation basés sur l’IA ne respectent pas les règles établies de trois manières :
robots.txtest considéré comme facultatif. Les rapports de TollBit font état d’une augmentation spectaculaire du nombre de bots ignorant les directives du fichier robots.txt. Ces mêmes rapports indiquent que Cloudflare a détecté un important fournisseur de recherche basé sur l’IA accédant au contenu de sites qui l’avaient explicitement interdit.- Il n’y a pas de limitation de débit. De nombreuses implémentations de robots d’indexation IA envoient des requêtes à un débit élevé et constant, quelle que soit la réponse de votre serveur. Dans certains cas, cela n’est même pas délibéré, car certains « codent un robot à l’instinct… et le lâchent » sans jamais vérifier
robots.txt. - Les robots d’indexation se retrouvent pris dans des boucles. Il s’agit d’un phénomène coûteux qui relève davantage d’une structure que d’une intention malveillante. La plupart des robots d’indexation suivent chaque lien qu’ils trouvent et enregistrent chaque URL unique comme une page distincte. Les robots d’indexation basés sur l’IA suivent une variante, qui en génère une autre, qu’ils suivent à leur tour, sans se rendre compte qu’ils tournent en rond.
Le problème, c’est que la plupart des explorations par IA servent à l’entraînement de modèles plutôt qu’à la recherche ou aux requêtes des utilisateurs, ce qui signifie qu’elles ne génèrent aucun trafic de référence vers votre site.
Pourquoi cela se traduit-il par un problème de performances pour votre serveur ?
Le volume n’est pas vraiment le problème ici. Par exemple, une page statique servie à partir du cache ne vous coûte presque rien ; ainsi, un millier de visites mises en cache ne se remarque pratiquement pas. Les problèmes commencent lorsque le trafic contourne le cache, et les robots d’indexation en boucle sont particulièrement doués pour trouver ces chemins.
Sur un site WordPress utilisant WooCommerce, les requêtes de recherche ou de filtrage représentent une part importante des requêtes adressées à des points de terminaison dynamiques plutôt qu’à des pages. Il s’agit généralement d’actions liées au panier, de variantes de réglages ?add-to-cart=, de pages de produits filtrées, de requêtes de recherche et d’interactions basées sur AJAX acheminées via admin-ajax.php. Aucune de ces requêtes ne peut être mise en cache comme le serait un article de blog ; chaque requête oblige donc le serveur à effectuer une :
- Exécution PHP. Un thread PHP est réservé pour toute la durée de chaque requête. En cas de charge soutenue due aux robots, les threads viennent à manquer et les visiteurs réels se retrouvent en file d’attente derrière les robots.
- 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 cache pour absorber la requête.
- Gestion des sessions. Les pages de panier et de commande créent ou valident une session à chaque requête, ce qui ajoute une charge supplémentaire, même pour les robots qui n’achèteront jamais rien.
D’après les données d’infrastructure de Kinsta, un seul robot a généré 3,75 millions de requêtes vers des URL de add-to-cart en 24 heures. Cela représente environ une requête toutes les 23 millisecondes, 24 heures sur 24. Les symptômes se traduisent par des anomalies d’utilisation, des dépassements de bande passante, des processus PHP saturés et des temps de réponse plus lents pour les utilisateurs légitimes. En conséquence, cela ressemble davantage à une exploration classique qu’à une attaque, ce qui peut facilement passer inaperçu.
Comment identifier l’activité d’un robot d’exploration basé sur l’IA dans MyKinsta
Avant de modifier vos réglages, vous devez vous assurer que les robots d’exploration sont bien à l’origine du problème. MyKinsta vous propose trois vues qui, combinées, vous permettent de transformer une intuition en diagnostic.
Tout d’abord, rendez-vous dans Sites > nom-du-site > Protection contre les robots dans MyKinsta. Ici, le graphique « Ventilation des requêtes » affiche toutes les requêtes adressées à votre site au cours des dernières 24 heures et la manière dont Kinsta classe chacune d’entre elles.
La catégorie « Crawlers IA à débit excessif » isole les robots générant des volumes de requêtes suffisamment élevés pour menacer les performances. Lorsqu’une grande partie du graphique se situe dans cette fourchette, il s’agit d’une charge due aux crawlers plutôt que d’une véritable augmentation du nombre de visiteurs.
Le graphique des résultats de la protection contre les robots vous montre ce qu’il est advenu du trafic en le ventilant entre les requêtes autorisées, contestées ou bloquées. Cela vous permet de voir quelle part du trafic automatisé atteint actuellement votre site et quelle part est filtrée avant même d’y parvenir. Comparés côte à côte, ces graphiques vous permettent de déterminer si la charge est déjà gérée ou si elle parvient directement à votre serveur.
Pour établir un lien entre le trafic et le ralentissement, consultez la liste des principales adresses IP clientes dans la section « Analyses » de MyKinsta :
Cela vous permet d’identifier les adresses qui envoient le plus de requêtes ; chaque adresse IP est liée à un service de recherche permettant de vérifier son origine. Enfin, ouvrez l’onglet « Performance » et comparez les pics de temps de réponse aux périodes d’activité intense des robots d’indexation. Si les pics de ressources et le volume de robots augmentent et diminuent de concert, vous savez que la prochaine étape consiste à contrôler le trafic entrant.
Comment gérer les robots d’exploration basés sur l’IA grâce à la protection anti-robots de Kinsta
Une fois la source identifiée, la protection contre les robots de Kinsta vous permet de contrôler chaque catégorie de trafic. Elle vient s’ajouter aux défenses de la plateforme qui filtrent déjà le trafic manifestement malveillant et est incluse dans tous les plans.
Le panneau « Niveau de protection » de l’écran « Protection contre les robots » dans MyKinsta propose quatre réglages au choix :
- « Bloquer le trafic malveillant » est le réglage par défaut. Il gère l’atténuation des attaques DDoS et bloque les adresses IP et les terminaux liés à des sources d’attaques connues.
- « Bloquer les automatisations » ajoute une couche de protection qui bloque le trafic automatisé confirmé tout en laissant passer les robots vérifiés et les visiteurs réels.
- « Défier les robots » ajoute une étape de vérification pour les robots potentiels. Un visiteur qui réussit cette vérification ne sera plus sollicité pendant dix jours sur le même navigateur et la même adresse IP.
- « Défier tout le monde » est le réglage le plus strict et n’autorise que les robots vérifiés. Il s’agit d’un outil destiné à une utilisation à court terme lors d’un pic de trafic.
À partir du réglage « Défier les robots » ou d’un niveau supérieur, tout outil se connectant à votre site de manière programmatique et ne figurant pas dans le répertoire des robots vérifiés de Cloudflare sera soumis à une vérification ou bloqué. Par conséquent, assurez-vous que vos outils essentiels à votre activité figurent bien sur cette liste avant de relever le niveau de sécurité.
Kinsta superpose ses propres règles à la liste des bots vérifiés de Cloudflare. Cela signifie qu’il reclassifie les robots IA vérifiés générant des volumes de requêtes élevés dans la catégorie distincte « Crawlers IA à taux excessif ».
La logique consiste à évaluer un robot d’indexation en fonction de son comportement plutôt que de ses identifiants ; ainsi, un robot vérifié qui commence à saturer votre site est traité comme le problème qu’il est devenu. Lorsque vous réglez la protection sur « Défier les robots » ou un niveau supérieur, cela permet à un service légitime à fort volume de prouver sa légitimité tout en filtrant les robots d’indexation bloqués dans une boucle.
Autres fonctionnalités de protection contre les robots de MyKinsta
Le bouton « Bloquer les robots d’IA » est un contrôle distinct du niveau de protection qui cible spécifiquement les robots d’IA, y compris ceux qui sont vérifiés, tels que GPTBot. Googlebot et Bingbot continuent d’indexer votre site quoi qu’il arrive ; cela permet donc d’éliminer la charge des robots d’IA sans affecter votre visibilité dans les résultats de recherche.
Il s’agit d’une option plus simple que de modifier manuellement le fichier robots.txt ou de gérer des règles spécifiques à chaque robot, mais il convient de bien peser le pour et le contre avant de l’activer.
Le blocage des robots d’indexation IA réduit la fréquence à laquelle votre contenu apparaît dans les réponses et les résumés générés par l’IA. Or, à mesure que les outils d’IA deviennent un canal de découverte de plus en plus important pour certains publics, le fait de s’en priver totalement a des implications qui vont au-delà de la charge du serveur.
Pour les sites où la performance est primordiale, tels que les boutiques WooCommerce, les sites à fort trafic ou les plateformes d’adhésion, le coût en ressources lié au crawling par l’IA est élevé et le retour sur investissement faible ; le blocage peut donc s’avérer une solution plus judicieuse si vous constatez des problèmes. Pour les sites axés sur le contenu, où la visibilité via l’IA constitue une priorité stratégique, le fait de conserver les options « Bloquer les automatisations » ou « Défier les robots » permet de filtrer les comportements les plus indésirables tout en garantissant que votre contenu reste indexable par les plateformes d’IA.
Il n’existe pas de réponse universelle. Le bouton de bascule est là pour vous laisser le choix.
Une protection plus stricte peut bloquer le trafic automatisé dont vous dépendez ; deux réglages permettent donc de le maintenir. La section « Toujours autoriser » vous permet d’ajouter jusqu’à 50 exceptions par adresse IP, chemin d’accès ou agent utilisateur. C’est là que vous répertoriez les éléments qui ne doivent jamais être soumis à un contrôle, tels qu’un service de surveillance, un webhook de commande ou une adresse IP de bureau ou de client de confiance.
L’option « Autoriser les automatisations WordPress courantes » active une « liste d’autorisations » gérée des points de terminaison et services WordPress courants, y compris l’API REST et les tâches en arrière-plan. Vous l’activez en parallèle d’une protection plus stricte lorsque votre site dépend d’extensions, d’intégrations ou de tâches planifiées qui effectuent des requêtes automatisées, afin que le renforcement de vos défenses ne perturbe pas discrètement un flux de travail.
Les nouvelles règles de l’exploration du Web nécessitent une gestion plus rigoureuse de votre part
Alors que les comportements sur Internet ont évolué, votre hébergement n’a probablement pas suivi cette évolution. Les robots d’exploration basés sur l’IA ne répondent pas aux mêmes règles que celles que les moteurs de recherche ont mis deux décennies à définir. robots.txt est facultatif, et l’exploration se poursuit à un rythme élevé et constant. De plus, vous ne tirez aucun bénéfice des ressources utilisées. Cela vous pose un problème de performances et de coûts qui s’apparente davantage à un site en difficulté qu’à l’activité d’un robot d’exploration.
La solution consiste en une série d’étapes simples que vous maîtrisez. Tout d’abord, vérifiez la cause dans les statistiques de MyKinsta. Ensuite, définissez le niveau de protection approprié dans MyKinsta et activez l’option « Bloquer les robots d’indexation IA » afin de réduire la charge générée par ces derniers sans perdre en visibilité sur les moteurs de recherche. Protégez ensuite ce dont vous avez besoin grâce à l’option « Toujours autoriser », afin que des réglages plus stricts ne compromettent pas une intégration fiable. Chaque modification prend effet sans interruption de service, ce qui vous permet de vous adapter à mesure que les tendances évoluent.
Si vous gérez de nombreux sites clients, le programme de partenariat pour agences de Kinsta regroupe ces contrôles avec une assistance dédiée. Découvrez l’hébergement WordPress infogéré de Kinsta pour mettre ce contrôle à profit.
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.
