Robots.txt-Leitfaden für SEO und KI-Crawler (2026)

heise hat im Oktober 2025 einen Nachruf auf robots.txt veröffentlicht: „Abschied von robots.txt (1994-2025)" — wehmütig argumentiert, das Protokoll, das das Web zivilisierte, sei tot, weil KI-Crawler die Compliance optional gemacht hätten. Das Framing ist halb richtig. Das Protokoll ist nicht mehr der stille Standard, der es zwei Jahrzehnte lang war. Compliance ist nicht mehr universell. Die Bot-Population, die eine durchschnittliche Site abruft, ist von einer Handvoll Suchmaschinen auf Dutzende KI-Crawler, Agenten und nachgelagerte Scraper explodiert, jeder mit eigener Haltung gegenüber robots.txt.

Aber der Nachruf überspringt die unbequeme Hälfte: die großen KI-Labs haben sich öffentlich verpflichtet, robots.txt für ihre deklarierten User-Agents zu respektieren, und CDN-Betreiber wie Cloudflare berichten breite Compliance bei den benannten Bots — mit dokumentierten Ausnahmen (Perplexity wurde im Juni 2024 von Wired beim Ignorieren von robots.txt erwischt). Das Protokoll funktioniert für die Bots, die öffentlich sagen, dass sie es respektieren. Es ersetzt nur keine Firewall, wenn du echte Durchsetzung brauchst. Dieser Leitfaden ist das ehrliche Bild für 2026: was robots.txt ist, warum sie immer noch zählt, die 19 KI-Crawler-User-Agents, die du wirklich kennen musst, die fünf Muster, die funktionieren, die sechs Fehler, die fast jede Site macht, und der Audit-Workflow, der alle aufdeckt. Live-Audit von 10 Top-Leitfäden auf Google EN + DE zeigt die Lücke: 9 von 10 shippen kein FAQPage, 3 erwähnen KI-Crawler überhaupt nicht, und der meistzitierte US-Leitfaden wurde seit März 2025 nicht mehr angefasst.

Was robots.txt wirklich ist

Robots.txt ist eine reine Textdatei im Wurzelverzeichnis deiner Domain (deineseite.de/robots.txt), die Web-Crawlern sagt, welche Pfade sie abrufen dürfen und welche nicht. Das Format ist standardisiert in RFC 9309, veröffentlicht von der IETF im September 2022. Das war die erste formale Spezifikation nach 28 Jahren De-facto-Verbreitung des Protokolls.

Die Datei wird von jedem gut erzogenen Crawler abgerufen, bevor er irgendeine andere Anfrage an deine Domain stellt. Googlebot, bingbot, GPTBot, ClaudeBot, PerplexityBot: sie alle starten mit einer Anfrage an deineseite.de/robots.txt, parsen sie und nutzen die Regeln, um zu entscheiden, welche URLs als Nächstes folgen. Das Protokoll ist freiwillig: nichts zwingt einen Bot, das Gelesene zu respektieren. Aber für die Bots, die sich öffentlich zu robots.txt bekennen, ist die Datei der effizienteste Weg, das Crawling zu steuern.

Ein Detail, das die meisten Leitfäden auslassen: robots.txt steuert das Abrufen, nicht die Indexierung. Eine in robots.txt gesperrte Seite wird nicht gecrawlt, kann aber im Google-Index erscheinen (ohne Titel und Beschreibung), wenn andere Sites darauf verlinken. Um eine Seite aus dem Index rauszuhalten, brauchst du ein Noindex-Meta-Tag oder einen HTTP-Header, der nur dann funktioniert, wenn der Bot die Seite überhaupt erst abrufen darf. Diese Feinheit ist die Quelle für Fehler Nummer eins im entsprechenden Abschnitt unten.

Warum robots.txt 2026 immer noch zählt

Robots.txt zählt 2026 aus dem gleichen Grund wie 2010, plus einem neuen. Crawl-Budget ist real: Googlebot gibt einer Domain ein endliches Tageskontingent an Abrufen, und in robots.txt gesperrte Seiten setzen dieses Kontingent für Inhalte frei, die wirklich indexiert werden sollen. KI-Crawler legen eine zweite Schicht obendrauf: Training-Opt-out, Echtzeit-Zitierfähigkeit, alles über eine einzige Datei.

