So testen Sie Ihre robots.txt und finden Sperrfehler

Warum lohnt sich ein Test der robots.txt?

Ein Test lohnt sich, weil eine einzige Zeile wie „Disallow: /“ alle Seiten einer Website für Crawler sperren kann, während die Website im Browser normal läuft. Die robots.txt ist eine Textdatei im Stammverzeichnis, die Crawlern sagt, welche Pfade sie abrufen dürfen. Wie Sie Gruppen und Regeln anlegen, erklärt der Ratgeber robots.txt aufsetzen und richtig steuern.

Für B2B-Firmen wiegt ein Sperrfehler schwer: Käufer fragen heute auch ChatGPT, Perplexity oder Google AI nach Anbietern, und ein Crawler, der Ihre Seiten nicht abrufen darf, kann deren Inhalte in der Regel nicht für Antworten heranziehen.

Die Datei regelt das Crawlen. Eine gesperrte Adresse kann trotzdem im Index stehen, wenn andere Seiten auf sie verlinken; der Bericht „Seitenindexierung“ führt dafür die Statuszeile „Indexiert, obwohl durch robots.txt-Datei blockiert“. Soll eine Seite aus der Suche verschwinden, entfernen Sie die Sperre und setzen noindex. Wie Google Seiten aufnimmt, beschreibt der Ratgeber zur Indexierung bei Google.

Wie prüfen Sie die robots.txt im Browser und in der Search Console?

Sie prüfen die Datei zuerst im Browser und danach im robots.txt-Bericht der Search Console.

1. Rufen Sie ihredomain.de/robots.txt auf. Erwartet werden Klartext und der Status 200. Die Datei gilt nur für Host, Protokoll und Port, unter denen sie liegt; eine Subdomain oder die http-Variante braucht eine eigene. Laut der robots.txt-Spezifikation von Google wertet Google höchstens 500 KiB aus.
2. Öffnen Sie in der Search Console die Einstellungen und dort den robots.txt-Bericht. Er steht für Domain-Properties und URL-Präfix-Properties auf Domainebene bereit und deckt die 20 wichtigsten Hosts ab. Die Versionshistorie reicht 30 Tage zurück.
3. Lesen Sie die Spalten „Abrufstatus“ und „Probleme“ (Tabelle unten).
4. Haben Sie die Datei korrigiert, klicken Sie in der Dateiliste neben der Datei auf „Weitere Einstellungen“ und wählen „Erneutes Crawlen beantragen“. Ob Google die bisher gesperrten Seiten damit sofort wieder crawlt, ist nicht sicher.

Wie testen Sie einzelne Adressen gegen die Regeln?

Einzelne Adressen testen Sie mit dem URL-Prüftool der Search Console, das anzeigt, ob eine URL blockiert ist, oder mit einem Validator, der eine URL-Liste gegen die Live-Datei oder einen Entwurf prüft. Nehmen Sie je Seitentyp eine Beispieladresse: Startseite, Leistungsseite, Ratgeber, Produktseite, Sitemap und die Skript- und Stildateien, die Ihre Seiten zum Darstellen laden.

Zum Auswerten gilt: Maßgeblich ist die Regel mit dem längsten passenden Pfad; sind zwei widersprüchliche Regeln gleich lang, setzt sich die weniger restriktive durch, also Allow. Pfade unterscheiden Groß- und Kleinschreibung, „*“ steht für beliebige Zeichen, „$“ für das Adressende.

Entwickler können Googles quelloffenen robots.txt-Parser lokal ausführen. Er prüft eine Adresse und einen User-Agent gegen eine lokale Datei und meldet ALLOWED oder DISALLOWED. So lässt sich ein Entwurf vor dem Livegang testen.

Was findet ein Validator, und was übersieht er?

Ein Validator findet Syntaxfehler und Regeln, die Adressen blockieren; ob eine Sperre gewollt ist, entscheidet er nicht. Das ist wichtig, weil Google ungültige Zeilen ignoriert: Eine Zeile wie „Noindex: /intern/“ hat keine Wirkung, und die Website zeigt keinen Fehler an.

Das findet ein Validator

• Felder, die Google nicht kennt: Laut Googles Spezifikation werden nur „user-agent“, „allow“, „disallow“ und „sitemap“ unterstützt, andere wie „crawl-delay“ nicht.
• Sitemap-Zeilen ohne vollständige Adresse mit Protokoll und Host.
• Dateien über 500 KiB, deren Ende Google nicht mehr liest.
• Adressen, die eine Regel blockiert.

Das übersieht er

• Server, die einen Bot trotz Freigabe abweisen. Firewall, CDN oder Bot-Schutz können mit 403 antworten; der Bericht „Seitenindexierung“ nennt das „Wegen Zugriffsverbot (403) blockiert“.
• Den Indexstatus. Ob eine Seite im Index steht, zeigt der Ratgeber zum Indexstatus bei Google.
• Abweichende Auslegung von Sonderfällen wie Wildcards; gleichen Sie wichtige Ergebnisse mit dem URL-Prüftool ab.

