Alle KI-Bots blockieren? Damit blockieren Sie vielleicht gerade Ihre Reichweite

„Wir blockieren einfach alle AI-Bots.“

Das klingt nach einer klaren Datenschutz- oder Content-Strategie. Technisch kann es aber genau das Gegenteil sein: Eine einzige pauschale Regel kann gleichzeitig Modelltraining verhindern, Suchsichtbarkeit reduzieren, nutzerinitiierte Agenten ausbremsen und später niemandem mehr erklären, warum eine Website in einem KI-Suchprodukt nicht auftaucht.

2026 wird dieses Thema sichtbarer, weil Anbieter ihre Crawler inzwischen stärker nach Zweck trennen. OpenAI unterscheidet beispielsweise zwischen OAI-SearchBot für ChatGPT-Suche und GPTBot als Signal für potenzielles Modelltraining. Google verwendet Google-Extended als eigenen robots.txt-Token für bestimmte Gemini-Nutzungen, ohne damit die normale Google-Suche zu beeinflussen. Cloudflare unterscheidet inzwischen sogar ausdrücklich zwischen AI-Search, Agent und Training und hat für den 15. September 2026 neue Standardregeln für neue Domains angekündigt.

Die operative Frage lautet deshalb nicht mehr:

„Dürfen KI-Bots auf die Website?“

Sondern:

„Welche automatisierten Systeme dürfen welche Inhalte für welchen Zweck abrufen – und wie wird diese Entscheidung tatsächlich durchgesetzt?“

Das erste Missverständnis: robots.txt ist keine Firewall

Die Robots Exclusion Protocol-Spezifikation RFC 9309 definiert robots.txt als Mechanismus, mit dem Website-Betreiber Crawlern Regeln für den Zugriff auf URI-Pfade mitteilen können.

Entscheidend ist ein Satz, der in vielen Website-Konfigurationen praktisch vergessen wird: Die Regeln sind keine Zugriffsautorisierung.

Wer eine URL wirklich geheim, intern oder geschützt halten muss, braucht Authentifizierung, Netzwerkregeln, WAF-Regeln oder eine andere technische Zugriffskontrolle. Eine Zeile wie Disallow: /intern/ verhindert nicht, dass jemand die URL mit einem normalen HTTP-Client aufruft.

Das gilt für klassische Suchmaschinen genauso wie für AI-Crawler.

robots.txt ist eine veröffentlichte Präferenz für konforme Crawler. Sie ist wertvoll – aber sie ist kein Schloss.

Das zweite Missverständnis: „AI“ ist ein einzelner Zweck

Ein automatisierter Abruf kann heute sehr unterschiedliche Funktionen haben.

1. Suche und Zitierbarkeit

Ein Such-Crawler sammelt Inhalte, damit eine Seite später in Suchergebnissen, Zusammenfassungen oder Antworten gefunden und verlinkt werden kann.

OpenAI dokumentiert aktuell, dass Website-Inhalte für Zusammenfassungen und Snippets in ChatGPT-Suche nicht über OAI-SearchBot blockiert werden sollten. OpenAI weist außerdem darauf hin, dass ein Host oder CDN den veröffentlichten Crawler-Traffic technisch durchlassen muss.

Für Betreiber ist das eine Reichweitenentscheidung.

Wer OAI-SearchBot pauschal blockiert, sollte nicht gleichzeitig erwarten, dass Inhalte zuverlässig über diesen Crawl-Pfad in ChatGPT-Suche entdeckt und zitiert werden.

2. Modelltraining

Training ist eine andere Nutzung.

OpenAI nennt dafür GPTBot als relevanten User-Agent. Publisher sollen GPTBot für Websites oder Seiten ausschließen, die sie von potenziellem Training ausnehmen möchten.

Google verfolgt ein ähnliches Prinzip mit einem separaten Control-Token: Google-Extended. Laut Google beeinflusst dieser Token nicht die Aufnahme einer Website in die normale Google-Suche und ist kein Ranking-Signal. Er steuert stattdessen bestimmte Nutzungen bereits von Google gecrawlter Inhalte für zukünftige Gemini-Modelle und für bestimmte Grounding-Funktionen.

