Was die Firewall vor Ihren Logs verbirgt: der blinde Fleck der Blockaden am Edge

Ein Website-Verantwortlicher öffnet seine Logs, sucht nach GPTBot, ClaudeBot oder PerplexityBot, findet nichts und schließt daraus, dass sich die KI-Dienste nicht für seine Inhalte interessieren. Der Schluss ist oft falsch, und zwar aus einem mechanischen Grund: Wenn eine Firewall oder ein CDN eine Anfrage abweist, endet diese am Rand des Netzes, am Edge, und erreicht den Origin-Server nie. Sie existiert daher in keinem Origin-Log. Das Schweigen der Logs bedeutet nicht, dass die Bots fehlen; es kann genau das Gegenteil bedeuten.

Wie eine Anfrage verschwinden kann

Auf einer Website, die hinter einem CDN wie Cloudflare ausgeliefert wird, durchläuft jede Anfrage mehrere Schichten, bevor sie den Server erreicht. Die Anwendungs-Firewall, beschrieben in der WAF-Dokumentation von Cloudflare, wertet Regeln aus und kann blockieren, umleiten oder eine Challenge ausspielen. Ein Modul zur Bot-Verwaltung, dargestellt in der Bots-Dokumentation, klassifiziert automatisierten Traffic und wendet eine Richtlinie darauf an. Seit 2024 bieten diese Plattformen an, KI-Bots per Klick zu blockieren, wie Cloudflare es in seinem Beitrag über das Blockieren von KI-Bots ankündigte, und viele Websites haben die Option aktiviert, ohne zu messen, was sie bewirkt.

Jede auf dieser Ebene gestoppte Anfrage erhält eine vom CDN fabrizierte Antwort, in aller Regel einen 403 oder eine Challenge-Seite. Der Origin-Server sieht davon nichts. Die Logs von Apache, nginx oder der Anwendung enthalten sie nicht, und ein Werkzeug zur Log-Analyse, das nur den Origin liest, kann sie nicht zählen.

Die drei Fehlschlüsse, die daraus folgen

1. „Bei uns kommt keine KI vorbei.“ Der verbreitetste. Die Website wird in Wirklichkeit besucht, doch jeder Besuch wird vorgelagert abgewiesen. Eine vorsichtshalber aktivierte Regel, mal von einem Dienstleister, mal durch ein Häkchen in einer Oberfläche, kappt stillschweigend jede Möglichkeit, zitiert zu werden.
2. „Unsere Crawl-Erfolgsquote liegt bei 100 %.“ Ein Dashboard, das die vom Origin ausgelieferten 200er-Antworten zählt, zeigt einen perfekten Wert, denn nur die angenommenen Anfragen kommen dort an. Die tatsächliche Quote, Blockaden eingerechnet, kann sehr niedrig sein.
3. „Der Bot hält sich nicht an unsere robots.txt.“ Wird die robots.txt selbst vom Origin ausgeliefert, die erste Anfrage des Bots aber am Edge blockiert, dann hat er sie nie gelesen. Man wirft dem Bot ein Verhalten vor, dessen Ursache im eigenen Haus liegt.

Wie Sie prüfen, was am Edge geschieht

Die Prüfungen, von der einfachsten zur vollständigsten:

• Die CDN-Konfiguration erneut lesen. WAF-Regeln, Modus der Bot-Verwaltung, Optionen „KI-Bots blockieren“, Listen abgewiesener User-Agents. Sie ist so zu lesen, wie sie ist, nicht so, wie man sie eingestellt zu haben glaubt: Auf einer Website, die wir diesen Sommer auditiert haben, kappte eine aus einer früheren Konfiguration geerbte Regel Bots, die im Team niemand blockieren wollte.
• Mit den echten User-Agents testen. Von außerhalb des Netzes selbst eine Anfrage an eine öffentliche Seite senden, dabei den User-Agent jedes KI-Bots angeben, und auf den Antwortcode und dessen Absender schauen. Ein vom CDN gezeichneter 403, während der Origin mit 200 antwortet, ist der direkte Beweis einer Blockade am Edge.
• Die Logs des CDN lesen, nicht nur die des Origin. Die großen CDN legen Traffic-Statistiken offen, die abgewiesene Anfragen enthalten, nach Regel und nach User-Agent, mitunter nach Pfad. Dort zeigen sich die Bots, die man für abwesend hielt. Bei Cloudflare sind diese Daten über die Oberfläche und über die API zugänglich, mit einem Token, das das Leserecht Zone Analytics besitzt; im kostenlosen Tarif erfordert die Aufschlüsselung nach Pfad den Weg über die API.

