Comment vérifier les robots d'exploration et agents IA par IP : DNS inverse, plages CIDR et Web Bot Auth

Vous voyez GPTBot, ClaudeBot ou PerplexityBot dans vos journaux et vous devez trancher : l'autoriser, limiter son débit ou le bloquer. Mais avant tout cela, vous devez répondre à une question plus élémentaire : s'agit-il vraiment de ce bot ? Car un en-tête User-Agent est une affirmation, pas une preuve. N'importe qui peut exécuter curl -A "GPTBot/1.3" https://your-site.com, et vos journaux enregistreront consciencieusement « GPTBot ».

Ce n'est pas théorique. L'équipe Satori de HUMAN Security a constaté que 5,7 % de tout le trafic se présentant comme un robot d'exploration IA connu était usurpé, avec un pic à 7,7 % certains jours (~2 millions de requêtes par jour), l'agent ChatGPT-User étant usurpé dans environ une requête sur six. Ce guide couvre les trois vraies façons de vérifier un robot d'exploration au niveau de l'IP et de la cryptographie (DNS inverse confirmé par résolution directe, listes d'autorisation CIDR publiées par les opérateurs et Web Bot Auth), ainsi que les modes de défaillance qui piègent presque tous les autres guides.

Pourquoi un User-Agent « GPTBot » ne prouve rien

Le User-Agent est une métadonnée autodéclarée. Il ne contient aucune authentification, rien de signé, rien qu'un serveur d'origine puisse vérifier. Vérifier un robot d'exploration consiste à rattacher la requête à une infrastructure ou à une clé que l'opérateur contrôle réellement. Il existe exactement trois régimes qui le permettent :

1. DNS inverse confirmé par résolution directe (FCrDNS) : prouver que l'IP se résout vers et depuis le domaine de l'opérateur.
2. Listes d'autorisation CIDR publiées : comparer l'IP aux plages publiées par l'opérateur.
3. Web Bot Auth (RFC 9421) : vérifier une signature cryptographique portée par la requête elle-même.

Tout ce qui suit explique comment appliquer correctement ces méthodes, et ce que chacune peut et ne peut pas prouver.

Les enjeux en 2026 : les bots sont majoritaires sur le web

La vérification des robots d'exploration a cessé d'être une niche SEO au moment où le trafic automatisé est devenu l'essentiel d'Internet. Le Bad Bot Report 2026 d'Imperva a constaté que le trafic automatisé représentait 53 % du trafic web observé en 2025, et que les bots malveillants à eux seuls en représentaient 40 %. Lorsque la plupart des requêtes sont automatisées et que le volume des robots d'exploration IA ne cesse de croître, la question « ce bot est-il authentique ? » se pose sur vos endpoints de connexion, d'inscription et de paiement, et pas seulement dans votre robots.txt. Au paiement, c'est désormais aussi une question de fraude : voyez comment arrêter la fraude des agents d'achat IA sans bloquer les vraies ventes réalisées par des agents. Pour savoir quel signal IP répond à quelle question sur les bots, des plages de robots d'exploration aux indicateurs de scanners, consultez notre page de référence sur la détection des bots par IP.

Méthode 1 : le DNS inverse confirmé par résolution directe, bien appliqué

Le FCrDNS est la méthode de référence que Google documente pour vérifier Googlebot. Quatre étapes :

Pourquoi l'étape directe est indispensable : un attaquant contrôle l'enregistrement inverse (PTR) de sa propre IP ; il peut donc faire pointer 1.2.3.4 vers crawl-fake.googlebot.com. Ce qu'il ne peut pas faire, c'est falsifier le DNS direct faisant autorité de googlebot.com pour que ce nom d'hôte renvoie vers 1.2.3.4. Une vérification qui se contente de chercher « googlebot.com » dans la chaîne de l'enregistrement PTR (ce que suggèrent un nombre étonnant de tutoriels) est elle-même contournable. La confirmation directe est tout l'intérêt de la méthode. Pour Google en particulier, avec ses trois types de robots d'exploration et leurs fichiers de plages distincts, consultez notre guide pour vérifier Googlebot par IP et repérer les faux Googlebots.

La limite de précision à signaler : les enregistrements PTR sont facultatifs et souvent absents, en particulier chez les fournisseurs d'IA les plus récents. En l'absence de PTR, le FCrDNS renvoie « invérifiable », ce qui n'est ni un succès ni un échec. C'est là qu'intervient la méthode 2.

Méthode 2 : les listes d'autorisation CIDR publiées, bot par bot

La plupart des fournisseurs d'IA se passent d'enregistrements PTR et publient plutôt les plages IP de leurs robots d'exploration au format JSON. C'est la vérification la plus pratique sur le plan opérationnel. Récupérez le flux de source primaire de chaque opérateur :

• OpenAI : un fichier par bot : openai.com/gptbot.json, openai.com/searchbot.json, openai.com/chatgpt-user.json (documentation des robots d'exploration d'OpenAI).
• Google : cinq fichiers CIDR sous developers.google.com/static/crawling/ipranges/.
• Anthropic : publie un seul fichier pour ses bots, claude.com/crawling/bots.json, accessible depuis sa page d'aide sur les robots d'exploration. La liste d'adresses de sa documentation plateforme concerne l'API, pas les robots d'exploration.
• Perplexity : perplexitybot.json et perplexity-user.json.
• Apple iCloud Private Relay : un CSV des sorties à mask-api.icloud.com/egress-ip-ranges.csv (documentation Apple). Attention : il s'agit d'humains sur un relais de confidentialité, pas de bots. Autorisez-les ; ne les bloquez pas.

Nous chargeons 19 fichiers de plages de robots d'exploration provenant de 10 opérateurs ; la liste des IP de robots d'exploration vérifiés les recense tous, avec leur date et la façon de construire la liste d'autorisation.

Trois règles distinguent une mise en œuvre correcte d'une mise en œuvre défaillante :

• Associez chaque bot aux fichiers de son opérateur, et à son propre fichier uniquement lorsque l'opérateur en publie un par bot. GPTBot se trouve dans gptbot.json, pas dans « une plage OpenAI quelconque », et utiliser le mauvais fichier OpenAI revient à confondre un robot d'exploration d'entraînement avec un outil de récupération déclenché par l'utilisateur. Anthropic publie un seul fichier partagé pour ses trois bots, et les deux fichiers de DuckDuckGo sont identiques : dans ces cas, l'opérateur est la correspondance la plus précise disponible. Notre comparaison GPTBot vs OAI-SearchBot vs ChatGPT-User montre ce que fait chaque bot d'OpenAI, ce que coûte son blocage, et une requête réelle pour chaque fichier.
• Comparez avec le préfixe exact publié, jamais avec l'ASN d'hébergement. Autoriser « tout AWS » ou « tout Google Cloud » parce qu'un bot s'y exécute laissera passer tous les attaquants hébergés sur le même cloud.
• Actualisez selon un calendrier régulier. Ces plages changent ; traitez-les comme un flux, pas comme une constante.

Asymétrie entre fournisseurs : quelle méthode existe réellement

La plupart des guides mettent tous les fournisseurs dans le même sac. Ils diffèrent pourtant, à la fois par la méthode de vérification disponible et par les jetons de robots d'exploration que chacun utilise, qui ont des implications différentes en matière de politique :

La nuance qui fait échouer les pipelines naïfs : les outils de récupération déclenchés par l'utilisateur se comportent comme de vrais visiteurs et peuvent légitimement provenir de l'extérieur des plages de bots publiées. Lorsqu'un utilisateur demande à un assistant d'ouvrir une URL précise, cette récupération peut provenir d'une infrastructure cloud générique avec un User-Agent de navigateur normal. Bloquer « ce qui n'est pas dans la plage GPTBot » peut donc bloquer l'action d'agent d'un vrai utilisateur. Les politiques de limitation de débit et de blocage doivent différer par jeton, et non par fournisseur.

Vérifier les robots d'exploration SEO et analytiques : AhrefsBot et consorts

Les deux mêmes méthodes au niveau de l'IP permettent de vérifier les robots d'exploration SEO et analytiques que l'on cherche le plus souvent à identifier dans ses journaux : AhrefsBot, et ses pairs comme SemrushBot et DataForSeoBot. Ce ne sont pas des robots d'exploration IA, mais la vérification est identique :

• AhrefsBot est vérifiable par DNS inverse confirmé par résolution directe (ses adresses se résolvent en noms d'hôtes sous les propres domaines d'Ahrefs), et Ahrefs publie les plages IP de son robot d'exploration pour permettre leur autorisation. Appliquez la même vérification FCrDNS que dans la méthode 1, ou comparez avec la liste publiée comme dans la méthode 2.
• Le piège est celui qui guette aussi les robots d'exploration IA : n'autorisez pas par ASN. Un « AhrefsBot » arrivant depuis une plage d'hébergement quelconque que vous n'avez jamais vérifiée correspond exactement au schéma d'usurpation, puisque n'importe qui peut envoyer User-Agent: AhrefsBot/7.0. Confirmez l'IP, pas la chaîne.

Si vous cherchez les « adresses IP d'AhrefsBot » pour construire une règle de pare-feu, la version durable est une vérification par DNS inverse confirmé par résolution directe associée à la plage publiée par l'opérateur, actualisée selon un calendrier régulier, et non une liste d'IP codée en dur qui se périme dès que le robot d'exploration ajoute de la capacité.

Méthode 3 : Web Bot Auth et la vérification cryptographique

La solution structurelle à l'usurpation consiste à cesser de faire confiance à la position réseau et à vérifier plutôt une signature. Avec Web Bot Auth, l'agent signe chaque requête avec une clé Ed25519 en utilisant les HTTP Message Signatures de la RFC 9421 (une Proposed Standard, février 2024). La requête contient :

• Signature : la valeur de la signature
• Signature-Input : les composants couverts, created/expires, keyid et tag="web-bot-auth"
• Signature-Agent : facultatif, nomme l'agent signataire

Les clés sont découvertes sous forme de JWKS à /.well-known/http-message-signatures-directory (en s'appuyant sur le mécanisme d'URI « well-known » de la RFC 8615). La vérification : récupérer l'annuaire, faire correspondre l'empreinte keyid, vérifier la signature et la fenêtre created/expires. L'avantage par rapport aux méthodes fondées sur l'IP est décisif : elle résiste aux adresses partagées, tournantes et CGNAT, car l'identité voyage avec la requête, et non avec la route.

Retour à la réalité : c'est expérimental, pas un standard

Soyez honnête avec votre architecture sur ce point. Web Bot Auth est spécifié dans des Internet-Drafts de l'IETF (draft-meunier-web-bot-auth-architecture, 2 mars 2026, auteurs de Cloudflare et de Google) qui portent la mention standard « not endorsed by the IETF and has no formal standing » (non approuvé par l'IETF et sans statut formel) et expirent le 3 septembre 2026. Le support de Google lui-même est explicitement expérimental. Google indique qu'il « ne signe pas encore toutes les requêtes » et demande aux opérateurs de continuer à utiliser la vérification par IP, par DNS inverse et par User-Agent. Au niveau de l'infrastructure, les choses sont plus avancées : Cloudflare a intégré les Message Signatures à son Verified Bots Program (juillet 2025) et AWS WAF en a ajouté la prise en charge (novembre 2025). Verdict : privilégiez les signatures lorsqu'elles sont présentes, mais n'en dépendez pas encore.

