robots.txt

Wie funktioniert die robots.txt?

Bevor ein Crawler Seiten einer Website abruft, lädt er die Datei unter /robots.txt und prüft, ob die gewünschte Adresse für ihn gesperrt ist. Mit dieser Datei regeln Betreiber den Suchmaschinenzugriff auf ihre Website. Genau genommen steuert sie das Crawling, also den Abruf von URLs, und nicht die Indexierung.

Wo die Datei liegen muss, legt der Standard RFC 9309 (Request for Comments) fest. Sie muss robots.txt heißen, in Kleinbuchstaben, und im Stammverzeichnis stehen, etwa unter https://www.example.com/robots.txt. In Unterverzeichnissen suchen Crawler nicht nach ihr. Ihre Regeln gelten nur für den Host, das Protokoll und den Port, unter denen sie abrufbar ist. Eine Datei unter https://www.example.com/robots.txt gilt also weder für http://www.example.com noch für eine Subdomain wie banking.example.com, die eine eigene robots.txt braucht.

Das Protokoll geht auf einen Vorschlag von Martijn Koster aus dem Jahr 1994 zurück. RFC 9309 ergänzte es im September 2022 unter anderem um Regeln für Fehler und Caching. Die Befolgung bleibt freiwillig, technisch verhindert die Datei keinen Zugriff. Die Crawler großer Suchmaschinen wie der Googlebot halten sich an die Regeln, manche andere Bots ignorieren sie. Damit Crawler die Datei lesen können, muss sie öffentlich abrufbar sein. Deshalb lässt sie sich auch im Browser über die Domain mit angehängtem /robots.txt aufrufen.

Braucht jede Website eine robots.txt?

Nein, eine Website kommt ohne robots.txt aus, denn ohne Datei dürfen Crawler alle öffentlichen Seiten abrufen. Google behandelt eine fehlende Datei mit dem Statuscode 404 so, als gäbe es keine Einschränkungen. Sinnvoll ist eine robots.txt, wenn eine Website Bereiche ohne Suchwert hat oder ihr Betreiber einzelne Crawler anders behandeln will.

• Bereiche ohne Suchwert. Interne Suchergebnisse und URLs mit Session-Parametern erzeugen viele Adressen ohne eigenen Inhalt, Antragsstrecken haben keinen Suchwert. Google nennt das Vermeiden unwichtiger oder ähnlicher Seiten als typischen Einsatz. Auf sehr großen Websites schont das zudem das Crawl-Budget.
• Serverlast. Laut Google dient die Datei vor allem dazu, eine Überlastung der Website durch Anfragen von Crawlern zu vermeiden.
• KI-Crawler. Die Datei legt fest, welche KI-Crawler Inhalte für Training oder Suche abrufen dürfen. Für Abrufe auf Nutzerfrage gelten die Regeln nicht bei jedem Anbieter.

Für die SEO zählt die robots.txt, weil sie festlegt, welche Inhalte Suchmaschinen überhaupt lesen können. Eine einzige falsche Zeile kann wichtige Seiten oder die CSS- und JavaScript-Dateien, die Google zum Darstellen braucht, vom Crawling ausschließen. Eine robots.txt ohne Sperren schadet deshalb nicht, eine zu weit gefasste Sperre schon.

Aufbau und Syntax der robots.txt

Eine robots.txt besteht aus Gruppen, die mit einer oder mehreren Zeilen User-agent beginnen und darunter Regeln mit Disallow oder Allow enthalten. Jede Zeile folgt dem Muster Feld, Doppelpunkt, Wert, und Kommentare beginnen mit #. Google wertet vier Felder aus.

• User-agent nennt den Crawler über sein Token, etwa Googlebot. Das Token entspricht meist der Kennung, die ein Crawler als User-Agent mitsendet. Der Stern * steht für alle Crawler ohne eigene Gruppe.
• Disallow verbietet einen Pfad, Allow erlaubt ihn. Ein Pfad beginnt mit / und gilt für alle URLs, die mit ihm beginnen.
• Sitemap nennt die vollständige Adresse einer Sitemap. Die Zeile gilt unabhängig von den Gruppen und darf mehrfach vorkommen.

Ein Crawler befolgt nur eine Gruppe, nämlich die, deren User-agent am besten zu ihm passt. Gibt es eine eigene Gruppe für den Googlebot, ignoriert er die Gruppe * vollständig, Regeln für alle müssen dort also wiederholt werden. Innerhalb der Gruppe gewinnt die spezifischste Regel, also die mit dem längsten Pfad. Sind eine Allow- und eine Disallow-Regel gleich spezifisch, wendet Google die weniger restriktive an. Bei Feldnamen spielt die Groß- und Kleinschreibung keine Rolle, bei Pfaden schon, /Konto/ ist nicht /konto/.

