Crawlers IA : lesquels bloquer avant le 15 septembre 2026 ?

Vous avez treize jours, et vous ne savez probablement pas quel bot IA vous rapporte quoi. Le 15 septembre 2026, Cloudflare change son comportement par défaut et se met à bloquer une partie des crawlers IA sur les pages qui portent de la publicité, sans que vous ayez rien décidé. Si votre site est sur un compte gratuit existant, ou s’il s’agit d’un nouveau site chez un client existant, la bascule se fait toute seule. Des milliers de sites vont donc changer de politique de crawl à l’aveugle. La vraie question n’est pas « faut-il bloquer les crawlers IA ». C’est : lesquels, et sur quelle donnée. Voici la méthode pour trancher, logs à l’appui, avant que le défaut ne tranche à votre place.

Ce qui change le 15 septembre 2026

Les faits, sans dramatiser. Cloudflare a annoncé le 1er juillet 2026 qu’à partir du 15 septembre, les crawlers d’entraînement et d’agent seraient bloqués par défaut sur les pages monétisées par de la publicité. Le changement vise trois populations : les nouveaux domaines, les nouveaux sites des comptes existants, et surtout tous les comptes gratuits existants qui n’ont pas modifié leurs réglages. Les crawlers de recherche, eux, restent autorisés par défaut.

Deux détails comptent plus que le titre. D’abord, les bots « mixtes » comme Googlebot, qui crawlent à la fois pour la recherche et pour l’entraînement, sont traités par la règle la plus restrictive : un réglage trop large peut vous sortir de Google sans que vous l’ayez voulu. Ensuite, Cloudflare fait évoluer son « Pay Per Crawl » de 2025 vers un « Pay Per Use » : vous êtes rémunéré quand votre contenu apparaît dans une réponse IA, pas seulement quand un bot aspire la page. Le principe est meilleur, mais il ne vous dispense pas de savoir ce que chaque bot fait chez vous.

Les trois familles de crawlers IA, et pourquoi la confusion coûte cher

C’est l’erreur numéro un, et elle est partout. On parle « des IA » comme d’un bloc, alors qu’il y a trois métiers derrière, avec trois effets opposés quand on les bloque. Bloquer GPTBot ne vous sort pas des réponses ChatGPT. Bloquer OAI-SearchBot, si. Tant que ce point n’est pas clair, toute décision de blocage est un coup de dé.

Retenez la logique, pas le tableau par cœur. Le bot d’entraînement se bloque sans douleur pour votre trafic (c’est un arbitrage de propriété du contenu, pas de visibilité). Le bot d’index de recherche est celui qui vous met, ou pas, dans les réponses : le bloquer, c’est renoncer à la citation. Le bot de récupération live est déclenché par un vrai utilisateur, donc le bloquer revient à fermer la porte à quelqu’un qui vous cherche activement. Ne le confondez pas avec un navigateur agentique piloté par un humain, qui rend la page dans un vrai navigateur : ce cas-là est traité dans Navigateurs IA dans GA4 : détecter Atlas et Comet, et il ne se gère pas au niveau du crawl.

Pourquoi GA4 est aveugle ici

Vous allez avoir le réflexe d’ouvrir GA4 pour voir « combien passe ». N’y comptez pas : GA4 ne voit aucun des trois bots. La raison est mécanique. Ces crawlers ne rendent pas le JavaScript, ils n’exécutent donc jamais votre tag, et rien ne remonte. GA4 mesure des humains équipés d’un navigateur ; un crawler qui télécharge du HTML brut passe totalement sous le radar.

C’est aussi pour ça que le rapport « Generative AI performance » de Search Console, déployé mondialement le 31 août 2026, ne suffit pas : il donne des impressions, pas les clics, et il ne dit rien du crawl lui-même. Sur la partie mesure de l’impact, le sujet est traité en détail dans Google AI Overviews : mesurer l’impact sur le trafic organique. Mais pour savoir qui aspire quoi, il n’y a qu’une source de vérité : vos logs serveur.

Le pipeline : des logs vers BigQuery

