Fin août 2026, la société de sécurité GreyNoise a recensé 824 adresses IP réparties sur 795 réseaux distincts envoyant des requêtes se faisant passer pour GPTBot, ClaudeBot, PerplexityBot et d'autres crawlers IA. Aucune de ces adresses ne correspondait aux plages IP publiées par les entreprises réelles. Ces scanners ne collectaient pas de contenu pour une réponse IA. Ils cherchaient des fichiers .env et des identifiants AWS exposés, et plus de 263 000 des sessions falsifiées utilisaient un user agent, Google-Extended, que les crawlers de Google n'envoient jamais eux-mêmes. Pour tout site qui laisse son pare-feu ouvert aux crawlers IA afin de rester visible dans ChatGPT ou Perplexity, ce schéma de trafic pose un problème direct : la requête qui prétend être un robot de collecte de citations pourrait bien n'être ni l'un ni l'autre.
Ce que révèle le rapport de GreyNoise sur l'usurpation de crawlers d'août 2026
Le réseau de capteurs de GreyNoise a enregistré ce trafic falsifié entre le 28 juillet et le 23 août 2026, avec un pic d'activité le dernier jour de cette période. Les 824 adresses usurpaient six noms de crawlers IA appartenant à quatre entreprises, Anthropic, OpenAI, Google et Perplexity, ainsi qu'une vague distincte et plus importante de faux noms de crawlers Amazon. Chaque session demandait des chemins d'identifiants connus : /.env, /.env.production, /.aws/credentials, /.git/config. Aucun crawler IA légitime n'a de raison de demander le fichier d'environnement d'un site.
Cette spécificité est ce qui rend le schéma facile à repérer une fois qu'on sait quoi chercher. Analyser le trafic des crawlers IA dans vos logs serveur est le premier réflexe à avoir, et une requête vers un chemin d'identifiants est l'un des signaux les plus nets : un robot qui existe pour résumer ou citer votre contenu n'a pas besoin de vos secrets. La recommandation de GreyNoise est de déclencher une alerte pour toute requête vers un chemin d'identifiants, quel que soit le user agent associé, car un crawler légitime demandant /.env relève de la contradiction pure, pas d'un cas limite à débattre.
Pourquoi c'est aussi un problème de GEO, pas seulement de sécurité
De plus en plus de marques laissent leur robots.txt ouvert à GPTBot, ClaudeBot et PerplexityBot, précisément pour que leur contenu puisse être exploré et cité dans les réponses IA. Cette même porte ouverte n'a aucun moyen intégré de distinguer un vrai crawler de collecte de citations d'un scanner portant son nom, ce qui signifie que l'accès recommandé par la plupart des conseils GEO ne suffit pas, à lui seul, à écarter le mauvais trafic.
Les sites qui suivent leur ratio exploration/référencement pour juger si l'exploration par l'IA vaut la bande passante ont désormais un biais caché dans leurs données : les sessions falsifiées gonflent le côté exploration de ce ratio sans produire aucune des citations du côté référencement. Une décision entièrement distincte est de savoir s'il faut laisser entrer un véritable crawler d'entraînement ; bloquer l'entraînement de l'IA peut silencieusement vous coûter des citations ailleurs sur un domaine, mais c'est un choix de politique appliqué via une règle disallow dans le robots.txt. L'usurpation ignore purement et simplement le robots.txt, puisqu'un scanner se faisant passer pour GPTBot n'allait de toute façon jamais lire le fichier qu'il est censé respecter.
Le risque pratique joue dans les deux sens. Traiter comme fiable toute requête qui se réclame d'un crawler IA, et un site distribue des chemins d'identifiants et de la bande passante à des scanners qui n'ont rien à voir avec des citations. Traiter comme hostile toute requête non vérifiée et bloquer sur le seul user agent, et un site risque de freiner les vraies sessions GPTBot ou PerplexityBot qui auraient fait apparaître son contenu dans une réponse. C'est la vérification, et non des règles d'autorisation ou de blocage en bloc, qui fait la différence entre les deux issues.
Pourquoi « Google-Extended » dans vos logs est toujours faux
Google-Extended n'est pas un crawler. C'est un jeton d'autorisation du robots.txt qui contrôle si le contenu déjà récupéré par Googlebot peut être utilisé pour entraîner Gemini ou étayer ses réponses, et la documentation développeur de Google elle-même confirme qu'il n'a pas de user agent de requête HTTP qui lui soit propre. Toute requête arrivant avec « Google-Extended » comme user agent, y compris les 263 849 que GreyNoise a enregistrées en trois semaines, est falsifiée par définition.
Google-Extended n'a pas de crawler qui lui soit propre. Une requête arrivant avec ce user agent a déjà échoué au contrôle d'identité, car le vrai Google-Extended n'en envoie jamais.
Ce simple fait fait de Google-Extended l'usurpation la plus facile à repérer. Contrairement à GPTBot ou PerplexityBot, il n'existe aucun trafic légitime de référence dont le distinguer : chaque requête est du bruit, et GreyNoise a constaté que la plupart visaient des identifiants cloud plutôt que du contenu. Une règle de pare-feu qui rejette simplement toute requête s'identifiant comme Google-Extended ne coûte rien et ne bloque rien de réel, ce qui en fait l'un des rares cas, dans tout ce problème, où la solution ne fait aucun doute.
Comment OpenAI et Perplexity permettent de vérifier si un crawler est réel
OpenAI et Perplexity publient tous deux des listes de plages IP lisibles par machine, sur openai.com/gptbot.json et via la documentation crawler de Perplexity, de sorte qu'une requête prétendant être GPTBot ou PerplexityBot peut être vérifiée par rapport à une vraie liste d'adresses plutôt que d'être crue sur la seule base de sa chaîne user agent.
La documentation de Perplexity recommande de vérifier les deux signaux ensemble : faire correspondre le user agent à PerplexityBot, puis faire correspondre l'IP source à sa plage publiée actuelle, car chacun des deux pris isolément est trivial à falsifier. La liste d'OpenAI est horodatée et mise à jour en continu, donc un script de vérification doit la récupérer à jour plutôt que de mettre en cache une ancienne copie, le même problème que des chercheurs ont signalé sur le forum développeur d'OpenAI lorsque des propriétaires de sites ont repéré du trafic GPTBot provenant d'IP absentes de la plage publiée. Une copie obsolète de l'une ou l'autre liste est presque inutile : elle indique ce qui était vrai le mois dernier, pas ce qui frappe votre serveur en ce moment.
Pourquoi ClaudeBot est plus difficile à vérifier que les crawlers d'OpenAI ou de Perplexity
Anthropic adopte une approche différente. Sa documentation d'assistance indique que le blocage par IP de ClaudeBot « peut ne pas fonctionner de manière fiable », car le crawler tourne sur une infrastructure cloud partagée, et, contrairement à OpenAI ou Perplexity, Anthropic ne publie pas de plage IP stable permettant aux propriétaires de sites de vérifier les requêtes.
C'est un véritable compromis pour les marques qui recherchent des citations de Claude. Comment être cité par Claude AI détaille comment un accès légitime de ClaudeBot façonne ce que Claude inclut dans une réponse, mais l'absence de liste IP publique signifie qu'un site ne peut vraiment contrôler cet accès que via le respect du robots.txt, et un scanner usurpant ClaudeBot n'a aucune raison de respecter un fichier qu'il n'avait de toute façon jamais l'intention de lire. Tant qu'Anthropic ne publie pas l'équivalent des listes d'adresses d'OpenAI ou de Perplexity, l'analyse des schémas dans les logs serveur, comme des requêtes qui ne touchent jamais le robots.txt ou qui visent des chemins d'identifiants, reste le signal le plus fiable pour ClaudeBot en particulier.
La solution de Cloudflare : des requêtes de robots signées cryptographiquement
Web Bot Auth de Cloudflare, développé avec l'IETF et intégré à son programme Verified Bots en 2025, permet à un crawler de signer cryptographiquement ses requêtes HTTP afin qu'un serveur récepteur puisse confirmer son identité de façon mathématique, plutôt que de se fier à une liste IP potentiellement déjà obsolète ou à un user agent qu'il ne coûte rien de falsifier.
L'agent ChatGPT d'OpenAI a fait partie de la première cohorte à adopter les requêtes signées lorsque Cloudflare a lancé cette classification en août 2025, aux côtés d'outils d'automatisation de navigateur comme Goose et Browserbase. Les sites qui utilisent déjà la gestion des robots de Cloudflare pour éviter de bloquer par erreur des crawlers IA légitimes peuvent activer dès aujourd'hui la vérification par signature. C'est la première méthode d'identification dans ce domaine qui ne dépend pas d'une liste que quelqu'un doit penser à tenir à jour, et c'est ce qui se rapproche le plus d'une vraie solution au scénario de GreyNoise : une signature est valide ou elle ne l'est pas, sans liste IP susceptible de devenir obsolète entre les deux.
Une checklist pratique pour vérifier le trafic des crawlers IA
Aucune des vérifications ci-dessus ne nécessite de nouvel outillage. Ensemble, appliquées dans l'ordre, elles permettent de repérer le schéma documenté par GreyNoise sans obliger un site à bloquer tout robot qui se réclame du nom d'une entreprise IA.
Vérifiez l'IP source, pas seulement le user agent, par rapport aux plages publiées par OpenAI et Perplexity avant de faire confiance à une requête.
Considérez toute requête « Google-Extended » dans vos logs comme fausse. Les vrais crawlers de Google n'envoient jamais ce user agent eux-mêmes.
Signalez tout crawler IA autoproclamé qui ne demande jamais le robots.txt en premier ; les vrais crawlers le consultent avant toute autre chose.
Surveillez les requêtes vers des chemins d'identifiants comme /.env ou /.aws/credentials. Aucun crawler légitime n'en a besoin, quel que soit le nom qu'il revendique.
Lorsque votre fournisseur le permet, activez une vérification cryptographique des robots comme Web Bot Auth plutôt que de vous reposer uniquement sur des listes blanches d'IP.
Questions fréquemment posées
Comment savoir si un robot prétendant être GPTBot est vraiment OpenAI ?
Vérifiez l'IP source par rapport à la plage publiée par OpenAI sur openai.com/gptbot.json plutôt que de vous fier uniquement à la chaîne user agent, car n'importe quel scanner peut définir son user agent sur « GPTBot ». GreyNoise a recensé 824 adresses en 2026 envoyant du trafic sous des noms de crawlers IA, dont GPTBot, et aucune ne correspondait aux plages publiées par une entreprise, ce qui est exactement l'écart que cette vérification est conçue pour repérer.
Anthropic publie-t-il une plage IP pour ClaudeBot ?
Non. La documentation d'assistance d'Anthropic indique elle-même que le blocage par IP « peut ne pas fonctionner de manière fiable » pour ClaudeBot, car le crawler tourne sur une infrastructure cloud partagée qui évolue dans le temps. Les propriétaires de sites doivent donc s'appuyer principalement sur le respect du robots.txt plutôt que sur une liste d'adresses, ce qui ne fonctionne que contre les crawlers qui lisent réellement ce fichier.
Pourquoi GreyNoise a-t-il observé 263 849 fausses sessions Google-Extended ?
Parce que Google-Extended n'est pas du tout un crawler, selon la documentation développeur de Google elle-même. C'est un jeton d'autorisation du robots.txt qui régit la façon dont le contenu déjà exploré peut être utilisé, sans requêtes HTTP qui lui soient propres. Cela signifie que chaque requête arrivant avec ce user agent est falsifiée, quel que soit le volume atteint.
Que faire si je trouve du faux trafic de crawlers IA visant des chemins d'identifiants ?
Faites immédiatement tourner toutes les clés ou identifiants cloud accessibles via les chemins demandés, déplacez les fichiers .env et autres stockages d'identifiants hors de la racine web, et bloquez les adresses fautives au niveau du pare-feu. Les vrais crawlers IA, quel que soit le nom qu'ils utilisent, n'ont de toute façon aucune raison légitime de demander ces chemins.
Web Bot Auth de Cloudflare est-il la même chose que robots.txt ?
Non. Le robots.txt est un fichier texte volontaire que n'importe quel crawler peut simplement ignorer, ce qui est exactement ce qu'ont fait les usurpateurs documentés par GreyNoise tout en continuant à revendiquer des noms de crawlers IA. Web Bot Auth utilise à la place des signatures cryptographiques qu'un serveur peut vérifier mathématiquement, de sorte que l'identité ne dépend plus de ce que la requête visiteuse prétend être.