Verifizierte Crawler-IP-Liste: eine Allowlist für gute Bots aus 19 offiziellen Feeds

Eine Firewall-Regel, die Traffic aus Hosting-Netzen herausfordert, trifft auch die Crawler, die Sie haben wollen. Jede verifizierte Crawler-Adresse, die wir am 29. Oktober 2026 abgefragt haben, liegt in einem Hosting-Netz: ClaudeBot bei Amazon, DuckDuckGo bei Microsoft, AhrefsBot bei OVH, Googlebot im eigenen Netz von Google. Lockern Sie die Regel stattdessen per User-Agent, spaziert jeder Scraper herein, der „Googlebot“ in seinen Header schreibt.

Die Betreiber veröffentlichen den Nachweis kostenlos, aber in 19 Dateien auf 10 verschiedenen Websites, mit unterschiedlichen Daten und ohne angegebenen Aktualisierungsrhythmus. Zwei der Dateien sind dieselbe Liste. Der Traffic ist real. Zur Vorstellung des Imperva 2026 Bad Bot Report schrieb Thales: „Bots dominieren inzwischen das Internet und machen über 53 % des gesamten Web-Traffics aus, wobei 40 % als bösartig eingestuft werden.“

Im Folgenden finden Sie jede Datei mit dem Datum, das sie am 29. Oktober 2026 trug, was die IP-Lookup-API von GeoIPHub für echte Adressen daraus zurückgibt, ein Skript, das die Allowlist baut, eine Richtlinienprüfung, die bei geteilten Dateien nicht danebengreift, und die Bots, die keine Datei abdeckt.

Gute Bots vs. schlechte Bots: Der Unterschied ist der Nachweis, nicht der Name

Ein guter Bot ist einer, den Sie hereinlassen wollen und dessen IP Sie nachweislich seinem Betreiber zuordnen können. Ein schlechter Bot fällt bei einem der beiden Tests durch, und die häufigste Sorte ist ein Scraper, der den User-Agent eines guten Bots trägt.

Zu den guten Bots gehören Suchmaschinen-Crawler, KI-Suche und von Nutzern ausgelöste Fetcher, SEO-Tools und Webarchive. Zu den schlechten Bots gehören Scraper, Credential-Stuffer, Klickbots und Spambots. Viele Glossare sagen, gute Bots „geben sich zu erkennen“. Das tun schlechte Bots auch: Sie kopieren die Identität, und genau deshalb leihen sich Scraper Crawler-Namen.

Die nützliche Frage lautet also nicht „Ist das ein guter Bot?“, sondern „Kommt diese Anfrage von dem Betreiber, den sie nennt?“. Diese zweite Frage hat eine mechanische Antwort, und sie ist der Kern der Bot-Erkennung per IP: Der Betreiber kontrolliert seine IP-Bereiche, und sonst niemand. Ob Sie einen nachgewiesenen Bot hereinlassen, ist dann Ihre Richtlinie, und die kann sich von Website zu Website unterscheiden.

Die verifizierte Crawler-IP-Liste: 19 offizielle Dateien von 10 Betreibern

Sie taugt als IP-Liste für Suchmaschinen-Bots und mehr: Die 19 Range-Dateien, die GeoIPHub lädt, stammen von 10 Betreibern, von Suchmaschinen und KI-Unternehmen bis zu einem Archiv und einem SEO-Tool. Hier ist jede einzelne mit ihrer Präfixzahl und dem in der Datei eingetragenen Datum, abgerufen am 29. Oktober 2026 zwischen 04:41 und 04:42 UTC. Alle 19 antworteten mit HTTP 200 und haben dieselbe Struktur: ein prefixes-Array mit ipv4Prefix- oder ipv6Prefix-Einträgen.

Der Scanner von GeoIPHub ruft jede Datei täglich neu ab. Am 27. Oktober 2026 haben wir aus jeder Datei eine Adresse abgefragt, und alle 19 kamen als verifiziert zurück; die beiden Adressen von Perplexity stammten aus den Dateien, die Perplexity am 28. Oktober ersetzt hat.

