Zwei Leute haben uns während unseres Live-Events „Bot Traffic Reality Check“ dieselbe Frage gestellt, und wir sind live bei keiner der beiden darauf eingegangen: Verhindert eine llms.txt-Datei tatsächlich, dass KI eure Website überlastet?

Wir haben lange über diese Frage nachgedacht, denn die ehrliche Antwort lässt sich nicht einfach mit Ja oder Nein beantworten. Tatsache ist, dass llms.txt nie dafür entwickelt wurde, eine der beiden Aufgaben zu erfüllen, die sich die Leute davon erhofft haben – und vieles, was dieses Jahr darüber veröffentlicht wurde, hat die Leute stillschweigend zu der gegenteiligen Annahme verleitet.

Diese Verwirrung ist kein Einzelfall. In den Fragen, die wir erhalten haben, wurden robots.txt, llms.txt, „KI-Crawler“ und Bot-Schutz immer wieder so diskutiert, als wären sie vier Einstellungen auf demselben Regler, bei denen das Drehen einer beliebigen Einstellung zum gleichen Ergebnis führt. Das ist nicht der Fall. Sie befinden sich an völlig unterschiedlichen Punkten im Anfragepfad, werden durch völlig unterschiedliche Mechanismen durchgesetzt (oder in einem Fall gar nicht durchgesetzt), und genau diese Verwechslung führt dazu, dass ein Website-Betreiber alles „richtig“ macht und trotzdem unter der Last zusammenbricht.

Und das ist nicht nur Theorie. In unserem „KI & Bot Traffic Report“ haben wir festgestellt, dass der KI-Bot-Traffic auf von Kinsta gehosteten Seiten von 1 von 200 Webbesuchen vor einem Jahr auf heute 1 von 31 gestiegen ist. Ein Schild an der Tür nützt nicht viel, wenn so viele Leute versuchen, die Türklinke zu betätigen.

TL;DR

  • robots.txt ist eine Bitte, kein Schloss. Seriöse KI-Crawler von OpenAI, Anthropic, Google und Perplexity lesen und befolgen sie in der Regel. Einige, darunter in der Vergangenheit auch Bytespider von ByteDance, haben das nicht getan.
  • llms.txt kontrolliert den Zugriff nicht. Es ist ein Inhaltsindex für KI-Tools, die ihn lesen wollen – keine Berechtigungsdatei. Die Akzeptanz liegt bei etwa 9–10 % der Websites, und die großen KI-Crawler rufen ihn ohnehin größtenteils nicht ab.
  • Der Bot-Schutz ist die einzige Ebene, die tatsächlich etwas durchsetzt. „robots.txt“ und „llms.txt“ funktionieren, indem sie höflich darum bitten. Kinsta Bot Protection und Cloudflares AI Crawl Control sind die Lösungen, die einen Crawler, der deine Einstellungen ignoriert, tatsächlich blockieren, herausfordern oder in seiner Zugriffsrate begrenzen.

Vier Ebenen, vier Aufgaben, ein Punkt der Verwirrung

Ebene Was sie tatsächlich tut Kann sie einen böswilligen Akteur aufhalten?
robots.txt Gibt jedem Crawler, der sich die Mühe macht, es zu lesen, deine Präferenzen an Nein
llms.txt Stellt KI-Tools einen bereinigten Index deiner Inhalte zur Verfügung Nein
KI-Crawler Die Bots, die die Anfragen stellen k. A. (das sind die, die du verwaltest, kein Kontrollelement)
Bot-Schutz (Kinsta / Cloudflare) Erkennt, klassifiziert und reagiert auf Anfragen auf Infrastrukturebene Ja

Wenn man es einmal so aufgeschlüsselt sieht, beantworten sich die meisten Fragen der Teilnehmer von selbst. Gehen wir also Schicht für Schicht vor, beginnend mit der, die jeder schon halbwegs versteht.

robots.txt

robots.txt, formalisiert als RFC 9309, teilt Crawlern mit, welche Teile deiner Website sie lieber überspringen sollen. Es gibt keine technische Durchsetzung, daher funktioniert es nur, weil die Crawler, die es lesen, sich aus grundsätzlichen Erwägungen heraus dazu entschlossen haben, sich daran zu halten.

Das Beruhigende daran ist, dass die Crawler, die dir wahrscheinlich am wichtigsten sind – wie OpenAI, Anthropic, Google und Perplexity –, alle dokumentierte User-Agents veröffentlichen und sich an die Standardrichtlinien halten.

