KI-Crawler blockieren oder zulassen? Die Entscheidung per robots.txt

Wer „KI-Crawler blockieren“ in die robots.txt tippt, hat meist schon eine Vermutung, aber keine klare Antwort: Sperrt die eine Zeile wirklich das, was man aussperren wollte, oder trifft sie den falschen Bot? Die kurze Antwort ist, dass „KI-Crawler“ keine einzelne Kategorie ist. Mindestens drei Gruppen von User-Agents verstecken sich dahinter, und jede kostet beim Blockieren etwas anderes.

Wer alle Bots mit „KI“ oder „GPT“ im Namen pauschal aussperrt, verliert nicht dasselbe wie jemand, der nur die Trainings-Crawler blockt. Und wer Google-Extended sperrt, weil er die KI-Übersichten in der Google-Suche fürchtet, blockiert in Wahrheit etwas völlig anderes. Dieser Text ordnet die einzelnen User-Agents ihrer Funktion zu, zeigt die konkrete robots.txt-Syntax dafür und erklärt, wie du in den Server-Logs prüfst, ob ein Zugriff wirklich von dem Bot stammt, für den er sich ausgibt.

Die drei Kategorien von KI-Crawlern

Unter dem Sammelbegriff „KI-Crawler“ laufen technisch drei unterschiedliche Aufgaben. Die erste Gruppe sammelt Inhalte, um künftige Modellversionen zu trainieren. Die zweite Gruppe ruft einzelne Seiten in Echtzeit ab, entweder um einen laufenden Suchindex für eine KI-Antwortmaschine aufzubauen oder um genau die eine Seite zu holen, nach der ein Nutzer im Chat gerade gefragt hat. Die dritte „Kategorie“ ist eigentlich nur ein einziges Steuer-Token: Google-Extended.

Zu den Trainings-Crawlern zählen GPTBot (OpenAI), ClaudeBot in seiner Trainingsfunktion (Anthropic), Bytespider (ByteDance) und meta-externalagent (Meta). Dazu kommt CCBot, der Crawler von Common Crawl: Er speist keinen einzelnen Anbieter, sondern die offene Textsammlung, aus der etliche Modelle unterschiedlicher Firmen trainieren. Blockierst du CCBot, triffst du potenziell mehrere Modelle gleichzeitig, nicht nur eines.

Die zweite Gruppe, Live-Retrieval, hat zwei Spielarten. OAI-SearchBot (OpenAI), PerplexityBot (Perplexity) und Claude-SearchBot (Anthropic) bauen den Suchindex auf, den die jeweilige KI-Antwortmaschine für ihre Web-Suche-Funktion nutzt – ähnlich wie ein klassischer Suchmaschinen-Crawler, nur für ein KI-Antwortformat statt für eine Ergebnisliste. ChatGPT-User, Claude-User und Perplexity-User dagegen rufen genau eine Seite ab, in dem Moment, in dem ein Nutzer im Chat einen Link nennt oder eine Frage stellt, die eine Live-Prüfung einer bestimmten URL auslöst.

Google-Extended ist kein Bot, der eigene Anfragen stellt. Es ist ein User-Agent-Name, den nur robots.txt kennt: Trägst du ihn ein, entscheidest du damit ausschließlich, ob deine Inhalte in das Training von Gemini und in die generativen Funktionen der Vertex-AI-Plattform einfließen dürfen. Der reguläre Googlebot, der deine Seite für die klassische Suche crawlt und indexiert, ist davon komplett getrennt und reagiert auf Google-Extended überhaupt nicht.

Dass OpenAI, Anthropic und Perplexity ihre Bots inzwischen fast identisch aufteilen, ist kein Zufall. Ein einziger undifferenzierter Bot, der gleichzeitig trainiert, den eigenen Suchindex pflegt und live abruft, ließe Website-Betreibern nur die Wahl zwischen komplett sperren und komplett zulassen. Die Aufteilung in separate, benannte User-Agents schafft genau die Feinsteuerung, um die es hier geht: Training getrennt von Live-Zitat, und beides getrennt von der reinen Indexpflege für die KI-eigene Suche.

• Trainings-Crawler: GPTBot, ClaudeBot, Bytespider, meta-externalagent, CCBot
• Index-Crawler für KI-Suche: OAI-SearchBot, PerplexityBot, Claude-SearchBot
• Live-Fetch-Agenten für einzelne Anfragen: ChatGPT-User, Claude-User, Perplexity-User
• Sonderfall: Google-Extended – ein Steuer-Token, kein eigener Crawler

