Robots.txt-Spezifikationen

Zusammenfassung

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

Zurück nach oben

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.

Zurück nach oben

Grundlegende 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 vorhanden, 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.

Zurück nach oben

Geltungsbereich

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.

Zurück nach oben

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.

Hinweis: Bei der URL für die robots.txt-Datei wird wie bei anderen URLs zwischen Groß- und Kleinschreibung unterschieden.

Zurück nach oben

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

robots.txt-URLGültig für Nicht gültig fürBemerkungen
http://ihrebeispielurl.de/robots.txt http://ihrebeispielurl.de/
http://ihrebeispielurl.de/ordner/datei
http://other.ihrebeispielurl.de/
https://ihrebeispielurl.de/
http://ihrebeispielurl.de:8181/
Diese URL entspricht dem üblichen Schema. Sie gilt nicht für andere Subdomains, Protokolle oder Portnummern. Sie gilt für alle Dateien in allen Unterverzeichnissen auf demselben Host, mit demselben Protokoll und derselben Portnummer.
http://www.ihrebeispielurl.de/robots.txt http://www.ihrebeispielurl.de/ http://ihrebeispielurl.de/
http://shop.www.ihrebeispielurl.de/
http://www.shop.ihrebeispielurl.de/
Eine robots.txt-Datei in einer Subdomain gilt nur für die jeweilige Subdomain.
http://ihrebeispielurl.de/ordner/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 http://www.müller.eu/
http://www.xn--mller-kva.eu/
http://www.muller.eu/ Die IDNs entsprechen ihren Punycode-Versionen. Weitere Informationen finden Sie unter RFC 3492.
ftp://ihrebeispielurl.de/robots.txt ftp://ihrebeispielurl.de/ http://ihrebeispielurl.de/ Google-spezifisch: Wir verwenden robots.txt-Dateien für FTP-Ressourcen.
http://212.96.82.21/robots.txt http://212.96.82.21/ http://ihrebeispielurl.de/ (auch wenn unter 212.96.82.21 gehostet) Eine robots.txt-Datei, deren Hostname eine IP-Adresse ist, ist nur für das Crawlen dieser IP-Adresse als Hostname gültig. Sie ist nicht automatisch für alle unter dieser IP-Adresse gehosteten Websites gültig. Es ist allerdings möglich, dass die robots.txt-Datei freigegeben ist. In diesem Fall steht sie auch unter dem gemeinsamen Hostnamen zur Verfügung.
http://ihrebeispielurl.de:80/robots.txt http://ihrebeispielurl.de:80/
http://ihrebeispielurl.de/
http://ihrebeispielurl.de:81/ Die standardmäßigen Portnummern (80 für http, 443 für https, 21 für ftp) entsprechen den jeweiligen standardmäßigen Hostnamen. Weitere Informationen finden Sie unter [portnumbers].
http://ihrebeispielurl.de:8181/robots.txt http://ihrebeispielurl.de:8181/ http://ihrebeispielurl.de/ robots.txt-Dateien unter nicht standardmäßigen Portnummern sind nur für Inhalte gültig, die über diese Portnummern zur Verfügung gestellt werden.