Welche Sperrfehler entstehen nach Relaunch, Umzug oder CMS-Update?

Sperrfehler entstehen nach Relaunch, Umzug oder CMS-Update, wenn eine Datei an den falschen Ort gelangt oder nicht mehr zur neuen Struktur passt. Typische Muster mit Lösung:

Sichern Sie vor jeder Änderung den alten Stand der Datei, dann lässt sich ein Fehler zurücknehmen. Wie sich technische Prüfungen und KI-Sichtbarkeit gemeinsam planen lassen, beschreibt der Ratgeber zu technischem SEO und KI-Sichtbarkeit.

Wie prüfen Sie KI-Bots wie GPTBot und ClaudeBot mit?

Prüfen Sie jeden KI-Bot einzeln, denn die Anbieter trennen Training, Suche und Abruf auf Nutzerwunsch. Stand 08.11.2026 gilt:

Die Aufgaben der OpenAI-Bots beschreibt die Crawler-Übersicht von OpenAI. Für Claude gilt die robots.txt je Subdomain. Hat ein Bot eine eigene Gruppe, etwa für GPTBot, wendet er nur deren Regeln an; die Gruppe „*“ kommt nicht dazu. Testen Sie deshalb jeden Bot mit seiner eigenen Kennung.

Ergänzend zur Freigabe in der robots.txt lässt sich eine llms.txt anlegen; die Anleitung steht im Ratgeber zur llms.txt.

Wie oft sollten Sie die robots.txt kontrollieren?

Kontrollieren Sie die Datei sofort nach jeder Änderung an Domain, Hosting, CMS oder URL-Struktur und sonst etwa einmal im Monat. Der Monatsrhythmus passt zur Versionshistorie des Berichts, die 30 Tage zurückreicht; Google speichert die Datei in der Regel bis zu 24 Stunden, ein Fehler wirkt also schnell.

• Vor dem Livegang: Entwurf gegen die URL-Liste der neuen Website testen.
• Am Tag des Livegangs: Aufruf im Browser, Status 200, Größe unter 500 KiB, kein „Disallow: /“.
• Am Tag danach: Bericht öffnen, Abrufstatus „Abgerufen“ und Zahl der Probleme prüfen.
• Nach jedem CMS- oder Plugin-Update: Inhalt mit dem gesicherten Stand vergleichen.
• Monatlich: Regeln, KI-Bots und Sitemap-Zeilen kontrollieren.

Auch strukturierte Daten brauchen eine regelmäßige Kontrolle; wie Sie sie selbst prüfen, steht im Ratgeber zum Testen strukturierter Daten.

Häufige Fragen von Entscheidern

Was passiert, wenn die robots.txt einen Serverfehler liefert?

Bei einem 5xx-Fehler stoppt Google das Crawlen zunächst für 12 Stunden und nutzt danach bis zu 30 Tage lang die letzte gültige Fassung der Datei. Gibt es keine zwischengespeicherte Fassung, gelten keine Einschränkungen. Kontrollieren Sie die Datei deshalb nach jedem Serverproblem.

Wie lange dauert es nach einer Korrektur, bis Google die Seiten wieder crawlt?

Nach einem Antrag auf erneutes Crawlen kann es einige Tage bis mehrere Wochen dauern. Mehrere Anträge für dieselbe URL beschleunigen nichts, und für einzelne URLs gilt ein Kontingent. Die Datei selbst speichert Google in der Regel bis zu 24 Stunden zwischen.

Welcher robots.txt-Validator ist der richtige?

Der richtige Validator wendet die Regeln von Google an, nimmt eine URL-Liste entgegen und prüft die Live-Datei ebenso wie einen Entwurf. Er sollte den HTTP-Status der Datei anzeigen und den User-Agent wählbar machen, damit Sie auch GPTBot oder ClaudeBot testen. Gleichen Sie wichtige Ergebnisse mit dem URL-Prüftool ab. Für Bing bieten die Bing Webmaster Tools einen eigenen robots.txt-Tester.

Hält ein Disallow vertrauliche Seiten geheim?

Nein, die robots.txt ist öffentlich abrufbar und schützt keine Inhalte. Nicht alle Crawler halten sich an die Regeln, und gesperrte Adressen können im Index erscheinen, wenn andere Seiten auf sie verlinken. Vertrauliche Seiten gehören hinter einen Passwortschutz; aus der Suche halten Sie Seiten mit noindex.

Gibt es den robots.txt-Tester der Search Console noch?

Nein, den früheren robots.txt-Tester hat Google Ende 2023 eingestellt. An seine Stelle trat der robots.txt-Bericht in den Einstellungen der Search Console, der Abrufstatus, Probleme und die Versionshistorie der letzten 30 Tage zeigt. Ob eine einzelne Adresse blockiert ist, prüfen Sie im URL-Prüftool. Einen Entwurf testen Sie lokal mit Googles quelloffenem Parser.