Liste d'IP de robots d'exploration vérifiés : construire une allowlist de bons bots à partir de 19 fichiers officiels

Une règle de pare-feu qui met au défi le trafic des réseaux d'hébergement attrape aussi les robots d'exploration que vous voulez. Chaque adresse de robot d'exploration vérifié que nous avons interrogée le 29 octobre 2026 se trouve sur un réseau d'hébergement : ClaudeBot chez Amazon, DuckDuckGo chez Microsoft, AhrefsBot chez OVH, Googlebot sur le réseau de Google lui-même. Assouplissez plutôt la règle par User-Agent, et chaque scraper qui écrit « Googlebot » dans son en-tête entre librement.

Les opérateurs publient la preuve gratuitement, mais dans 19 fichiers répartis sur 10 sites différents, avec des dates différentes et aucun calendrier de mise à jour annoncé. Deux de ces fichiers sont la même liste. Le trafic, lui, est bien réel. En annonçant le Bad Bot Report 2026 d'Imperva, Thales écrivait : « Les bots dominent désormais Internet, représentant plus de 53 % de tout le trafic web, dont 40 % classés comme malveillants. »

Vous trouverez ci-dessous chaque fichier avec la date qu'il portait le 29 octobre 2026, ce que l'API de recherche IP de GeoIPHub renvoie pour de vraies adresses qui en sont issues, un script qui construit l'allowlist, une vérification de politique qui ne se trompe pas sur les fichiers partagés, et les bots qu'aucun fichier ne couvre.

Bons bots vs mauvais bots : la différence est la preuve, pas le nom

Un bon bot est un bot que vous avez décidé de laisser entrer, et dont vous pouvez prouver que l'IP appartient à son opérateur. Un mauvais bot échoue à l'un de ces deux tests, et le type le plus courant est un scraper qui porte le User-Agent d'un bon bot.

Les bons bots comprennent les robots d'exploration des moteurs de recherche, les fetchers de recherche IA et ceux déclenchés par un utilisateur, les outils SEO et les robots d'archivage du web. Les mauvais bots comprennent les scrapers, les bots de credential stuffing, les bots de clics et les bots de spam. Beaucoup de glossaires disent que les bons bots « s'identifient ». Les mauvais bots le font aussi : ils copient l'identité, ce qui explique pourquoi les scrapers empruntent des noms de robots d'exploration au départ.

La question utile n'est donc pas « est-ce un bon bot ? » mais « cette requête provient-elle de l'opérateur qu'elle nomme ? ». Cette seconde question a une réponse mécanique, et c'est le cœur de la détection des bots par IP : l'opérateur contrôle ses plages d'IP, et personne d'autre. Admettre ou non un bot prouvé relève ensuite de votre politique, et celle-ci peut varier d'un site à l'autre.

La liste d'IP de robots d'exploration vérifiés : 19 fichiers officiels de 10 opérateurs

Elle fait office de liste d'IP de bots de moteurs de recherche, et plus encore : les 19 fichiers de plages que charge GeoIPHub proviennent de 10 opérateurs, des moteurs de recherche et entreprises d'IA jusqu'à une archive et un outil SEO. Voici chacun d'eux avec son nombre de préfixes et la date écrite dans le fichier, récupérés le 29 octobre 2026 entre 04:41 et 04:42 UTC. Les 19 ont répondu HTTP 200 et partagent la même forme : un tableau prefixes d'entrées ipv4Prefix ou ipv6Prefix.

Le scanner de GeoIPHub récupère à nouveau chaque fichier tous les jours. Le 27 octobre 2026, nous avons interrogé une adresse de chaque fichier, et les 19 sont revenues vérifiées ; les deux adresses de Perplexity provenaient des fichiers qu'il a remplacés le 28 octobre.

Cela fait 3 626 préfixes au total, dont 2 181 dans les cinq fichiers de Google. Ce ne sont d'ailleurs que 18 listes distinctes : les deux fichiers de DuckDuckGo étaient identiques octet pour octet lorsque nous les avons récupérés (même empreinte MD5). Les deux fichiers de Perplexity ont changé entre le 27 et le 28 octobre, passant de 4 et 8 préfixes à 10 et 13, ce qui est un bon avertissement contre le fait de recopier à la main le tableau de qui que ce soit, y compris celui-ci, dans un fichier de configuration.