Zurück nach oben

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 der Inhalte gecrawlt werden.
  • conditional allow: Die Anweisungen in der robots.txt-Datei bestimmen, ob bestimmte Inhalte gecrawlt werden dürfen.
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 (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 (Client-Fehler)
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. Hinweis: Dies gilt auch für die HTTP-Ergebniscodes 401 (Unauthorized) und 403 (Forbidden).
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 als ein Serverfehler zurückgegeben wird. 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.
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 sie auch länger im Cache verbleiben. Die Antwort im Cache kann gleichzeitig für verschiedene Crawler gelten. Google kann das Cache-Alter basierend auf HTTP-Headern des Typs max-age Cache-Control erhöhen oder verringern.

Zurück nach oben

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><#optionaler-kommentar>". Leerräume am Anfang und am Ende des Datensatzes werden ignoriert.

Das <field>-Element unterscheidet zwischen Groß- und Kleinschreibung. 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 KB durch.

Zurück nach oben

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 mit "" umschlossen, 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.

Zurück nach oben

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.

      Zurück nach oben

      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)
      

      Die relevante Gruppe wird von den Crawlern folgendermaßen bestimmt:

      Name des CrawlersBefolgte Datensatzgruppe Bemerkungen
      Googlebot-News (Gruppe 1) Nur die am genauesten angegebene Gruppe wird befolgt, alle anderen werden ignoriert.
      Googlebot (Web) (Gruppe 3) 
      Googlebot für Bilder (Gruppe 3) Es gibt keine spezifische googlebot-images-Gruppe. Deshalb wird der allgemeineren Gruppe gefolgt.
      Googlebot-News (beim Crawlen von Bildern) (Gruppe 1) Diese Bilder werden für und von Googlebot-News gecrawlt. Deshalb wird nur die Googlebot-News-Gruppe befolgt.
      Otherbot (Web)(Gruppe 2) 
      Otherbot (News)(Gruppe 2) Selbst wenn ein Eintrag für einen ähnlichen Crawler besteht, gilt dieser nur bei genauer Übereinstimmung.

      Weitere Informationen finden Sie unter Crawler von Google und User-Agent-Strings

      Zurück nach oben

      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 "Anweisung: [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. Falls ein Pfad ohne vorangehenden Schrägstrich gefunden wird, wird dennoch davon ausgegangen, dass er vorhanden ist. 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.

      Syntax:

      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.

      Syntax:

      allow: [path]
      

      Zurück nach oben

      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.

      Hinweis: "AJAX-Crawling"-URLs müssen in ihrer gecrawlten Version angegeben werden. Weitere Informationen finden Sie in der Dokumentation zur Herstellung der Crawlbarkeit von AJAX-Anwendungen.

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

      1. * kennzeichnet 0 oder mehr Exemplare ungültiger Zeichen.
      2. $ kennzeichnet das Ende der URL.

      Übereinstimmungen von Beispielpfaden

      [path]Übereinstimmungen Keine ÜbereinstimmungBemerkungen
      /beliebige gültige URL  Stimmt mit dem Stamm und jeder URL auf einer niedrigeren Ebene überein
      /*Entspricht / Entspricht / Entspricht "/" – nachstehender Platzhalter wird ignoriert
      /fish/fish
      /fish.html
      /fish/salmon.html
      /fishheads
      /fishheads/yummy.html
      /fish.php?id=anything
      /Fish.asp
      /catfish
      /?id=fish
      Beachten Sie, dass beim Abgleichen zwischen Groß- und Kleinschreibung unterschieden wird.
      /fish*/fish
      /fish.html
      /fish/salmon.html
      /fishheads
      /fishheads/yummy.html
      /fish.php?id=anything
      /Fish.asp
      /catfish
      /?id=fish
      Entspricht "/fish" – nachstehender Platzhalter wird ignoriert
      /fish//fish/
      /fish/?id=anything
      /fish/salmon.htm
      /fish
      /fish.html
      /Fish/Salmon.asp
      Der nachstehende Schrägstrich bedeutet, dass dies mit dem gesamten Ordnerinhalt übereinstimmt.
      fish/Entspricht /fish/ Entspricht /fish/ Entspricht /fish/
      /*.php/filename.php
      /folder/filename.php
      /folder/filename.php?parameters
      /folder/any.php.file.html
      /filename.php/
      / (auch wenn auf /index.php verwiesen wird)
      /windows.PHP
       
      /*.php$/filename.php
      /folder/filename.php
      /filename.php?parameters
      /filename.php/
      /filename.php5
      /windows.PHP
       
      /fish*.php/fish.php
      /fishheads/catfish.php?parameters
      /Fish.PHP  

      Zurück nach oben

      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 äquivalente URL. Die URL muss nicht denselben Host aufweisen wie die robots.txt-Datei. 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.

      Zurück nach oben

      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:

      URLallow:disallow:Urteil Bemerkungen
      http://ihrebeispielurl.de/page /p /allow 
      http://ihrebeispielurl.de/folder/page /folder/ /folderallow 
      http://ihrebeispielurl.de/page.htm /page /*.htmundefined 
      http://ihrebeispielurl.de/ /$ /allow 
      http://ihrebeispielurl.de/page.htm /$ /disallow 

      Zurück nach oben

       

Feedback geben zu...