Wenn ein Tool „alle KI-Crawler erlaubt“ meldet, kann es „wir konnten es nicht feststellen“ bedeuten

Die zwei Fehler, die identisch aussehen

Wenn ein Tool deinen Server nach /robots.txt fragt, kann dreierlei passieren. Es bekommt die Datei. Es bekommt ein eindeutiges „gibt es nicht“. Oder es bekommt nichts Verwertbares: einen Timeout, einen Verbindungsabbruch, ein 403 von einer Firewall, ein 503 von einem überlasteten Server.

Die ersten beiden sind Antworten. Die dritte ist keine, und der Unterschied ist entscheidend, weil der zweite und der dritte Fall zu entgegengesetzten Schlüssen führen. Ein bestätigter 404 bedeutet tatsächlich, dass Crawler alles abrufen dürfen: keine Datei, keine Regeln, also ist nichts verboten. Ein Timeout bedeutet, dass du die Regeln nicht kennst.

Der Fehler besteht darin, beide Fälle auf einen leeren String zu reduzieren. Durchsuche einen leeren String nach Disallow-Regeln, finde keine, melde „erlaubt“. Die Logik ist in jedem einzelnen Schritt korrekt und liefert eine selbstbewusst falsche Antwort.

Was die Spezifikation wirklich sagt

RFC 9309, die das Robots Exclusion Protocol 2022 standardisiert hat, behandelt diese Fälle getrennt und gibt ihnen entgegengesetzte Bedeutungen.

Abschnitt 2.3.1.3 behandelt den Zustand „unavailable“ (nicht verfügbar): 4xx-Statuscodes, einschließlich 404 und 410. Der Crawler darf auf jede Ressource des Servers zugreifen. Keine Datei, keine Einschränkungen.

Abschnitt 2.3.1.4 behandelt den Zustand „unreachable“ (nicht erreichbar): 5xx-Statuscodes und Netzwerkfehler. Die Formulierung ist ungewöhnlich deutlich: die robots.txt gilt als undefiniert und der Crawler MUSS von einem vollständigen Verbot ausgehen. Nicht „mit Vorsicht fortfahren“. Die strenge Lesart ist die vorgeschriebene, und sie ist das genaue Gegenteil des 404-Falls.

Ein Tool, das einen Timeout wie eine fehlende Datei behandelt, war also nicht etwas zu konservativ. Es hat eine normative Vorgabe umgekehrt.

Warum echte Crawler nachsichtiger sind als die RFC

Google setzt das wörtliche MUSS nicht um, und das solltest du wissen, bevor du bei einem 503 in Panik verfällst.

Das dokumentierte Verhalten von Google: In den ersten zwölf Stunden mit 5xx-Antworten stellt Google das Crawlen der Website ein und versucht es weiter. Die folgenden dreißig Tage nutzt es die letzte gültige Version aus dem Cache. Existiert keine Cache-Version, geht Google davon aus, dass es keine Crawl-Einschränkungen gibt. Nach dreißig Tagen verhält es sich, sofern die Website ansonsten erreichbar ist, als gäbe es überhaupt keine robots.txt.

Das ist eine abgestufte Degradierung, die die RFC erlaubt, aber nicht verlangt. Es bedeutet auch, dass ein kurzer Ausfall dich nichts kostet, solange deine robots.txt vorher erreichbar war und danach wieder erreichbar ist.

Die praktische Erkenntnis ist enger als „ein 503 wirft dich aus dem Index“. Sie lautet: ein dauerhaftes 403 — wie es eine Bot-Sperre erzeugt, das sich nie auflöst und nie in den Cache gelangt — ist ein anderes und deutlich langlebigeres Problem als ein vorübergehender 500.

Der Fall, der wirklich schadet: eine Firewall, die auf alles antwortet

Ein 403 von einer WAF ist der interessante Fehler, weil er aus dem Browser heraus unsichtbar ist. Du rufst deineseite.de/robots.txt auf, siehst die Datei und schließt daraus, dass alles in Ordnung ist. Die Datei wird dir ausgeliefert und allem verweigert, was automatisiert aussieht.

Das ist nicht hypothetisch. Als wir unseren eigenen Checker am 13. September 2026 gegen große Websites laufen ließen, antworteten medium.com, quora.com, g2.com und stackoverflow.com auf unsere Anfrage mit 403. Unser User-Agent ist unauffällig und identifiziert sich ehrlich — und genau deshalb wird er abgewiesen, denn genau darauf zielen Bot-Regeln.

Bemerkenswert ist, wie schnell sich das ändert. nytimes.com, reddit.com und theguardian.com hatten uns am Tag davor abgewiesen und antworten jetzt normal. Jede Liste blockierter Seiten, auch diese, ist eine Momentaufnahme und keine Tatsache über diese Unternehmen — genau das ist das Argument dafür, die eigene Domain zu testen statt aus fremden Ergebnissen zu schließen.

