Auf den Punkt gebracht

• Mit der robots.txt steuert man das Crawling einer Webseite
• Die robots.txt muss im Rootverzeichnis der Domain liegen
• CSS- und JS-Dateien dürfen in der robots.txt nicht geblockt werden

Bei einer robots.txt handelt es sich um eine Textdatei im Rootverzeichnis der Domain, mit der man das Crawling der Domain steuern kann. Suchmaschinenbots wie Google oder Bing besuchen zuerst die robots.txt, um die Anweisungen auszulesen, bevor mit dem Crawl der Domain begonnen wird.

Aufbau einer robots.txt

Grundsätzlich ist es wichtig, dass die robots.txt im Rootverzeichnis der Domain liegt. Also z.B. https://www.demirjasarevic.com/robots.txt. robots.txt-Dateien, die unterhalb eines Verzeichnisses liegen haben keine Gültigkeit. Zudem sollte die Datei genau “robots.txt” heißen (also alles in klein), da das Auslesen case-sensitive erfolgt.

Erstellen kann man die robots.txt mit einem einfachen Texteditor. Eine Regel besteht aus 2 Blöcken. Der erste Block beginnt mit “User:” und legt den Useragent fest (z.B. Googlebot). Gleich darunter folgt der zweite Block mit “Disallow:” oder “Allow:” mit der Angabe des Verzeichnisses. Eine einfache robots.txt kann folgendermaßen aussehen:

User-agent: Googlebot
Disallow:

Damit erlaubt man den Googlebot den Zugriff auf alle Webseiteninhalte. Will man die komplette Webseite sperren, so würde die robots.txt folgende Angaben enthalten:

User-agent: Googlebot
Disallow: /

Will man andere bzw. mehrere Bots aussperren, so definiert man für jeden Bot eine eigene Zeile.

robots.txt-Spezifikationen

Nachfolgend sind einige Beispiele für gültige und ungültige robots.txt-URLs aufgeführt:

Beim vorletzten Beispiel sei zu beachten, dass die Standard-Portnummern (80 für http, 443 für https, 21 für ftp) den Standard-Hostnamen entsprechen. Wenn die robots.txt unter nicht standardmäßigen Portnummern läuft (letztes Beispiel mit 8181), dann ist sie nur für diese Portnummer gültig.

HTTP-Statuscodes und Konsequenzen

Wenn der Crawler die robots.txt aufruft, dann kann es zu 3 verschiedenen Ergebnissen kommen:

• full allow: Alle Inhalte dürfen gecrawlt werden.
• full disallow: Keine Inhalte dürfen gecrawlt werden.
• conditional allow: Ein paar Inhalte können gecrawlt werden, ein paar nicht.

Dabei kann die robots.txt folgende Status Codes senden:

2xx (Vorhanden)
Die robots.txt ist vorhanden und sendet einen 2xx-Code. Dies führt zu “conditional allow”. Google prüft die Anweisungen.

3xx (Weiterleitung)
Beim Aufruf der robots.txt bekommt der Bot eine Weiterleitung. Grundsätzlich wird diese verarbeitet. Sollten mehr als 5 Weiterleitungen existieren, so verzeichnet Google einen 404-Code für die robots.txt. Auf Weiterleitungen sollte aber verzichtet werden.

4xx (Client-Fehler)
Sendet die robots.txt einen 404er, 410er, etc. geht Google davon aus, dass es die robots.txt nicht gibt. Es wird angenommen, dass es keine Einschränkungen gibt, weshalb hier ein “full allow” herrscht.

5xx (Serverfehler)
Serverfehler werden als temporäre Fehler verstanden. Diese führen zu einem “full disallow”. Google wird versuchen, die robots.txt so oft aufzurufen, bis ein anderer Status-Code geliefert wird. Google empfiehlt in diesem Fall einen 503er zu senden, da ein “full disallow” sonst nach einer Zeit zu einer Deindexierung der Domain führen kann. 503 hat zur Folge, dass mehrere Wiederholungsversuche zum Abrufen vorgenommen werden. Wenn die robots.txt innerhalb von 30 Tagen nicht aufgerufen werden kann, wird die letzte im Cache bekannte Datei verwendet. Ist im Cache keine Datei hinterlegt, geht Google davon aus, dass es keine Einschränkungen gibt.

Kurz und knapp bedeutet das:

• HTTP-Status 200: Keine Probleme
• HTTP-Status 404: Ist für Crawling und Indexierung ok
• HTTP-Status 5xx: OK, wenn vorübergehend
• HTTP-Status 5xx: Kritisch, wenn dauerhaft

Wird ein undefinierter Status Code ausgeliefert, dann kann Google das Crawlen der Domain einstellen (Quelle).

Wichtige Angaben in der robots.txt

Neben dem Googlebot gibt es noch weitere Bots, die man vielleicht aussperren möchte. Einige Beispiele:

• Googlebot (Google-Suchmaschine)
• Googlebot-Image (Google-Bildersuche)
• Adsbot-Google (Google AdWords)
• Slurp (Yahoo)
• bingbot (Bing)

Nachfolgend die wichtigsten Angaben für die robots.txt zusammengefasst:

• User-agent: Angesprochene(r) Crawler –> z.B. User-agent: Googlebot
• Allow: Besuch wird erlaubt –> z.B. “Allow: /datei1-erlaubt.html”
• Disallow: Besuch wird nicht erlaubt –> z.B. “Disallow: /datei2-nicht-erlaubt.html”
• # (Raute): Kommentarzeile –> z.B. “# robots.txt von demirjasarevic.com”
• * (Stern): Wildcard nutzbar für Useragents und URL-Pfade –> z.B. “Disallow: /*?”
• $ (Dollarzeichen): Kennzeichnet Pfadende –> z.B. “Disallow: /*.pdf$”
• Sitemap: Angabe der Sitemap –> z.B. “Sitemap: https://www.demirjasarevic.de/sitemap.xml”
• Crawl-delay: Verzögerung in Minuten zwischen 2 Abrufen (wird von Google nicht befolgt) –> z.B. “Crawl-Delay: 120”

Noch ein paar Hinweise zu * und $:

• Der Stern (*) dient als Platzhalter für jegliche Zeichenkette, die darauf folgt. Mit “*check” kann man also alle Seiten aussperren, die “check” in der URL enthalten. Dies wird sehr oft bei Parameter-URLs verwendet. Mit der Angabe “User-agent: *” würde man demnach alle Bots ansprechen.
• Das Dollarzeichen ($) dient als Platzhalter für eine Filterregel, die am Ende einer Zeichenkette greift. Bei “*check$” würden Bots URLs nicht crawlen, die mit dieser Zeichenkette enden. So kann man auch mit “Disallow: /*.pdf$” alle Dateien sperren, die mit “.pdf” enden.

Dateiformat

Bez. dem Dateiformat ist folgendes zu beachten:

• Es sollte ein UTF-8 codiertes Nur-Text-Format sein
• Wenn es ein HTML ist, werden nur Textzeilen berücksichtigt
• Unicode-BOM wird ignoriert
• Leerzeichen sind optional; sollten aber zur besseren Lesbarkeit eingesetzt werden
• Kommentare können mit “#” eingesetzt werden
• Google beschränkt die Dateigröße auf 500KB

SEO und robots.txt

Im “Robots Exclusion Standard Protokoll” (kurz: REP) ist geregelt, dass Suchmaschinenbots zunächst die robots.txt aufrufen und auslesen, bevor mit den Crawling und der Indexierung der Seite begonnen wird. Man muss jedoch beachten, dass sich nicht alle Suchmaschinen strikt an den Vorgaben in der robots.txt halten. So kann es passieren, dass eine in der robots.txt ausgesperrte Seite dennoch im Index landet. Grund dafür sind meist externe Signale, wie z.B. Backlinks auf die betroffene Seite.

Aus diesem Grund setzt sich Google für einen Standard ein. Es sollen ungeklärte Szenarien in den Standard reinfließen:

• Alle URI-basierten Übertragungsprotokolle sollen die robots.txt unterstützen. Neben HTTP wären dies auch FTP oder CoAP.
• Es müssen min. 500 KB der robots.txt geparst werden, damit eine zu große Datei nicht zu Verbindungsproblemen führt.
• Die robots.txt soll eine Caching-Obergrenze von 24 Stunden bekommen. Webmaster bekommen dadurch die Flexibilität Anpassungen auch kurzfristig vorzunehmen. Gleichzeitig müssen Crawler die Webseite nicht mit robots.txt-Anfragen überlasten.
• Wenn eine vorher verfügbare robots.txt plötzlich nicht mehr aufrufbar ist, dann werden die mit vorher “Disallow” gekennzeichneten Bereiche für einen bestimmten Zeitraum weiterhin nicht gecrawlt.

Es werden aber auch einige Regeln (ab dem 1. September 2019) nicht mehr unterstützt, da sie nicht oft genutzt werden oder weil sie offiziell eigentlich nie richtig unterstützt wurden:

• crawl-delay
• nofollow
• noindex

Aus SEO-Sicht sollte man bei der robots.txt folgendes sicherstellen:

• Keine CSS- und JavaScript-Dateien sperren
• Link zur Sitemap hinzufügen
• Seiten nicht per robots.txt von der Indexierung ausschließen

Vor allem beim letzten Punkt werden immer wieder Fehler gemacht. Ursache ist meist ein fehlendes Verständnis für Crawling und Indexierung. Das Crawling wird mit der robots.txt gesteuert, die Indexierung z.B. mit dem noindex-Attribut oder dem Canonical. Eine Sperrung einer URL in der robots.txt mit dem Ziel, eine bestehende Seite aus dem Index zu nehmen, wird nicht zum Erfolg führen. Das Ergebnis: Die Seite bleibt weiterhin im Index mit dem Hinweis “Aufgrund der robots.txt dieser Website ist keine Beschreibung für dieses Ergebnis verfügbar. Weitere Informationen” in der Meta-Description. Durch die Crawling-Aussperrung kann Google den Quellcode nicht verarbeiten und keine Informationen auslesen. Das Gleiche gilt beim Zusammenspiel mit noindex. Würde man nun im Nachgang die Seite mit noindex versehen, bliebe sie dennoch im Index. Wie kann Google die noindex-Anweisung verarbeiten, wenn die URL vom Crawling ausgeschlossen wird? Daher sollte man beim Deindexieren von Seiten zunächst mit noindex arbeiten. Will man diese zusätzlich vom Crawling ausschließen, so wartet man bis die URL aus dem Index ist und kann dann den Eintrag in der robots.txt vornehmen.

Hinweis zur Verwendung der Raute (#) in der robots.txt: Auch in der URL können Hash-Zeichen – z.B. bei AJAX-Seiten oder als Anker – existieren. Falls man solche URL dann in der robots.txt aussperren möchte, kann dies zu nachteiligen Nebeneffekten führen, da das Hash Kommentare in der robots.txt einleitet. Ein “Disallow: /#*” um alle Hash-URLs zu sperren, führt dazu dass Google nur “Disallow: /” sieht und die komplette Domain somit nicht mehr crawlt, da mit dem # dann ein Kommentar eingeleitet wird. Daher sollte man damit vorsichtig sein. Zudem crawlt Google keine URLs mit Hash-Zeichen, weshalb man diese nicht in der robots.txt anführen muss.

Tools

Nachfolgend einige Tools, die bez. robots.txt Hilfe leisten.

Google Search Console

Die Google Search Console bietet bez. der robots.txt folgende Möglichkeiten:

• Aktuelle verfügbare robots.txt einsehen: Unter “Crawling” und dann “robots.txt-Tester” kann man sehen, welche robots.txt aktuell Google ausliest.
• Analyse geblockte Ressourcen: Unter “Google-Index” und dann “Blockierte Ressourcen” kann man sehen, ob es blockierte Ressourcen gibt, die man ggf. freischalten müsste.
• Neue robots.txt an Google übermitteln: Unter “Crawling” und dann “robots.txt-Tester” kann man mit einem Klick auf “Senden” die aktuelle robots.txt an Google zur Verarbeitung übermitteln.
• Testen, ob URLs geblockt sind: Unter “Crawling” und dann “robots.txt-Tester” kann man ganz unten testen, ob gewissen URLs blockiert oder frei für das Crawling sind.

Screaming Frog

Auch der Screaming Frog bietet viele interessante Möglichkeiten bez. der robots.txt an:

• robots.txt ignorieren: Unter “Configuration” -> “robots.txt” -> “Settings” kann man festlegen, ob beim Crawlen die robots.txt ignoriert werden soll oder nicht. Hier kann man – trotz gesperrter Inhalte – die komplette Webseite zu Analysezwecke crawlen.
• Report, was alles geblockt ist: Unter “Configuration” -> “robots.txt” -> “Settings” kann man die Funktion aktivieren, dass der Screaming Frog anzeigt, welche internen und externen URLs durch die robots.txt geblockt sind. Auf Development-Umgebungen kann man so schon vor dem Live-Gang einer Domain prüfen, ob es Ressourcen gibt, die man freischalten sollte.
• Testing: Unter “Configuration” -> “robots.txt” -> “Custom” kann man die Webseiten-URL eingeben unter welcher man die robots.txt finden kann. Hier kann man dann testen, ob gewünschte URLs blockiert sind oder nicht. Zudem kann man die robots.txt bearbeiten und so vor dem Live-Stellen prüfen, ob Angaben funktionieren oder nicht.

Googles Parser für robots.txt

In GitHub hat Google den Parser für robots.txt-Dateien zur Verfügung gestellt.

robots.txt und Sicherheit

Da die robots.txt meist öffentlich von Mensch und Maschine aufgerufen werden kann, sollte man zwecks Sicherheit folgendes beachten:

• Schlechte Bots besuchen eventuell gesperrte Bereiche bewusst
• Bereiche und Seiten, die über die robots.txt gesperrt sind, können von Menschen und Bots aufgerufen werden, um sensible Informationen zu finden
• Sensible Seiten mit sensiblen Informationen sollten nicht über die robots.txt gesperrt werden; besser ist es diese mit einer noindex-Anweisung zu versehen, damit sie nicht im den Suchindex gelangen (die robots.txt ist sowieso nicht dazu da, die Indexierung zu steuern)
• Seiten, die weder über den Suchindex noch direkt ansteuerbar sein sollen, am besten z.B. per htaccess sperren
• Wenn man unbedingt per robots.txt was sperren muss, dann lieber Bereiche (Verzeichnisse) statt einzelne Seiten sperren; bei einzelnen Seiten macht man sich zu transparent
• Wenn man Bereiche (Verzeichnisse) sperrt, dann am besten auch eine leere Index-Datei im Ordner hinterlegen, damit man das surfen auf einer Index-of-Seite verhindert
• Um die Sicherheit zu erhöhen, kann man in der robots.txt auch bewusst gezielt eine Seite angeben und als Honeypot verwenden; die IP-Adresse, die auf die gesperrte Seite zugreift, wird dann auf die IP-Blackliste gesetzt und zukünftig von der Seite ausgesperrt

Weitere Informationen zur robots.txt

• ASCII-Art in der robots.txt: Viele Domains bringen in ihrer robots.txt ASCII-Zeichnungen oder auch bestimmte Botschaften unter. So kann man bspw. mittels ASCII-Zeichen das eigene Logo oder andere Zeichnungen unterbringen.
• humans.txt: Analog zur robots.txt, die für Maschinen ist, hat sich daraus humans.txt entwickelt. Hier kann man sozusagen Botschaften an Menschen unterbringen. Meist wird die humans.txt dazu verwendet, die Menschen hinter dem Webseiten-Projekt vorzustellen.
• Aus URL-Sicht behandelt Google die robots.txt wie alle anderen URLs auf der Seite. Heißt, dass auch die URL /robots.txt indexiert werden kann. Das ist grundsätzlich kein Problem. Über die X-Robots-Header-Angabe kann eine Indexierung jedoch verhindert werden.
• WordPress: Das CMS erzeugt automatisch eine robots.txt, wenn auf dem Server keine liegt. Im besten Fall wird eine eigene mit eigenen Regeln definiert. Falls man keine eigene erzeugt hat oder erzeugen will, sollte man sicherheitshalber die Standard-robots.txt von WordPress prüfen.
• Eine robots.txt einer Subdomain hat keine Auswirkungen auf die Hauptdomain. Sperrt man bspw. /test/ auf der Subdomain ist dieses Verzeichnis nicht auf der Hauptdomain gesperrt.
• Je Domain (inkl. Subdomain) muss eine separate robots.txt erstellt werden.
• Wenn man Seiten per 404 oder 410 aus dem Index entfernen möchte, muss man aufpassen, dass diese Seiten nicht gleichzeitig in der robots.txt gesperrt sind. Dann kann es passieren, dass Bots die Status Codes aufgrund der Sperrung nicht verarbeiten können.
• Sollte man Änderungen in der robots.txt vornehmen, dann muss man beachten, dass die Änderungen nicht sofort greifen. Google hält die robots.txt ca. 1 Tag im Cache. Um die Verarbeitung der Änderungen zu beschleunigen, kann die robots.txt in der Google Search Console neu eingereicht werden.