Robots.txt-Spezifikationen

Zusammenfassung

Dieses Dokument beschreibt, wie Google die robots.txt-Datei behandelt. Mit dieser Datei können Sie steuern, wie die Website-Crawler von Google öffentlich zugängliche Websites crawlen und indexieren.

Konventionen für die Formulierung von Anforderungen

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 laut 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. 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 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 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) 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 (RFC 1945 für HTTP/1.0 erlaubt bis zu fünf Sprünge), beenden dann den Vorgang und gehen von einem 404-Fehler aus. Die Behandlung von robots.txt-Weiterleitungen zu nicht zulässigen URLs ist nicht definiert und wird nicht empfohlen. 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), 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" 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. Es wird daher empfohlen, den HTTP-Ergebniscode 503 zurückzugeben, um das Crawling vorübergehend auszusetzen. Die Behandlung permanenter Serverfehler ist nicht definiert.

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, HTTP-Chunking-Fehlern – nicht abgerufen werden kann, ist nicht definiert.
Caching 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 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 Datensätzen (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 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 ist <field>:<value><#optional-comment>. Leerzeichen am Anfang und Ende des Datensatzes 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") ist nicht definiert. Die Anweisungen werden von manchen User-Agents möglicherweise als korrekt interpretiert.

Unter Umständen wird eine maximale Dateigröße pro Crawler erzwungen. Inhalte jenseits der maximalen Dateigröße werden möglicherweise ignoriert. Google erzwingt derzeit eine Höchstgrenze von 500 Kilobyte (KB).

Formale Syntax und Definition

Dies ist eine der Backus-Naur-Form (BNF) ähnelnde Beschreibung, der die Konventionen von RFC 822 zugrunde liegen. Abweichend von BNF werden Alternativen jedoch durch "|" gekennzeichnet. Literale werden "in gerade Anführungszeichen eingeschlossen" und Elemente werden (mit runden Klammern gruppiert). Optionale Elemente sind [durch eckige Klammern gekennzeichnet]. Wiederholungen des folgenden Elements können durch Voranstellen von <n>* bezeichnet 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.

Datensätze gruppieren

Datensätze werden je nach dem Typ des angegebenen <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 eine 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 folgende:

  • 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" und eine gemeinsame für "e" und "f". Jede Gruppe verfügt über einen eigenen group-member-Datensatz. Beachten Sie, dass zur Verbesserung der Lesbarkeit jeweils eine leere Zeile eingefügt wurde. Dies ist optional.

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* gleichwertig mit googlebot. 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)

Die relevante Gruppe wird von den einzelnen Crawlern so bestimmt:

Befolgte Datensatzgruppe pro Crawler
Googlebot-News Die befolgte Datensatzgruppe ist Gruppe 1. Nur die spezifischste 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-News (beim Crawlen von Bildern) Die befolgte Datensatzgruppe ist Gruppe 1. Diese Bilder werden für und von Googlebot-News gecrawlt. Deshalb wird nur die Googlebot-News-Gruppe befolgt.
Otherbot (Web) Die befolgte Datensatzgruppe ist Gruppe 2.
Otherbot (News) Die befolgte Datensatzgruppe 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-Datensätze

In diesem Abschnitt werden nur allgemeine und Google-spezifische group-member-Datensatztypen behandelt. Diese Datensatztypen 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"-Datensätze

Sitemap

Unterstützt von Google, Ask, Bing, Yahoo; 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"-Datensätze sind diese nicht an bestimmte User-Agents gebunden und können von allen Crawlern befolgt werden, sofern zulässig.

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. Bei Regeln mit Platzhaltern ist die Reihenfolge nicht definiert.

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

Feedback geben zu...