Technik

AI-Crawler steuern: GPTBot, ClaudeBot und Co. in der robots.txt

27. Juli 20263 Min. Lesezeit

Wer GPTBot pauschal sperrt, verliert oft mehr, als er schützt. Der entscheidende Unterschied liegt zwischen Bots, die für Training sammeln, und solchen, die live für eine Antwort abrufen. Ein Überblick mit konkreter Konfiguration.

Kaum eine technische Entscheidung im GEO-Umfeld wird so häufig falsch getroffen wie die Steuerung von KI-Crawlern. Der Reflex vieler Unternehmen lautet: Wir wollen nicht, dass unsere Inhalte für KI-Training verwendet werden, also sperren wir alles. Das Ergebnis ist regelmäßig, dass die Marke aus KI-Antworten verschwindet, während das Trainingsproblem ungelöst bleibt.

Zwei grundverschiedene Bot-Typen

Der wichtigste Punkt zuerst: Nicht jeder KI-Crawler tut dasselbe. Es gibt zwei Kategorien mit völlig unterschiedlichen Konsequenzen.

Trainings-Crawler

Diese Bots sammeln Inhalte für das Training künftiger Modellgenerationen. Ihre Inhalte fließen in Gewichte ein, ohne dass eine Quellenangabe erfolgt. Ein Traffic-Rückfluss existiert nicht. Wer diese Bots sperrt, verliert kurzfristig nichts an Sichtbarkeit.

Retrieval-Crawler

Diese Bots rufen Ihre Seite ab, wenn ein Nutzer gerade eine Frage stellt und das System eine Antwort mit Quellen zusammenstellt. Hier entsteht Sichtbarkeit unmittelbar: Ihre Marke wird genannt, Ihre URL wird verlinkt, Nutzer klicken. Wer diese Bots sperrt, macht sich unsichtbar.

Die Verwirrung entsteht, weil beide Kategorien vom selben Anbieter kommen und ähnlich heißen.

Die relevanten User-Agents

  • GPTBot (OpenAI): Trainings-Crawler. Sammelt Inhalte für künftige Modelle.
  • OAI-SearchBot (OpenAI): Indexiert für die Suchfunktion. Relevant für Sichtbarkeit.
  • ChatGPT-User (OpenAI): Live-Abruf, wenn ein Nutzer im Chat eine Seite öffnen lässt. Klar sichtbarkeitsrelevant.
  • ClaudeBot (Anthropic): Trainings-Crawler.
  • Claude-User und Claude-SearchBot (Anthropic): Live-Abruf und Suchindexierung. Sichtbarkeitsrelevant.
  • PerplexityBot: Indexierung für Perplexity-Antworten. Perplexity zitiert Quellen prominent, dieser Bot ist besonders wertvoll.
  • Perplexity-User: Live-Abruf auf Nutzeranfrage.
  • Google-Extended: Kein eigener Crawler, sondern ein Steuerungs-Token. Er entscheidet, ob Ihre bereits von Googlebot erfassten Inhalte für Gemini-Training und KI-Funktionen genutzt werden dürfen. Ein Ausschluss beeinflusst das klassische Google-Ranking nicht.
  • Applebot-Extended: Äquivalent bei Apple.
  • Bytespider (ByteDance), meta-externalagent (Meta), Amazonbot: überwiegend Trainings- und Datensammlung.
  • CCBot (Common Crawl): Speist offene Datensätze, die fast jeder Modellanbieter nutzt.

Die pragmatische Standardkonfiguration

Für die große Mehrheit der Unternehmen ist die sinnvolle Haltung: Retrieval erlauben, Training einschränken. Sie bleiben in KI-Antworten sichtbar, geben Ihre Inhalte aber nicht kostenlos in Trainingskorpora.

Konkret bedeutet das in der robots.txt:

  • Erlauben: OAI-SearchBot, ChatGPT-User, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User
  • Sperren: GPTBot, ClaudeBot, CCBot, Bytespider, meta-externalagent, Google-Extended, Applebot-Extended

Jeder Eintrag besteht aus einer User-agent-Zeile und einer Disallow- beziehungsweise Allow-Zeile mit Slash. Wichtig: Genauigkeit zählt. Ein Eintrag für User-agent mit Sternchen und Disallow-Slash sperrt alles, auch Google.

Die Gegenposition ist legitim: Wer maximale Präsenz in künftigen Modellen anstrebt und keine Verwertungsbedenken hat, lässt auch die Trainings-Crawler zu. Publisher mit Lizenzinteresse sperren dagegen konsequent. Beide Entscheidungen sind vertretbar, solange sie bewusst getroffen werden.

robots.txt ist nur eine Bitte

Die Datei ist eine Konvention, keine technische Sperre. Seriöse Anbieter halten sich daran, andere nicht. Wenn Inhalte wirklich geschützt werden müssen, brauchen Sie serverseitige Maßnahmen: Blockieren nach User-Agent und IP-Bereich auf Ebene des Webservers oder CDN. Cloudflare und ähnliche Dienste bieten dafür fertige Regelsätze.

Umgekehrt gilt: Wer sperren will, muss auch prüfen, ob die Sperre wirkt. Ein Blick in die Server-Logs auf die genannten User-Agents zeigt binnen weniger Tage, wer tatsächlich vorbeischaut.

Der häufigste Fehler in der Praxis

In Audits sehen wir immer wieder drei Muster:

  • Pauschalsperre aus dem Plugin: Ein Sicherheits-Plugin sperrt alle unbekannten Bots, darunter auch alle Retrieval-Crawler. Die Marke taucht in keiner KI-Antwort auf, niemand weiß warum.
  • Firewall vor der robots.txt: Die robots.txt erlaubt den Zugriff, aber die Web Application Firewall liefert 403. Der Bot kommt nie an.
  • JavaScript-Rendering vorausgesetzt: Die Inhalte sind erst nach clientseitigem Rendering da. Die meisten KI-Crawler rendern kein JavaScript und sehen eine leere Seite. Serverseitiges Rendering ist hier keine Kür, sondern Voraussetzung.

Prüfen statt vermuten

Die Kontrolle ist unaufwendig. Rufen Sie Ihre Seite mit dem User-Agent eines KI-Crawlers ab und prüfen Sie, ob HTTP 200 zurückkommt und ob der Hauptinhalt im ausgelieferten HTML enthalten ist. Danach ein Blick in die Logs: Welche Bots kommen wie oft, welche Seiten rufen sie ab, welchen Statuscode bekommen sie. Diese beiden Schritte klären die Mehrzahl aller Sichtbarkeitsprobleme, die als inhaltlich diagnostiziert wurden, in Wahrheit aber technisch sind.

Wenn Sie den Ist-Zustand systematisch aufnehmen wollen, ist das Teil jedes GEO-Audits. Die Begriffe rund um Crawler und Retrieval sind im GEO-Glossar nachschlagbar.

Bereit für mehr KI-Sichtbarkeit?

Lassen Sie uns gemeinsam Ihre GEO-Strategie entwickeln. Kostenlose Erstberatung — unverbindlich und persönlich.

Jetzt Kontakt aufnehmen