Ein gemessener Fall

Auf einer anderen Website, einer industriellen, im selben Sommer auditiert, zeigten die Origin-Logs über mehrere Wochen keine einzige Anfrage eines KI-Bots, und das Crawl-Dashboard wies eine perfekte Erfolgsquote aus. Die Logs des CDN erzählten etwas anderes: mehrere hundert Anfragen von KI-Bots, von einer Firewall-Regel mit 403 abgewiesen, von denen es nirgends eine Spur gab. Der anfängliche Schluss, „die KI-Dienste kommen nicht“, war das genaue Gegenteil der Wirklichkeit: Sie kamen regelmäßig und zogen wieder ab, ohne etwas zu lesen. Die Website tauchte in keiner generierten Antwort auf, nicht aus mangelndem Interesse der Suchmaschinen, sondern wegen einer Sicherheitseinstellung. Die Diagnose dauerte eine Stunde; sie hätte auch nie gestellt werden können.

Die Falle der IP-Adresse

Ein zweiter Effekt des CDN erschwert das Lesen der Origin-Logs: Die IP-Adresse, die der Server sieht, ist die des CDN und nicht die des Besuchers, es sei denn, der Server ist so konfiguriert, dass er den Header ausliest, der die Ursprungsadresse transportiert. Fehlt diese Einstellung, scheinen alle Besucher, Menschen wie Bots, von einigen Dutzend Adressen des CDN zu kommen. Die Echtheitsprüfungen, die wir in unserem Artikel über Reverse DNS und veröffentlichte IP-Bereiche beschreiben, werden unmöglich, und ein echter Bot kann für einen Hochstapler gehalten werden oder umgekehrt. Ein proprietärer Header, den das CDN hinzufügt, übersteht in aller Regel sämtliche Zwischenstationen, während ein generischer Header überschrieben werden kann. Bei Cloudflare heißt er CF-Connecting-IP; der generische Header, X-Forwarded-For, kann von jedem Zwischenknoten neu geschrieben werden. Fragen Sie Ihren Hoster nach dem genauen Namen des Headers, den er setzt, und prüfen Sie, ob er tatsächlich bis ins Origin-Log gelangt.

Welche Linie zu halten ist

Die Grundfrage ist redaktionell: Ein Medium, das von KI-Diensten zitiert werden will, hat keinen Grund, deren Such- und Lese-Bots am Edge zu blockieren. Das Training zu blockieren ist eine legitime Entscheidung, aber sie fällt in der robots.txt, User-Agent für User-Agent, wie wir in „robots.txt und KI“ erläutern, und nicht über einen Schalter, der alles abweist, was nach KI aussieht. Eine Blockade am Edge ergibt nur bei erwiesenem Missbrauch Sinn: auffällige Volumina, Identitätsmissbrauch, Scraper, die die robots.txt ignorieren.

Eine Vorsichtsmaßnahme bleibt: auch Hochstapler nicht mit einer breiten Regel auf den User-Agent blockieren. Eine Regel, die jeden „GPTBot“ von einer Adresse außerhalb der von OpenAI veröffentlichten Bereiche abweist, wirkt umsichtig; in der Praxis weist sie an dem Tag auch legitime Anfragen ab, an dem OpenAI einen Bereich ergänzt, den die lokale Liste noch nicht kennt. Die richtige Antwort auf Identitätsmissbrauch ist Messung und Drosselung, keine blinde Abweisung.

Was messen heißt, sobald die Blockade aufgehoben ist

Wenn der Edge durchlässt, werden die Origin-Logs wieder zu einer verlässlichen Quelle, sofern sie die Ursprungsadresse transportieren und den vollständigen User-Agent bewahren. Dann lässt sich je Bot und je Zweck (Training, Suche, Abruf auf Anfrage) zählen, was die KI-Dienste wirklich lesen: welche Seiten, in welchem Takt, mit welchem Antwortcode. Diese Auswertung, und nicht ein Origin-Dashboard, erlaubt die Aussage, dass ein Inhalt von generativen Suchmaschinen erreicht wird. Die Methode führen wir in „Ein Access-Log in 30 Minuten lesen“ aus.

Das Prinzip steht: Ein Origin-Log beweist nur, was bis zum Origin gelangt ist. Alles, was vorher abgewiesen wurde, hinterlässt dort keine Spur, und genau das muss man anderswo suchen, bevor man irgendetwas über die KI-Dienste schließt.