robots.txt-Spezifikationen

Abstrakt

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

Anforderungssprache

Dieser Artikel ist eine Übersetzung aus dem Englischen. Für die im Original verwendeten Begriffe MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY und OPTIONAL gelten die Definitionen in RFC 2119.

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. Wenn neue URLs gefunden werden, beispielsweise über Links auf vorhandenen, bereits 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äß der Definition in RFC 1738
Google-spezifisch Diese Elemente sind für die Implementierung von robots.txt durch Google spezifisch und sind für Dritte möglicherweise nicht relevant.

Gültigkeit

Die in diesem Dokument dargelegten Richtlinien werden von allen automatisierten Crawlern von Google befolgt. Falls ein Agent auf Anweisung eines Nutzers auf URLs zugreift, beispielsweise zwecks Übersetzung, bei manuell abonnierten Feeds oder für die Malware-Analyse, gelten diese Richtlinien nicht unbedingt.

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 und das Crawlen von Websites sind "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 befolgt robots.txt-Dateien auch für FTP-Websites. robots.txt-Dateien auf FTP-Grundlage werden unter Verwendung anonymer Anmeldeinformationen über das FTP-Protokoll aufgerufen.

Die in der robots.txt-Datei aufgeführten Anweisungen gelten nur für den Host, das Protokoll und die Portnummer, unter der die Datei gehostet wird.

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 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/

HTTP-Ergebniscodes handhaben

Das Abrufen von robots.txt-Dateien kann im Allgemeinen zu drei verschiedenen Ergebnissen führen:

  • full allow: Alle Inhalte dürfen gecrawlt werden.
  • full disallow: Es dürfen keine Inhalte gecrawlt werden.
  • conditional allow: Die Anweisungen in der robots.txt-Datei bestimmen, ob bestimmte Inhalte gecrawlt werden dürfen.
HTTP-Ergebniscodes handhaben
2xx (erfolgreiche Operation) HTTP-Ergebniscodes, die einen erfolgreichen Vorgang signalisieren, führen zu einem "conditional allow" für das Crawling.
3xx (Weiterleitung) Den Weiterleitungen wird im Allgemeinen gefolgt, bis ein gültiges Ergebnis erreicht oder eine Schleife erkannt wird. Wir folgen dabei einer begrenzten Anzahl von Weiterleitungssprüngen bzw. Hops (RFC 1945 für HTTP/1.0 gestattet bis zu 5 Sprünge) und halten dann an und verzeichnen einen 404-Fehler. Die Verarbeitung von robots.txt-Weiterleitungen zu nicht zugelassenen URLs ist nicht definiert und wird nicht empfohlen. Die Verarbeitung logischer Weiterleitungen für die robots.txt-Datei auf der Grundlage von HTML-Inhalten, die 2xx-Ergebniscodes zurückgeben (Frame-, JavaScript- oder Meta-Refresh-Weiterleitungen), ist nicht definiert und wird nicht empfohlen.
4xx (Clientfehler) Google behandelt alle 4xx-Fehler gleich und geht davon aus, 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" für das Crawling führen. Die Anforderung wird wiederholt, bis ein anderer HTTP-Ergebniscode zurückgegeben wird, bei dem es sich nicht um einen Serverfehler handelt. Der Fehler 503 (Service Unavailable) hat recht häufige Wiederholungsversuche zur Folge. Es wird empfohlen, den HTTP-Ergebniscode 503 zurückzugeben, um das Crawling vorübergehend auszusetzen. Die Verarbeitung permanenter Serverfehler ist nicht definiert.

Google-spezifisch: Sollten wir feststellen, dass eine Website aufgrund einer fehlerhaften 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 Verarbeitung einer robots.txt-Datei, die aufgrund von DNS- oder Netzwerkproblemen – z. B. Zeitüberschreitungen, ungültigen Antworten, zurückgesetzten oder unterbrochenen Verbindungen, HTTP-Chunking-Fehlern – nicht abgerufen werden kann, ist nicht definiert.
Speichern im Cache robots.txt-Anforderungen 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 sie auch länger im Cache verbleiben. Die Antwort im Cache kann gleichzeitig für verschiedene Crawler gelten. Google kann die Cache-Lebensdauer basierend auf HTTP-Headern des Typs max-age Cache-Control erhöhen oder verringern.

Dateiformat

Das erwartete Dateiformat ist ein in UTF-8 codiertes Nur-Text-Format. Die Datei besteht aus Datensätzen (Zeilen), die durch CR, CR/LF oder LF getrennt sind.

