13% der geprüften Seiten blockiert einen KI-Crawler — Korrektur unseres eigenen 40.8%

Aktualisiert August 31, 2026. Die Version dieses Artikels, veröffentlicht am August 20, begann mit "20 von den 49 Seiten, die wir geprüft haben — 40.8%. " Diese Zahl war zweimal falsch. 40.8% war der Anteil der einzelnen Prüfungen, die die Prüfung fehlgeschlagen haben, nicht der Anteil der eindeutigen Seiten, und die Multiplikation zurück auf eine Seitenanzahl erzeugte ein "20 Seiten", das niemand je gezählt hatte. Schlimmer noch, als wir zurückgingen und jede robots. txt in der Stichprobe erneut gegen die Spezifikation gelesen haben, erwiesen sich die 2 Fehler in unserem eigenen Parser als Ursache für die Hälfte der Fehler. Die korrigierten Zahlen sind unten, und die Korrektur ist jetzt die nützlichere Hälfte dieses Artikels. Jede Prüfung, die wir durchführen, lädt robots.txt herunter und liest sie so, wie ein KI-Crawler es tun würde. Am August 31, 2026 haben wir die Datei von allen 48 eindeutigen Domains, die in unserem aktuellen Engine-Fenster geprüft wurden, erneut heruntergeladen, und 45 von ihnen lieferten eine. Von diesen 45, 6 Seiten — 13.3% — schlossen mindestens 1 Haupt-KI-Crawler aus dem gesamten Site. Am anderen Ende haben 8 Seiten keine Regeln, die für KI-Crawler gelten — nicht einmal eine Wildcard-Direktive, die sie befolgen müssten. Das ist 17.8% der Stichprobe. Das lässt 31 Seiten — 68.9% der Stichprobe — mit einer robots.txt, die eine Richtlinie angibt, die ein KI-Crawler tatsächlich lesen wird und keine von ihnen sitewide blockiert. In einem Jahr, in dem ChatGPT Suche, Perplexity und Claude Quellen zitieren, indem sie sie abrufen, ist die Datei, die die meisten Eigentümer seit der Einführung nicht geöffnet haben, heimlich zu einem Sichtbarkeits-Schalter geworden. Weniger Menschen haben sie ausgeschaltet, als wir zuerst berichtet haben. Mehr von ihnen haben sie überhaupt nicht berührt.

Methodik. Die Population umfasst jede eindeutige Domain mit einem abgeschlossenen Audit in unserem aktuellen Engine-Fenster, das von Mai 23 bis August 31, 2026 läuft. Das sind 48 Domains über 228 Berichtläufe. Die gespeicherten Urteile tragen die Antwort des fehlerhaften Parsers, daher ist die obige Tabelle nicht die gespeicherte Gesamtsumme. Es handelt sich um eine gleichzeitige erneute Abfrage der Live-Robots dieser Domains. txt-Dateien, gelesen im August 31 und bewertet mit dem korrigierten Parser. 3 der 48 dienen nicht mehr als Robots. txt überhaupt nicht, weshalb der Nenner 45 ist. Die Stichprobe ist selbstgewählt – das sind Seiten, die jemand ausgewählt hat, um ein Audit durchzuführen – und sie ist von klein bis mittelgroß verzerrt. Behandle die Raten als Richtwerte für den langen Schwanz des Webs statt für das Web im Allgemeinen. Domains werden nicht benannt.

Was unser Parser falsch gemacht hat und wie wir es gefunden haben

