Robots.txt-Spezifikationen

Zusammenfassung

In diesem Dokument wird beschrieben, wie Google die robots.txt-Datei handhabt. Mit dieser Datei steuern Website-Inhaber, wie die Website-Crawler von Google öffentlich zugängliche Websites crawlen und indexieren.

Was hat sich geändert?

Am 1. Juli 2019 hat Google bekannt gegeben, dass das robots.txt-Protokoll zum Internetstandard werden soll. Dieses Dokument wurde dementsprechend aktualisiert.

Grundlegende Definitionen

Definitionen
Crawler Ein Crawler ist ein Dienst oder Agent, der Websites "crawlt", also durchsucht. Allgemein ausgedrückt, greift ein Crawler automatisch und rekursiv auf bekannte URLs eines Hosts zu. Dabei werden Inhalte ermittelt, die mit standardmäßigen Webbrowsern aufgerufen werden können. Stößt der Crawler auf neue URLs, beispielsweise über Links auf bereits vorhandenen und gecrawlten Seiten oder über XML-Sitemap-Dateien, werden diese auf die gleiche Weise gecrawlt.
User-Agent Mittel zur Angabe eines bestimmten Crawlers oder einer Gruppe von Crawlern.
Anweisungen Die Liste der in der robots.txt-Datei angegebenen Richtlinien, die für einen Crawler oder eine Gruppe von Crawlern gelten.
URL Uniform Resource Locators gemäß Definition in RFC 1738.
Google-spezifisch Richtlinien, die im Folgenden als "Google-spezifisch" bezeichnet werden, beziehen sich speziell auf die Implementierung der robots.txt durch Google und sind für Dritte unter Umständen nicht relevant.

Geltungsbereich

Die in diesem Dokument beschriebenen Richtlinien werden von allen automatisierten Crawlern von Google befolgt. Falls ein Agent im Auftrag eines Nutzers auf URLs zugreift, beispielsweise zur Übersetzung, bei manuell abonnierten Feeds oder für die Malwareanalyse, gelten diese Richtlinien nicht in jedem Fall.

Dateispeicherort und Gültigkeitsbereich

Die robots.txt-Datei muss sich im obersten Verzeichnis des Hosts befinden und über das entsprechende Protokoll und die entsprechende Portnummer zugänglich sein. Allgemein akzeptierte Protokolle für robots.txt-Dateien basieren auf URIs und sind, speziell für die Google-Suche (z. B. das Crawlen von Websites), "HTTP" und "HTTPS". Unter HTTP und HTTPS wird die robots.txt-Datei mit einer nicht konditionalen HTTP-GET-Anforderung abgerufen.

Google-spezifisch: Google akzeptiert und folgt robots.txt-Dateien auch bei FTP-Websites. Auf FTP basierende robots.txt-Dateien werden mithilfe anonymer Anmeldeinformationen über das FTP-Protokoll aufgerufen.

Die in der robots.txt-Datei enthaltenen Anweisungen gelten nur für den Host, auf dem sich die Datei befindet, das zugehörige Protokoll und die entsprechende Portnummer.

Beispiele für gültige robots.txt-URLs

Beispiele für robots.txt-URLs
http://example.com/robots.txt Gültig für:
  • http://example.com/
  • http://example.com/folder/file
Nicht gültig für:
  • http://other.example.com/
  • https://example.com/
  • http://example.com:8181/
http://www.example.com/robots.txt

Gültig für: http://www.example.com/

Nicht gültig für:

  • http://example.com/
  • http://shop.www.example.com/
  • http://www.shop.example.com/
http://example.com/folder/robots.txt Dies ist keine gültige robots.txt-Datei. Crawler suchen in diesem Fall nicht in Unterverzeichnissen nach robots.txt-Dateien.
http://www.müller.eu/robots.txt Gültig für:
  • http://www.müller.eu/
  • http://www.xn--mller-kva.eu/

Nicht gültig für: http://www.muller.eu/

ftp://example.com/robots.txt

Gültig für: ftp://example.com/

Nicht gültig für: http://example.com/

Google-spezifisch: Wir verwenden robots.txt-Dateien für FTP-Ressourcen.

http://212.96.82.21/robots.txt

Gültig für: http://212.96.82.21/

Nicht gültig für: http://example.com/ (auch wenn unter 212.96.82.21 gehostet)

http://example.com:80/robots.txt

