Cloudflare bloque les crawlers IA par défaut le 15 septembre 2026 : ce qui change

En bref — Le 1er juillet 2026, Cloudflare a ouvert à tous ses clients, offre gratuite comprise, un réglage qui classe les robots en trois catégories : Search, Agent et Training. Le 15 septembre 2026, les valeurs par défaut changent — sur les pages qui affichent de la publicité, Training et Agent seront bloqués sans action de votre part. Le point réellement critique est ailleurs : Cloudflare indique qu'un crawler multi-usages est traité selon la règle la plus restrictive qui le concerne, et cite nommément Googlebot, Applebot et Bingbot comme pouvant être bloqués par un site ayant choisi de bloquer Training. Aucun de ces blocages n'apparaîtra dans votre robots.txt : ils sont appliqués au niveau du réseau, en amont de votre serveur. Vos logs serveur sont le seul endroit où ils deviennent visibles.

Cloudflare a publié le 1er juillet 2026 une annonce qui modifie la manière dont les robots d'exploration accèdent à une part importante du web. L'entreprise place devant plus d'un cinquième des sites mondiaux : un changement de ses valeurs par défaut ne relève pas du réglage d'éditeur, il déplace la ligne de base pour tout le monde.

Cet article décrit ce qui a été annoncé, ce qui change précisément le 15 septembre 2026, et surtout ce qu'un responsable SEO peut faire pour vérifier si son site est concerné. Nous distinguons systématiquement ce qui est documenté par Cloudflare de ce qui relève de l'interprétation — la nuance compte particulièrement ici, parce que l'effet secondaire le plus lourd de cette annonce concerne un robot dont personne ne veut se passer : Googlebot.

Ce que Cloudflare a annoncé le 1er juillet 2026

L'annonce, publiée sous le nom de « Content Independence Day », introduit un contrôle par finalité plutôt que par robot. Jusque-là, autoriser ou bloquer un crawler se faisait nom par nom : une règle pour GPTBot, une autre pour ClaudeBot, une troisième pour PerplexityBot. Cette approche impose de suivre l'apparition de chaque nouvel agent — et il en apparaît régulièrement.

Le nouveau modèle regroupe les robots selon ce qu'ils font de votre contenu. Cloudflare motive ce changement par le déséquilibre entre exploration et trafic renvoyé, en citant ses propres ratios mesurés en 2025 : environ 14 requêtes d'exploration pour une visite renvoyée chez Google, 1 700 pour une chez OpenAI, et 73 000 pour une chez Anthropic. Ces chiffres sont ceux de Cloudflare, mesurés sur son réseau ; nous les rapportons comme tels et n'avons aucun moyen de les vérifier indépendamment.

Le raisonnement sous-jacent est explicite : l'échange historique entre un éditeur et un moteur — vous m'explorez, vous m'envoyez des lecteurs — ne tient plus quand le rapport atteint plusieurs milliers pour un. La réponse de Cloudflare est de rendre le refus plus simple, et d'en faire progressivement la position par défaut.

Search, Agent et Training : ce que recouvre chaque catégorie

Search désigne, selon la définition de Cloudflare, tout comportement qui collecte ou indexe votre contenu afin de pouvoir répondre à des questions le concernant plus tard. Cette catégorie englobe les moteurs classiques et les moteurs de réponse qui citent leurs sources. C'est la catégorie qui peut vous renvoyer des lecteurs, et elle reste autorisée par défaut.

Agent désigne un comportement automatisé agissant en temps réel pour le compte d'une personne, afin d'accomplir une tâche immédiate. C'est la famille de ChatGPT-User ou des agents de navigation : une requête déclenchée par un humain qui attend une réponse. Ces agents ne construisent pas d'index ; ils consultent une page à l'instant où quelqu'un en a besoin.

Training désigne un crawler qui prélève du contenu pour entraîner ou affiner un modèle. C'est le rôle documenté de GPTBot et de ClaudeBot. Le contenu collecté est absorbé dans les poids du modèle : il n'existe aucun mécanisme de citation ni de renvoi associé.

Cette tripartition recoupe largement la distinction que nous documentons fiche par fiche dans notre référentiel des crawlers : entraînement d'un côté, citation de l'autre. La nouveauté n'est pas conceptuelle, elle est opérationnelle — c'est désormais un interrupteur à trois positions plutôt qu'une liste de noms à maintenir.

Ce qui change exactement le 15 septembre 2026

Depuis le 1er juillet 2026, les trois réglages sont disponibles pour tous les clients Cloudflare, y compris sur l'offre gratuite. À cette date, rien n'a changé automatiquement : les contrôles sont proposés, pas appliqués.

