Aller au contenu
Vrai ou faux GPTBot ? Vérifier un crawler IA en 2026

Vrai ou faux GPTBot ? Vérifier un crawler IA en 2026

Par Lucas M.

10 min de lecture
Lien copié dans le presse-papiers
Lucas M.

Ouvrez un terminal, tapez curl -A "compatible; GPTBot/1.4; +https://openai.com/gptbot" https://votresite.fr, et votre log serveur enregistrera une visite de GPTBot. Sauf qu'OpenAI n'a rien demandé. Le user-agent est une chaîne de caractères que le client envoie lui-même, personne ne la signe, personne ne la contrôle. C'est exactement le problème du dev qui fait confiance aux données venues du client : ça marche jusqu'au jour où quelqu'un a envie de tricher.

Un user-agent ne prouve rien. La seule vérification qui tient est l'adresse IP source : on la compare aux fichiers JSON de plages publiés par chaque opérateur, récupérés en direct. Google et Common Crawl acceptent en plus un contrôle par DNS inverse. OpenAI, Anthropic et Perplexity, non : chez eux, l'adresse IP est le seul point d'appui.

Pourquoi le user-agent est la mauvaise preuve#

Dans un jeu multijoueur, on ne demande jamais au client combien de points de vie il lui reste. Il mentirait. Le serveur garde l'autorité, le client n'envoie que des intentions. Le web des crawlers fonctionne selon le même principe, sauf que beaucoup d'administrateurs raisonnent encore comme si le user-agent faisait foi.

Or il déclare deux choses distinctes qu'on confond en permanence : qui crawle, et pourquoi. Chez OpenAI, GPTBot collecte pour l'entraînement des modèles et respecte robots.txt, tandis que ChatGPT-User exécute une action déclenchée par un humain. La documentation d'OpenAI le dit sans détour à propos de ce dernier : « these actions are initiated by a user, robots.txt rules may not apply ». Même entreprise, même infrastructure, comportement inverse face à vos directives. OAI-SearchBot, lui, respecte l'opt-out pour les résultats de recherche.

Conclusion pratique : raisonner par entreprise ne mène nulle part, il faut raisonner par user-agent. Et comme cette chaîne se falsifie en une ligne de commande, il faut ensuite la confronter à quelque chose que l'attaquant ne contrôle pas.

Ce que chaque opérateur publie réellement#

J'ai récupéré les fichiers officiels un par un plutôt que de recopier un tableau trouvé ailleurs. Voici l'état au 28 juillet 2026.

CrawlerFichier d'adresses IPDNS inverse documentérobots.txt
GPTBot (entraînement)openai.com/gptbot.json, 21 blocs CIDR IPv4, mise à jour du 30 octobre 2025NonRespecté
ChatGPT-User (action utilisateur)openai.com/chatgpt-user.json, 373 blocs CIDR, mise à jour du 23 juillet 2026NonPeut ne pas s'appliquer, action initiée par un utilisateur
OAI-SearchBot (recherche)openai.com/searchbot.json, 35 blocs CIDR, mise à jour du 2 janvier 2026NonRespecté, opt-out des résultats de recherche
ClaudeBot, Claude-User, Claude-SearchBotclaude.com/crawling/bots.json, fichier unique commun aux trois, 20 entrées, mise à jour du 1er mai 2026NonRespecté, extension Crawl-delay supportée
Googlebot (et le jeton Google-Extended)Vérification officielle fondée sur le DNS, colonne suivanteOui, en deux tempsRespecté
PerplexityBotwww.perplexity.ai/perplexitybot.json, 8 entrées seulement, mise à jour du 7 février 2025NonRespecté
Perplexity-UserUn fichier dédié est cité dans la documentation, non récupéré lors de cette vérificationNonGénéralement ignoré, action utilisateur
CCBot (Common Crawl)index.commoncrawl.org/ccbot.json, IPv4 et IPv6Oui, IPv4 uniquementRespecté

Deux détails de ce tableau méritent qu'on s'y arrête.