Gültig für:

  • http://example.com:80/
  • http://example.com/

Nicht gültig für: http://example.com:81/

http://example.com:8181/robots.txt

Gültig für: http://example.com:8181/

Nicht gültig für: http://example.com/

Behandlung von HTTP-Ergebniscodes

Das Abrufen von robots.txt-Dateien kann generell zu drei verschiedenen Ergebnissen in Bezug auf die Crawling-Erlaubnis führen, die vom HTTP-Ergebniscode abhängen:

  • full allow: Alle Inhalte dürfen gecrawlt werden.
  • full disallow: Es dürfen keine Inhalte gecrawlt werden.
  • conditional allow: Welche Inhalte gecrawlt werden dürfen, wird durch die Anweisungen in der robots.txt-Datei vorgegeben.
Behandlung von HTTP-Ergebniscodes
2xx (erfolgreich) HTTP-Ergebniscodes, die einen erfolgreichen Vorgang signalisieren, führen zu einem "conditional allow" für das Crawling.
3xx (Weiterleitung) Google folgt mindestens fünf Weiterleitungssprüngen, wie in RFC 1945 für HTTP/1.0 definiert, beendet dann den Vorgang und geht von einem 404-Fehler aus. Von robots.txt-Weiterleitungen an nicht zugelassene URLs wird abgeraten. Da noch keine Regeln abgerufen wurden, werden die Weiterleitungen für mindestens fünf Sprünge befolgt. Wenn keine robots.txt-Datei gefunden wird, geht Google von einem 404-Fehler aus. Die Behandlung logischer Weiterleitungen der robots.txt-Datei auf der Grundlage von HTML-Inhalten, die 2xx-Ergebniscodes zurückgeben (Frame-, JavaScript- oder Meta-Refresh-Weiterleitungen), wird nicht empfohlen. Der Inhalt der ersten Seite wird zur Suche nach anwendbaren Regeln verwendet.
4xx (Clientfehler) Alle 4xx-Fehler werden gleich behandelt und es wird davon ausgegangen, dass keine gültige robots.txt-Datei vorhanden ist. Es wird angenommen, dass keine Einschränkungen gelten. Dies entspricht einem "full allow" für das Crawling.
5xx (Serverfehler)

Serverfehler werden als temporäre Fehler interpretiert, die zu einem "full disallow" des Crawlings führen. Die Anforderung wird wiederholt, bis ein anderer HTTP-Ergebniscode als ein Serverfehler zurückgegeben wird. Der Fehler 503 (Service Unavailable) hat relativ häufige Wiederholungsversuche zur Folge. Wenn die robots.txt-Datei länger als 30 Tage nicht erreichbar ist, wird die letzte im Cache gespeicherte Kopie der robots.txt-Datei verwendet. Falls nicht verfügbar, geht Google davon aus, dass es keine Crawling-Einschränkungen gibt. Es wird daher empfohlen, den HTTP-Ergebniscode 503 zurückzugeben, um das Crawling vorübergehend auszusetzen.

Google-spezifisch: Sollten wir feststellen, dass eine Website aufgrund fehlerhafter Konfiguration einen 5xx-Fehler statt des Fehlers 404 für fehlende Seiten zurückgibt, behandeln wir einen 5xx-Fehler von dieser Website als 404-Fehler.

Fehlgeschlagene Anforderungen oder unvollständige Daten Die Behandlung einer robots.txt-Datei, die aufgrund von DNS- oder Netzwerkproblemen – z. B. Zeitüberschreitungen, ungültigen Antworten, zurückgesetzten oder unterbrochenen Verbindungen und HTTP-Chunking-Fehlern – nicht abgerufen werden kann, wird als Serverfehler eingestuft.
Caching robots.txt-Inhalte werden normalerweise bis zu 24 Stunden lang im Cache gespeichert. Sollte die Aktualisierung der im Cache gespeicherten Version jedoch nicht möglich sein, beispielsweise aufgrund einer Zeitüberschreitung oder eines 5xx-Fehlers, können die Anforderungen auch länger im Cache verbleiben. Die Antwort im Cache kann gleichzeitig für verschiedene Crawler gelten. Google kann die Verbleibedauer im Cache entsprechend der Anweisung "max-age" im HTTP-Headerfeld "Cache-Control" erhöhen oder verringern.

Dateiformat