Was Blockieren wirklich kostet

Blockierst du einen reinen Trainings-Crawler wie GPTBot oder Bytespider, passiert kurzfristig nichts Sichtbares. Diese Bots erzeugen keine Zitate, keine Antworten und keinen Referral-Traffic in Echtzeit – sie sammeln Rohmaterial für einen Trainingslauf, der Monate später ein neues Modell ergibt. Der Preis ist also kein Sichtbarkeitsverlust heute, sondern die Möglichkeit, dass dein Inhalt in einer künftigen Modellversion gar nicht mehr vorkommt.

Ein Detail wird dabei oft übersehen: Die Blockade wirkt nur nach vorn. Hat ein Crawler deine Seite schon vor der Sperre erfasst und ist dieses Material bereits in einen abgeschlossenen Trainingslauf eingeflossen, holt eine nachträgliche robots.txt-Regel nichts davon zurück. Sie verhindert den nächsten Durchlauf, nicht das, was ein Modell aus dem letzten schon gelernt hat.

Bei den Live-Fetch-Agenten liegt der Fall anders, und hier tut eine Blockade tatsächlich sofort weh. Fragt jemand ChatGPT, Claude oder Perplexity nach einem Thema, zu dem deine Seite eine gute Antwort liefern würde, versucht der jeweilige Agent, die Seite live zu laden und zu zitieren. Sperrst du ihn aus, kann diese eine Anfrage deine Seite nicht als Quelle nennen – die Antwort entsteht ohne dich, meist mit einer Konkurrenzseite als Beleg. Weil solche Zitate zunehmend echten Klick-Traffic bringen, ist das der Fall, in dem „KI-Crawler blockieren“ realen Preis hat, nicht nur einen theoretischen.

Ein Beispiel macht den Unterschied greifbar: Eine Anleitung zu einem engen Nischenthema, die in einer KI-Antwort mit Quellenangabe auftaucht, bringt einen Klick von jemandem mit einer sehr konkreten Frage – vergleichbar mit einem Ranking in den klassischen Suchergebnissen, nur an anderer Stelle in der Antwort platziert. Sperrst du den zuständigen Live-Fetch-Agenten, verschwindet nicht die Frage, sondern nur deine Chance, als Antwort darauf zu erscheinen; die KI beantwortet sie trotzdem, nur mit einer anderen Quelle oder ganz ohne Quellenangabe.

Google-Extended zu blockieren kostet in der klassischen Google-Suche nichts, und es kostet auch nichts bei den KI-Übersichten, die dort inzwischen über vielen Ergebnissen erscheinen. Beide laufen über den normalen Suchindex, den Googlebot pflegt, unabhängig von Google-Extended. Wer Google-Extended sperrt, um seine Position in der Suche oder in den KI-Übersichten zu schützen, blockiert das falsche Ziel: Er verzichtet lediglich darauf, dass seine Inhalte ins Training von Gemini und in die generativen Funktionen von Vertex AI einfließen – ein separates, deutlich kleineres Anliegen.

Die robots.txt-Syntax für einzelne Bots

robots.txt liest pro User-Agent-Block, nicht global. Jeder Bot braucht seine eigene Zeile, denn eine Disallow-Regel unter einem fremden User-Agent gilt für ihn nicht. Ein Block, der nur GPTBot sperrt, lässt ChatGPT-User unangetastet, auch wenn beide von OpenAI stammen.

Wichtig ist die Reihenfolge der Prüfung: Ein Crawler befolgt zuerst den Block, der exakt seinen eigenen User-Agent-Namen trägt. Existiert keiner, greift der allgemeine Block mit User-agent: *. Die beiden Regeln werden nicht addiert – ein spezifischer Block überschreibt den allgemeinen vollständig, auch wenn Letzterer strenger wäre.

Der Unterschied zwischen Disallow: / und Disallow: /blog/ ist die gesamte Domain gegen einen einzelnen Ordner. Ein fehlender oder falsch gesetzter Schrägstrich sperrt entweder viel zu viel oder gar nichts – ein Tippfehler an dieser Stelle ist einer der häufigsten Gründe, warum eine robots.txt-Regel nicht das tut, was gedacht war.

