Le coût caché de la visibilité dans les moteurs IA

Nous cherchons de plus en plus à rendre les sites visibles dans ChatGPT, Claude, Perplexity, AI Mode et les autres interfaces de recherche générative.

Mais cette visibilité a une couche moins visible : avant de citer un contenu, il faut souvent venir le chercher.

Chaque crawl est une requête HTTP. Sur une page statique servie depuis un cache, son coût peut être minime. Sur une recherche interne, un filtre e-commerce, une URL de panier ou un endpoint d’APIApplication Programming Interface : contrat machine pour consommer un service (HTTP, SDK, webhooks)., le même crawl peut déclencher du PHP, des requêtes en base de données, une session ou d’autres traitements côté serveur.

À mesure que les systèmes IA multiplient les recherches, les récupérations de pages et les usages agentiques, une nouvelle question apparaît derrière le SEOSearch Engine Optimization : ensemble de pratiques pour améliorer la visibilité organique dans les moteurs de recherche. et le GEOGenerative Engine Optimization : stratégies pour apparaître dans les réponses génératives (AI Overviews, chatbots). : combien coûte la visibilité que nous essayons d’obtenir ?

Le sujet ne consiste pas à déclarer les crawlers IA indésirables. Certains sont précisément ceux qu’il faut laisser passer pour apparaître dans les réponses. L’enjeu est devenu plus fin : distinguer qui vient, pourquoi, sur quelles URLs, à quelle fréquence — et pour quelle valeur en retour.

Le problème n’est pas « le bot », mais ce qu’il demande au serveur

Le papier publié par Kinsta le 15 septembre 2026 part d’un constat simple : traiter tout le trafic automatisé comme une seule catégorie conduit à de mauvaises décisions.

Une visite de crawler sur un article public et caché n’a pas le même impact qu’une exploration agressive de paramètres dynamiques.

Kinsta donne un exemple spectaculaire issu de son infrastructure : sur une période de 24 heures, les bots ont généré 7,67 millions de requêtes vers des URLs add-to-cart, dont 3,75 millions attribuées à ClaudeBot.

Ce chiffre ne signifie pas que ClaudeBot génère systématiquement ce niveau de charge sur un site. Il agrège une observation de l’infrastructure Kinsta sur une période donnée. Mais il montre pourquoi la distinction entre « crawler légitime » et « trafic coûteux » est insuffisante.

Une URL ?add-to-cart= sur WooCommerceExtension e-commerce de référence sur WordPress (produits, panier, paiement). n’est pas une simple page d’article. Elle peut déclencher l’exécution de WordPressCMS open source dominant du web, basé sur PHP/MySQL, extensible via thèmes et plugins. et WooCommerce, des accès à la base, de la gestion de session et d’autres traitements que le cache de page ne peut pas absorber de la même manière.

Dans un autre article consacré à la charge serveur, Kinsta précise qu’un seul bot a généré ces 3,75 millions de hits en 24 heures, soit environ une requête toutes les 23 millisecondes en moyenne. L’hébergeur mentionne aussi une règle de détection de boucle ayant filtré 550 millions de requêtes en 30 jours sur sa plateforme.

Ces données viennent d’un hébergeur qui commercialise justement des outils de protection contre les bots. Il faut donc les lire comme des observations d’infrastructure Kinsta, pas comme une mesure universelle du Web.

Mais le mécanisme technique, lui, est banal : une requête automatisée peut devenir chère dès qu’elle échappe au cache ou touche un endpoint conçu pour une interaction humaine.

Le pacte historique du crawl devient plus asymétrique

Pendant des années, le compromis du Web ouvert était relativement clair.

Les moteurs de recherche exploraient les sites, construisaient leurs index, puis renvoyaient des visiteurs vers les pages trouvées.

Le crawl avait un coût, mais il faisait partie d’un échange dont la contrepartie — le trafic organique — était facile à comprendre.

Avec les plateformes IA, cet échange devient plus difficile à mesurer.

Cloudflare a créé une métrique appelée crawl-to-refer ratio : le nombre de pages HTML demandées par les crawlers d’une plateforme pour chaque page visitée par un utilisateur référé depuis cette même plateforme.