Es werden nur gültige Datensätze 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-BOM (byte order mark) am Anfang der robots.txt-Datei wird ignoriert.

Jeder Datensatz 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 des Datensatzes wird als Kommentar behandelt und ignoriert. Das allgemeine Format lautet <field>:<value><#optional-comment>. Leerräume am Anfang und am Ende des Datensatzes werden ignoriert.

Beim <field>-Element wird zwischen Groß- und Kleinschreibung unterschieden. Ob das <value>-Element zwischen Groß- und Kleinschreibung unterscheidet, hängt vom <field>-Element ab.

Die Verarbeitung von <field>-Elementen mit einfachen Fehlern bzw. Tippfehlern (z. B. "useragent" statt "user-agent") ist nicht definiert. Die Anweisungen werden von einigen User-Agents möglicherweise als korrekt interpretiert.

Unter Umständen wird eine maximale Dateigröße pro Crawler durchgesetzt. Inhalte jenseits der maximalen Dateigröße werden möglicherweise ignoriert. Google setzt derzeit eine maximale Größe von 500 Kilobyte (KB) durch.

Formale Syntax/Definition

Dies ist eine der Backus-Naur-Form (BNF) ähnelnde Beschreibung, in der die Konventionen von RFC 822 verwendet werden. Allerdings werden Alternativen durch "|" gekennzeichnet. Literale werden in gerade Anführungszeichen ("") gesetzt, Elemente mit den Klammern "(" und ")" gruppiert. Optionale Elemente werden in [eckige Klammern] gesetzt. n oder mehr Wiederholungen des folgenden Elements können durch Voranstellen von <n>* ausgezeichnet werden. Der Standardwert für "n" ist 0.

robotstxt = *entries
entries = *( ( <1>*startgroupline
  *(groupmemberline | nongroupline | comment)
  | nongroupline
  | comment) )
startgroupline = [LWS] "user-agent" [LWS] ":" [LWS] agentvalue [comment] EOL
groupmemberline = [LWS] (
  pathmemberfield [LWS] ":" [LWS] pathvalue
  | othermemberfield [LWS] ":" [LWS] textvalue) [comment] EOL
nongroupline = [LWS] (
  urlnongroupfield [LWS] ":" [LWS] urlvalue
  | othernongroupfield [LWS] ":" [LWS] textvalue) [comment] EOL
comment = [LWS] "#" *anychar
agentvalue = textvalue

pathmemberfield = "disallow" | "allow"
othermemberfield = ()
urlnongroupfield = "sitemap"
othernongroupfield = ()

pathvalue = "/" path
urlvalue = absoluteURI
textvalue = *(valuechar | SP)
valuechar = <any UTF-8 character except ("#" CTL)>
anychar = <any UTF-8 character except CTL>
EOL = CR | LF | (CR LF)

Die Syntax für "absoluteURI", "CTL", "CR", "LF" und "LWS" ist in RFC 1945 definiert, die Syntax für "path" in RFC 1808.

Gruppierung von Datensätzen

Datensätze werden basierend auf dem Typ des <field>-Elements in verschiedene Typen unterteilt.

  • start-of-group
  • group-member
  • non-group

Alle group-member-Datensätze nach einem start-of-group-Datensatz bis zum nächsten start-of-group-Datensatz werden als Datensatzgruppe behandelt. Das einzige start-of-group-Feldelement ist user-agent. Auf die letzte start-of-group-Zeile folgen die group-member-Datensätze gefolgt von mehreren start-of-group-Zeilen direkt hintereinander. Alle group-member-Datensätze, denen kein start-of-group-Datensatz vorangeht, werden ignoriert. Alle non-group-Datensätze sind gültig, und zwar unabhängig von allen Gruppen.

Gültige <field>-Elemente, die weiter unten in diesem Dokument einzeln beschrieben werden, sind die folgenden:

  • user-agent (Anfang der Gruppe)
  • disallow (nur als group-member-Datensatz gültig)
  • allow (nur als group-member-Datensatz gültig)
  • sitemap (non-group-Datensatz)

Alle anderen <field>-Elemente können ignoriert werden.

Über das start-of-group-Element user-agent wird angegeben, für welchen Crawler die Gruppe gilt. Für einen bestimmten Crawler gilt jeweils nur eine Datensatzgruppe. Die Reihenfolge wird weiter unten in diesem Dokument behandelt.

Beispielgruppen:

user-agent: a
disallow: /c

user-agent: b
disallow: /d

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