Das sind insgesamt 3.626 Präfixe, und die fünf Dateien von Google enthalten 2.181 davon. Es sind außerdem nur 18 verschiedene Listen: Die beiden DuckDuckGo-Dateien waren beim Abruf byte-identisch (gleicher MD5-Hash). Die beiden Dateien von Perplexity änderten sich zwischen dem 27. und 28. Oktober von 4 und 8 Präfixen auf 10 und 13, was eine deutliche Warnung ist, die Tabelle von irgendjemandem, auch diese hier, von Hand in eine Konfigurationsdatei zu kopieren.

Vier Anmerkungen. Googles alter Pfad, developers.google.com/search/apis/ipranges/googlebot.json, antwortet jetzt mit einer 301-Weiterleitung auf common-crawlers.json, ältere Anleitungen, die darauf verlinken, funktionieren also weiter, wenn Ihr Code Weiterleitungen folgt. Die Datei von Microsoft ist auf Januar 2024 datiert. Die Dokumentation von Perplexity verlinkt noch www.perplexity.com-URLs, die auf die oben genannten www.perplexity.ai-Dateien weiterleiten. Und www.gstatic.com/ipranges/goog.json deckt alle Adressen von Google ab, ist also keine Crawler-Liste. Wie sich Googles fünf Dateien auf seine Crawler-Gruppen verteilen, lesen Sie in unserem Googlebot-Leitfaden.

Was ein Treffer zurückgibt: vier echte Abfragen

Ein Treffer in der API von GeoIPHub liefert threat.crawler.verified: true, den Betreiber, ein Datei-Label und verification_method: "ip_range_list". Eine Adresse außerhalb aller Dateien liefert verified: false, und das heißt „nicht verifiziert“, nicht mehr. Hier ist die Adresse von ClaudeBot, gekürzt aus der Live-Antwort (29. Oktober 2026, 04:42:21 UTC):

dig -x 216.73.216.10 lieferte am 29. Oktober 2026 keinen PTR-Eintrag, Reverse DNS kann für diese Adresse also nicht bürgen. Das kann nur die Datei von Anthropic. Drei weitere Adressen, abgefragt zwischen 04:42:28 und 04:42:44 UTC:

Verfolgen Sie nun eine Anfrage. Angenommen, eine Anfrage gibt sich als DuckDuckBot von 104.43.54.127 aus, einer Adresse, die in beiden DuckDuckGo-Dateien als /32 steht. Die Abfrage meldet verified: true und operator: "DuckDuckGo", aber name: "DuckAssistBot" und category: "ai". Eine Richtlinie nach dem Muster „Such-Bots erlauben, KI-Bots drosseln“, die auf den Namen oder die Kategorie schaut, würde den echten Such-Crawler von DuckDuckGo drosseln. Schaut sie auf den angegebenen Bot und seinen Betreiber, kommt er durch. Wir erwarteten den Namen DuckDuckBot und bekamen DuckAssistBot: Das Namensfeld verriet uns, welche Datei zuletzt geladen wurde, nicht, welcher Bot angeklopft hat.

Meta ist die andere Falle. Wir erkennen das Netz von Meta (AS32934) per ASN, daher ist is_crawler true, aber verified ist false und verification_method ist "none". Behandeln Sie das als unverifiziert. Unsere Dokumentation listet die Crawler-Felder und was jedes einzelne bedeutet.

Eine Datei kann mehrere Bots abdecken, also richten Sie Ihre Richtlinie am Betreiber aus

Ordnen Sie den angegebenen User-Agent einem Betreiber zu und verlangen Sie dann verified: true und genau diesen Betreiber. Verwenden Sie nie crawler.name oder category als Schalter, denn eine Datei kann für mehrere Bots stehen:

• DuckDuckGo: zwei Dateien, eine Liste. Unser Scanner lädt duckassistbot.json als zweite, der letzte Schreibvorgang gewinnt also, und jede DuckDuckGo-Adresse trägt das Label DuckAssistBot.
• Anthropic: eine Datei für ClaudeBot, Claude-User und Claude-SearchBot. Die Crawler-Hilfeseite von Anthropic sagt: „Wenn ein Crawler eine Quell-IP-Adresse auf dieser Liste hat, bedeutet das, dass der Crawler von Anthropic kommt.“ Ein Treffer bedeutet also verifiziert als Anthropic; welcher Bot es ist, sagt Ihnen der User-Agent.
• Google: Die Common-Crawlers-Datei deckt mehrere Google-Crawler unter einem Label ab, Googlebot.

is_crawler allein reicht für eine Allowlist ebenfalls nicht, denn es ist auch beim unverifizierten Treffer von Meta true. Und die API sieht Ihre Request-Header nie. Sie nimmt eine IP entgegen, die Seite der Behauptung läuft also immer in Ihrem Code.

So bauen Sie eine Crawler-Allowlist in vier Schritten

Bauen Sie sie in vier Schritten: Ordnen Sie jeden erlaubten User-Agent seinem Betreiber zu, laden Sie die Dateien dieses Betreibers, prüfen Sie die IP dagegen und schicken Sie jede Behauptung, die scheitert, an den Rate-Limiter.

1. Die Zuordnung der Behauptungen. Listen Sie die User-Agent-Tokens auf, die Sie erlauben (ältere WAFs nennen das Whitelist), und den Betreiber, in dessen Datei die IP stehen muss.
2. Die Dateien. Bauen Sie entweder mit dem Skript unten Ihre eigene zusammengeführte Liste oder führen Sie pro neuer IP eine Abfrage durch und cachen Sie das Ergebnis einige Stunden, nicht Wochen, denn die Bereiche ändern sich.
3. Der Abgleich. Prüfen Sie die IP nur gegen die Präfixe des angegebenen Betreibers.
4. Der unverifizierte Pfad. Beantworten Sie ihn nicht mit einem 403. Drosseln Sie per Rate-Limit, was Sie nicht verifizieren können, damit ein echter Crawler auf einem neuen Präfix langsamer wird, statt zu verschwinden.

Warum pro Betreiber und nicht pro Datei? Weil manche Betreiber das Festlegen auf eine Datei unmöglich machen. Die drei Bots von Anthropic teilen sich eine Datei, und die zwei Bots von DuckDuckGo teilen sich eine Liste, eine Prüfung, die „die eigene Datei von Claude-SearchBot“ verlangt, hat also nichts zum Abgleichen. Der Abgleich auf Betreiberebene verliert etwas Präzision bei Google, OpenAI, Perplexity und Mistral, wo die Dateien getrennt sind, und greift dafür bei einer geteilten Datei nie daneben.

Zwei Regeln. Gleichen Sie exakte veröffentlichte Präfixe ab, nie die ASN: In unseren Abfragen trägt AS8075 von Microsoft Bingbot, GPTBot, ChatGPT-User und DuckDuckGo, eine Allowlist dafür lässt also jeden Azure-Kunden herein. Und setzen Sie nie allein anhand des User-Agents auf die Allowlist. Für Bots ohne Datei verwenden Sie Forward-Confirmed Reverse DNS, wo der Betreiber es dokumentiert.

Der Builder ruft alle 19 Dateien ab, gruppiert die Präfixe nach Betreiber und schreibt allowlist.json mit einem Abrufzeitpunkt pro Datei. Wenn eine Datei nicht heruntergeladen oder nicht geparst werden kann, leer zurückkommt oder auf weniger als die Hälfte ihrer letzten guten Kopie schrumpft, behält er die bisherigen Präfixe dieser Datei. Der Scanner von GeoIPHub macht es genauso, mit einer festen Mindestzahl an Präfixen pro Datei.