Quatre remarques. L'ancien chemin de Google, developers.google.com/search/apis/ipranges/googlebot.json, répond désormais par une redirection 301 vers common-crawlers.json, donc les anciens guides qui y renvoient fonctionnent encore si votre code suit les redirections. Le fichier de Microsoft date de janvier 2024. La documentation de Perplexity renvoie encore vers des URL www.perplexity.com, qui redirigent vers les fichiers www.perplexity.ai ci-dessus. Et www.gstatic.com/ipranges/goog.json couvre toutes les adresses de Google, ce n'est donc pas une liste de robots d'exploration. Pour savoir comment les cinq fichiers de Google se répartissent entre ses groupes de robots d'exploration, consultez notre guide sur Googlebot.

Ce que renvoie une correspondance : quatre vraies requêtes

Une correspondance dans l'API de GeoIPHub renvoie threat.crawler.verified: true, l'opérateur, une étiquette de fichier et verification_method: "ip_range_list". Une adresse hors de tous les fichiers renvoie verified: false, ce qui signifie « non vérifié », rien de plus. Voici l'adresse de ClaudeBot, extraite de la réponse en direct (29 octobre 2026, 04:42:21 UTC) :

dig -x 216.73.216.10 n'a renvoyé aucun enregistrement PTR le 29 octobre 2026, donc le DNS inverse ne peut pas se porter garant de cette adresse. Seul le fichier d'Anthropic le peut. Trois autres adresses, interrogées entre 04:42:28 et 04:42:44 UTC :

Suivons maintenant une requête. Supposons qu'une requête revendique DuckDuckBot depuis 104.43.54.127, une adresse listée en /32 dans les deux fichiers de DuckDuckGo. La recherche indique verified: true et operator: "DuckDuckGo", mais name: "DuckAssistBot" et category: "ai". Une politique écrite comme « autoriser les bots de recherche, limiter le débit des bots IA » et fondée sur le nom ou la catégorie bridera le vrai robot d'exploration de recherche de DuckDuckGo. Fondée sur le bot revendiqué et son opérateur, elle le laisse passer. Nous attendions un nom DuckDuckBot et avons obtenu DuckAssistBot : le champ du nom nous indiquait quel fichier avait été chargé en dernier, pas quel bot frappait à la porte.

Meta est l'autre piège. Nous reconnaissons le réseau de Meta (AS32934) par ASN, donc is_crawler vaut true mais verified vaut false et verification_method vaut "none". Traitez-le comme non vérifié. Notre documentation liste les champs du robot d'exploration et la signification de chacun.

Un fichier peut couvrir plusieurs bots : fondez votre politique sur l'opérateur

Associez le User-Agent revendiqué à un opérateur, puis exigez verified: true et ce même opérateur. N'utilisez jamais crawler.name ou category comme critère, car un seul fichier peut représenter plusieurs bots :

• DuckDuckGo : deux fichiers, une seule liste. Notre scanner charge duckassistbot.json en second, donc la dernière écriture l'emporte et chaque adresse de DuckDuckGo porte l'étiquette DuckAssistBot.
• Anthropic : un seul fichier pour ClaudeBot, Claude-User et Claude-SearchBot. La page d'aide d'Anthropic sur ses robots d'exploration indique : « Si un robot d'exploration a une adresse IP source figurant sur cette liste, cela indique qu'il provient d'Anthropic. » Une correspondance signifie donc vérifié comme Anthropic ; le User-Agent vous dit de quel bot il s'agit.
• Google : le fichier common-crawlers couvre plusieurs robots d'exploration de Google sous une seule étiquette, Googlebot.

is_crawler seul ne suffit pas non plus pour une allowlist, puisqu'il vaut true pour la correspondance non vérifiée de Meta. Et l'API ne voit jamais les en-têtes de votre requête. Elle prend une IP, donc la partie revendication de la vérification s'exécute toujours dans votre code.

Construire une allowlist de robots d'exploration en quatre étapes

Construisez-la en quatre étapes : associez chaque User-Agent que vous autorisez à son opérateur, chargez les fichiers de cet opérateur, vérifiez l'IP par rapport à eux et envoyez toute revendication qui échoue au limiteur de débit.

