robots.txt für KI-Crawler erlauben: Vorlage und Fehler

Eine robots.txt, die KI-Crawler erlaubt, braucht im einfachsten Fall keine Einträge für einzelne Bots: Solange keine Regel sie sperrt, dürfen sie laut Protokoll abrufen. Sobald Sie nach Zweck unterscheiden wollen, schreiben Sie je Bot eine Gruppe mit User-agent und Allow oder Disallow. Danach prüfen Sie das Ergebnis, statt es zu vermuten.

Wie ein Bot Ihre Regeln liest

Das Robots Exclusion Protocol, RFC 9309, definiert das Format. Jede Gruppe beginnt mit einer oder mehreren User-agent-Zeilen, gefolgt von Allow- und Disallow-Regeln. Ein Crawler sucht die Gruppe, die zu seinem Namen passt. Findet er keine, nimmt er die Gruppe mit *. Das erklärt den häufigsten Stolperstein: Ein pauschales Disallow: / unter * sperrt alle Bots, die nicht ausdrücklich eine eigene Gruppe haben. Die Einführung von Google zur robots.txt zeigt dasselbe Prinzip aus Sicht der Suchmaschine.

Eine Datei ist außerdem nur ein Wunsch an kooperierende Bots. Das Protokoll selbst hält fest, dass es keine Zugriffsautorisierung ist.

Vorlage: KI-Suche zulassen, Training bewusst steuern

Die folgende Vorlage ist ein Ausgangspunkt. Prüfen Sie die Bot-Namen vor dem Einsatz bei den Betreibern, weil sie sich ändern:

User-agent: *
Allow: /
Disallow: /intern/

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: PerplexityBot
Allow: /

Sitemap: https://ihre-domain.de/sitemap.xml

Beachten Sie, dass eine Gruppe mit eigenem Namen die Sternregel für diesen Bot ersetzt, nicht ergänzt. Wenn /intern/ auch für OAI-SearchBot gesperrt bleiben soll, müssen Sie es in dessen Gruppe wiederholen.

Welche Entscheidung gehört zu welchem Bot

Ziel	Regelansatz	Hinweis
In KI-Antworten auftauchen	Such- und Abruf-Bots zulassen	Namen beim Anbieter prüfen
Kein Training mit Ihren Texten	Trainings-Bot sperren	Wirkt nur für künftige Abrufe
Google-KI-Nutzung steuern	Token Google-Extended	Siehe Google-Extended
Bereiche schützen	Pfade mit Disallow	Kein Ersatz für Login oder Passwortschutz

Zur Rolle der Bots lesen Sie den Beitrag zu OAI-SearchBot und ChatGPT-User und die Grundlagen zu KI-Crawlern.

Typische Fehler

1. Staging-Datei live gelassen. Ein Disallow: / aus der Entwicklungsumgebung landet auf der Produktivseite. Prüfen Sie nach jedem Relaunch.
2. Falscher Bot-Name. Ein Tippfehler macht die Gruppe wirkungslos.
3. Leerzeilen innerhalb einer Gruppe. Manche Parser trennen dort Gruppen. Halten Sie jede Gruppe zusammenhängend.
4. robots.txt mit falschem Statuscode. Liefert die Datei einen Serverfehler, behandeln Crawler das unterschiedlich. Sie sollte mit 200 und als Klartext antworten.
5. Sperre auf CDN-Ebene. Selbst eine offene robots.txt hilft nicht, wenn eine WAF die Bots abweist. Dazu der Beitrag WAF und CDN blockieren KI-Crawler.

Key takeaway: robots.txt zeigt nur Ihre Absicht. Ob Bots wirklich kommen, sehen Sie erst in den Server-Logs.

Testen in drei Schritten

Rufen Sie die Datei im Browser auf und prüfen Sie Statuscode und Inhalt. Lassen Sie sie dann vom AI Crawler Checker von BusinessMCP auswerten, der laut Anbieter zeigt, welche KI-Crawler (genannt werden GPTBot, ClaudeBot, PerplexityBot) Ihre robots.txt zulässt. Wer mehrere Domains betreut, kann denselben Check über die Data API automatisieren; die Seite nennt 0,01 US-Dollar pro Aufruf und 5 US-Dollar Startguthaben für 7 Tage. Prüfen Sie aktuelle Preise beim Anbieter.