Planen Sie ihn mit einer einzigen Cron-Zeile ein, etwa 20 5 * * * cd /srv/bots && node build-allowlist.mjs. Die Richtlinienprüfung liest entweder diese Datei oder eine Abfrageantwort, und beide Pfade richten sich nach dem Betreiber des angegebenen Bots:

Wir haben beide Pfade gegen die Dateien und Abfragen vom 29. Oktober 2026 laufen lassen, dazu die Fehlerfälle. Der GPTBot-Fall verwendet 45.33.32.156, den öffentlichen Testhost von Nmap, der nie eine solche Anfrage gesendet hat. Die Prüfung erfolgt pro Betreiber, nicht pro Bot: Eine Googlebot-Behauptung von einer Adresse aus Googles Fetcher-Datei kommt ebenfalls als Google durch.

Dieser Code ist die Erlauben-Seite. Um eine Sperrrichtlinie pro Bot durchzusetzen, lesen Sie das nginx- und Express-Setup in unserem Leitfaden zu KI-Crawlern.

Kann ein verifizierter Bot trotzdem ein schlechter Bot sein? AhrefsBot sagt Ja

Ja. Die Verifizierung beweist, wer die Adresse betreibt, nicht, dass die Adresse sauber oder willkommen ist. Die Adresse 5.39.1.230 von AhrefsBot zeigt beides zugleich (29. Oktober 2026, 04:42:51 UTC):

Das Signal für verifizierte Crawler zieht 28,5 Punkte ab (minus 30 bei einer Konfidenz von 0,95), hebt aber einen Blocklisten-Eintrag nicht auf; der Leitfaden zu den Gründen hinter dem Risikoscore zeigt die Rechnung. Wir haben zwei frühere Werte für diese Adresse gespeichert: 59, step_up am 19. Oktober, als zusätzlich ein Missbrauchseintrag griff, und 35, review seit dem 22. Oktober. Als wir diese Adresse am 19. Oktober untersucht haben, zeigte die Registry von RIPE das /27 als auf Ahrefs registriert, innerhalb eines OVH-Blocks.

Ihre Allowlist entscheidet, ob AhrefsBot hereinkommt. Der Score sagt Ihnen, dass sein Bereich eine Vorgeschichte hat. Viele Websites haben keine Verwendung für SEO-Crawler, viele schon, diese Entscheidung liegt also bei Ihnen.

Gute Bots, die robots.txt bewusst ignorieren

„Befolgt robots.txt“ ist kein Test für einen guten Bot, denn die Betreiber selbst sagen, dass ihre von Nutzern ausgelösten Fetcher sich womöglich nicht daran halten:

• Google: „Da der Abruf von einem Nutzer angefordert wurde, ignorieren diese Fetcher robots.txt-Regeln in der Regel.“ (Von Nutzern ausgelöste Fetcher bei Google)
• OpenAI, zu ChatGPT-User: „Da diese Aktionen von einem Nutzer ausgelöst werden, gelten robots.txt-Regeln möglicherweise nicht.“ (OpenAI-Bots)
• Perplexity, zu Perplexity-User: „Da ein Nutzer den Abruf angefordert hat, ignoriert dieser Fetcher robots.txt-Regeln in der Regel.“ (Perplexity-Crawler)

Die Begründung ist bei allen dreien dieselbe: Der Abruf handelt für eine Person, wer ihn sperrt, sperrt also die Anfrage dieser Person. Ein verifizierter Fetcher, der Ihre robots.txt übergeht, verhält sich wie dokumentiert und benimmt sich nicht daneben.

robots.txt bittet, eine Allowlist setzt durch. Wenn Sie einen von Nutzern ausgelösten Fetcher draußen halten wollen, brauchen Sie eine Regel am Edge, keine Zeile in einer Textdatei. Was jeder OpenAI-Bot tut und was das Sperren jedes einzelnen kostet, lesen Sie in unserem OpenAI-Vergleich.

