Bloquer les crawlers IA sur Cloudflare sans bloquer Googlebot

GPTBot, ClaudeBot, PerplexityBot, Bytespider et une dizaine d'autres lisent votre site tous les jours. Certains vous renvoient des visiteurs, d'autres absorbent votre contenu dans un modèle, d'autres encore agissent en temps réel pour un humain. Ce guide sépare les trois cas, donne l'inventaire à jour des user agents avec leurs sources, et détaille la configuration Cloudflare qui arrête ce que vous avez choisi d'arrêter sans jamais toucher aux robots d'indexation vérifiés.

Dernière vérification le 12 septembre 2026. Le sujet bouge vite : Cloudflare a changé sa taxonomie de bots le 1er juillet 2026 et modifie les réglages par défaut des domaines nouvellement raccordés le 15 septembre 2026. Confrontez donc ce qui suit aux valeurs réelles de votre dashboard plutôt que de les supposer.

Trois types de robot, trois décisions différentes

L'erreur la plus coûteuse sur ce sujet consiste à traiter « bot » comme une catégorie unique. Une requête de Googlebot, une requête de GPTBot et une requête de ChatGPT-User n'ont presque rien en commun au-delà d'être automatisées, et les bloquer toutes les trois avec une seule règle est précisément la façon dont un site perd son trafic de recherche tout en continuant à se faire aspirer.

Robots d'indexation. Googlebot, Bingbot, Applebot, DuckDuckBot. Ils lisent vos pages pour construire un index de recherche, et l'échange est explicite : ils consomment de la bande passante, vous êtes référencé et vous recevez des clics. Les bloquer vous coûte du trafic, et rien d'autre ne change.
Crawlers d'entraînement IA. GPTBot, ClaudeBot, CCBot, Bytespider, Amazonbot, meta-externalagent. Ils lisent vos pages pour que le contenu soit absorbé dans les poids d'un modèle. Aucun renvoi, aucune citation, aucun lien retour, ni maintenant ni plus tard. C'est cette catégorie que visent réellement la plupart des propriétaires de site quand ils disent « bloquer les crawlers IA ».
Robots de recherche et de réponse IA. OAI-SearchBot, PerplexityBot, Claude-SearchBot, meta-webindexer. Ils indexent votre contenu pour qu'un moteur de réponse puisse le citer et le lier. Économiquement, ils sont bien plus proches de Googlebot que de GPTBot, ce qui fait de leur blocage une décision commerciale et non une mesure d'hygiène.
Agents IA en temps réel. ChatGPT-User, Claude-User, Perplexity-User, meta-externalfetcher, Amzn-User. Un humain a posé une question à un assistant, et l'assistant est allé chercher une page pour y répondre. Le volume est faible, l'intention est humaine, et plusieurs opérateurs indiquent explicitement que robots.txt ne s'applique pas à ces récupérations, justement parce qu'une personne les a demandées.