Der klassische Fall ist klar. Sites mit tausenden Low-Value-URLs (Filter-Navigation, interne Suche, Kalender-Seiten, Session-getaggte URLs) verschwenden Crawl-Budget, wenn sie Googlebot daran lassen. Eine präzise robots.txt lenkt das Budget zurück auf kanonische Inhalte und verbessert die Aktualität der indexierten Seiten. Mueller hat das in mehreren Search-Off-the-Record-Episoden bestätigt: die Crawl-Priorisierung reagiert auf Disallow-Regeln, und die Reaktion ist meist innerhalb einer Woche sichtbar.

Der neue Fall ist die KI. ChatGPT, Claude, Perplexity und Googles Gemini-Suite betreiben jeweils einen oder mehrere Crawler, und die Crawler teilen sich auf drei Aufgaben auf: künftige Modelle trainieren, einen Retrieval-Index für Live-Antworten aufbauen, und im Auftrag eines eingeloggten Nutzers als Agent agieren. Jede Aufgabe nutzt einen eigenen User-Agent. Robots.txt ist der einzige standardisierte Ort, an dem du einem Trainings-Crawler „nein" und einem Retrieval-Crawler gleichzeitig „ja" sagen kannst: Opt-out aus den LLM-Trainingsdaten, ohne in der KI-Suche unsichtbar zu werden.

Das Dateiformat (RFC 9309)