Wie aktuell ist die Liste? Dateidaten, ein täglicher Abruf und zwei Tage Verzögerung

Die Liste ist so aktuell wie die letzte Änderung des Betreibers plus Ihr Abruf. Für die API von GeoIPHub heißt das: ein täglicher Abruf und bis zu etwa zwei Tage, bis eine Änderung live ist.

Hier die Mechanik, aus dem Scanner-Code und der Konfiguration von GeoIPHub, geprüft am 29. Oktober 2026. Der Crawler-Schritt ruft jede Datei höchstens einmal am Tag ab. Wenn ein Abruf fehlschlägt oder weniger Präfixe liefert als das Minimum dieser Datei, behält der Scanner die letzten guten Bereiche. Ein Präfix, das der Betreiber entfernt, wird nach dem nächsten guten Abruf und dem darauffolgenden täglichen Rebuild nicht mehr verifiziert. Die Lookup-Datenbank wird dann täglich um 00:00 UTC neu gebaut und ist gegen 04:00 UTC live.

Die praktische Regel: Cachen Sie ein Verifizierungsergebnis für Stunden, rufen Sie die Dateien täglich neu ab und rechnen Sie damit, dass ein neu hinzugefügtes Präfix bis zu etwa zwei Tage lang nicht verifiziert wird. Das ist ein weiterer Grund, warum der unverifizierte Pfad an einen Rate-Limiter geht und nicht in eine Sperre.

Perplexity ist der einzige Betreiber in unseren Prüfungen, dessen Dokumentation überhaupt etwas zum Rhythmus sagt: „Diese Adressen werden regelmäßig aktualisiert und sollten die maßgebliche Quelle für Ihre WAF-Konfigurationen sein.“ Googles Verifizierungsseite nennt keine Frequenz. Die Dateidaten, die wir am 29. Oktober 2026 abgerufen haben, reichen von Januar 2024 (Microsoft) bis zum 28. Oktober 2026 (Google und Perplexity). Ein unverändertes Datum ist kein Fehler; manche Flotten bewegen sich nicht.

Eine Lücke auf unserer Seite: Die API zeigt nicht, welche Datei getroffen wurde oder wann wir sie abgerufen haben. Wenn Sie diesen Audit-Trail brauchen, lassen Sie den Builder laufen und bewahren Sie seine fetched_at-Werte auf.

Bots ohne veröffentlichte Liste, und was Sie mit ihnen tun

Manche Bots, die Sie vielleicht haben wollen, veröffentlichen keine Datei, die GeoIPHub lädt, daher kann diese Liste sie nicht verifizieren:

• OAI-AdsBot: OpenAI dokumentiert ihn und veröffentlicht adsbot.json, aber unser Scanner lädt die Datei noch nicht. Nehmen Sie sie in Ihren eigenen Builder auf, wenn Sie Anzeigen in ChatGPT schalten.
• Amazonbot: Amazon zeigt seine Bereiche innerhalb einer Webseite, ohne Datei zum Herunterladen. Wir laden sie nicht.
• Meta: Die Crawler-Seite von Meta sagt: „Fügen Sie Ihrer Allowlist entweder die User-Agent-Strings oder die IP-Adressen (sicherer) hinzu, die der Crawler verwendet“, bietet aber keine Range-Datei. Wir erkennen sein Netz nur per ASN, unverifiziert.
• Yandex und Baidu: nur Reverse DNS. Der Leitfaden von Yandex beschreibt die Prüfung: Der Reverse-DNS-Name muss auf yandex.ru, yandex.net oder yandex.com enden, und eine Forward-Abfrage dieses Namens muss dieselbe IP liefern.
• Bytespider: Wir haben keine Range-Datei von ByteDance gefunden.
• Uptime-Monitore und Zahlungs-Webhooks: Viele veröffentlichen eigene Listen. Stripe veröffentlicht Webhook-IPs als JSON, dokumentiert auf seiner Seite zu IP-Adressen. Verwenden Sie die Liste des Anbieters; das sind keine Crawler und sie sind nicht in unseren Feeds.
• Bots, die Anfragen signieren: Mit Web Bot Auth kann sich ein Bot per kryptografischer Signatur statt per IP ausweisen, beschrieben in unserem Leitfaden zur Crawler-Verifizierung. Das Verzeichnis verifizierter Bots von Cloudflare akzeptiert einen Bot, der entweder per Web Bot Auth oder über eine veröffentlichte IP-Liste mit stabilem User-Agent validiert ist.

