Inhaltsverzeichnis
tl;dr: Die robots.txt ist von der Crawl-Budget-Krücke zur Zugriffspolitik geworden. Denn KI-Bots sprießen quasi aus dem Boden. Wer 2026 jedoch einfach alle KI-Bots blockt, verliert messbar Traffic. Wer alle durchlässt, füttert im Gegensatzu dazu Modelle, die kaum etwas zurückgeben. Wir zeigen dir, wie eine differenzierte Konfiguration aussieht, was Cloudflares Managed Signals sind und warum die llms.txt nach 22 Monaten immer noch fast niemand liest.
Die robots.txt ist von 1994. Den RFC-Status hat sie erst seit 2022 bekommen. Und jetzt, mit über 30 Jahren auf dem Buckel, ist sie das einzige halbwegs universelle Werkzeug, mit dem du KI-Bots und Crawlern sagen kannst, was sie mit deinen Inhalten dürfen (und nicht dürfen). Das ist gleichzeitig beruhigend und ziemlich unbefriedigend.
Was sich bei der robots.txt geändert hat
Früher war die robots.txt eine reine Crawl-Steuerung. Eine Suchmaschine (die früher meistens Google war) kommt auf deine Website, du hältst sie von Filtern, Suchergebnisseiten und Warenkorb-URLs weg, fertig.
Heute stellst du damit vier verschiedene Fragen auf einmal:
- Darf mein Content in einen Suchindex?
- Darf er in ein Modelltraining?
- Darf er zur Laufzeit in eine KI-Antwort gezogen werden?
- Darf ein Agent, den ein echter Mensch losgeschickt hat, meine Seite abrufen?
Diese vier Fälle haben komplett unterschiedliche wirtschaftliche Folgen. Training bringt dir nichts zurück, davor profitiert nur der Anbieter. Retrieval bringt dir eine Nennung, im besten Fall einen Klick auf deine Website. Ein User-Agent, der für einen echten Kunden ein Produkt sucht, ist praktisch qualifizierter Traffic. Der Fehler, den wir am häufigsten sehen: es werden alle vier Fälle über einen Kamm geschert.
Zahlen, die eine Entscheidung erschweren
Anthropic (Claude) hat laut einer im Februar 2026 dokumentierten Auswertung für jeden einzelnen Besuch, den sie an Publisher zurückgeschickt haben, 38.000 Seiten gecrawlt. Das Verhältnis ist absurd, und es ist ein gutes Argument fürs Blocken solcher Bots.
Die US-amerikanischen Unis Wharton und Rutgers haben eine Studie betrieben, was dieses Blocken kostet. News-Publisher, die AI-Crawler per robots.txt ausgesperrt haben, haben innerhalb von sechs Wochen rund 7% ihres wöchentlichen Website-Traffics verloren. Eine frühere Version derselben Studie kam sogar auf 23%. Der Rückgang zeigte sich also auch in den menschlichen Browsing-Daten, nicht nur in den Bot-Metriken.
Das ist der eigentliche Trade-off, und er ist unangenehm. Wir sind der Meinung, für Shops und Dienstleister ist die Lage etwas entspannter als für Publisher, weil weniger Content substituierbar ist. Aber grundsätzlich kann man attestieren, pauschales Blocken kostet Sichtbarkeit, und zwar auch bei echten Menschen.
Die Crawler-Taxonomie 2026
Zuerst musst du wissen, welche Bots überhaupt auf deiner Website vorbeikommen. Cloudflare hat seine Bot-Klassifikation im Juli 2026 auf drei Funktionen umgestellt: Search, Agent und Training. Das ist die aus unserer Sicht bislang brauchbarste Einteilung, weil sie am Verwendungszweck ansetzt und nicht am Absender.
| User-Agent | Betreiber | Beachtet robots.txt |
|---|---|---|
| Training · crawlt fürs Modell, kein Rückkanal | ||
| GPTBot | OpenAI | Ja |
| ClaudeBot | Anthropic | Ja |
| Google-Extended | Ja · reines Opt-out-Token, kein eigener Crawler | |
| Applebot-Extended | Apple | Ja |
| meta-externalagent | Meta | Ja |
| CCBot | Common Crawl | Ja |
| Amazonbot | Amazon | Ja |
| cohere-ai | Cohere | Ja |
| Bytespider | ByteDance | Nein · nur per WAF-Regel blockbar |
| Search & Retrieval · holt Content für AI-Antworten, nennt dich | ||
| OAI-SearchBot | OpenAI | Ja |
| Claude-SearchBot | Anthropic | Ja |
| PerplexityBot | Perplexity | Laut Betreiber ja · Cloudflare dokumentierte 2025 Umgehungen |
| User-triggered · ein Mensch hat auf Enter gedrückt | ||
| ChatGPT-User | OpenAI | Ja |
| Claude-User | Anthropic | Ja |
| Google-Agent | Nein · ignoriert sie per Definition, seit März 2026 | |
Stand: 30. Juli 2026.
Der letzte Block ist wichtig: der „Google-Agent„, im März 2026 offiziell in die Crawler-Liste aufgenommen, ignoriert die robots.txt komplett. Aus Googles Sicht ist das nur konsequent. Der Abruf passiert im Auftrag eines Menschen, der gerade auf Enter gedrückt hat, und für dessen Handlungen gilt robots.txt seit 1994 nicht. Steuern kannst du diese Abrufe über die Datei also gar nicht.
Zwei Sachen, die du dir merken solltest:
„Google-Extended“ ist ein reines Opt-out-Token für Gemini-Training, kein eigenständiger Crawler. Der Googlebot crawlt ganz normal weiter. Wer „Google-Extended: Disallow“ setzt, verliert nichts an klassischer Sichtbarkeit, verliert aber unter Umständen Gemini-Grounding. Ob letzteres schmerzt, hängt davon ab, wie sehr du auf AI-Overviews spielst.
„Bytespider“ hält sich laut mehreren Auswertungen ohnehin nicht an Disallow-Regeln. Wenn du ByteDance draußen haben willst, brauchst du eine WAF-Regel (WAF steht für „Web Application Firewall“), keinen Höflichkeitsvermerk.
Content Signals von Cloudflare
Cloudflare hat im September 2025 die Content Signals Policy eingeführt und über 3,8 Millionen Domains ausgerollt.
Die Syntax ist eine Zeile innerhalb einer User-Agent-Gruppe:
User-Agent: *
Content-signal: search=yes, ai-input=yes, ai-train=no
Allow: /
Hier sind folgende drei Kategorien definiert:
- search (Suchindex bauen, Snippets zeigen),
- ai-input (Content zur Laufzeit in ein Modell geben, also RAG und Grounding) und
- ai-train (Training und Fine-Tuning).
RAG (Retrieval-Augmented Generation) und Grounding sind Methoden in der Künstlichen Intelligenz, um die Antworten von Sprachmodellen genauer zu machen und Fehler oder frei erfundene Inhalte (sogenannte Halluzinationen) zu verhindern.
Seit dem 1. Juli 2026 gibt es ein viertes Feld: „use„. Es beschreibt, was ein Crawler mit dem Content nach dem Abruf machen darf, in drei Stufen.
- „use=immediate“ erlaubt Interaktion, aber keine Speicherung und keine Wiederverwendung.
- „use=reference“ erlaubt Indexierung, Ausschnitte und Zitate, solange auf die Quelle verlinkt wird.
- „use=full“ erlaubt eine Zusammenfassung und eine Reproduktion.
Nun zum kritischen Teil: Kein großer Crawler-Betreiber hat Support für Cloudflares Content Signals zugesprochen. Stand Ende Juli 2026 gibt es keine bekannte Adoption bei den LLM-Anbietern. Kein Commitment von OpenAI, keines von Anthropic, keines von Google.
Cloudflare versucht das über Druck zu lösen. Verified Bots, die die deklarierten Präferenzen ignorieren, verlieren ihren Status, und die Compliance wird in BotBase getrackt. Weil über 20% aller Webdomains hinter Cloudflare liegen, hat diese Drohung Gewicht.
isitagentready.com von Cloudflare
Cloudflare hat unter isitagentready.com einen robots.txt-Scanner online gestellt. Er prüft in fünf Kategorien:
- Discoverability (robots.txt, Sitemap, Link-Header, DNS-AID),
- Content Accessibility (Markdown Content Negotiation),
- Bot Access Control (AI-Bot-Regeln, Content Signals, Web Bot Auth),
- Protocol Discovery (MCP Server Card, Agent Skills, WebMCP, API Catalog, OAuth Discovery) und
- Commerce (x402, MPP, UCP, ACP).
Als Inventur ist das brauchbar. Du siehst in 30 Sekunden, was deine Domain nach außen preisgibt. Als Bewertungsmaßstab ist es mit Vorsicht zu behandeln. Ein großer Teil der geprüften Standards hat nahe null Adoption, und Cloudflare hat naturgemäß ein Interesse daran, dass die Liste lang wirkt.
Die Handlungsempfehlungen sind laut eigenem Disclaimer KI-generiert. Wer den Score als KPI ins Reporting hebt, optimiert auf Protokolle, die möglicherweise nie ankommen. Cloudflares eigene Antwort auf „wie verbessere ich meinen Score“ ist übrigens ehrlich kurz: erstelle eine valide robots.txt mit KI-Bot-Regeln und einer Sitemap-Direktive, dazu sinnvolle Discovery-Header auf der Startseite.
So konfigurierst du eine robots.txt in 2026
In den nachfolgenden Schritten zeigen wir dir, wie wir eine robots.txt für einen Kunden aufsetzen:
Schritt 1: Logs anschauen, nicht raten. Welche Bots kommen überhaupt, mit welchem Volumen, auf welche Pfade? Ohne diese Daten konfigurierst du gegen ein Phantom. Bei Cloudflare geht das über Bot Analytics, sonst über die Server-Logs, Screaming Frog Log File Analyser oder ein GA4-Server-Side-Setup.
Schritt 2: Wir treffen eine Entscheidung pro Funktion, nicht pro Bot. „Search“ und „AI-Input“ ja, „AI-Train“ nein. Das ist unser Default für Shops und Websites. Wer Content als Produkt verkauft, wird AI-Input ebenfalls einschränken wollen.
Schritt 3: Klassische Crawl-Hygiene bleibt. Facettierte Filter, interne Suche, Warenkorb, Checkout, Tracking-Parameter, Print-Views. Das ist alles nach wie vor sinnvoll und empfohlen in Bezug auf dein Crawlbudget.
Schritt 4: Sitemap-Direktive als absolute URL ganz am Ende rein. Ja, das ist wirklich immer noch relevant, und einer der zwei Punkte, die Cloudflare selbst als Quick Win nennt.
Schritt 5: Testen. Entweder über den robots.txt-Tester in der GSC, dazu ein „curl -A „GPTBot“ https://domain.at/robots.txt“ und ein Abruf ohne User-Agent. Wenn du Cloudflare auf deiner seite aufgeschalten hast, prüfe zusätzlich, was der Origin ausliefert und was der Edge daraus macht.
Fallstricke, die regelmäßig Schaden anrichten
Disallow ist kein Noindex. Eine per robots.txt gesperrte URL kann trotzdem im Index landen, wenn sie verlinkt ist. Google sieht dann den Inhalt nicht, kennt aber die URL. Wenn etwas raus soll: „noindex“ im Header oder Meta-Tag, und die URL crawlbar lassen. Sonst kann Google das noindex nie lesen.
Disallow ist kein Zugriffsschutz. Die Compliance ist freiwillig. Wer wirklich blocken will, braucht WAF-Regeln, Rate Limiting oder AI Crawl Control. Die robots.txt formuliert (leider) lediglich nur eine Präferenz.
5xx auf der robots.txt ist gefährlich. Google behandelt einen Serverfehler bei der robots.txt zunächst als „alles gesperrt“. Erst nach längerer Zeit fällt es auf die letzte gecachte Version oder auf „keine Einschränkungen“ zurück. Ein kaputtes Origin plus ein unaufmerksamer Monitoring-Setup kostet dich deine Rankings.
Größenlimit. Google liest maximal 500 KB. Alles darüber wird ignoriert. Bei generierten Dateien mit tausenden Disallow-Zeilen ist das theoretisch erreichbar. In der freien Wildbahn habe ich es allerdings noch nie gesehen ;)
Nur eine Gruppe pro Bot. Crawler wenden die spezifischste passende User-Agent-Gruppe an, und nur diese. Wenn du „User-agent: GPTBot“ mit einer eigenen Gruppe anlegst, gelten die Regeln aus „User-agent: *“ für GPTBot nicht mehr. Genau hier entstehen die leisen Fehler.
Subdomains und Protokolle sind getrennt. „shop.domain.at“ braucht seine eigene robots.txt. Die vom Host ohne Subdomain (domain.at oder www.domain.at) gilt dort nicht.
Warum die llms.txt (noch) keine Rolle spielt
Jeremy Howard hat die llms.txt am 3. September 2024 vorgeschlagen. Dabei handelt es sich um eine Markdown-Datei im Root-Verzeichnis, die KI-Modellen die wichtigsten Seiten und den Aufbau der Website zusammenfasst.
Die Idee an sich ist unserer Meinung nach gut. Context-Windows sind begrenzt, HTML ist teuer zu parsen, eine kuratierte Karte senkt die Kosten fürs Verstehen einer Seite.
22 Monate später sieht die Bilanz jedoch eher ernüchternd aus. Ahrefs hat Server-Logs von 137.000 Domains ausgewertet. 97% aller llms.txt-Dateien haben im Mai 2026 exakt null Requests bekommen. Bei den Dateien, die überhaupt abgerufen wurden, waren die Top-Requester SEO-Audit-Tools mit 21,7%, gefolgt von nicht identifizierten Bots (14,9%) und Webcrawlern (13,1 %). AI-Retrieval-Bots kamen auf 1,1%. GPTBot auf 4,51%, ClaudeBot auf 0,80%.
Die Dateien werden also hauptsächlich von den Tools gelesen, die prüfen, ob es die Dateien gibt. Das hat eine gewisse Komik. Die Anbieter senden widersprüchliche Signale, und zwar alle drei auf dieselbe Weise. Google, OpenAI und Anthropic verweisen Site-Betreiber für Crawler-Steuerung auf die robots.txt.
Gleichzeitig hat jeder von ihnen allerdings eine llms.txt für die eigene Developer-Dokumentation publiziert. Google hat am 15. Mai 2026 im AI-Search-Guide festgehalten, dass eine llms.txt weder positiv noch negativ auf Rankings wirkt, und das am 15. Juni 2026 nochmal explizit als „nicht erforderlich“ nachgeschärft. John Mueller hatte schon im Juni 2025 auf der Social-Media-Plattform bluesky gesagt, dass kein AI-System die Datei nutzt.
Gegenläufig hat Chrome Lighthouse 13.3 den llms.txt-Audit am 7. Mai 2026 aus dem experimentellen Status in die Kategorie „Agentic Browsing“ geholt. Innerhalb von Google widersprechen sich Search und Chrome damit offen.
Unser Fazit dazu: Für eine Doku-Site, eine API-Referenz oder eine strukturierte Produktdatenbank ist eine llms.txt eine sinnvolle, günstige Ergänzung. Coding-Assistenten und Doku-bewusste Agenten holen sie gelegentlich ab.
Für Sichtbarkeit in der KI-Suche ist sie kein Hebel, und wer sie Kunden als GEO-Maßnahme verkauft, verkauft bloß Hoffnung. Die llms-full.txt würden wir in den meisten Fällen weglassen: hier finden sich 100.000e Wörter in einer Datei, man hat einen laufenden Pflegeaufwand, der dokumentierte Nutzen ist nahe null.
Checkliste zum Mitnehmen
- Bot-Traffic in den Logs prüfen, bevor du konfigurierst
- Nach Funktion entscheiden: Training, Retrieval, Agent
- Sitemap-Direktive mit absoluter URL einbinden
- Bytespider und Co. über WAF blocken, nicht über robots.txt
- Termin Anfang September 2026: Cloudflare-Defaults prüfen, sonst riskierst du eine Blockierung des Googlebots
- Quartalsweise nachziehen, es kommen laufend neue (und auch relevante) User-Agents
- Eine llms.txt ist nur bei Doku, API oder strukturierten Produktdaten nützlich
Wenn du bei einem Punkt unsicher bist, kannst du uns gerne kontaktieren. Solche Konfigurationen reparieren und optimieren wir in der Agentur inzwischen regelmäßig, meistens nachdem jemand einen Schalter in Yoast SEO, bei RankMath oder in Cloudflare umgelegt hat, ohne die robots.txt danach zu checken.