Cloudflare AI Crawl Control: Diese Einstellung versteckt Ihre Seite

Von Manfred Mayer Rieger · Veröffentlicht 1. November 2026

Eine Durchsicht des Cloudflare-Dashboards einer Website, vorgenommen nach zwei voneinander unabhängigen KI-Crawler-Vorfällen im Abstand von fünf Wochen im Jahr 2026, zählte sechs getrennte Einstellungen, von denen jede für sich einen KI-Crawler am Erreichen der Seite hindern kann. Keine der sechs steht in der robots.txt, und keine prüft, wie die anderen fünf konfiguriert sind.

Der Vorfall im September ging auf eine Funktion zurück, die robots.txt automatisch an eine Reihe von Dashboard-Einstellungen anpasst. In dem Moment, in dem sich eine dieser Einstellungen änderte, änderte sich die Datei mit – neue Disallow-Zeilen, eingefügt ohne dass jemand einen Texteditor öffnete, live und indexiert, bevor es jemand bemerkte. Der Vorfall im Oktober, auf derselben Website, ging auf eine völlig andere Einstellung zurück: einen Block-Schalter, der an der Edge unabhängig vom Inhalt der robots.txt mit 403 antwortet, sodass die Datei korrekt blieb und die Crawler trotzdem nicht durchkamen. Zwei Einstellungen, zwei unabhängige Ursachen, dasselbe Ergebnis: eine Website, die glaubte, erreichbar zu sein, und es nicht war.

Was steuert AI Crawl Control eigentlich?

AI Crawl Control gibt einer Website drei Dashboard-Einstellungen – Search, Agent und Training – für den Umgang mit jeder Kategorie von KI-Crawlern, dazu einen Block-Schalter für einzelne benannte Crawler darunter. Welcher benannte Crawler in welche Kategorie fällt und was er mit erlaubten Inhalten anschließend tut, ist an anderer Stelle im Detail beschrieben; hier geht es um den Schalter, der das außer Kraft setzt, unabhängig von der Kategorie. Cloudflares eigene Ankündigung besagt, dass bei neuen Domains mit werbefinanzierten Seiten ab dem 15. September 2026 Training- und Agent-Crawler standardmäßig blockiert werden, während Search-Crawler erlaubt bleiben. Eine Domain, die vor diesem Datum angelegt wurde oder keine Werbung ausspielt, kann eine andere Standardeinstellung haben – weshalb die tatsächliche, aktuelle Einstellung zu prüfen wichtiger ist, als eine anzunehmen.

Auf manchen Tarifen gibt es noch einen vierten Hebel: Pay per crawl, das gelisteten Crawlern Gebühren berechnet und jedem, der nicht gezahlt hat, HTTP 402 zurückgibt. Ein 402 sieht einem robots.txt-Disallow in keiner Weise ähnlich, und wer diesen Reiter nie geöffnet hat, hat auch keinen Grund, damit zu rechnen.

Wie wird eine robots.txt umgeschrieben, ohne dass jemand sie anfasst?

Bot Preference Sync, im August 2026 eingeführt, hält die robots.txt einer Website synchron zu ihren Search-, Agent- und Training-Einstellungen, indem es Regeln direkt in die Datei schreibt – vor das, was die Website bereits selbst veröffentlicht hat. Cloudflares eigene Dokumentation zeigt genau das: einen Block aus automatisch erzeugten Disallow-Zeilen oberhalb der eigenen Regeln der Website, aktualisiert, sobald sich eine Dashboard-Einstellung ändert oder Cloudflare seine Liste bekannter Bots erweitert.

Das ist an sich ein vernünftiges Konzept – robots.txt und Dashboard-Einstellungen sollen übereinstimmen. Der Fehler liegt darin, dass der Abgleich nur in eine Richtung läuft. Wird eine Einstellung aus irgendeinem Grund auf Block gestellt, von wem auch immer mit Dashboard-Zugriff, ändert sich die Datei mit – lautlos, beim nächsten Abruf durch einen Crawler.

Warum trifft dieselbe Website zwei unterschiedliche Einstellungen in zwei Monaten?