Was Sie tun sollten: Verwenden Sie die Reverse-DNS-Methode des Betreibers, wo es eine gibt, die eigene Liste des Anbieters bei Diensten und den Rate-Limiter für alles andere.

Lassen Sie den Builder heute Nacht laufen oder fügen Sie eine IP aus Ihren Logs in den IP-Lookup ein und prüfen Sie, ob in der Zeile „Crawler“ „Verified crawler“ oder „Unverified crawler“ steht. Der Name im Header ist eine Behauptung; die Datei des Betreibers ist der Nachweis.

Häufig gestellte Fragen

Was ist eine verifizierte Crawler-IP-Liste?

Eine Liste, die aus den IP-Range-Dateien entsteht, die Bot-Betreiber für ihre eigenen Crawler veröffentlichen. GeoIPHub lädt 19 solcher Dateien von 10 Betreibern, darunter Google, Microsoft, Apple, OpenAI und Anthropic; OpenAI veröffentlicht eine 20., adsbot.json, die wir noch nicht laden. Eine Anfrage stammt von einem verifizierten Crawler, wenn ihr User-Agent einen Bot nennt und ihre IP in der Datei dieses Betreibers liegt.

Sieht eine IP-Abfrage den User-Agent?

Nein. Eine GeoIPHub-Abfrage nimmt nur die IP entgegen. Sie kann Ihnen sagen, dass die Adresse in der Datei von Anthropic oder Google steht, und Ihr eigener Code vergleicht diesen Betreiber mit dem Bot, den der User-Agent angibt.

Kann ein verifizierter Bot trotzdem ein schlechter Bot sein?

Ja. Die Adresse 5.39.1.230 von AhrefsBot passte zu den veröffentlichten Bereichen von Ahrefs, stand aber auch auf Spamhaus ZEN und erhielt am 29. Oktober 2026 in der API von GeoIPHub den Score 35, review. Die Verifizierung sagt Ihnen, wer die Adresse betreibt, nicht, ob Sie sie hereinlassen sollten.

Wie oft ändern sich Crawler-IP-Bereiche?

Das hängt vom Betreiber ab, und die meisten sagen es nicht. Am 29. Oktober 2026 reichten die Dateidaten von Januar 2024 (Microsoft) bis zum 28. Oktober 2026 (Google und Perplexity). GeoIPHub ruft jede Datei täglich neu ab, und eine Änderung kann bis zu etwa zwei Tage brauchen, bis sie in der API ankommt.

Sollte ich Crawler per ASN auf die Allowlist setzen?

Nein. Viele Crawler laufen in geteilten Clouds: Über das Netz von Microsoft laufen Bingbot, GPTBot und die Bots von DuckDuckGo, eine Allowlist dafür lässt also jeden Kunden dieser Cloud herein. Gleichen Sie die exakten Präfixe in der Datei jedes Betreibers ab.

Welche Bots lassen sich nicht über eine IP-Liste verifizieren?

Bots, deren Betreiber keine Datei veröffentlichen, etwa Yandex und Baidu (stattdessen Reverse DNS), Meta (keine Range-Datei; GeoIPHub erkennt sein Netz per ASN, unverifiziert) und Bytespider. Amazon zeigt die Bereiche von Amazonbot nur innerhalb einer Webseite. Was Sie nicht verifizieren können, sollten Sie per Rate-Limit drosseln.