Il y a un an, beaucoup de sites ont cherché à bloquer les bots des IA Géneratives. Parce que cela consomme de la bande passante, ou pour éviter de se faire « voler » son contenu. Ou par défiance. Ou par principe.
Le problème, c’est que beaucoup ne souviennent plus ce qu’ils ont bloqué : les bots collectant les données d’entrainement ? Les bots de grounding ? Les bots des fonctionnalités IA des moteurs ?
Votre site passe par Cloudflare (c’est fréquent, ils gèrent 20% du web) ? Ils ont pris une décision pour vous.
Le 15 septembre 2026, si vous faites partie des éditeurs qui bloquent les bots d’entraînement des modèles IA, Cloudflare bloquera aussi par défaut Googlebot, Applebot et BingBot.
C’est radical, et ceux qui n’auront pas vue l’annonce auront une mauvaise surprise côté SEO. Car un Googlebot bloqué, cela signifie des pages sites qui ne sont plus crawlés, donc plus de contenu à terme et donc plus de trafic SEO du tout !
Décryptons cette annonce ébouriffante de Cloudflare, et voyons le mode d’emploi à suivre pour ne pas être impacté à l’insu de votre plein gré!
Trois comportements plutôt qu’une case à cocher
Le deuxième Content Independence Day de Cloudflare, célébré le 1er juillet 2026, abandonne le bouton unique « bloquer les bots IA » au profit d’une taxonomie comportementale.
Un crawler, ce robot logiciel qui parcourt les pages pour en collecter le contenu, n’est plus jugé sur son étiquette « IA ou pas », mais sur ce qu’il fait réellement du site. Cloudflare distingue désormais trois usages que tout client peut gérer séparément, y compris sur l’offre gratuite.
- Le premier, Search (recherche), regroupe les robots qui indexent le contenu pour répondre plus tard à des requêtes, avec en principe du trafic de retour à la clé.
- Le deuxième, Agent, désigne les robots agissant en temps réel pour un humain, comme ChatGPT-User ou un agent de navigation piloté par Gemini ou Claude dans Chrome.
- Le troisième, Training (entraînement), vise les robots qui aspirent le contenu pour entraîner ou affiner un modèle, le texte étant alors absorbé dans l’architecture même de l’IA.
Ces trois réglages sont actifs immédiatement dans les paramètres de sécurité de chaque site. La logique affichée par Cloudflare est la transparence : un opérateur qui indexe, agit et entraîne à la fois devrait, selon l’entreprise, séparer ses robots en trois pour que l’éditeur sache pourquoi on le visite.
Problème : Google ne veut pas faire cela du tout !
D’où le bras de fer qui s’annonce entre la firme de Mountain View et Cloudlare
Le piège du 15 septembre
À partir du 15 septembre 2026, Cloudflare appliquera aux crawlers multi-usages (dont Googlebot), ceux qui mélangent recherche et entraînement dans un seul robot, la règle la plus restrictive de tous leurs comportements. La conséquence est directe : un site qui bloque l’entraînement bloquera aussi les robots qui font recherche et entraînement en même temps.
Cloudflare nomme explicitement les trois concernés : Googlebot, Applebot et BingBot. Le point sensible tient à l’historique. L’ancienne option « Block AI bots », activée par plus d’un million de sites selon Cloudflare, sera elle aussi soumise à cette règle. Un éditeur qui a coché cette case il y a un an pour repousser l’entraînement se retrouvera donc, sans nouvelle action de sa part, à bloquer Googlebot le 15 septembre.
Or bloquer Googlebot, c’est disparaître de la recherche Google, et pas seulement de ses fonctions IA.
Le raisonnement de Cloudflare est assumé : forcer les grands moteurs à séparer structurellement leurs robots. L’entreprise estime que le plus gros moteur de recherche accède à environ deux fois plus d’informations que les autres acteurs de l’IA, précisément parce qu’il utilise un robot mixte.
Reste que la pression s’exerce d’abord sur les éditeurs pris entre visibilité et protection, pas sur Google. L’initiative de Cloudflare peut se retourner contre eux !
Qui est concerné, et comment refuser le nouveau paramétrage par défaut
La précision compte, car beaucoup de reprises la brouillent.
Le nouveau réglage par défaut, à savoir bloquer Entraînement et Agent sur les pages affichant de la publicité tout en laissant passer Search, s’applique aux nouveaux domaines rejoignant Cloudflare, aux nouveaux sites créés par des clients existants, et aux clients de l’offre gratuite qui n’auront rien changé. Il ne s’agit pas d’une bascule imposée rétroactivement à toutes les zones payantes déjà en place.
En revanche, la règle du comportement le plus restrictif, celle qui rattrape Googlebot, concerne tout site ayant choisi de bloquer l’entraînement, que ce soit via les nouvelles options ou via l’ancienne case « Block AI bots ». C’est cette population, potentiellement large, qui doit vérifier ses réglages.
La marche à suivre pour conserver la situation actuelle est simple.
Cloudflare permet de faire un opt-out, c’est-à-dire de refuser explicitement ce nouveau paramétrage par défaut, dans les paramètres de sécurité de la zone, à tout moment avant le 15 septembre.
Ce choix confirme qu’aucun changement ne s’appliquera aux robots d’entraînement qui explorent aussi pour la recherche. Concrètement, un éditeur qui veut continuer d’apparaître dans Google doit définir ce paramètre avant l’échéance.
Cloudflare indique qu’il notifiera les clients à l’approche de la date, mais mieux vaut ne pas attendre le rappel.
La question Googlebot : une accusation que Google conteste
Présenter Googlebot comme un robot « recherche plus entraînement » est la lecture de Cloudflare, et Google la récuse de longue date. Le moteur rappelle qu’il propose Google-Extended, une directive à placer dans le fichier robots.txt, ce fichier texte par lequel un site indique aux robots ce qu’ils peuvent explorer.
Google-Extended permet de refuser l’entraînement de Gemini sans affecter, selon Google, l’inclusion dans la recherche.
L’asymétrie pointée par Cloudflare reste néanmoins réelle sur un point précis. Refuser Google-Extended n’empêche pas le contenu d’apparaître dans les AI Overviews, ces résumés générés en tête de résultats, car ceux-ci puisent dans l’index de Search alimenté par Googlebot. Un éditeur ne dispose donc d’aucun levier propre pour être indexé sans nourrir les réponses génératives de Google.
Le signal use= et le statut vérifié : une préférence n’est pas un blocage
Cloudflare ajoute un autre paramètre, le content use, qui décrit ce qu’un robot a le droit de conserver et de rediffuser. Trois niveaux existent, du plus strict au plus permissif : immediate (interagir sans rien stocker), reference (indexer, citer, faire un lien, valeur par défaut) et full (résumer et reproduire). Un nouveau signal use= étend en ce sens le standard Content Signals dans le robots.txt.
Une distinction méthodologique s’impose ici.
Comme toute mention du robots.txt, ce signal exprime une préférence, pas une contrainte technique. Il indique un souhait aux robots respectueux, rien de plus. Seul le blocage opéré au niveau du réseau Cloudflare constitue une barrière effective. Confondre les deux revient à surestimer la portée du dispositif.
Cloudflare retouche aussi la notion de robot vérifié.
Auparavant, tout robot vérifié était autorisé par défaut. Désormais, le label rend le robot autorisable seulement dans sa catégorie : c’est l’usage autorisé, par exemple Search, qui décide de l’accès. Un robot qui reproduit le contenu en entier ne peut plus être vérifié. La logique consiste à faire de la confiance une ressource que l’on gagne en étant honnête sur ses intentions, et que l’on perd en trichant.
Google a toutefois envoyé dernièrement une pierre dans le jardin de Cloudflare en précisant que ces directives ne sont utilisées par personne à part Cloudflare (ni les LLMs, ni les moteurs).
Quelques points à préciser :
John Mueller, Reddit, https://www.reddit.com/r/TechSEO/comments/1uo1rpb/testing_whether_contentsignal_headers_and_llmstxt/
- Google n’utilise pas les fichiers llms.txt ni llms-author.txt. À ma connaissance, aucun autre robot d’exploration ou LLM ne confirme leur utilisation (à l’exception des outils SEO).
- À ma connaissance, aucun robot d’exploration ou LLM n’utilise la directive « content-signal » dans le fichier robots.txt. Cette directive a été créée par un CDN et, à ma connaissance, elle est totalement inefficace pour les robots d’exploration ou les LLM. Son utilisation ne fait qu’alourdir le fichier robots.txt et engendrer des coûts de maintenance supplémentaires. Vous pouvez également ajouter d’autres éléments à votre fichier robots.txt ; les robots d’exploration se contentent d’utiliser les directives « content-signal ».…
Ouch !
Un arbitre privé qui vend aussi les outils
Reste une question de fond, moins commentée. En fixant des réglages par défaut sur près de 20 pour cent du web, un acteur privé oriente de fait les usages de tout l’écosystème. Le blocage n’est d’ailleurs qu’un versant du dispositif. Le même jour, Cloudflare a fait évoluer Pay Per Crawl en Pay Per Use, qui rémunère l’éditeur quand son contenu crée de la valeur et non plus seulement quand il est exploré, avec deux partenaires initiaux, Ceramic.ai et You.com. S’y ajoute la Monetization Gateway, une infrastructure de facturation reposant sur le protocole ouvert x402 et réglée en stablecoins, ces cryptomonnaies indexées sur une devise.
Il faut donc lire les chiffres avancés en gardant à l’esprit qu’ils émanent d’une partie intéressée, qui vend les outils qu’elle promeut. Selon la cellule Radar de Cloudflare, 52 pour cent des requêtes de crawl seraient liées à l’entraînement en juin 2026, contre 22 pour cent au printemps 2025, et les crawlers mixtes pèseraient plus de 36 pour cent de l’activité. Ces mesures, comme les ratios crawl sur trafic renvoyé cités pour 2025, servent un argumentaire commercial autant qu’un constat. Elles restent utiles, à condition d’être attribuées et prises pour ce qu’elles sont : les données d’un acteur qui a intérêt à ce qu’on bloque.
Pour aller plus loin
- Cloudflare, Your site, your rules: new AI traffic options for all customers, source primaire de l’annonce et des réglages.
- Cloudflare, Content Independence Day, one year on: building the business model for the agentic Internet, rapport Radar et chiffres de crawl.
- Matt G. Southern, Cloudflare’s AI Crawler Rules Can Block Googlebot, Search Engine Journal.
- Sarah Perez, Cloudflare’s new policy pushes AI companies to pay for publishers’ content, TechCrunch.
- The Register, Cloudflare to block cynical search-and-scrape bots from ad-supported web pages.
- Content Signals, spécification du standard étendu par le signal
use=. - IETF, RFC 7239 : Forwarded HTTP Extension, base technique de la confiance transitive proposée par Cloudflare.