KI-Crawler steuern: GPTBot, robots.txt & llms.txt

Ein Blick ins Server-Log einer Kundenseite, und dir fällt eine Zeile auf, die vor zwei Jahren noch niemand kannte: GPTBot/1.2. Daneben ClaudeBot, PerplexityBot, Google-Extended. Ein ganzer Zoo an Programmen liest die Inhalte deines Kunden aus – für das Training von Sprachmodellen, für Antworten in ChatGPT, für Zusammenfassungen in der Suche. Und irgendwann fragt der Kunde: „Sollen die das dürfen? Und wenn nein – wie stellen wir das ab?" Genau hier wird das Steuern von KI-Crawlern zu einer Aufgabe, die auf deinem Tisch landet.

Die Frage ist keine akademische mehr. Wer heute eine Website betreibt, trifft – bewusst oder unbewusst – eine Entscheidung darüber, ob und wie KI-Systeme die eigenen Inhalte verwerten. Dieser Beitrag erklärt, wer da eigentlich krabbelt, wie du den Zugriff sauber regelst, was der viel diskutierte llms.txt-Standard taugt – und warum du pro Kunde eine bewusste Strategie brauchst statt einer Copy-Paste-Datei.

Warum du KI-Crawler steuern musst – jetzt

Lange war das Auslesen von Websites ein fairer Handel: Suchmaschinen crawlten Inhalte und schickten im Gegenzug Besucher. Dieses Gleichgewicht kippt. Der Infrastruktur-Anbieter Cloudflare hat das Verhältnis von Crawls zu weitergeleiteten Besuchern gemessen und kam für Ende Juni 2025 auf drastische Werte: Anthropics KI-Plattform Claude stellte rund 70.900 Seitenanfragen für jeden einzelnen zurückgeschickten Besucher – ein Verhältnis von etwa 70.900 zu 1. Klassische Suchmaschinen crawlten historisch nur wenige Male pro gesendetem Besucher. Die Botschaft dahinter: KI-Systeme konsumieren deutlich mehr Inhalte, als sie an Traffic zurückgeben.

Für die Betreiber von Kundenseiten heißt das zweierlei. Erstens verursachen manche Bots spürbare Last, ohne einen Gegenwert in Form von Besuchern zu liefern. Zweitens – und strategisch wichtiger – stellt sich die Frage, ob Inhalte, in die Zeit und Geld geflossen sind, ungefragt in fremden Trainingsdaten und KI-Antworten landen sollen. Cloudflare zog daraus im Juli 2025 eine radikale Konsequenz: Neue Domains blockieren KI-Crawler seither standardmäßig, und Betreiber können den Zugriff nicht nur erlauben oder sperren, sondern über ein „Pay per Crawl"-Modell sogar in Rechnung stellen – technisch über den HTTP-Statuscode 402 „Payment Required". Der Umgang mit KI-Bots ist damit vom Nischenthema zur Grundsatzentscheidung jeder Domain geworden.

Wer da eigentlich krabbelt

Bevor du etwas regelst, musst du wissen, mit wem du es zu tun hast. Die Bots lassen sich grob in drei Lager sortieren, und diese Unterscheidung ist der Schlüssel zu jeder sinnvollen Entscheidung.

Die erste Gruppe sind die Trainings-Crawler. Sie sammeln Inhalte, um damit große Sprachmodelle zu trainieren. Dazu zählen OpenAIs GPTBot, Anthropics ClaudeBot und Googles Google-Extended. Blockierst du sie, verhinderst du, dass deine Inhalte in künftige Modellgenerationen einfließen – auf die Sichtbarkeit in der klassischen Suche hat das keinen Einfluss.

Die zweite Gruppe sind die Such- und Antwort-Crawler. Sie holen Inhalte, um sie live in KI-Antworten zu zitieren. OAI-SearchBot liefert die Quellen für die Suchfunktion in ChatGPT, PerplexityBot speist die Antwortmaschine Perplexity. Wer hier blockiert, riskiert, in genau diesen neuen Antwortflächen nicht mehr aufzutauchen.

Die dritte Gruppe sind die nutzergesteuerten Abrufe. ChatGPT-User etwa wird ausgelöst, wenn eine reale Person die KI bittet, eine bestimmte Seite anzusehen. Das ist kein Massen-Scraping, sondern ein einzelner, angeforderter Besuch – dem Aufruf durch einen Menschen mit Browser ähnlicher als dem eines Trainings-Crawlers.

GPTBot ist nicht gleich ChatGPT-User

Diese Dreiteilung klingt nach Wortklauberei, hat aber handfeste Folgen. Wer pauschal „alles von OpenAI" sperrt, wirft womöglich das Kind mit dem Bade aus: Er hält zwar den Trainings-Crawler GPTBot fern, kappt aber gleichzeitig OAI-SearchBot – und verschwindet damit aus den zitierten Quellen in ChatGPTs Suche, obwohl genau diese Sichtbarkeit erwünscht wäre.

Besonders tückisch ist Google-Extended. Viele glauben, das Blockieren dieses Tokens schade der Google-Sichtbarkeit. Das Gegenteil ist der Fall: Google-Extended steuert ausschließlich, ob Inhalte für Googles KI-Modelle (Gemini und Vertex AI) genutzt werden dürfen. Die reguläre Indexierung durch den Googlebot bleibt davon vollständig unberührt. Du kannst deinem Kunden also KI-Training verweigern, ohne einen einzigen Platz im organischen Ranking zu riskieren – eine Unterscheidung, die im Kundengespräch Gold wert ist.

robots.txt: dein wichtigstes Werkzeug – mit einer Einschränkung