Es sind drei unterschiedliche Gruppen angegeben, eine für "a", eine für "b" sowie eine gemeinsame für "e" und "f". Jede Gruppe verfügt über einen eigenen group-member-Datensatz. Es wird ein optionaler Leerraum (eine leere Zeile) verwendet, um die Lesbarkeit zu verbessern.

Reihenfolge der User-Agents

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

Beispiel

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

user-agent: googlebot-news
(group 1)

user-agent: *
(group 2)

user-agent: googlebot
(group 3)

So wird die relevante Gruppe von den Crawlern bestimmt:

Befolgte Datensatzgruppe pro Crawler
Googlebot für Nachrichten Die befolgte Datensatzgruppe ist Gruppe 1. Nur die am genauesten angegebene Gruppe wird befolgt, alle anderen werden ignoriert.
Googlebot (Web) Die befolgte Datensatzgruppe ist Gruppe 3.
Googlebot für Bilder Die befolgte Datensatzgruppe ist Gruppe 3. Es gibt keine spezifische googlebot-images-Gruppe. Deshalb wird die allgemeinere Gruppe befolgt.
Googlebot für Nachrichten (beim Crawlen von Bildern) Die befolgte Datensatzgruppe ist Gruppe 1. Die Bilder werden für und von Googlebot für Nachrichten gecrawlt. Deshalb wird nur die Gruppe für Googlebot für Nachrichten befolgt.
Otherbot (Web) Die befolgte Datensatzgruppe ist Gruppe 2.
Otherbot (Nachrichten) Die befolgte Datensatzgruppe ist Gruppe 2. Selbst wenn ein Eintrag für einen ähnlichen Crawler vorhanden ist, gilt dieser nur bei genauer Übereinstimmung.

Weitere Informationen finden Sie unter Google-Crawler (User-Agents).

group-member-Datensätze

In diesem Abschnitt werden nur allgemeine und Google-spezifische group-member-Datensatztypen behandelt. Diese Datensatztypen werden bei den Crawlern auch als "Anweisungen" bezeichnet. Diese Anweisungen werden in Form von 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 Stamm 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 "/" beginnen, um den Stamm zu kennzeichnen. Bei dem Pfad wird zwischen Groß- und Kleinschreibung unterschieden. Weitere Informationen dazu finden Sie weiter unten im Abschnitt "Auf Pfadwerten basierende URL-Übereinstimmung".

disallow

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

Verwendung:

disallow: [path]

allow

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

Verwendung:

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. Nicht-7-Bit-ASCII-Zeichen in einem Pfad können als UTF-8-Zeichen oder als durch ein 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. Diese sind:

  • * kennzeichnet 0 oder mehr Instanzen ungültiger Zeichen.
  • $ kennzeichnet das Ende der URL.
Übereinstimmungen von Beispielpfaden
/ Stimmt mit dem Stamm und jeder URL auf einer niedrigeren Ebene überein
/* Gleichbedeutend mit /. Der nachstehende Platzhalter wird ignoriert.
/fish

Übereinstimmungen:

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

Nichtübereinstimmungen:

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

Gleichbedeutend mit /fish. Der nachstehende Platzhalter wird ignoriert.

Übereinstimmungen:

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

Nichtübereinstimmungen:

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

Der nachstehende Schrägstrich bedeutet, dass eine Übereinstimmung mit dem gesamten Ordnerinhalt besteht.

Übereinstimmungen:

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

Nichtübereinstimmungen:

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

Übereinstimmungen:

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

Nichtübereinstimmungen:

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

Übereinstimmungen:

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

Nichtübereinstimmungen:

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

Übereinstimmungen:

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

Nichtübereinstimmungen: /Fish.PHP

Von Google unterstützte non-group-member-Datensätze

sitemap

Unterstützt von Google, Ask, Bing, Yahoo; definiert auf sitemaps.org

Verwendung:

sitemap: [absoluteURL]

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

Reihenfolge der group-member-Datensätze

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. Die Reihenfolge für Regeln mit Platzhaltern ist nicht definiert.

Beispielsituationen
http://example.com/page

allow: /p

disallow: /

Verdikt: zulassen

http://example.com/folder/page

allow: /folder

disallow: /folder

Verdikt: zulassen

http://example.com/page.htm

allow: /page

disallow: /*.htm

Verdikt: nicht definiert

http://example.com/

allow: /$

disallow: /

Verdikt: zulassen

http://example.com/page.htm

allow: /$

disallow: /

Verdikt: nicht zulassen

Feedback geben zu...