Le fichier d'Anthropic est unique et partagé. Sa structure se résume à une clé creationTime et une liste prefixes, sans aucun champ nommant l'agent. Un bloc en /22 sur 216.73.216.0/22, dix-neuf adresses individuelles en /32 sur des plages 34.x, 35.x et 136.x, et c'est tout. Conséquence directe : l'adresse IP vous dit qu'une requête vient bien d'Anthropic, jamais lequel des trois bots l'a émise. Pour ça, vous n'avez que le user-agent, celui-là même qui ne prouve rien. La chaîne de preuve se coupe à cet endroit précis, et aucune bidouille serveur ne la recolle.

Second détail, les dates. Le fichier de GPTBot date d'octobre 2025, celui de ChatGPT-User de juillet 2026, celui de PerplexityBot de février 2025. Ces listes bougent à des rythmes complètement différents, et l'écart de volume est du même ordre : 8 entrées chez Perplexity contre 373 chez ChatGPT-User. Toute personne qui colle ces plages en dur dans une conf nginx signe une régression à retardement.

Google-Extended n'est pas un crawler, arrêtez de chercher ses IP#

C'est l'erreur que je vois passer le plus souvent, et elle fait perdre des heures. Google-Extended n'a ni plages d'adresses, ni user-agent, ni DNS propre. C'est un jeton lu dans robots.txt par l'infrastructure de crawl existante de Google, qui contrôle si votre contenu sert à entraîner les modèles Gemini et les API génératives de Vertex AI. Google le présente comme un contrôle laissé à l'administrateur du site, pas comme un robot supplémentaire.

Donc : vous ne verrez jamais Google-Extended dans vos logs, et vous ne trouverez jamais sa liste d'adresses, parce qu'elle n'existe pas. La requête qui arrive, c'est Googlebot, et c'est Googlebot qu'on vérifie. Le jeton agit en amont, sur l'usage du contenu, pas sur la connexion.

La procédure, étape par étape#

Voilà ce que je mets en place. Rien d'exotique, mais l'ordre compte.

1. Extrayez le couple user-agent, adresse IP de vos logs. Pas le user-agent seul. Une ligne de log sans son IP source est inexploitable pour cette vérification. Si vous croisez déjà vos logs serveur avec le Crawl Stats de la Search Console, la donnée est en place.

2. Récupérez les fichiers JSON en direct, dans le script. Un fetch au moment du contrôle, ou un cache court avec revalidation. Jamais de plages copiées à la main dans un fichier de conf. Les dates de mise à jour du tableau ci-dessus suffisent à démontrer pourquoi.

3. Faites le match CIDR, pas une comparaison de chaînes. Une adresse contenue dans 216.73.216.0/22 ne « ressemble » à rien textuellement. Il faut convertir en entier et masquer, ce que fait n'importe quelle bibliothèque d'adressage réseau de votre langage. C'est cinq lignes de code, et c'est la seule étape qui produit une vraie décision binaire.

4. Pour Googlebot, passez au DNS inverse en deux temps. La procédure officielle de Google demande d'abord un host [IP] sur l'adresse relevée dans les logs, puis de vérifier que le nom obtenu se termine par googlebot.com, google.com ou googleusercontent.com. Ensuite seulement, un host [domaine] doit renvoyer l'adresse de départ. C'est ce second aller-retour, le forward-confirmed reverse DNS, qui fait la preuve : un attaquant peut contrôler la zone inverse d'une IP, il ne contrôle pas la zone directe de google.com.

5. Même logique pour CCBot, avec sa limite. Common Crawl documente un DNS inverse fonctionnel : l'adresse 18.97.14.84 résout en 18-97-14-84.crawl.commoncrawl.org. C'est valable en IPv4 seulement, la documentation précise que l'IPv6 n'est pas encore supporté. Si votre serveur est joignable en IPv6, prévoyez le repli sur le match CIDR.

6. Journalisez le verdict, ne bloquez pas dans la foulée. Un booléen verified à côté de chaque ligne de log vaut mieux qu'une règle WAF écrite à chaud. Vous saurez au bout d'une semaine quelle proportion de votre trafic « IA » est authentique.

Une remarque sur l'étape 2 : sur un petit site à faible trafic, figer les plages une fois par trimestre m'a paru raisonnable pendant des années. J'hésite encore, honnêtement. Le compromis se défend tant que quelqu'un tient le calendrier, et il tombe le jour où cette personne change de poste.

Le cas Perplexity, ou pourquoi la liste d'IP ne suffit pas#