En juillet 2025, ses données mondiales donnaient environ :

• 38 066 crawls par referral pour Anthropic ;
• 1 091 pour OpenAI ;
• 195 pour Perplexity ;
• contre 5,4 pour Google sur ce même mois.

Ces écarts sont suffisamment grands pour illustrer une asymétrie, mais ils ne doivent pas devenir un classement définitif des plateformes.

Cloudflare avait signalé, dans une analyse distincte portant sur les données du 19 au 26 juin 2025, une limite importante : les applications natives de certains assistants ne transmettent pas toujours de header Referer. Des visites réelles peuvent donc ne pas être attribuées à Claude, ChatGPT ou d’autres applications natives. Nous appliquons cette réserve aux ratios de juillet comme limite méthodologique plausible, même si le billet qui publie ces ratios ne la répète pas explicitement.

Les ratios évoluent aussi rapidement dans le temps. Anthropic était par exemple à près de 287 000:1 en janvier 2025, puis autour de 38 000:1 en juillet. OpenAI oscillait autour du millier, avec de fortes variations. Perplexity restait généralement bien plus bas que ces deux acteurs.

La lecture utile n’est donc pas : « tel moteur rapporte X fois moins qu’un autre ».

Elle est plus simple : le volume de contenu récupéré et le trafic mesurable rendu aux sites peuvent être découplés de plusieurs ordres de grandeur.

Et une grande partie du crawl IA ne sert pas directement la recherche

Un autre chiffre Cloudflare change encore la lecture du problème.

Dans son bilan publié en juillet 2026, l’entreprise estime qu’en juin 2026, 52 % des requêtes de crawlers qu’elle catégorisait étaient liées à l’entraînement IA, contre 22 % au printemps 2025.

Les crawlers mixtes — combinant recherche, usages agentiques et entraînement — représentaient en parallèle plus de 36 % de l’activité.

Le crawl exclusivement destiné à la recherche ne représentait donc plus qu’une part minoritaire du trafic automatisé observé dans cette analyse.

C’est important parce que le bénéfice potentiel n’est pas le même.

Un crawler de recherche peut indexer une page afin qu’elle soit retrouvée dans une future réponse et éventuellement citée. Un agent peut charger une page en temps réel parce qu’un utilisateur lui a demandé une tâche. Un crawler d’entraînement collecte du contenu pour développer ou améliorer un modèle, sans relation immédiate avec la visibilité actuelle du site.

Mettre ces trois usages dans une même règle « AI bots : allow » ou « AI bots : block » devient donc de moins en moins pertinent.

OpenAI montre déjà pourquoi le nom de l’entreprise ne suffit pas

Le cas OpenAI illustre bien cette séparation.

Dans sa documentation destinée aux éditeurs, OpenAI demande de ne pas bloquer OAI-SearchBot si l’on veut que son contenu puisse être découvert, résumé et cité dans les résultats de recherche ChatGPT.

L’entreprise distingue ce crawler de GPTBot, utilisé pour le contenu pouvant contribuer à l’entraînement des modèles.

Autrement dit, « autoriser OpenAI » n’est pas une décision unique.

Un éditeur peut vouloir laisser passer OAI-SearchBot pour conserver la découvrabilité dans ChatGPT Search, tout en bloquant GPTBot s’il ne souhaite pas contribuer à l’entraînement.

Cette distinction répond directement au faux dilemme qui a longtemps entouré les crawlers IA : être visible ou protéger son contenu.

Les deux décisions commencent à être techniquement séparables.

Cloudflare passe lui aussi du bot à l’usage

Cloudflare a franchi la même étape en juillet 2026.

Ses contrôles distinguent désormais trois comportements :

• Search : crawlers qui indexent le contenu pour le retrouver plus tard ;
• Agent : automatisations qui agissent en temps réel pour le compte d’un utilisateur ;
• Training : collecte destinée à l’entraînement ou au fine-tuningRéentraînement partiel ou total d’un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement..

Chacune de ces catégories peut recevoir une politique différente.

