Die Robots.txt

Die Robots.txt steuert, was (gutartige) Bots auf Deiner Webseite tun dürfen und was nicht. In der SEO-Steinzeit diente die Robots.txt umfangreich zur Steuerung von Suchmaschinen und zur De-Indexierung von Inhalten. Heute ist die Welt komplexer.

Was ist die Robots.txt?

Die Robots.txt ist eine kleine Text-Datei, die im Hauptverzeichnis (=Root) einer Subdomain liegt. Sie definiert, was Bots (nicht nur Suchmaschinen) auf Deiner Webseite dürfen und was nicht. Diese Erlaubnis kannst Du für jeden Bot einzeln vornehmen oder für alle zusammen. Aber: Die Robots.txt ist keine technische Sperrvorrichtung. Das bedeutet, dass die Einstellungen nur für Bots wirken, die sich an die Robots.txt halten. Hacker, Mail-Adressen-Scraper und Content-Diebe lassen sich durch eine Robots.txt-Einstellung nicht aufhalten.

Das ganze Verfahren Robots.txt basiert auf einer Spezifikation von einer Gruppe um Martijn Koster aus dem Jahr 1994. Das Dokument ist ein De-Facto-Standard. Ob und wie das Protokoll von einem Bot implementiert wird, ist abhängig vom Betreiber des Bots. Google, Yahoo und Microsoft haben aber 2008 einige Gemeinsamkeiten der Interpretation veröffentlicht, an die sie sich halten wollen. Die Robots.txt ist damit Teil des „Robots Exclusion Protokolls”, das weitere Themen wie Meta-Robots-, X-Robots-Angaben, Sitemaps und Weiteres umfasst.

Inhalt des Artikels:

Muss ich eine Robots.txt haben?
Wie sollte ein SEO mit der Robots.txt umgehen?
Wie ist die Robots.txt spezifiziert?
Pfadangaben für Disallow
Anweisungen in der Robots.txt
Yandex-spezifische Angaben
Wildcards in der Robots.txt
Robots.txt und Indexierung
Robots.txt testen
Fallstricke und häufige Fehler
Trivia und FunFacts
WrapUP und Zusammenfassung

Muss ich eine Robots.txt haben?

Nein. Ist keine Robots.txt vorhanden, werden Bots davon ausgehen, dass sie alle URLs auf Deiner Protokoll-, Subdomain- oder Domain-Kombination crawlen dürfen. Möchtest Du allerdings Bots aktiv steuern, dann kannst Du unter Umständen eine Robots.txt-Datei dazu verwenden.

Wie sollte ein SEO mit der Robots.txt umgehen?

Nutze den Standardeintrag

Für 99% aller Webseiten ist der „Standard-Eintrag” ausreichend und sinnvoll: Standardeintrag der robots.txt:

User-Agent: *
Disallow: 
Sitemap: https://wngmn.de/sitemap.xml

Manche verwenden auch:

User-Agent: * 
Allow: / 
Sitemap: https://wngmn.de/sitemap.xml

Dieser Eintrag erlaubt es Crawlern, grundsätzlich auf alle Ressourcen Deiner Domain zuzugreifen. Fragen der De-Indexierung werden auf Seitenebene beispielsweise mit der Meta-Robots-Angabe gelöst. Wichtig beim Standardeintrag: Schreibe entweder: Allow: /(mit "/") oder Disallow: (ohne „/”), sonst wird der Crawler-Zugriff auf alle Inhalte Deiner Domain gesperrt. Mehr dazu findest Du bei Interesse im Abschnitt Format der Robots.txt.

Gründe für weitere Einträge in der Robots.txt

Es kann Fälle geben, in denen ein Robots.txt-Standard-Eintrag nicht ausreichend ist. Hauptgründe sind meist:

Crawling-Probleme: Suchmaschinen verlaufen sich aus diversen Gründen in Seitenbereichen, in denen wenig wertvolle Inhalte stecken und ignorieren wichtige Seitenbestandteile. Wenn Du dieses Problem nicht auf vernünftige Weise gelöst bekommst, dann kann ein Eintrag in der Robots.txt provisorisch hilfreich sein. (Eine vernünftige Lösung bestünde aus: Korrektur der internen Verlinkung + Meta-Robots/X-Robots Noindex,Follow, sofern die Seiten nicht komplett gelöscht werden können)
Effizienz-Gründe: Du musst schnell und temporär reagieren. Dann kann ein Eintrag in die Robots.txt eine effiziente Übergangslösung sein.
Ein Crawler ist zwar gutartig, erzeugt aber zu viel Last und Du möchtest ihm den Zugriff auf Deine Seite (teilweise) verwehren oder nur gezielt erlauben – wenn es sich nicht um einen Suchmaschinenbot handelt.
Tracking- oder Werbepixel, die auf einer (Sub)Domain in Deiner Verantwortung gehostet werden und bei denen ein Crawler-Zugriff die Erfassung korrekter Werte erschwert.

Die Robots.txt ist aber nie eine grundsätzliche Lösung eines Problems, sondern kann nur in Ausnahmefällen Symptome lindern.

Keine Gründe für weitere Einträge in der Robots.txt

Häufig wird die Robots.txt aber aus Motiven verwendet, die negative und unbeabsichtigte Nebeneffekte haben können. Aus unserer Sicht sind diese Motive nicht geeignet, um einen Eintrag in der Robots.txt zu begründen:

De-Indexierung von Inhalten mit Disallow: – sie funktioniert einfach nicht. Im Gegenteil. Du machst interessierte Nutzer in einer zentralen Datei aufmerksam auf die Inhalte, die Du eigentlich verbergen willst. (Shortcut: Mehr Infos zur Nutzung von noindex in der robots.txt.)
Cloaking: Cloaking ist grundsätzlich keine gute Idee. Die JavaScript-Dateien, mit denen Du das Cloaking betreibst, werden zwar nicht mehr regulär mitgecrawlt, aber das heißt noch lange nicht, dass Google sie nicht finden kann.
Sperrung von Seitenbereichen: Wenn Du beispielsweise Deine interne Suche oder paginierte Seiten über die Robots.txt sperrst, dann kann Google nicht darauf zugreifen. Aber: Links, die dorthin zeigen, werden auch keinen PageRank vererben und die Inhalte können trotzdem in der Suche auftauchen. (Shortcut: Crawl-Verbot vs. Indexierungs-Verbot)

Wie ist die Robots.txt spezifiziert?

Dateipfad

Die Datei muss immer im Root einer Subdomain-/Domain-Konstellation liegen und gilt dann für alle Pfade unterhalb dieses Roots.  Der Dateiname Robots.txt wird immer komplett klein geschrieben: „robots.txt”. Verwendest Du andere Zeichen, werden Bots die Datei nicht finden und sie kann nicht wirken. Ein paar schöne Beispiele für valide Pfade hat Google hier aufgeführt: Beispiele für gültige robots.txt-URLs

Robots.txt und HTTP vs. HTTPS

In den Beispielen fehlt allerdings der Hinweis, dass auch das Protokoll mit dazu gehört. Ich kann also für HTTP und HTTPs jeweils eine eigene Robots.txt definieren.

Format der Robots.txt

Zurück zum technischen Aufbau der Robots.txt. Wir haben oben schon ein Beispiel gesehen.

Struktur

Grundsätzlich folgt die Robots.txt immer folgender Struktur:

User-Agent: [user-agent] # Beispiel: User-Agent: [Googlebot] 
Disallow: [pfad1] # Beispiel: /admin/ 
Disallow: [pfad2]` # Beispiel: .js

Damit wird spezifiziert, dass für den User-Agent (=Name des Bots, etwa Googlebot oder Bingbot) [user-agent] die Dateipfade [pfad1] und [pfad2] nicht für den Zugriff erlaubt sind. Möchte ich alle User-Agents adressieren, dann ist User-Agent: eine Wildcard, die alle User-Agents einschließt.

Datei-Codierung

Die Datei sollte utf-8 codiert sein und nur Text enthalten. Robots.txt-Dateien mit HTML-Code werden nicht verlässlich funktionieren. Sollten in der HTML-Datei die Anweisungen in korrekten Zeilen und Zeilenblöcken stehen, können sie trotzdem Berücksichtigung finden.

Größe der Robots.txt-Datei

Die Datei sollte nicht zu groß werden. Google beispielsweise verarbeitet nur die ersten 500KB und ignoriert den Rest von Robots.txt-Dateien, die größer sind. Dieses Limit solltest Du üblicherweise nicht im Ansatz erreichen. Solltest Du aber jede einzelne URL in Deiner Robots.txt referenzieren oder auf umfangreiche ASCII-Art setzen, könntest Du Probleme mit dem Dateigrößenlimit bekommen.

Kommentare in der Robots.txt

Möchtest Du Einträge mit Kommentaren versehen, um Dich oder Deine Kollegen daran zu erinnern, was mit einer Zeile beabsichtigt ist, dann kannst Du „#” verwenden. Alles hinter „#” bis zum Ende der Zeile wird als Kommentar gewertet.

User-Agent: Googlebot 
# Spezifische Anweisungen für Googlebot 
Disallow: 
# Das Verbot von „nichts" führt zur Erlaubnis von „allem"

oder:

# Spezifische Anweisungen für Googlebot 
User-Agent: Googlebot 
# Das Verbot von „nichts" führt zur Erlaubnis von „allem" 
Disallow:

Vorsicht vor Leerzeilen

Anweisungen für einen User-Agent müssen in einem Block stehen. Wenn Du Leerzeilen einfügst, besteht die Gefahr, dass Bots die Anweisungen ignorieren.

User-Agent: Googlebot 
Disallow: /verboten/ 
Allow: /verboten/erlaubt/

Das Beispiel kann dazu führen, dass die Inhalte unter /verboten/erlaubt/ nicht gecrawlt werden dürfen, da durch die Leerzeile die Allow-Anweisung ignoriert wird. Google ist hier aber relativ fehlertolerant. Übrigens: Das Leerzeichen hinter den Doppelpunkten ist optional. Sowohl User-Agent: * als auch User-Agent:* sind korrekt.

User-Agents

Die Angabe von User-Agent: [User-Agent] leitet immer einen neuen Block Anweisungen ein. Die Reihenfolge der User-Agents ist irrelevant. Spezifische Regelungen für einen User-Agent überschreiben allerdings allgemeine Anweisungen:

User-Agent: * 
Disallow: 
#erlaubt allen Bots auf alle Inhalte zuzugreifen 

User-Agent: Googlebot 
Disallow: / 
#verbietet aber Googlebot den Zugriff auf alle Inhalte

Das Überschreiben allgemeiner Anweisungen gilt beispielsweise auch für Bots, die eigentlich zu einer Klasse gehören:

User-Agent: Googlebot 
Disallow: 
#erlaubt allen Googlebots auf alle Inhalte zuzugreifen

User-Agent: Googlebot-News 
Disallow: / 
#verbietet aber dem News-Bot von Google den Zugriff auf alle Inhalte

Beim Überschreiben von Angaben werden nicht einzelne Angaben überschrieben, sondern immer ganze Blöcke. Das bedeutet im Beispiel oben, dass der News-Bot alle Anweisungen, die allgemein für Googlebots gelten sollen, ignorieren wird.

Pfadangaben für Disallow

Pfadangaben sind relativ

Hinter einer Disallow--Angabe wird der Pfad angegeben, für den diese Anweisungen gelten. Der Pfad wird dabei immer relativ zum Root gesehen, unter dem die Robots.txt liegt. Der Root umfasst Protokoll (HTTP/HTTPs), Subdomain (www./stage.), Domain inkl. TLD (wngmn.de/google.com) sowie eventuell einen Port. Liegt die Robots.txt also unter http://wngmn.de/robots.txt, gelten alle Pfadangaben für HTTP-URLs. Liegt die Robots.txt unter https://wngmn.de, gelten alle Angaben für HTTPS-URLs. Solltest Du also Teile Deiner Seite noch unter HTTP betreiben oder mehrere Subdomains haben, dann achte darauf, dass möglicherweise jedes Protokoll und jede Subdomain eine eigene, spezifische Robots.txt benötigt. Die Angabe eines Pfades beginnt immer mit einem „/”, auch wenn beispielsweise Google hierbei fehlertolerant ist und den „/” im Zweifel für Dich einsetzt.

User-Agent: * 
Disallow: /verboten/ 
#Sperrt alle Dateien im Ordner „verboten“ 

Disallow: verboten/ 
#Wird von Google zu /verboten/ erweitert und ist äquivalent zur vorherigen Angabe.

Bots interpretieren die Angaben weiträumig

Bots gehen immer davon aus, dass hinter Deiner Angabe noch etwas kommen kann. Gibst Du also:

User-Agent: * 
Disallow: /verboten 
#Sperrt alle Dateien im Ordner „verboten"

und alle Dateien im Root, die mit verboten beginnen an, dann werden nicht nur alle Dateien im Ordner „verboten” gesperrt, sondern auch alle Dateien in „verboten2”. Zusätzlich wird auch die „/verboten.txt”, „verboten123.html” oder jede andere Datei im Root, die mit „verboten” beginnt, gesperrt. Dieses Verhalten kannst Du mit „$” beeinflussen. Mehr dazu im Abschnitt Wildcards.

Groß- und Kleinschreibung

Bei Pfadangaben wird zwischen Groß- und Kleinschreibung unterschieden. /Verboten/ sperrt also andere Pfade als /verboten/. /verboten/ sperrt aber auch alle URLs mit Großbuchstaben unterhalb dieses Ordners, beispielsweise /verboten/Verboten.html. Randnotiz: Grundsätzlich ist es eine gute Idee, alle Deine Pfade klein zu schreiben und Varianten mit Großbuchstaben immer auf die Kleinschreibung weiterzuleiten (301!).

Ausnahme: Pfadangabe bei „Sitemap”

Bei der Referenzierung von Sitemaps ist immer eine voll qualifizierte URL mit Protokoll und Domain zu referenzieren:  https://wngmn.de/sitemap.xml oder http://www.wngmn.de/sitemap.xml . Grund dafür ist, dass Du grundsätzlich auch Sitemaps auf einer anderen Domain referenzieren kannst. Mehr dazu in unserem Wissensartikel zu HTML- und XML-Sitemaps für SEOs.

Reihenfolge von Pfadangaben

Die Reihenfolge von Pfadangaben ist grundsätzlich irrelevant. Allerdings überschreiben auch hier spezifische Angaben die allgemeinen Anweisungen.  Definierst Du beispielsweise:

Disallow: /verboten 
Allow: /verboten/

so wird /verboten.html/ nicht gecrawlt, alle Dateien unterhalb von /verboten/ (beispielsweise /verboten/verboten.html) allerdings schon.

Widersprüche in Pfadangaben

Du kannst Widersprüche in Pfaden erzeugen:

Disallow: /verboten/ 
Allow: /verboten/

ist nicht definiert. Du kannst davon ausgehen, dass Suchmaschinen die URLs im Zweifel crawlen werden. Auch mit Wildcards kannst Du Widersprüche erzeugen.

Disallow: /verboten/ 
Allow: /*.html

wird dazu führen, dass /verboten/verboten.html mit hoher Wahrscheinlichkeit dennoch gecrawlt wird.

Anweisungen in der Robots.txt

Es gibt verschiedene Anweisungen, die ich in Robots.txt vornehmen kann. Für Anweisungen ist die Groß- und Kleinschreibung irrelevant. Disallow, DisAllow, disallow und disAllow oder DISALLOW sind also äquivalent (im Gegensatz zu Verwendung von Groß- und Kleinschreibung in Pfadangaben).

Disallow:

Am Weitesten verbreitet ist mit Sicherheit „Disallow”. Mit Disallow werden URLs vom Crawler-Zugriff ausgeschlossen.  Du kannst spezifische URLs oder bestimmte URL-Muster ausschließen. Innerhalb von Ausschlüssen kann mit „Allow” wiederum eine Ausnahme vorgenommen werden. Wichtig: Disallow verbietet den Zugriff für den Crawler, aber nicht die Indexierung.

Noindex:

Noindex ist relativ wenig bekannt und wird offiziell auch nicht von Google unterstützt. John Müller rät aktiv von einer Verwendung ab. https://twitter.com/JohnMu/status/638644112359604224 Bis 01/2018 haben wir damit teilweise in Fällen, bei denen es schnell gehen musste oder andere Möglichkeiten nicht zur Verfügung standen, dazu geraten haben. Eine langfristige und solide Lösung ist Noindex in der Robots.txt nie gewesen. Seit 01/2018 scheint Google diese Konfiguration überhaupt nicht mehr zu beachten. Die Ergebnisse waren immer durchwachsen (andere Suchmaschinen berücksichtigen die Angabe grundsätzlich nicht).

Sitemaps:

„Sitemaps:” ist eine Anweisung, die sich im Gegensatz zu Noindex oder Disallow/Allow nicht an einen speziellen Bot richtet. Wie der Name sagt, wird es mit diesem Befehl möglich, eine (Index-)Sitemap anzugeben. Damit kann das Anmelden der Sitemap in der Google Search Console oder den Bing Webmaster Tools entfallen. Mehr dazu haben wir in unserem Wissensartikel über Sitemaps für SEOs zusammengeschrieben. Manch einer scheut davor zurück, dadurch seine Sitemaps auch Konkurrenten und Scrapern offenzulegen. Aber wer Deine Sitemaps finden möchte, der wird sie auch ohne die Referenzierung in der Robots.txt finden.

Crawl-Delay:

Crawl-Delay ist eine Angabe, mit der Du in der Vergangenheit Bots anweisen konntest, zwischen zwei Requests eine bestimmte Anzahl von Sekunden abzuwarten und so den Bot zu drosseln, um den Webserver vor Überlastung zu schützen. Heutzutage ist diese Angabe in den allermeisten Fällen obsolet, denn:

Dein Webserver sollte diese Last in jedem Fall aushalten.
Falls nicht, ist eine Konfiguration in der Google Search Console oder den Bing Webmaster Tools der effizientere Ansatz.

Dennoch halten sich Bing, Yandex und Yahoo weiterhin an die Direktive. Möchtest Du Crawl-Delay dennoch implementieren, dann sollte es etwa so aussehen: User-Agent: * Crawl-Delay: 1 Achtung: Du kannst das Crawl-Delay nicht für einzelne Ordner oder Dateien definieren. Du kannst aber für Protokoll-/Host-Kombinationen entsprechend das Crawling reduzieren. Wenn Du beispielsweise auf einer Subdomain eine Whitelabel-Integration eines Branchenbuchs oder Immobilienportals hättest, dann könnte es möglicherweise sinnvoll sein, hier mit dem Crawl-Delay Suchmaschinen anzuregen, eher Deine Haupt-Domain zu crawlen. Wenn die Inhalte allerdings nicht relevant sind, dann solltest Du Dir auch nochmal neu die Frage stellen, ob Du die Inhalte überhaupt noch brauchst oder ob sie überhaupt gecrawlt werden sollten. Vorsicht übrigens auch beim Setzen des Delays. Ein Delay von einer Sekunde bedeutet bei einer durchschnittlichen Downloadzeit eines Dokuments von Deinem Server von 300ms, dass alle 1,3 Sekunden eine URL gecrawlt werden kann. Das wären „nur“ 66.462 URL-Crawls am Tag. Bei einer schlechten Steuerung des Bots könnte es sein, dass hier weniger als 10.000 URLs am Tag gecrawlt werden.

[table id=4/]

Für kleine Domains mag das nach hohen Limits erscheinen. In der Praxis sollten es für kleine Domains aber auch keinerlei Notwendigkeit geben, diesen Wert zu setzen. Bei großen Domains kommen solche Werte relativ schnell einem De-Facto-Disallow gleich.

Yandex-spezifische Angaben

Host:

Yandex unterstützt auch eine Angabe von Host: Damit kannst Du eine andere Subdomain/Domain angeben, die vordringlich verarbeitet werden sollte. Beispiel: https://www.wngmn.de/robots.txt User-Agent: YandexBot Host: wngmn.de Das weist Yandex an, „wngmn.de” höher zu priorisieren als „www.wngmn.de”. Es ist aber sinnvoll, das Problem bei der Wurzel zu packen und auf „ein Inhalt, eine URL” zu setzen und den Duplicate Content wirklich zu beheben, anstatt auf ein solches Workaround zu setzen, das dann auch nur bei Yandex berücksichtigt wird.

Clean-Param:

Außerdem unterstützt Yandex eine Angabe von Parametern, die ignoriert oder normalisiert werden sollen (ähnlich der Parameter-Konfiguration in der Google Search Console oder in den Bings Webmaster Tools): Hier kannst Du mehr über Yandex-Robots.txt erfahren

Feature Support nach Crawler

[table id=5/]

Wildcards in der Robots.txt

Das „*“-Zeichen

Grundsätzlich matchen Pfade in der Robots.txt auf Teilstrings. Das bedeutet, dass /verboten auch /verboten2 mit einschließt. Häufig reicht eine reine Einstellung des Pfades nicht aus. Wenn Du etwa alle XML-Dateien vom Crawling ausschließen möchtest (Achtung: XML-Sitemaps sollen eigentlich immer gecrawlt werden), dann kannst Du folgende Angabe verwenden:

User-Agent: * 
Disallow: /*.xml

Damit wird Google alle URLs, die auf der Domain der Robots.txt liegen und „.xml” enthalten, vom Crawling ausschließen. Aber Vorsicht: Referenzierst Du /*.xml, werden beispielsweise auch /sitemap.xml2 oder /allesüber.xml_dateien.html vom Crawling ausgeschlossen.

Das „$”-Zeichen

Daher solltest Du bei Datei-Endungs-Wildcards immer den Punkt mit referenzieren und zusätzlich das „$”-Zeichen verwenden.

User-Agent: * 
Disallow: /*.xml$

Das „$”-Zeichen gibt an, dass der referenzierte Pfad an dieser Stelle endet und die Anweisung nicht für Pfade gilt, bei denen nach „.xml” noch etwas folgt. /sitemap.xml2 dürfte in diesem Beispiel gecrawlt werden.

Wildcards in User-Agent-Angaben

Wildcards werden auch in User-Agent-Angaben berücksichtigt. Sowohl User-Agent: Googlebot als auch User-Agent: Google* werden funktionieren. Die zweite Anweisung wird aber beispielsweise auch die User-Agents Googlebot-News einschließen.

Robots.txt und Indexierung

Wichtig: Eine Robots.txt verbietet Suchmaschinen lediglich das Crawling, nicht die Indexierung. Findet Google viele Links zu einer URL, die über die Robots.txt gesperrt ist, dann kann diese URL Nutzern in der Suche dennoch angezeigt werden.  Als Title wird dabei häufig der häufigste Linktext verwendet.

Als Description zeigte Google dann (früher) an: "Die Datei „robots.txt" auf dieser Website lässt nicht zu, dass eine Beschreibung für das Suchergebnis angezeigt wird". Heute sieht das Snippet so aus: "Für diese Seite sind keine Informationen verfügbar. Weitere Informationen" Das Ergebnis einer blockierten URL kann auch Site-Links enthalten: Auch Bing indexiert Dateien, die vom Crawling ausgeschlossen sind. Möchtest Du einen Inhalt aus der Anzeige in der Suche ausschließen, so ist die Angabe "noindex" im Bereich des HTMLs der jeweiligen URL der richtige Weg. Damit Google diese Noindex-Angabe allerdings auslesen kann, ist es wichtig, dass Du das Crawling dieser URL über die Robots.txt erlaubst.

Robots.txt und Links

Ebenfalls wichtig: Eine Datei, die in der Robots.txt gesperrt ist, kann zwar indexiert werden, da der Bot aber nicht auf sie zugreifen darf, wird sie keinen Beitrag zur internen Verlinkung leisten. Auch externe Links, die auf Seiten liegen, die von einer Robots.txt gesperrt wurden, sind aus SEO-Sicht wertlos.

Robots.txt und Caching

Um nicht bei jedem Datei-Aufruf die Robots.txt zusätzlich abzufragen, werden die meisten Bots die Robots.txt cachen. In aller Regel wird ein Abbild der Robots.txt für 24 Stunden gespeichert und dann erst geprüft, ob sich Änderungen ergeben haben. Über den HTTP-Cache-Control-Header max-age kannst Du den Bot allerdings dazu auffordern, die Datei häufiger zu crawlen.

Robots.txt testen

Google Search Console Robots.txt-Tester

Die Google Search Console stellt einen robots.txt-Tester bereit. Ein Feature, das oft übersehen wird, aber einen hohen Mehrwert hat: Immer, wenn Google eine Änderung Deiner Robots.txt feststellt, bekommst Du auch die Möglichkeit, in der Search Console diese Änderung mit Datum nachzustellen.

Ryte.com Robots.txt-Tester

Auch Ryte.com (ehemals Onpage) stellt einen Robots.txt-Tester zur Verfügung, der es im Gegensatz zum Google Search Console-Tester auch ermöglicht, unterschiedliche User-Agents zu testen: Kostenfreier Tester von Ryte

Crawling mit Screaming-Frog

Du kannst den Screaming-Frog anweisen, die Robots.txt zu ignorieren. Es ist bei komplexeren Robots.txts durchaus sinnvoll, den Crawl einmal mit Berücksichtigung der Robots.txt und einmal ohne durchzuführen, um zu schauen, welche Unterschiede es gibt und ob die Robots.txt so wirkt, wie Du Dir das vorstellst.

Eigenen Validator programmieren

Grundsätzlich gibt es die Möglichkeit, sich einen Validator selbst zu schreiben – das ist aufgrund des überschaubaren Regelsets nicht übermäßig komplex. Wir haben allerdings beispielsweise mit reppy für python von moz.com gute Erfahrungen im Produktiveinsatz gemacht.

Fallstricke und häufige Fehler

Vier Fehler finden wir häufig:

Den Versuch, Dateien über die Robots.txt mit Disallow: zu de-indexieren
Widersprüche in den Pfadangaben
Zu weitreichende Pfadangaben durch Substring-Matching und Wildcards
Fehlerhafte Konfiguration der Robots.txt durch falsch gesetzte Leerzeichen

Trivia und FunFacts

Schau Dir Robots.txts an, beispielsweise von Foren oder News-Publishern. In vielen dieser Robots.txts wirst Du Hinweise auf URLs finden, die der Seitenbetreiber eigentlich vor Nutzern verstecken möchte.
Du kannst die Robots.txt in der Robots.txt vom Crawling ausschließen. Das wirkt aber nur 24 Stunden, da dann die Robots.txt in aller Regel neu abgefragt wird.
Alec Bertram hat sich ein richtiges HTML-Dokument in die Kommentare gebaut und die Robots.txt ist weiter valide: https://awebsiteinsidemy.com/robots.txt.
"Just crawl it"

WrapUP und Zusammenfassung

Du brauchst keine Robots.txt – in aller Regel ist der Standard-Eintrag ausreichend.
Achte darauf, dass Deine Robots.txt semantisch korrekt aufgebaut ist.
Vorsicht vor Substring-Matching und Wildcards. Hier könnten versehentlich Dateien gesperrt werden, die nicht gesperrt werden sollen.
Die Robots.txt ist kein geeignetes Instrument zur De-Indexierung von Inhalten, da sie nur den Crawler-Zugriff, nicht aber die Indexierung steuert.

Changelog

05.07.2018: Abschnitt zu Noindex in Robots.txt aktualisiert und präzisiert. Zuvor hatten wir berichtet, dass wir in Einzelfällen gute Erfahrungen gemacht haben. Seit 01/2018 lassen sich diese Ergebnisse in unseren Tests nicht mehr reproduzieren.

Hat Dir der Artikel gefallen?

Neue Artikel, Updates zu unseren Artikeln und Artikel von anderen Stellen wir regelmäßig unserem Newsletter.

Beispielausgaben und Anmeldung findest Du unter Wingmen-Newsletter