Was viele Leute auf die falsche Fährte führt, ist die Annahme, dass jedes Unternehmen nur einen einzigen „KI-Bot“ betreibt. Das tun sie nicht. Die meisten trennen mittlerweile das Training von der Suche, und genau diese Trennung ist der nützlichste Hebel in diesem ganzen Artikel:

  • GPTBot (OpenAI): trainiert Basis-Modelle. Wenn du ihn blockierst, fließen deine Inhalte nicht mehr in zukünftige Trainingsläufe ein.
  • OAI-SearchBot (OpenAI): Indiziert Seiten für die Zitierung in der ChatGPT-Suche. Wenn du ihn blockierst, verlierst du diese Zitierungen, das Training bleibt jedoch unbeeinträchtigt.
  • ClaudeBot (Anthropic): Training.
  • Claude-SearchBot (Anthropic): Suchindexierung für Claude.
  • Google-Extended: regelt speziell die Nutzung im KI-Training und in KI-Übersichten. Wenn du ihn blockierst, hat das keinen Einfluss auf die reguläre Googlebot-Indizierung oder deine normalen Suchrankings.
  • PerplexityBot: Der Crawler der Antwort-Engine von Perplexity.

Die eigentliche Entscheidung lautete also nie „KI reinlassen oder draußenhalten“. Die Frage ist vielmehr: Willst du, dass deine Inhalte ein Modell trainieren, in einer KI-Antwort zitiert werden, beides oder gar nichts davon? Mit robots.txt kannst du diese Frage bereits präzise beantworten. Die meisten Website-Betreiber haben sie sich nur noch nicht in diesen Begriffen gestellt.

So sieht diese Präzision in einer robots.txt-Datei konkret aus. Angenommen, du möchtest komplett vom Training ausgeschlossen bleiben, aber trotzdem erscheinen, wenn jemand ChatGPT oder Claude eine Frage stellt, die deine Inhalte beantworten könnten:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

Wenn du lieber einen bestimmten Bereich komplett ausklammern möchtest – sowohl vom Training als auch von der Suche –, beschränkst du die „disallow“-Regel auf einen bestimmten Pfad statt auf die gesamte Website:

User-agent: GPTBot
Disallow: /premium-reports/

User-agent: ClaudeBot
Disallow: /premium-reports/

Der Haken dabei ist, dass die Einhaltung eine Höflichkeit ist, keine Verpflichtung. Es gibt eine Handvoll Crawler, von denen bekannt ist, dass sie „disallow“-Regeln komplett ignorieren. Es gibt noch eine weitere neue Herausforderung: Wenn jemand ChatGPT oder einen ähnlichen Assistenten bittet, eine bestimmte Seite sofort für ihn zu lesen, verhält sich dieser einzelne Abruf nicht immer wie ein Crawl, und die „robots.txt“-Logik lässt sich nicht eindeutig darauf anwenden.

llms.txt

In vielen Beiträgen aus dem Jahr 2026 wurde llms.txt entweder als Tool zur Zugriffskontrolle oder als SEO-Trick beschrieben. Die ehrliche Antwort ist einfacher und weniger nützlich, als die meisten Berichte vermuten lassen.

llms.txt ist eine einfache Markdown-Datei in deinem Stammverzeichnis, die wie ein Inhaltsverzeichnis für KI-Tools funktioniert und diese auf deine wichtigsten Seiten verweist, damit ein Modell nicht eine vollständig gerenderte Seite analysieren muss, um zu verstehen, was du tust. Das ist die gesamte Spezifikation. Sie sagt nichts darüber aus, was ein Crawler tun darf und was nicht.

So sieht so eine Datei in etwa aus:

# Acme Analytics

> Acme Analytics is a WordPress plugin for tracking site performance and uptime.