Le 15 septembre 2026, les valeurs par défaut basculent. Sur les pages qui affichent de la publicité, Training et Agent seront bloqués par défaut, tandis que Search restera autorisé par défaut. Cloudflare annonce également la mise à disposition d'un robots.txt géré et d'une option permettant d'empêcher l'accès aux portions de site monétisées par la publicité.

Le mot important est « par défaut ». Il ne s'agit pas d'un blocage imposé : un propriétaire de site peut modifier ces réglages dans ses paramètres de sécurité avant le 15 septembre, ou après. Mais l'inaction n'est plus neutre — jusqu'ici, ne rien faire signifiait laisser passer ; à partir du 15 septembre, pour les sites concernés, ne rien faire signifie bloquer.

Le piège des crawlers multi-usages : Googlebot, Applebot et Bingbot

C'est la partie de l'annonce qui mérite le plus d'attention, et c'est celle qui a été la moins relayée. Un même robot peut appartenir à plusieurs catégories : il explore pour indexer *et* il collecte de la donnée susceptible de servir à l'entraînement. Cloudflare indique qu'un tel crawler multi-usages est traité selon la règle la plus restrictive qui s'applique à lui.

La conséquence est formulée noir sur blanc dans l'annonce : les crawlers multi-usages tels que Googlebot, Applebot et Bingbot seront bloqués chez les clients ayant choisi de bloquer Training. Autrement dit, un éditeur qui coche « bloquer l'entraînement » avec l'intention de refuser GPTBot et ClaudeBot peut, par la même action, cesser de servir Googlebot, Applebot et Bingbot.

Il faut mesurer ce que cela implique. Bloquer Googlebot n'est pas une perte de visibilité IA : c'est une sortie progressive de l'index Google. Les pages cessent d'être réexplorées, les mises à jour ne sont plus vues, et le déclassement suit. Un site peut donc désindexer son propre contenu en croyant simplement refuser l'entraînement de modèles de langage — une intention parfaitement légitime, avec un effet collatéral disproportionné.

Cloudflare décrit ce mécanisme comme une pression assumée sur les fournisseurs d'IA : séparer leurs robots d'entraînement de leurs robots de recherche, ou accepter que le blocage porte sur l'ensemble. C'est un levier de négociation dont les éditeurs sont les intermédiaires — et, si le réglage est mal compris, les victimes.

Qui est concerné par le changement de valeurs par défaut

Le basculement du 15 septembre ne touche pas tout le monde de la même manière. D'après l'annonce, les nouvelles valeurs par défaut s'appliquent aux nouveaux clients Cloudflare, aux nouveaux sites créés par des clients existants, et à l'ensemble des clients de l'offre gratuite.

Ce dernier point élargit considérablement la population concernée. L'offre gratuite de Cloudflare est massivement utilisée par des sites vitrines, des blogues, des projets associatifs et des petites structures — précisément le profil de propriétaires qui ne consultent pas leur tableau de bord de sécurité et ne liront pas cette annonce. Ce sont aussi ceux qui disposent le moins de moyens pour diagnostiquer une chute de trafic six semaines après coup.

À l'inverse, un client payant existant, sur un site déjà configuré, conserve ses réglages actuels tant qu'il ne les modifie pas. Si vous gérez plusieurs propriétés, l'inventaire à faire est donc précis : lesquelles sont sur l'offre gratuite, lesquelles ont été créées récemment, et lesquelles affichent de la publicité.

Si vous ignorez si un site passe par Cloudflare, la vérification la plus rapide tient dans un en-tête de réponse : une requête vers le domaine renvoie un en-tête server: cloudflare et un identifiant cf-ray lorsque c'est le cas. Les agences et les indépendants qui héritent de sites clients sont les plus exposés, parce que le choix d'hébergement est souvent antérieur à leur intervention et qu'aucune interface de CMS ne le signale. Une propriété migrée vers Cloudflare par un prestataire précédent, sur l'offre gratuite, correspond exactement à la configuration qui bascule le 15 septembre sans que personne n'en soit averti.

Pourquoi votre robots.txt ne vous dira pas que vous êtes bloqué

Un blocage appliqué par Cloudflare intervient au niveau du réseau, avant que la requête n'atteigne votre serveur d'origine. Il ne modifie pas le contenu de votre fichier robots.txt — ce fichier peut continuer d'autoriser explicitement Googlebot pendant que le robot reçoit une réponse de refus au niveau du proxy.

C'est une distinction que beaucoup d'audits techniques manquent, parce qu'ils vérifient la *déclaration* plutôt que le *comportement*. Un testeur de robots.txt lit un fichier et simule une règle ; il ne rejoue pas la requête depuis l'adresse IP réelle du robot, à travers la couche réseau qui la filtrera. Les deux peuvent diverger complètement.