Das erwartete Dateiformat ist ein in UTF-8 codiertes Nur-Text-Format. Die Datei besteht aus Zeilen, die durch Zeilenumbrüche (CR), durch Zeilenumbrüche und Zeilenvorschübe (CR/LF) oder durch Zeilenvorschübe (LF) getrennt sind.

Es werden nur gültige Zeilen berücksichtigt, alle anderen Inhalte werden ignoriert. Handelt es sich beim resultierenden Dokument beispielsweise um eine HTML-Seite, werden nur gültige Textzeilen berücksichtigt. Der Rest wird ohne Warnung oder Fehlermeldung verworfen.

Wird eine Zeichencodierung verwendet, die dazu führt, dass nicht zu einer Untergruppe von UTF-8 gehörende Zeichen verwendet werden, wird der Inhalt der Datei möglicherweise nicht korrekt geparst.

Eine optionale Unicode-Byte Order Mark (BOM) am Anfang der robots.txt-Datei wird ignoriert.

Jede gültige Zeile besteht aus einem Feld, einem Doppelpunkt und einem Wert. Leerzeichen sind optional, werden zwecks verbesserter Lesbarkeit jedoch empfohlen. Kommentare können an jeder beliebigen Stelle der Datei mithilfe des Zeichens "#" eingefügt werden. Jeglicher Inhalt vom Beginn eines Kommentars bis zum Ende der Zeile wird als Kommentar behandelt und ignoriert. Das allgemeine Format ist <field>:<value><#optional-comment>. Leerzeichen am Anfang und Ende der Zeile werden ignoriert.

Im <field>-Element wird nicht zwischen Groß- und Kleinschreibung unterschieden. Ob beim <value>-Element zwischen Groß- und Kleinschreibung unterschieden wird, hängt vom <field>-Element ab.

Die Behandlung von <field>-Elementen mit einfachen Fehlern oder Tippfehlern (z. B. "useragent" statt "user-agent") wird nicht unterstützt.

Unter Umständen wird eine maximale Dateigröße pro Crawler erzwungen. Inhalte jenseits der maximalen Dateigröße werden ignoriert. Google erzwingt derzeit eine Höchstgrenze von 500 Kibibyte (KiB). Wenn Sie die Größe der robots.txt-Datei verringern möchten, fassen Sie Anweisungen zusammen, die sonst zu einer übergroßen robots.txt-Datei führen. Platzieren Sie beispielsweise ausgeschlossenes Material in einem separaten Verzeichnis.

Formale Syntax und Definition

Nachfolgend finden Sie die Beschreibung der angereicherten Backus-Naur-Form (nach RFC 5234):

robotstxt = *(group / emptyline)
group = startgroupline                    ; We start with a user-agent
        *(startgroupline / emptyline)     ; ... and possibly more user-agents
        *(rule / emptyline)               ; followed by rules relevant for UAs

startgroupline = *WS "user-agent" *WS ":" *WS product-token EOL

rule = *WS ("allow" / "disallow") *WS ":" *WS (path-pattern / empty-pattern) EOL

; parser implementors: add additional lines you need (for example, Sitemaps), and
; be lenient when reading lines that don’t conform. Apply Postel’s law.

product-token = identifier / "*"
path-pattern = "/" *(UTF8-char-noctl)    ; valid URI path pattern; see 3.2.2
empty-pattern = *WS

identifier = 1*(%x2d / %x41-5a / %x5f / %x61-7a)
comment = "#" *(UTF8-char-noctl / WS / "#")
emptyline = EOL
EOL = *WS [comment] NL         ; end-of-line may have optional trailing comment
NL = %x0D / %x0A / %x0D.0A
WS = %x20 / %x09

; UTF8 derived from RFC3629, but excluding control characters
UTF8-char-noctl = UTF8-1-noctl / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-noctl    = %x21 / %x22 / %x24-7F  ; excluding control, space, '#'
UTF8-2          = %xC2-DF UTF8-tail
UTF8-3          = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
                  %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
UTF8-4          = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
                  %xF4 %x80-8F 2( UTF8-tail )
UTF8-tail       = %x80-BF

Gruppierung von Zeilen und Regeln

Eine Gruppe enthält mindestens eine User-Agent-Zeile, auf die mindestens eine Regel folgt. Diese Gruppe wird durch eine User-Agent-Zeile oder das Dateiende beendet. Die letzte Gruppe hat möglicherweise keine Regeln, was bedeutet, dass implizit alles erlaubt ist.

Beispielgruppen:

user-agent: a
disallow: /c

user-agent: b
disallow: /d

user-agent: e
user-agent: f
disallow: /g

user-agent: h

Es sind vier unterschiedliche Gruppen angegeben: eine für "a", eine für "b" und eine gemeinsame für "e" und "f". Mit Ausnahme der letzten Gruppe verfügt jede Gruppe über eine eigene group-member-Zeile. Die letzte Gruppe ist leer. Beachten Sie, dass zur Verbesserung der Lesbarkeit Leerzeichen und leere Zeilen eingefügt werden. Dies ist optional.

Reihenfolge der User-Agents

Für einen bestimmten Crawler gilt jeweils nur eine Gruppe. Der Crawler muss die richtige Zeilengruppe bestimmen, indem er die Gruppe mit der genauesten User-Agent-Angabe ermittelt, die noch eine Übereinstimmung ergibt. Alle anderen Gruppen werden vom Crawler ignoriert. Beim User-Agent wird zwischen Groß- und Kleinschreibung unterschieden. Jeder nicht übereinstimmende Text wird ignoriert. Zum Beispiel sind sowohl googlebot/1.2 als auch googlebot* gleichwertig mit googlebot. Die Reihenfolge der Gruppen innerhalb der robots.txt-Datei ist irrelevant.

Wenn es für einen bestimmten User-Agent mehr als eine Gruppe gibt, werden alle Regeln aus den Gruppen, die für einen bestimmten User-Agent gelten, kombiniert.

Beispiel

Angenommen, es liegt folgende robots.txt-Datei vor:

user-agent: googlebot-news
(group 1)

user-agent: *
(group 2)

user-agent: googlebot
(group 3)

Die relevante Gruppe wird von den einzelnen Crawlern so bestimmt:

Befolgte Gruppe pro Crawler
Googlebot-News Die befolgte Gruppe ist Gruppe 1. Nur der am genauesten angegebenen Gruppe wird gefolgt, alle anderen werden ignoriert.
Googlebot (Web) Die befolgte Gruppe ist Gruppe 3.
Googlebot für Bilder Die befolgte Gruppe ist Gruppe 3. Es gibt keine spezifische googlebot-images-Gruppe. Deshalb wird der allgemeineren Gruppe gefolgt.
Googlebot-News (beim Crawlen von Bildern) Die befolgte Gruppe ist Gruppe 1. Diese Bilder werden für und von Googlebot-News gecrawlt. Deshalb wird nur der Googlebot-News-Gruppe gefolgt.
Otherbot (Web) Die befolgte Gruppe ist Gruppe 2.
Otherbot (News) Die befolgte Gruppe ist Gruppe 2. Auch wenn ein Eintrag für einen ähnlichen Crawler besteht, gilt dieser nur bei genauer Übereinstimmung.

Weitere Informationen zu Crawlern von Google und User-Agent-Strings

group-member-Regeln

In diesem Abschnitt werden nur group-member-Standardregeln beschrieben. Diese Regeln werden bei Crawlern auch als "Anweisungen" bezeichnet. Die Anweisungen werden im Format directive: [path] angegeben, wobei [path] optional ist. Standardmäßig gibt es keine Beschränkungen für das Crawlen durch bestimmte Crawler. Anweisungen ohne [path] werden ignoriert.

Der Wert [path] wird, falls angegeben, als relativ zum Stammverzeichnis der Website betrachtet, für die die robots.txt-Datei abgerufen wurde. Dabei werden dasselbe Protokoll, dieselbe Portnummer, derselbe Host und dieselben Domainnamen verwendet. Der Pfadwert muss mit dem Zeichen "/" beginnen, das den Stamm kennzeichnet. Beim Pfad wird zwischen Groß- und Kleinschreibung unterschieden. Weitere Informationen dazu finden Sie unten im Abschnitt "Auf Pfadwerten basierende URL-Übereinstimmung".

disallow

Die Anweisung disallow gibt Pfade an, auf die die angegebenen Crawler nicht zugreifen dürfen. Falls hier kein Pfad angegeben ist, wird die Anweisung ignoriert.

Syntax:

disallow: [path]

allow

Die Anweisung allow gibt Pfade an, auf die die angegebenen Crawler zugreifen dürfen. Falls hier kein Pfad angegeben ist, wird die Anweisung ignoriert.

Syntax:

allow: [path]

Auf Pfadwerten basierende URL-Übereinstimmung

