Rate Limiting für KI-Crawler: Solltest du GPTBot begrenzen?
Cloudflare Radar beobachtet, dass GPTBot zu den KI-Crawlern mit dem größten Anteil an eindeutigen Webseiten im Cloudflare-Netzwerk zählt, gleich nach Googlebot (Cloudflare, 2025). Wer diese Größenordnung nicht einordnen kann, blockiert im Zweifel mehr, als nötig wäre.
Definition: Rate Limiting für KI-Crawler bezeichnet die gezielte Begrenzung der Anfragen, die Bots wie GPTBot, PerplexityBot oder ClaudeBot pro Zeiteinheit an eine Website stellen dürfen. Ziel ist, Serverlast zu kontrollieren, ohne die eigenen Inhalte für die generative Suche unsichtbar zu machen.
Warum überhaupt KI-Crawler begrenzen?
Website-Betreiber stellen sich diese Frage meist aus zwei Gründen: Serverlast oder Kontrolle darüber, welche Inhalte in KI-Antworten landen. Beides ist berechtigt, führt aber zu unterschiedlichen Maßnahmen.
GPTBot (OpenAI), PerplexityBot (Perplexity), ClaudeBot (Anthropic) und CCBot (Common Crawl) crawlen nicht wie klassische Suchmaschinen-Bots im festen Rhythmus. Sie können in Wellen auftreten, etwa wenn ein Modell-Update ansteht oder eine Website neu in den Index aufgenommen wird. Für kleinere Server mit begrenzter Rechenleistung kann das spürbar werden, insbesondere bei dynamisch generierten Seiten wie Produktfiltern oder Suchergebnissen.
Die zweite Motivation ist inhaltlicher Natur: Manche Betreiber wollen verhindern, dass veraltete Preise, interne Testseiten oder rechtlich heikle Inhalte in ChatGPT- oder Perplexity-Antworten zitiert werden. Hier hilft technisches Rate Limiting wenig. Gefragt sind stattdessen saubere robots.txt-Regeln und Canonical-Tags, um solche Inhalte gezielt von der Indexierung auszuschließen.
GPTBot, PerplexityBot, ClaudeBot: Wie unterschiedlich sie crawlen
Die drei großen KI-Crawler verhalten sich technisch nicht identisch. Perplexity dokumentiert selbst, dass PerplexityBot robots.txt-Regeln respektiert und Inhalte nicht indexiert, wenn eine Seite per Disallow gesperrt ist (Perplexity, Docs). Der separate Perplexity-User-Agent, der aktiv wird, wenn ein Nutzer live etwas nachfragt, wird von Perplexity dagegen ausdrücklich als Assistent und nicht als klassischer Bot eingeordnet. robots.txt gilt dafür nach eigener Aussage des Unternehmens nicht in gleicher Weise.
| Crawler | Betreiber | Zweck | Folgt robots.txt |
|---|---|---|---|
| GPTBot | OpenAI | Trainings- und Antwortdaten | Ja |
| PerplexityBot | Perplexity | Such-Index für Antworten | Ja |
| ClaudeBot | Anthropic | Trainings- und Antwortdaten | Ja |
| CCBot | Common Crawl | Offener Web-Datensatz, Basis vieler Modelle | Ja |
Was in der Praxis oft übersehen wird: Ein klassisches Crawl-Delay in der robots.txt, wie es manche traditionelle Suchmaschinen-Bots respektieren, ist kein offizieller Bestandteil des Robots-Exclusion-Standards RFC 9309. Ob und wie stark GPTBot, PerplexityBot oder ClaudeBot eine Crawl-Delay-Angabe tatsächlich berücksichtigen, ist öffentlich nicht einheitlich dokumentiert. Wer die Crawl-Rate wirklich steuern will, kommt an serverseitigem Rate Limiting kaum vorbei.
Eigene Beobachtung: Muster aus geaio-Scans bei robots.txt
Ausgangslage: Bei der Arbeit mit geaio.de sehen wir regelmäßig, wie Website-Betreiber ihre robots.txt gegen KI-Crawler konfigurieren, oft in Reaktion auf Presseberichte über KI-Training statt auf eine konkrete Serverlast-Analyse.
Vorgehen: In einer Stichprobe von geaio-Scans an betreuten Websites haben wir robots.txt-Dateien darauf geprüft, wie granular GPTBot- und PerplexityBot-Regeln gesetzt sind: vollständiger Disallow für den ganzen Bot versus gezielte Sperrung einzelner Pfade wie /suche/ oder /warenkorb/.
Beobachtung: In eigenen Analysen sehen wir häufiger, dass GPTBot per pauschalem Disallow: / komplett ausgesperrt wird, während PerplexityBot und ClaudeBot unangetastet bleiben oder umgekehrt. Eine nachvollziehbare Strategie dahinter, etwa eine bewusste Entscheidung gegen KI-Training bei gleichzeitiger Offenheit für KI-Suche, ist in den robots.txt-Dateien selbst meist nicht erkennbar; oft wirkt die Konfiguration eher zufällig gewachsen als geplant.
Einordnung: Das ist eine Beobachtung aus einer Stichprobe, keine repräsentative Studie. Wie stark eine pauschale GPTBot-Sperrung die Sichtbarkeit in ChatGPT-Antworten tatsächlich reduziert, lässt sich ohne Zugriff auf OpenAIs interne Crawl- und Trainingsdaten nicht seriös beziffern. Was wir sagen können: Die Entscheidung sollte bewusst getroffen werden, nicht als Nebenprodukt einer kopierten robots.txt-Vorlage.
Was passiert, wenn du GPTBot oder PerplexityBot komplett blockierst?
Ein kompletter Block über robots.txt ist technisch einfach, hat aber Folgen für die KI-Sichtbarkeit. Cloudflare beobachtet für 2025, dass GPTBot, ClaudeBot und CCBot zu den Crawlern mit den meisten vollständigen Disallow-Einträgen zählen: Website-Betreiber sperren sie überdurchschnittlich häufig komplett aus (Cloudflare, 2025).
Für Websites, die auf Sichtbarkeit in ChatGPT Search oder Perplexity setzen, ist das riskant. Wird GPTBot blockiert, kann OpenAI die Inhalte weder für Trainingsdaten noch für Live-Antworten heranziehen: Die Seite fällt aus der Quellenbasis heraus. Bei Perplexity gilt laut eigener Dokumentation: Ist PerplexityBot per robots.txt gesperrt, indexiert Perplexity den Volltext nicht, kann aber je nach Konfiguration weiterhin Domain, Titel und eine kurze Zusammenfassung anzeigen.
Rate Limiting ist hier die differenziertere Alternative zum harten Block: Statt einen Crawler komplett auszusperren, begrenzt man die Anzahl der Requests pro Minute oder Sekunde. Der Bot bekommt weiterhin Zugriff, nur langsamer.
Rate Limiting technisch umsetzen: Server, robots.txt und llms.txt im Zusammenspiel
robots.txt allein reicht für echtes Rate Limiting nicht aus, weil die Crawl-Delay-Direktive kein verlässlich unterstützter Standard ist. Wirksame Begrenzung passiert auf drei Ebenen:
- Server- oder CDN-Ebene: Nginx-Rate-Limiting oder ein WAF-Regelwerk, das Requests pro IP-Bereich pro Zeitfenster deckelt. Wichtig ist, die offiziellen IP-Bereiche der Bots zu verifizieren, bevor man sperrt, sonst trifft man versehentlich legitimen Traffic.
- Gezielte Pfad-Sperrung: Teure, dynamisch generierte Pfade (Facettensuche, interne Suchergebnisse, Warenkorb) per Disallow ausschließen, den Rest der Website offen lassen.
- llms.txt als ergänzendes Signal: Eine llms.txt kann priorisierte Inhalte benennen, ist aber kein offiziell ratifizierter Standard der großen KI-Anbieter und ersetzt keine technische Rate-Limiting-Lösung. Details dazu findest du im Beitrag zu robots.txt für KI-Crawler.
Rechenbeispiel zur Einordnung der Größenordnung (Modellrechnung, keine gemessenen Werte): Crawlt ein Bot eine mittelgroße Website mit 5.000 Produktseiten im Schnitt einmal pro Sekunde, ergibt das rechnerisch bis zu 86.400 Requests pro Tag, allein durch diesen einen Crawler. Bei drei aktiven KI-Bots parallel und ohne jede Begrenzung kann sich diese Zahl theoretisch vervielfachen. Ob das für einen konkreten Server tatsächlich zum Problem wird, hängt von Response-Zeit und Infrastruktur ab und lässt sich nur mit einer echten Log-Auswertung beantworten. Dafür eignet sich die Log File Analyse für KI-Crawler. Wer die Server-Antwortzeiten selbst systematisch verbessern will, findet Ansätze im Beitrag zum Crawl-Budget für KI-Bots.
Die richtige Grenze: wann Rate Limiting sich lohnt
Aus unserer Sicht lohnt sich aktives Rate Limiting vor allem dann, wenn eine echte Log-Auswertung zeigt, dass KI-Crawler tatsächlich Ressourcen belasten, nicht als vorsorgliche Standardmaßnahme. Für die meisten kleinen und mittleren Websites dürfte die Crawl-Last einzelner KI-Bots im Rahmen dessen liegen, was auch klassische Suchmaschinen-Crawler verursachen. Wichtiger als pauschale Begrenzung ist aus unserer Sicht, gezielt zu entscheiden: Welche Pfade sind für KI-Crawler wertvoll, welche nicht.
Wer stattdessen reflexartig alle GPTBot- oder PerplexityBot-Anfragen blockiert, verliert Sichtbarkeit in KI-Suchsystemen, ohne dass klar ist, ob ein reales Serverproblem vorlag. Für GEO und KI-Suche insgesamt gilt: Websites müssen für KI-Crawler zugänglich bleiben und gleichzeitig technisch stabil laufen. Eine gute Rate-Limiting-Strategie sorgt für genau dieses Gleichgewicht.
Häufig gestellte Fragen
Sollte ich GPTBot grundsätzlich blockieren? Nicht ohne Grund. Ein pauschaler Block über robots.txt entzieht deiner Website die Grundlage, in ChatGPT-Antworten zitiert zu werden. Sinnvoller ist eine gezielte Sperrung einzelner, unwichtiger Pfade statt eines kompletten Disallow.
Honorieren GPTBot, PerplexityBot und ClaudeBot die Crawl-Delay-Direktive in robots.txt? Das ist öffentlich nicht einheitlich dokumentiert. Crawl-Delay ist kein offizieller Bestandteil des Robots-Exclusion-Standards RFC 9309, deshalb solltest du dich für echte Rate-Begrenzung nicht darauf verlassen, sondern serverseitig limitieren.
Wie erkenne ich, ob KI-Crawler meinen Server tatsächlich belasten? Am zuverlässigsten über eine Log-File-Analyse, die Requests nach User-Agent und verifizierter IP-Range auswertet. Erst mit diesen Zahlen lässt sich beurteilen, ob Rate Limiting nötig ist oder ob die wahrgenommene Last woanders herkommt.
Ist llms.txt eine Alternative zu Rate Limiting? Nein. llms.txt ist ein freiwilliges Konvention-Format, um KI-Systemen priorisierte Inhalte zu benennen, kein technischer Mechanismus zur Traffic-Begrenzung und kein ratifizierter Standard der großen KI-Anbieter.