Cloudflare a ajouté un indicateur de refus IA à robots.txt. Google affirme qu'aucun crawler ne l'applique.

Le 24 septembre 2025, Cloudflare a ajouté trois nouvelles préférences à robots.txt, chacune un simple indicateur oui/non appelé search, ai-input et ai-train. Plus de 3,8 millions de domaines ont activé la fonctionnalité via l'outil robots.txt géré par Cloudflare au cours de sa première année. Dix mois après son lancement, Google a rendu son verdict sur ce que ces indicateurs font réellement. Dans une réponse sur Reddit rapportée en juillet 2026, John Mueller, de Google, a déclaré que la directive n'a aucun effet sur aucun crawler ni aucun grand modèle de langage qu'il connaisse, et qu'elle ajoute surtout du poids inutile à un fichier robots.txt. Pour une entreprise qui venait d'annoncer à des millions de propriétaires de sites qu'ils avaient enfin leur mot à dire sur l'accès IA, c'est un bilan gênant.

Ce que la Content Signals Policy contrôle réellement

La Content Signals Policy est une préférence, pas un blocage technique. Elle permet à un site de déclarer trois réglages sur une ligne Content-Signal dans robots.txt : search, qui signifie qu'un crawler peut indexer la page et afficher un extrait ; ai-input, qui signifie qu'un modèle d'IA peut puiser dans la page pour répondre à une question en direct ; et ai-train, qui signifie que le contenu peut servir à entraîner ou affiner un modèle.

Cloudflare publie le texte de la politique elle-même sous licence CC0, et tout site utilisant son robots.txt géré reçoit désormais search=yes, ai-train=no par défaut, sans position fixée sur ai-input, car Cloudflare dit ne pas connaître la préférence de chaque client sur ce point précis. L'entreprise a construit cette fonctionnalité après ce que son annonce décrit comme des centaines de conversations avec des éditeurs qui voulaient une option entre tout laisser prendre à un crawler et le bloquer purement et simplement. Un site peut déjà écrire une règle qui nomme directement un crawler, par exemple User-agent : GPTBot ou User-agent : PerplexityBot, mais Content Signals a été conçue pour fonctionner avec tous les moteurs à la fois, sans nommer une seule entreprise. C'est aussi exactement pour cela que rien ne les oblige à la lire. Notre guide sur ce que robots.txt bloque réellement quand les crawlers IA visitent un site détaille comment ces règles plus anciennes, propres à chaque bot, se comportent une fois qu'un crawler se présente.

Pourquoi Google dit que rien de tout cela n'a d'importance

Google n'a rien construit qui lise la ligne Content-Signal, et d'après l'un de ses propres ingénieurs, personne d'autre digne d'attention ne l'a fait non plus. John Mueller, de Google, a répondu dans un fil Reddit que la directive, qu'il a décrite simplement comme quelque chose qu'un CDN avait inventé, n'a aucun effet sur aucun crawler ni aucun LLM qu'il connaisse.

Cela n'a absolument aucun effet pour aucun crawler ni aucun LLM. Cela ne fait qu'ajouter du poids et de la maintenance future à votre fichier robots.txt.

C'est John Mueller, de Google, qui répond ainsi sur Reddit en juillet 2026, en nuançant son propos par « à ma connaissance », ce qui laisse la porte ouverte à un crawler quelconque qui la respecterait discrètement malgré tout. Mais le message pratique adressé aux propriétaires de sites était sans détour : régler ai-train=no n'arrête pas Googlebot, et cela n'arrête presque certainement personne d'autre non plus, à moins que cette entreprise n'ait choisi séparément et publiquement de la respecter. C'est une déception d'un genre familier. Notre analyse sur pourquoi le noindex ne bloque pas les crawlers IA a relevé le même écart avec une balise plus ancienne et plus établie : le noindex empêche de façon fiable une page de figurer dans l'index de recherche de Google, car Google a construit son pipeline d'indexation pour la respecter, mais aucun crawler IA n'est contractuellement tenu de traiter un signal spécifique à l'IA de la même manière, et beaucoup ne le font pas.

Une entreprise a scindé son crawler plutôt que d'ignorer la question

Toutes les entreprises d'IA ne considèrent pas les permissions granulaires comme inutiles. Anthropic a séparé son crawler web en trois bots distincts en février 2026, chacun avec sa propre chaîne user-agent et son propre comportement documenté, ce qui se rapproche davantage de ce que Content Signals cherchait à offrir que ce que le rejet de Google ne laisse penser que l'industrie souhaite.

