So lesen Sie eine robots.txt-Datei: Ein umfassender Leitfaden

Unsere Position: Wir sind Geonode und verkaufen Proxys an Personen, die Daten sammeln, sodass robots.txt direkt im Mittelpunkt der Arbeit unserer Kunden steht. Ehrlich gesagt liegt es in Ihrem Interesse, diese Datei zu beachten – nicht nur im Interesse der Website. Ein Crawler, der die Datei respektiert, sich identifiziert und sein Tempo anpasst, ist einer, den Website-Betreiber zulassen können. Ein Crawler, der sie ignoriert, ist ein Störfaktor, der blockiert werden muss – und das Blockieren ist für sie kostengünstig, für Sie jedoch teuer. Wir möchten auch klarstellen, was der Standard selbst zu diesem Thema sagt: Der RFC besagt eindeutig, dass diese Regeln „keine Form der Zugriffsberechtigung darstellen“ – die Einhaltung von robots.txt ist also notwendig, aber nicht ausreichend, und die Nutzungsbedingungen sind eine separate Frage.

Was „robots.txt“ ist und was nicht

Die Formulierung im RFC selbst ist am eindeutigsten:

Es kann für Betreiber von Diensten unerwünscht sein, wenn Crawler ihren gesamten URI-Raum durchsuchen. Dieses Dokument legt die ursprünglich im „Robots Exclusion Protocol“ definierten Regeln fest, an die sich Crawler beim Zugriff auf URIs halten sollen.

Diese Regeln stellen keine Form der Zugriffsberechtigung dar.

Dieser letzte Satz erfüllt eine doppelte Funktion. Er bedeutet zum einen, dass ein unzulässiger Pfad nicht geschützt ist – nichts setzt die Regel durch –, und zum anderen, dass ein zulässiger Pfad dadurch nicht autorisiert ist, da die Berechtigung sich aus Vertragsbedingungen und Gesetzen ergibt und nicht aus einer Textdatei.

Der Abschnitt zur Sicherheit macht die erste Hälfte explizit und ist es wert, zitiert zu werden, da so viele Menschen dies falsch verstehen:

Das Robots Exclusion Protocol ist kein Ersatz für gültige Maßnahmen zur Inhaltssicherheit. Das Auflisten von Pfaden in der robots.txt-Datei macht diese öffentlich sichtbar und somit auffindbar.

Disallow: /admin/secret-reports/ teilt also der Welt mit, dass dieser Pfad existiert. Wenn Sie eine „robots.txt“-Datei erstellen, ist dies ein Argument dafür, sensible Pfade dort überhaupt nicht aufzuführen – nutzen Sie stattdessen die Authentifizierung, die der RFC ausdrücklich empfiehlt.

Das Format

Eine Datei besteht aus einer Abfolge von Gruppen. Jede Gruppe beginnt mit einer oder mehreren Zeilen mit dem Befehl „user-agent“ und wird von Regeln gefolgt.

User-agent: *
Disallow: /admin/
Disallow: /search?
Allow: /search/help

User-agent: BadBot
Disallow: /

Sitemap: https://example.com/sitemap.xml

Drei Sonderzeichen, die Crawler UNBEDINGT unterstützen MÜSSEN:

Eine leere Gruppe am Ende hat eine bestimmte Bedeutung: Im RFC heißt es, dass „die letzte Gruppe keine Regeln enthalten darf, was bedeutet, dass sie implizit alles zulässt“. Ein abschließendes „User-agent: quxbot“ ohne darunterliegende Elemente gewährt diesem Crawler also uneingeschränkten Zugriff.

Ein leeres „Disallow:“ ohne Pfad bedeutet ebenfalls, dass alles erlaubt ist – dies ist die übliche Art, „keine Einschränkungen“ auszudrücken. „