• User-agent: GPTBot, Disallow: / — sperrt den OpenAI-Trainingscrawler auf der gesamten Domain
• User-agent: ChatGPT-User, Disallow: /premium/ — lässt den Live-Fetch-Agenten überall zu, außer im geschützten Bereich
• User-agent: Google-Extended, Disallow: / — schließt Inhalte vom Gemini-Training aus, ohne den normalen Googlebot zu berühren
• User-agent: *, Disallow: — Fallback-Regel für alle nicht einzeln genannten Bots; sie gilt nur ohne spezifischeren Block

Warum robots.txt nur eine Bitte ist

robots.txt ist keine Firewall. Die Datei ist eine öffentlich lesbare Ansage, an die sich ein Bot freiwillig hält – oder auch nicht. OpenAI, Anthropic und Perplexity erklären in ihrer jeweiligen Crawler-Dokumentation, dass ihre Crawler robots.txt respektieren; für nutzerausgelöste Abrufe wie Perplexity-User schränken manche Anbieter das allerdings ausdrücklich ein. Das ist eine Zusage der jeweiligen Firma, keine technische Barriere.

Ein Scraper, der sich nicht an diese Zusage hält, liest die robots.txt entweder gar nicht oder ignoriert sie bewusst. Nichts auf deinem Server verhindert das technisch. Genauso wenig verhindert die Datei, dass ein Scraper sich als GPTBot ausgibt, ohne es zu sein – der User-Agent-String ist ein einfaches HTTP-Header-Feld, das der Client frei wählt, kein Ausweis.

Für seriöse Anbieter reicht robots.txt aus, weil sie ein Interesse daran haben, als vertrauenswürdiger Crawler zu gelten. Für alles andere – aggressive Scraper, die sich absichtlich als bekannter Bot tarnen, oder Fälle, in denen eine echte Durchsetzung nötig ist – braucht es eine Prüfung auf Serverebene, nicht nur eine Zeile in einer Textdatei.

Serverseitig prüfen, ob der Zugriff wirklich stimmt

Der erste Schritt ist simpel: im Access-Log nach dem User-Agent-String filtern und zählen, wie oft und auf welchen Pfaden er auftaucht. Häufen sich Zugriffe von „GPTBot“ auf Seiten, die für einen Trainingscrawler wenig Sinn ergeben – etwa auf interne Suchergebnisse oder Warenkorb-Seiten – ist das ein Hinweis, dass hier nicht der echte GPTBot unterwegs ist, sondern etwas, das sich nur so nennt.

Die verlässliche Prüfung ist eine sogenannte forward-confirmed reverse DNS-Abfrage: Zuerst ermittelst du per Reverse-Lookup, welcher Hostname zur IP-Adresse des Zugriffs gehört. Gehört dieser Hostname erkennbar zur Domain des jeweiligen Anbieters, prüfst du in einem zweiten Schritt per Forward-Lookup, ob dieser Hostname wieder auf dieselbe IP-Adresse zurückführt. Stimmen beide Richtungen überein, ist die IP tatsächlich beim genannten Anbieter registriert. Diese zweistufige Prüfung ist dieselbe Methode, mit der schon lange die Echtheit von Googlebot-Zugriffen verifiziert wird, und mittlerweile wenden mehrere KI-Anbieter sie sinngemäß auf ihre eigenen Crawler an.

Mehrere Anbieter veröffentlichen zusätzlich feste IP-Bereiche für ihre Crawler, die du automatisiert mit den IP-Adressen in deinen Logs abgleichen kannst. Das ist schneller als eine Lookup-Abfrage pro Zugriff, muss aber regelmäßig aktualisiert werden, weil sich diese Bereiche ändern können.

Diese Prüfung schützt in zwei Richtungen. Sie deckt auf, wenn ein Scraper sich als bekannter KI-Crawler tarnt, um Zugriff zu bekommen. Und sie verhindert den umgekehrten Fehler: dass du einen ganz gewöhnlichen Scraper fälschlich einem großen Anbieter zuschreibst, nur weil er denselben Namen im User-Agent-Feld trägt, und deine Analyse auf dieser falschen Zuordnung aufbaust.

Selektiv blockieren statt alles oder nichts

Die pauschale Entscheidung „alles sperren“ oder „alles zulassen“ übersieht, dass nicht jeder Bereich einer Website gleich viel Wert aus einer KI-Zitierung zieht. Ein öffentlicher Ratgeberartikel profitiert von einer Nennung in einer KI-Antwort, weil ein Klick auf die zitierte Quelle möglich ist. Ein Bereich hinter einem Login bringt diesen Vorteil nicht, weil der zitierende Nutzer dort ohnehin nicht hineinkommt.