1. La table des revendications. Listez les jetons de User-Agent que vous autorisez (les anciens WAF appellent cela une whitelist) et l'opérateur dont le fichier doit contenir l'IP.
2. Les fichiers. Soit vous construisez votre propre liste fusionnée avec le script ci-dessous, soit vous faites une requête par nouvelle IP et mettez le verdict en cache pendant quelques heures, pas des semaines, car les plages changent.
3. La correspondance. Vérifiez l'IP uniquement par rapport aux préfixes de l'opérateur revendiqué.
4. Le chemin non vérifié. N'y répondez pas par un 403. Limitez le débit de ce que vous ne pouvez pas vérifier, afin qu'un vrai robot d'exploration sur un nouveau préfixe ralentisse au lieu de disparaître.

Pourquoi par opérateur et non par fichier ? Parce que certains opérateurs rendent l'association par fichier impossible. Les trois bots d'Anthropic partagent un seul fichier, et les deux bots de DuckDuckGo partagent une seule liste, donc une vérification qui exige « le propre fichier de Claude-SearchBot » n'a rien à faire correspondre. La correspondance par opérateur perd un peu de précision chez Google, OpenAI, Perplexity et Mistral, où les fichiers sont distincts, et en échange elle ne se trompe jamais sur un fichier partagé.

Deux règles. Faites correspondre les préfixes publiés exacts, jamais l'ASN : dans nos requêtes, l'AS8075 de Microsoft transporte Bingbot, GPTBot, ChatGPT-User et DuckDuckGo, donc l'autoriser admet tous les clients d'Azure. Et n'autorisez jamais sur le seul User-Agent. Pour les bots sans fichier, utilisez le DNS inverse confirmé par une requête directe lorsque l'opérateur le documente.

Le constructeur récupère les 19 fichiers, regroupe les préfixes par opérateur et écrit allowlist.json avec une heure de récupération par fichier. Si un fichier ne se télécharge pas, ne s'analyse pas, revient vide ou se réduit à moins de la moitié de sa dernière bonne copie, il conserve les préfixes précédents de ce fichier. Le scanner de GeoIPHub fait de même avec un nombre minimal fixe de préfixes par fichier.

Planifiez-le avec une seule ligne cron, par exemple 20 5 * * * cd /srv/bots && node build-allowlist.mjs. La vérification de politique lit soit ce fichier, soit une réponse de requête, et les deux chemins se fondent sur l'opérateur du bot revendiqué :

Nous avons exécuté les deux chemins sur les fichiers et requêtes du 29 octobre 2026, ainsi que sur les cas d'échec. Le cas GPTBot utilise 45.33.32.156, l'hôte de test public de Nmap, qui n'a jamais envoyé une telle requête. La vérification se fait par opérateur, pas par bot : une revendication Googlebot depuis une adresse du fichier des fetchers de Google passe aussi en tant que Google.

Ce code couvre le côté autorisation. Pour appliquer une politique de blocage par bot, consultez la configuration nginx et Express de notre guide sur les robots d'exploration IA.

Un bot vérifié peut-il quand même être un mauvais bot ? AhrefsBot répond oui

Oui. La vérification prouve qui exploite l'adresse, pas que l'adresse est propre ou bienvenue. L'adresse 5.39.1.230 d'AhrefsBot montre les deux à la fois (29 octobre 2026, 04:42:51 UTC) :

Le signal de robot d'exploration vérifié retranche 28,5 points (moins 30 à une confiance de 0,95), mais il n'annule pas une inscription sur une liste de blocage ; le guide des raisons du score de risque détaille le calcul. Nous avons conservé deux valeurs antérieures pour cette adresse : 59, step_up le 19 octobre, lorsqu'une inscription pour abus s'est aussi déclenchée, et 35, review depuis le 22 octobre. Lorsque nous avons enquêté sur cette adresse le 19 octobre, le registre du RIPE montrait le /27 enregistré au nom d'Ahrefs à l'intérieur d'un bloc OVH.

Votre allowlist décide si AhrefsBot entre. Le score vous dit que sa plage a un historique. Beaucoup de sites n'ont aucun usage des robots d'exploration SEO et beaucoup d'autres en ont un, donc cette décision vous appartient.