Sitemap:“ ist nicht Teil der Kerngrammatik. Die ABNF im RFC enthält einen Hinweis an Implementierer, „zusätzliche Zeilen zu definieren, die Sie benötigen (zum Beispiel Sitemaps)“, es handelt sich also eher um eine weit verbreitete Erweiterung als um eine erforderliche Funktion. Crawl-delay fällt in dieselbe Kategorie: weit verbreitet, von vielen Crawlern unterstützt und nicht im Standard enthalten.

So funktioniert der User-Agent-Abgleich

Präziser als die meisten Menschen annehmen – und es lohnt sich, dies richtig zu verstehen.

Das Token ist eine Teilzeichenfolge Ihres User-Agent-Headers. Das Beispiel aus dem RFC: Ein Header von Mozilla/5.0 (compatible; ExampleBot/0.1; https://www.example.com/bot.html) entspricht einer Zeile „robots.txt“ von user-agent: ExampleBot, und es wird darauf hingewiesen, dass „das Produkt-Token (ExampleBot) eine Teilzeichenfolge des User-Agent-HTTP-Headers ist“.

Beim Abgleich wird die Groß-/Kleinschreibung nicht berücksichtigt. „Crawler MÜSSEN einen Abgleich ohne Berücksichtigung der Groß-/Kleinschreibung verwenden, um die Gruppe zu finden, die mit dem Produkt-Token übereinstimmt, und dann die Regeln dieser Gruppe befolgen.“

Mehrere übereinstimmende Gruppen werden zusammengeführt. „Wenn es mehr als eine Gruppe gibt, die mit dem User-Agent übereinstimmt, MÜSSEN die Regeln der übereinstimmenden Gruppen zu einer einzigen Gruppe zusammengefasst werden.“ Zwei separate „User-agent: ExampleBot“-Blöcke in derselben Datei ergeben also einen kombinierten Regelsatz, anstatt dass der zweite den ersten überschreibt.

Man erhält eine Gruppe, nicht mehrere. Wenn eine Gruppe Ihr Token nennt, verwenden Sie diese Gruppe und ignorieren die „*“-Gruppe vollständig – der Platzhalter dient als Ausweichlösung, nicht als Grundlage, auf der spezifische Regeln aufbauen. Das überrascht viele: Ein Crawler mit eigener Gruppe unterliegt nicht zusätzlich den allgemeinen Regeln.

Und wenn überhaupt nichts passt: „Wenn keine Gruppe mit dem Produkt-Token übereinstimmt und es keine Gruppe mit einer User-Agent-Zeile mit dem Wert * gibt oder gar keine Gruppen vorhanden sind, gelten keine Regeln.“

Der Abgleich erfolgt nach Spezifität, nicht nach Reihenfolge

Die am häufigsten falsch dargestellte Regel in diesem gesamten Bereich.

Um zu prüfen, ob der Zugriff auf eine URI erlaubt ist, MUSS ein Crawler die Pfade in den „allow“- und „disallow“-Regeln mit der URI abgleichen. Beim Abgleich SOLLTE die Groß-/Kleinschreibung beachtet werden. Der Abgleich MUSS mit dem ersten Oktett des Pfades beginnen. Die spezifischste gefundene Übereinstimmung MUSS verwendet werden. Die spezifischste Übereinstimmung ist diejenige, die die meisten Oktette umfasst.

Es gilt nicht: „Die erste Übereinstimmung gewinnt.“ Es gilt nicht: „Die letzte Übereinstimmung gewinnt.“ Die längste Übereinstimmung gewinnt.

Das Beispiel aus dem RFC selbst:

User-Agent: foobot
Allow: /example/page/
Disallow: /example/page/disallowed.gif

Für example.com/example/page/disallowed.gif ist die Zeile „Disallow“ länger, daher gilt sie – obwohl sie an zweiter Stelle steht und obwohl eine „Allow“-Regel den übergeordneten Pfad abdeckt.

Kehrt man die Reihenfolge in der Datei um, ändert sich nichts. Die Reihenfolge ist irrelevant.

Zwei weitere Regeln vervollständigen das Bild. Bei Gleichstand gilt „Allow“: „Wenn eine ‚allow‘-Regel und eine ‚disallow‘-Regel gleichwertig sind, SOLLTE die ‚allow‘-Regel verwendet werden.“ Und keine Übereinstimmung bedeutet Zulassung: „Wenn unter den Regeln einer Gruppe keine Übereinstimmung für einen passenden User-Agent gefunden wird oder keine Regeln in der Gruppe vorhanden sind, ist die URI zulässig.“

Noch ein wissenswertes Detail: „Die URI /robots.txt ist implizit erlaubt“, sodass eine Datei, die alles verbietet, sich selbst nicht verbietet.

Beim Pfadabgleich kommt es außerdem zur Normalisierung durch Prozentkodierung. Oktette außerhalb des ASCII-Zeichensatzes und solche im reservierten Bereich „MÜSSEN vor dem Vergleich prozentkodiert werden“, und ein prozentkodiertes ASCII-Oktett in der URI „MUSS vor dem Vergleich dekodiert werden“, sofern es nicht reserviert ist. In der Praxis: Verwenden Sie eine gepflegte Bibliothek, anstatt dies selbst zu programmieren.

Statuscodes verändern alles

Die Regeln hier sind präzise, werden jedoch häufig ignoriert, und der Unterschied zwischen zwei von ihnen ist groß.

Erfolg. „Wenn der Crawler die robots.txt-Datei erfolgreich herunterlädt, MUSS der Crawler die auswertbaren Regeln befolgen.“

Weiterleitungen. „Die Crawler SOLLTEN mindestens fünf aufeinanderfolgende Weiterleitungen verfolgen, auch über verschiedene Autoritäten hinweg.“ Eine Datei, die innerhalb von fünf Weiterleitungen erreicht wird, „MUSS abgerufen, analysiert und ihre Regeln im Kontext der ursprünglichen Autorität befolgt werden“. Bei mehr als fünf Weiterleitungen „DARF ein Crawler davon ausgehen, dass die robots.txt-Datei nicht verfügbar ist.“

Nicht verfügbar – 4xx. „Wenn ein Server-Statuscode anzeigt, dass die robots.txt-Datei für den Crawler nicht verfügbar ist, DARF der Crawler auf beliebige Ressourcen auf dem Server zugreifen.“ Ein 404-Code bedeutet, dass keine Einschränkungen bestehen.

Nicht erreichbar – 5xx. Dies ist der Punkt, den viele falsch verstehen: „Wenn die robots.txt-Datei aufgrund von Server- oder Netzwerkfehlern nicht erreichbar ist, bedeutet dies, dass die robots.txt-Datei undefiniert ist und der Crawler von einem vollständigen Zugriffsverbot ausgehen MUSS.“

Ein 5xx-Code bedeutet, vollständig anzuhalten. Nicht „wie bisher fortfahren“, nicht „die zwischengespeicherte Kopie auf unbestimmte Zeit verwenden“ – vollständiges Verbot. Der RFC lässt jedoch eine langfristige Ausnahmeregelung zu: Wenn die Datei „für einen angemessen langen Zeitraum (zum Beispiel 30 Tage)“ nicht definiert ist, DÜRFEN Crawler davon ausgehen, dass die robots.txt-Datei nicht verfügbar ist … oder weiterhin eine zwischengespeicherte Kopie verwenden.“

Parsing-Fehler. „Crawler MÜSSEN versuchen, jede Zeile der robots.txt-Datei zu parsen. Crawler MÜSSEN die parsbaren Regeln verwenden.“ Eine fehlerhaft formatierte Zeile macht die Datei nicht ungültig; man verwendet das, was man lesen kann.

Die praktische Konsequenz für jeden, der einen Crawler schreibt: Ein vorübergehender Ausfall auf der Zielseite sollte Ihren Crawl unterbrechen, nicht beschleunigen. Wenn man das verkehrt herum versteht, bedeutet das, eine Website zu überlasten, die ohnehin schon Probleme hat.

Zwischenspeicherung und Beschränkungen

Zwei betriebliche Anforderungen, an denen selbst entwickelte Implementierungen oft scheitern.

Mindestens einmal täglich aktualisieren. „Crawler DÜRFEN den Inhalt der abgerufenen robots.txt-Datei zwischenspeichern … Crawler SOLLTEN die zwischengespeicherte Version nicht länger als 24 Stunden verwenden, es sei denn, die robots.txt-Datei ist nicht erreichbar.“

Das einmalige Abrufen der Datei beim Start Ihres Crawlers und das Ausführen über eine Woche hinweg entspricht nicht den Vorgaben. Websites ändern ihre Regeln, und ein lang laufender Job muss dies erkennen.

Mindestens 500 KiB analysieren. „Das Parsing-Limit MUSS mindestens 500 Kibibyte betragen.“ Große Websites haben große Dateien, und ein Parser, der bei einer willkürlich festgelegten kleineren Größe abschneidet, übersieht stillschweigend Regeln – was hier der schlimmstmögliche Fehlerfall ist, da dadurch ein Crawler entsteht, der glaubt, konform zu sein, es aber nicht ist.

Eine echte Datei lesen

Ein realistisches Beispiel durcharbeiten.

User-agent: *
Disallow: /search
Allow: /search/about
Disallow: /*?sessionid=
Disallow: /*.pdf$
Crawl-delay: 2

User-agent: GPTBot
Disallow: /

User-agent: PartnerBot
Disallow:

Sitemap: https://example.com/sitemap_index.xml

Zeile für Zeile:

**Disallow: /search

** blockiert /search

, /search/

, /search/results

– alles, was mit dieser Zeichenfolge beginnt, da der Abgleich beim ersten Oktett beginnt und es kein „$

“ gibt.

**Allow: /search/about

** ist länger und hat daher bei diesem konkreten Pfad Vorrang. Es kommt auf die längste Übereinstimmung an, nicht auf die Reihenfolge.

**Disallow: /*?sessionid=

** nutzt den Platzhalter, um jeden Pfad zu blockieren, der einen Sitzungsparameter enthält, unabhängig davon, was davor steht.

**Disallow: /*.pdf$

** blockiert URLs, die auf .pdf

enden. Ohne das $

würde es auch /report.pdf.html

blockieren.

**Crawl-delay: 2

** ist eher eine Erweiterung als ein Standard, und es ist empfehlenswert, diese zu berücksichtigen.

**User-agent: GPTBot

mit Disallow: /

** schließt diesen Crawler vollständig aus. Beachten Sie, dass GPTBot nur diese Regel erhält – er unterliegt nicht zusätzlich der Gruppe „*

“, sodass die oben genannte Regel Crawl-delay

für ihn nicht gilt.

**User-agent: PartnerBot

mit einem leeren „Disallow:

“** gewährt uneingeschränkten Zugriff.

**Sitemap:

** verweist auf das URL-Verzeichnis, was in den meisten Dateien die unmittelbar nützlichste Zeile ist. Wie man damit umgeht, haben wir unter So finden Sie alle Seiten einer Website behandelt.

Dies im Code berücksichtigen

Verwenden Sie einen gepflegten Parser. Allein die Regel zum Abgleich der Spezifität ist eine häufige Fehlerquelle, und die Normalisierung durch Prozent-Kodierung ist noch problematischer.

Python: „urllib.robotparser“ ist in der Standardbibliothek enthalten und für einfache Fälle ausreichend; Googles Open-Source-Parser „robotstxt“ und dessen Python-Bindings setzen RFC 9309 präzise um. Scrapy verfügt über „RobotsTxtMiddleware“, das in neuen Projekten standardmäßig integriert und aktiviert ist – stellen Sie sicher, dass niemand es deaktiviert hat.

Node: Es gibt mehrere gepflegte Pakete, die den Standard implementieren.

Go: Es gibt Bibliotheken, die den Abgleichregeln des RFC folgen.

Egal, was Sie verwenden, beachten Sie diese vier Punkte:

Aktualisieren Sie alle 24 Stunden, nicht nur einmal beim Start. Behandeln Sie 5xx-Fehler als vollständiges Verbot und 404-Fehler als keine Einschränkungen. Führen Sie den Abgleich anhand Ihres tatsächlichen Produkt-Tokens durch und stellen Sie sicher, dass Ihr User-Agent-Header dieses enthält. Verfolgen Sie bis zu fünf Weiterleitungen und wenden Sie die Regeln im Kontext des ursprünglichen Hosts an.

Und ein fünfter Punkt, der zwar nicht im RFC steht, aber ebenso wichtig ist: Protokollieren Sie, was Sie übersprungen haben. Ein Crawler, der stillschweigend die Hälfte einer Website aufgrund einer unerwarteten Regel ausschließt, ist ein Crawler, bei dem die fehlenden Daten erst Wochen später entdeckt werden, wenn jemand fragt, warum ein Bericht falsch aussieht.

Was „robots.txt“ nicht abdeckt

Es lohnt sich, dies ausdrücklich zu betonen, da die Leute dies in beide Richtungen falsch interpretieren.

Es sagt nichts darüber aus, was Sie mit den abgerufenen Daten tun dürfen. Urheberrecht, Datenbankrechte und Nutzungsbedingungen gelten unabhängig davon.

Es handelt sich nicht um eine Erlaubnis. Der RFC sagt dies ausdrücklich. Ein erlaubter Pfad ist ein Pfad, den die Website Crawlern nicht ausdrücklich untersagt hat – was nicht gleichbedeutend ist mit einer Einwilligung zur massenhaften Datenerfassung.

Die Norm enthält keine Ratenbegrenzung. „Crawl-delay“ ist eine Erweiterung. Höflichkeit liegt in Ihrer Verantwortung.

Es wird nicht nach Zwecken unterschieden. Eine Datei kann in der Standardsyntax nicht angeben: „Indizierung ja, KI-Training nein“, obwohl viele Websites dies mittlerweile annähernd umsetzen, indem sie spezifische KI-Crawler-Token benennen. Der Rahmen der EU für Text- und Data-Mining sieht maschinenlesbare Rechtevorbehalte vor, und die Mechanismen zu deren Ausdruck befinden sich noch in der Entwicklung.

Es kann niemanden daran hindern. Es handelt sich um eine Aufforderung. Die Durchsetzung erfolgt durch Ratenbegrenzung, Sperrung und rechtliche Schritte – was der praktische Grund dafür ist, dass ein Betreiber den Crawler zulässt, anstatt ihn stoppen zu müssen.

Häufig gestellte Fragen

Ist die robots.txt-Datei rechtsverbindlich?

An sich nicht. In RFC 9309 heißt es, dass die darin enthaltenen Regeln „keine Form der Zugriffsberechtigung darstellen“ – es handelt sich vielmehr um eine Bitte, der Crawler nachkommen sollen. Rechtliche Verpflichtungen ergeben sich aus Nutzungsbedingungen, dem Urheberrecht, Datenbankrechten und rechtsraumbezogenen Gesetzen, die alle unabhängig vom Inhalt der Datei gelten.

Werden die Regeln in der robots.txt der Reihe nach abgeglichen?

Nein, und dies ist der am häufigsten wiederholte Irrtum in diesem Zusammenhang. Die Spezifikation schreibt vor, dass „die spezifischste gefundene Übereinstimmung verwendet werden MUSS“, wobei „spezifischste“ die meisten Oktette bedeutet. Die längste Übereinstimmung hat Vorrang, die Reihenfolge ist irrelevant, und bei Gleichstand gilt „Allow“.

Was passiert, wenn robots.txt einen 404-Fehler zurückgibt?

Die Datei ist „nicht verfügbar“, und laut RFC „DARF“ der Crawler „auf beliebige Ressourcen auf dem Server zugreifen“. Keine Datei bedeutet keine Einschränkungen. Dies ist etwas anderes als ein Serverfehler.

Was passiert, wenn „robots.txt“ einen 500-Fehler zurückgibt?

Die Datei ist „nicht erreichbar“ und undefiniert, und der Crawler „MUSS von einer vollständigen Sperrung ausgehen“. Ein Serverfehler bedeutet, vollständig anzuhalten, nicht fortzufahren. Nach einer längeren Zeitspanne – der RFC schlägt 30 Tage vor – darf ein Crawler die Datei als nicht verfügbar behandeln oder weiterhin eine zwischengespeicherte Kopie verwenden.

Wie oft sollte ich die robots.txt abrufen?

Mindestens alle 24 Stunden. Der RFC besagt, dass Crawler „die zwischengespeicherte Version nicht länger als 24 Stunden verwenden SOLLTEN, es sei denn, die robots.txt-Datei ist nicht erreichbar“. Ein einmaliger Abruf beim Start und eine Laufzeit von einer Woche entsprechen nicht den Vorgaben.

Hat eine bestimmte User-Agent-Gruppe Vorrang vor der Wildcard-Gruppe?

Sie ersetzt diese. Wenn eine Gruppe Ihr Produkt-Token nennt, befolgen Sie diese Gruppe und ignorieren die Gruppe „*“ vollständig – spezifische Regeln ergänzen die allgemeinen nicht. Zwei Gruppen, die dasselbe Token nennen, werden zu einer zusammengefasst.

Was bedeuten „*“ und „$“ in der robots.txt?

„*“ passt auf null oder mehr beliebige Zeichen, und „$“ markiert das Ende des Übereinstimmungsmusters. Beide Zeichen MÜSSEN von Crawlern unterstützt werden. „Disallow: /*.pdf$“ blockiert URLs, die auf „.pdf“ enden; ohne das „$“ würde es auch „/file.pdf.html“ blockieren.

Kann ich „robots.txt“ verwenden, um sensible Seiten zu verbergen?

Nein, und dies würde die Situation sogar verschlimmern. Im Abschnitt zur Sicherheit des RFC heißt es: „Das Auflisten von Pfaden in der robots.txt-Datei macht diese öffentlich zugänglich und somit auffindbar.“ Jeder kann die Datei lesen. Verwenden Sie stattdessen eine Authentifizierung, wie es die Spezifikation ausdrücklich empfiehlt.

Fazit: „

robots.txt“ ist kurz, standardisiert und wird regelmäßig falsch umgesetzt. Drei Regeln sind für die meisten Fehler verantwortlich.

Die längste Übereinstimmung gewinnt, nicht die erste oder letzte. Ein „Disallow“ weiter unten in der Datei kann ein „Allow“ darüber überschreiben und umgekehrt – allein aufgrund der Länge. Ein 5xx-Code bedeutet vollständige Sperrung, was das Gegenteil dessen ist, was eine intuitive Implementierung tut – eine Website mit Problemen sollte weniger Traffic von Ihnen erhalten, nicht die gleiche Menge. Und die Datei muss mindestens täglich aktualisiert werden, da Websites ihre Richtlinien ändern können und eine eine Woche alte zwischengespeicherte Kopie nicht den Anforderungen entspricht.

Verwenden Sie einen gepflegten Parser, anstatt einen eigenen zu schreiben, stellen Sie sicher, dass Ihr User-Agent-Header tatsächlich das Token enthält, auf das abgeglichen werden soll, und protokollieren Sie, was Sie übersprungen haben, damit fehlende Daten eine bewusste Entscheidung und keine Überraschung sind.

Und behalte den im Standard selbst enthaltenen Vorbehalt im Blick. Diese Regeln „stellen keine Form der Zugriffsberechtigung dar“ – ihre Einhaltung macht dich zu einem Crawler, mit dem ein Betreiber leben kann, und klärt nicht die separaten Fragen, was die Bedingungen zulassen und was du mit den gesammelten Daten tun darfst.