Technisch ist das dieselbe Syntax wie im Beispiel oben, nur mit einem Pfad statt einem einzelnen Schrägstrich hinter Disallow. Der Aufwand liegt nicht in der Syntax, sondern darin, für jeden Bereich einmal zu entscheiden, ob ein Zitat dort überhaupt etwas wert wäre.

• Marketing- und Ratgeberinhalte: für Live-Fetch-Agenten offen lassen, weil eine Zitierung dort tatsächlich Reichweite bringt
• Bezahlbereich, Kundenkonto, interne Suche: für alle KI-Crawler sperren, weil dort ohnehin kein Zitat-Traffic entstehen kann
• Presse- oder Rechtsseiten mit sensiblen Formulierungen: einzeln prüfen, statt sie über die allgemeine Regel laufen zu lassen

Testen und überwachen, bevor und nachdem du umstellst

robots.txt wird nicht bei jedem einzelnen Zugriff neu geladen. Die meisten Crawler laden die Datei in regelmäßigen, aber unterschiedlichen Abständen neu und cachen sie dazwischen. Eine Änderung wirkt deshalb nicht sofort – rechne mit einer Verzögerung, bevor ein Bot die neue Regel überhaupt zum ersten Mal sieht.

Weil robots.txt eine einfache Textdatei ist, ist eine Änderung risikoarm und sofort umkehrbar: Eine falsch gesetzte Zeile lässt sich in Sekunden zurücknehmen, ohne Deployment und ohne Wartefenster. Das macht Testen im laufenden Betrieb vertretbar, solange die Kontrolle danach nicht ausbleibt.

Bleiben nach der erwarteten Verzögerung weiterhin Zugriffe des eigentlich gesperrten User-Agents im Log, ist entweder die Syntax fehlerhaft, oder es handelt sich – wie im Abschnitt zur Serverprüfung beschrieben – gar nicht um den echten Bot, sondern um einen Nachahmer, der sich ohnehin nie an die Datei gehalten hätte.

• Vor der Umstellung: aktuelle robots.txt sichern, damit ein Rollback nicht neu geschrieben werden muss
• Direkt danach: Syntax gegenprüfen – ein Tippfehler im User-Agent-Namen macht den ganzen Block wirkungslos, nicht nur die eine Zeile
• Ein bis zwei Wochen danach: Access-Log erneut auf denselben User-Agent filtern und die Zugriffszahl mit der Zeit davor vergleichen
• Bei Live-Fetch-Agenten zusätzlich prüfen, ob die betroffene KI-Antwortmaschine die eigene Seite in Antworten weiterhin zitiert oder nicht mehr

Ein Entscheidungsrahmen für die eigene Situation

Vier Fragen decken die gängigen Fälle ab:

• Sorge, dass eigene Inhalte unbezahlt in Trainingsdaten für Konkurrenzmodelle landen? Trainings-Crawler (GPTBot, ClaudeBot, Bytespider, meta-externalagent, CCBot) sperren, Live-Fetch-Agenten aber zulassen, wenn Zitate mit Linkangabe Referral-Traffic bringen
• Zielgruppe recherchiert überwiegend in KI-Antwortmaschinen, und maximale Sichtbarkeit dort ist wichtiger als Kontrolle über Trainingsdaten? Alles zulassen, inklusive Trainings-Crawler
• Bezahlte oder exklusive Inhalte, die nicht kostenlos zusammengefasst werden sollen? Selektiv nach Pfad sperren, wie im Abschnitt oben beschrieben
• Unentschieden? Verbreiteter Mittelweg: Trainings-Crawler sperren, Index- und Live-Fetch-Agenten (OAI-SearchBot, PerplexityBot, Claude-SearchBot, ChatGPT-User, Claude-User, Perplexity-User) zulassen – das trennt die Frage, wer ein Modell trainieren darf, von der Frage, wer gerade jetzt zitieren darf

Welche Kombination am Ende in der robots.txt landet, ist eine Abwägung zwischen dem Wert einer Zitierung und dem Unbehagen, das eigene Material in einem Trainingsdatensatz zu wissen. Beides ist legitim – wichtig ist nur, dass die Entscheidung bewusst pro Kategorie getroffen wird und nicht über eine einzige pauschale Zeile, die „KI“ im Namen trägt und mehr sperrt, als eigentlich gewollt war.