Le pipeline de décision en couches (à copier)

Combinez les trois méthodes selon un ordre de priorité, puis enrichissez et classez. Une fois un bot vérifié, décidez quoi faire de chaque robot d'exploration IA vérifié à l'aide de la politique à trois niveaux décrite dans ce guide :

L'étape 5 est celle où GeoIPHub trouve sa place : lorsque l'IP d'un bot autodéclaré ne figure dans aucune plage publiée et n'a pas de PTR, le propriétaire de l'ASN, l'indicateur d'hébergement/datacenter, les indicateurs VPN, proxy et Tor et un score de risque sont ce qui vous permet d'évaluer les cas non concluants à la connexion, à l'inscription et au paiement au lieu de deviner. Si vous limitez le débit de la catégorie « déclaré mais non vérifié », indexez les sources IPv6 sur le préfixe plutôt que sur l'adresse ; notre guide sur la limitation de débit et le blocage IPv6 par préfixe /64 explique pourquoi.

Même ASN Google, un Googlebot vérifié et un autre non

Deux adresses du même réseau Google obtiennent des verdicts opposés en tant que robots d'exploration, car la vérification utilise le préfixe publié, et non l'ASN. Nous avons interrogé deux IP Google le 5 octobre 2026 (les résultats évoluent à mesure que les plages changent) : 192.178.4.0, la première adresse du premier préfixe IPv4 du fichier de plages Googlebot publié par Google, et 8.8.8.8, Google Public DNS.