Cloudflare a formalisé la même distinction le 1er juillet 2026. Les bots sont désormais classés par comportement plutôt que par une étiquette unique « bot IA », et trois de ces comportements sont exposés à tous les clients sous forme de préréglages : Search (collecte ou indexe votre contenu pour pouvoir répondre à des questions le concernant plus tard), Agent (activité automatisée agissant en temps réel pour le compte d'une personne) et Training (explore votre contenu pour entraîner ou affiner un modèle). Cloudflare suit d'autres comportements en parallèle, dont Transact, Data Collection, Security Testing, SEO, Ads Verification, Social et Link Preview, Feed Fetching, et Monitoring and Operations.

Avant de toucher la moindre règle, écrivez une ligne par catégorie : autoriser, bloquer, ou plafonner. Tout ce qui suit n'est que la mécanique d'application de cette phrase.

L'inventaire à jour : qui opère quoi

La liste ci-dessous provient de la documentation de chaque opérateur, vérifiée le 12 septembre 2026. Les noms sont sensibles à la casse et doivent être reproduits exactement : une faute de frappe dans un token de robots.txt ne fait rien du tout, silencieusement.

OpenAI

GPTBot : explore le contenu susceptible d'être utilisé pour entraîner les modèles de fondation génératifs d'OpenAI. Respecte robots.txt.
OAI-SearchBot : fait remonter des sites dans les fonctions de recherche de ChatGPT. Non utilisé pour l'entraînement. Respecte robots.txt. OpenAI documente explicitement la possibilité d'autoriser celui-ci tout en refusant GPTBot.
ChatGPT-User : récupère une page parce qu'un utilisateur ou une action de GPT personnalisé l'a demandé. Non utilisé pour l'entraînement. Comme la requête est initiée par un utilisateur, OpenAI indique que les règles de robots.txt peuvent ne pas s'appliquer.
OAI-AdsBot : contrôle les pages de destination publicitaires.

Anthropic

ClaudeBot : collecte du contenu web pouvant contribuer à l'entraînement. Respecte robots.txt.
Claude-SearchBot : explore le web pour améliorer la qualité des résultats de recherche dans Claude.
Claude-User : récupère une page quand une personne pose une question à Claude.

Anthropic publie les plages d'IP sources de ses robots sur https://claude.com/crawling/bots.json, ce qui permet de vérifier une requête plutôt que de faire confiance à son en-tête.

Perplexity

PerplexityBot : indexe les pages pour qu'elles apparaissent et soient liées dans les résultats Perplexity. Documenté comme servant à l'indexation uniquement, pas à l'entraînement.
Perplexity-User : visite une page pour répondre à une question précise, et selon la documentation de Perplexity ignore généralement robots.txt puisqu'un humain a demandé la récupération.

C'est aussi le cas le mieux documenté de contournement des préférences d'un site. En août 2025, Cloudflare a publié une enquête montrant un crawler Perplexity non déclaré se présentant comme Chrome sur macOS, changeant d'IP et d'ASN en dehors des plages publiées après le blocage de l'agent déclaré, et récupérant des pages sur des domaines de test dont le robots.txt interdisait tout. Cloudflare a retiré Perplexity de sa liste de bots vérifiés et a ajouté des signatures de détection pour tous ses clients, offre Free comprise. Une chaîne de user agent est une déclaration, jamais une preuve.

Google

Google-Extended : un token de robots.txt, pas un robot. Google précise qu'il n'a pas de chaîne de user agent HTTP distincte et que le crawl est réalisé avec les user agents Google existants. Il gouverne l'utilisation de votre contenu pour entraîner les futurs modèles Gemini et pour le grounding dans les applications Gemini et l'API Vertex AI pour Gemini.

La conséquence mérite d'être écrite noir sur blanc, car c'est l'erreur de configuration la plus fréquente sur le sujet : une règle Edge portant sur http.user_agent contains "Google-Extended" ne correspond à rien, jamais. Aucune requête ne transporte cette chaîne. Le seul endroit où ce token produit un effet est robots.txt.

Apple

Applebot : le robot qui alimente Siri, Spotlight et les fonctions de recherche d'Apple.
Applebot-Extended : là encore un token de robots.txt, pas un robot. Apple indique qu'il n'explore aucune page et sert uniquement à déterminer comment utiliser les données déjà collectées par Applebot, et que les pages qui le refusent peuvent toujours apparaître dans les résultats de recherche.

Common Crawl

CCBot : opéré par la fondation à but non lucratif Common Crawl, s'identifiant par CCBot/2.0 (https://commoncrawl.org/faq/). Respecte robots.txt et publie ses plages d'IP sur https://index.commoncrawl.org/ccbot.json.

Common Crawl est une archive ouverte plutôt qu'une entreprise d'IA, mais son corpus est l'un des jeux de données d'entraînement les plus réutilisés au monde, ce qui explique sa présence dans presque toutes les listes de blocage IA, y compris le robots.txt géré de Cloudflare.

ByteDance

Bytespider : opéré par ByteDance, envoie un user agent de Safari mobile auquel est ajouté compatible; Bytespider; [email protected].

ByteDance ne publie aucune documentation de crawler, aucune liste d'IP et aucune position sur robots.txt, et des analyses de journaux serveur indépendantes rapportent régulièrement que Bytespider télécharge robots.txt puis demande malgré tout des chemins interdits. Sa conformité doit être considérée comme non vérifiée, ce qui laisse le blocage au niveau Edge comme seul contrôle fiable.

Amazon

Amazonbot : Amazon indique que les données peuvent servir à entraîner ses modèles d'IA. Respecte robots.txt, rel="nofollow" et les balises meta robots.
Amzn-SearchBot et Amzn-User : Amazon indique que ces deux agents n'explorent pas le contenu pour l'entraînement de modèles génératifs. Le premier rend le contenu éligible à des expériences de recherche comme Alexa, le second sert les actions utilisateur nécessitant une information à jour.

Pourquoi robots.txt ne suffit pas, et pourquoi il faut quand même l'écrire

La documentation de Cloudflare le dit sans détour : la conformité à robots.txt est volontaire, le fichier exprime vos préférences, et il n'empêche techniquement aucun crawler d'accéder à votre contenu. Trois modes de défaillance distincts en découlent.

C'est déclaratif. Il n'existe aucune étape d'application. Un crawler lit le fichier, décide, et poursuit. Rien dans l'échange HTTP ne rend un Disallow contraignant.
Certains opérateurs l'ignorent. L'enquête sur Perplexity ci-dessus en est le cas documenté ; les signalements récurrents sur Bytespider en sont le cas largement observé. AI Crawl Control dispose désormais d'un tableau dédié comptant les violations de robots.txt par crawler, précisément parce que le problème est assez répandu pour mériter un rapport.
Les agents initiés par un utilisateur en sont exclus volontairement. OpenAI indique que les règles de robots.txt peuvent ne pas s'appliquer à ChatGPT-User ; Perplexity indique que Perplexity-User les ignore généralement. Ce n'est pas une esquive, c'est une position assumée : un humain a demandé la page, donc l'opérateur traite la récupération comme une visite humaine.

Un quatrième échec, plus discret, est l'usurpation. N'importe quel client HTTP peut envoyer User-agent: GPTBot ou User-agent: Googlebot, et beaucoup de scrapers envoient le second justement parce que des sites le mettent en liste d'autorisation. C'est ce qui rend une règle fondée sur le seul user agent dangereuse dans les deux sens : elle rate le trafic qu'elle visait, et elle peut servir à franchir une liste d'autorisation.

Écrivez le fichier malgré tout. Cela ne coûte rien, les opérateurs respectueux s'arrêtent réellement, et c'est le seul endroit où Google-Extended et Applebot-Extended produisent un effet. Le fichier a en outre une portée juridique depuis l'apparition du Content Signals Policy : le texte que Cloudflare y ajoute précise que toute restriction exprimée par un content signal constitue une réservation expresse de droits au titre de l'article 4 de la directive (UE) 2019/790 sur le droit d'auteur dans le marché unique numérique.

Les Content Signals ajoutent trois préférences lisibles par une machine, sur une seule ligne du type Content-signal: search=yes, ai-train=no :

search : construire un index de recherche et renvoyer des liens et de courts extraits. Exclut explicitement les résumés générés par IA.
ai-input : injecter votre contenu dans un modèle au moment de la réponse, ce qui couvre la génération augmentée par récupération et le grounding.
ai-train : entraîner ou affiner des modèles.

Un signal à yes accorde cet usage, no le refuse, et un signal omis n'accorde ni ne restreint rien. Le texte complet de la politique est publié sur contentsignals.org.

Ce que Cloudflare applique réellement, et ce que cela coûte

Cloudflare propose désormais plusieurs fonctions qui se recouvrent sur ce sujet. Elles ne font pas le même travail et leur disponibilité tarifaire diffère : autant être précis.

Politiques de bots IA : l'interrupteur d'application, sur toutes les offres

Dans Security Settings > Configure AI bot policies, chacun des trois comportements (Search, Agent, Training) prend l'une de ces trois actions :

Block (on all pages) : blocage sur toute la zone.
Block on pages with ads : s'appuie sur la détection automatique par Cloudflare des pages affichant de la publicité, et ne bloque que sur celles-ci.
Allow (do not block) : aucun blocage.

Chaque réglage bloque les bots vérifiés classés dans ce comportement, plus des bots non vérifiés relevant de la même classification. C'est disponible pour tous les clients, offre Free comprise, et c'est la partie du dispositif qui survit au renommage d'un crawler, puisqu'elle s'appuie sur la classification Cloudflare et non sur la chaîne présente dans l'en-tête.

Deux dates comptent. L'ancien réglage en un clic Block AI bots est en dépréciation le 15 septembre 2026 ; il bloquait les bots vérifiés classés comme explorant à des fins d'entraînement IA, plus des bots non vérifiés au comportement similaire, et excluait les bots à usage mixte utilisés à la fois pour Training et Search. À la même date, Cloudflare applique de nouveaux réglages par défaut aux domaines nouvellement raccordés : Training et Agent bloqués sur les pages qui affichent de la publicité, Search autorisé. Les crawlers à usage mixte combinant Search et Training sont bloqués par toute configuration bloquant l'entraînement, y compris l'ancienne option. Les clients pouvaient se désinscrire de ces nouveaux réglages avant cette date.

AI Crawl Control : l'observation, également sur toutes les offres

AI Crawl Control (anciennement AI Audit) est disponible sur toutes les offres et fonctionne sans configuration. Son onglet Crawlers liste chaque crawler IA vu sur votre zone avec son opérateur, sa catégorie, le nombre de requêtes réussies et échouées avec une courbe de tendance, le nombre de violations de robots.txt, et une action Allow ou Block par crawler avec une réponse de blocage configurable. Son onglet Directives suit l'accessibilité de votre robots.txt et son code de réponse, la présence de Content Signals, et la liste des crawlers ayant demandé des chemins que votre fichier interdit, avec la ligne de directive fautive affichée en regard de chaque violation.

Une réserve honnête sur le coût : sur l'offre Free, AI Crawl Control identifie les crawlers à partir de leur seule chaîne de user agent, ce qui détecte les crawlers connus qui s'identifient et rien d'autre. Les offres payantes ajoutent les signaux de détection propres à Cloudflare pour une identification plus fiable. Le pay per crawl, qui permet de facturer l'accès aux crawlers au lieu de les bloquer, est en bêta fermée et n'est pas disponible pour tous.

robots.txt géré : la couche déclarative, générée pour vous

Activer le réglage de robots.txt géré fait générer et maintenir le fichier par Cloudflare, qui insère son bloc géré avant votre propre fichier si vous en servez déjà un. Le bloc géré pose Content-signal: search=yes, ai-train=no, use=reference pour tous les agents, puis ajoute Disallow: / pour Amazonbot, Applebot-Extended, Bytespider, CCBot, ClaudeBot, Google-Extended, GPTBot et meta-externalagent. La documentation Cloudflare est explicite : cela exprime des préférences, l'application effective relève d'AI Crawl Control, et les deux sont faits pour être utilisés ensemble.

Règles de sécurité personnalisées : la partie que vous maîtrisez au détail

Dans Security > WAF > Custom rules, le champ qui compte est cf.client.bot. C'est un booléen, disponible sur toutes les offres, porteur de la même information que cf.bot_management.verified_bot, et vrai quand Cloudflare a confirmé l'identité du client. Cloudflare vérifie par validation de reverse DNS, listes d'IP publiées, blocs d'ASN et, de plus en plus, signatures cryptographiques. Comme la vérification repose sur des preuves que le client ne peut pas falsifier, un User-agent: Googlebot usurpé depuis un hôte quelconque satisfera la condition de user agent et échouera sur cf.client.bot : c'est exactement la discrimination recherchée.

Une distinction qui fait trébucher : vérifié signifie identifié, pas bienvenu. Googlebot est un bot vérifié. ClaudeBot aussi. OAI-SearchBot aussi. Écrire une règle qui autorise tout ce pour quoi cf.client.bot est vrai ne bloque pas les crawlers IA, cela leur ouvre la porte. cf.client.bot a sa place dans vos expressions comme condition de sécurité sur les règles de blocage, pas comme politique IA.

Deux champs plus riches existent mais relèvent de Bot Management, une option payante et non une fonction de l'offre Free : cf.verified_bot_category, une chaîne permettant de segmenter le trafic vérifié par type et par finalité, et cf.bot_management.signed_agent, un booléen vrai quand la requête provient d'un agent s'identifiant via Web Bot Auth. Sur Free et Pro, on construit avec cf.client.bot et des tokens de user agent explicites, en s'appuyant sur les préréglages de politiques IA pour le reste.

Vérification cryptographique : Web Bot Auth

Web Bot Auth est le mécanisme qui remplace « faites confiance à cette plage d'IP » par « prouvez-le ». Un crawler génère une paire de clés Ed25519, publie la clé publique sous forme de JSON Web Key Set sur /.well-known/http-message-signatures-directory en HTTPS, enregistre ce répertoire auprès de Cloudflare, puis signe chaque requête avec les HTTP Message Signatures en joignant les en-têtes Signature, Signature-Input et Signature-Agent. Cloudflare valide la signature contre la clé enregistrée.

Depuis le 1er juillet 2026, les agents signés comptent comme des bots vérifiés et Cloudflare étiquette chaque bot vérifié en Direct (opéré par un opérateur unique et restreint, sur sa propre infrastructure, de sorte que lui seul peut se présenter comme ce bot) ou Intermediary (un service agentique piloté par une multitude d'utilisateurs finaux). La distinction compte pour la politique, car un intermédiaire introduit une confiance transitive : vous pouvez faire confiance à l'opérateur sans faire confiance à chaque utilisateur final derrière lui. Cloudflare expérimente la transmission d'informations sur l'utilisateur final via l'en-tête Forwarded de la RFC 7239, afin que les propriétaires de site puissent appliquer leurs préférences à la partie réellement responsable de la requête.

En pratique, c'est ce qui rend l'approche durable. Le reverse DNS et les listes d'IP se dégradent au fil des déménagements d'infrastructure ; une signature, non. Attendez-vous à voir une part croissante du trafic agentique arriver signée, et à voir la question utile passer de « quelle chaîne figure dans l'en-tête » à « qui a signé ceci, et pour le compte de qui ».

Bloquer les crawlers IA sans casser Googlebot ni Bingbot

C'est ce que promet le titre, et cela se joue en deux temps : comprendre ce que gouvernent réellement les contrôles IA de Google, puis écrire des règles qui ne peuvent pas se retourner contre vous.

Google-Extended et Googlebot sont liés, et ce n'est pas un problème

C'est la même flotte qui fait les deux travaux. Googlebot récupère la page ; Google-Extended ne gouverne que ce que Google a ensuite le droit de faire de ce que Googlebot détient déjà. D'où l'absence de user agent distinct, et l'impossibilité d'exprimer la préférence ailleurs que dans robots.txt.

Refuser Google-Extended signifie : votre contenu n'est pas utilisé pour entraîner les futurs modèles Gemini qui alimentent les applications Gemini et l'API Vertex AI pour Gemini, et il n'est pas utilisé pour le grounding dans les applications Gemini ni pour Grounding with Google Search sur Vertex AI.

Refuser Google-Extended ne signifie pas : cela ne vous retire pas de l'index Google, ne fait pas baisser votre classement, et ne vous sort pas des AI Overviews ni d'AI Mode. Google l'écrit directement : Google-Extended n'a aucune incidence sur la présence d'un site dans Google Search et n'est pas utilisé comme signal de classement dans Google Search. Les fonctions IA sont intégrées à Search et reposent sur Googlebot, si bien que ce sont les directives robots.txt visant Googlebot qui les gouvernent.

Si votre objectif réel est de sortir des AI Overviews et d'AI Mode, les leviers sont différents : nosnippet, data-nosnippet, max-snippet et noindex, qui limitent ce que Search peut afficher de vos pages dans tous ses formats, plus le réglage de la Search Console que Google a déployé mondialement le 31 août 2026 et qui permet à un site de ne plus apparaître dans les fonctions de recherche génératives ni d'y servir de source. S'en retirer signifie aucun trafic ni impression depuis ces fonctions, et Google précise que ce réglage n'est pas utilisé comme signal de classement pour les résultats en dehors d'elles. Pesez ce choix : c'est un arbitrage réel, pas une précaution gratuite.

Bing et Apple ont leurs propres leviers

Le mécanisme de Microsoft repose sur des balises meta plutôt que sur des tokens robots.txt. Un contenu marqué NOARCHIVE n'est pas inclus dans les réponses de Bing Chat et n'est pas utilisé pour entraîner les modèles de fondation génératifs de Microsoft. Un contenu marqué NOCACHE peut apparaître dans les réponses de Bing Chat, mais seuls les URL, titres et extraits peuvent servir à l'entraînement. Les deux continuent d'apparaître dans les résultats de recherche ordinaires. L'Applebot-Extended d'Apple fonctionne de la même manière sur le principe : il bloque l'usage d'entraînement, et les pages qui le refusent restent éligibles aux résultats de recherche.

Dans les trois écosystèmes, le schéma est identique et mérite d'être intégré : le refus de l'entraînement IA est volontairement découplé de la présence dans l'index. Vous n'avez pas à choisir entre être indexé et refuser de servir de données d'entraînement.

Des règles qui ne peuvent pas se retourner contre vous

Les règles personnalisées sont évaluées dans l'ordre, ce qui veut dire qu'une réorganisation quelques mois plus tard peut changer le comportement. La bonne habitude consiste à rendre chaque expression de blocage sûre isolément, plutôt que de dépendre d'une règle d'exemption placée au-dessus :

Embarquez l'exclusion de bot vérifié dans l'expression. Chaque expression de blocage se termine par and not cf.client.bot. Une règle écrite ainsi ne peut pas toucher Googlebot, même si quelqu'un la remonte en tête de liste.
Ciblez des tokens complets, jamais des sous-chaînes lâches. http.user_agent contains "bot" attrape Googlebot, bingbot, Applebot, la plupart des outils de supervision et bien d'autres. C'est la première cause de désindexation accidentelle, un incident que nous détaillons dans notre guide sur le blocage accidentel de Googlebot et la chute SEO.
Attention à la casse. L'évaluation des chaînes dans le langage de règles Cloudflare est sensible à la casse par défaut. contains "gptbot" ne correspondra pas à GPTBot. Reproduisez le token exactement, ou normalisez avec lower(http.user_agent) contains "gptbot".
Ne bloquez jamais par pays ni par ASN pour régler un problème de crawler. Cela coupe les robots d'indexation, les robots d'aperçu de liens, les outils de supervision et de vrais clients derrière ces réseaux : on échange un problème de bande passante contre un problème de disponibilité.
Ne bloquez pas /robots.txt lui-même. Une règle trop large qui attrape le fichier supprime le seul canal par lequel les crawlers respectueux apprennent vos préférences. AI Crawl Control le signale dans l'onglet Directives quand le fichier commence à renvoyer des erreurs.

Pas à pas sur une zone en production

Écrivez d'abord la politique. Une ligne pour les moteurs de recherche, une pour les moteurs de réponse IA, une pour l'entraînement IA, une pour les agents en temps réel : autoriser, bloquer, ou plafonner. Revenir sur un blocage une fois que les crawlers ont cessé de venir prend bien plus de temps que de trancher correctement au départ.
Mesurez la référence. Ouvrez AI Crawl Control > Crawlers et notez quels crawlers sont réellement présents, à quel volume, et avec combien de violations de robots.txt. Recoupez le volume de requêtes dans Security > Events. Sans un avant, pas d'après démontrable, et impossible de distinguer une règle qui fonctionne d'une règle qui ne correspond silencieusement à rien.
Publiez robots.txt. Ajoutez des blocs Disallow: / pour les tokens d'entraînement que vous refusez, ajoutez une ligne Content-signal, et incluez ici Google-Extended et Applebot-Extended puisque c'est le seul endroit où ils agissent. Ou activez le réglage de robots.txt géré et laissez Cloudflare tenir la liste, en gardant à l'esprit que sa liste par défaut bloque largement l'entraînement.
Réglez les politiques de bots IA. Dans Security Settings > Configure AI bot policies, réglez Training, Agent et Search conformément aux phrases écrites à l'étape une. Pour la plupart des sites, cela donne Training bloqué, Search autorisé, Agent tranché au cas par cas. Surveillez Security > Events pendant les premières heures pour voir ce que les préréglages interceptent réellement sur votre trafic.
Ajoutez une règle personnalisée contre les usurpateurs. Dans Security > WAF > Custom rules, attrapez les clients qui envoient une signature d'entraînement connue sans passer la vérification Cloudflare :

Expression :
  (lower(http.user_agent) contains "gptbot"
   or lower(http.user_agent) contains "claudebot"
   or lower(http.user_agent) contains "ccbot"
   or lower(http.user_agent) contains "bytespider"
   or lower(http.user_agent) contains "amazonbot"
   or lower(http.user_agent) contains "meta-externalagent")
  and not cf.client.bot
Action : Block

Notez ce qui ne figure pas dans cette liste : OAI-SearchBot, PerplexityBot et Claude-SearchBot en sont délibérément absents, parce qu'ils indexent pour des moteurs de réponse qui citent et créent des liens. Ne les ajoutez que si votre ligne de politique sur les moteurs de réponse IA disait « bloquer ». Notez aussi l'absence de Google-Extended et Applebot-Extended, qui doivent le rester : aucune requête ne les transporte.

Plafonnez les clients non identifiés sur les chemins de contenu. De nouveaux agents apparaissent plus vite qu'aucune liste ne peut être tenue, et le filet de sécurité pour ceux dont vous n'avez jamais entendu parler est volumétrique plutôt que nominatif :

Expression :
  not cf.client.bot and starts_with(http.request.uri.path, "/blog/")
Caractéristique : adresse IP
Compteur : 30 requêtes sur 1 minute
Action : Managed Challenge

Les robots d'indexation vérifiés n'atteignent jamais cette règle grâce à la condition not cf.client.bot. Un client non identifié qui rafale dans vos archives est plafonné au lieu de saturer l'origine. Calez le seuil sur la référence de l'étape deux, en le gardant confortablement au-dessus de ce que peut produire un lecteur humain derrière une adresse d'entreprise partagée.

Limitez à des chemins quand l'enjeu est partiel. Si seule une partie de votre site est concernée, ajoutez la condition de chemin à l'expression de blocage plutôt que de l'appliquer à tout le site :

Expression :
  (lower(http.user_agent) contains "gptbot"
   or lower(http.user_agent) contains "claudebot")
  and starts_with(http.request.uri.path, "/archives/")
Action : Block

Confirmez que les robots d'indexation passent toujours. Filtrez Security > Events sur les user agents de Googlebot et de bingbot sur plusieurs jours. Chaque entrée doit être autorisée, ou explicable par une règle que vous avez écrite délibérément. Tout le reste est une régression à corriger immédiatement.

Le choix inverse : être découvrable par les IA volontairement

Tous les sites n'ont pas intérêt à bloquer. Le postulat selon lequel le crawl IA serait un vol vaut pour certains modèles économiques et pas pour d'autres, et il vaut mieux être honnête sur celui dans lequel on se trouve.

S'ouvrir a plutôt du sens quand votre contrainte est la découverte et non la distribution : cabinets de conseil et sociétés de services, documentation et outillage pour développeurs, logiciels B2B, expertises de niche dont l'acheteur pose désormais la première question à un assistant plutôt qu'à un moteur. Dans ces cas, une citation dans un moteur de réponse est une recommandation qualifiée que vous auriez sinon payée, et aucun revenu par page vue n'est cannibalisé.

Bloquer a plutôt du sens quand le contenu est le produit : éditeurs vivant de la page vue ou de l'abonnement, archives payantes, jeux de données propriétaires, places de marché dont le prix affiché en temps réel est l'actif, et tous ceux qui ont le poids nécessaire pour négocier une licence au lieu d'offrir le corpus.

Ce site a fait le premier choix, délibérément. Notre robots.txt accueille les crawlers IA sur tout sauf les mentions légales et les pages post-achat, et nous publions un résumé lisible par une machine sur /llms.txt. Le raisonnement est simple : il n'y a ici aucun inventaire publicitaire à protéger, et une activité de conseil se trouve en étant citée.

Si vous arrivez à la même conclusion, voici comment la mettre en œuvre proprement plutôt qu'en ne faisant rien :

Vérifiez vos politiques de bots IA au lieu de les supposer. Passez Search et Agent sur Allow explicitement. Si votre domaine a été raccordé le 15 septembre 2026 ou après, les réglages par défaut bloquent désormais Training et Agent sur les pages publicitaires : « je n'ai jamais rien configuré » ne veut plus dire « tout est autorisé ».
Laissez le robots.txt géré désactivé, ou acceptez que son contenu par défaut refuse toute la liste d'entraînement. Écrivez plutôt votre propre fichier et servez-vous des Content Signals pour exprimer une position nuancée, par exemple Content-signal: search=yes, ai-input=yes, ai-train=no si vous voulez être cité et lié sans être absorbé dans des poids de modèle.
Gardez /robots.txt en réponse 200. L'onglet Directives d'AI Crawl Control existe en partie parce qu'un robots.txt bloqué par une règle de sécurité trop zélée est une panne fréquente et invisible. Vérifiez le code de réponse à cet endroit.
Auditez vos règles existantes. Une règle de Rate Limiting écrite il y a des années contre les scrapers plafonnera aussi OAI-SearchBot. Être découvrable demande le même soin que bloquer.
Publiez un llms.txt. Proposé par Jeremy Howard en septembre 2024, c'est un fichier Markdown à la racine du site donnant un titre de niveau H1, un résumé en bloc de citation, et des sections H2 de liens accompagnés chacun d'une ligne de description, pour qu'un assistant puisse naviguer votre site sans analyser du HTML. C'est une proposition et non une norme ratifiée, mais OpenAI, Anthropic et Google en publient tous un pour leur documentation, et le Lighthouse de Chrome audite désormais sa présence.
Ne le confondez pas avec un sitemap. sitemap.xml indique à un robot quelles URL existent ; llms.txt indique à un modèle quelles pages comptent et pourquoi. Publiez les deux.

Vérifier le blocage, et repérer les faux positifs

Les règles se propagent mondialement en quelques secondes, ce qui est commode et dangereux à parts égales : une mauvaise expression fait le tour du monde aussi vite qu'une bonne. Vérifiez toujours dans les deux sens.

Confirmer que le blocage fonctionne

Security > Events, filtré sur la règle. Les correspondances doivent apparaître en quelques minutes sur un site ayant un trafic de crawlers réel. Une règle qui ne correspond à rien après un jour relève généralement d'une erreur de casse ou d'un token jamais envoyé.
AI Crawl Control > Crawlers. Comparez requêtes réussies et échouées par crawler, et suivez la courbe de tendance autour du déploiement. C'est la vue la plus claire pour savoir si les crawlers visés se sont arrêtés.
Le volume de requêtes vers l'origine, comparé à la référence. Après une semaine, confrontez aux chiffres de l'étape deux. Attendez-vous à un rebond partiel, certains scrapers bloqués changeant de user agent : c'est exactement ce que la règle de Rate Limiting est là pour absorber.
Ne vous fiez pas à un test curl. Envoyer un User-agent: GPTBot usurpé depuis votre poste prouve que votre règle anti-usurpation se déclenche, rien de plus. Votre machine échoue aux contrôles de reverse DNS et de signature que passe un vrai robot : le blocage est donc le résultat correct et attendu, et il ne dit rien du crawler réel.

Repérer les faux positifs sur du trafic légitime

Les victimes d'une règle IA trop large sont rarement des humains, et c'est ce qui les rend faciles à manquer : ce sont des clients automatisés dont vous dépendez, qui échouent en silence.

Robots d'indexation. Dans la Google Search Console, lancez un test d'URL en direct et confirmez une réponse 200, puis surveillez Paramètres > Statistiques d'exploration pour une hausse des erreurs client ou une baisse des requêtes d'exploration. Bing Webmaster Tools propose l'équivalent. Découvrir le problème par une chute des pages indexées quinze jours plus tard est la voie coûteuse.
Robots d'aperçu de liens. Partagez une URL dans Slack, Discord, WhatsApp et sur votre principal réseau social. L'absence de carte d'aperçu signale que facebookexternalhit ou un équivalent est intercepté.
Lecteurs de flux et supervision. Des sondes de disponibilité qui alertent sur des 403, un nombre d'abonnés RSS qui baisse, une page de statut qui passe au rouge sans raison : autant de symptômes classiques.
Votre propre infrastructure. Chaînes d'intégration continue, tests en navigateur sans interface, rappels des prestataires de paiement, scanners d'accessibilité et déploiements de préproduction ressemblent tous à de l'automatisation vus du niveau Edge.
Vérifiez une IP suspecte plutôt que de deviner. Pour Google, une résolution DNS inverse doit renvoyer googlebot.com, google.com ou googleusercontent.com, et une résolution directe sur ce nom doit redonner la même IP ; à défaut, comparez aux listes CIDR publiées par Google. Anthropic et Common Crawl publient des listes JSON équivalentes.
Déployez d'abord en action Log là où le produit le permet. Examinez pendant quelques heures ce que la règle aurait intercepté, puis passez-la en Managed Challenge ou en blocage sur la base de preuves plutôt que d'espoir.

Si les symptômes que vous poursuivez relèvent du bruit automatisé générique plutôt que des crawlers IA en particulier, les règles de remplacement de notre guide sur les faux positifs du Bot Fight Mode partagent la même base de bots vérifiés et constituent le bon point de départ.

Les erreurs fréquentes

Écrire une règle de sécurité sur Google-Extended ou Applebot-Extended. Ce sont des tokens robots.txt sans user agent derrière eux. La règle ne correspond à aucune requête et crée un faux sentiment de protection.
Croire que robots.txt applique quoi que ce soit. C'est une demande, pas un contrôle. Le point d'application est le niveau Edge.
Bloquer les moteurs de réponse en croyant bloquer les entraîneurs. OAI-SearchBot n'est pas GPTBot ; Claude-SearchBot n'est pas ClaudeBot. Se tromper de moitié dans chaque paire vous coûte des citations tout en laissant intact le crawl d'entraînement.
Prendre cf.client.bot pour une politique IA. Vérifié signifie identifié, pas bienvenu. La plupart des crawlers IA sont des bots vérifiés.
Le filtrage par sous-chaîne lâche. contains "bot" est l'accident de désindexation classique.
Oublier la sensibilité à la casse. Un token en minuscules dans une comparaison sensible à la casse ne correspond silencieusement à rien.
Bloquer des pays ou des ASN entiers. Cela coupe les robots d'indexation, les robots d'aperçu, la supervision et de vrais utilisateurs mobiles derrière ces réseaux.
Laisser le mode « I'm Under Attack » activé en permanence. L'interstitiel JavaScript casse tout client non navigateur : applications mobiles, API de serveur à serveur, tâches planifiées et rappels de paiement. C'est un levier d'urgence, pas une configuration.
Tenir une liste figée sans jamais la revoir. De nouveaux agents apparaissent en permanence et les existants sont renommés. Les préréglages par comportement survivent à ce roulement, une liste écrite à la main non.
Changer plusieurs choses à la fois. Un réglage, une observation, puis le suivant. Sinon aucun effet n'est attribuable et vous ne pouvez pas revenir en arrière sur celui qui a fait mal.
Ne jamais réexaminer la décision. Une politique arrêtée en 2024 est antérieure à l'époque où la recherche IA a commencé à envoyer du trafic mesurable. Mieux vaut la retrancher chaque année que d'en hériter par défaut.

Questions fréquentes

Cloudflare bloque-t-il les crawlers IA par défaut ?

Pas sur une zone existante que vous n'avez jamais configurée. Cloudflare fournit à tous ses clients, offre Free comprise, des politiques de bots IA couvrant trois comportements : Search, Agent et Training. Chacun se règle sur Allow, Block sur toutes les pages, ou Block sur les pages qui affichent de la publicité. À partir du 15 septembre 2026, Cloudflare applique de nouveaux réglages par défaut aux domaines nouvellement raccordés : Training et Agent bloqués sur les pages publicitaires, Search autorisé. Les zones existantes conservent leur réglage antérieur, donc la seule réponse fiable pour votre site consiste à ouvrir Security Settings et à lire les valeurs en place.

Comment bloquer les crawlers IA ?

En trois couches. Déclarez votre préférence dans robots.txt pour que les opérateurs respectueux s'arrêtent d'eux-mêmes. Passez le préréglage Training sur Block dans les politiques de bots IA de Cloudflare, pour que le blocage s'applique réellement au niveau Edge même quand un crawler change de user agent. Ajoutez enfin une règle de sécurité personnalisée qui cible les tokens d'entraînement combinés à not cf.client.bot, afin d'écarter les clients qui envoient une signature connue sans passer la vérification Cloudflare. Seules les deux dernières couches arrêtent effectivement quelque chose.

Existe-t-il un bloqueur de bots IA intégré à Cloudflare ou faut-il un outil tiers ?

Tout est intégré, aucun outil tiers n'est nécessaire. Configure AI bot policies, dans Security Settings, est le bloqueur proprement dit. AI Crawl Control, disponible sur toutes les offres et sans configuration, en est la face observation : il liste chaque crawler IA vu sur votre zone, ses requêtes, le nombre de violations de votre robots.txt, avec une action Allow ou Block par crawler. Sur l'offre Free, AI Crawl Control identifie les crawlers par leur chaîne de user agent uniquement ; les offres payantes ajoutent les signaux de détection propres à Cloudflare.

Bloquer les crawlers IA va-t-il pénaliser mon référencement Google ?

Non, à condition de bloquer les crawlers IA et pas Googlebot : ce sont des clients différents. Google indique que Google-Extended, le token robots.txt qui gouverne l'entraînement et le grounding, n'a aucune incidence sur la présence d'un site dans Google Search et n'est pas utilisé comme signal de classement. Le vrai risque est le dommage collatéral : une règle écrite sur un ASN, un pays ou une sous-chaîne trop large comme bot peut attraper Googlebot par accident, et cela coûte bien des positions. C'est pourquoi chaque expression de blocage de ce guide embarque une exclusion explicite des bots vérifiés.

Que fait exactement le blocage de Google-Extended, et que ne fait-il pas ?

Google-Extended n'a pas de user agent propre. Google précise qu'il n'existe pas de chaîne de user agent HTTP distincte et que le crawl est effectué avec les user agents Google existants : c'est donc un token robots.txt uniquement, impossible à cibler dans une règle de sécurité au niveau Edge. Le refuser indique à Google de ne pas utiliser votre contenu pour entraîner les futurs modèles Gemini ni pour le grounding dans les applications Gemini et Grounding with Google Search sur Vertex AI. Cela ne vous retire pas de l'index Google, ne modifie pas votre classement, et ne vous retire pas des AI Overviews ni d'AI Mode, qui font partie de Search et reposent sur Googlebot.

Comment empêcher tous les robots d'explorer mon site ?

C'est possible, mais c'est presque toujours une mauvaise idée. Une règle qui bloque tout client n'étant pas un navigateur supprime aussi les moteurs de recherche, les robots d'aperçu de liens de Slack, Discord et WhatsApp, les lecteurs RSS, les outils de supervision, les scanners d'accessibilité, les rappels de vos prestataires de paiement et vos propres contrôles de déploiement. Un objectif plus utile consiste à plafonner ce que l'automatisation vous coûte : bloquer les crawlers d'entraînement que vous avez écartés, plafonner les clients non identifiés sur les chemins riches en contenu, et laisser passer les bots vérifiés qui vous apportent du trafic ou dont vous dépendez.

Comment bloquer les robots SEO comme Ahrefs, Semrush ou Majestic sans bloquer les moteurs de recherche ?

Ciblez leurs tokens de user agent explicitement plutôt que des catégories entières, et gardez les robots d'indexation vérifiés hors de l'expression. La plupart des crawlers SEO commerciaux s'identifient honnêtement et respectent robots.txt : un Disallow assorti d'une règle de blocage étroite suffit généralement. Gardez en tête que les bloquer retire aussi votre propre site de leurs graphes de liens, donc votre veille concurrentielle et votre suivi de backlinks cessent de fonctionner.

Comment bloquer Googlebot volontairement ?

Bloquer Googlebot au niveau Edge est le mauvais outil pour presque toutes les raisons qui poussent à le faire. Pour sortir une page de l'index, servez-la avec une balise meta robots noindex et laissez Googlebot la lire : un robot bloqué ne peut pas prendre connaissance de l'instruction de désindexation. Si le volume de crawl est le problème, utilisez les statistiques d'exploration de la Search Console et corrigez les réponses lentes qui font ralentir Google. Ne bloquez Googlebot au niveau Edge que pour un hôte de préproduction, en limitant la règle à ce seul nom d'hôte. Notre guide sur le blocage accidentel de Googlebot et la chute SEO détaille ce qui se passe quand cela dérape sur une zone de production.

Comment bloquer les crawlers IA sur certaines pages seulement ?

Ajoutez une condition de chemin à l'expression de blocage, par exemple un test starts_with() sur http.request.uri.path, pour que la règle ne vise que vos archives ou votre espace membres. Cloudflare propose aussi une version prête à l'emploi de la même idée : l'option Block on pages with ads des politiques de bots IA limite le blocage aux pages détectées comme affichant de la publicité. Si votre site est un projet Cloudflare Pages, les mêmes règles s'appliquent dès lors que le domaine personnalisé est proxifié par une zone que vous contrôlez.

J'ai bloqué les crawlers IA et quelque chose de légitime est cassé. Comment corriger ?

Ouvrez Security > Events, filtrez sur la règle ajoutée et lisez les user agents réellement interceptés. Les victimes habituelles sont les robots d'aperçu de liens, les lecteurs RSS, les outils de supervision, votre propre intégration continue et, quand l'expression utilisait une sous-chaîne trop large, les robots d'indexation. Resserrez l'expression plutôt que de désactiver la règle : ajoutez l'exclusion de bot vérifié manquante, remplacez la sous-chaîne par un token complet, ou limitez la règle aux chemins réellement concernés. Si Googlebot figure parmi les correspondances, supprimez la règle immédiatement et relancez un test d'URL en direct dans la Search Console.

Puis-je autoriser les moteurs de réponse IA tout en bloquant l'entraînement ?

Oui, et c'est la politique la plus répandue en pratique. Plusieurs opérateurs publient des tokens distincts selon l'usage : OAI-SearchBot pour les résultats de recherche de ChatGPT face à GPTBot pour l'entraînement, Claude-SearchBot face à ClaudeBot, PerplexityBot pour l'indexation. Passez le préréglage Training sur Block et le préréglage Search sur Allow dans les politiques de bots IA, et ne gardez que les tokens d'entraînement dans votre règle personnalisée. Attention : Cloudflare bloque les crawlers à usage mixte, utilisés à la fois pour Search et Training, sous n'importe quel blocage d'entraînement.

Comment bloquer les agents IA qui agissent en temps réel pour un utilisateur ?

Passez le préréglage Agent sur Block dans les politiques de bots IA. Agent couvre l'activité automatisée agissant en temps réel pour le compte d'une personne, comme les robots de récupération de page des assistants conversationnels et les agents pilotant un navigateur : ChatGPT-User, Claude-User, Perplexity-User, meta-externalfetcher. Décidez-le en connaissance de cause, car un humain est à l'origine de cette requête et plusieurs opérateurs indiquent que robots.txt ne s'applique pas aux requêtes initiées par un utilisateur. Bloquer les agents signifie qu'une personne qui demande à un assistant de lire votre page n'obtiendra rien.

La protection anti-bot de Cloudflare suffit-elle à elle seule ?

Pour les crawlers IA qui s'identifient, les politiques de bots IA associées à une règle personnalisée couvrent les cas réalistes. Le Bot Fight Mode est un produit différent, avec une finalité différente, et n'est pas un contrôle de crawlers IA : il note l'automatisation générique sans réglage possible, d'où ses faux positifs sur des clients légitimes, détaillés dans notre guide sur les faux positifs du Bot Fight Mode. Ce qui rend une règle fiable, ce sont les signaux infalsifiables : cf.client.bot sur toutes les offres et les champs Bot Management sur les offres payantes. Une chaîne de user agent n'est qu'une déclaration, pas une preuve.

Faut-il plutôt rendre son site découvrable par les IA que le bloquer ?

Pour un site dont l'activité dépend d'être trouvé et cité plutôt que d'un revenu publicitaire par page vue, s'ouvrir aux robots de recherche IA est un choix défendable, et c'est celui qu'a fait ce site. Gardez Search et Agent autorisés, bloquez Training si vous le souhaitez, déclarez-le dans robots.txt avec les Content Signals, et publiez un llms.txt décrivant vos pages en Markdown. Les éditeurs qui monétisent la page vue, les archives payantes et les sites dont les données sont le produit doivent conclure l'inverse.

Comment savoir si le blocage fonctionne réellement ?

Ouvrez Security > Events et filtrez sur la règle : les correspondances apparaissent en quelques minutes, les règles se propageant mondialement en quelques secondes. Recoupez dans AI Crawl Control, qui indique les requêtes réussies et échouées par crawler et compte les violations de robots.txt. Vérifiez ensuite l'autre versant : lancez un test d'URL en direct dans la Google Search Console et confirmez une réponse 200. Un test avec curl et un user agent usurpé ne prouve que le déclenchement de votre règle anti-usurpation, puisque votre machine échoue au contrôle de reverse DNS que passe un vrai robot.

Sources

Tous les éléments factuels ci-dessus ont été vérifiés sur les documentations primaires le 12 septembre 2026 : les pages Cloudflare sur le blocage des bots IA, les bots vérifiés, AI Crawl Control, le robots.txt géré, Web Bot Auth et les variables Bot Management ; l'enquête publiée par Cloudflare sur le crawl Perplexity non déclaré ; les documentations de robots publiées par OpenAI, Anthropic, Perplexity, Google Search Central, Apple, Amazon, Meta et Common Crawl ; le blog Bing Webmaster sur NOARCHIVE et NOCACHE ; le Content Signals Policy ; et la proposition llms.txt.

Bloquer les crawlers IA sur Cloudflare™ sans bloquer Googlebot