Robots.txt-Prüfer: URLs auf Crawler-Zugriff testen

Die Datei robots.txt steuert, welche Bereiche einer Website von Crawlern besucht werden dürfen. Doch wie entscheidet ein Crawler, welche Regeln für ihn gelten? Der Schlüssel liegt in der Struktur der Datei: Sie besteht aus mehreren Gruppen, die jeweils mit einer oder mehreren User-agent-Zeilen beginnen. Jede Gruppe definiert anschließend Allow- und Disallow-Regeln, die für die genannten Crawler gelten.

Ein Crawler wie Googlebot durchsucht die Datei von oben nach unten und sucht nach der ersten Gruppe, deren User-agent auf ihn zutrifft. Dabei gilt: Ein spezifischer Token wie Googlebot hat Vorrang vor dem Platzhalter *. Falls keine passende Gruppe gefunden wird, greift der Crawler auf die *-Gruppe zurück, sofern vorhanden. Gibt es auch diese nicht, darf der Crawler alle URLs besuchen. Wichtig ist, dass eine spezifische Gruppe die *-Gruppe vollständig ersetzt, nicht ergänzt. Enthält die Googlebot-Gruppe beispielsweise Disallow: /private/, während die *-Gruppe Allow: /private/ enthält, wird der Zugriff auf /private/ für Googlebot dennoch blockiert.

Ein besonderer Fall sind hyphenierte Tokens wie Googlebot-Image. Hier greift die sogenannte Parent-Token-Regel: Der Crawler prüft zunächst, ob eine Gruppe mit dem exakten Token existiert. Falls nicht, fällt er auf den übergeordneten Token (Googlebot) zurück. Erst wenn auch dieser nicht vorhanden ist, wird die *-Gruppe berücksichtigt. Diese Hierarchie sorgt dafür, dass spezifische Crawler-Versionen gezielt gesteuert werden können, ohne die Regeln für den Haupt-Crawler zu beeinflussen.

Der Robots.txt-Prüfer simuliert diesen Auswahlprozess präzise und zeigt an, welche Gruppe für einen bestimmten Crawler gilt. So lässt sich vorab prüfen, ob die gewünschten Regeln greifen, etwa wenn man GPTBot für bestimmte Pfade sperren möchte, während Googlebot weiterhin Zugriff hat.

Sobald ein Crawler seine relevante Gruppe in der robots.txt gefunden hat, muss er entscheiden, welche Regel für eine bestimmte URL gilt. Hier kommt das Prinzip „Longest-Match-Wins“ ins Spiel: Die Regel mit der längsten Übereinstimmung gewinnt. Das bedeutet, dass nicht die erste passende Regel angewendet wird, sondern die spezifischste. Ein Beispiel verdeutlicht dies:

Angenommen, die robots.txt enthält folgende Regeln: - Disallow: /dokumente/ - Allow: /dokumente/offentlich/ - Disallow: /dokumente/offentlich/vertraulich.pdf

Für die URL https://example.com/dokumente/offentlich/vertraulich.pdf würde die dritte Regel greifen, da sie die längste Übereinstimmung aufweist. Die zweite Regel (Allow) wird ignoriert, obwohl sie ebenfalls passt. Bei gleich langen Übereinstimmungen (etwa wenn sowohl Allow: /dokumente/ als auch Disallow: /dokumente/ vorhanden wären) setzt sich die Allow-Regel durch.