Les deux se trouvent dans l'AS15169 et toutes deux relèvent de l'hébergement : une liste d'autorisation par ASN les traiterait donc de la même façon. Seule la première figure dans le fichier Googlebot, et threat.crawler.verification_method: "ip_range_list" montre que le verdict provient de la méthode 2. Le signal verified_crawler ramène son fraud_score à 0, tandis que 8.8.8.8 conserve le score de datacenter ordinaire de 15. La méthode no_ptr_datacenter se déclenche sur les deux, car notre enregistrement ne contient aucun PTR pour elles, alors qu'un dig -x 192.178.4.0 en direct renvoie crawl-192-178-4-0.googlebot.com. C'est un petit exemple réel de la raison pour laquelle la vérification par plage est celle qu'il faut automatiser : elle ne dépend pas de la réussite d'une résolution PTR.

Modes de défaillance et faux positifs

Voici ce que les articles les mieux classés comprennent mal :

• Hors plage ≠ faux. Le cas Perplexity (Cloudflare, août 2025) a montré un robot d'exploration utilisant un UA Chrome générique, des IP hors de sa plage publiée et des ASN tournants, à raison de 3 à 6 millions de requêtes par jour. Être dans la plage est un vrai positif ; être hors plage est non concluant, et non une preuve d'usurpation.
• Biais géographique du CGNAT. Des recherches de Cloudflare fin 2025 (rapportées par The Register) ont montré que les IP CGNAT subissaient une limitation de débit ~3 fois plus souvent alors qu'elles présentaient moins de signaux de bots. Des centaines d'utilisateurs partagent une même IPv4, de façon concentrée en Afrique et en Asie. Le blocage naïf par IP pose un problème d'équité.
• iCloud Private Relay. Des IP de sortie partagées et tournantes qui transportent de vrais humains ; autorisez-les à l'aide du CSV d'Apple.
• Proxys résidentiels. Ils mettent complètement en échec les listes d'autorisation par ASN (le rapport 2025 d'Imperva a constaté que 21 % des attaques de bots les utilisaient), et c'est précisément pourquoi détecter le trafic anonymisé sans bloquer de vrais clients est un problème comportemental, pas une simple consultation de liste.

