Robots.txt-Direktiven: Ein Leitfaden zu allen Standard- und versteckten Regeln

Executive Summary

Die Datei robots.txt (Robots Exclusion Protocol, REP) ist ein langjähriger, textbasierter Mechanismus, mit dem Webmaster automatisierten Crawlern mitteilen können, welche Teile einer Website zugänglich sind und welche nicht. Sie wurde erstmals im Juli 1994 von Martijn Koster vorgeschlagen ^[1] und hat sich seitdem zu einem De-facto-Standard entwickelt. Im Jahr 2022 wurde sie als RFC 9309 im Rahmen des IETF Standards Track formell standardisiert ^[2]. Robots.txt ist kein Zugriffssteuerungs- oder Sicherheitsmechanismus – vielmehr ist es eine freiwillige „Anfrage“ an freundliche Crawler (Suchmaschinen und andere Bots) bezüglich ihrer Crawling-Präferenzen ^[3]. Bis 2021 hatten etwa 81,9 % der indexierten Websites eine robots.txt-Datei ^[4], was ihre Allgegenwart widerspiegelt.

Dieser Bericht bietet eine eingehende Untersuchung aller bekannten Direktiven und Parameter in robots.txt, einschließlich obskurer und suchmaschinenspezifischer. Wir behandeln den Standardkern (z. B. User-agent, Disallow, Allow) und die Mustersyntax (Platzhalter, $ Zeilenende), sowie Erweiterungen wie Sitemap:-Links. Anschließend werden nicht-standardisierte oder weniger bekannte Direktiven detailliert beschrieben – zum Beispiel Crawl-delay, Yandex’ Clean-param und Host, Seznams Request-rate/Visit-time und historische noindex-Regeln – einschließlich der Angabe, welche großen Such-Crawler sie unterstützen. Durchweg werden Behauptungen durch offizielle Dokumentation, Expertenanalysen und Fallstudien aus der Praxis untermauert. Zum Beispiel bestätigt Googles Search Central-Anleitung, dass Robots-Regeln wie „noindex“ (in robots.txt) nicht unterstützt werden ^[5], und dass durch Robots blockierte Seiten immer noch indexiert werden können, wenn sie von anderswo verlinkt sind ^[6] (und sogar in Googles Ergebnissen mit Snippets erscheinen können ^[6]). Yandex dokumentiert seine einzigartigen Funktionen wie Clean-param (zum Ignorieren von Abfrageparametern) ^[7], während Bings Ingenieure festgestellt haben, dass Bing eine noindex-Direktive in robots.txt nie beachtet hat ^[8].

Wir analysieren auch Nutzungstrends (z. B. Tabelle der Suchmaschinen-Direktiven-Unterstützung) und reale Vorfälle. Zum Beispiel berichtete eine SEO-Fallstudie, wie vom Host konfigurierte Robots-Regeln (ohne Wissen des Webmasters hinzugefügt) im Laufe der Zeit unbeabsichtigt wichtige Website-Bereiche ausschlossen – die betroffenen Seiten fielen langsam aus Googles Index ^[9]. Aus Sicherheitssicht warnen Forscher, dass das Einschließen sensibler Pfade (wie /admin/, /backup/, /debug/) in robots.txt Angreifern tatsächlich ein Ziel aufzeigt ^{[10] [11]}. Basierend auf Daten (z. B. aus dem 2021 HTTP Archive SEO Almanac ^[4]) und Suchmaschinen-Blogs ^{[12] [13]} schließt der Bericht mit Implikationen für Webmaster (Best Practices, Crawling-Zuverlässigkeit) und zukünftige Richtungen (das Potenzial, REP mit neuen Konsensregeln zu erweitern).

Introduction and Background

Das Robots Exclusion Protocol (REP) ist der ursprüngliche Crawler-Kontrollstandard des Webs. Es begann als einfache Datei /robots.txt im Stammverzeichnis einer Website, die von Indexierungs-Bots gelesen wurde und angab, welche URLs ausgeschlossen oder zugelassen werden sollten. Martijn Koster stellte die Idee erstmals im Juli 1994 auf der W3C www-talk Mailingliste vor ^[1]; berühmt wurde er, weil er sie benötigte, nachdem seine Website von einem aggressiven Crawler per DOS angegriffen worden war. In den folgenden Jahrzehnten blieb REP ein informeller De-facto-Standard, der von praktisch allen großen Suchmaschinen verwendet wurde. Trotz seines Alters blieb REP mit geringen Änderungen bestehen: Bis 2025 hatte es sich „kaum weiterentwickeln müssen“ – Google merkt an, dass die einzige universell unterstützte Erweiterung, die es erhielt, die Allow-Direktive war ^[13].

Im September 2022 formalisierte die IETF diese Praktiken als RFC 9309 (Source: blog.seznam.cz). Dieses Dokument kodifiziert die REP-Sprache und Verarbeitungsregeln auf dem Internet Standards Track ^[2]. Der RFC würdigt die ursprüngliche Spezifikation von Koster aus dem Jahr 1994 ^[14] und klärt, wie Crawler robots.txt parsen und cachen, Weiterleitungen, Fehler behandeln und User-agent, Allow, Disallow-Regeln lesen sollten ^{[15] [16]}. Wichtig ist, dass der RFC explizit feststellt, dass Robots-Direktiven kein Autorisierungsschema sind – wenn Sie einen Pfad in robots.txt auflisten, ist er für jeden Menschen oder bösartigen Bot offen zugänglich, daher sollte die tatsächliche Sicherheit eine ordnungsgemäße Zugriffssteuerung (z. B. HTTP-Authentifizierung) verwenden ^[17].

In der Praxis verwenden robots.txt-Dateien eine unkomplizierte Grammatik. Sie bestehen aus einer oder mehreren „Gruppen“ (Blöcken), die jeweils mit einer oder mehreren User-agent:-Zeilen beginnen, gefolgt von passenden Regeln. Zum Beispiel:

User-agent: *
Disallow: /private/
Allow: /private/special/
Sitemap: https://example.com/sitemap.xml

Dies bedeutet: „Für alle Crawler, /private/ nicht zulassen, außer /private/special/ zulassen. Außerdem, hier ist unsere Sitemap.“ In Gruppe 1 impliziert der leere Pfad nach Disallow: alles zulassen. Jede Regel ist ein Schlüssel-Wert-Paar, getrennt durch einen Doppelpunkt. Der Schlüssel kann Allow: oder Disallow: sein, gefolgt von einem URL-Pfadmuster. Die REP-Syntax (gemäß RFC 9309) besagt, dass für eine passende Gruppe die spezifischste Regel (längste Pfadübereinstimmung) Vorrang hat, und im Falle eines Gleichstands eine Allow-Regel eine Disallow-Regel schlägt ^[18]. Regeln sind im URL-Pfad groß- und kleinschreibungsempfindlich – zum Beispiel blockiert Disallow: /Example/ nicht /example/ ^[19]. Wenn keine Regeln einem bestimmten Crawler oder einer URL entsprechen, ist das Crawling implizit erlaubt (der Standard ist offen) ^{[18] [20]}.

Seit den frühen Tagen des Internets war das Paradigma, dass freundliche Crawler diese Direktiven befolgen sollten. Google, Bing, Yandex und andere haben ihre Bots so gebaut, dass sie die Standardregeln und viele gängige Erweiterungen respektieren. Diese freiwillige Natur bedeutet jedoch, dass jeder Crawler selbst entscheiden kann, welche Direktiven er unterstützt. Wie wir sehen werden, werden einige Direktiven (wie Crawl-delay oder Clean-param) nur von wenigen Engines beachtet, und andere (wie eine Noindex-Zeile in robots) werden von großen Crawlern ignoriert ^{[5] [8]}. Die folgenden Abschnitte beschreiben die Syntax, die offizielle Unterstützung und viele „versteckte“ oder weniger bekannte Parameter, die in den heutigen robots.txt-Dateien verwendet werden.

Core robots.txt Syntax and Directives

Standard-Direktiven: User-agent, Disallow, Allow

Die grundlegenden Direktiven in einer robots.txt-Datei sind User-agent (identifiziert den Ziel-Crawler) und Disallow (blockiert Pfade). RFC 9309 formalisiert diese Basissyntax: Jede Regel ist entweder Allow: oder Disallow:, jeweils gefolgt von einem Pfadmuster ^[21]. Eine Gruppe von Regeln gilt für die vorangehenden User-agent-Zeilen ^[22]. Zum Beispiel:

User-agent: Googlebot
Disallow: /admin/
Allow: /admin/help/

Dies weist Googlebot an, /admin/ nicht zu crawlen, außer /admin/help/ darf gecrawlt werden. Das Schlüsselwort * wird verwendet, um alle Crawler zu matchen (z. B. User-agent: *) ^[23]. Konventionell bedeutet ein leeres Disallow: (kein Pfad) alles erlauben (keine Einschränkungen). Wenn keine Regel zutrifft, ist der Inhalt standardmäßig crawlbar ^[18].

Crawler matchen die längste Regel: Wenn mehrere Direktiven auf eine URL zutreffen, gewinnt diejenige mit der längsten Pfadzeichenkette. Wenn eine Allow- und eine Disallow-Regel exakt gleich lang sind, hat Allow Vorrang ^[18]. Groß-/Kleinschreibung ist wichtig: Der Pfadabgleich ist groß- und kleinschreibungsempfindlich ^[19]. (In der Praxis, da Domainnamen groß- und kleinschreibungsunempfindlich sein können, rät der RFC zur Verwendung von Punycode oder UTF-8-Konvertierung, aber diese Details betreffen hauptsächlich die Lokalisierung ^[24].)

Die meisten Suchmaschinen unterstützen heute die Allow-Direktive ^[25]. Zum Beispiel listet Yandex' Webmaster-Dokumentation Allow explizit neben Disallow als eine Direktive auf, die das Crawling erlaubt ^[26]. Auch Google verwendet Allow:-Regeln, um Ausnahmen aus einem Disallow-Baum zu schnitzen ^{[25] [12]}. (Ursprünglich war Allow eine inoffizielle Google-Erweiterung, die in den 1990er Jahren eingeführt wurde; sie ist heute allgegenwärtig.)

Eine weitere gängige Direktive ist Sitemap:, die dem Crawler mitteilt, wo die XML-Sitemap(s) der Website zu finden sind. Obwohl sie nicht Teil des ursprünglichen REP ist, ist sie „ein zusätzlicher Standard“, der von Google, Bing, Yandex und anderen anerkannt wird ^[12]. Im obigen Beispiel verweist Sitemap: https://example.com/sitemap.xml Crawler auf die Sitemap-URL. Google ermutigt tatsächlich dazu, Sitemaps in robots.txt zu platzieren (und hat sie über diese Regel crawlbar gemacht) ^[27]. Alle großen Suchmaschinen beachten die Sitemap:-Zeile der Einfachheit halber, obwohl sie außerhalb der formalen RFC-Grammatik liegt ^[28].

Muster und Wildcards

