Wer heute "robots.txt tester" sucht, landet öfter bei einem toten Link als bei einem funktionierenden Werkzeug. Google hat den alten robots.txt-Tester im November 2023 aus der Search Console entfernt, ohne großen Nachfolge-Trubel. Das Tool ist weg, die Datei selbst ist es nicht: robots.txt entscheidet weiterhin, welche Crawler welche Bereiche deiner Website betreten dürfen, und ein Tippfehler darin kann eine ganze Domain aus der Suche werfen. Dieser Artikel zeigt, wie du deine Datei heute testest, welche Regeln robots.txt wirklich kennt und warum die pauschale Blockade von KI-Crawlern meistens die falsche Reaktion auf eine berechtigte Sorge ist.
Was aus dem alten Google-Tester geworden ist
Der klassische robots.txt-Tester lebte in der alten Google Search Console und zeigte live, ob eine bestimmte URL für einen bestimmten User-Agent gesperrt war. Google hat ihn im November 2023 endgültig abgeschaltet, bestätigt unter anderem von Search Engine Land und Search Engine Roundtable am 15. November desselben Jahres. An seiner Stelle steht seither der robots.txt-Bericht: Search Console → Einstellungen → robots.txt-Bericht.
Der Bericht zeigt die robots.txt der bis zu 20 wichtigsten Hosts deiner Property, wann Google sie zuletzt gecrawlt hat, sowie Warnungen und Fehler beim Parsen. Ein Button erlaubt zusätzlich, einen erneuten Crawl anzufordern, statt auf den nächsten automatischen Durchlauf zu warten. Klingt praktisch, hat aber eine Hürde: Du brauchst eine verifizierte Property in der Search Console. Für eine schnelle Prüfung während der Entwicklung, oder wenn du die robots.txt eines fremden Projekts checken willst, ist das ein Umweg zu viel.
Genau für diesen Fall gibt es den SchemaValid Robots.txt-Tester: Du fügst den Inhalt der Datei oder die URL ein, das Tool zeigt sofort, welche Pfade für welchen User-Agent erlaubt oder gesperrt sind, kostenlos und ohne Konto. Der Unterschied zum Search-Console-Bericht ist der Zeitpunkt: Google zeigt dir, was es beim letzten Crawl gesehen hat, ein Ad-hoc-Tester zeigt dir sofort, was aktuell in der Datei steht.
Was robots.txt wirklich kann
robots.txt ist keine Skriptsprache und kein Sicherheitsmechanismus, sondern eine sehr kurze Liste von Regeln nach dem Robots-Exclusion-Protokoll. Google unterstützt laut eigener Dokumentation "How Google Interprets the robots.txt Specification" genau vier Felder.
| Feld | Bedeutung | Groß-/Kleinschreibung |
|---|---|---|
user-agent | Legt fest, für welchen Crawler die folgenden Regeln gelten | Feldname unwichtig, Wert case-insensitiv |
disallow | Verbietet das Crawlen eines Pfads oder Präfixes | Feldname case-insensitiv, Pfad case-sensitiv |
allow | Erlaubt einen Pfad, auch innerhalb eines gesperrten Bereichs | Feldname case-insensitiv, Pfad case-sensitiv |
sitemap | Verweist auf die URL der XML-Sitemap | Feldname case-insensitiv, URL case-sensitiv |
Bei widersprüchlichen Regeln gewinnt der längere, spezifischere Pfad; bei gleicher Länge hat allow laut Google Vorrang vor disallow. Das ist die komplette Spezifikation. Alles andere in robots.txt-Vorlagen im Netz ist entweder herstellerspezifisch oder schlicht überholt.
Der Crawl-delay-Mythos
Googlebot unterstützt Crawl-delay nicht und ignoriert es vollständig. Google steuert seine Crawling-Rate automatisch über die Antwortzeiten deines Servers; wer die Rate bewusst drosseln will, macht das über die entsprechende Einstellung in der Search Console, nicht über robots.txt. Seit dem 1. September 2019 ignoriert Google zusätzlich noindex und nofollow in robots.txt, angekündigt im Google Search Central Blog am 2. Juli 2019 mit der Begründung, beide Regeln seien nie offiziell dokumentiert gewesen und hätten in praktisch allen Fällen anderen Regeln in derselben Datei widersprochen (Google beziffert die Ausnahme auf 0,001% aller robots.txt-Dateien). Bing und DuckDuckGo respektieren Crawl-delay nach gängiger SEO-Praxiserfahrung weiterhin, eine offizielle Einzelquelle mit Zahl dafür gibt es allerdings nicht.
Crawl-delay in einer robots.txt zu setzen und sich dabei sicher zu fühlen ist ein bisschen wie ein Schild "Bitte langsam fahren" vor eine Baustelle zu stellen, an der nur Google vorbeikommt. Es schadet nicht, aber es bringt auch nichts, wenn der einzige Adressat es gar nicht liest.
KI-Crawler gezielt erlauben statt pauschal blockieren
Die naheliegende Reaktion vieler Websites auf KI-Crawler ist eine Pauschalsperre: User-agent: * und dann alles dicht. Das ist verständlich, denn niemand füttert gern ein fremdes Trainingsmodell ohne Gegenleistung. Trotzdem ist die Position dieses Artikels: Pauschales Blocken ist meistens die falsche Antwort, weil es Live-Suchcrawler mit derselben Sperre trifft wie Trainingscrawler und dich damit aus KI-gestützten Suchergebnissen fernhält, in denen du eigentlich sichtbar sein willst.
| Bot | Anbieter | Zweck | Befolgt robots.txt laut Doku |
|---|---|---|---|
| GPTBot | OpenAI | Sammlung von Trainingsdaten (seit Aug. 2023) | Ja |
| OAI-SearchBot | OpenAI | Indexierung für die ChatGPT-Suche | Ja |
| ChatGPT-User | OpenAI | Live-Abruf im Auftrag eines Nutzers | Umstritten, siehe unten |
| ClaudeBot | Anthropic | Web-Sammlung | Ja |
| Claude-SearchBot | Anthropic | Claude-Suchindex | Ja |
| Claude-User | Anthropic | Live-Abruf im Auftrag eines Nutzers | Ja, laut Anthropic |
| PerplexityBot | Perplexity | Indexierung | Ja |
| Perplexity-User | Perplexity | Live-Abruf im Auftrag eines Nutzers | Umstritten, siehe unten |
| Google-Extended | Steuert Nutzung für Gemini/Vertex-AI-Training und -Grounding | Ja, eigenes Steuer-Token | |
| CCBot | Common Crawl | Allgemeiner Web-Crawl, Basis vieler Fremdmodelle | Ja |
| Applebot-Extended | Apple | Steuert, ob Applebot-Daten für Apple-Intelligence-Training genutzt werden | Ja, eigenes Steuer-Token |
Bei den reinen Crawl-Bots der großen Anbieter ist die robots.txt-Befolgung offiziell dokumentiert: OpenAI, Anthropic und Perplexity bestätigen sie für GPTBot, ClaudeBot und PerplexityBot, Common Crawl prüft laut eigener Doku vor jedem Abruf. Anders bei den "User"-Varianten, die live im Namen eines einzelnen Chat-Nutzers abrufen: Anthropic erklärt, auch Claude-User halte sich daran. OpenAI schreibt für ChatGPT-User inzwischen selbst, robots.txt-Regeln griffen bei nutzerinitiierten Anfragen möglicherweise nicht; für Perplexity-User gibt es nur widersprüchliche Community-Berichte ohne Primärquelle. Beides ist ehrlich unklar, und jede Behauptung, die das als gesicherten Fakt verkauft, verkauft dir etwas, das niemand nachgeprüft hat.
Für Google-Extended und Applebot-Extended gilt eine Besonderheit, die in Blogposts oft untergeht: Beides sind reine Steuer-Token ohne eigenen HTTP-User-Agent. Google-Extended hat keinen Einfluss auf die normale Google-Suche, sondern regelt ausschließlich Gemini und Vertex AI. Applebot-Extended crawlt selbst nichts, sondern entscheidet, ob die vom normalen Applebot bereits gesammelten Daten für das Training von Apple Intelligence genutzt werden dürfen. Wer Applebot generell erlaubt, hat Applebot-Extended damit nicht automatisch mit erlaubt, das braucht eine eigene Zeile.
Praktische Empfehlung
Statt einer Pauschalsperre lohnt sich eine gezielte Regel pro Zweck: Trainingscrawler wie GPTBot oder ClaudeBot sperren, ohne die Suchcrawler OAI-SearchBot und PerplexityBot mitzutreffen. Wer in KI-Suchergebnissen zitiert werden will, sollte genau diese ausdrücklich erlauben. Der Robots.txt-Generator baut solche differenzierten Regeln pro Bot. Wie sichtbar deine Website für KI-Systeme insgesamt ist, prüft der AI-Readiness-Checker.
Dass die Sorge hinter dem Blocking nicht aus der Luft gegriffen ist, zeigen zwei Zahlen. Das Reuters Institute for the Study of Journalism zählte in einem Faktenblatt vom Februar 2024, Datenstand Ende 2023, bei großen Nachrichtenverlagen aus zehn Ländern: 48% blockierten OpenAIs Crawler, aber nur 24% Googles KI-Crawler, mit einer Spanne von 79% in den USA bis 20% in Mexiko und Polen. Eine akademische Studie (arXiv 2510.10315, Oktober 2025), Erhebungszeitraum September 2023 bis Mai 2025, fand einen deutlichen Anstieg: Der Anteil seriöser, etablierter Websites mit AI-Blocking stieg von 23% im September 2023 auf knapp 60% im Mai 2025, geblockte Seiten verbieten im Schnitt 15,5 AI-User-Agents, Fehlinformationsseiten weniger als einen. Für tagesaktuelle Zahlen aus 2026 gibt es keine seriös belegte Einzelquelle, deshalb bleibt es bei diesen zwei Ankerpunkten.
Häufige Fehler beim Testen
Die meisten robots.txt-Fehler sind kein Missverständnis der Syntax, sondern schlicht Unaufmerksamkeit an der falschen Stelle. Ein klassisches Beispiel: Ein Staging-Server bekommt beim Aufsetzen Disallow: / für alle Crawler, damit Google die Testversion nicht indexiert. Beim Go-Live wird die Domain umgezogen, aber die robots.txt-Datei wird unverändert mitkopiert. Ergebnis: Die produktive Website ist komplett für jeden Crawler gesperrt, und niemand merkt es, bis der organische Traffic einbricht.
Ein häufig übersehener Punkt ist das sitemap-Feld selbst: Fehlt die Zeile, findet Google deine Sitemap nur über die manuelle Einreichung in der Search Console, nicht automatisch beim Crawl der robots.txt. Wie du eine Sitemap überhaupt richtig aufbaust und dort einträgst, steht im Artikel XML-Sitemap erstellen.
Ein zweiter häufiger Fehler betrifft CSS- und JavaScript-Verzeichnisse: Google rendert Seiten wie ein Browser, und sind /assets/ oder /static/ gesperrt, rendert es die Seite im schlimmsten Fall als leere Hülle. Ein dritter Punkt ist Case-Sensitivity: /Blog/ und /blog/ sind zwei unterschiedliche Pfade, eine Regel für die eine Schreibweise greift nicht automatisch für die andere. Und schließlich muss robots.txt exakt im Root liegen, unter https://deine-domain.de/robots.txt – in einem Unterverzeichnis findet sie kein Crawler, egal wie korrekt ihr Inhalt ist.