Depuis le 15 septembre 2026, Cloudflare propose aux nouveaux domaines deux configurations recommandées selon que le site est monétisé par la publicité ou non. Sans publicité, Search, Training et Agent restent en Allow. Avec publicité, Search reste en Allow, Training passe en Disallow AI Training et Agent en Block on pages with ads. Ces réglages restent modifiables par le propriétaire du domaine.

Disallow AI Training combine deux mécanismes. Pour les crawlers mixtes reconnus comme « Accountable » — Googlebot, Bingbot et Applebot — Cloudflare publie une préférence dans robots.txt et les laisse passer pour la recherche. Les crawlers dédiés à l’entraînement, notamment ceux d’Amazon, Anthropic, Meta ou OpenAI, sont en revanche bloqués, sans effet sur la recherche.

Mais le nouveau modèle introduit aussi un piège SEO plus concret. Depuis le 15 septembre, les politiques Block et Block on pages with ads appliquées à la catégorie Training touchent désormais les crawlers mixtes, notamment Googlebot, Bingbot et Applebot. Choisir Block pour la catégorie Training peut donc couper l’accès de Googlebot, Bingbot et Applebot au site, recherche classique comprise. C’est exactement le type de configuration où une volonté légitime de protéger son contenu peut produire l’effet inverse de celui recherché côté SEO.

Cloudflare indique qu’Apple, Google et Microsoft respectent déjà ou se sont engagés à respecter le signal de refus d’entraînement, mais avec des calendriers différents. Microsoft ne prévoit de prendre en compte la préférence robots.txt « no training » qu’au début de 2027. D’ici là, le réglage Disallow AI Training ne transmet donc pas cette préférence à Bing ; Cloudflare renvoie vers NOARCHIVE, et éventuellement vers l’outil de blocage d’URLs de Bing Webmaster Tools si un contrôle supplémentaire est nécessaire.

Il faut donc distinguer trois choses : l’expression d’une préférence, la date à laquelle chaque opérateur la respecte et le blocage technique effectif. Un signal dans robots.txt n’empêche pas matériellement un acteur non coopératif de télécharger une page publique. Pour les usages à bloquer réellement, il faut une mesure d’enforcement au niveau réseau ou applicatif.

Le coût du crawl n’est pas le nombre de requêtes

C’est probablement le point le plus important à garder si nous voulons éviter un nouvel indicateur trompeur.

Un million de crawls ne vaut pas nécessairement cher.

Si ces requêtes sont absorbées en edge cache et servent quelques kilo-octets de HTML statique, leur coût marginal peut rester faible.

À l’inverse, quelques dizaines de milliers de requêtes vers des endpoints non cachés peuvent provoquer une vraie pression sur l’infrastructure.

Le coût dépend notamment de :

• la part des requêtes servies depuis le CDNContent Delivery Network : réseau de caches géodistribués pour servir assets et parfois HTML au plus près. ou le cache ;
• le poids des réponses ;
• l’exécution serveur nécessaire ;
• le nombre de requêtes base de données ;
• la création éventuelle de sessions ;
• les appels à des APIs tierces ;
• la concurrence avec le trafic humain sur les workers, threads ou connexions disponibles.

C’est pourquoi les métriques « bot requests » ou « crawl-to-refer » ne suffisent pas à mesurer un ROI.

Elles disent quelque chose du volume d’accès et de l’asymétrie du retour mesurable. Elles ne donnent pas directement le coût en euros d’un crawler ni la valeur économique d’une citation IA.

Toutes les pages ne méritent pas le même niveau d’accès

Une politique saine peut donc se construire à deux niveaux.

Le premier concerne l’identité et la finalité du crawler.

Le second concerne le chemin qu’il essaie de parcourir.

Même un crawler utile à la découvrabilité n’a probablement aucune raison d’explorer sans limite :

• les URLs de panier et de checkout ;
• les recherches internes ;
• certaines combinaisons de filtres ;
• les paramètres générant une infinité de variantes ;
• les endpoints administratifs ;
• certaines routes d’API sans valeur éditoriale.

À l’inverse, bloquer un crawler de recherche sur toutes les pages publiques peut réduire la capacité d’un moteur IA à découvrir les mises à jour du site.