La règle : réservez les blocages stricts au comportement associé à la provenance, jamais à la seule absence d'une liste.

Les bots vérifiés relèvent du GIVT, les bots usurpés du SIVT

Dans la taxonomie du Media Rating Council, les robots d'exploration déclarés et les IP de datacenter connues relèvent du General Invalid Traffic (GIVT, trafic invalide général), filtrable par des listes, tandis que les bots « se faisant passer pour des utilisateurs légitimes » relèvent du Sophisticated Invalid Traffic (SIVT, trafic invalide sophistiqué), qui exige analyse et examen. Vérifier un robot d'exploration par IP est précisément ce qui fait passer une requête de la seconde catégorie à la première. Les listes complètes des catégories, les neuf catégories propres à Google et celles qu'une requête IP peut voir figurent dans GIVT vs SIVT : les catégories de trafic invalide de Google.

Vérifiez les robots d'exploration et agents IA avec GeoIPHub

GeoIPHub fournit l'enrichissement de l'étape 5 que les acteurs historiques de la géo-IP omettent dans leurs contenus pratiques : ASN et type de connexion, détection d'hébergement/datacenter, indicateurs VPN / proxy / Tor, indicateurs de robots d'exploration vérifiés issus de 19 flux de plages officiels (dont GPTBot, ClaudeBot, PerplexityBot et AhrefsBot), et un score de risque de fraude IP. Nous ne détectons pas les proxys résidentiels ; ils nécessitent des signaux comportementaux. Vous pouvez ainsi confirmer qu'un bot autodéclaré provient réellement de l'infrastructure du fournisseur, et évaluer les cas non concluants au lieu de les bloquer aveuglément. Associez-le aux méthodes de vérification ci-dessus et aux guides connexes sur la détection de prise de contrôle de compte et de credential stuffing et sur la précision réelle de la géolocalisation IP.

FAQ

Comment vérifier qu'une requête provient réellement de GPTBot et n'est pas usurpée ?

Ne vous fiez pas à l'en-tête User-Agent : il se falsifie trivialement. Comparez l'IP source au fichier de plages publié par OpenAI pour chaque bot (openai.com/gptbot.json), en restreignant la vérification à GPTBot précisément plutôt qu'à une plage OpenAI générique. Si une signature Web Bot Auth valide est présente, vérifiez-la d'abord dans l'annuaire de clés d'OpenAI, car elle ne dépend pas de l'IP. Considérez une IP absente de la plage publiée comme non concluante, et non comme une preuve d'usurpation, car le trafic d'agents déclenché par un utilisateur peut provenir d'une autre infrastructure. Notre comparaison GPTBot vs OAI-SearchBot vs ChatGPT-User montre une requête réelle pour chaque fichier de plages d'OpenAI.