Les bons bots qui ignorent robots.txt par conception

« Respecte robots.txt » n'est pas un critère de bon bot, car les opérateurs eux-mêmes disent que leurs fetchers déclenchés par l'utilisateur peuvent ne pas le suivre :

• Google : « Comme la récupération a été demandée par un utilisateur, ces fetchers ignorent généralement les règles de robots.txt. » (Fetchers déclenchés par l'utilisateur de Google)
• OpenAI, à propos de ChatGPT-User : « Comme ces actions sont lancées par un utilisateur, les règles de robots.txt peuvent ne pas s'appliquer. » (Bots d'OpenAI)
• Perplexity, à propos de Perplexity-User : « Comme un utilisateur a demandé la récupération, ce fetcher ignore généralement les règles de robots.txt. » (Robots d'exploration de Perplexity)

Le raisonnement est le même dans les trois cas : la récupération agit pour une personne, donc la bloquer bloque la requête de cette personne. Un fetcher vérifié qui ignore votre robots.txt se comporte comme documenté, il ne se conduit pas mal.

robots.txt demande ; une allowlist impose. Si vous voulez écarter un fetcher déclenché par l'utilisateur, il vous faut une règle en bordure de réseau, pas une ligne dans un fichier texte. Pour ce que fait chaque bot d'OpenAI et ce que coûte le blocage de chacun, consultez notre comparatif OpenAI.

Quelle est la fraîcheur de la liste ? Dates des fichiers, récupération quotidienne et délai de deux jours

La liste est aussi fraîche que la dernière modification de l'opérateur plus votre récupération. Pour l'API de GeoIPHub, cela signifie une récupération quotidienne et jusqu'à environ deux jours avant qu'un changement soit en ligne.

Voici le fonctionnement, d'après le code et la configuration du scanner de GeoIPHub, vérifiés le 29 octobre 2026. L'étape des robots d'exploration récupère chaque fichier au plus une fois par jour. Si une récupération échoue, ou renvoie moins de préfixes que le minimum de ce fichier, le scanner conserve les dernières bonnes plages. Un préfixe retiré par l'opérateur cesse d'être vérifié après la bonne récupération suivante et la reconstruction quotidienne qui la suit. La base de données de recherche est ensuite reconstruite chaque jour à 00:00 UTC et est en ligne vers 04:00 UTC.

La règle pratique : mettez un verdict vérifié en cache pendant des heures, récupérez à nouveau les fichiers chaque jour et attendez-vous à ce qu'un préfixe nouvellement ajouté échoue à la vérification pendant jusqu'à environ deux jours. C'est une raison de plus pour que le chemin non vérifié mène à un limiteur de débit, et non à un blocage.

Perplexity est le seul opérateur de nos vérifications dont la documentation dit quelque chose sur la cadence : « Ces adresses sont mises à jour régulièrement et doivent servir de source de vérité pour vos configurations de WAF. » La page de vérification de Google n'indique aucune fréquence. Les dates des fichiers que nous avons récupérés le 29 octobre 2026 vont de janvier 2024 (Microsoft) au 28 octobre 2026 (Google et Perplexity). Une date stable n'est pas une erreur ; certaines flottes ne bougent pas.

Une lacune de notre côté : l'API n'indique pas quel fichier a correspondu ni quand nous l'avons récupéré. Si vous avez besoin de cette piste d'audit, exécutez le constructeur et conservez ses valeurs fetched_at.

Les bots sans liste publiée, et que faire à leur sujet

Certains bots que vous voudrez peut-être accueillir ne publient aucun fichier que GeoIPHub charge, donc cette liste ne peut pas les vérifier :

• OAI-AdsBot : OpenAI le documente et publie adsbot.json, mais notre scanner ne le charge pas encore. Ajoutez-le à votre propre constructeur si vous diffusez des publicités sur ChatGPT.
• Amazonbot : Amazon affiche ses plages dans une page web, sans fichier à télécharger. Nous ne le chargeons pas.
• Meta : la page de Meta sur ses robots d'exploration indique « Ajoutez à votre liste d'autorisation soit les chaînes de user agent, soit les adresses IP (plus sûr) utilisées par le robot d'exploration », mais ne fournit aucun fichier de plages. Nous reconnaissons son réseau uniquement par ASN, sans vérification.
• Yandex et Baidu : DNS inverse uniquement. Le guide de Yandex décrit la vérification : le nom DNS inverse doit se terminer par yandex.ru, yandex.net ou yandex.com, et une requête directe sur ce nom doit renvoyer la même IP.
• Bytespider : nous n'avons trouvé aucun fichier de plages publié par ByteDance.
• Moniteurs de disponibilité et webhooks de paiement : beaucoup publient leurs propres listes. Stripe publie les IP de ses webhooks en JSON, documentées sur sa page des adresses IP. Utilisez la liste du fournisseur ; ce ne sont pas des robots d'exploration et ils ne figurent pas dans nos flux.
• Les bots qui signent leurs requêtes : Web Bot Auth permet à un bot de prouver son identité par une signature cryptographique plutôt que par une IP, ce que couvre notre guide de vérification des robots d'exploration. L'annuaire des bots vérifiés de Cloudflare accepte un bot validé soit par Web Bot Auth, soit par une liste d'IP publiée avec un User-Agent stable.

Que faire : utilisez la méthode de DNS inverse de l'opérateur lorsqu'elle existe, la liste du fournisseur pour les services, et le limiteur de débit pour tout le reste.

Exécutez le constructeur ce soir, ou collez une IP de vos journaux dans l'outil de recherche IP et vérifiez si sa ligne Crawler indique « Verified crawler » ou « Unverified crawler ». Le nom dans l'en-tête est une revendication ; le fichier de l'opérateur est la preuve.

Questions fréquentes

Qu'est-ce qu'une liste d'IP de robots d'exploration vérifiés ?

Une liste construite à partir des fichiers de plages d'IP que les opérateurs de bots publient pour leurs propres robots d'exploration. GeoIPHub charge 19 de ces fichiers provenant de 10 opérateurs, dont Google, Microsoft, Apple, OpenAI et Anthropic ; OpenAI en publie un 20e, adsbot.json, que nous ne chargeons pas encore. Une requête provient d'un robot d'exploration vérifié lorsque son User-Agent nomme un bot et que son IP se trouve dans le fichier de cet opérateur.

Une requête IP voit-elle le User-Agent ?

Non. Une requête GeoIPHub ne prend que l'IP. Elle peut vous dire que l'adresse figure dans le fichier d'Anthropic ou de Google, et c'est votre propre code qui compare cet opérateur au bot revendiqué par le User-Agent.

Un bot vérifié peut-il quand même être un mauvais bot ?

Oui. L'adresse 5.39.1.230 d'AhrefsBot correspondait aux plages publiées par Ahrefs et figurait aussi sur Spamhaus ZEN, avec un score de 35, review, dans l'API de GeoIPHub le 29 octobre 2026. La vérification vous dit qui exploite l'adresse, pas s'il faut la laisser entrer.

À quelle fréquence les plages d'IP des robots d'exploration changent-elles ?

Cela dépend de l'opérateur, et la plupart ne le disent pas. Le 29 octobre 2026, les dates des fichiers allaient de janvier 2024 (Microsoft) au 28 octobre 2026 (Google et Perplexity). GeoIPHub récupère à nouveau chaque fichier tous les jours, et un changement peut mettre jusqu'à environ deux jours pour atteindre son API.

Faut-il autoriser les robots d'exploration par ASN ?

Non. Beaucoup de robots d'exploration tournent sur des clouds partagés : le réseau de Microsoft transporte Bingbot, GPTBot et les bots de DuckDuckGo, donc l'autoriser revient à admettre tous les clients de ce cloud. Faites correspondre les préfixes exacts du fichier de chaque opérateur.

Quels bots ne peuvent pas être vérifiés par une liste d'IP ?

Les bots dont les opérateurs ne publient aucun fichier, comme Yandex et Baidu (DNS inverse à la place), Meta (aucun fichier de plages ; GeoIPHub reconnaît son réseau par ASN, sans vérification) et Bytespider. Amazon n'affiche les plages d'Amazonbot que dans une page web. Limitez le débit de ce que vous ne pouvez pas vérifier.