RFC 9309 definiert exakt fünf Dinge in einer robots.txt-Datei: User-Agent-Deklarationen, Allow-Regeln, Disallow-Regeln, das Kommentar-Zeichen (#) und ein paar Formatierungs-Kleinigkeiten. Alles andere (Crawl-delay, Sitemap, Host) ist nicht-standard, aber breit unterstützt. Die Spezifikation lässt sich in fünfzehn Minuten lesen und beantwortet die meisten Edge-Cases, über die dein Team streiten könnte.

Hier eine minimal gültige robots.txt, die jede Direktive enthält, die eine typische Site braucht:

User-agent: *
Disallow: /admin/
Disallow: /search?
Disallow: /tmp/
Allow: /admin/help/

User-agent: Googlebot
Disallow: /staging/

Sitemap: https://example.com/sitemap.xml

Die Datei wird von oben nach unten gelesen. Jede User-Agent-Zeile öffnet eine Gruppe, und die Regeln darunter gelten für diesen User-Agent bis zur nächsten User-Agent-Zeile. Die erste Gruppe, deren User-Agent passt, gewinnt (spezifischste Übereinstimmung). Wildcards funktionieren beim Pfad-Matching: * matcht eine beliebige Zeichenfolge, $ matcht das URL-Ende. Disallow: /*.pdf$ sperrt also jede PDF-Datei der Site.

Die Allow-Direktive überschreibt eine Disallow-Regel innerhalb derselben Gruppe. Die Reihenfolge spielt keine Rolle, weil die längste passende Regel gewinnt. Disallow: /admin/ gefolgt von Allow: /admin/help/ heißt also: „sperre den Admin-Bereich, lass aber den Hilfe-Abschnitt durch". Die meisten Sites stellen das in der falschen Reihenfolge dar; das ändert das Verhalten nicht, verwirrt aber Leser.

Drei Dinge, die wie Teil der Spec aussehen, aber keiner sind: Crawl-delay (Bing und Yandex respektieren sie, Google ignoriert sie, der Wert sind Sekunden zwischen Anfragen), Host (Yandex nutzt es zur Auswahl der kanonischen Domain, sonst niemand) und die Noindex-robots.txt-Direktive aus alten Leitfäden (Google hat den Support im September 2019 entfernt, war nie verlässlich, kommt nicht zurück).

Die KI-Crawler-Schicht: 19 neue User-Agents

Die KI-Crawler-Population ist zwischen 2022 und 2026 von null auf neunzehn gewachsen. Jeder Anbieter hat eigene User-Agents, oft nach Zweck getrennt. Die wichtigste Aufteilung ist Training gegen Retrieval: Trainings-Crawler holen Inhalte, um künftige Modelle zu schulen; Retrieval-Crawler holen live während einer Nutzeranfrage und liefern die Zitate.

Die Aufteilung Training vs. Retrieval ist die handlungsrelevante. Wer aus den LLM-Trainingsdaten raus will, aber zitierfähig bleiben möchte, blockt die Trainings-Crawler und lässt die Retrieval-Crawler durch. Konkret bei OpenAI: Disallow: GPTBot sperrt Training, Allow: OAI-SearchBot, ChatGPT-User hält dich in ChatGPT Search zitierfähig. Anthropic funktioniert genauso: ClaudeBot und anthropic-ai sperren für Trainings-Opt-out, Claude-SearchBot und Claude-User erlauben für Live-Zitate. Das ist die Konfiguration, die die meisten Publisher tatsächlich wollen, und es ist die Konfiguration, die die meisten bestehenden robots.txt-Dateien nicht haben, weil sie aus der Zeit vor dem User-Agent-Split stammen.

Die 5 Muster, die funktionieren

Fünf robots.txt-Konfigurationen decken rund 90 Prozent der realen Sites ab. Jede löst ein anderes Problem; die meisten Sites brauchen eine Kombination aus zwei oder drei. Welches Muster du wählst, hängt davon ab, ob deine Priorität Crawl-Budget, KI-Trainings-Opt-out, KI-Retrieval-Sichtbarkeit oder Inhalts-Sicherheit ist (mit der Einschränkung, dass robots.txt fürs Sicherheits-Thema das falsche Werkzeug ist).

1. Die minimale Alles-Erlaubt-Datei

Für eine Site ohne spezifischen Sperr-Bedarf reichen zwei Zeilen:

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

Das sagt explizit „alle Crawler willkommen, ganze Site erlaubt". Die Sitemap-Zeile zeigt Crawlern den Weg zur sitemap.xml. Mehr braucht es nicht. Viele kleine Sites überkomplizieren ihre robots.txt; das hier ist die richtige Baseline.

2. Crawl-Budget-Schutz

Für Sites mit Filter-Navigation, interner Suche, Kalendern oder Session-getaggten URLs sperrst du gezielt die rauschintensiven Pfade:

User-agent: *
Disallow: /search?
Disallow: /*?session=
Disallow: /*?utm_
Disallow: /tag/
Disallow: /author/

Sitemap: https://example.com/sitemap.xml

So bleibt Googlebot auf kanonischen Inhalten konzentriert. Sperr Parameter-Explosionen, lass aber niemals echte Produkt-, Artikel- oder Service-Seiten weg.

3. KI-Trainings-Opt-out, Retrieval erlaubt

Die 2026er-Default-Wahl der meisten Publisher: Opt-out aus den Trainingsdaten, in der KI-Suche zitierfähig bleiben:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: Bytespider
Disallow: /

# Retrieval-Bots bleiben erlaubt — Zitate in KI-Antworten willkommen
User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

4. Voller KI-Block

Aus Marken- oder rechtlichen Gründen (Paywall-Nachrichten, urheberrechtlich geschützter IP, regulierter Content) sperrst du alle KI-Crawler einschließlich Retrieval:

User-agent: GPTBot
User-agent: ChatGPT-User
User-agent: OAI-SearchBot
User-agent: ClaudeBot
User-agent: Claude-User
User-agent: Claude-SearchBot
User-agent: anthropic-ai
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Google-Extended
User-agent: Applebot-Extended
User-agent: CCBot
User-agent: Bytespider
User-agent: Meta-ExternalAgent
User-agent: MistralAI-User
User-agent: DeepSeekBot
User-agent: xAI-Web-Crawler
User-agent: cohere-ai
Disallow: /

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

Beachte: das stoppt nur die benannten Bots. Common Crawls CCBot scraped für viele nachgelagerte Open-Source-Modelle. Wer CCBot blockt, beeinflusst also Modelle, von denen man noch nie gehört hat. Für harte Durchsetzung legst du das mit einer Cloudflare-WAF-Regel oder einem serverseitigen Block in Schichten übereinander.

5. Abschnittsspezifische Regeln

Für Sites, bei denen manche Bereiche KI sperren, andere zulassen sollen (eine Marketing-Site, die KI auf dem Blog erlaubt, aber in den Docs sperrt):

User-agent: GPTBot
Disallow: /docs/
Allow: /

User-agent: ClaudeBot
Disallow: /docs/
Allow: /

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

Die Logik der längsten passenden Regel führt dazu, dass Disallow auf /docs/ über Allow auf / gewinnt. Der Docs-Bereich ist also für die benannten Bots gesperrt, der Rest der Site bleibt offen.

Die 6 häufigsten Fehler

Sechs wiederkehrende Fehler machen den Großteil der robots.txt-Probleme aus, die ich in Audits sehe. Keiner davon ist subtil, alle sind häufig, und jeder kostet Traffic, Crawl-Budget oder KI-Sichtbarkeit. Die meisten Production-Dateien, die ich prüfe, haben mindestens zwei der sechs an Bord. Die Korrektur unten dauert in Summe einen Nachmittag.

1. Disallow auf einer Seite, die du deindexieren willst

Der häufigste Fehler im ganzen Web. Um eine Seite aus Google zu entfernen, ist das Noindex-Meta-Tag das richtige Werkzeug. Ist die Seite aber zusätzlich in robots.txt gesperrt, ruft Googlebot sie nicht ab, sieht das Noindex-Tag nicht und behält die URL möglicherweise im Index, gestützt auf eingehende Links. Die korrekte Reihenfolge: lass die Seite crawlbar, füg Noindex hinzu, warte, bis Google sie neu crawlt und entfernt, und füg dann optional die Disallow hinzu, wenn du künftige Crawls verhindern willst.

2. CSS oder JavaScript sperren

Ältere robots.txt-Dateien sperren oft /wp-content/, /assets/ oder /js/ aus „Performance-Gründen". Das bricht Googles Fähigkeit, die Seite korrekt zu rendern. Googlebot braucht CSS und JS, um Mobile-Friendliness, Layout-Shift und Inhalts-Sichtbarkeit zu bewerten. Modernes Googlebot-Rendering hängt vom vollen Asset-Zugriff ab. Lass CSS und JS zu, außer du hast einen sehr spezifischen Grund zu sperren, und sperre niemals den Pfad mit deinen CMS-Asset-Bundles.

3. Robots.txt als Sicherheits-Schicht

Robots.txt ist öffentlich lesbar. /admin/, /staging/ oder /backup/ in den Disallow-Regeln aufzulisten zeigt jedem, der deineseite.de/robots.txt abruft, genau die Pfade, die existieren und die du nicht besucht haben möchtest. Für echten Schutz nutze HTTP-Authentifizierung, IP-Allowlists oder VPN-only-Zugriff. Reservier robots.txt für Pfade, die du nur nicht crawlen lassen willst, nicht für Pfade, die du nicht entdeckt haben willst.

4. Wildcards in User-Agent-Namen

RFC 9309 erlaubt Wildcards beim Pfad-Matching, nicht aber bei User-Agent-Namen. User-agent: GPT* matcht nicht GPTBot, sondern einen literalen User-Agent-String „GPT*", den kein Bot nutzt. Jeder KI-Crawler muss mit seinem exakten Namen aufgelistet werden. Ja, das heißt bis zu 19 User-Agent-Zeilen, wenn du alle blocken willst (siehe Muster 4 oben).

5. Konfliktierende Regeln aus mehreren Dateien

Eine robots.txt liegt an exakt einem Ort: im Wurzelverzeichnis der Domain (deineseite.de/robots.txt). Wenn ein CMS automatisch eine erzeugt und gleichzeitig eine statische Datei im Repo liegt, kann es zwei konkurrierende Dateien geben. Browser holen sich die zuerst ausgelieferte. Audit-Methode: ruf deineseite.de/robots.txt selbst ab und vergleich, ob das, was du tatsächlich auslieferst, mit dem übereinstimmt, was du beabsichtigst.

6. Die Sitemap-Direktive vergessen

Die Sitemap-Direktive in robots.txt ist der zuverlässigste Weg, jedem Crawler zu zeigen, wo deine Sitemap liegt. Die meisten CMS fügen sie nicht automatisch hinzu. Eine Zeile am Ende: Sitemap: https://deineseite.de/sitemap.xml. Mehrere Sitemap-Zeilen, wenn du mehrere Sitemaps hast (eine pro Sprache, eine pro Content-Typ). Kostet nichts und hilft jedem Crawler beim Auffinden deines kompletten URL-Sets.

Robots.txt vs. Noindex vs. WAF: welches Werkzeug wann

Robots.txt, das Noindex-Meta-Tag und ein serverseitiger WAF-Block lösen unterschiedliche Probleme, und sie in der falschen Reihenfolge zu kombinieren produziert vorhersehbare Pannen. Welches Werkzeug richtig ist, hängt davon ab, ob der Bot die URL abrufen, sehen oder gar nicht erst finden soll.

Der häufigste Kombi-Fehler: Disallow plus Noindex auf derselben URL. Die Disallow verhindert, dass das Noindex überhaupt gelesen wird, sodass die URL ohne Snippet im Google-Index erscheinen kann. Wer eine URL aus dem Index will, lässt sie crawlbar, fügt Noindex hinzu und denkt erst an Disallow, sobald Google die Seite neu gecrawlt und entfernt hat (typischerweise nach ein paar Wochen).

Wie du deine robots.txt auditierst (3 Methoden)

Drei Audit-Methoden fangen den Großteil der robots.txt-Probleme ab. Jede dauert für eine typische Site unter 15 Minuten, und alle drei auf einer kritischen Domain zu fahren liefert dir Cross-Validierung. Die meisten Production-robots.txt-Dateien, die ich auditiere, haben mindestens einen Befund aus dieser Liste.

Methode 1: Lumina Crawler-Access-Checker

Pasten irgendeine URL in Luminas Crawler-Access-Checker. Das Tool ruft deine robots.txt ab, parst jede Regel und prüft den Zugriffsstatus für 36 verschiedene Crawler (19 KI plus 17 klassische Suchbots). Für jeden Bot bekommst du ein klares Erlaubt-oder-Gesperrt-Verdict für die eingereichte Seite, plus die passende Regel, die das Verdict ausgelöst hat. Nutz es, um zu prüfen, ob dein Trainings-Opt-out wirklich die Bots blockt, die du blockieren willst, und ob deine Retrieval-Allowlist tatsächlich die Bots durchlässt, die dich zitieren sollen.

Methode 2: Google-Search-Console-robots.txt-Bericht

In der Search Console gehst du auf Einstellungen → Crawling → robots.txt. Der Bericht zeigt die Version deiner robots.txt, die Google zuletzt abgerufen hat, alle Parsing-Fehler und einen Tester, mit dem du prüfen kannst, ob Googlebot eine bestimmte URL unter den aktuellen Regeln abrufen darf. Nutz es als Quelle der Wahrheit für das, was Google tatsächlich sieht, gerade nach einem Deploy, wenn das Caching bis zu 24 Stunden hinterherhinken kann.

Methode 3: Direkter Abruf + manuelle Prüfung

Öffne deineseite.de/robots.txt im Browser. Bestätige: die Datei existiert, gibt HTTP 200 zurück, hat eine Sitemap-Zeile am Ende, listet User-Agents auf, die du wirklich blocken willst, und enthält keine Überraschungen (CMS-injizierte Pfade, Reste von Staging-Regeln, doppelte User-Agent-Gruppen). Mach diese manuelle Prüfung mindestens vierteljährlich. Robots.txt ist genau die Art Datei, die von Plugins oder Deploy-Skripten still verändert und nie wieder angeschaut wird.

KI-Crawler und die neue Compliance-Realität

Die Compliance der KI-Crawler mit robots.txt ist freiwillig, wie jede robots.txt-Regel. Aber die großen Anbieter haben sich öffentlich verpflichtet, sie für ihre deklarierten User-Agents zu respektieren. OpenAI dokumentierte GPTBots Compliance im August 2023; Anthropic, Perplexity, Google und Apple zogen nach. Cloudflares Berichte von 2024 zeigten breite Compliance bei den benannten Bots, mit dokumentierten Ausnahmen (Perplexity wurde im Juni 2024 von Wired beim Ignorieren von robots.txt erwischt).

Die Lücke entsteht, wenn Inhalte von einem Bot abgeholt werden, der robots.txt überhaupt nicht respektiert. Common Crawls CCBot ist technisch compliant, er respektiert Disallow-Regeln. Aber der öffentliche Datensatz, den er produziert, wird von Dutzenden nachgelagerten KI-Modellen konsumiert, von denen sich manche auf deiner Site nie identifizieren. CCBot zu blocken ist das, was robots.txt einer „Block Training generell"-Option am nächsten kommt. Auch das fängt nicht jede nachgelagerte Nutzung ein.

Die tiefere Compliance-Frage: selbst wenn ein KI-Lab sich öffentlich zu robots.txt bekennt, bindet diese Verpflichtung den benannten User-Agent. Ein Forschungs-Team in derselben Firma kann einen unbenannten Crawler laufen lassen, und die offizielle robots.txt-Verpflichtung gilt für ihn nicht. Genau deshalb legen Publisher, die harte Durchsetzung wollen, Cloudflares AI Bot Block (der auf Netzwerk-Ebene blockt) auf ihre robots.txt-Regeln drauf. Robots.txt ist eine höfliche Bitte, der WAF ist die Durchsetzung.

Für die meisten Sites reicht die höfliche Bitte. Die großen KI-Labs haben geschäftliche Gründe, sie zu respektieren (Regulierungsdruck, Markenrisiko, PR), und die Daten zeigen, dass sie das tun. Aber „reicht für die meisten Sites" ist nicht „reicht für alle Sites". Publisher mit hochwertigen Paywall-Inhalten, regulierte Branchen und markenkritische Properties sollten robots.txt und WAF zusammen fahren, statt sich allein auf robots.txt zu verlassen.

Ein 5-Schritte-Workflow für robots.txt 2026

Fünf Schritte führen jede Site in einem fokussierten Nachmittag zu einer sauberen, modernen robots.txt-Konfiguration. Die ersten drei sind diagnostisch, die letzten zwei sind Konfiguration. Die meisten Sites schaffen den ganzen Workflow in zwei oder drei Stunden, inklusive einer echten Bestandsaufnahme und einer überlegten Policy-Entscheidung vor dem Deploy.

FAQ

Wo du anfängst

Wenn du diese Woche genau eine Sache machen kannst: ruf deineseite.de/robots.txt ab und lass sie durch Luminas Crawler-Access-Checker laufen. Die meisten Sites haben eines von drei Problemen: eine veraltete Regel, die einen Bereich sperrt, der offen sein sollte; eine fehlende KI-Crawler-Sperre; oder eine fehlende Sitemap-Direktive. Diese drei Punkte zu fixen dauert einen Nachmittag.

Wenn du mehr Zeit hast, arbeite den 5-Schritte-Workflow oben durch. Der größte Hebel für die meisten Publisher 2026 ist das Muster Trainings-Opt-out plus Retrieval-Erlaubnis. Es signalisiert den KI-Labs, dass du über deine Daten nachgedacht hast, holt dich aus den Trainings-Datasets raus, die dir nichts bringen, und hält dich in Echtzeit-KI-Antworten zitierfähig. Genau dort lebt der KI-getriebene Traffic. Beide Updates landen in derselben Datei, der Deploy ist ein Commit, und der Effekt ist innerhalb von Minuten in den Crawler-Access-Checker-Ergebnissen sichtbar.

Julien El-Bahy

Web Development Lead und Schöpfer von Lumina SEO. Spezialisiert auf SEO, GEO und KI-gestützte Such-Tools.

Auf LinkedIn vernetzen →

Verwandte Tools & Artikel