Wenn der Hoster den KI-Crawler blockt

Wir haben im September 2026 die Erreichbarkeit unserer eigenen Website für KI-Crawler gemessen — routinemäßig, ohne konkreten Verdacht. Das Ergebnis war nicht das erwartete: Zwei Kennungen kamen nicht durch, und die Ursache lag an einer Stelle, an der niemand zuerst nachsieht.

Dieser Text beschreibt den Diagnoseweg, nicht das Ergebnis. Das Muster ist auf jedes Hosting übertragbar, das ein Panel mit Bot-Filter mitbringt.

Schritt 1: Der Messwert, der nicht passte

Der übliche Test läuft über die robots.txt. Dort stand:

User-agent: *
Allow: /

Also alles offen. Der Test gegen den Host sagte etwas anderes:

„Kein Status" ist wörtlich gemeint: keine 403, keine 429, keine Fehlerseite. curl beendet sich mit Exit-Code 92.

Schritt 2: Wo genau bricht es ab?

Ein ausführlicher Abruf zeigt, wie weit die Verbindung kommt:

curl -sv -A "Mozilla/5.0 (compatible; ClaudeBot/1.0)" https://pixupmedia.com/

* Connected to pixupmedia.com (94.130.4.202) port 443
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* ALPN: server accepted h2
* using HTTP/2
> GET / HTTP/2
* HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

Damit ist die halbe Diagnose erledigt. TCP steht, TLS gelingt vollständig, ALPN handelt HTTP/2 aus — erst die Anfrage selbst wird abgeräumt. Das schließt DNS, Zertifikat, Firewall auf Paketebene und Netzwerkprobleme aus. Übrig bleibt: Der Webserver hat die Anfrage gesehen, gelesen und entschieden, nicht zu antworten.

In nginx gibt es dafür genau eine übliche Anweisung: return 444 — Verbindung schließen, ohne Antwort. Über HTTP/2 erscheint das beim Aufrufer als PROTOCOL_ERROR.

Schritt 3: Worauf reagiert die Regel?

Bevor man etwas ändert, sollte man wissen, wie genau die Bedingung greift. Dieselbe URL, verschiedene Kennungen:

Daraus liest sich die Regel ab: Teilzeichenkette, Groß- und Kleinschreibung egal. Sie trifft die Zeichenfolge ClaudeBot, nicht das Wort Claude. Das erklärt, warum Claude-SearchBot und Claude-User nie betroffen waren.

Zweite wichtige Frage: Gilt die Regel überall?

Auch die robots.txt selbst. Der Crawler konnte also nicht einmal die Datei lesen, die ihm hätte sagen sollen, was erlaubt ist. Das ist der Grund, warum kein robots.txt-Prüfwerkzeug hier etwas findet.

Schritt 4: Die Ursache im Panel

Erst jetzt lohnt der Blick in die Konfiguration. Im Hosting-Panel — bei uns ISPConfig — gibt es je Website unter „Umleitung/Header" eine Option „Bad Bots blockieren" mit einer Auswahlliste. Sie war aktiviert, und alle fünf verfügbaren Einträge waren gewählt:

anthropic-ai
Bytedance
Bytespider
ClaudeBot
Scrapy

Das deckt sich exakt mit der Messung: Genau die Kennungen, die in dieser Liste stehen, wurden abgewiesen.

Wichtig für die Bewertung: Die Liste ist eine Mehrfachauswahl. Einzelne Einträge lassen sich entfernen, ohne die Funktion abzuschalten. Wer das nicht prüft, deaktiviert womöglich den gesamten Filter — und öffnet dabei auch für Kennungen, die man bewusst draußen haben wollte.

Schritt 5: Ändern, aber nur so viel wie nötig

Wir haben zwei Einträge entfernt und drei stehen lassen. Die Option selbst blieb aktiviert.

Die drei verbliebenen sind bewusst gewählt: zwei Crawler mit hoher Crawl-Last und die Standardkennung eines Scraping-Frameworks. Keiner davon trägt zur Sichtbarkeit in Suchmaschinen oder KI-Antworten bei.

Schritt 6: Nachmessen — und zwar den Inhalt

Nach etwa 45 Sekunden griff die Änderung. Die Nachmessung prüft mehr als den Statuscode:

Zwei Dinge sind hier absichtlich mitgemessen:

Die kanonische Weiterleitung. Der Test startet auf der www.-Form, damit auch der Umweg über den 301 mitgeprüft wird. Ein Bot, der beim Redirect scheitert, sieht die Seite nie.

Die Prüfsumme des ausgelieferten HTML. Sie ist über alle zugelassenen Kennungen identisch mit der eines anonymen Abrufs. Damit ist belegt, dass kein reduziertes Bot-Dokument ausgeliefert wird. Ein reiner Statuscode-Test hätte das nicht gezeigt.

Die Prüfliste, wenn Sie den Verdacht haben

1. Nicht mit der robots.txt anfangen. Sie zeigt Ihre Absicht, nicht das Verhalten des Servers.
2. Je Kennung curl gegen den Host, Exit-Code mitlesen. 000 und Exit 92 bedeuten etwas anderes als 403.
3. Bei 000: curl -sv — bis wohin kommt die Verbindung? TLS ok heißt Webserver-Ebene.
4. Regel eingrenzen: Groß-/Kleinschreibung, Teiltreffer, betroffene Pfade. Erst dann wissen Sie, was eine Änderung bewirken wird.
5. Panel-Optionen durchsehen, bevor Sie an der nginx-Konfiguration arbeiten — viele Panels überschreiben Handarbeit beim nächsten Speichern.
6. Prüfen, ob die Sperre granular ist. Alles-oder-nichts ist selten nötig.
7. Nach der Änderung nicht nur den Status messen, sondern den Inhalt.
8. robots.txt an das tatsächliche Verhalten angleichen, damit beide dasselbe sagen.

Warum das mehr als eine Randnotiz ist

Eine Sperre, die keinen HTTP-Status sendet, ist in jedem Bericht unsichtbar, der auf Statuscodes beruht. Sie erscheint nicht in der Search Console, nicht in gängigen SEO-Crawlern und nicht in robots.txt-Testern. Sie fällt auf, wenn jemand gezielt mit der betroffenen Kennung misst — und danach sucht niemand, solange er keinen Grund hat.

Wer Sichtbarkeit in KI-Antworten anstrebt, sollte diese Messung einmal durchführen, bevor er Inhalte produziert. Welche Kennungen dabei relevant sind und wie eine dazu passende robots.txt aussieht, steht in Welche KI-Crawler Ihren Shop besuchen dürfen. Den Rahmen dazu beschreibt GEO & KI-Optimierung.