KI-Crawler blockiert: WAF und CDN als versteckte Sperre

Wenn KI-Crawler trotz offener robots.txt nicht auftauchen, blockiert oft eine Web Application Firewall oder ein CDN die Anfragen, bevor sie Ihre Seite erreichen. Erkennbar ist das an Statuscodes wie 403 oder 429 für Bot-User-Agents in den Logs. Die Lösung ist eine gezielte Freigabe der gewünschten Bots, nicht das Abschalten der Firewall.

Zwei Ebenen, zwei Entscheidungen

Die robots.txt und die Firewall beantworten unterschiedliche Fragen. Die robots.txt sagt: “Ich möchte, dass dieser Bot kommt oder wegbleibt.” Das Robots Exclusion Protocol beschreibt das ausdrücklich als freiwillige Regel. Die Firewall sagt: “Diese Anfrage lasse ich durch oder nicht.” Sie entscheidet oft nach Herkunft, Verhalten oder Reputation, nicht nach Ihren Wünschen für KI-Sichtbarkeit. Ein Bot kann also auf Ebene eins willkommen und auf Ebene zwei ausgesperrt sein.

Typische Auslöser sind Bot-Schutz-Voreinstellungen von Hostern und CDNs, die Rechenzentrums-IP-Bereiche, hohe Abrufraten oder unbekannte User-Agents als Risiko behandeln. Da KI-Crawler genau so auftreten, werden sie mitgesperrt. Welche Voreinstellungen Ihr Anbieter hat, lesen Sie in dessen Dokumentation; wir treffen dazu keine Aussagen über einzelne Produkte.

Ebene	Wer entscheidet	Wirkung	Wo prüfen
robots.txt	Sie, als Bitte	Freiwillig, kooperierende Bots	Datei, Checker
WAF, CDN, Bot-Schutz	Regelwerk des Dienstes	Hart, vor der Seite	Dashboard, Logs
Webserver-Regeln	Konfiguration	Hart, auf dem Server	Konfigurationsdateien
Anwendung (Plugin)	Software auf der Seite	Hart oder weich	Plugin-Einstellungen

So finden Sie die Sperre

1. robots.txt prüfen. Zuerst die einfache Ebene: Lassen Sie die Datei mit dem AI Crawler Checker auswerten. Wenn sie die Bots zulässt, liegt das Problem woanders.
2. Logs lesen. Suchen Sie nach den Bot-Namen und schauen Sie auf die Statuscodes. Die Methode steht in der Logfile-Analyse für KI-Crawler. Viele 403 oder 429 deuten auf eine Sperre hin.
3. CDN- oder WAF-Logs prüfen. Dort stehen oft Abweisungen, die der Webserver nie sieht. Wenn Ihr Server keine Bot-Abrufe zeigt, die CDN-Logs aber schon, ist die Ursache gefunden.
4. Regeln ansehen. Suchen Sie nach Bot-Schutz, Rate-Limits, Länder- und IP-Filtern und Herausforderungsseiten (Captchas), die ein Bot nicht lösen kann.
5. Gegenprobe. Testen Sie mit einem Aufruf, der einen Bot-User-Agent setzt, etwa mit curl, ob Sie eine Fehlerantwort erhalten. BusinessMCP beschreibt eine solche Prüfung mit curl -A "GPTBot/1.1" in seinem Leitfaden zum serverseitigen Tracking von KI-Crawlern. Beachten Sie: Ein Test mit gefälschtem User-Agent aus Ihrem Netz zeigt nicht, wie die echten Bots aus anderen Netzen behandelt werden.

Key takeaway: Eine offene robots.txt und eine blockierende Firewall widersprechen sich, und die Firewall gewinnt immer.

Lösung: gezielt freigeben

Das Ziel ist nicht “alle Bots durchlassen”, sondern “die gewünschten Bots erkennbar durchlassen”. Gehen Sie so vor:

1. Liste erstellen. Welche Bots wollen Sie? Orientieren Sie sich an Ihrer Entscheidung aus robots.txt für KI-Crawler.
2. Herkunft prüfen. Betreiber wie OpenAI und Perplexity veröffentlichen laut OpenAI-Dokumentation und Perplexity-Dokumentation Angaben zu ihren Bots; BusinessMCP erwähnt veröffentlichte IP-Bereiche zur Verifikation. Nutzen Sie diese, statt dem User-Agent zu vertrauen.
3. Regel schreiben. Erlauben Sie die verifizierten Bots in der WAF. Lassen Sie alles andere unter Ihrem normalen Schutz.
4. Testen. Beobachten Sie die Logs in den folgenden Tagen.
5. Dokumentieren. Notieren Sie Regel, Datum und Verantwortliche.

Sicherheit nicht aufgeben

Ein Bot, der sich als GPTBot ausgibt, ist nicht automatisch GPTBot. Wer nur nach User-Agent freigibt, öffnet Scrapern die Tür. Deshalb ist die Prüfung per IP-Bereich wichtig. Wenn Sie das nicht leisten können, ist die konservative Variante, nur die Such- und Abruf-Bots zu erlauben, die für Ihre Sichtbarkeit zählen, und den Rest geschützt zu lassen. Die Unterschiede der Bots erklärt der Beitrag zu OAI-SearchBot und ChatGPT-User.

Gegenteil: Sie wollen sperren

Auch der umgekehrte Fall gehört hierher. Wer Trainings-Crawler aussperren will und sich nicht auf Freiwilligkeit verlassen mag, kann Regeln in der WAF ergänzen. Das ist eine bewusste Entscheidung mit Wartungsaufwand, denn Bots ändern ihre Namen und Netze. Wer lediglich die Absicht kommunizieren will, ist mit der robots.txt gut bedient, wie im Beitrag, ob Sie GPTBot blockieren sollten, dargelegt.

Typische Fehler beim Freigeben

• Zu breite Regel. “Alle Rechenzentrums-IPs erlauben” öffnet mehr als gewollt.
• Regel ohne Ablaufdatum. Netze ändern sich, Regeln veralten.
• Nur ein Standort. Haben Sie mehrere Domains oder Subdomains, gilt die Regel vielleicht nicht für alle.
• Kein Vorher-Nachher. Ohne Logs vor der Änderung können Sie den Effekt nicht belegen.

Dauerhafte Kontrolle

Wer mehrere Auftritte betreut, sollte den Zugang regelmäßig prüfen. Der AI Crawler Checker von BusinessMCP lässt sich laut Anbieter als API-Aufruf nutzen, für 0,01 US-Dollar pro Aufruf; neue Konten erhalten laut Seite 5 US-Dollar Startguthaben für 7 Tage. Damit lässt sich die Prüfung von robots.txt-Freigaben automatisieren. Die Firewall-Ebene sieht er nicht: Er liest die Freigaben der Datei, nicht das Verhalten Ihrer Infrastruktur. Beide Sichten brauchen Sie. Und wenn trotz freier Wege keine Nennungen entstehen, geht es weiter mit Website wird in ChatGPT nicht gefunden.

Abstimmung zwischen Marketing und IT

In vielen Betrieben liegt die Firewall bei der IT oder beim Hoster, die Sichtbarkeit beim Marketing. Das führt zu typischen Missverständnissen: Marketing meldet “KI-Bots sind erlaubt”, weil die robots.txt offen ist. Die IT hat den Bot-Schutz zugleich verschärft, weil es Scraping-Probleme gab. Beide haben recht, und das Ergebnis ist trotzdem eine Sperre. Vermeiden lässt sich das mit einer gemeinsamen Liste: welche Bots sind erwünscht, welche geduldet, welche unerwünscht. Die Liste gehört in ein Dokument, das beide Seiten kennen. Außerdem hilft ein einfacher Ablauf für Änderungen: Wer eine Regel ändert, trägt Datum und Grund ein und prüft anschließend die Logs.

Kurzer Gegencheck mit dem Checker

Wenn Sie sich unsicher sind, ob die Ursache auf Ebene der Datei oder der Infrastruktur liegt, trennen Sie die Fragen. Der AI Crawler Checker von BusinessMCP beantwortet die erste Frage: Was erlaubt meine robots.txt? Die zweite beantworten Ihre Logs: Was kommt tatsächlich an? Erst wenn beides zusammenpasst, ist der Zugang sauber. Das Ergebnis beider Prüfungen sollten Sie mit Datum festhalten, damit Sie nach einer Änderung vergleichen können.