Zuletzt kontrollieren Sie nach ein bis zwei Wochen die Logs. Tauchen die erlaubten Bots auf, passt die Konfiguration. Wie Sie dabei vorgehen, steht in der Logfile-Analyse für KI-Crawler.

Und die llms.txt?

Die llms.txt ersetzt die robots.txt nicht. BusinessMCP beschreibt sie im llms.txt-Leitfaden als Ergänzung, die Verständnis fördern soll, während robots.txt den Zugang regelt. Ohne Zugang hilft die schönste llms.txt nicht. Ob sich der Aufwand lohnt, besprechen wir ehrlich im Beitrag Bringt llms.txt etwas.

Sonderfälle: Subdomains, Shops und Staging

Eine robots.txt gilt nur für den Host, unter dem sie liegt. Haben Sie www.ihre-domain.de, shop.ihre-domain.de und blog.ihre-domain.de, braucht jede Subdomain eine eigene Datei. Das ist der Grund, warum Checks pro Host laufen müssen und warum ein einmaliger Test bei Betrieben mit mehreren Auftritten wenig aussagt.

Onlineshops. Hier sperren viele Filter- und Warenkorb-Pfade, um Crawl-Budget zu sparen. Prüfen Sie, dass diese Regeln nicht versehentlich Kategorie- oder Produktseiten treffen, denn genau die sollen in KI-Antworten vorkommen können. Ein Disallow: /*? ist beliebt und schneidet unter Umständen mehr ab als gedacht.

Staging und Entwicklung. Entwicklungsumgebungen gehören hinter einen Passwortschutz. Eine robots.txt reicht dafür nicht, weil sie ein Hinweis und keine Sperre ist.

Mehrsprachige Seiten. Liegen Sprachen in Unterordnern, genügt eine Datei. Liegen sie auf eigenen Domains, braucht jede ihre eigene.

Pflege im Alltag

Versionieren Sie die Datei wie Code. Notieren Sie bei jeder Änderung Datum, Grund und Verantwortliche. Wenn Ihr CMS die Datei dynamisch erzeugt, prüfen Sie nach jedem Update des Systems oder der SEO-Erweiterung, ob sich der Inhalt verändert hat. Ein automatischer Wochencheck, etwa über die API, vermeidet böse Überraschungen; der Beitrag Website für KI-Suche vorbereiten enthält dafür eine Checkliste.

Wann robots.txt nicht reicht

Wenn Bots Ihre Regeln ignorieren, brauchen Sie Durchsetzung auf Server- oder Netzwerkebene. Umgekehrt gilt: Wenn eine Firewall seriöse Bots abweist, bringt die schönste Freigabe in der robots.txt nichts. Welche der beiden Ebenen den Ausschlag gibt, lässt sich nur mit Logs klären. Auch der Leitfaden von BusinessMCP zum serverseitigen Tracking von KI-Crawlern rät dazu, erst zu messen und dann pro Crawler zu entscheiden. Das ist ein vernünftiger Ablauf, unabhängig davon, welches Werkzeug Sie dafür verwenden.

Kurze Checkliste zum Abschluss

• Datei erreichbar unter /robots.txt, Statuscode 200, Klartext.
• Keine pauschale Sperre unter User-agent: *, es sei denn, sie ist gewollt und begründet.
• Jeder bewusst behandelte KI-Bot steht mit dem aktuellen Namen in einer eigenen Gruppe.
• Pfade, die auch für KI-Bots gesperrt bleiben sollen, sind in jeder Gruppe wiederholt.
• Sitemap-Zeile ist vorhanden und die Adresse stimmt.
• Nach der Änderung wurde mit einem Checker und später in den Logs geprüft.
• Datum, Grund und Verantwortliche sind notiert.

Wenn Sie diese sieben Punkte abgehakt haben, ist der technische Zugang in den allermeisten Fällen sauber geregelt. Alles Weitere, vom Aufbau der Inhalte bis zur Messung der Nennungen, beginnt erst danach. Für Betriebe in der Region finden Sie die lokale Einordnung im Beitrag KI-Sichtbarkeit in Mannheim.