Anhand des Pfadwerts wird bestimmt, ob eine Regel für eine bestimmte URL einer Website gilt. Außer bei Platzhaltern wird der Pfad verwendet, um den Anfang einer URL und gegebenenfalls gültige URLs, die mit demselben Pfad beginnen, abzugleichen. Zeichen im Pfad, die keine 7-Bit-ASCII-Zeichen sind, können als UTF-8-Zeichen oder als durch ein Escapezeichen (Prozentzeichen) gekennzeichnete UTF-8-codierte Zeichen gemäß RFC 3986 eingeschlossen werden.

Google, Bing, Yahoo und Ask unterstützen eine eingeschränkte Form von Platzhaltern für Pfadwerte. Dabei handelt es sich um folgende Platzhalter:

  • * gibt 0 oder mehr Instanzen eines beliebigen Zeichens an.
  • $ kennzeichnet das Ende der URL.
Übereinstimmungen von Beispielpfaden
/ Stimmt mit dem Stamm und jeder URL auf einer niedrigeren Ebene überein
/* Gleichbedeutend mit /. Der nachgestellte Platzhalter wird ignoriert.
/fish

Übereinstimmungen:

  • /fish
  • /fish.html
  • /fish/salmon.html
  • /fishheads
  • /fishheads/yummy.html
  • /fish.php?id=anything

Keine Übereinstimmung:

  • /Fish.asp
  • /catfish
  • /?id=fish
/fish*

Entspricht /fish. Der nachgestellte Platzhalter wird ignoriert.

Übereinstimmungen:

  • /fish
  • /fish.html
  • /fish/salmon.html
  • /fishheads
  • /fishheads/yummy.html
  • /fish.php?id=anything

Keine Übereinstimmung:

  • /Fish.asp
  • /catfish
  • /?id=fish
/fish/

Der nachgestellte Schrägstrich bedeutet, dass der Ausdruck mit beliebigen Ordnerelementen übereinstimmt.

Übereinstimmungen:

  • /fish/
  • /fish/?id=anything
  • /fish/salmon.htm

Keine Übereinstimmung:

  • /fish
  • /fish.html
  • /Fish/Salmon.asp
/*.php

Übereinstimmungen:

  • /filename.php
  • /folder/filename.php
  • /folder/filename.php?parameters
  • /folder/any.php.file.html
  • /filename.php/

Keine Übereinstimmung:

  • / (auch wenn auf "/index.php" verwiesen wird)
  • /windows.PHP
/*.php$

Übereinstimmungen:

  • /filename.php
  • /folder/filename.php

Keine Übereinstimmung:

  • /filename.php?parameters
  • /filename.php/
  • /filename.php5
  • /windows.PHP
/fish*.php

Übereinstimmungen:

  • /fish.php
  • /fishheads/catfish.php?parameters

Keine Übereinstimmung: /Fish.PHP

Von Google unterstützte "non-group-member"-Zeilen

sitemap wird von Google, Ask, Bing und Yahoo unterstützt (definiert auf sitemaps.org).

Syntax:

sitemap: [absoluteURL]

[absoluteURL] verweist auf eine Sitemap, eine Sitemap-Indexdatei oder eine entsprechende URL. Die URL muss sich nicht auf dem gleichen Host wie die robots.txt-Datei befinden. Es können mehrere sitemap-Einträge vorhanden sein. Als "non-group-member"-Zeilen sind diese nicht an bestimmte User-Agents gebunden und können von allen Crawlern befolgt werden, sofern zulässig.

Reihenfolge der "group-member"-Zeilen

Auf "group-member"-Ebene hat die Regel, die der Länge des [path]-Eintrags zufolge spezifischer ist, Vorrang vor der weniger spezifischen, weil kürzeren Regel. Dies gilt insbesondere bei allow- und disallow-Anweisungen. Bei widersprüchlichen Regeln, einschließlich Regeln mit Platzhaltern, wird die am wenigsten restriktive verwendet.

Beispielsituationen
http://example.com/page

allow: /p

disallow: /

Verdikt: allow

http://example.com/folder/page

allow: /folder

disallow: /folder

Verdikt: allow

http://example.com/page.htm

allow: /page

disallow: /*.htm

Verdikt: undefined

http://example.com/

allow: /$

disallow: /

Verdikt: allow

http://example.com/page.htm

allow: /$

disallow: /

Verdikt: disallow