En août 2025, Cloudflare a publié une analyse technique documentant un crawler qu'il qualifie de furtif : un user-agent générique imitant Chrome sur macOS, entre 3 et 6 millions de requêtes par jour, des adresses situées hors des plages officiellement publiées par Perplexity, et des changements d'ASN décrits comme des tentatives de contourner les blocages. Le test portait sur des dizaines de milliers de domaines fraîchement enregistrés avec un robots.txt restrictif. Je m'en tiens à ce que Cloudflare a publié : aucune réponse de Perplexity sur ces accusations n'a été retrouvée lors de cette vérification, je ne lui prête donc aucune position.

Ce qui m'intéresse ici, c'est la mécanique. Un crawler qui ne veut pas être identifié n'annonce pas un user-agent de crawler. Votre contrôle d'authenticité renverra donc « non vérifié » sur une requête qui se présente comme un navigateur ordinaire, et vous ne saurez rien de plus. La vérification par IP prouve l'authenticité d'un bot déclaré, elle ne détecte pas un bot qui se cache. Ce sont deux problèmes différents, et le second relève de la détection comportementale côté CDN.

Le tableau plus haut distingue d'ailleurs deux réalités qu'on empile souvent sous « Perplexity ignore robots.txt » : Perplexity-User l'ignore généralement, c'est documenté et assumé puisqu'un humain déclenche la requête, tandis que PerplexityBot, le crawler documenté, le respecte. L'accusation de Cloudflare porte sur un troisième acteur, non déclaré.

Ce que vous faites du verdict#

Vérifier n'est pas bloquer. Anthropic déconseille explicitement le blocage par adresse IP, pour une raison de mécanique interne : couper l'IP peut empêcher ses bots de lire votre robots.txt, et ne garantit donc pas l'opt-out que vous cherchiez. Vous obtenez le pire des deux mondes, un bot qui n'entre plus et qui n'a jamais lu votre refus.

L'authenticité sert à autre chose : à savoir si votre politique s'applique à du trafic réel. Décider quels crawlers autoriser est un autre débat, traité dans notre article sur la stratégie robots.txt des éditeurs face aux bots IA. La vérification, elle, dit simplement si les lignes que vous écrivez dans robots.txt ou dans un fichier llms.txt parlent à quelqu'un.

FAQ#

Le user-agent GPTBot peut-il être falsifié ?#

Oui, en une seule commande. Un user-agent est une chaîne envoyée par le client, sans signature ni contrôle. Seule la comparaison de l'adresse IP source avec le fichier openai.com/gptbot.json publié par OpenAI permet de trancher. OpenAI ne documente aucune autre méthode de vérification.

Comment vérifier Googlebot officiellement ?#

Google demande un DNS inverse sur l'adresse relevée dans vos logs avec la commande host, et vérifie que le nom obtenu appartient à googlebot.com, google.com ou googleusercontent.com. Une seconde requête DNS directe sur ce nom doit renvoyer l'adresse de départ. Les deux étapes sont nécessaires.

Peut-on distinguer ClaudeBot de Claude-User par l'adresse IP ?#

Non. Anthropic publie une liste d'adresses unique et commune à ClaudeBot, Claude-User et Claude-SearchBot, sans aucun champ distinguant les trois agents. L'adresse IP confirme l'origine Anthropic, rien de plus. Seul le user-agent nomme l'agent, et il ne constitue pas une preuve.

Où trouver les plages IP de Google-Extended ?#

Nulle part, et c'est normal. Google-Extended n'est pas un crawler mais un jeton lu dans robots.txt par l'infrastructure de crawl de Google, qui contrôle l'usage du contenu pour l'entraînement de ses modèles génératifs. Les requêtes proviennent de Googlebot, dont la vérification suit la procédure DNS officielle.

Faut-il copier les plages IP dans sa configuration serveur ?#

Non. Les fichiers évoluent à des rythmes très différents selon les opérateurs : octobre 2025 pour GPTBot, juillet 2026 pour ChatGPT-User, février 2025 pour PerplexityBot. Une liste figée devient fausse sans prévenir. Le script doit interroger l'URL officielle au moment du contrôle.

Sources#

Lien copié dans le presse-papiers

À lire aussi