ClaudeBot continue de collecter des pages pour l'entraînement des modèles. Claude-User ne récupère une page qu'au moment où un utilisateur de Claude, en direct, pose une question à son sujet. Claude-SearchBot indexe le contenu pour les propres résultats de recherche de Claude, et la documentation d'assistance d'Anthropic prévient que bloquer spécifiquement Claude-SearchBot peut réduire la visibilité et la précision d'un site dans ces résultats. Bloquer le crawler d'entraînement ne touche pas les deux autres. C'est une version concrète du choix que Content Signals tentait d'offrir, mais construite avec trois user agents nommés et vérifiables indépendamment, plutôt qu'une seule ligne de préférence que rien n'oblige à consulter. C'est aussi le genre de distinction qui compte vraiment pour une marque qui cherche à apparaître dans les réponses de Claude sans voir chacune de ses pages aspirée pour l'entraînement, un compromis que nous détaillons dans bloquer l'entraînement de l'IA peut aussi bloquer silencieusement vos citations IA.

Le prochain mouvement de Cloudflare : bloquer les crawlers aux usages mixtes

Cloudflare n'a pas attendu que les entreprises d'IA adoptent Content Signals volontairement. À partir du 15 septembre 2026, ses réglages par défaut ont commencé à bloquer ce qu'elle appelle les crawlers à usages mixtes, des bots qui combinent indexation pour la recherche, accès d'agent IA en direct et entraînement de modèle dans un seul user agent, sur toute page qui affiche des publicités.

Le changement s'applique par défaut aux nouveaux clients de Cloudflare, aux nouveaux sites ajoutés par des clients existants, et à tous les sites encore sur l'offre gratuite de Cloudflare, bien que chaque propriétaire de site puisse le désactiver. L'exemple nommé par Cloudflare est Googlebot, qui explore une seule fois à la fois pour la Recherche, les AI Overviews et le AI Mode, et l'entreprise affirme que Google obtient ainsi environ deux fois l'accès de n'importe quel concurrent IA pris isolément, une comparaison que Google conteste en pointant vers Google-Extended comme véritable option de retrait pour l'entraînement et certains produits IA, sans perdre l'inclusion dans la Recherche. Cloudflare affirme aussi que plus de la moitié du trafic des crawlers IA récupère à nouveau des pages qui n'ont pas changé depuis la dernière visite, ce qu'elle présente comme de la bande passante gaspillée pour les éditeurs plutôt qu'une réelle demande de contenu frais, selon les informations de TechCrunch sur ce changement. L'ancien outil Pay Per Crawl de Cloudflare, qui utilise un code de statut HTTP 402 pour facturer les crawlers à la requête, évolue vers un modèle qu'elle appelle Pay Per Use, qui ne rémunère les éditeurs que lorsque leur contenu apparaît réellement dans la sortie d'un produit IA ; Ceramic.ai et You.com sont les deux premiers partenaires. Nous avons déjà couvert les réglages de Cloudflare pour les crawlers IA, notamment comment vérifier si Cloudflare bloque déjà vos crawlers IA sans que vous le sachiez.

Ce que cela signifie si vous suivez votre visibilité IA

Rien de tout cela ne change ce qui fait réellement citer une marque. Cela change qui peut atteindre un site, et c'est la couche sous-jacente à chaque chiffre d'AI Share of Voice qu'une entreprise suit. Un indicateur dans robots.txt que rien ne lit n'est pas une stratégie de visibilité ; c'est une note que personne n'ouvre.

Le signal le plus fiable reste l'observation directe. Vérifier dans les logs serveur quels user agents se présentent réellement, et à quelle fréquence ils récupèrent à nouveau des pages qui n'ont pas changé, en apprend bien plus à une marque qu'aucune ligne de préférence, une méthode que nous détaillons dans notre guide du ratio exploration/référencement. La même logique s'applique à llms.txt, un fichier séparé que certains sites publient pour indiquer quelles pages un modèle d'IA devrait privilégier : comme Content Signals, cela ne fonctionne que pour les moteurs qui ont choisi de le lire, ce qui reste une liste courte, comme nous l'expliquons dans notre guide complet de llms.txt. La séparation en trois crawlers d'Anthropic reste le seul exemple public d'une grande entreprise d'IA intégrant ce type de contrôle granulaire et vérifiable directement dans sa propre infrastructure, plutôt que de demander aux propriétaires de sites de faire confiance à un fichier de préférences.