Syntax, Regeln und typische Fehler der robots.txt

Was ist die robots.txt?

Die robots.txt ist eine Textdatei im obersten Verzeichnis einer Website. Sie sagt Crawlern, welche URLs sie abrufen dürfen. Google nennt als Hauptzweck, die Website vor zu vielen Anfragen zu schützen. In der Praxis hält sie Crawler außerdem aus Bereichen fern, die in der Suche nichts bringen, etwa Warenkorb oder interne Suche.

Die Regeln folgen dem Robots Exclusion Protocol. Martijn Koster hat es 1994 entworfen. Seit September 2022 beschreibt es der RFC 9309 der IETF. Google richtet sich danach und ergänzt in der eigenen Doku Details, zum Beispiel den Umgang mit Serverfehlern.

Eine kurze Datei sieht so aus.

Steuert die robots.txt das Crawling oder die Indexierung?

Die Datei steuert das Crawling, also den Abruf. Die Indexierung ist ein eigener Schritt. Eine gesperrte URL kann trotzdem im Google-Index landen, wenn andere Seiten darauf verlinken. Das Ergebnis erscheint dann ohne Beschreibung. Mehr dazu steht im Ratgeber Google Indexierung.

Für noindex gilt die umgekehrte Logik. Google muss die Seite abrufen, um die Anweisung zu sehen. Sperrst du eine Seite per robots.txt und setzt zusätzlich noindex, bleibt die Anweisung unsichtbar. Je nach Ziel brauchst du deshalb ein anderes Mittel.

Wie ist die robots.txt aufgebaut?

Jede Zeile enthält ein Feld, einen Doppelpunkt und einen Wert. Google wertet vier Felder aus.

Bei den Feldnamen spielt die Groß- und Kleinschreibung keine Rolle, bei den Pfaden schon. Pfade beginnen mit einem Schrägstrich, Kommentare mit #. Felder wie crawl-delay und noindex wertet Google in der robots.txt nicht aus, ungültige Zeilen ignoriert Google.

Platzhalter * und $

Der Stern steht für beliebig viele Zeichen, auch für keines. Das Dollarzeichen markiert das Ende der URL. Beide Zeichen sind Teil von RFC 9309. Jede Regel wirkt vom Anfang des Pfads aus und trifft alles, was so beginnt. Die Beispiele zeigen, was das bedeutet.