Zusätzlich unterstützen moderne Crawler die Wildcards * und $. Das Sternchen * steht für beliebige Zeichenfolgen, während das Dollarzeichen $ das Ende einer URL markiert. So blockiert Disallow: /*.pdf$ alle PDF-Dateien, unabhängig von ihrem Pfad, während Disallow: /downloads/* alle Unterseiten des Verzeichnisses /downloads/ sperrt. Der Robots.txt-Prüfer berücksichtigt diese Syntax und zeigt an, welche Regel für eine URL entscheidend ist, inklusive der genauen Zeilennummer in der robots.txt.

Ein häufiger Fehler ist die Annahme, dass eine leere Disallow-Regel (Disallow:) alles blockiert. Tatsächlich bewirkt sie das Gegenteil: Sie erlaubt den Zugriff auf alle URLs. Ebenso wichtig ist, dass eine URL, die auf keine Regel passt, standardmäßig erlaubt ist. Wer also versehentlich / in einer Allow-Regel vergisst, könnte damit den gesamten Zugriff blockieren, ein Szenario, das der Prüfer sofort aufdeckt.

Mit dem Aufkommen von KI-basierten Suchmaschinen und Textgeneratoren wie ChatGPT oder Claude wird die Steuerung von KI-Crawlern in der robots.txt immer wichtiger. Diese Crawler (etwa GPTBot, ClaudeBot oder Google-Extended) durchsuchen Websites, um Daten für Trainingszwecke oder Antwortgenerierung zu sammeln. Der Robots.txt-Prüfer ermöglicht es, gezielt zu testen, ob diese Crawler auf bestimmte Inhalte zugreifen dürfen.

Ein zentrales Element ist dabei die Content-Signal-Zeile, die in der RFC 9309 als maschinenlesbare Angabe für Nutzungspräferenzen definiert ist. Sie kann drei Werte annehmen: - search: Die Inhalte dürfen für Suchmaschinen verwendet werden. - ai-input: Die Daten dürfen als Eingabe für KI-Systeme dienen. - ai-train: Die Inhalte dürfen zum Training von KI-Modellen genutzt werden.

Der Robots.txt-Prüfer zeigt an, welcher Content-Signal-Wert in der relevanten Gruppe gesetzt ist. Allerdings ist wichtig zu verstehen, dass diese Zeile keine technische Blockade darstellt. Sie dient lediglich als Hinweis für Crawler, die sich an die Spezifikation halten. Ein Crawler wie GPTBot könnte theoretisch trotzdem auf Inhalte zugreifen, wenn keine explizite Disallow-Regel existiert.

Ein typisches Szenario für deutsche Verlage oder Unternehmen ist die gezielte Steuerung von KI-Crawlern. Möchte man beispielsweise verhindern, dass GPTBot auf Presseartikel zugreift, während Googlebot weiterhin indexieren darf, könnte die robots.txt folgende Gruppen enthalten:

User-agent: Googlebot
Allow: /presse/

User-agent: GPTBot
Disallow: /presse/
Content-Signal: search

Mit dem Robots.txt-Prüfer lässt sich vorab testen, ob diese Regeln wie gewünscht greifen. Besonders nützlich ist die Funktion, mehrere URLs gleichzeitig zu prüfen (etwa /presse/artikel1.html und /blog/neuigkeiten.html), um sicherzustellen, dass nur die gewünschten Pfade blockiert werden. Wer seine robots.txt für KI-Crawler optimieren möchte, findet im AI-Crawler-Robots.txt-Generator ein passendes Werkzeug, um die Regeln korrekt zu formulieren.

Auch erfahrene Webentwickler und SEO-Experten machen bei der Erstellung einer robots.txt immer wieder dieselben Fehler. Der Robots.txt-Prüfer hilft, diese Probleme frühzeitig zu erkennen, bevor die Datei live geht. Ein klassischer Fehler ist das Platzieren von Regeln vor der ersten User-agent-Zeile. Da die robots.txt von oben nach unten gelesen wird, ignorieren Crawler alle Anweisungen, die vor dem ersten User-agent stehen. Der Prüfer warnt in solchen Fällen mit einer klaren Fehlermeldung.

Ein weiteres häufiges Problem sind relative Pfade. Regeln wie Disallow: dokumente/ sind ungültig, da alle Pfade mit einem Schrägstrich beginnen müssen (Disallow: /dokumente/). Auch Umlaute oder Sonderzeichen in Pfaden können zu Problemen führen, wenn sie nicht korrekt kodiert sind. Der Prüfer zeigt an, ob eine Regel syntaktisch korrekt ist, und markiert ungültige Pfade.

Besonders tückisch ist die Crawl-delay-Direktive. Obwohl sie von einigen Crawlern wie Bing unterstützt wird, ignoriert Google sie komplett. Der Robots.txt-Prüfer weist darauf hin, dass diese Anweisung nicht zum offiziellen Standard (RFC 9309) gehört und daher mit Vorsicht zu verwenden ist. Ähnlich verhält es sich mit herstellerspezifischen Direktiven wie Host (Yandex) oder Clean-param (Yandex), die der Prüfer als Warnung ausgibt.

Ein weiterer Stolperstein ist die Verwechslung von Crawling und Indexierung. Viele Nutzer gehen fälschlicherweise davon aus, dass eine Disallow-Regel eine URL aus den Suchergebnissen entfernt. Tatsächlich steuert robots.txt nur das Crawling, nicht die Indexierung. Eine blockierte URL kann trotzdem in den Suchergebnissen erscheinen, wenn sie von anderen Seiten verlinkt wird. Der Prüfer klärt diesen Unterschied auf und verweist auf Alternativen wie das noindex-Meta-Tag.

Auch die Groß- und Kleinschreibung spielt eine Rolle: Pfade sind case-sensitive. Eine Regel wie Disallow: /Dokumente/ blockiert nicht /dokumente/. Der Robots.txt-Prüfer berücksichtigt dies und zeigt an, welche Regeln für eine bestimmte URL gelten, unabhängig von der Schreibweise in der robots.txt.

Der Robots.txt-Prüfer ist ein leistungsstarkes Werkzeug, um die Regeln einer robots.txt zu testen, doch er hat klare Grenzen, die bewusst gewählt sind. Der größte Unterschied zu anderen Tools wie der robots.txt-Analyse in der Google Search Console: Der Prüfer arbeitet ausschließlich mit dem Text, den der Nutzer eingibt. Es wird keine Live-Datei von einer Website abgerufen. Das hat Vorteile: Man kann Entwürfe testen, bevor sie veröffentlicht werden, und muss keine Änderungen an der Live-Umgebung vornehmen. Auch private oder noch nicht veröffentlichte Websites lassen sich problemlos prüfen, ohne dass die Datei öffentlich zugänglich sein muss.

Ein weiterer wichtiger Punkt: Der Prüfer simuliert das Verhalten von Crawlern gemäß RFC 9309, kann aber keine Garantie geben, dass reale Crawler exakt gleich reagieren. Einige Crawler wie Baidu oder Naver halten sich nicht strikt an den Standard und interpretieren Regeln anders. Auch Google weicht in seltenen Fällen von der Spezifikation ab, etwa bei der Behandlung von Prozentkodierungen in URLs. Der Robots.txt-Prüfer normalisiert diese nicht, sondern behandelt sie wortwörtlich.

Ebenso wenig kann das Tool die tatsächliche Indexierung einer URL überprüfen. Es zeigt lediglich an, ob eine URL gemäß der robots.txt gecrawlt werden darf, nicht, ob sie in Suchergebnissen erscheint oder ob Suchmaschinen sie tatsächlich besucht haben. Für solche Fragen sind Tools wie die Google Search Console oder der Web-Bot-Auth-Key-Generator besser geeignet, der die Identität von Crawlern verifiziert.

Ein weiterer bewusster Verzicht ist die fehlende Unterstützung für dynamische robots.txt-Dateien, die serverseitig generiert werden. Da der Prüfer nur statischen Text analysiert, können keine serverseitigen Logiken wie PHP- oder Apache-Konfigurationen berücksichtigt werden. Wer solche Dateien testen möchte, muss den generierten Text manuell kopieren und einfügen.

Trotz dieser Einschränkungen ist der Robots.txt-Prüfer ideal für die tägliche Arbeit von SEO-Experten und Entwicklern. Er ist kostenlos, erfordert keine Anmeldung und läuft vollständig im Browser. Dadurch bleiben sensible Daten wie Entwürfe oder interne URLs lokal auf dem Gerät. Das ist ein entscheidender Vorteil für Datenschutz und Sicherheit.

Ein deutsches Nachrichtenportal möchte seine Inhalte gezielt für Suchmaschinen freigeben, gleichzeitig aber verhindern, dass KI-Systeme wie ChatGPT die Artikel für Trainingszwecke nutzen. Mit dem Robots.txt-Prüfer lässt sich eine solche Konfiguration vorab testen, ohne dass Änderungen an der Live-Website nötig sind.

Die gewünschte robots.txt könnte so aussehen:

User-agent: Googlebot
Allow: /artikel/
Allow: /nachrichten/
Content-Signal: search

User-agent: GPTBot
Disallow: /artikel/
Disallow: /nachrichten/
Content-Signal: search

User-agent: *
Disallow: /admin/
Disallow: /intern/

In diesem Beispiel dürfen Googlebot und andere Suchmaschinen-Crawler auf die Verzeichnisse /artikel/ und /nachrichten/ zugreifen, während GPTBot explizit blockiert wird. Die Content-Signal-Zeile gibt an, dass die Inhalte für Suchzwecke genutzt werden dürfen, eine Information, die für KI-Crawler jedoch irrelevant ist, da sie durch die Disallow-Regel ohnehin keinen Zugriff erhalten.

Mit dem Robots.txt-Prüfer lässt sich nun testen, ob die Regeln wie gewünscht greifen. Dazu gibt man folgende URLs ein: - /artikel/klimawandel-2024.html - /nachrichten/politik/ - /admin/login.php

Für Googlebot sollten die ersten beiden URLs als „erlaubt“ markiert werden, während GPTBot sie als „blockiert“ anzeigt. Die dritte URL sollte für beide Crawler gesperrt sein. Der Prüfer zeigt zudem an, welche Regel jeweils entscheidend war, etwa Disallow: /artikel/ in Zeile 7 für GPTBot.

Ein häufiger Fehler in solchen Konfigurationen ist die Annahme, dass die Content-Signal-Zeile eine technische Blockade darstellt. Tatsächlich ist sie nur ein Hinweis für Crawler, die sich an die Spezifikation halten. Ein nicht konformer Crawler könnte die Regeln ignorieren. Daher ist es wichtig, zusätzlich zu Content-Signal auch Disallow-Regeln zu setzen, wenn bestimmte Inhalte wirklich gesperrt werden sollen.

Wer seine robots.txt für KI-Crawler optimieren möchte, findet im AI-Crawler-Robots.txt-Generator ein passendes Werkzeug, um die Regeln korrekt zu formulieren. Der Generator erstellt eine valide robots.txt, die anschließend mit dem Robots.txt-Prüfer getestet werden kann. Das ist ein effizienter Workflow für Publisher und Website-Betreiber.

Die robots.txt ist seit Jahrzehnten der Standard, um Crawlern den Zugriff auf Websites zu steuern. Doch mit dem Aufkommen von KI-Systemen wie Sprachmodellen oder Bildgeneratoren reicht sie allein oft nicht mehr aus. Hier kommt die llms.txt ins Spiel, eine Ergänzung zur robots.txt, die speziell für KI-Crawler gedacht ist. Während die robots.txt den Zugriff auf URLs regelt, definiert die llms.txt Nutzungsbedingungen für die Inhalte, die von KI-Systemen verarbeitet werden dürfen.

Der Robots.txt-Prüfer ist ideal, um zu testen, ob bestimmte Crawler wie GPTBot oder ClaudeBot auf bestimmte Pfade zugreifen dürfen. Er zeigt an, welche Regeln für einen Crawler gelten und ob eine URL blockiert wird. Die llms.txt hingegen geht einen Schritt weiter: Sie ermöglicht es Website-Betreibern, detaillierte Nutzungsrichtlinien für KI-Systeme festzulegen, etwa ob Inhalte für Trainingszwecke, zur Antwortgenerierung oder zur Suche verwendet werden dürfen. Wer beide Dateien kombiniert, kann Crawling und Nutzung getrennt steuern.

Ein Beispiel: Ein deutscher Verlag möchte, dass seine Artikel von Suchmaschinen indexiert werden, aber nicht von KI-Systemen für das Training von Sprachmodellen genutzt werden. Die robots.txt könnte so aussehen:

User-agent: Googlebot
Allow: /artikel/

User-agent: GPTBot
Disallow: /artikel/

Die llms.txt würde zusätzlich festlegen, dass die Inhalte zwar für Suchzwecke (search), aber nicht für KI-Training (ai-train) genutzt werden dürfen:

User-agent: GPTBot
Usage: search

Mit dem llms.txt-Generator lässt sich eine solche Datei erstellen, während der Robots.txt-Prüfer sicherstellt, dass die Crawling-Regeln korrekt umgesetzt sind. Beide Tools ergänzen sich: Die robots.txt steuert den Zugriff, die llms.txt die Nutzung der Inhalte.

Ein weiterer Unterschied liegt in der Reichweite: Die robots.txt wird von fast allen Crawlern unterstützt, während die llms.txt noch relativ neu ist und nicht von allen KI-Systemen berücksichtigt wird. Dennoch ist sie eine sinnvolle Ergänzung, um Nutzungsbedingungen klar zu kommunizieren. Wer seine Website für die Zukunft rüsten möchte, sollte beide Dateien nutzen und mit den passenden Tools von Callculation testen und optimieren.