Die Prüfung selbst ist einfach. Unsere Engine parst jede robots.txt-Gruppe und bewertet 6 User Agents dagegen: GPTBot, OAI-SearchBot, PerplexityBot, ClaudeBot, Claude-SearchBot und CCBot. Ein Crawler gilt nur dann als blockiert, wenn die Gruppe, die ihn regelt, ein weltweites Disallow: / trägt. Teilweise Sperren wie Disallow: /admin registrieren sich als festgelegte Richtlinie, was gesund ist, und sie werden akzeptiert. Die korrekte Anwendung dieser Definition ist der Punkt, an dem wir versagt haben. Das erneute Lesen aller 45-Dateien ergab 2 unterschiedliche Defekte, die in entgegengesetzte Richtungen zeigen. Ein leerer Disallow: ist keine Sperre. RFC 9309 ist eindeutig, dass eine Regel ohne Pfad ignoriert wird, was Disallow: zur kanonischen Art macht, alles zu erlauben zu sagen. Yoast gibt standardmäßig genau diese Datei aus, und das tun auch mehrere Shared Hosts. Unser Parser behandelte den leeren Wert als gleichwertig zu / und markierte alle 6 Crawler als blockiert. 5 der 10 Sites, die der Engine markiert hatte, führten eine gewöhnliche Allow-All-Datei aus: 3 von ihnen die Yoast-Standardblockierung wortwörtlich, 1 von ihnen eine reine 2-Zeilen-Datei. Eine benannte Gruppe überschreibt das Wildcard. RFC 9309 sagt außerdem, dass ein Crawler der eindeutigsten Gruppe folgt, die ihn benennt, und User-agent: * vollständig ignoriert, wenn eine solche Gruppe existiert. Unser Parser las jede passende Gruppe in Dateiorder und ließ die letzte gewinnen. Das wirkt sich in beide Richtungen aus. Eine große Social-Plattform im Beispiel nennt GPTBot, ClaudeBot und PerplexityBot mit engen Pfadregeln und schließt die Datei dann mit einem Catch-All User-agent: * / Disallow: / – unser Parser gab diesen 3 benannten Crawlern den Catch-All, von dem sie befreit waren. Und die 1 Site wurde in die andere Richtung falsch gezählt: sie verbietet 3 AI-Crawler nach Namen nahe dem oberen Teil ihrer Datei, gibt dann weiter unten lockerere Wildcard-Regeln an und unser Parser ließ das Wildcard einen echten, absichtlichen Block löschen. Diese Site hatte bestanden. Beide Fehler sind jetzt behoben, mit Unit-Tests, die aus den genauen Dateien gebaut wurden, die sie aufgedeckt haben. Der Nettoeffekt auf dieses Beispiel: 5 Sites, die der alte Parser blockiert hatte, sind es nicht, und 1 Site, die er sauber nannte, ist. Die 3 Zahlen nebeneinander, alle aus demselben Fenster: die gespeicherten Urteile der Engine lauten 42.9% von 226 einzelnen Auditläufen und 21.3% von 47 Sites; das erneute Lesen der Live-Dateien mit dem korrigierten Parser ergibt 13.3% von 45 Sites. Nur die letzte ist eine Behauptung über Sites, gemessen mit einem Parser, der die Spezifikation korrekt liest. Eine Eigenschaft der Prüfung überlebt all dies: sie ist immer noch konservativ. Eine WAF-Herausforderung, eine CDN Bot-Regel oder ein Firewall-Block tauchen nie in robots.txt auf, sodass 13,3 % weiterhin ein Bodenwert dafür bleiben, wie viele Sites diese Crawler tatsächlich abweisen. Und eine Site kann immer noch einen Crawler blockieren, ohne seinen Namen zu tippen – ein blanket Wildcard-Disallow, geschrieben für eine Preview-Umgebung, gilt für GPTBot genau wie für alles andere. 2 der 6 bestätigten Blocker erreichen mindestens 1 Crawler auf diese Weise: ein Preview-Host, dessen gesamtes robots.txt eine 3-Zeilen-Blanket-Disallow ist, und eine große Plattform, deren schließender Catch-All die 3 Crawler aufsammelt, die sie nicht benannte.

Eine Regel, geschrieben in 2023, beantwortet die falsche Frage in 2026