Für OAI-SearchBot und PerplexityBot sind diese Seiten mit hoher Wahrscheinlichkeit erreichbar, weil die großen KI-Crawler IP-Bereiche veröffentlichen und von CDNs auf Allowlists gesetzt werden. Die ehrliche Schlussfolgerung für eine große Website lautet also: „wir können es nicht sehen, aber die echten Crawler wahrscheinlich schon“. Der gefährliche Fall ist der umgekehrte: eine kleine Website hinter einer aggressiven WAF-Standardregel, wo niemand irgendetwas auf eine Allowlist gesetzt hat und wo „unser Checker wurde abgewiesen“ eine echte Warnung ist und kein Fehlalarm.

So prüfst du es selbst mit einem Befehl

Lass den Browser weg — er ist der einzige Client, der garantiert eine freundliche Antwort bekommt. Nutze curl mit einem User-Agent, den eine Bot-Regel erkennt, und schau auf den Statuscode statt auf den Inhalt. Der Schalter -L ist wichtig: viele Domains leiten /robots.txt weiter, und ohne ihn liest du die 301 statt der Datei.

Führe das aus und setze deine Domain ein:

curl -sL -o /dev/null -w "%{http_code}\n" -A "OAI-SearchBot" https://deineseite.de/robots.txt

Ein 200 bedeutet, dass die Datei an etwas ausgeliefert wird, das sich als Crawler ausgibt. Ein 403 oder 503 bedeutet, dass sie es nicht wird — und das ist eine Untersuchung wert, unabhängig davon, was irgendein Tool dir gemeldet hat. Vergleiche es mit derselben Anfrage unter einem Browser-User-Agent: unterscheiden sich die beiden, entscheidet eine Bot-Regel darüber, wer deine Crawl-Anweisungen sieht.

Eine Falle, die du vermeiden solltest: füge kein -I hinzu, um stattdessen eine HEAD-Anfrage zu senden. Im Test antwortete quora.com bei identischer URL und identischem User-Agent auf HEAD mit 403 und auf GET mit 200. Manche Bot-Regeln behandeln HEAD als verdächtiger als GET, ein HEAD-basierter Test erzeugt also genau den Fehlalarm, um den es in diesem Artikel geht. Crawler rufen mit GET ab — teste also mit GET.

Speziell bei OpenAI kannst du weiter gehen: OpenAI veröffentlicht IP-Bereiche pro Bot unter openai.com/searchbot.json, gptbot.json und chatgpt-user.json. Zeigen deine Firewall-Logs Sperren aus diesen Bereichen, ist das Problem bestätigt und nicht nur vermutet.

Was unser Checker tut — und wo er von der Spezifikation abweicht

Unser KI-Sichtbarkeits-Checker gibt für robots.txt einen von drei Zuständen zurück: erfolgreich gelesen, bestätigt nicht vorhanden, oder nicht lesbar. Ein bestätigter 404 erhält die volle Punktzahl, weil das laut RFC tatsächlich unbeschränkten Zugriff bedeutet. Eine nicht lesbare robots.txt erhält eine Teilpunktzahl und wird als nicht verifiziert gemeldet, wobei die Prüfung als fehlgeschlagen und nicht als bestanden gilt.

Bei einem Punkt sollten wir präzise sein, denn dieser Artikel handelt von der Unpräzision anderer. Die RFC sagt, ein Crawler MUSS von einem vollständigen Verbot ausgehen, wenn robots.txt nicht erreichbar ist. Wir melden keine Null. Ein Diagnose-Tool und ein Crawler haben verschiedene Aufgaben: ein Crawler muss entscheiden, ob er abruft, braucht also einen Standardwert, und der sichere Standard ist Fernbleiben. Ein Tool muss dir sagen, was zutrifft — und zutreffend ist, dass der Zustand unbekannt ist. Null zu melden würde eine selbstbewusst falsche Antwort gegen eine andere tauschen.

Das war ein echter Fehler in unserem eigenen Code, keine Hypothese, die wir bei anderen entdeckt haben. Unsere erste Version reduzierte „Abruf fehlgeschlagen“ auf einen leeren String und gab nytimes.com — das uns damals abwies — die perfekte Punktzahl für Crawler-Zugang: gemeldet wurden alle zehn KI-Crawler als erlaubt, obwohl wir gar nichts gelesen hatten. Gefunden haben wir das, indem wir das Tool gegen Seiten laufen ließen, die wir nicht kontrollieren. Das ist der einzige verlässliche Weg, diese Fehlerklasse zu finden.

So bewertest du jeden Checker in diesem Punkt

Du musst niemandes Quellcode lesen. Richte das Tool auf eine Domain, deren robots.txt bekanntermaßen automatisierte Anfragen abweist — die oben genannten Publisher eignen sich gut — und lies, was es behauptet.

Meldet es eine konkrete Zahl erlaubter Crawler, dann meldet es die Auswertung von nichts. Unterscheidet es „keine robots.txt gefunden“ von „robots.txt nicht lesbar“, behandelt es den Fall korrekt. Sagt es gar nichts über robots.txt, hast du weniger gelernt, als dieses Schweigen vermuten lässt.

Das gilt über robots.txt hinaus. Jede Prüfung, bei der die Datenbeschaffung fehlschlagen kann, braucht drei Ergebnisse statt zwei — und im dritten zeigt sich, ob ein Tool gebaut wurde, um dich zu informieren oder um ein beruhigendes grünes Häkchen zu produzieren.