Genau diese Trennung ist wichtig:

Suche zulassen und Training ablehnen kann technisch eine bewusste Kombination sein.

Ein globales User-agent: * / Disallow: / kann diese Nuance zerstören.

3. Agenten und nutzerinitiierte Abrufe

Ein Agent verhält sich wieder anders. Er kann in Echtzeit handeln, weil ein Nutzer gerade etwas erledigen möchte: Informationen lesen, eine Buchung vorbereiten, eine Seite analysieren oder ein Formular verstehen.

Cloudflare unterscheidet solche Agent-Aktivität inzwischen als eigene Kategorie neben Search und Training.

Das ist ein hilfreiches Architekturmodell, selbst wenn Sie Cloudflare gar nicht einsetzen: Ein Bot, der heute auf einen konkreten Nutzerauftrag reagiert, ist funktional etwas anderes als ein Crawler, der Millionen Seiten für einen späteren Index oder Trainingsdatensatz einsammelt.

Wer alles unter „AI bot“ zusammenfasst, verliert diese Geschäftsentscheidung.

Warum das gerade jetzt relevant ist

Cloudflare hat angekündigt, seine AI-Bot-Standards für neue Domains ab dem 15. September 2026 zu ändern. Dabei sollen Search-Bots grundsätzlich erlaubt bleiben, während als Training oder Agent klassifizierte Bots auf Seiten mit Werbung standardmäßig blockiert werden. Für gemischte Crawler, die sowohl Suche als auch Training betreiben, gelten zusätzliche Regeln.

Das ist nicht automatisch die richtige Policy für jede Website.

Es zeigt aber, wohin die Infrastrukturentwicklung geht: weg vom einen „AI-Bot“-Schalter und hin zu einer zweckbezogenen Steuerung.

Für Website-Betreiber bedeutet das: Die Bot-Policy wird Teil der Content-, SEO-, Privacy- und Plattformstrategie.

Sechs typische Red Flags

Red Flag 1: Eine pauschale Blockregel wurde „zur Sicherheit“ eingebaut

In robots.txt steht:

User-agent: *

Disallow: /

Oder ein CDN-Feature blockiert „AI Bots“, ohne dass jemand weiß, welche Kategorien darunter fallen.

Das kann sinnvoll sein, wenn die Website bewusst keinerlei automatisierte Indexierung erlauben soll. Für die meisten öffentlichen Unternehmensseiten ist es jedoch zu grob.

Fragen Sie stattdessen:

• Soll die Seite in klassischer Suche erscheinen?
• Soll sie in AI-Suche oder Antwortsystemen auffindbar sein?
• Soll sie für Modelltraining verwendet werden dürfen?
• Sollen Agenten im Auftrag eines Nutzers zugreifen können?
• Gibt es Bereiche, die grundsätzlich nicht von Bots besucht werden sollen?
• Welche Entscheidung ist technische Policy, welche ist Content-Policy?

Red Flag 2: robots.txt und WAF widersprechen sich

Die robots.txt erlaubt einen Suchcrawler, aber die WAF blockiert dessen IPs oder User-Agent trotzdem mit 403.

Dann ist die veröffentlichte Erlaubnis praktisch bedeutungslos.

Das umgekehrte Problem ist ebenfalls möglich: robots.txt bittet einen Crawler, einen Bereich nicht abzurufen, die WAF lässt ihn technisch dennoch vollständig passieren. Bei konformen Crawlers reicht die Regel vielleicht. Bei nicht konformen Scrapers nicht.

Ein Audit muss deshalb beide Ebenen vergleichen:

Was sagen wir? Und was erzwingt die Infrastruktur tatsächlich?

Red Flag 3: Search und Training werden unbeabsichtigt gekoppelt

Ein Team möchte Modelltraining ausschließen und blockiert deshalb alle bekannten AI-Crawler.

