Le trafic des crawlers d'OpenAI a à peu près triplé dans les huit mois qui ont suivi le lancement de GPT-5 en août 2025, selon une analyse de Botify portant sur sept milliards d'événements de logs chez des entreprises clientes. OAI-SearchBot, qui récupère les pages pour la fonction de recherche de ChatGPT, a enregistré 3,5 fois plus de requêtes. GPTBot, qui collecte les données d'entraînement, en a enregistré 2,9 fois plus. Cette hausse se heurte à une autre tendance : des éditeurs de sites, sous une vraie pression serveur causée par les bots IA, se tournent vers des limitations de débit, voire des blocages purs et simples. Les deux tendances ne se combinent pas sans friction. Limiter le débit du mauvais bot, et un site peut perdre silencieusement les citations qu'il cherchait justement à protéger.
Dans quelle mesure le trafic des crawlers IA a-t-il vraiment augmenté
L'ensemble de données de Botify, qui couvre novembre 2024 à mars 2026 chez ses entreprises clientes, montre que le ratio recherche/entraînement des explorations d'OpenAI s'est inversé après GPT-5 : environ 0,95 avant le lancement et 1,14 après, ce qui signifie que la récupération pour la recherche génère désormais plus de requêtes que l'entraînement n'en a jamais généré. L'activité d'OAI-SearchBot a augmenté le plus vite dans la santé, en hausse d'environ 740 %, et dans les médias et l'édition, en hausse d'environ 702 %, sur un an. Malgré cette croissance, les bots d'OpenAI ne représentent toujours qu'une fraction de l'empreinte de Googlebot : sur la fenêtre de 30 jours la plus récente, Googlebot a enregistré 18,2 milliards d'événements contre 887 millions pour l'ensemble des crawlers d'OpenAI, soit environ 4 %, contre environ 1,38 % un an plus tôt, selon l'analyse des données de Botify par Search Engine Journal. Le taux de croissance compte plus que la part absolue : un crawler qui passe de négligeable à significatif en un an est exactement le type de trafic qu'une équipe technique remarque en premier, et qu'une équipe marketing remarque en second.
Pourquoi la pression sur les serveurs pousse certains sites vers le blocage pur et simple
L'équipe de recherche sur les menaces de Fastly a constaté que les crawlers IA représentaient près de 80 % du trafic des bots IA sur 6,5 billions de requêtes mensuelles entre la mi-avril et la mi-juillet 2025, Meta générant à lui seul 52 % de cette exploration, davantage que Google et OpenAI combinés.
Les bots d'OpenAI racontent une histoire différente du côté temps réel : les requêtes de type « fetcher », celles qu'un chatbot envoie en pleine conversation pour vérifier une page précise, provenaient presque entièrement d'OpenAI, à 98 % du volume de ces requêtes, avec des pics dépassant 39 000 requêtes par minute contre des sites isolés. Cette pression a déjà poussé certains acteurs vers des réponses extrêmes. Un rapport largement repris de TechCrunch décrit AmazonBot ignorant le fichier robots.txt et usurpant des adresses IP tout en mettant hors ligne, à plusieurs reprises, un serveur d'hébergement Git début 2025, ce qui a poussé le développeur Xe Iaso à créer Anubis, une porte à preuve de travail qui bloque les bots avant même qu'ils n'atteignent le serveur. Un administrateur système de Fedora a bloqué un pays entier, le Brésil, après que des bots similaires n'ont pas non plus respecté les défenses habituelles. Mesurer si le trafic d'un bot justifie cette pression, c'est justement l'objet du ratio exploration/référencement : il compare la fréquence à laquelle un bot explore un site à la fréquence à laquelle il lui renvoie un visiteur humain, et un chiffre très déséquilibré est souvent le premier signe qu'un bot mérite d'être examiné avant d'être bloqué.
On ne peut pas sécuriser ce qu'on ne voit pas, et sans normes de vérification claires, les risques liés à l'automatisation par l'IA deviennent un angle mort pour les équipes techniques, a déclaré Arun Kumar, chercheur senior en sécurité chez Fastly.
Tous les bots d'OpenAI n'ont pas le même rôle, et les traiter de façon identique est l'erreur à éviter
GPTBot, OAI-SearchBot et ChatGPT-User sont trois bots distincts avec trois rôles distincts, et la documentation développeur d'OpenAI les traite comme des interrupteurs indépendants plutôt que comme un seul réglage. Limiter le débit des trois de façon identique risque de freiner le bot responsable des citations tout en laissant intact celui qui ne fait qu'alimenter l'entraînement des modèles.
GPTBot collecte du contenu susceptible d'entraîner les futurs modèles, et le désactiver retire un site de l'entraînement sans toucher du tout à sa visibilité dans la recherche, selon les propres consignes d'OpenAI. OAI-SearchBot, lui, détermine si une page peut apparaître dans les réponses de recherche de ChatGPT, donc le bloquer retire un site des citations même si GPTBot reste actif. ChatGPT-User est encore différent : il ne se déclenche que lorsqu'une personne demande à ChatGPT de visiter une page précise en pleine conversation, et OpenAI indique qu'il n'est pas régi par robots.txt de la même façon que les deux autres bots, puisque la requête est initiée par l'utilisateur et non par une exploration automatisée. Nous avons déjà abordé le volet entraînement de cette distinction : désactiver GPTBot pour l'entraînement ne bloque pas les citations en direct de ChatGPT, parce qu'OAI-SearchBot continue de fonctionner quoi qu'il arrive à GPTBot. L'erreur inverse, limiter le débit des trois bots au niveau du serveur ou du CDN parce que l'un d'eux fait grimper le trafic, produit l'effet opposé. Elle peut étouffer les requêtes de récupération en direct d'OAI-SearchBot en même temps que l'exploration d'entraînement de GPTBot, ce qui est exactement la combinaison qui coûte des citations.
Pourquoi crawl-delay et les limitations de débit globales ne fonctionnent pas comme on l'espère
Crawl-delay, la directive de robots.txt vers laquelle de nombreux éditeurs de sites se tournent en premier, ne fait pas partie de la norme formelle qui régit robots.txt, et rien n'oblige un crawler IA à la respecter. La RFC 9309, la norme de l'IETF publiée en 2022, a volontairement laissé crawl-delay de côté, faute de comportement réel suffisamment cohérent pour justifier une codification.
Robots.txt se retrouve donc à jouer le rôle que la norme elle-même qualifie de recommandation indicative, et non de mécanisme de contrôle d'accès. Un crawler bien élevé lit les lignes Disallow et s'y conforme, tandis qu'un crawler qui ignore totalement le fichier, ce que plusieurs crawlers IA ont été documentés en train de faire, ne subit aucune pénalité pour autant. Une limitation de débit stricte, appliquée au niveau du serveur ou du CDN, est plus fiable qu'une simple demande polie dans un fichier texte, mais elle reste un instrument grossier : une règle écrite contre une chaîne de user agent ou une plage d'IP a tendance à toucher tous les bots portant cette identité, qu'il s'agisse du crawler d'entraînement dont personne n'a un besoin urgent ou du bot de recherche auprès duquel une page essaie activement de se faire citer. Nous avons déjà vu ce qui se passe quand les réglages par défaut d'un CDN bloquent les crawlers IA sans que personne ne l'ait voulu ; le même problème d'instrument grossier s'applique aux limitations de débit mises en place dans l'urgence pendant un pic de trafic. Il vaut la peine de lire ce que robots.txt bloque réellement pour chaque grand bot IA avant d'écrire la moindre ligne Disallow.
Une approche pratique : vérifier le bot, puis limiter le débit selon sa fonction
La solution n'est pas de choisir entre un accès illimité et un blocage total. C'est de vérifier quel bot fait réellement la requête, puis de fixer des limites adaptées à ce que ce bot fait, et non à ce qu'il prétend être.
Commencez par les logs, pas par le fichier robots.txt : analyser le trafic des crawlers IA dans les logs serveur montre quels bots frappent le plus fort un site, et quand, ce qui est la seule façon de savoir si GPTBot, OAI-SearchBot, ou quelque chose qui usurpe l'un des deux, est à l'origine d'un pic. Les chaînes de user agent sont triviales à falsifier, donc il vaut mieux comparer les requêtes aux plages d'IP publiées par les fournisseurs. Une part croissante du trafic arrivant sur les sites sous le nom d'un bot familier s'avère être de faux crawlers usurpant les vrais, et limiter le débit d'un bot de recherche vérifié pendant qu'un bot usurpé passe sans encombre annule complètement l'intérêt de la démarche. Une fois le trafic vérifié, les limites peuvent être délibérément asymétriques : freiner ou mettre en cache fortement les crawlers purement dédiés à l'entraînement, puisque ce que produit GPTBot n'a aucune échéance, et laisser plus de marge à OAI-SearchBot et aux bots similaires qui récupèrent à la demande, dont les requêtes disparaissent généralement en quelques secondes, le temps de répondre à la question qui les a déclenchées.
Questions fréquemment posées
Quelle est la différence entre GPTBot et OAI-SearchBot ?
GPTBot explore le contenu qu'OpenAI peut utiliser pour entraîner ses futurs modèles, et le désactiver retire un site de l'entraînement uniquement. OAI-SearchBot récupère le contenu pour que la fonction de recherche de ChatGPT puisse trouver et citer une page en temps réel. La documentation développeur d'OpenAI traite les deux comme des réglages indépendants, donc un site peut bloquer GPTBot pour l'entraînement tout en laissant OAI-SearchBot actif pour les citations, ou l'inverse.
Crawl-delay dans robots.txt ralentit-il vraiment les crawlers IA ?
Pas de façon fiable. Crawl-delay a volontairement été écarté de la RFC 9309, la norme de l'IETF qui a formalisé robots.txt en 2022, faute de comportement suffisamment cohérent à normaliser. Plusieurs crawlers IA ont été documentés ignorant totalement les directives de robots.txt, si bien qu'une ligne crawl-delay fonctionne comme une demande polie plutôt que comme une limite exécutoire.
La limitation de débit des bots IA va-t-elle nuire à ma visibilité sur ChatGPT ou Perplexity ?
Cela dépend du bot que vous limitez. Limiter un crawler purement dédié à l'entraînement comme GPTBot n'a aucun effet sur le fait que ChatGPT cite ou non une page, puisque les citations viennent d'OAI-SearchBot et des bots de récupération en temps réel similaires. Limiter ces bots de récupération sans distinction, surtout pendant la courte fenêtre qui suit une question posée par un utilisateur, risque de provoquer des délais d'attente qui excluent une page de la réponse.
Comment distinguer un vrai crawler IA d'un faux avant de limiter son débit ?
Comparez l'adresse IP de la requête aux plages publiées par chaque fournisseur, car les chaînes de user agent seules sont faciles à falsifier. OpenAI et d'autres fournisseurs publient des listes d'IP à jour, et vérifier les logs serveur par rapport à ces plages, plutôt qu'à l'en-tête user agent, reste le moyen le plus fiable de confirmer qu'une requête provient réellement du bot qu'elle prétend être.
Pourquoi certains sites bloquent-ils entièrement les crawlers IA, y compris par pays ?
La pression sur les serveurs, pas une stratégie de citation. Un rapport de TechCrunch de 2025 décrivait des crawlers IA agressifs poussant des mainteneurs de projets open source vers des mesures radicales, dont un administrateur système de Fedora qui a bloqué tout le Brésil, après que des défenses classiques comme robots.txt et le blocage par user agent ont échoué face à des bots usurpant leur identité et changeant d'adresse IP.