La bonne nouvelle, c’est que la donnée existe déjà, elle attend juste d’être exploitée. Trois sources possibles selon votre stack : Cloudflare Logpush si vous êtes derrière Cloudflare, les logs d’accès de votre origine (Cloud Run, Nginx, votre CDN), ou les deux recoupés. Vous poussez ces logs dans BigQuery et vous avez, enfin, une vue par requête.

Le schéma minimal tient en cinq colonnes : timestamp, user_agent, client_ip, url_path, status_code. C’est tout ce qu’il faut pour l’analyse qui suit. Côté coût, on parle de quelques centimes à quelques euros par mois pour un site de taille moyenne : le stockage BigQuery est facturé au volume scanné, et ces requêtes scannent peu si vous partitionnez par date. Si vous n’avez pas encore de dataset BigQuery en place, la mise en route est décrite dans Exploiter l’export GA4 dans BigQuery ; le principe d’ingestion des logs est le même, avec une table dédiée.

La requête : volume de crawl par bot, par URL, semaine par semaine

Une fois les logs dans BigQuery, la première question est simple : qui vient, combien, et sur quoi. Voici la requête de départ, à adapter au nom de votre table.

SELECT
  CASE
    WHEN user_agent LIKE '%GPTBot%'         THEN 'GPTBot (train OpenAI)'
    WHEN user_agent LIKE '%OAI-SearchBot%'  THEN 'OAI-SearchBot (search)'
    WHEN user_agent LIKE '%ChatGPT-User%'   THEN 'ChatGPT-User (live)'
    WHEN user_agent LIKE '%ClaudeBot%'      THEN 'ClaudeBot (train Anthropic)'
    WHEN user_agent LIKE '%Claude-SearchBot%' THEN 'Claude-SearchBot (search)'
    WHEN user_agent LIKE '%Claude-User%'    THEN 'Claude-User (live)'
    WHEN user_agent LIKE '%PerplexityBot%'  THEN 'PerplexityBot (search)'
    ELSE 'autre'
  END AS bot,
  DATE_TRUNC(DATE(timestamp), WEEK) AS semaine,
  COUNT(*) AS hits,
  COUNT(DISTINCT url_path) AS urls_distinctes
FROM `votre_projet.logs.access`
WHERE DATE(timestamp) >= DATE_SUB(CURRENT_DATE(), INTERVAL 8 WEEK)
  AND REGEXP_CONTAINS(user_agent, r'(?i)(GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|Claude-User|PerplexityBot)')
GROUP BY bot, semaine
ORDER BY semaine DESC, hits DESC;

Vous obtenez, semaine par semaine, le volume de chaque bot et le nombre d’URL distinctes touchées. Regardez le ratio hits / urls_distinctes : s’il est très élevé, le bot re-télécharge en boucle des pages qui n’ont pas changé. Cloudflare a documenté que plus de la moitié du crawl IA sert justement à re-télécharger du contenu inchangé, ce qui est du coût pur pour vous et zéro valeur ajoutée. Pour d’autres recettes SQL prêtes à l’emploi sur vos données, voir Les 10 requêtes BigQuery indispensables pour analyser GA4.

L’étape que tout le monde saute : l’anti-spoofing

Voilà le piège. N’importe qui peut se déclarer « GPTBot » dans son user-agent. Si vous décidez sur le user-agent seul, vous comptez des imposteurs, et vous risquez de bloquer un vrai bot légitime en croyant taper sur un faux. Cloudflare a d’ailleurs publié dès août 2025 des preuves de crawlers non déclarés qui font tourner leurs user-agents et leurs IP pour contourner robots.txt.

La parade : chaque éditeur publie ses plages d’IP officielles (OpenAI, Anthropic, Perplexity, Google). Vous chargez ces plages dans une petite table BigQuery et vous validez que l’IP du hit tombe bien dedans avant de compter le bot comme authentique. Concrètement, une jointure sur la plage CIDR, et une colonne verifie à vrai/faux. Tout ce qui se dit « GPTBot » depuis une IP hors plage part dans un seau « suspect » que vous traiterez au niveau du WAF, pas de la politique de crawl. C’est cinq minutes de travail, et ça change vos chiffres du tout au tout.