Qu'est-ce que le DNS inverse confirmé par résolution directe (FCrDNS) ?

Le FCrDNS est une vérification en quatre étapes : résoudre l'IP source en nom d'hôte par DNS inverse, confirmer que le nom d'hôte se termine par le domaine de l'opérateur, résoudre ce nom d'hôte par DNS direct, puis confirmer qu'il renvoie bien à l'IP d'origine. C'est l'étape directe qui déjoue l'usurpation : un attaquant peut définir un faux enregistrement PTR sur sa propre IP, mais il ne peut pas falsifier le DNS direct faisant autorité de l'opérateur. Une vérification qui n'inspecte que la chaîne PTR est contournable.

Pourquoi ne puis-je pas simplement bloquer les robots d'exploration IA par leur chaîne User-Agent ?

Parce que le User-Agent est une affirmation que n'importe qui peut envoyer. HUMAN Security a constaté que 5,7 % de tout le trafic étiqueté comme provenant d'un robot d'exploration IA connu était faux, avec un pic proche d'une requête sur six pour l'agent ChatGPT-User. Bloquer sur la seule base de l'en-tête laisse passer les bots usurpés tout en ne faisant rien contre un opérateur qui cesse simplement de se déclarer.

Qu'est-ce que Web Bot Auth, et s'agit-il d'un standard finalisé ?

Web Bot Auth est une méthode émergente dans laquelle un bot signe cryptographiquement chaque requête HTTP avec une clé Ed25519 en utilisant les HTTP Message Signatures de la RFC 9421, et le serveur d'origine la vérifie à l'aide des clés publiées à /.well-known/http-message-signatures-directory. La RFC 9421 elle-même est une Proposed Standard (février 2024), mais Web Bot Auth reste un Internet-Draft de l'IETF sans statut formel à la mi-2026. Considérez-le comme expérimental : vérifiez les signatures lorsqu'elles sont présentes, mais conservez la vérification par IP et par DNS inverse comme base.

Où les fournisseurs d'IA publient-ils les plages IP de leurs robots d'exploration ?

OpenAI publie un fichier JSON par bot à openai.com/gptbot.json, searchbot.json et chatgpt-user.json ; Google publie des fichiers JSON de CIDR sous developers.google.com/static/crawling/ipranges/ ; Anthropic publie un seul fichier pour ses bots à claude.com/crawling/bots.json ; Perplexity publie perplexitybot.json et perplexity-user.json. Restreignez chaque vérification au fichier du bot concerné, comparez avec les préfixes exacts publiés plutôt qu'avec l'ASN d'hébergement, et actualisez les fichiers selon un calendrier régulier. Pour les trois fichiers d'OpenAI et leur nombre actuel de préfixes, consultez les plages IP de GPTBot, OAI-SearchBot et ChatGPT-User.

Si une IP ne figure pas dans la plage publiée par le fournisseur, cela signifie-t-il que la requête est fausse ?

Non. Une IP dans la plage, un FCrDNS réussi ou une signature valide constituent un vrai positif à haut niveau de confiance, mais une IP hors plage est non concluante. Il peut s'agir de trafic d'agent légitime déclenché par un utilisateur depuis une autre infrastructure, d'une adresse partagée en CGNAT, d'une sortie iCloud Private Relay, d'un fournisseur qui ne publie aucun enregistrement PTR ou d'un fichier de plages obsolète de votre côté. Réservez les blocages stricts aux signaux de comportement et de provenance, et non à la seule absence d'une liste.

Bloquer les plages IP des robots d'exploration n'affectera-t-il pas de vrais utilisateurs sur des adresses partagées ?

Si, et c'est pourquoi l'absence d'une IP dans une liste ne doit pas déclencher de blocage strict. Des recherches de Cloudflare fin 2025 ont montré que les adresses CGNAT subissaient une limitation de débit environ trois fois plus souvent que les autres, alors qu'elles présentaient moins d'indicateurs de bots, car des centaines voire des milliers d'utilisateurs partagent une même adresse IPv4 ; et le CGNAT étant concentré dans certaines régions d'Afrique et d'Asie, cela crée un biais géographique. Les IP de sortie d'iCloud Private Relay transportent elles aussi de vrais humains et doivent être autorisées à l'aide du CSV publié par Apple.