Le bon niveau de contrôle devient donc : autoriser les contenus qui créent de la valeur de découverte, restreindre les routes qui ne devraient jamais être explorées, puis surveiller le débit réel.

C’est une logique familière pour le SEO technique, mais les crawlers IA la rendent plus importante parce que les finalités et les volumes se diversifient.

La visibilité IA doit commencer à intégrer un « crawl-to-value »

Nous avons déjà consacré plusieurs articles à la visibilité dans les moteurs génératifs : le query fan-out, les follow-up queries et l’audit de découvrabilité pour les machines.

Dans chacun de ces sujets, le moteur peut effectuer davantage de recherches et récupérer davantage de sources qu’une SERPSearch Engine Results Page : page de résultats d’un moteur (liens bleus, features, AI Overviews…). classique.

Cela rend un nouveau type de mesure intéressant : non pas seulement crawl-to-refer, mais crawl-to-value.

Ce n’est pas aujourd’hui une métrique standardisée. C’est plutôt une manière de structurer l’analyse.

Pour un crawler donné, nous pouvons essayer de rapprocher :

• le nombre de requêtes servies ;
• les endpoints touchés ;
• la charge ou le coût d’infrastructure associé ;
• les citations observées ;
• les visites référées mesurables ;
• les conversions ou actions générées ;
• et, lorsque c’est pertinent, la valeur stratégique d’une présence sans clic.

Cette dernière dimension compte. Une citation dans une réponse peut exposer une marque sans provoquer de visite immédiate. Nous ne pouvons donc pas réduire la valeur d’un moteur IA à Google Analytics.

Mais l’inverse est également vrai : la promesse de visibilité ne justifie pas automatiquement un accès illimité à toutes les ressources d’un site.

Mesurer avant de bloquer

La tentation naturelle face à une hausse brutale du trafic automatisé est de bloquer.

Mais un blocage global peut aussi supprimer des canaux de découverte utiles.

Une démarche plus robuste consiste à établir une baseline :

1. identifier les crawlers réellement présents dans les logs ;
2. mesurer leur fréquence et leurs principales URLs ;
3. distinguer les réponses cachées des traitements dynamiques ;
4. observer les pics de CPU, PHP, base de données ou temps de réponse serveur qui leur correspondent ;
5. mesurer les referrals IA lorsque c’est possible ;
6. puis ajuster progressivement les règles par bot, usage ou chemin.

Après chaque changement, il faut comparer : la charge a-t-elle baissé ? Les referrals ont-ils bougé ? Les citations ou la découvrabilité semblent-elles affectées ?

Cette approche évite deux erreurs symétriques : payer inutilement pour servir du trafic sans valeur, ou se rendre invisible en bloquant ce qui alimentait réellement la découverte.

Le SEO avait un crawl budget ; l’IA ajoute un budget de service

Le SEO connaît déjà la notion de crawl budget : combien d’URLs un moteur explore, lesquelles méritent d’être accessibles, où éviter le gaspillage.

Les moteurs IA ajoutent une autre dimension.

Le problème n’est plus seulement de savoir si le bot peut découvrir une page. Il faut aussi savoir si nous voulons payer pour la lui servir, dans quelles conditions et pour quel usage.

Sur un site éditorial largement statique, cette question peut rester marginale. Sur un gros WordPress, un WooCommerce, une marketplace, une documentation dynamique ou une application exposant de nombreux paramètres, elle peut devenir une vraie question d’architecture.

Le Web semble d’ailleurs évoluer dans cette direction : OpenAI sépare déjà recherche et entraînement par user-agent ; Cloudflare sépare Search, Agent et Training ; ses nouveaux mécanismes essaient désormais de permettre un refus de l’entraînement sans sacrifier la découvrabilité.

Le prochain enjeu SEO ne sera donc probablement pas « faut-il laisser passer les bots IA ? ».

Ce sera : quels bots, pour quel usage, sur quelles ressources et avec quelle valeur en retour ?

La visibilité reste souhaitable. Mais elle n’a jamais été gratuite : nous commençons simplement à pouvoir mesurer plus précisément qui paie la facture.