Damit kann gleichzeitig ein Suchcrawler blockiert werden, der eigentlich Referral-Traffic oder Sichtbarkeit bringen sollte.

OpenAI und Google bieten heute getrennte Steuerungsmöglichkeiten genau für diese Fälle.

Das bedeutet nicht, dass jede Website AI-Suche erlauben sollte. Es bedeutet nur, dass die Entscheidung bewusst getroffen werden kann.

Red Flag 4: Die Policy existiert nur für die Hauptdomain

www.example.de/robots.txt ist sauber gepflegt. Gleichzeitig laufen:

• shop.example.de
• docs.example.de
• app.example.de
• help.example.de
• cdn.example.de
• alte Kampagnen-Hosts
• Preview- und Staging-Systeme

mit ganz anderen Regeln oder gar keiner Policy.

RFC 9309 bindet robots.txt an den jeweiligen Service beziehungsweise Host. Eine Regel auf der Hauptdomain ist keine globale Unternehmensrichtlinie.

Red Flag 5: Sensible Inhalte werden nur über robots.txt „geschützt“

Ein Kundenportal, Export, internes PDF oder Staging-Verzeichnis steht auf Disallow.

Das ist keine Zugriffskontrolle.

Wenn der Inhalt nicht öffentlich sein soll, muss die Antwort technisch geschützt sein: Authentifizierung, Autorisierung, private Storage-URLs, Netzwerkregeln oder vergleichbare Maßnahmen.

Ein Bot-Audit sollte deshalb immer nach Pfaden suchen, deren Betreiber offenbar Vertraulichkeit über Crawling-Regeln statt echte Security herstellen wollen.

Red Flag 6: Niemand kontrolliert die Auswirkungen

Die Policy wurde vor sechs Monaten geändert, aber niemand schaut auf:

• Crawl-Logs
• WAF-Events
• 403- und 429-Raten
• Referrals aus AI-Suche
• Suchsichtbarkeit
• neue oder geänderte User-Agents
• Hostnamen ohne robots.txt
• blockierte, aber weiterhin angefragte Pfade

Dann ist die Policy eine Konfigurationsdatei, kein Betriebsprozess.

Ein brauchbares Entscheidungsmodell

Statt „AI erlauben oder blockieren“ hilft eine kleine Matrix.

Öffentliche redaktionelle Inhalte

Beispiel: Magazin, Ratgeber, Produktseiten, Leistungsseiten.

Mögliche Entscheidung:

• klassische Suche: erlauben
• AI-Suche: erlauben
• Training: separat entscheiden
• Agenten: meist erlauben, solange Missbrauch und Last kontrolliert sind
• technische Rate Limits: ja
• sensible Parameter oder Adminpfade: blockieren beziehungsweise schützen

Bezahlte oder lizenzierte Inhalte

Beispiel: Mitgliederbereich, Premium-Datenbank, bezahlte Reports.

Hier sollte die Hauptkontrolle nicht robots.txt, sondern Authentifizierung und Autorisierung sein.

Zusätzliche Bot-Policies können sinnvoll sein, ändern aber nicht die Grundregel: Inhalte hinter einer Berechtigungsgrenze müssen auch ohne Bot-Kooperation geschützt sein.

Nutzerbezogene oder vertrauliche Bereiche

Beispiel: Dashboard, Bestellungen, Mandate, Gesundheits- oder Personaldaten.

Crawler-Policy ist hier nur Randthema. Solche Inhalte gehören nicht öffentlich erreichbar.

Wenn ein User-Agent-Wechsel genügt, um Zugriff zu erhalten, liegt ein Security-Problem vor.

Öffentliche APIs und Dokumentation

Bei APIs, Dokumentation oder Entwicklerportalen kann AI-Sichtbarkeit sogar strategisch erwünscht sein. Gleichzeitig können aggressive Crawler API-Kosten oder Last verursachen.

Dann braucht es differenzierte Kontrollen:

• Dokumentation crawlbar
• produktive API authentifiziert
• Demo-Endpunkte limitiert
• Rate Limits
• Bots separat messbar
• keine Secrets in Beispielen oder öffentlichen Schemas

So führen Sie einen AI-Crawler-Audit durch

1. Alle Hostnamen erfassen

Nicht nur die Marketingdomain. Prüfen Sie Subdomains, Hilfecenter, Shop, App, API-Dokumentation, alte Domains, CDN-Hosts und Staging.

Für jeden Host:

• existiert /robots.txt?
• liefert er 200 und text/plain?
• enthält er erwartete Gruppen?
• widerspricht er anderen Hosts?

2. User-Agent-Regeln inventarisieren

Dokumentieren Sie bewusst mindestens die Crawler, die für Ihre Strategie relevant sind.

Bei OpenAI kann die Entscheidung beispielsweise zwischen OAI-SearchBot und GPTBot unterschiedlich ausfallen.

Bei Google kann Google-Extended unabhängig von der normalen Search-Crawling-Strategie bewertet werden.

Die konkrete Liste sollte regelmäßig gegen die aktuellen Anbieter-Dokumentationen geprüft werden. User-Agents und Produktgrenzen können sich ändern.

3. Tatsächlichen Zugriff testen

Eine saubere robots.txt beweist noch nicht, dass der Request durchkommt.

Prüfen Sie:

• CDN
• WAF
• Bot Management
• Rate Limits
• Geo-Regeln
• JavaScript Challenges
• Captchas
• Reverse Proxy
• Origin-Firewall

Ein legitimer Crawler kann korrekt erlaubt sein und trotzdem an einer Sicherheitsregel hängen bleiben.

4. Zwischen Präferenz und Enforcement unterscheiden

Für jeden Pfad sollte klar sein:

Ist das eine Bitte an einen konformen Crawler oder eine echte technische Sperre?

Diese Frage verhindert besonders gefährliche Fehlkonfigurationen.

5. Auswirkungen messen

Nach einer Änderung sollten mindestens einige Wochen lang beobachtet werden:

• welche Bots tatsächlich kommen
• welche Pfade sie abrufen
• welche Regeln blockieren
• ob sich Referral-Traffic verändert
• ob Such- oder AI-Sichtbarkeit leidet
• ob Origin-Last sinkt oder steigt
• ob legitime User-Journeys durch Bot-Schutz beschädigt werden

Was Website-Pflichtencheck prüfen würde

Ein AI-Crawler- und robots.txt-Check kann unter anderem untersuchen:

• robots.txt auf Hauptdomain und Subdomains
• Such-, Training- und Agenten-Policies
• OpenAI- und Google-spezifische Regeln
• Inkonsistenzen zwischen robots.txt, WAF und CDN
• öffentlich erreichbare Pfade, die fälschlich nur per Disallow „geschützt“ sind
• Bot- und Crawl-Logs
• 403, 429 und Challenge-Verhalten
• Hostnamen ohne definierte Policy
• AI-Such-Referral-Messung
• Indexierungs- und Sichtbarkeitsfolgen
• Dokumentation und Verantwortlichkeit für Policy-Änderungen

Das Ziel ist nicht, „AI freundlich“ oder „AI feindlich“ zu sein.

Das Ziel ist eine präzise technische Entscheidung, welche Nutzung gewollt ist und welche nicht.

Ein öffentlicher Ratgeber kann in Suche und AI-Suche sichtbar bleiben, während Training ausgeschlossen wird. Ein Kundenportal kann für alle Crawler gesperrt sein und zusätzlich echte Zugriffskontrolle besitzen. Ein Agent kann auf öffentliche Inhalte zugreifen dürfen, ohne dass dadurch eine Trainingsfreigabe entsteht.

Wer 2026 noch einen einzigen Schalter mit der Beschriftung „AI Bots“ sucht, komprimiert mehrere Geschäftsentscheidungen in eine technische Abkürzung. Genau dort entstehen Fehlkonfigurationen.