Gesteuert wird all das an einer altbekannten Stelle: der Datei robots.txt im Wurzelverzeichnis der Domain. Dort trägst du pro Bot ein, was er darf. Ein Block, der Trainings-Crawler aussperrt, aber Such-Crawler zulässt, sieht etwa so aus:

User-agent: GPTBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

Ein Wort der Ehrlichkeit gehört dazu: robots.txt ist eine Bitte, keine Mauer. Sie funktioniert nur, solange sich ein Bot freiwillig daran hält. Die großen, reputablen Anbieter tun das in der Regel – ihr Ruf hängt daran. Für Crawler, die sich nicht daran halten, hilft nur eine technische Sperre auf Server- oder Firewall-Ebene, etwa über die Bot-Verwaltung eines Anbieters wie Cloudflare. Für einen sauberen Standard-Kunden ist robots.txt das richtige Mittel; wer wirklich harten Schutz braucht, kommt um die Firewall-Ebene nicht herum. Diese Grenze solltest du kennen, bevor du einem Kunden „wir sperren die KI aus" versprichst.

Blocken, zulassen – oder kassieren?

Die spannendere Frage ist ohnehin nicht das Wie, sondern das Ob. Und die Antwort ist selten ein pauschales Nein. Für einen Nachrichten- oder Ratgeber-Verlag, dessen Geschäftsmodell auf Website-Besuchen beruht, kann das Blockieren der Trainings-Crawler sinnvoll sein – warum die eigene Substanz verschenken, wenn kaum Traffic zurückkommt? Für ein lokales Handwerksunternehmen dagegen ist jede Erwähnung in einer KI-Antwort kostenlose Reichweite; hier wäre Blockieren ein Eigentor.

Zwischen den Extremen liegt Cloudflares dritter Weg: Inhalte gegen Bezahlung freigeben. Für die allermeisten kleinen Kundenseiten ist das (noch) überdimensioniert, zeigt aber die Richtung – der ungefragte Gratis-Zugriff auf fremde Inhalte ist kein Naturgesetz mehr. Die praktische Konsequenz für dich: Die Entscheidung „blocken, zulassen oder differenzieren" gehört ins Kundengespräch, nicht in eine Standardvorlage.

llms.txt: der gehypte Standard und was er wirklich taugt

Kaum ein Thema wird gerade so überschätzt wie die Datei llms.txt. Der Vorschlag stammt von Jeremy Howard vom KI-Labor Answer.AI und wurde im September 2024 vorgestellt. Die Idee klingt bestechend: eine Markdown-Datei, die KI-Systemen eine aufgeräumte „Landkarte" der wichtigsten Inhalte liefert, ohne dass sie sich durch HTML, Navigation und Werbung wühlen müssen.

Das Problem: Kaum jemand liest sie. Google hat mehrfach und deutlich klargestellt, dass die Suche llms.txt nicht verwendet und das auch nicht plant. Googles Gary Illyes bestätigte das bei einem Search-Central-Live-Event, und John Mueller verglich den Ansatz mit dem längst bedeutungslosen Keywords-Meta-Tag – Bots fragten die Datei auf den von ihm geprüften Seiten schlicht nicht ab. In Googles Leitfaden zur Optimierung für KI-Suche taucht llms.txt ausdrücklich unter den unnötigen Taktiken auf. Und kein großer KI-Anbieter hat bislang offiziell bestätigt, fremde llms.txt-Dateien beim Erzeugen von Antworten zu lesen. Eine eigene llms.txt zu veröffentlichen ist eben etwas völlig anderes, als dass ein Crawler die von anderen ausliest.

Ganz tot ist die Idee nicht: In der Web-Prüfsoftware Lighthouse gibt es inzwischen einen experimentellen Test, der llms.txt im Kontext von KI-Browser-Agenten bewertet – Programmen also, die im Auftrag eines Nutzers eine Seite ansteuern und verstehen sollen. Für die reine Suchsichtbarkeit bringt die Datei heute nichts. Der ehrliche Rat an den Kunden lautet deshalb: kein Schaden, aber auch kein Wundermittel – und ganz sicher kein Ersatz für sauberes technisches Fundament und gute Inhalte. Wer echte Sichtbarkeit in KI-Antworten will, arbeitet besser an belastbaren, gut strukturierten Inhalten, wie wir es im Beitrag zur Sichtbarkeit in KI-Suchen (GEO) beschrieben haben.

Die Agentur-Entscheidung: eine bewusste Crawler-Strategie pro Kunde

Das eigentliche Angebot steckt nicht in einer Datei, sondern in der Beratung. Kaum ein Kunde weiß, dass seine Inhalte ausgelesen werden, geschweige denn von wem und wofür. Genau diese Aufklärung ist deine Rolle: erklären, welche Bots was tun, den Unterschied zwischen Training und Sichtbarkeit greifbar machen und daraus pro Domain eine bewusste Entscheidung ableiten. Für den einen ist das die klare Sperre der Trainings-Crawler, für den anderen die offene Tür für maximale KI-Reichweite.

Praktisch heißt das: eine passende robots.txt aufsetzen, bei sensiblen Fällen die Firewall-Ebene mitdenken und die Entscheidung dokumentieren – auch, weil sich die Bot-Landschaft ständig verändert und regelmäßig neue Namen auftauchen. Das macht die Sache zu einem wiederkehrenden Wartungsposten, der gut zu bestehenden Verträgen passt und zugleich eine strategische Diskussion eröffnet, die eng mit dem Traffic-Einbruch durch KI-Antworten zusammenhängt. Wer diese Entscheidung aktiv für seine Kunden trifft, statt sie dem Zufall zu überlassen, positioniert sich als jemand, der die neue Realität des Webs verstanden hat – bevor der Kunde die unbekannte Log-Zeile selbst entdeckt.