Die letzte Zeile ist eine typische Falle. Steht ein Parameter nicht an erster Stelle, greift die Regel nicht. Mit /*sort= triffst du beide Fälle.

Welchen Regeln folgt ein Crawler?

Eine Gruppe beginnt mit einer oder mehreren User-agent-Zeilen, darunter stehen die Regeln. Ein Crawler sucht die Gruppe mit seinem Token, die Groß- und Kleinschreibung ist dabei egal. Gibt es keine, gilt die Gruppe mit dem Stern. Fehlt auch die, darf er alles abrufen. Stehen mehrere Gruppen für denselben Crawler in der Datei, führt er sie zusammen. Ihre Reihenfolge spielt keine Rolle.

Eine eigene Gruppe ersetzt die Stern-Gruppe vollständig.

In diesem Beispiel folgt Googlebot nur seiner eigenen Gruppe. Er darf /warenkorb/ und /konto/ abrufen, gesperrt ist für ihn nur /intern/. Sollen die allgemeinen Sperren auch für ihn gelten, müssen sie in seiner Gruppe stehen. Dasselbe gilt für jeden KI-Crawler mit eigener Gruppe. Google nennt außerdem eine Ausnahme. AdsBot fällt nicht unter den Stern und muss namentlich genannt werden.

Welche Regel gewinnt?

Innerhalb einer Gruppe ist die Reihenfolge der Zeilen egal. Es gewinnt die Regel mit dem längsten passenden Pfad. Sind eine Allow- und eine Disallow-Regel gleich lang, gilt Allow. Trifft keine Regel, ist die URL erlaubt. Die Datei /robots.txt selbst ist immer abrufbar.

Wo liegt die Datei und wie groß darf sie sein?

• Ort. Crawler lesen nur /robots.txt im obersten Verzeichnis. Unterordner prüfen sie nicht, und der Dateiname ist klein geschrieben.
• Geltungsbereich. Die Regeln gelten für genau einen Host, ein Protokoll und einen Port. Die Datei auf https://www.example.com gilt weder für https://example.com noch für https://shop.example.com oder http://www.example.com. Jede Subdomain braucht ihre eigene Datei.
• Größe. Laut RFC 9309 müssen Crawler mindestens 500 KiB verarbeiten. Google liest die ersten 500 KiB und ignoriert den Rest.
• Format. Die Datei ist reiner Text in UTF-8. Ein BOM ignoriert Google, Zeichen außerhalb von UTF-8 können Regeln ungültig machen.
• Cache. Crawler sollen die Datei laut RFC 9309 höchstens 24 Stunden cachen. Google hält sich in der Regel daran. Der Cache-Control-Wert max-age kann die Dauer ändern, und bei Timeouts oder Serverfehlern bleibt die Kopie länger im Einsatz.

Welche Statuscodes gelten für die robots.txt?

Der Statuscode von /robots.txt entscheidet, ob ein Crawler überhaupt loslegt. RFC 9309 gibt den Rahmen vor, Google beschreibt sein Verhalten genauer.

Ein 404 ist also harmlos, ein 503 auf der robots.txt dagegen nicht. Wer die Datei über ein CDN oder eine Firewall ausliefert, sollte auch diese Antwort im Blick behalten. Um Crawler zu bremsen, helfen 401 oder 403 übrigens nicht, denn Google wertet beide Codes wie eine fehlende Datei.

Wie hängen robots.txt und Sitemap zusammen?

Die robots.txt darf auf Sitemaps verweisen. Die Zeile steht unabhängig von den Gruppen und gilt damit für alle Crawler. Sie enthält eine absolute URL, mehrere Zeilen sind erlaubt, und die Sitemap darf auf einem anderen Host liegen.

Ein Eintrag in der Sitemap hebt keine Sperre auf. Steht eine URL in der Sitemap und ist per Disallow gesperrt, bleibt sie für den Crawler gesperrt. Aufbau und Limits erklärt der Ratgeber XML-Sitemap.

robots.txt für KI-Crawler

KI-Crawler lesen dieselbe Datei wie Suchmaschinen und folgen denselben Gruppen. Wichtig ist, dass die Betreiber je Zweck eigene Tokens anbieten. GPTBot sammelt bei OpenAI Inhalte, die fürs Training genutzt werden können. OAI-SearchBot sorgt dafür, dass Seiten in der Suche von ChatGPT erscheinen. Beide Einstellungen sind laut OpenAI unabhängig voneinander. Bei Anthropic ist ClaudeBot fürs Training zuständig und Claude-SearchBot für die Suche.

Abrufe auf Nutzerwunsch laufen anders. ChatGPT-User, Perplexity-User und meta-externalfetcher halten sich laut Betreiber nicht verlässlich an die robots.txt, weil ein Mensch den Abruf auslöst. Claude-User folgt ihr laut Anthropic.

Alle Bots, ihre Zwecke und was eine Sperre jeweils bewirkt, stehen im Ratgeber KI-Crawler und in der KI-Bot-Liste. Wie du das im Alltag steuerst, zeigt der Use Case KI-Bots steuern.

Beispiele für typische Fälle

Die ersten drei Beispiele decken die Grundfälle ab. Das erste entspricht einer fehlenden Datei und ist nur der Vollständigkeit halber dabei.

Jeder Block steht für eine eigene Datei. Ein Shop könnte seine Datei so aufbauen.

Häufige Fehler

• Die Sperre der Testumgebung geht live. Ein Disallow: / rutscht beim Release auf die Produktivseite. Wie du das vermeidest, steht im Ratgeber Staging-Umgebung.
• Disallow statt noindex. Die Seite bleibt im Index, und Google kann ein noindex auf ihr nicht mehr lesen.
• CSS oder JavaScript gesperrt. Unwichtige Ressourcen darfst du sperren. Braucht Google die Dateien, um die Seite zu verstehen, müssen sie abrufbar bleiben.
• Allgemeine Regeln fehlen in der Bot-Gruppe. Mit einer eigenen Gruppe gelten die Sperren aus der Stern-Gruppe für diesen Bot nicht mehr.
• Datei auf dem falschen Host. Nach einem Umzug oder bei einer neuen Subdomain fehlt die Datei dort, wo sie gelten soll.
• Serverfehler auf /robots.txt. Ein 503 stoppt das Crawling der ganzen Website, auch wenn alle anderen URLs laufen.
• HTML statt Text. Liefert /robots.txt eine HTML-Seite mit Status 200, sind die Zeilen ungültig. Google ignoriert sie, und es gilt keine einzige Regel.
• Falsche Schreibweise. Disallow: /Shop/ sperrt /shop/ nicht.
• Vertrauliche Pfade eingetragen. Die Datei ist öffentlich, ein Eintrag zeigt den Pfad jedem, der nachsieht.

robots.txt testen und überwachen

Der robots.txt-Bericht der Search Console zeigt, welche Dateien Google gefunden hat, wann der letzte Abruf war und welche Fehler Google beim Lesen gefunden hat. Er deckt die 20 Hosts mit der höchsten Crawl-Rate einer Domain-Property ab und zeigt die Abrufe der letzten 30 Tage. Nach einer dringenden Änderung forderst du dort einen neuen Abruf an.

Einzelne URLs testest du im kostenlosen robots.txt Tester, auch für GPTBot, ClaudeBot und weitere Bots. Entwickler können außerdem Googles Open-Source-Bibliothek lokal nutzen. Weil ein Release die Datei jederzeit ändern kann, lohnt sich zusätzlich ein laufendes robots.txt Monitoring.

Häufige Fragen