La même limite vaut pour les outils d'analyse fondés sur une balise JavaScript. Un robot bloqué au niveau réseau n'exécute rien, ne charge aucun script, et n'apparaît dans aucun rapport analytique. Il ne laisse une trace qu'à un seul endroit : le journal des requêtes reçues, c'est-à-dire vos logs serveur.

Comment repérer un blocage de crawler dans vos logs serveur

Deux signaux permettent de détecter un blocage. Le premier est un code de réponse de refus adressé à un robot légitime : un 403 servi à Googlebot, ou un 429 répété, sont anormaux et méritent une enquête immédiate. Nous détaillons la lecture de ces codes dans notre guide sur les erreurs 404 et 5xx vues par les crawlers — la logique est identique pour les codes de refus.

Le second signal est plus insidieux : la disparition pure et simple. Si le blocage intervient au niveau du réseau, la requête n'atteint jamais votre serveur, et aucune ligne n'est écrite dans votre journal. Vous ne verrez pas d'erreur — vous verrez une absence. C'est pourquoi une mesure de référence prise *avant* le 15 septembre a beaucoup plus de valeur qu'un diagnostic tenté après coup : sans point de comparaison, une absence ne se distingue pas d'une accalmie.

Concrètement, la démarche tient en trois temps. Exportez vos logs sur une fenêtre représentative — notre guide explique comment les récupérer selon votre hébergement. Relevez le volume quotidien de requêtes par robot, en vérifiant leur authenticité par plage d'IP plutôt que par user-agent, ce dernier étant trivialement falsifiable. Conservez ce relevé daté : il devient votre témoin.

→ Établissez votre relevé de référence dans l'analyseur de logs Crawl Lab : segmentation par robot et par code de réponse, vérification d'authenticité par plages d'IP officielles, volumes quotidiens. Tout se passe dans votre navigateur, aucun fichier n'est téléversé.

Ce qu'il faut vérifier avant le 15 septembre 2026

La première vérification est administrative : identifiez lesquelles de vos propriétés sont derrière Cloudflare, sur quelle offre, et lesquelles affichent de la publicité. C'est le croisement de ces trois critères qui détermine si le basculement vous concerne.

La deuxième est le réglage lui-même. Ouvrez les paramètres de sécurité et regardez l'état des trois catégories. Si vous tenez à votre visibilité dans la recherche classique, la question à trancher n'est pas « est-ce que je bloque l'IA », mais « est-ce que mon réglage Training emporte des robots que je veux garder ». Compte tenu du traitement des crawlers multi-usages, ces deux questions n'ont pas la même réponse.

La troisième est la mesure. Prenez un relevé de crawl daté avant la bascule, et un autre dans les jours qui suivent. C'est la seule méthode qui permette d'attribuer une variation à ce changement plutôt qu'à autre chose — une mise à jour d'algorithme, une panne, ou une simple fluctuation. Notre étude de cas sur le budget de crawl d'un site neuf montre à quel point les volumes de crawl varient d'un jour à l'autre : sans mesure avant/après, une baisse de 30 % n'est pas interprétable.

Ce que cette annonce ne permet pas encore de mesurer

Nous n'avons observé aucun effet de ce changement dans nos propres logs, pour une raison simple : la bascule n'a pas encore eu lieu. Tout ce qui précède est documenté par Cloudflare, pas constaté par nous. Nous tenons à cette distinction — un fait documenté et un fait observé n'ont pas le même statut, et les confondre est la manière la plus courante de produire du contenu SEO faux avec assurance.

Trois inconnues subsistent en particulier. La définition exacte d'une « page qui affiche de la publicité » n'est pas précisée dans le détail : on ignore si elle repose sur la détection de scripts publicitaires, sur une déclaration du client, ou sur une autre méthode. La classification d'un robot donné dans une catégorie relève de Cloudflare et peut évoluer sans que les éditeurs en soient notifiés. Enfin, la réaction des fournisseurs d'IA — séparer leurs agents, ou non — déterminera l'ampleur réelle de l'effet sur les crawlers multi-usages.

Nous republierons une mesure après le 15 septembre 2026, avec le même protocole que nos études précédentes et sur la même propriété, pour confronter ces annonces à des logs réels. D'ici là, le seul conseil défendable est celui-ci : prenez votre relevé de référence maintenant, pendant qu'il a encore une valeur de comparaison.

À lire aussi

• Analyse de log serveur pour le SEO : le guide complet (2026)
• Budget de crawl : ce que la nouvelle documentation Google change vraiment
• Budget de crawl d'un site neuf : ce que nos logs montrent
• Erreurs 404 et 5xx vues par les crawlers : les repérer dans les logs SEO
• Récupérer ses logs serveur : Apache, Nginx, cPanel, CDN