Cloudflare blockiert KI-Bots: GEO-Sichtbarkeit ab 15.09.2026 schützen

Wer Cloudflare vor seiner Website hat, sollte prüfen, welche Crawler-Regeln dort aktiv sind — Cloudflare kann KI-Bots serverseitig blockieren, unabhängig von der eigenen robots.txt.

Definition: Mit Cloudflare-KI-Bot-Blocking sind in diesem Beitrag die Firewall- und Bot-Management-Funktionen von Cloudflare gemeint, mit denen sich Crawler wie GPTBot, ClaudeBot, PerplexityBot und CCBot serverseitig blockieren lassen. Laut Cloudflares eigenem Blog bietet das Unternehmen Website-Betreibern mehrere Funktionen an, um den Zugriff bekannter KI-Crawler auf ihre Inhalte einzuschränken (https://blog.cloudflare.com/control-content-use-for-ai-training/).

Warum Cloudflare-Regeln direkt auf GEO-Sichtbarkeit wirken

Für Websites mit vorgeschaltetem Cloudflare ist das relevant: Laut Cloudflares eigenem Blog kann das Unternehmen KI-Crawler wie GPTBot, ClaudeBot, Meta-ExternalAgent oder Bytespider direkt über eigene Firewall- und Bot-Management-Regeln blockieren — technisch durchgesetzt und unabhängig davon, was die eigene, freiwillige robots.txt-Regel des Projekts erlaubt (https://blog.cloudflare.com/control-content-use-for-ai-training/). Für Website-Betreiber mit vorgeschaltetem Cloudflare bedeutet das: Eine Cloudflare-Regel kann einen Crawler aussperren, den die eigene robots.txt ausdrücklich zulässt — und diese Diskrepanz lässt sich nicht an der robots.txt-Datei allein erkennen, sondern nur durch einen Blick ins Cloudflare-Dashboard.

Für GEO ist das relevant: Laut der Entwicklerdokumentation von OpenAI betreibt das Unternehmen getrennte Bots mit unabhängig konfigurierbaren robots.txt-Regeln: GPTBot für das Training, OAI-SearchBot für Ergebnisse in der ChatGPT-Suche, OAI-AdsBot für Anzeigen-Landingpages und ChatGPT-User für nutzerausgelöste Abrufe ohne automatisches Crawling (https://developers.openai.com/api/docs/bots). Wer pauschal alle KI-Bots sperrt, blockiert damit möglicherweise auch den Suchindex-Crawler, nicht nur den Trainings-Crawler, und verliert Sichtbarkeit an einer Stelle, die er eigentlich gar nicht schützen wollte.

Ähnlich bei Anthropic: Laut dem Anthropic Help Center betreibt das Unternehmen drei separat blockierbare Bots — ClaudeBot für das Sammeln von Trainingsdaten, Claude-User für nutzerausgelöste Fragen und Claude-SearchBot für die Suchqualität. Eine vollständige Sperre erfolgt über den Eintrag “User-agent: ClaudeBot / Disallow: /” (https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler). Wird stattdessen ein ganzer IP-Bereich pauschal blockiert, greift diese Feinsteuerung nicht mehr.

Wie du robots.txt und Cloudflare-Konfiguration selbst gegenprüfst

Ein praktischer Punkt folgt direkt daraus: Eine robots.txt-Prüfung auf dem eigenen Server zeigt nur, was dort freigegeben ist — sie zeigt nicht, was zusätzlich über Cloudflare-Firewallregeln gesperrt wird. Beide Ebenen lassen sich nur getrennt prüfen.

So lassen sich beide Ebenen an einer eigenen Domain gegenprüfen:

1. robots.txt regulär abrufen und mit den dokumentierten User-Agent-Einträgen für GPTBot, ClaudeBot, PerplexityBot und CCBot abgleichen.
2. Cloudflare-Sicherheitseinstellungen einsehen, insbesondere die Bereiche für Bot-Management, Bot Fight Mode und KI-Crawler-Kontrolle im Dashboard.
3. Beide Ergebnisse gegeneinanderhalten: Erlaubt die robots.txt einen Bot, den eine Cloudflare-Regel gleichzeitig blockiert, entsteht eine Lücke, die sich über die Datei allein nicht erkennen lässt.

Die Prüfung sollte an beiden Stellen ansetzen, nicht nur an einer — sonst bleibt eine mögliche Diskrepanz zwischen Datei- und Netzwerkebene unentdeckt.

Was du bei robots.txt und llms.txt konkret prüfen solltest

Zwei Dateien, zwei unterschiedliche Zwecke — beide gehören auf die Kontrollliste, wenn Cloudflare zwischengeschaltet ist.

Google erklärt in der offiziellen Dokumentation zu KI-Funktionen in der Suche, dass robots.txt-Direktiven für Googlebot das primäre Steuerungsinstrument sind, verweist für die Begrenzung von KI-Training aber separat auf Google-Extended sowie auf Meta-Tags wie nosnippet, data-nosnippet und max-snippet zur Einschränkung angezeigter Inhalte (https://developers.google.com/search/docs/appearance/ai-features, Stand 2025-12-10).

llms.txt ist ein eigenes Format mit anderer Funktion. llmstxt.org beschreibt llms.txt als eigenes Format mit einfacher Markdown-Struktur, das Assistenzsystemen zusätzliche Informationen zu einer Website bereitstellen soll (https://llmstxt.org/). Die Seite grenzt das Format ausdrücklich von robots.txt ab: robots.txt regelt, welcher automatisierte Zugriff akzeptabel ist, während llms.txt Informationen liefert, die ein Assistenzsystem bei Bedarf abruft. Für die reine Zugriffssteuerung von GPTBot, ClaudeBot oder PerplexityBot bleibt robots.txt damit das maßgebliche Instrument; llms.txt ergänzt es um ein separates, freiwilliges Informationsangebot. Mehr Details dazu findest du im Beitrag zu llms.txt für Website und KI-Crawler.

Bei Perplexity kommt eine zusätzliche Besonderheit hinzu: Laut der offiziellen Dokumentation unterscheidet Perplexity zwischen PerplexityBot, der für Suchergebnisse crawlt und robots.txt respektiert, und Perplexity-User, der nutzerausgelöste Abrufe durchführt und robots.txt-Regeln generell ignoriert (https://docs.perplexity.ai/docs/resources/perplexity-crawlers). Eine Cloudflare-Regel, die auf User-Agent-Strings zielt, kann diesen Unterschied technisch abbilden, vorausgesetzt, sie wird auch entsprechend granular konfiguriert und nicht als Sammelregel “alle KI-Bots sperren” angelegt.

Crawler	Zweck laut Anbieter	Separat steuerbar?
GPTBot (OpenAI)	Training	Ja, getrennt von OAI-SearchBot/OAI-AdsBot
OAI-SearchBot (OpenAI)	ChatGPT-Suchergebnisse	Ja
ClaudeBot (Anthropic)	Trainingsdatensammlung	Ja, getrennt von Claude-User/Claude-SearchBot
PerplexityBot (Perplexity)	Suchergebnisse, respektiert robots.txt	Ja
Perplexity-User (Perplexity)	Nutzerausgelöste Abrufe, ignoriert robots.txt i.d.R.	Separat, aber nicht über robots.txt steuerbar
CCBot (Common Crawl)	Allgemeine Web-Archivierung	Ja

Quelle für CCBot: Laut Common-Crawl-FAQ prüft der Crawler zuerst robots.txt und lässt sich über den Standardeintrag User-agent: CCBot / Disallow: / blockieren (https://commoncrawl.org/faq/, https://commoncrawl.org/ccbot).

Ein Rechenbeispiel zur Einordnung: Angenommen, eine Website mit 200 indexierten Unterseiten setzt eine pauschale Cloudflare-Regel “Known AI Bots blockieren” ein und geht davon aus, dass diese nur Trainings-Crawler betrifft. Nimmt man an, dass eine solche Sammelregel technisch alle als “KI-Bot” klassifizierten User-Agents gleich behandelt, könnte sie auch Search- und User-Bots erfassen — nicht nur den Trainings-Crawler. In einem solchen Szenario wäre im ungünstigsten Fall der komplette Seitenbestand für alle drei Zugriffsarten gleichzeitig gesperrt. Ob das tatsächlich eintritt, hängt von der genauen Cloudflare-Regelkonfiguration ab; die Zahl 200 ist hier ein Modellwert, kein Messergebnis.

Was bei robots.txt-Konfigurationen regelmäßig als technisches Findings-Muster auffällt

Bei der technischen Prüfung von Websites für KI-Sichtbarkeit gehören robots.txt-Konfiguration und Crawlability-Signale zu den Punkten, die sich unabhängig vom eigentlichen Content überprüfen lassen. Solche Prüfungen sind für registrierte Nutzer kostenlos auf geaio.de/erklaert einsehbar.

Daraus lässt sich als Fazit ableiten: robots.txt und eine vorgelagerte Firewall-Konfiguration wie bei Cloudflare bilden zwei getrennte Steuerungsebenen — die Datei regelt, was der Ursprungsserver zulässt, während Cloudflare-Regeln zusätzlich und unabhängig davon entscheiden, was bereits am Netzwerkrand blockiert wird. Und wie die oben zitierten Entwicklerdokumentationen von OpenAI und Anthropic zeigen, bestimmt zusätzlich, welcher der mehreren separat steuerbaren Bots überhaupt anfragt. Wer nur robots.txt prüft, sieht deshalb nicht, ob eine Cloudflare-Regel zusätzlich greift.

Wer prüfen will, ob eigene Crawler-Regeln tatsächlich greifen, findet ergänzend Hintergrund im Beitrag zu robots.txt für KI-Crawler sowie zur Frage, ob und wie stark Crawler überhaupt begrenzt werden sollten, im Beitrag zu Rate Limiting für KI-Crawler.

Häufig gestellte Fragen

Blockiert Cloudflare KI-Bots automatisch, ohne dass ich etwas einstelle? Das hängt von Plan und Konfiguration ab. Cloudflare bietet nach eigenen Angaben mehrere Funktionen an, mit denen sich der Zugriff bekannter KI-Crawler einschränken lässt (https://blog.cloudflare.com/control-content-use-for-ai-training/). Prüfe im Cloudflare-Dashboard aktiv, welche Bot-Regeln aktiv sind — verlass dich nicht allein auf deine robots.txt-Datei.

Reicht eine korrekte robots.txt, wenn Cloudflare vorgeschaltet ist? Nein, nicht zwangsläufig. Cloudflare kann KI-Crawler über eigene Firewall- und Bot-Management-Regeln blockieren, unabhängig davon, was in der robots.txt-Datei steht. robots.txt-Freigabe und Cloudflare-Konfiguration sind zwei getrennte Ebenen und müssen deshalb auch einzeln geprüft werden.

Warum reicht eine Regel für “alle KI-Bots blockieren” nicht aus? Weil Anbieter wie OpenAI und Anthropic ihre Crawler laut eigener Dokumentation in mehrere, funktional unterschiedliche Bots aufgeteilt haben — Training, Suche, Nutzeranfragen. Eine Sammelregel kann deshalb mehr treffen als beabsichtigt, etwa auch den Suchindex-Crawler, wenn Trainings- und Search-Bot wie oben beschrieben unterschiedliche User-Agents verwenden.

Ersetzt llms.txt die robots.txt-Steuerung? Nein. llmstxt.org beschreibt llms.txt als eigenes Format mit einfacher Markdown-Struktur, das robots.txt ausdrücklich nicht ersetzt, sondern ergänzt: robots.txt regelt den Zugriff, llms.txt liefert zusätzliche Informationen für Assistenzsysteme. Für die Zugriffssteuerung der einzelnen Bots bleibt robots.txt damit das entscheidende Instrument.