Unsere korrigierte Rate liegt jetzt unter dem, was größere externe Stichproben berichten. Eine März 2026 Analyse von 10.000 Sites durch SEO Score Tools fand 18,7 % aktiv blockierend GPTBot und 41,3 % ohne jegliche AI-spezifische robots-Regeln. Beide ihrer Zahlen liegen über unseren – Definitionen unterscheiden sich zwischen Stichproben, unsere Stichprobe ist ein Bruchteil der Größe, und unsere Prüfung zählt eine Wildcard-Gruppe als angewandte Richtlinie, während die ihre nach benannten sucht. Wir behaupten nicht, dass unser 13.3% ihre 18.7% kippt; eine 45-Site-Stichprobe kann das nicht. Was beide Datensätze übereinstimmen, ist die Form: ein Minderheitsanteil des Webs hat eine AI-Zugriffsentscheidung getroffen, ein weiterer Teil hat eine getroffen, ohne es zu wissen, und der Rest wurde nicht gefragt. Der unbeachtete Teil ist die Geschichte, und unsere korrigierten Daten sind vorsichtig, welcher Teil das ist. Die 6 Blockierungen, die wir bestätigt haben, sind überwiegend absichtlich – 4 benennt den Crawler, und 2 von denen führen Cloudflare's verwaltete Content-Signals-Liste aus, die diese Jahr geschrieben wurde und kein Überbleibsel ist. Was wir von 45-Seiten nicht zeigen können, ist, wie viel des weiteren Webs noch eine veraltete Regel trägt; dafür sind die oben genannten externen Beispiele gedacht. Der Mechanismus ist trotzdem erwähnenswert, weil er die veraltete Regel teuer macht. In 2023, als GPTBot erstmals in Serverprotokollen auftauchte und CCBot als Trainingsquelle neu berüchtigt wurde, war die einzige bekannte Folge des Zugriffs die Modellbildung — so wurden Bot-Blocklisten verbreitet, Plugins mit 1-Klick-Umschaltern ausgeliefert, und robots.txt-Dateien erben Disallows, die niemand seitdem erneut gelesen hat. Die Frage, die diese Regeln beantworteten, war „Will ich meinen Inhalt in einem Trainingskorpus haben?“ Die Frage, die in 2026 wichtig ist, ist anders: „Will ich gefunden und zitiert werden, wenn ein Assistent zu meinem Thema antwortet?“ Eine Regel, die für die erste Frage geschrieben wurde, beantwortet jetzt stillschweigend die zweite.

Trainings-Crawler und Such-Crawler verdienen unterschiedliche Antworten

Die 6-Crawler, die wir untersuchen, teilen sich sauber in 2-Aufgaben auf, pro jeder Betreiberpublikation der Bot-Dokumentation:

• Suche und Abruf. OAI-SearchBot indexiert Inhalte, sodass ChatGPT Suche sie aufdecken und verlinken kann — OpenAI Dokumente, die dieser Zugriff, und nur dieser Zugriff, bestimmen, ob Seiten für ChatGPT Suchergebnisse berücksichtigt werden. PerplexityBot baut den Suchindex von Perplexity auf. Claude-SearchBot indexiert, um Claude's suchgestützte Antworten zu verbessern. Das Blockieren eines dieser Crawler entfernt dich aus den Zitaten dieses Assistenten.
• Training. GPTBot sammelt Inhalte, die OpenAI's Modelle trainieren könnten. ClaudeBot führt das äquivalente Crawlen für Anthropic durch. CCBot speist Common Crawl, das offene Korpus hinter vielen Forschungs- und Trainingsdatensätzen. OpenAI ist ausdrücklich, dass das Blockieren von GPTBot keinen Einfluss auf die Aufnahme in ChatGPT Suchergebnisse hat — die beiden Pipelines sind getrennt.

Google führt die gleiche Aufteilung unter verschiedenen Namen durch: seine KI nutzt den normalen Googlebot-Zugriff, während der separate Google-Extended-Token Gemini-Training und Grounding steuert. Wir haben diese Mechanik in unserer Anleitung zu Google's generativer Suche behandelt.

Das Split verwandelt eine vage Angst in eine 2-teilige Entscheidung. Das Blockieren von Trainings-Crawlern ist eine legitime Haltung, wie Ihre Inhalte wiederverwendet werden können, und kostet Sie nichts in der KI-Suche. Das Blockieren von Abruf-Crawlern ist eine Sichtbarkeitsentscheidung – dieselbe Kategorie wie das eigene Noindexing – und verdient die gleiche Überlegung.