Weil AI Crawl Control und Bot Preference Sync nicht die einzigen Stellen sind, an denen ein Crawler aufgehalten werden kann – und die eine zu beheben, ändert nichts an den anderen. Security › Bots hat seinen eigenen Schalter „Block AI scrapers“, unabhängig von AI Crawl Control. Bot Fight Mode und Super Bot Fight Mode können einen Crawler als Nebenwirkung einer ganz anderen Abwehrmaßnahme herausfordern, was als 403 in den Security Events auftaucht, nicht in einem Crawler-Zähler. WAF-Regeln und Rate Limiting können den User-Agent oder die ASN eines Crawlers treffen, ohne dass jemand überhaupt eine Regel mit KI-Bezug formuliert hat. Keine dieser Stellen liest robots.txt, und keine schreibt die Datei – sie beantworten die Anfrage, bevor die Datei je zur Sprache kommt.

Wie unterscheidet eine Prüfung „blockiert“ von „blockiert, ohne dass es jemand weiß“?

Eine Zeile in robots.txt ist eine Erlaubnisaussage, keine Messung dessen, was tatsächlich passiert. Beide für dasselbe zu halten, ist der eigentliche Fehler. Eine Prüfung, die nur robots.txt liest, kann bestätigen, dass ein Crawler erlaubt ist, und trotzdem völlig falschliegen, ob er die Website tatsächlich erreicht – die beiden Fragen müssen getrennt beantwortet werden, durch eine direkte Anfrage an den Server, mit dem echten User-Agent des Crawlers, von außerhalb des CDN.

Genau das tut die Prüf-Engine dieses Produkts: Sie liest, was robots.txt erlaubt, fragt die Seite separat mit jedem erfassten KI-Crawler ab und vergleicht beide Antworten. Erlaubt die Datei einen Crawler, den der Server trotzdem abweist, wird genau diese Kombination – auf dem Papier erlaubt, in der Praxis blockiert – eigenständig markiert, getrennt von einem Crawler, den robots.txt von vornherein ausschließt. Eine aggregierte Zahl, wie oft diese Kombination über geprüfte Websites hinweg vorkommt, gibt es noch nicht; die beiden oben beschriebenen Einstellungen sind bislang einfach der klarste gefundene Fall – entdeckt von Hand, bevor es eine automatische Prüfung gab, die gezielt danach sucht.

Was sollte eine Website auf Cloudflare tatsächlich prüfen?

Fünf Dinge, in dieser Reihenfolge: die Kategorien in AI Crawl Control (Search, Agent, Training, plus einzelne Crawler-Ausnahmen); ob Bot Preference Sync aktiv ist, denn das ist der Mechanismus, der eine Dashboard-Einstellung in eine Dateiänderung verwandelt; Security › Bots und Bot Fight Mode, unabhängig von AI Crawl Control; jede WAF-Regel oder Rate-Limit-Einstellung, die den User-Agent eines Crawlers treffen könnte, ohne irgendeinen KI-Bezug zu erwähnen; und, falls der Tarif es anbietet, ob Pay per crawl für Crawler aktiviert ist, die man nicht abrechnen möchte. Allein robots.txt zu lesen, beantwortet keine dieser Fragen – ein kostenloser robots.txt-Checker zeigt nur, was zuletzt geschrieben wurde, von welcher dieser Funktionen auch immer zuletzt zugegriffen hat, nicht, was der Server mit der folgenden Anfrage tatsächlich tut. Die Methodik-Seite listet genau auf, was von außerhalb des CDN geprüft wird und was nicht.

Von außen zu testen hilft, aber nur eingeschränkt. Eine Seite mit dem Namen eines Crawlers als User-Agent anzufragen und auf 403 zu prüfen, deckt eine Blockierung auf CDN-Ebene schnell auf. Es bleibt trotzdem nur eine Näherung: Cloudflare verifiziert manche Bots, darunter die großen Suchmaschinen, über die IP-Adresse statt über den User-Agent-String, sodass eine gefälschte Anfrage sich anders verhalten kann als der echte Crawler. Die eigenen Allowed- und Blocked-Zähler des Dashboards pro Crawler sind die Zahl, die tatsächlich zählt – und sie brauchen ein bis zwei Tage, um sich nach einer Änderung zu füllen, was lange genug ist, dass jemand, der direkt nach dem Umschalten nachsieht, trotzdem zum falschen Schluss kommen kann.

Eine robots.txt-Datei sagt, was eine Website beabsichtigt. Ob diese Absicht den Kontakt mit dem davorgeschalteten CDN überlebt, ist eine andere Frage – beantwortet in einem anderen Teil des Dashboards, manchmal von einer anderen Person, manchmal Monate später.