Moderne Crawler unterstützen auch einfache Musterabgleiche in Pfaden. Am weitesten verbreitet sind der *-Platzhalter (passt auf jede Zeichenfolge) und der $-Anker (passt auf das Ende der URL). Zum Beispiel bedeutet Disallow: /*.pdf$ „alle URLs, die auf .pdf enden, nicht zulassen“. Googles REP erlaubt seit langem * und $ in Disallow-Mustern (sein Open-Source-Parser und seine Dokumentation unterstützen diese Syntax) ^{[25] [12]}. Yandex akzeptiert diese Wildcards ebenfalls. Laut Baidus Hilfe unterstützt sein Baiduspider sowohl „* als auch $“ für den Abgleich von URLs ^[29]. In der Praxis nutzen viele Websites diese Möglichkeit, um ganze Dateitypen oder URL-Abfrageparameter zu blockieren. (Zum Beispiel blockiert Disallow: /*?* jede URL, die „?“ enthält.) Ein detaillierter Abgleichprozess wird angewendet: Sobald ein Crawler alle Disallow- und Allow-Regeln für seinen User-Agent gesammelt hat, findet er die Regel mit dem spezifischsten (längsten) passenden Präfix; wenn diese Regel Allow ist, darf die URL gecrawlt werden, und wenn sie Disallow ist, wird die URL blockiert ^[18].

Groß-/Kleinschreibung und Normalisierung

Direktiven passen URL-Pfade wörtlich ab. Das bedeutet, dass die Groß-/Kleinschreibung wichtig ist und die exakte Zeichenfolge vom ersten Zeichen an übereinstimmen muss. Zum Beispiel blockiert eine Direktive Disallow: /Category/ URLs wie /Category/Item1, aber nicht /category/item1 – die Nichtübereinstimmung von Klein- und Großbuchstaben bedeutet, dass die zweite URL nicht erfasst wird ^[19]. Ähnlich dekodiert der Robots-Parser prozentkodierte Zeichen vor dem Abgleich ^[30]. Beachten Sie jedoch, dass, obwohl der Pfadabgleich in Regeln groß- und kleinschreibungsempfindlich ist, die meisten Crawler die User-agent:- und Direktiven-Namen (User-agent, Allow usw.) als groß- und kleinschreibungsunempfindliche Schlüsselwörter behandeln ^[31]. Zusammenfassend lässt sich sagen, dass robots.txt-Regeln eine präzise Zeichenfolgenübereinstimmung auf dem Pfadteil von URLs befolgen, daher muss man bei der Erstellung von Regeln die URL-Normalisierung und Groß-/Kleinschreibung berücksichtigen.

Extended and Lesser-Known Directives

Jenseits der grundlegenden Grammatik sind eine Reihe von nicht-standardisierten Direktiven aufgetaucht. Diese sind nicht Teil des ursprünglichen REP von 1994, werden aber in der Praxis von bestimmten Crawlern unterstützt.

• Allow: Wir haben Allow: bereits als Erweiterung zur Außerkraftsetzung von Disallows behandelt. Seine Unterstützung ist gewachsen, bis es in allen großen Engines effektiv ein Standard ist ^[25]. Googles Robots-Parser stellt sicher, dass Allow-Regeln beachtet werden, und wenn eine Allow- und eine Disallow-Regel beide auf eine URL zutreffen, verwendet Google den längeren Pfad (oft die Allow-Regel, wenn sie länger ist) ^[18].

• Crawl-delay: Diese Direktive wurde erfunden, um die Crawling-Geschwindigkeit zu drosseln (wenige Seiten pro Sekunde). Sie ist nicht Teil der offiziellen REP-Grammatik【26†】, aber einige Engines verwenden sie. Yandex unterstützt Crawl-delay in robots.txt, z. B. Crawl-delay: 10, um 10 Sekunden zwischen den Abrufen zu warten ^[32]. Bing beachtet Crawl-delay ebenfalls. Google unterstützt keine Crawl-delay-Direktive in robots.txt: Wie Googles Matt Cutts erklärte, konfigurieren viele Webmaster sie falsch (z. B. auf 100.000 setzen), was effektiv kein Crawling verursacht ^[33]. Stattdessen bietet Google Crawl-Rate-Kontrollen in der Search Console an (und steuert intern das Crawling mit „Host-Load“-Einstellungen) ^[34]. Wenn Sie also Crawl-delay in robots.txt schreiben, werden nur Yandex, Bing (und vielleicht einige benutzerdefinierte Crawler) es beachten, nicht Google.

• Suchmaschinenspezifisches „Host“: Ursprünglich führte Yandex eine Host:-Direktive ein, damit Webmaster die bevorzugte Domain einer Website unter mehreren Spiegelungen deklarieren konnten. Wenn eine Website beispielsweise sowohl unter example.com als auch unter example.net erreichbar ist, würde Yandex die erste Host:-Zeile als kanonischen Host verwenden ^[35]. In der Praxis erkannte nur Yandex Host: überhaupt an. Seit März 2018 hat Yandex die Unterstützung für Host: jedoch eingestellt und rät stattdessen zur Verwendung von Weiterleitungen (Source: robotstxt.ru). (Alle Host:-Zeilen nach der ersten werden ignoriert ^[35].) Andere Suchmaschinen ignorieren diese Direktive vollständig.

• Yandex „Clean-param“: Yandex unterstützt eine ungewöhnliche Direktive Clean-param: p0[&p1&p2...] [path], um URLs zu kanonisieren, indem irrelevante Abfrageparameter entfernt werden ^[7]. Um beispielsweise Tracking-Parameter zu reduzieren, könnte man Folgendes schreiben:

  User-agent: Yandex
  Clean-param: ref /some_dir/get_book.pl
  

  Dies weist Yandex an, URLs der Form /some_dir/get_book.pl?ref=XYZ&book_id=123 so zu behandeln, als ob nur book_id=123 relevant wäre, d.h. alle ref=-Werte zu ignorieren ^[7]. Yandex wird dann nur eine kanonische URL (get_book.pl?book_id=123) anstelle von Duplikaten indexieren. Diese Direktive ist einzigartig für Yandex (Google, Bing usw. unterstützen Clean-param nicht), und ihre Syntax kann mehrere Parameter und sogar Pfad-Wildcards akzeptieren ^[7].

• Noindex und Nofollow (in robots.txt): Anfangs zogen einige Website-Betreiber (und sogar einige Google-Diskussionen) in Betracht, Noindex: /somepage in robots.txt hinzuzufügen, um die Indexierung zu verhindern. Google hat sich jedoch lange geweigert, Noindex in robots.txt zu berücksichtigen. In einem Blogbeitrag von 2019 riet Gary Illyes (Google) von der Verwendung von noindex-, nofollow- oder crawl-delay-Regeln in robots.txt ab und erklärte: „Wir stellen den gesamten Code ein, der nicht unterstützte und unveröffentlichte Regeln (wie noindex) verarbeitet“ ^[5]. Tatsächlich sagt Google explizit, dass es nicht garantiert, dass das Blockieren einer URL in robots.txt sie aus den Suchergebnissen fernhält ^{[5] [6]}. (Von Robots ausgeschlossene Seiten können immer noch ranken, wenn sie anderswo verlinkt sind; Google zeigt möglicherweise einfach ein Platzhalter-Snippet an.) Ähnlich bemerkte das Bing-Team, dass die „undokumentierte noindex-Direktive nie für Bing funktionierte“ ^[8]. Zusammenfassend lässt sich sagen, dass keine große moderne Suchmaschine eine <Noindex>-Regel in robots.txt unterstützt. Um Seiten aus Google zu entfernen, muss man ein <meta name="robots" content="noindex"> auf der Seite verwenden oder eine 404/410-Antwort senden ^{[5] [8]}. (Das einzige „nofollow“, das für robots.txt relevant ist, ist Disallow, das den Crawler daran hindert, Links zu folgen – aber auch dies verhindert die Indexierung nicht, wenn andere Websites darauf verlinken.)

• Weitere vorgeschlagene Erweiterungen: Im Laufe der Jahre wurden verschiedene andere Direktiven vorgeschlagen oder von Nischen-Crawlern übernommen. Zum Beispiel definierte der Conman.org-Entwurf (2000er Jahre) Request-rate: und Visit-time:. SeznamBot (eine beliebte tschechische Suchmaschine) implementiert diese: z.B. Request-rate: 10/1m begrenzt das Crawling auf 10 Seiten pro Minute, möglicherweise mit zusätzlichen Zeitfenstern (wie 1500-0559) (Source: blog.seznam.cz). Die Visit-time-Direktive des Entwurfs könnte bevorzugte Crawl-Stunden vorschlagen. Diese werden von Google, Bing, Yandex oder den meisten Websites außerhalb von Seznam nicht erkannt. Matt Cutts scherzte, dass das IBM-Team unicorns: allowed-Zeilen definieren könnte, wenn sie das Protokoll erweitern wollten ^[36]. Der entscheidende Punkt ist, dass Crawler proprietäre Direktiven frei implementieren können – das Protokoll ist erweiterbar. Zum Beispiel wurde Googles eigener Open-Source-Parser mit einem Sitemap:-Handler demonstriert, um die Unterstützung benutzerdefinierter Regeln zu validieren ^[36]. Der Google-Blog „Future-proof REP“ aus dem Jahr 2025 erkennt solche benutzerdefinierten Regeln (wie clean-param, crawl-delay) explizit als außerhalb des neuen RFC liegend an, die aber immer noch von einigen Engines unterstützt werden (obwohl nicht von der Google-Suche für diese spezifischen) ^[28].

Die folgende Tabelle fasst gängige (oben) und ungewöhnliche robots.txt-Direktiven zusammen und zeigt, welche großen Suchmaschinen sie derzeit unterstützen:

Tabelle: Wichtige robots.txt-Direktiven und deren Unterstützung durch große Suchmaschinen. „✓“ bedeutet Unterstützung. Ein leeres „–“ bedeutet keine Unterstützung. Yandex akzeptierte historisch Host: und Clean-param:; Google/Bing tun dies nicht. Sowohl Google als auch Bing ignorieren jegliches Noindex: in robots.txt` ^{[5] [8]}. (Quellen: Offizielle Google- und Yandex-Dokumentation, Community-Wissen.)

Suchmaschinenspezifische Verhaltensweisen

Verschiedene Crawler interpretieren robots-Regeln geringfügig unterschiedlich. Dieser Abschnitt beleuchtet die Verhaltensweisen wichtiger Suchmaschinen (Google, Bing, Yandex, Baidu usw.) und wie sie robots.txt behandeln.

• Google (und Googlebot): Googlebot folgt vollständig dem „Standard“-Teil des REP. Es erkennt User-agent, Disallow, Allow, Sitemap und Wildcards. Google implementiert kein Crawl-delay oder Request-rate; stattdessen verwendet es zentralisierte Crawl-Steuerungen. Google ignoriert auch alle nicht unterstützten Zeilen wie Noindex: in robots.txt ^[5]. Wichtig ist, dass Google URLs, die ausgeschlossen sind, weiterhin (ohne Inhalt) indexiert. Wie ein SEO-Leitfaden feststellt: „Keine URL wird vollständig von Suchmaschinen blockiert, wenn Sie sie in robots.txt ausschließen“ ^[6]. Googles Dokumentation besagt ebenfalls, dass es „nicht garantiert“, dass ausgeschlossene Seiten nicht indexiert werden. In der Praxis kann Google einen Ergebniseintrag für eine ausgeschlossene URL anzeigen (oft als „Unverified“ oder ohne Snippet gekennzeichnet), wenn es Links dazu findet ^[6]. Neuere Google-Funktionen erlauben sogar, dass ausgeschlossene Seiten in KI-Übersichten mit Snippets zitiert werden ^[37]. Nach 2019 deaktivierte Google die Analyse von noindex in robots (und aller unveröffentlichten Regeln wie nofollow) formell ^[5], was mit Bings Haltung übereinstimmt ^[8]. Im Jahr 2019 veröffentlichte Google seinen robots.txt-Parsing-Code als Open Source und veröffentlichte einen Internet-Draft (einen Vor-RFC-Vorschlag), der zeigte, wie neue Regeln hinzugefügt werden könnten ^[36]. Googles offizieller Blog („Future-proof REP“) merkt an, dass in über 25 Jahren die einzige universell übernommene Änderung das Hinzufügen von Allow war ^[13]; andere Erweiterungen (wie sitemap:) wurden außerhalb des RFC üblich.

• Bing und Yahoo: Da Yahoo Search nun Bings Crawler („Bingbot“) verwendet, ist ihre robots-Nutzung identisch. Bing unterstützt User-agent, Disallow, Allow, Sitemap und (inoffiziell) Crawl-delay. Bing verlangt, dass, wenn Sie einen benannten Abschnitt für Bingbot: angeben, Sie alle allgemeinen Regeln dort wiederholen müssen. Wie SearchLand berichtete: „Wenn Sie einen Abschnitt speziell für Bingbot erstellen, werden alle Standarddirektiven ignoriert… Sie müssen die Direktiven, denen Bingbot folgen soll, unter seinem eigenen Abschnitt kopieren und einfügen“ ^[38]. Bings Senior Developer Frédéric Dubut bestätigte, dass noindex in robots.txt nie erkannt wurde, daher müssen Seiten Meta-Tags oder Header verwenden, um aus Bings Index entfernt zu werden ^[8]. Ansonsten ähnelt Bings Verhalten dem von Google: ausgeschlossene Seiten können immer noch indexiert werden, wenn sie verlinkt sind, und Bing behält seine eigenen Cache-Kontrollen in den Webmaster Tools vor.

• Yandex: Yandexbot berücksichtigt den Standard-REP sowie seine proprietären Erweiterungen. Die Dokumentation listet Allow, Disallow, Crawl-delay sowie Sitemap und Clean-param auf ^[26]. Yandex verwendet Clean-param: zur Optimierung des Crawlings dynamischer URLs (siehe Beispiel oben ^[7]). Sein Crawl-delay wird in Sekunden angegeben (z.B. Crawl-delay: 10) ^[32]. Bis 2018 las Yandex auch eine Host:-Direktive für die kanonische Domain, diese wird aber inzwischen nicht mehr unterstützt (Source: robotstxt.ru). Bemerkenswerterweise behandelt Yandex ausgeschlossene Seiten ähnlich wie Google: Sie können immer noch indexiert werden, aber Yandex kann deren Inhalt nicht sehen und daher keine HTML-noindex-Anweisungen auf ihnen respektieren. (Yandex warnt Webmaster daher, Meta-noindex anstelle von robots zu verwenden, um Inhalte zu verbergen ^[39].) Wie Google betrachtet Yandex robots-Regeln als groß-/kleinschreibungsempfindlich.

• Baidu (Chinas führende Suchmaschine): Baidus Bots (z.B. „Baiduspider“) unterstützen User-agent, Disallow, Allow und Sitemap. Baidu unterstützt explizit die Wildcard-Muster * und das Zeilenende-Zeichen $ ^[29] (die eigene Dokumentation besagt: „Baiduspider unterstützt die Wildcard-Zeichen * und $“). Baidu hat kein öffentliches Crawl-delay-Argument in robots.txt; stattdessen passen chinesische Webmaster die Crawl-Rate über die Baidu Webmaster Tools an. Baidu weist auch darauf hin, dass durch robots blockierte Seiten möglicherweise immer noch in den Suchergebnissen über Links von anderen Websites erscheinen können ^[40]; daher ist Disallow wiederum eine Direktive zur Steuerung des Crawlings, nicht eine narrensichere Methode zur Nicht-Indexierung. In der Praxis erscheint <User-agent: Baiduspider> auf etwa 1,9 % der Websites (laut Crawling Stats ^[41]).

• Andere Crawler: Es gibt unzählige kleinere Bots (Majestics mj12bot, Ahrefs usw.), die den REP einfach wie Google befolgen. Der HTTP Archive SEO-Bericht von 2021 stellte fest, dass die häufigsten spezifischen User-Agents (nach Google, Bing, Baidu, Yandex) Majestic (mj12bot, 3,3 % Desktop) und Ahrefs (ahrefsbot, 3,3 % Desktop) umfassten ^[42]. Keiner dieser Bots führt einzigartige neue Direktiven ein, die über das hinausgehen, was die großen Engines tun.

Datentrends und Statistiken

Um die reale Nutzung von robots.txt zu verstehen, können wir auf Web-Crawl-Daten zurückgreifen. Laut dem 2021 HTTP Archive SEO-Kapitel ^[4] verwenden 81,9 % der Websites eine robots.txt-Datei auf ihrer Hauptdomain (ein leichter Anstieg von ~72 % im Jahr 2019). Umgekehrt haben etwa 16,5 % der Websites keine robots.txt, wobei Google in diesem Fall alle Seiten als crawlbar behandelt ^[4]. Die verbleibenden ~1,6 % lieferten entweder Fehler oder waren nicht erreichbar. Wichtig ist, dass Google bei einem Fehler beim Abrufen einer robots.txt mit HTTP 5xx (Serverfehler) gemäß RFC 9309 die Website als „nicht erreichbar“ behandelt und das Crawling vorübergehend aussetzt ^{[43] [44]}. Schlägt der Abruf mit 4xx oder 403 fehl, kann Google die Datei als „nicht verfügbar“ behandeln und standardmäßig das Crawling zulassen ^[43]. In der Praxis stellte das Archiv fest, dass ~0,3 % der Websites 403/5xx für robots.txt zurückgaben, und Googles Team schätzte, dass bis zu 5 % vorübergehende 5xx-Fehler hatten und 26 % zeitweise nicht erreichbar waren ^[44]. Selbst vorübergehende Probleme mit robots.txt können einen Crawler stoppen: In einer Umfrage gab Google an, eine Website für eine Weile nicht mehr zu crawlen, wenn ihre robots.txt Fehler zurückgibt, da es „unsicher ist, ob eine bestimmte Seite gecrawlt werden kann oder nicht“ ^[44].

Bezüglich der Dateigröße sind die meisten robots.txt-Dateien recht klein (<100 KiB). Die Analyse des HTTP Archive zeigt, dass nur ~3.000 Domains 500 KiB überschritten – Googles dokumentiertes Maximum – was bedeutet, dass bei diesen extragroßen Dateien alle Regeln jenseits von 500 KiB einfach ignoriert würden ^[45]. Neben der Größe gibt es auch Überlegungen zur Dateikodierung (RFC 9309 erfordert UTF-8) und eine Parser-Grenze von 500 KB, um eine Überlastung zu vermeiden ^{[24] [46]}. Sehr große oder fehlerhafte Dateien laufen daher Gefahr, nicht vollständig geparst zu werden.

Eine weitere nützliche Statistik: wie oft bestimmte User-Agents erwähnt werden. Abbildung 8.6 des Web Almanac zeigt, dass „Googlebot“ in etwa 3,3–3,4 % der robots.txt-Regeln vorkommt, Bingbot in ~2,5–3,4 %, Baiduspider ~1,9 %, Yandexbot ~0,5 % ^[41]. (Diese Prozentsätze beziehen sich auf alle gecrawlten robots.txt-Dateien.) Das deutet darauf hin, dass Google und Bing von einigen Prozent der Websites explizit angesprochen werden, während Majestic und Ahrefs ebenfalls vorkommen (~3 % jeweils). Dies spiegelt die Praxis von SEO-Tools wider, ihre eigenen Crawl-Anweisungen zu platzieren.

Schließlich ist die Verwendung erweiterter Direktiven im Web relativ selten. Vergleicht man beispielsweise Yandex' Clean-param mit der breiten Nutzung: Praktisch 100 % der an Yandex gerichteten robots-Regeln verwenden es, wenn es vorhanden ist, aber es erscheint nur auf wenigen Prozent aller Websites weltweit (da es nur von Yandex indexierte Websites überhaupt verwenden würden). Ähnlich listen heute nur noch sehr wenige Websites Host: (da Yandex es fallen gelassen hat) oder Seznams Request-rate. Dieser Bericht hat sich auf Vollständigkeit statt auf Verbreitung konzentriert, daher behandeln wir auch diese selteneren Fälle vollständig.

Fallstudien und Praxisbeispiele

SEO-Fehler: Ein klassisches Beispiel für die Auswirkungen von robots.txt ist Glenn Gabes Fallstudie auf Search Engine Land ^[9]. Ein Kunde bemerkte, dass wichtige Kategorieseiten auf mysteriöse Weise aus Google verschwanden. Bei der Untersuchung fand Gabe zwei Übeltäter: (1) Der CMS-Anbieter hatte im Laufe der Zeit programmatisch neue robots.txt-Direktiven hinzugefügt, ohne dass der Website-Betreiber davon wusste, und (2) einige Disallows verwendeten die falsche Groß-/Kleinschreibung (z. B. /CATEGORY/ statt /Category/). Da robots.txt-Abgleiche groß-/kleinschreibungsempfindlich sind, blockierten diese Direktiven versehentlich Seiten. Das Ergebnis war ein „langsames Leck“ wichtiger URLs aus dem Google-Index ^[9]. Gabes Analyse unterstreicht die Gefahr selbst kleiner robots-Änderungen. Sie betont, dass Webmaster Änderungen an robots.txt überwachen (einige verwenden Warnmeldungen oder Versionskontrolle) und routinemäßig prüfen sollten, welche wichtigen URLs möglicherweise blockiert werden (Tools wie Screaming Frog oder der Robots-Tester der Search Console können helfen) ^{[9] [47]}. Die Verwendung der Wayback Machine des Internet Archive zur Überprüfung historischer robots.txt-Versionen kann auch aufzeigen, wann eine schädliche Direktive hinzugefügt wurde ^[47].

Sicherheitsrisiko/Honeypots: Über SEO hinaus haben robots.txt-Dateien die Aufmerksamkeit von Sicherheitsforschern und sogar Hackern auf sich gezogen. Ein Penetrationstester analysierte 2015 Hunderttausende von robots.txt-Dateien im Web und stellte fest, dass sie oft „Schatzkarten“ für Angreifer offenlegen ^[10]. Wenn eine robots-Datei Verzeichnisse wie /admin/, /staging/ oder /backup/ ausschließt, kündigt sie im Wesentlichen die Existenz dieser sensiblen Bereiche an. Zum Beispiel berichtete Weksteen (ein Sicherheitsforscher), viele Admin- und Login-Portale einfach durch das Auslesen von ausgeschlossenen Pfaden in robots.txt gefunden zu haben ^[10]. Seine Erkenntnisse umfassen reale Fälle: Tausende von Regierungs- und akademischen Websites hatten „/disallow“-Einträge, die auf vertrauliche PDF-Archive und Personaldaten verwiesen, auf die Angreifer später über die Suche zugriffen. Wie The Register zusammenfasst, „schreit die Erwähnung eines Verzeichnisses in einer robots.txt-Datei heraus, dass der Eigentümer etwas zu verbergen hat“ ^[10]. Selbst bekannte Websites sind nicht immun: Er nennt Fälle, in denen Namen von Dossiers von Opfern des Menschenhandels unbeabsichtigt über Bildbeschreibungen in Disallow-Listen offengelegt wurden.

Ähnlich raten Sicherheitsexperten dringend: Verlassen Sie sich nicht auf robots.txt, um geheime Inhalte zu schützen. Leitfäden für ethisches Hacking betonen, dass die Veröffentlichung sensibler Datei- oder Verzeichnisnamen in robots.txt kontraproduktiv ist; sie schafft eine „unbeabsichtigte Angriffsfläche“ ^[48]. Tatsächlich richten einige Administratoren Honeypots ein, indem sie gefälschte, verlockende ausgeschlossene Pfade auflisten (z. B. /admin/please_dont_hack/) und dann alle Zugriffe auf diese Pfade überwachen. Das Fazit ist, dass robots.txt öffentlich ist: Jeder Mensch und jeder bösartige Bot kann sie lesen. Ein Abschnitt, der einen Pfad einschränkt, bedeutet, dass dieser Pfad existiert und wichtig ist; Angreifer werden entsprechend sondieren ^{[48] [49]}.

Blockieren vs. Indexieren: Ein weiteres praktisches Anliegen betrifft die unterschiedlichen Verhaltensweisen von „blockiert“ und „indexiert“. Die Search Console führte neue Statusmeldungen wie „Indexiert, obwohl durch robots.txt blockiert“ ein, die viele SEOs verwirren. Wie ein Artikel von SearchEngineLand vom Februar 2025 erklärt ^[50], bedeutet „Durch robots.txt blockiert“ nicht „wird niemals in den Suchergebnissen erscheinen“. Google erklärt explizit, dass eine ausgeschlossene Seite trotzdem indexiert werden kann (oft unter Verwendung ihrer URL und des externen Linktextes), obwohl Googlebot ihre Inhalte nicht abrufen wird ^[6]. Tatsächlich können Seiten sogar in speziellen Funktionen auftauchen; Lily Ray beobachtete eine Goodreads-URL, die in Googles KI-Übersichten aufgeführt war, obwohl sie durch robots blockiert war ^[37]. Der Konsens der Community lässt sich zusammenfassen: „Keine URL ist vollständig von Suchmaschinen blockiert, wenn Sie sie in robots.txt ausschließen“ ^[6]. Die Behebung eines versehentlichen Disallows beinhaltet normalerweise das Entfernen der Direktive und das erneute Anfordern der Indexierung über Tools (oder einfach das Warten auf einen erneuten Crawl) ^[51].

Fall: Große Crawling-Operationen: Öffentliche Projekte wie das Internet Archive verlassen sich auf robots.txt, um Website-Ausschlüsse zu respektieren. Die Crawler des Archivs parsen robots.txt und befolgen Disallow (wie so ziemlich alle guten Bots). Verschiedene Organisationen haben jedoch einige Statuscodes unterschiedlich interpretiert. Zum Beispiel weisen die technischen Notizen des Internet Archive darauf hin, dass eine fehlende robots.txt standardmäßig als „alles erlauben“ behandelt wird, während ein bestimmtes Muster von Weiterleitungen oder 401/403 als „vollständiges Erlauben“ (d.h. indexierbar) behandelt werden könnte ^[17]. Google hingegen behandelt 401/403 anders (es betrachtet sie als parsbar als „alles erlauben“) ^[17]. Solche Nuancen bedeuten, dass die Crawling-Ergebnisse zwischen den Institutionen leicht variieren können.

Analyse und Diskussion

Tiefe der Erweiterungen vs. Praktische Nutzung. In den über 25 Jahren des Bestehens von robots haben nur sehr wenige neue Regeln die universelle Akzeptanz der Kerndirektiven erreicht. Google-Ingenieure stellen fest, dass neben Allow die einzige andere „Erweiterung“, die fast alle großen Bots verstehen, Sitemap: ist ^[13]. Alle anderen Funktionen bleiben entweder suchmaschinenspezifisch oder optional. Zum Beispiel ignorieren sowohl Google als auch Yandex stillschweigend alle noindex- oder nofollow-Direktiven, die in robots.txt platziert werden ^{[5] [8]} – solche Zeilen haben einfach keine Wirkung. Ähnlich wird Crawl-delay zwar von Bing und Yandex weitgehend erkannt, Google entscheidet sich jedoch bewusst dafür, es nicht zu unterstützen ^[33].

Einige in der Vergangenheit vorgeschlagene Erweiterungen leben noch in Nischenanwendungen weiter. Seznams „Request-rate“ und „Visit-time“ zeigen, dass die Planung komplexer Bot-Zeitpläne möglich ist, wenn sowohl Crawler als auch Webmaster zustimmen. Googles Robotik-Team fördert den Community-Input: Der Artikel „Future-proof REP“ lädt Webmaster explizit ein, neue Direktiven (mit Konsens) über offene Kanäle vorzuschlagen ^{[28] [52]}. Es erinnert uns daran, dass die Einfachheit und Allgegenwart von robots.txt sie zu einem Kandidaten für neue Regeln machen, aber nur, wenn sie weithin vorteilhaft sind. Die Geschichte der Annahme von sitemap: als Regel (einst von SEOs und Suchmaschinen per Crowdsourcing entwickelt) wird als Modell herangezogen ^[53]. Umgekehrt warnen sie davor, dass einseitige Änderungen nicht zum Standard werden – Zusammenarbeit ist erforderlich.

Implikationen für Webmaster und SEO. Für Praktiker geht es bei den „Geheimnissen“ von robots.txt hauptsächlich darum, zu verstehen, wie sich jeder Bot verhält und richtig zu testen. Gehen Sie immer davon aus, dass Google (und Bing) jede private oder versteckte Bedeutung in Ihrer robots-Datei ignorieren werden. Legen Sie niemals echte Passwörter, Schlüssel oder hochgeheime Endpunkte in robots.txt ab. Verwenden Sie es nur, um Crawl-Pfade mit geringem Wert (doppelte Seiten, Staging-/Testbereiche usw.) abzuschneiden, nicht um Inhalte zu verstecken. Testen Sie Ihre Regeln in Tools: Googles Search Console Robots Tester (falls verifiziert) und Validatoren von Drittanbietern, um sicherzustellen, dass die Syntax korrekt ist. Überwachen Sie Änderungen an Ihrer robots.txt-Nutzung (Wayback Machine oder Warnmeldungen) – wie der Fall Gabe zeigt, können unerwartete Änderungen die SEO still und leise zerstören. Halten Sie die Datei schlank, um Größenbeschränkungen zu vermeiden; komprimieren Sie mehrere Disallows, wenn möglich, in eine Pfadspezifikation.

Zukunftsaussichten. Da REP nun offiziell standardisiert ist, sind die meisten „Protokolllücken“ bekannt. Crawler zeigen Interesse an der Weiterentwicklung von robots.txt (z. B. der IETF-Entwurf, Open-Source-Parser), aber jede Änderung wird langsam sein, angesichts der Notwendigkeit der Abwärtskompatibilität und breiter Unterstützung. Googles Perspektive für 2025 ist, dass robots.txt neue Crawling-Präferenzen enthalten kann, aber nur durch sorgfältigen Community-Konsens ^[52]. Da KI und neue Suchmodalitäten aufkommen, bleibt die Kontrolle darüber, was ein Bot sehen kann, entscheidend (robots.txt ist die erste Kommunikationslinie). Ironischerweise betonen die Spezifikationen jedoch, dass sensible Kontrollen auf sicherere Mechanismen (z. B. Meta-Tags, Serverkonfigurationen) verlagert werden sollten ^[17]. Das REP wird wahrscheinlich ein wichtiger, wenn auch begrenzter, Bestandteil des Indexierungs-Ökosystems bleiben. Hinweise auf die Zukunft umfassen besseres Parsen (Google hat seinen Parser als Open Source veröffentlicht ^[36]) und potenziell neue flexible Direktiven – aber vorerst sollten Webmaster die bestehenden beherrschen, wissend, dass es „keine anderen Geheimnisse über robots.txt“ jenseits dieser Regeln gibt ^[54].

Tabellen

Tabelle: Funktionsunterstützung der wichtigsten Suchmaschinen-Crawler. Häkchen basieren auf den oben genannten offiziellen Dokumenten und Blogs. Google und Bing erkennen eine noindex-Direktive in der robots.txt nicht an ^{[5] [8]} (verwenden Sie stattdessen Meta-Tags oder HTTP-Header).

Tabelle: Aufschlüsselung, wie oft bestimmte Bots in der robots.txt genannt werden (Desktop- vs. Mobile-Nutzung ist ähnlich) ^[41]. Abgesehen von * (das in allen Dateien verwendet wird), werden Google- und Bing-Bots nur von wenigen Prozent der Websites explizit referenziert. Bemerkenswerterweise tauchen einige SEO-Tool-Bots (Majestic, Ahrefs) so häufig auf wie die von großen Suchmaschinen.

Fazit

Die robots.txt-Datei mag trivial erscheinen, birgt aber viele Feinheiten. Unsere Untersuchung zeigt, dass es neben den bekannten User-agent/Disallow-Regeln eine vielfältige Landschaft von Direktiven mit unterschiedlicher Akzeptanz gibt. Einige „Geheimnisse“ der robots.txt haben mit Abwesenheit zu tun: zum Beispiel die Kenntnis, dass Google Crawl-delay oder Noindex in dieser Datei nicht respektiert ^{[33] [5]}. Weitere Nuancen betreffen das Zusammenspiel und Grenzfälle: nicht zugelassene URLs können immer noch teilweise indexiert werden ^[6], oder Fehler beim Abrufen der robots.txt können das Crawling einfrieren, bis sie behoben sind ^{[43] [44]}. Wir haben auch weniger bekannte Tools wie Yandex' Clean-param für das Zusammenführen von Query-Strings entdeckt ^[7] und Seznams Regeln zur Ratenbegrenzung (Source: blog.seznam.cz). Jedes hat seinen Platz in spezifischen Ökosystemen.

Historisch gesehen hat sich die robots.txt als bemerkenswert langlebig und erweiterbar erwiesen. Sie hat in 30 Jahren nur geringfügige Änderungen erfahren (z. B. die Hinzufügung von Allow und Wildcard-Unterstützung) ^[13]. Der RFC von 2022 hat einen Großteil ihrer Syntax offiziell eingefroren, obwohl er neue Einträge über „andere Einträge“ (wie bei Sitemap:) zulässt ^[55]. Zukünftig werden Änderungen, wenn überhaupt, nur sehr langsam erfolgen. Google fördert gemeinschaftsgetriebene Ideen (das Beispiel einer bestehenden sitemap:-Regel zeigt, wie Konsens die Akzeptanz fördern kann ^[53]). Doch vorerst müssen Webmaster Experten in den aktuellen Regeln und Interpretationen sein: Missbrauch kann SEO oder Sicherheit schaden.

Empfehlungen: Webmaster sollten die robots.txt einfach und gut getestet halten. Listen Sie nur das auf, was wirklich nicht öffentlich oder von geringer Priorität ist (z. B. Anmeldeseiten, doppelte Suchpfade). Überprüfen Sie immer die Syntax (verwenden Sie Tools oder den Search Console Tester) und denken Sie daran, dass die Datei selbst öffentlich ist. Konsultieren Sie im Zweifelsfall die offizielle Dokumentation der jeweiligen Suchmaschine: für Google siehe Google Search Central; für Yandex siehe die Yandex.Webmaster-Richtlinien ^[26]; für Baidu oder Bing deren Hilfezentren. Bei der Fehlerbehebung von Indexierungsproblemen sollten Sie immer überprüfen, ob Sie nicht versehentlich benötigte URLs ausgeschlossen haben (gängige Tools sind der Robots-Bericht der Google Search Console ^[6] und die Archiv-Versionshistorie ^[47]) .

Zusammenfassend lässt sich sagen, dass robots.txt ein kritisches, wenn auch im Hintergrund agierendes, Tool zur Crawling-Kontrolle bleibt. Das Verständnis ihres gesamten Spektrums – bis hin zu den „Geheimnissen“ versteckter oder einzigartiger Parameter – befähigt Website-Betreiber, ihre Webpräsenz besser zu verwalten. Alle oben genannten Behauptungen und Empfehlungen werden durch maßgebliche Quellen und reale Beispiele gestützt. Nutzen Sie diesen Bericht als Referenz-Checkliste, um sicherzustellen, dass Ihre robots.txt sowohl korrekt als auch sicher ist, und um über zukünftige Entwicklungen im Robots Exclusion Protocol auf dem Laufenden zu bleiben ^{[28] [17]}.