Durch robots.txt blockiert: Was der Search-Console-Status bedeutet und wie Sie ihn beheben

Der Status durch robots.txt blockiert erscheint im Bericht zur Seitenindexierung der Google Search Console, unter den Gründen, warum Seiten nicht indexiert werden. Die Dokumentation zum Bericht zur Seitenindexierung beschreibt ihn in einer Zeile: Die Seite wurde durch die robots.txt-Datei Ihrer Website blockiert. Dahinter stecken zwei sehr unterschiedliche Situationen, eine gesunde und eine versehentliche Sperre, dazu ein verwirrender Verwandter: „Indexiert, obwohl durch robots.txt-Datei blockiert“. Dieser Leitfaden zeigt, wie Sie beide unterscheiden und jeweils beheben, ohne an anderer Stelle etwas kaputtzumachen. Wenn Ihnen die Datei selbst neu ist, beginnen Sie mit unserer Definition von robots.txt.

Was bedeutet „Durch robots.txt blockiert“ in der Search Console?

Ihre robots.txt-Datei liegt im Stammverzeichnis des Hosts (beispiel.de/robots.txt) und teilt Crawlern mit, welche Pfade sie abrufen dürfen. Findet Googlebot eine URL, über einen Link oder eine Sitemap, prüft er zuerst diese Datei. Passt eine Disallow-Regel für seinen User-Agent auf den Pfad, ruft er die Seite nicht ab. Die Search Console führt die URL dann unter „Durch robots.txt blockiert“.

Daraus folgen zwei Dinge. Google sieht weder den Inhalt noch den Titel, die internen Links oder Meta-Tags der Seite. Und weil Google die Seite nie liest, sieht es auch kein noindex-Tag. Der Status ist als Grund für die Nichtindexierung aufgeführt und für die meisten Websites rein informativ: Google weist selbst darauf hin, dass durch robots.txt blockierte URLs wahrscheinlich absichtlich gesperrt sind.

Zum Problem wird es, wenn die Liste Seiten enthält, die Sie bei Google sehen wollen: Produktseiten, Artikel, Kategorien oder nach einer Migration die ganze Website. Dann ist die Sperre eine direkte Ursache dafür, dass eine Website nicht bei Google erscheint, und gehört zu den technischen Fehlern, die sich am schnellsten beheben lassen.

„Durch robots.txt blockiert“ oder „Indexiert, obwohl blockiert“?

Der zweite Status wirkt widersprüchlich und beunruhigt Websitebetreiber am meisten. Googles Einführung in robots.txt erklärt ihn: robots.txt ist kein Mittel, um eine Seite aus Google herauszuhalten. Verlinken andere Seiten auf eine gesperrte URL, kann Google die URL selbst indexieren, ohne sie zu crawlen. Das Ergebnis zeigt dann die Adresse ohne Beschreibung, weil Google den Text nie gelesen hat.

Entscheidend ist, zuerst für jede URL festzulegen, was Sie wollen: indexiert oder nicht indexiert. robots.txt beantwortet eine andere Frage (gecrawlt oder nicht gecrawlt), und die Vermischung beider ist die Ursache der meisten Fehler.

Warum werden Ihre Seiten durch robots.txt blockiert?

Die meisten versehentlichen Sperren haben eine Handvoll Ursachen. Prüfen Sie sie in dieser Reihenfolge:

• Eine Staging-Regel landet in der Produktion. Disallow: / schützt eine Testumgebung, geht beim Launch mit live und blockiert alles.
• Eine CMS-Einstellung. WordPress bietet die Option „Suchmaschinen davon abhalten, diese Website zu indexieren“; andere Plattformen haben ähnliche Schalter, die robots.txt ändern oder Header hinzufügen.
• Eine zu breite Regel. Disallow: /p blockiert /produkte/ und /preise/ ebenso wie /p/. Regeln in robots.txt greifen auf den Anfang des Pfads.
• Platzhalter. * steht für eine beliebige Zeichenfolge, $ markiert das Ende einer URL. Disallow: /*? sperrt jede URL mit Parameter, darunter womöglich paginierte oder gefilterte Seiten, die indexiert werden sollen.
• Blockierte Ressourcen. Wer /assets/ oder /wp-includes/ sperrt, verbirgt das CSS und JavaScript, das Google zum Rendern braucht, und verschlechtert so das Verständnis Ihrer Inhalte.
• Eine Migration. Pfade ändern sich, die alte robots.txt bleibt, oder der neue Hoster liefert eine eigene Standarddatei aus.
• Der falsche Host. Jede Subdomain und jedes Protokoll hat eine eigene Datei: Regeln auf www.beispiel.de gelten nicht für shop.beispiel.de.

Merken Sie sich: Google folgt der spezifischsten Regel (dem längsten passenden Pfad), und sind eine Allow- und eine Disallow-Regel gleich spezifisch, gewinnt die weniger restriktive. Ein gezieltes Allow: /blog/ kann also einen Ordner unter einer breiteren Sperre wieder öffnen.

„Durch robots.txt blockiert“ Schritt für Schritt beheben

1. Betroffene URLs exportieren

Öffnen Sie in der Google Search Console Indexierung, dann Seiten, und klicken Sie auf die Zeile „Durch robots.txt blockiert“. Exportieren Sie die Liste und sortieren Sie nach Ordner. Meist erkennen Sie in einer Minute ein Muster: ein Verzeichnis, ein Parameter, eine Subdomain.

2. Gewollte Sperren von Fehlern trennen

Markieren Sie jedes Muster als „gesperrt lassen“ oder „gehört zu Google“. Warenkörbe, Checkout, Kundenkonten, interne Suchergebnisse und Adminbereiche gehören in die erste Gruppe. Alles, was eine Suchanfrage beantwortet, Links erhält oder in Ihrer XML-Sitemap steht, in die zweite. Eine URL, die zugleich in der Sitemap steht und gesperrt ist, ist ein Widerspruch, den Sie auflösen müssen.

3. Die passende Regel finden

Öffnen Sie das URL-Prüftool für eine Beispiel-URL: Es zeigt, ob Crawling erlaubt ist. Lesen Sie dann die Live-Datei oder fügen Sie die URL in unseren kostenlosen robots.txt-Checker ein, um zu sehen, welche Zeile sie für welchen User-Agent sperrt.

4. Die Datei bearbeiten

Entfernen oder verengen Sie die Regel oder ergänzen Sie ein spezifischeres Allow. Halten Sie die Änderung minimal und testen Sie sie sowohl an einer URL, die frei werden soll, als auch an einer, die gesperrt bleiben muss. Ist die Datei unübersichtlich, bauen Sie mit unserem robots.txt-Generator eine saubere Version und vergleichen Sie vor der Veröffentlichung.

5. Google die neue Datei lesen lassen

Laut seiner robots.txt-Spezifikation speichert Google robots.txt in der Regel bis zu 24 Stunden im Cache. Um das zu beschleunigen, öffnen Sie Einstellungen und dann den robots.txt-Bericht der Search Console (verfügbar für Domain-Properties) und beantragen ein erneutes Crawling der Datei. Beantragen Sie danach im URL-Prüftool die Indexierung Ihrer wichtigsten freigegebenen URLs.

6. Validieren und überwachen

Klicken Sie auf der Problemseite auf „Fehlerbehebung überprüfen“. Die Validierung kann einige Tage bis wenige Wochen dauern, und neue URLs werden geprüft, sobald Google sie erneut crawlt. Unser Leitfaden zur Google-Indexierung erklärt, was nach dem Crawling passiert, wenn Google entscheidet, ob eine Seite behalten wird.

„Indexiert, obwohl durch robots.txt-Datei blockiert“ beheben

Die Lösung hängt davon ab, was Sie mit der Seite wollen:

1. Die Seite soll bei Google erscheinen. Heben Sie die Sperre auf. Google crawlt die Seite, liest ihren Inhalt und zeigt ein normales Ergebnis mit Titel und Beschreibung.
2. Die Seite soll nicht bei Google erscheinen. Heben Sie die Sperre ebenfalls auf und setzen Sie dann <meta name="robots" content="noindex"> in den Head oder einen HTTP-Header X-Robots-Tag: noindex für PDFs und andere Dateien. Hat Google die Seite erneut gecrawlt und entfernt, können Sie sie wieder sperren, falls das Crawl-Volumen zählt, was die meisten Websites nie brauchen. Unsere Definition von noindex erklärt die Optionen.
3. Die Seite sollte gar nicht öffentlich sein. Schützen Sie sie mit einem Passwort oder entfernen Sie sie (404 oder 410). Weder robots.txt noch noindex sind Sicherheitsmaßnahmen.

Bei einer facettierten Navigation mit Tausenden Filter-URLs kann eine Sperre in robots.txt das richtige Mittel bleiben, um Crawl-Budget zu sparen. Die Warnung „Indexiert, obwohl blockiert“ bei einigen dieser URLs ist dann akzeptabel, solange die kanonischen Versionen Ihrer Kategorien crawlbar und indexiert sind.

So prüfen Sie, ob die Korrektur gewirkt hat

Drei Signale bestätigen eine erfolgreiche Korrektur. Das URL-Prüftool zeigt für die Live-URL „Crawling zulässig: Ja“. Die Zahl der blockierten Seiten im Bericht zur Seitenindexierung sinkt in den folgenden Wochen. Und die freigegebenen Seiten sammeln Impressionen im Leistungsbericht. Ein kurzer Durchlauf mit unserem Indexierbarkeits-Checker findet auch die anderen Bremsen, die oft mit robots.txt-Fehlern einhergehen: ein vergessenes noindex, ein falsches Canonical oder eine Weiterleitung.

Überwachung lohnt sich, weil diese Fehler wiederkommen. Ein Theme-Update, ein Plugin oder ein Deployment-Skript kann robots.txt umschreiben, ohne dass es jemand bemerkt. Seiten im Blick zu behalten, deren Klicks und Impressionen plötzlich fallen, ist das schnellste Frühwarnsystem.

Das GEO- und SEO-Dashboard von Sorank verbindet sich mit der Search Console und zeigt diese steigenden und fallenden Seiten in einer Ansicht. Eine durch ein Deployment eingeführte Sperre erscheint so als Gruppe rückläufiger URLs statt als langsamer, unerklärlicher Verlust.

robots.txt, KI-Crawler und GEO

robots.txt hat inzwischen ein zweites Publikum: die Crawler der KI-Assistenten. OpenAI, Anthropic, Perplexity und Google veröffentlichen jeweils User-Agents (GPTBot und OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended), die robots.txt beachten. Eine Regel für einen von ihnen oder eine pauschale Sperre mit User-agent: * entscheidet, ob ChatGPT, Claude oder Perplexity Ihre Seiten lesen können, wenn sie im Web nach Material für eine Antwort suchen.

Es gilt dieselbe Logik wie bei Google: Legen Sie pro Bot fest, was Sie wollen. Trainings-Crawler zu sperren und Such-Crawler zuzulassen, ist ein häufiger Kompromiss. Unser Leitfaden zu robots.txt für KI-Crawler listet die User-Agents und die Regeln für jeden auf. Der Glossareintrag zu KI-Crawlern erklärt, welcher Bot was tut.

Um die Wirkung dieser Entscheidungen zu sehen, verfolgen Sie die Prompts, die für Ihr Geschäft zählen. Das KI-Erwähnungs-Tracking von Sorank zeigt, ob ChatGPT, Gemini oder Claude Ihre Website zitieren und welche Wettbewerber sie stattdessen nennen.

Die Regel, die Sie sich merken sollten

robots.txt entscheidet, was Crawler lesen dürfen; noindex entscheidet, was Suchergebnisse zeigen dürfen. Sperren Sie nur Bereiche ohne Suchwert, sperren Sie nie eine Seite, die indexiert oder deindexiert werden soll, und prüfen Sie den Bericht zur Seitenindexierung nach jeder Migration und jedem Deployment. Die meisten Probleme mit „durch robots.txt blockiert“ sind in Minuten gelöst, sobald die passende Regel gefunden ist, und das Search-Console-Dashboard von Sorank hilft Ihnen, den nächsten Fall zu erkennen, bevor er Traffic kostet.