## Docs
- [Getting Started](https://example.com/docs/getting-started): Install and configure the plugin
- [API Reference](https://example.com/docs/api): Full REST API documentation

## Pricing
- [Plans](https://example.com/pricing): Current plans and feature comparison

Beachte, dass es kein Allow, kein Disallow, kein User-Agent-Targeting und nichts gibt, was einem Crawler vorschreibt, was er tun darf und was nicht.

Das sagen die aktuellen Erkenntnisse:

  • Die Verbreitung ist gering. Etwa 9–10 % der Websites haben eine solche Datei, selbst unter den größten Domains im Netz – und das, obwohl sich die Leute schon seit weit über einem Jahr gegenseitig dazu auffordern, sie hinzuzufügen.
  • Die Bots, auf die es ankommt, lesen die Datei größtenteils nicht. Eine Traffic-Analyse von Hunderten Millionen KI-Anfragen zeigt, dass GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot und Google-Extended die Datei überwiegend überspringen und direkt mit dem Crawlen des HTML-Codes beginnen.
  • Google hat sich öffentlich dagegen ausgesprochen. Googles eigene Such-Experten haben unmissverständlich erklärt, dass llms.txt nicht als Ranking- oder Crawling-Signal verwendet wird, und haben es – eher ungünstig – mit dem längst überholten Keyword-Meta-Tag verglichen.
  • Kein großes KI-Labor hat sich dazu verpflichtet, die Datei als Zugriffssignal zu behandeln – weder für das Training noch für die Suche.

Wo es sich wirklich bezahlt macht, ist als Übersicht für Programmier-Agenten und Entwickler-Tools wie Claude Code oder Cursor, die von einem sauberen, strukturierten Index einer Dokumentations-Website profitieren.

llms.txt wird also nicht verhindern, dass deine Seite wiederholt gecrawlt wird. Es ist eine Hilfe bei der Erkennung, kein Begrenzer der Crawling-Rate und kein Zugangsschranken.

KI-Crawler

Der Begriff „KI-Crawler“ wird als Sammelbegriff für mindestens drei unterschiedliche Verhaltensweisen verwendet, und genau diese Vermischung ist oft der Ausgangspunkt für viele Fehlentscheidungen:

  1. Trainings-Crawler, die regelmäßig Inhalte für den Trainingsdatensatz eines Modells sammeln: GPTBot, ClaudeBot, Google-Extended, Bytespider, CCBot.
  2. Such- und Antwort-Crawler, die den Index aufbauen, aus dem eine KI-Antwortmaschine tatsächlich zitiert: OAI-SearchBot, Claude-SearchBot, PerplexityBot.
  3. Echtzeit-Agentenabrufe, bei denen eine Person einen Assistenten bittet, sofort eine bestimmte Seite zu lesen, und dieser tut dies dann auf der Stelle.

Die ersten beiden verhalten sich wie klassische Crawler und identifizieren sich in der Regel mit einem dokumentierten User-Agent – genau das macht eine Steuerung über robots.txt überhaupt erst möglich. Der dritte ähnelt viel eher einer Person, die auf einen Link klickt, als einem Crawl – was zum Teil der Grund dafür ist, dass manche KI-Browsing-Tools in Server-Logs mittlerweile nicht mehr von normalen Besuchern zu unterscheiden sind, und zum Teil auch der Grund, warum grobe Bot-Blockierungen gelegentlich legitime, von Menschen gesteuerte Aktivitäten mit ins Netz ziehen.

Genau das ist auch der Kern dessen, was Daniel Pataki während des Webinars angesprochen hat: Der meiste KI-Crawler-Traffic ist heutzutage nicht bösartig, sondern einfach nur unaufhaltsam. Er folgt jedem Link, den er findet – einschließlich jeder überflüssigen URL-Variante, die eine dynamische WordPress- oder WooCommerce-Website generieren kann – und landet schließlich in einer Schleife, die wie ein Angriff aussieht, aber in Wirklichkeit nur ein Bot ist, der nicht weiß, dass er diese Seite bereits neuntausend Mal gesehen hat.

Wir gehen genauer darauf ein, warum genau das die WooCommerce-Infrastruktur besonders stark belastet und warum WooCommerce-Seiten besonders anfällig für Bot-Traffic sind.

Die Ebene, die wirklich etwas bewirkt: Bot-Schutz

Sobald du akzeptierst, dass „robots.txt“ freiwillig ist und „llms.txt“ überhaupt keine Kontrollmöglichkeit darstellt, bleibt nur noch eine Ebene übrig, die gegen einen Crawler vorgehen kann, der sich weigert zu kooperieren: Bot-Schutz – sei es Kinsta Bot Protection, die Tools von Cloudflare oder etwas ganz anderes.

Cloudflare hat sich in dieser Hinsicht schnell weiterentwickelt, aber bei Kinsta verfolgen wir einen engeren, WordPress-spezifischen Ansatz für dasselbe Problem: einen speziellen Schalter KI-Crawler blockieren, der KI-Crawler – einschließlich verifizierter – stoppt, ohne Googlebot oder Bing zu beeinträchtigen, sowie eine Klassifizierung für KI-Crawler mit übermäßiger Zugriffsrate, die einen Bot abfängt, der zwar technisch verifiziert ist, deine Website aber weitaus stärker belastet, als es ein normaler Crawl jemals tun würde.

Kinstas Bot-Schutz-Tool
Kinstas Bot-Schutz-Tool

Laszlo Farkas, unser Director of Engineering, hat den zugrunde liegenden Kompromiss so beschrieben, als wir ihn baten, ein verwaltetes Tool mit dem Erstellen eigener Regeln von Grund auf zu vergleichen:

Wenn du das Fachwissen und die Zeit hast, das selbst fein abzustimmen, ist das wahrscheinlich die bessere Wahl für dich. Wenn nicht, halte ich es für besser, das von Kinsta zu nutzen, da es verwaltet, speziell auf WordPress abgestimmt und für dich gewartet wird.

Einen umfassenderen Vergleich, wo das Tool von Kinsta und das von Cloudflare jeweils am besten passen, findest du in unserem Leitfaden „Kinsta Bot Protection vs. Cloudflare“.

Die Fragen, die wir tatsächlich bekommen haben, direkt beantwortet

„Wir wollen LLM-Crawler zulassen, aber Missbrauch vermeiden. Gibt es einen zuverlässigen Weg, das zu tun?“ Ja, es ist die bewusst angewandte Unterscheidung zwischen „Training“ und „Suche“. Erlaube den Such- und Antwort-Crawlern den Zugriff, wenn du auffindbar sein und zitiert werden möchtest. Nutze robots.txt, um Trainings-Crawler gezielt auszuschließen, wenn du genau das ablehnst. Lass dann den Bot-Schutz volumenbasierten Missbrauch von allem abfangen – egal ob verifiziert oder nicht –, was intensiver crawlt, als es sollte.

„Wir wollen den Traffic nicht blockieren, da wir möchten, dass KI unser Unternehmen hervorhebt. Was sollen wir denn eigentlich tun?“ Gleiche Antwort, andere Formulierung. In KI-Antworten auffindbar zu sein und die Ressourcenbelastung zu kontrollieren, steht nicht im Widerspruch zueinander, da unterschiedliche Bots die jeweiligen Aufgaben übernehmen. Wehre dich gegen Trainings- und Crawler mit hohem Datenaufkommen oder blockiere sie, wenn das dein Anliegen ist, und lass die Such- und Antwort-Crawler ausdrücklich zu.

„Hindern Content-Paywalls KI-Bots daran, diese Inhalte zu scrapen?“ Teilweise, und nur bei Crawlern, die sich wie Crawler verhalten. Eine Login-Barriere stoppt einen Bot, der die normale Seitenstruktur respektiert und keine gültigen Anmeldedaten hat – genauso wie sie jeden anonymen Menschen stoppt. Sie nützt jedoch nichts gegen KI-Tools, die sich eher wie ein echter, nicht angemeldeter Nutzer verhalten oder die denselben Inhalt über eine zwischengespeicherte Kopie, einen RSS-Feed oder einen anderen Umweg erreichen, der die Paywall-Logik überhaupt nicht berührt. Nützlich, ergänzend, aber kein Ersatz für Bot-Schutz.

„Können wir KI-Crawler davon abhalten, unsere WooCommerce-Shop-Filter endlos durchzulaufen?“ Das ist ein Caching- und URL-Struktur-Problem, das sich als Bot-Schutz tarnt. Crawler folgen jedem Link, auf den sie stoßen, und dynamische Filter- und Sortierparameter erzeugen nahezu unendlich viele unterschiedliche URLs für eine Website, die für einen Menschen eigentlich dieselbe ist. Diese Parametermuster in der robots.txt zu blockieren, ist ein sinnvoller erster Schritt:

User-agent: *
Disallow: /*?*filter_
Disallow: /*?*orderby=

Wenn ein Crawler das aber trotzdem ignoriert – was manche tun –, sind ratebasierte Regeln im Bot-Schutz das, was die Schleife tatsächlich durchbricht.

Was das für dich bedeutet

Hör auf, diese vier als konkurrierende Optionen zu betrachten, und behandle sie stattdessen als einen Stapel, der der Reihe nach angewendet wird:

  1. robots.txt legt deine Absicht fest und trennt Trainings-Crawler von Such- und Antwort-Crawlern, je nachdem, was du tatsächlich von jedem einzelnen erwartest.
  2. llms.txt ist, falls du dich damit beschäftigst, eine Höflichkeit gegenüber den Tools, die es lesen, und kein Hebel zur Reduzierung oder Steuerung des Crawling-Volumens.
  3. „KI-Crawler“ umfasst Trainings-Bots, Such-Bots und Abrufe durch Live-Agenten, und jeder davon verdient möglicherweise eine andere Antwort.
  4. Der Bot-Schutz ist der Bereich, in dem die Durchsetzung tatsächlich stattfindet, denn er ist die einzige Ebene hier, die auf eine Anfrage reagieren kann, die all deine Vorgaben ignoriert.

Wenn deine Frage weniger lautet „Wie kontrolliere ich das?“, sondern eher „Wie werde ich davon gefunden?“, knüpfen unsere Anleitungen zu AEO für WordPress und GEO vs. AEO vs. SEO dort an, wo dieser Beitrag aufhört. Um die hier behandelten Einstellungsmöglichkeiten zu erkunden, schau dir den Kinsta-Bot-Schutz an.

Joel Olawanle Kinsta

Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.