Le 15 septembre 2026, Cloudflare a basculé un réglage par défaut pour tout nouveau site rejoignant son réseau. Les pages qui affichent de la publicité bloquent désormais automatiquement les robots IA des catégories Entraînement et Agent. Les robots de recherche restent autorisés par défaut. Nous vous avons déjà montré comment connecter un agent IA à votre propre site WordPress via MCP. Ce qui a changé le 15 septembre va dans le sens inverse. Des agents et des robots d’entraînement que vous n’avez jamais invités viennent désormais se présenter seuls sur votre site. Une semaine plus tard, le 22 septembre 2026, Kinsta a publié sa propre réponse à une question que beaucoup de propriétaires de sites WordPress se posent désormais : à quoi ressemble vraiment le trafic de robots IA sur un site réel, et la plupart des gens réagissent-ils de la bonne manière. L’annonce de Cloudflare et les données de Kinsta tombent à une semaine d’écart, et ce n’est pas un hasard. Allons voir ensemble ce que chacune dit vraiment, et l’erreur que commettent la plupart des propriétaires de sites une fois qu’ils se penchent sur leurs propres journaux.
Qu’est-ce qui a vraiment changé le 15 septembre ?
Cloudflare regroupe les robots IA en trois catégories. Les robots d’Entraînement collectent des données pour construire des modèles, les robots Agent agissent sur une demande d’une personne ou d’un autre système, et les robots de Recherche indexent les pages comme Googlebot l’a toujours fait. Depuis le 15 septembre 2026, les nouveaux domaines qui rejoignent Cloudflare, les nouveaux sites ajoutés par des clients déjà présents, et les comptes gratuits non reconfigurés bloquent tous par défaut les robots Entraînement et Agent. Ce blocage ne s’applique qu’aux pages qui affichent de la publicité. Les robots de Recherche continuent de parcourir ces mêmes pages sans aucun changement, et les clients payants déjà en place ne sont pas affectés rétroactivement, sauf s’ils choisissent eux-mêmes cette option.
Cloudflare justifie ainsi ce périmètre limité à la publicité : une publicité signale que le propriétaire du site voulait qu’une personne y arrive et la voie, quelque chose que l’activité peut réellement monétiser. Les robots polyvalents qui mélangent Recherche et Entraînement, Googlebot et Bing en tête, restent bloqués pour leur activité d’Entraînement sur ces pages si le propriétaire du site a choisi de bloquer l’Entraînement, même si ce même robot continue d’indexer normalement pour la Recherche.
Que montrent vraiment les données WordPress de Kinsta ?
La réponse de Kinsta est arrivée une semaine plus tard, appuyée sur les données de Kinsta : une analyse de plus de 5 000 sites WordPress, complétée par une étude plus large de plus de 10 milliards de requêtes sur sa propre infrastructure. Kinsta rapporte que les robots IA ne représentaient que 1,57 % de la bande passante sur le site médian, contre 17,8 % au 90ᵉ centile et 90,3 % au 99ᵉ centile. Cet écart est tout l’intérêt du premier constat de Kinsta. Un pourcentage global de bande passante ne dit presque rien sur l’état réel de votre propre site, car les sites les plus touchés ne ressemblent en rien au site médian.
Les données de Kinsta deviennent plus précises dès qu’on regarde où ces requêtes atterrissent vraiment. L’entreprise rapporte qu’entre 76,9 % et 90,5 % des requêtes de robots IA visaient du contenu dynamique non mis en cache, contre 18,3 % à 18,9 % pour le trafic humain sur les mêmes sites. Sur une boutique WooCommerce, Kinsta rapporte qu’un seul robot a généré 3,75 millions de requêtes vers des URL d’ajout au panier en 24 heures, des pages qui ne peuvent pas être servies depuis un cache statique et qui sollicitent la base de données à chaque chargement. Ce sont les chiffres propres de Kinsta, tirés de sa propre infrastructure, pas des données reproduites de façon indépendante.
Pourquoi traiter tous les robots IA pareil se retourne contre vous ?
La liste des erreurs de Kinsta place celle-ci en premier, et ce n’est pas un hasard : traiter chaque robot IA comme la même menace. OpenAI fait tourner deux robots distincts pour deux tâches différentes. GPTBot collecte du contenu qui pourra entraîner un modèle, tandis qu’OAI-SearchBot indexe les pages pour qu’elles apparaissent dans la recherche ChatGPT. Une règle qui bloque « les robots IA » comme un seul bloc bloque les deux à la fois : le robot qui ne vous enverra probablement jamais un lecteur, et celui qui pourrait le faire. Cloudflare a construit la même distinction dans ses propres réglages par défaut, pour cette raison précise : les robots Entraînement et Agent sont bloqués par défaut sur les pages publicitaires, pas les robots de Recherche.
La propre enquête consommateurs de Kinsta, pas une étude externe, a trouvé que 44,7 % des personnes interrogées disent visiter le plus souvent le site d’une entreprise après avoir reçu une recommandation IA. Ce chiffre n’engage que Kinsta, puisqu’il n’a pas été confirmé de façon indépendante, mais la tendance qu’il indique compte : la Recherche est justement la catégorie d’où vient ce genre de trafic de recommandation. Un pic soudain de requêtes de robots n’est pas non plus automatiquement un incident de sécurité. La propre analyse de Kinsta sur ces pics a trouvé que les vraies attaques, tentatives de force brute et de bourrage d’identifiants comprises, se lisent différemment dans les journaux d’une simple vague de requêtes GET vers des pages publiques.
Le fichier robots.txt arrête-t-il vraiment quelque chose ?
robots.txt est une demande, pas un verrou. Kinsta le dit sans détour : le fichier dépend d’un robot qui choisit de respecter l’instruction, pas d’un mécanisme qui empêche physiquement la requête d’atteindre votre serveur. L’application réelle se fait au niveau du serveur, ou au niveau du réseau de périphérie placé devant lui, là où une règle peut examiner une requête et refuser de la servir. C’est cette couche que Cloudflare fait fonctionner avec ses nouveaux réglages par défaut. C’est aussi cette couche où Kinsta, sur sa propre infrastructure, a construit la règle qui a filtré 550 millions de requêtes en 30 jours.
Le conseil de Kinsta va dans le même sens : vérifiez à nouveau vos journaux ou votre outil d’analyse de robots après avoir modifié robots.txt. Si les requêtes d’un robot baissent, le changement a fonctionné. Sinon, il vous faut un vrai mécanisme d’application, pas une ligne de plus dans un fichier texte. wp-premiums a déjà traité un problème de cache qui vaut la peine d’être rappelé ici : le réglage LiteSpeed Cache que les utilisateurs de Complianz devaient vérifier relève de la même famille de problème, une règle qui interagit avec votre cache d’une façon que le tableau de bord ne vous montre jamais directement. Quel que soit le contrôle que vous ajoutez pour les robots IA, revérifiez vos journaux le lendemain avant de supposer qu’il a fonctionné.
Que devez-vous vérifier concrètement sur votre site ?
LE correctif ici n’est pas un fichier robots.txt plus long. C’est regarder vos propres chiffres avant d’écrire la moindre nouvelle règle.
- Vérifiez vos propres journaux avant de réagir à un pourcentage global. L’écart entre médiane et 99ᵉ centile chez Kinsta signifie qu’une statistique sectorielle peut décrire un site qui ne ressemble en rien au vôtre.
- Regardez quelles URL les robots visent, pas seulement combien de requêtes ils envoient. Les points d’accès dynamiques non mis en cache, pages panier et résultats de recherche compris, coûtent une vraie charge serveur selon les données de Kinsta. Un simple article de blog n’en coûte presque aucune.
- Séparez Entraînement, Agent et Recherche avant de bloquer quoi que ce soit, les trois mêmes catégories que Cloudflare laisse désormais chaque client configurer individuellement.
- Vérifiez si votre hébergeur ou votre CDN a déjà basculé un réglage par défaut sans vous le dire. Cloudflare n’a changé le défaut que pour les nouveaux domaines et les comptes gratuits non reconfigurés, mais cela couvre plus de sites qu’on ne l’imagine.
- Revérifiez vos journaux le lendemain de toute nouvelle règle. robots.txt ne fait que demander. Vos journaux, eux, disent si quelque chose a vraiment écouté.
Notre avis
La plupart des sites WordPress n’ont pas de problème de robots IA au sens où leurs propriétaires l’imaginent. Les nouveaux réglages de Cloudflare et les données de Kinsta pointent vers la même distinction. Ce qui compte n’est pas la part globale de trafic que représentent les robots IA. Ce qui compte, c’est de savoir s’ils martèlent la poignée d’URL dynamiques que votre serveur doit vraiment calculer, les pages panier en premier lieu. Si vous utilisez WooCommerce, regardez vos points d’accès panier et paiement dans vos journaux avant de toucher à robots.txt. Si votre site tourne derrière Cloudflare, vérifiez si votre compte porte déjà les nouveaux réglages du 15 septembre, ou si vous êtes encore sur l’ancien interrupteur tout-ou-rien « bloquer les robots IA ». Et avant de connecter quoi que ce soit à un agent IA vous-même, notre guide pas à pas pour WordPress et MCP vaut le coup d’être lu d’abord, pour savoir exactement ce qu’un agent qui visite votre propre site est autorisé à faire.
Photos : Brett Sayles / Pexels.