Schreiben Sie eine robots.txt, die die Entscheidung dokumentiert

Hier ist eine Richtlinie, die vollständig in der KI-Suche sichtbar bleibt, während sie die Trainingszustimmung zurückhält – die häufigste bewusste Aufteilung, die wir sehen:

# Search & retrieval — open, so assistants can find and cite this site
User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

# Training — withheld; this has no effect on AI search visibility
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

Wenn Sie alles offen haben wollen, sagen Sie es explizit, anstatt es wegzulassen – eine benannte Allow: / Gruppe pro Crawler dokumentiert, dass jemand entschieden hat, was genau die 17,8 % ohne anwendbare Regeln vermissen. 3 Verifizierungs-Schritte schließen den Kreis. Holen Sie https://yoursite.com/robots.txt von außerhalb Ihres Netzwerks und lesen Sie, was tatsächlich in Produktion ausgeliefert wird – CDNs und Plattformen können die Datei in Ihrem Repository einfügen oder überschreiben, und einige Edge-Anbieter liefern 1‑Klick‑AI‑Bot‑Blockierung, die Ihre Anweisungen vollständig außer Kraft setzt. Prüfen Sie alle WAF‑ oder Bot‑Management-Regeln für dieselben 6 User‑Agenten, denn die Erlaubnis in robots.txt bedeutet nichts für einen Crawler, der einen 403 erhält. Führen Sie dann die Prüfung nach jeder Infrastrukturänderung erneut durch; ein Anbieter‑Migrationswechsel kann diesen Schalter umlegen, ohne Ihren Code zu berühren. 1 Hinweis darauf, wie unser Audit die oben beschriebene bewusste Richtlinie liest: die sitewide‑Disallows für GPTBot, ClaudeBot und CCBot werden immer noch als Befund angezeigt. Das ist absichtlich. Ein sitewide AI‑Crawler‑Block sollte immer eine bestätigte Entscheidung sein, und der Befund ist, wo Sie ihn bestätigen – der Fehlermodus, den diese Prüfung zu erkennen versucht, ist der Block, den niemand mehr erinnert, geschrieben zu haben.

Der günstigste Sichtbarkeits‑Audit, den Sie in diesem Jahr durchführen werden

robots.txt ist 1 von 2 Dateien, über die Ihre Seite mit KI‑Systemen kommuniziert – die andere ist llms.txt, wo unsere Daten zeigen 76% von Dateien scheitern bei den Agenten, für die sie geschrieben wurden. Beide teilen die gleiche Fehlersignatur wie die Blöcke in diesem Bericht: einmal geschrieben, syntaktisch plausibel, nie zurückgelesen. So hat auch unser Parser funktioniert, was der unangenehme Teil dieser Korrektur ist – eine Regel, die seit dem Tag, an dem sie geschrieben wurde, nicht erneut gelesen wurde, ist genau das, was diese Prüfung zu erkennen versucht, und die unsere ebenfalls nicht erneut gelesen wurde. Das korrigierte Bild ist auch ermutigender als die Überschrift, die wir zuerst veröffentlicht haben. 4 der 6 Sites, die einen AI‑Crawler sitewide blockieren, indem sie den Crawler explizit benennen, und 2 dieser 4 betreiben Cloudflare’s verwalteten Content‑Signal‑Block – eine 2026 Richtlinie, die jemand gewählt hat, nicht eine 2023 Regel, die niemand erneut gelesen hat. Die versehentlichen Blöcke sind die verbleibenden, und sie sind eine kleine Zahl. Die größere Lücke in diesem Beispiel liegt nicht darin, dass Seiten AI-Crawler ausschließen; es sind die 8 Seiten, deren robots.txt überhaupt nichts enthält, was ein AI-Crawler lesen kann. Das Lesen Ihrer eigenen Datei dauert 2 Minuten; der free report liest sie für Sie, benennt jeden der 6 Crawler und zeigt genau, welche Regel für jeden gilt — so ist die Entscheidung im Protokoll die, die Sie tatsächlich getroffen haben.