Le crawl-to-refer ratio : ce que chaque bot coûte vraiment

Maintenant le cœur du sujet, celui que personne ne traite. Un bot qui aspire beaucoup n’est pas forcément un problème, s’il vous renvoie du trafic en retour. La bonne métrique, c’est le crawl-to-refer ratio : le nombre de pages aspirées par le bot divisé par le nombre de visites qu’il vous envoie.

Le numérateur, vous l’avez : ce sont vos hits crawler vérifiés, par éditeur. Le dénominateur, ce sont les sessions du canal « AI Assistant » de GA4, ventilées par source (ChatGPT, Perplexity, Claude). La méthode pour construire proprement ce canal et récupérer ces referrals est détaillée dans Tracker le trafic ChatGPT, Gemini et Claude dans GA4. Vous croisez les deux, éditeur par éditeur, et vous obtenez un ratio parlant.

Pour donner des ordres de grandeur, datés et à prendre comme tels : sur la fenêtre de juillet 2026 relayée à partir de Cloudflare Radar, ClaudeBot pesait autour de 18 % des requêtes de crawlers IA contre environ 10 % pour GPTBot, avec des ratios crawl-to-refer de l’ordre de 2 200:1 côté Anthropic et 200:1 côté OpenAI. Ces chiffres bougent énormément d’un mois et d’une source à l’autre, donc ne les prenez pas pour une vérité stable : mesurez les vôtres. Le principe, lui, ne bouge pas : un ratio de plusieurs milliers pour un, c’est un bot qui prend tout et ne rend rien.

La matrice de décision : Allow, Charge, Block, bot par bot

Vous avez les volumes vérifiés et les ratios. Vous pouvez enfin décider, et la décision dépend de votre modèle. Voici la grille.

La logique de fond. En B2B, la citation dans une réponse IA amène des leads très qualifiés, donc on garde grand ouverts les bots de recherche et de récupération, et on serre les bots d’entraînement qui ne rendent rien. En média, le contenu est l’actif : le nouveau Pay Per Use rend le « Charge » enfin crédible, et l’arbitrage « bloquer = renoncer à la citation » se joue au cas par cas (le sujet est creusé dans Mesurer la visibilité de votre marque dans les réponses IA). En e-commerce, attention : bloquer les agents de récupération live, c’est parfois bloquer un acheteur qui passe par un agent, un cas de plus en plus fréquent, détaillé dans Commerce agentique GA4 : tracker les ventes ChatGPT et AI Mode.

Ce qu’il faut poser dans le reporting mensuel

Une décision de crawl n’est pas un one-shot, elle se suit. Ajoutez trois indicateurs à votre reporting mensuel : le volume de crawl vérifié par bot, le crawl-to-refer ratio par éditeur, et la part de crawl « gaspillé » sur des pages inchangées. Branchez ça sur votre SEO existant plutôt que d’en faire un silo, dans la logique décrite dans GA4 Search Console : 5 analyses SEO. Une fois la requête stable, industrialisez : le suivi mensuel se met en pilote automatique comme n’importe quel autre rapport, voir Automatiser ses rapports avec Looker Studio et BigQuery.

Après le 15 septembre

Cet article porte une date-butoir, mais le sujet ne s’arrête pas au 15 septembre. La bascule Cloudflare n’est qu’un déclencheur : elle vous force à décider maintenant, sur une donnée que vous auriez dû regarder de toute façon. Une fois la deadline passée, la question devient permanente, parce que de nouveaux bots apparaissent chaque trimestre, les plages d’IP changent, et les ratios se déplacent. Gardez le pipeline logs vers BigQuery en place, rafraîchissez vos plages d’IP, et relisez votre matrice une fois par trimestre.

La conclusion tient en une phrase : ne laissez pas un réglage par défaut décider pour vous. Vous avez treize jours, une requête, et une matrice. Sortez vos logs, vérifiez les IP, calculez vos ratios, et tranchez bot par bot en fonction de votre modèle. C’est plus rapide à faire qu’à lire, et c’est la seule façon de bloquer les crawlers IA qui vous coûtent sans sacrifier ceux qui vous rapportent.