Die meisten Probleme mit der robots.txt fallen erst auf, wenn Seiten aus der Suche verschwinden oder Adressen im Index stehen, die dort nie hingehörten. Das liegt an Googles Umgang mit der Datei: Ungültige Zeilen werden still übergangen [1], und eine Sperre wirkt auf das Crawling, nicht auf den Index. Hier stehen die häufigsten Fehler und was Google in jedem Fall tut.
Wie eine korrekte Datei aufgebaut ist, erklärt der Ratgeber robots.txt richtig schreiben. Diese Seite setzt dort an, wo eine Datei schon existiert und etwas nicht stimmt.
Sperren, um Seiten aus dem Index zu holen
Der verbreitetste Denkfehler: Eine Seite soll aus Google verschwinden, also kommt sie in die robots.txt. Google schreibt dazu deutlich: "Sinn und Zweck von robots.txt-Dateien ist es nicht, Webseiten aus der Google Suche auszuschließen." [2] Eine gesperrte Adresse kann trotzdem indexiert werden, wenn andere Seiten auf sie verlinken. Sie erscheint dann ohne Beschreibung im Ergebnis [2]. In der Search Console heißt dieser Zustand "Indexiert, obwohl durch robots.txt-Datei blockiert"; was er bedeutet, steht in der FAQ unter Indexiert, obwohl durch robots.txt blockiert.
Noch heikler ist die Kombination aus Sperre und noindex. Damit Google ein noindex erkennt, muss es die Seite abrufen. Google formuliert die Bedingung so: Die Seite oder Ressource darf "nicht durch eine robots.txt-Datei blockiert werden" [4]. Wer beides gleichzeitig setzt, verhindert, dass Google das noindex je sieht. Die richtige Reihenfolge ist: erst noindex, warten, bis die Seiten aus dem Index sind, und erst dann, falls nötig, sperren.
Ähnlich verhält es sich mit Duplikaten. Google rät ausdrücklich davon ab, die robots.txt für die Kanonisierung zu verwenden [8]. Eine gesperrte Variante kann Google nicht lesen und also auch nicht mit dem Original zusammenführen.
noindex in der robots.txt
Ältere Dateien enthalten manchmal Zeilen wie Noindex: /alt/. Google hat die Verarbeitung solcher nicht dokumentierter Regeln zum 01.09.2019 eingestellt [3]. Seitdem gilt die Zeile als ungültig und wird ignoriert. Als Ersatz nannte Google damals unter anderem das noindex im robots-Meta-Tag, die Statuscodes 404 und 410, einen Passwortschutz und das Tool zum Entfernen in der Search Console [3]. Findet sich eine solche Zeile, prüfen Sie, ob die betroffenen Seiten wirklich aus dem Index sollen, und setzen Sie das noindex auf der Seite selbst oder per X-Robots-Tag.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Gesperrte Ressourcen
Sperren für Verzeichnisse wie /assets/, /js/ oder /wp-includes/ stammen oft aus einer Zeit, in der Suchmaschinen kein JavaScript ausführten. Heute rendert Google Seiten. Dafür braucht es CSS und Skripte. In der Dokumentation zu JavaScript steht: "In der Google Suche wird JavaScript aus blockierten Dateien oder auf blockierten Seiten nicht gerendert." [5] Lädt Ihre Seite Inhalte, Links oder strukturierte Daten per JavaScript nach, sieht Google davon nichts, wenn das Skript gesperrt ist. Google rät, Ressourcen nur zu sperren, wenn die Seite ohne sie kaum schlechter verstanden wird [2]. Wie Google rendert und was dabei schiefgehen kann, beschreibt Rendering durch Google.
Die Testsperre im Livebetrieb
Testumgebungen tragen oft User-agent: * mit Disallow: /, damit sie nicht in der Suche landen. Wird beim Livegang die ganze Installation kopiert, wandert diese Zeile mit. Ab dann fragt kein regelkonformer Crawler mehr Seiten an. Nach unserer Erfahrung ist das der Fehler mit den größten Folgen, weil er eine komplette Website betrifft und von außen erst auffällt, wenn die Besucherzahlen fallen. Wir empfehlen, die robots.txt in jede Checkliste für Livegang und Umzug aufzunehmen und sie unmittelbar nach dem Wechsel im Browser zu öffnen. Für die Testumgebung ist ein Passwortschutz ohnehin die sicherere Wahl, weil eine robots.txt nur eine Bitte an Crawler ist [2].
Fehler im Aufbau
Einige Fehler sind reine Schreibfehler, wirken aber wie bewusste Entscheidungen:
- Falsche Schreibweise im Pfad. Werte sind bei Google von Groß- und Kleinschreibung abhängig [1]. Disallow: /Intern/ sperrt /intern/ nicht.
- Zu kurze Präfixe. Disallow: /p sperrt jede Adresse, die mit /p beginnt, also auch /produkte/ und /presse/.
- Pfad ohne Schrägstrich am Anfang. Google verlangt, dass der Pfadwert mit / beginnt [1].
- Eine eigene Googlebot-Gruppe ohne die allgemeinen Regeln. Google kombiniert eine Gruppe für einen bestimmten Crawler nicht mit der Sternchen-Gruppe [1]. Sperren, die nur unter User-agent: * stehen, gelten für Googlebot dann nicht mehr.
- Zeilen wie Crawl-delay oder Host. Google unterstützt nur user-agent, allow, disallow und sitemap [1].
- Eine zu große Datei. Google liest höchstens 500 Kibibyte, alles danach wird ignoriert [1]. Das passiert vor allem, wenn ein System für jede Adresse eine eigene Zeile schreibt.
Was der Server antwortet
Oft ist die Datei in Ordnung, und der Server liefert sie falsch aus. Google behandelt die Statuscodes beim Abruf der robots.txt so [1]:
| Antwort | Was Google tut |
|---|---|
| 2xx | verarbeitet die Datei so, wie der Server sie liefert |
| 3xx | folgt mindestens fünf Weiterleitungen, danach gilt die Datei als nicht vorhanden (404); Weiterleitungen per JavaScript oder Meta-Refresh ignoriert Google |
| 4xx | verhält sich, als gäbe es keine gültige robots.txt, also ohne Einschränkungen; den Code 429 nimmt Google von dieser Regel ausdrücklich aus |
| 5xx | stellt in den ersten 12 Stunden das Crawling der Website ein, nutzt danach bis zu 30 Tage die letzte fehlerfreie Fassung |
Bleiben die Fehler länger als 30 Tage bestehen, verhält sich Google so, als gäbe es keine Datei, sofern die Website sonst erreichbar ist. Hat die Website allgemeine Verfügbarkeitsprobleme, stellt Google das Crawling ein [1]. Die Norm RFC 9309 geht bei Serverfehlern noch weiter: Ein Crawler MUSS dann von einer vollständigen Sperre ausgehen ("MUST assume complete disallow") [7].
Zwei Fälle kommen dabei häufig vor. Eine Firewall oder ein Bot-Schutz antwortet Crawlern auf /robots.txt mit 403 oder 503, während Browser die Datei normal sehen. Und manche Systeme leiten /robots.txt auf eine Fehlerseite um, die mit Status 200 HTML ausliefert. Google liest dann eine HTML-Seite als robots.txt und überspringt die ungültigen Zeilen. Google rät außerdem davon ab, 401 und 403 zur Drosselung des Crawlings zu nutzen [1].
So finden Sie die Fehler
- Rufen Sie https://ihre-domain/robots.txt für jeden Host und jedes Protokoll auf, also auch für Subdomains.
- Öffnen Sie in der Search Console den robots.txt-Bericht. Er zeigt für die 20 wichtigsten Hosts den letzten Abruf, den Abrufstatus und Probleme mit einzelnen Zeilen. Unter "Versionen" sehen Sie die Abrufe der letzten 30 Tage [6].
- Prüfen Sie Ihre zehn wichtigsten Seiten im URL-Prüftool. Es zeigt, ob eine Adresse durch die robots.txt blockiert ist [6].
- Gleichen Sie im Bericht zur Seitenindexierung die Gruppe "Durch robots.txt-Datei blockiert" mit Ihrer Absicht ab. Steht dort eine Seite, die ranken soll, ist die Regel zu breit.
- Haben Sie eine versehentliche Sperre entfernt, können Sie im robots.txt-Bericht ein erneutes Crawlen der Datei beantragen. Google sagt aber nicht zu, dass vorher gesperrte Adressen sofort neu gecrawlt werden [6].
Mehr zum Blockiert-Status steht unter Blockiert durch robots.txt, zum Unterschied der Mittel unter Unterschied zwischen noindex und robots.txt.
Sie haben eine Regel gefunden, deren Zweck niemand mehr kennt, und wissen nicht, ob Sie sie löschen dürfen? Stellen Sie die Frage in der gratis Sprechstunde. Sind durch eine Sperre schon Seiten aus der Suche verschwunden, übernimmt SEO NW die Aufarbeitung im Rahmen der Leistung Indexierungsprobleme beheben.
- Organisation Wie Google die robots.txt-Spezifikation interpretiert. Google Crawling-Infrastruktur. Stand 27.10.2026. abgerufen am 31.10.2026
- Organisation Einführung in robots.txt. Google Search Central. Stand 18.12.2025. abgerufen am 31.10.2026
- Organisation A note on unsupported rules in robots.txt. Google Search Central Blog. Stand 02.07.2019. abgerufen am 31.10.2026
- Organisation Aufnahme in den Suchindex mit noindex blockieren. Google Search Central. Stand 31.12.2025. abgerufen am 31.10.2026
- Organisation Grundlagen von JavaScript-SEO. Google Search Central. Stand 04.03.2026. abgerufen am 31.10.2026
- Organisation robots.txt-Bericht. Search Console-Hilfe. Stand laufend. abgerufen am 31.10.2026
- Gesetz RFC 9309: Robots Exclusion Protocol. IETF. Stand 09.2022. abgerufen am 31.10.2026
- Organisation Kanonische URLs angeben (doppelte URLs konsolidieren). Google Search Central. Stand 15.07.2026. abgerufen am 31.10.2026
Häufige Fragen
Entfernt eine Sperre in der robots.txt eine Seite aus Google?
Nein. Die robots.txt steuert das Crawling. Eine gesperrte Adresse kann weiter indexiert sein, etwa wenn andere Seiten auf sie verlinken, und erscheint dann ohne Beschreibung. Zum Entfernen dienen noindex, ein Passwortschutz oder die Statuscodes 404 und 410.
Funktioniert noindex in der robots.txt?
Nein. Google hat die Verarbeitung solcher Zeilen zum 01.09.2019 eingestellt. Das noindex gehört in das robots-Meta-Tag der Seite oder in einen X-Robots-Tag-Header.
Was passiert, wenn der Server für die robots.txt einen 503 liefert?
Google stellt das Crawling der Website in den ersten 12 Stunden ein und nutzt danach bis zu 30 Tage die letzte fehlerfreie Fassung. Ein dauerhafter Serverfehler an dieser Stelle bremst also die ganze Website.
Darf ich CSS und JavaScript sperren?
Nur, wenn Google die Seite ohne diese Dateien genauso gut versteht. Google rendert JavaScript aus gesperrten Dateien nicht. Inhalte und Links, die per Skript entstehen, bleiben dann unsichtbar.
Noch eine Frage offen?
In der gratis Sprechstunde beantworten wir Fragen zu SEO live, jeden ersten Samstag im Monat um 18 Uhr. Oder Sie rufen einfach an.
Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Haben Sie einen Fehler entdeckt? Schreiben Sie uns.