Google, Bing und andere große Suchmaschinen unterstützen zwei Platzhalter. Der Stern * steht für beliebig viele Zeichen, das Dollarzeichen $ für das Ende der URL. Die Tabelle zeigt nach dem Muster der Google-Dokumentation, welche Pfade eine Regel trifft. Die Datei muss UTF-8-codiert sein. Google liest höchstens 500 Kibibyte (512.000 Byte) und ignoriert alles, was danach folgt.

Disallow: Bereiche für Crawler sperren

Disallow verbietet den Crawlern einer Gruppe den Abruf aller URLs, deren Pfad mit dem angegebenen Wert beginnt. Wie weit die Sperre reicht, hängt allein von diesem Wert ab.

• Ganze Website. Disallow: / sperrt alles, im Englischen oft „disallow all“ genannt. Unter User-agent: * gilt das für alle Crawler, die sich an die Regeln halten, außer den AdsBot-Crawlern von Google, die namentlich genannt werden müssen.
• Nichts. Disallow: ohne Wert erlaubt alles und wirkt wie eine fehlende robots.txt.
• Verzeichnis. Disallow: /antrag/ sperrt das Verzeichnis mit allen Unterseiten, der Schrägstrich am Ende gehört dazu.
• Datei. Disallow: /preisaushang.pdf sperrt eine einzelne Datei.
• Parameter. Disallow: /*sessionid= sperrt jede URL, die diesen Parameter enthält.

Manche älteren Dateien enthalten noch Disallow: /cgi-bin/. Die Zeile steht schon in den Beispielen auf robotstxt.org, der langjährigen Informationsseite zum Protokoll, und sperrt das klassische Verzeichnis für Serverskripte. Nötig ist sie nur, wenn es dieses Verzeichnis gibt. Eine fehlerhafte Sperre kann mehr schaden als eine fehlende Datei, denn ohne Datei bleibt alles crawlbar. Drei Fehler wiegen besonders schwer.

• Komplettsperre im Livebetrieb. Ein Disallow: /, etwa aus einer Testumgebung übernommen, sperrt auf der Live-Website alle Seiten. Im Bing Webmaster Blog berichtete ein Mitarbeiter 2012 von 22 Start-ups, von denen die Hälfte über fehlende Indexierung klagte, und genau diese Hälfte sperrte so die ganze Website.
• Gesperrte Ressourcen. Sperrt die Datei CSS- oder JavaScript-Dateien, kann Google Seiten nur unvollständig darstellen und schlechter verstehen.
• Gesperrtes Favicon. Google zeigt ein Favicon in den Suchergebnissen nur, wenn Googlebot-Image die Bilddatei und der Googlebot die Startseite crawlen dürfen.

robots.txt-Beispiel einer fiktiven Bank

Das Beispiel zeigt eine vollständige robots.txt für die Website einer fiktiven Bank unter www.example.com. Sie nimmt die interne Suche, Session-Parameter und die Antragsstrecke aus dem Crawling, lässt eine Checkliste im gesperrten Verzeichnis zu und schließt zwei Crawler aus, die Inhalte für das Training von KI-Modellen sammeln.

# Fiktive Bank, Stand 10/20261
User-agent: *2
Disallow: /suche3
Disallow: /*sessionid=4
Disallow: /antrag/
Allow: /antrag/checkliste5
Disallow: /*.csv$6

User-agent: GPTBot7
User-agent: ClaudeBot
Disallow: /

Sitemap: https://www.example.com/sitemap.xml8

Such-Crawler wie OAI-SearchBot, Claude-SearchBot und PerplexityBot haben in diesem Beispiel keine eigene Gruppe. Sie folgen deshalb der Gruppe * und dürfen alles abrufen, was dort nicht gesperrt ist. Ob eine Bank Trainings-Crawler ausschließt, ist eine geschäftliche Abwägung, das Beispiel zeigt nur die Technik.

Regeln für einzelne Crawler

Ein Crawler bekommt eigene Regeln, sobald die robots.txt eine Gruppe mit seinem Token enthält, ohne eigene Gruppe folgt er der Gruppe *. Welche Tokens es gibt und was ein Crawler mit den Inhalten macht, beschreibt sein Betreiber.

Regeln für Googlebot und andere Google-Crawler

Regeln unter User-agent: Googlebot wirken auf die Google-Suche mit Discover und allen Suchfunktionen sowie auf Google Bilder, Video und News. Für Bilder, Logos und Favicons ist zusätzlich Googlebot-Image zuständig. Soll nur der Googlebot ein Verzeichnis nicht abrufen, steht Disallow: /intern/ in einer eigenen Googlebot-Gruppe, die alle Regeln aus der Gruppe * wiederholt, weil der Googlebot diese dann nicht mehr befolgt.

Google-Extended ist kein eigener Crawler, sondern nur ein Token in der robots.txt, abgerufen wird mit den bestehenden Google-Crawlern. Eine Sperre bewirkt laut Google, dass Inhalte nicht für das Training künftiger Gemini-Modelle und nicht für die Fundierung (Grounding) in Gemini-Apps und Vertex AI genutzt werden. Auf die Aufnahme in die Google-Suche und das Ranking hat sie keinen Einfluss.

Für die KI-Funktionen der Google-Suche wie AI Overviews und AI Mode gelten die Regeln für den Googlebot und Snippet-Angaben wie nosnippet. Seit dem 31.08.2026 lässt sich jede Website zudem über die Search-Console-Einstellung „Generative KI in der Google Suche“ aus AI Overviews, AI Mode und den KI-Funktionen in Discover ausschließen. Auf Ranking und Aufnahme in der übrigen Suche wirkt sich das laut Google nicht aus.

KI-Crawler zulassen oder sperren

OpenAI, Anthropic und Perplexity trennen ihre Bots nach Zweck. Training und Suche lassen sich so einzeln zulassen oder sperren, wobei Perplexity seine Bots laut eigener Angabe nicht für Training nutzt. Abrufe auf Nutzerfrage lassen sich laut Dokumentation der Anbieter verlässlich nur bei Anthropic sperren. Die Folgen einer Sperre beschreiben die Anbieter selbst.

Wer einen Such-Crawler sperrt, verliert Sichtbarkeit in den Antworten des jeweiligen Anbieters. Laut OpenAI erscheinen Websites, die OAI-SearchBot ausschließen, nicht in den Antworten der ChatGPT-Suche. Aus Sicht von KKP sollten Such-Crawler und Abrufe auf Nutzerfrage deshalb offen bleiben. Über Trainings-Crawler lässt sich getrennt entscheiden, denn eine Sperre von GPTBot oder ClaudeBot betrifft laut OpenAI und Anthropic nur das Training und nicht die Suche des Anbieters. Änderungen übernehmen OpenAI und Perplexity nach eigener Angabe innerhalb von rund 24 Stunden.

Für ChatGPT-User gelten die Regeln laut OpenAI womöglich nicht, Perplexity-User ignoriert sie laut Perplexity in der Regel. Bots, die die Datei missachten, lassen sich nur auf dem Server aussperren, etwa über die .htaccess. Anthropic weist darauf hin, dass eine Sperre seiner IP-Adressen das Opt-out nicht zuverlässig sichert, weil sie auch den Abruf der robots.txt verhindert. Eine llms.txt ersetzt die robots.txt nicht, denn sie steuert keine Crawler.

Wie oft KI-Crawler die Datei abfragen, zeigt eine KKP-Messung auf kkp.agency. Vom 23.07. bis 05.08.2026 galten 363 von 2.216 Abrufen durch KI-Bots der robots.txt, also 16,4 Prozent, keine andere Adresse der Domain wurde häufiger abgerufen. Am häufigsten fragte ClaudeBot die Datei ab (162-mal), gefolgt von OAI-SearchBot (57) und PerplexityBot (48).

robots.txt erstellen und testen

Eine robots.txt lässt sich mit einem einfachen Texteditor erstellen, als Nur-Text-Datei in UTF-8 mit dem Namen robots.txt, die ins Stammverzeichnis des Hosts hochgeladen wird. Textverarbeitungen eignen sich laut Google nicht, weil sie Zeichen wie typografische Anführungszeichen einfügen können. Je Host gibt es höchstens eine Datei.

Content-Management-Systeme nehmen die Arbeit teils ab. WordPress erzeugt eine virtuelle robots.txt, solange keine eigene Datei im Stammverzeichnis liegt. Sie sperrt nur den Verwaltungsbereich mit Disallow: /wp-admin/, erlaubt /wp-admin/admin-ajax.php und verweist seit Version 5.5 auf die Sitemap. Die Einstellung, Suchmaschinen von der Indexierung abzuhalten, schreibt seit Version 5.3 kein Disallow: / mehr in die Datei, sondern setzt ein Robots-Meta-Tag. Bei Anbietern wie Wix ersetzen oft Sucheinstellungen den direkten Zugriff auf die Datei.

Ob die Datei öffentlich erreichbar ist, zeigt ein Aufruf in einem privaten Browserfenster. Für eigene Websites listet der robots.txt-Bericht der Search Console seit November 2023 die Dateien der 20 wichtigsten Hosts mit dem Zeitpunkt des letzten Abrufs sowie Warnungen und Fehlern beim Lesen. Er ersetzt den früheren robots.txt-Tester und steht nur für Properties auf Domainebene bereit. Ob eine einzelne URL gesperrt ist, prüft das URL-Prüftool. Google speichert die Datei bis zu 24 Stunden zwischen, nach einer Änderung lässt sich im Bericht ein erneutes Crawling beantragen.

Best Practices für die robots.txt

Eine gute robots.txt ist kurz, sperrt nur Bereiche ohne Suchwert und lässt alles offen, was Suchmaschinen zum Darstellen der Seiten brauchen. Sechs Regeln helfen, die Datei zu optimieren, ohne Rankings zu gefährden.

Wie Google auf den Statuscode der robots.txt reagiert

Ob Google die Regeln anwendet, hängt vom HTTP-Statuscode ab, mit dem der Server die robots.txt ausliefert. Am riskantesten sind Serverfehler, denn dann stoppt Google das Crawling der ganzen Website vorübergehend.

Für die Praxis zählt vor allem der Unterschied zwischen 4xx und 5xx. Antwortet die robots.txt mit 403 oder 404, crawlt Google ohne jede Einschränkung, ein Passwortschutz auf der Datei hebt also alle Regeln auf. Bleiben die Serverfehler länger als 30 Tage bestehen, verhält sich Google wie ohne robots.txt, solange die Website sonst erreichbar ist. RFC 9309 schreibt für unerreichbare Dateien vor, dass Crawler zunächst von einer vollständigen Sperre ausgehen. Gespeichert wird die Datei bei Google normalerweise bis zu 24 Stunden, die Angabe max-age im HTTP-Header Cache-Control kann diese Dauer ändern.

Was die robots.txt nicht kann

Die robots.txt verhindert nur den Abruf durch Crawler, die sich an sie halten, sie ist weder Indexierungssperre noch Zugriffsschutz und kein Mittel zur Kanonisierung.

• Keine Indexierungssperre. Google kann eine gesperrte URL ohne Seitenaufruf indexieren, wenn andere Seiten mit beschreibendem Text auf sie verweisen, im Suchergebnis fehlt dann die Beschreibung. Zuverlässig aus dem Index hält eine Seite ein Noindex, das Google aber nur liest, wenn die robots.txt die Seite nicht sperrt.
• Kein Zugriffsschutz. Laut RFC 9309 sind die Regeln keine Zugangsberechtigung. Wer Pfade in die öffentliche Datei schreibt, macht sie sogar auffindbar. Vertrauliche Bereiche schützt nur eine Anmeldung auf dem Server, etwa ein Passwortschutz.
• Keine Kanonisierung. Google rät davon ab, die robots.txt zur Kanonisierung zu verwenden, weil gesperrte URLs ohne Inhalt im Index landen können. Die bevorzugte URL legt ein Canonical-Tag oder eine Weiterleitung fest.

crawl-delay und andere nicht unterstützte Regeln

Google wertet in der robots.txt nur User-agent, Allow, Disallow und Sitemap aus. Die Angabe crawl-delay, mit der ein Crawler zwischen zwei Abrufen warten soll, unterstützt Google nicht. Die Verarbeitung von noindex und anderen nie dokumentierten Regeln wie nofollow stellte Google am 01.09.2019 ein. Andere Betreiber handhaben crawl-delay anders. Bing beachtet die Angabe laut einem Beitrag aus dem Jahr 2012 als Zeitfenster von 1 bis 30 Sekunden, in dem der Crawler höchstens eine Seite abruft. Anthropic unterstützt sie nach eigener Dokumentation ebenfalls.

„Durch robots.txt-Datei blockiert“: Status in der Search Console

Der Status „Durch robots.txt-Datei blockiert“ im Bericht zur Seitenindexierung der Google Search Console bedeutet, dass eine Regel in der robots.txt dem Googlebot den Abruf der URL verbietet. Oft ist das gewollt, etwa bei der internen Suche. Steht dort eine Seite, die gefunden werden soll, wird die Regel entfernt und im robots.txt-Bericht ein erneutes Crawling der Datei beantragt. Ob eine einzelne URL betroffen ist, zeigt das URL-Prüftool.

„Indexiert, obwohl durch robots.txt-Datei blockiert“ heißt, dass Google die URL in den Index aufgenommen hat, ohne sie abzurufen. Die Informationen stammen dann von Seiten, die auf die gesperrte URL verlinken, und das Snippet im Suchergebnis ist stark eingeschränkt. Soll die Seite nicht in der Google-Suche erscheinen, empfiehlt Google, die Sperre in der robots.txt aufzuheben und die Seite mit Noindex zu kennzeichnen. Soll sie gefunden werden, genügt es, die Sperre aufzuheben.

Gratis Download

AI Search Guide: Sichtbar in ChatGPT & Co.

Der Praxis-Guide zeigt auf 164 Seiten, wie eine Brand in ChatGPT, Google AI Overviews, Gemini und Perplexity sichtbar wird, von den Grundlagen über Messung und KPIs bis zu konkreten Maßnahmen.

Kostenlos herunterladen →