URL wird von der robots.txt-Datei blockiert: wann richtig, wann teuer

„URL wird von der robots.txt-Datei blockiert“ bedeutet, dass Google die URL nicht gecrawlt hat, weil eine Regel in Ihrer robots.txt sie ausschließt, und dass die URL nicht im Index ist. Auf den meisten Websites ist der Status korrekt: Admin-Bereiche, Warenkörbe, interne Suche und Parameter-URLs werden absichtlich gesperrt. Er kostet Sie nur dann etwas, wenn die Regel eine Seite erfasst, die in der Suche erscheinen soll, und die Aufgabe besteht darin, diese Seiten zwischen den gewollten Sperren zu finden.

Bis 2022 verwendete der Bericht zur Indexabdeckung in der Search Console dafür 2 Bezeichnungen: „Gesendete URL durch robots.txt blockiert“ für URLs aus einer eingereichten Sitemap und „Durch robots.txt-Datei blockiert“ für alle übrigen. In der englischen Oberfläche heißt der heutige Status „URL blocked by robots.txt“. Steht in Ihrem Bericht „Indexiert, obwohl durch robots.txt-Datei blockiert“, ist die URL trotz der Sperre im Index, und dieser Status hat einen eigenen Leitfaden.

Was der Status laut Google bedeutet

Googles Dokumentation zum Bericht zur Seitenindexierung (Stand: Oktober 2026) führt „URL wird von der robots.txt-Datei blockiert“ unter „Nicht indexiert“ auf und sagt, dass die Seite durch die robots.txt-Datei Ihrer Website blockiert wurde. Dieselbe Dokumentation leitet die gesamte Gruppe „Nicht indexiert“ mit dem Hinweis ein, dass diese Seiten nicht indexiert sind, aber nicht unbedingt wegen eines Fehlers.

Die Sperre hat 2 Folgen für Ihre Entscheidung:

• Die Sperre verhindert das Crawling, nicht die Indexierung. Laut Googles Dokumentation garantiert eine Sperre nicht, dass die Seite aus dem Index herausbleibt. Findet Google Informationen über die Seite, ohne sie zu laden, etwa Links von anderen Seiten, besteht eine geringe Chance, dass sie trotzdem indexiert wird und zu „Indexiert, obwohl durch robots.txt-Datei blockiert“ wechselt.
• Google sieht die Seite nie. Kein Title, kein Inhalt, keine Links darauf, kein Canonical, kein noindex. Was die Seite über sich selbst sagt, bleibt unsichtbar, solange die Regel besteht.

Ist das ein Problem? Gewollte und versehentliche Sperren trennen

Beginnen Sie mit dem Filter oben im Bericht zur Seitenindexierung. Stellen Sie ihn von „Alle bekannten Seiten“ auf „Alle eingereichten Seiten“ um. Blockierte URLs, die unter „Alle eingereichten Seiten“ erscheinen, stehen in einer eingereichten Sitemap: Sie bitten Google, sie zu indexieren, während die robots.txt das Crawling verbietet. Dieser Widerspruch ist fast immer ein Fehler, ganz gleich, wozu die Regel gedacht war.

Bei 29 externen Websites, die für ein SEOReport-Audit eingereicht wurden und deren Sitemap-Seiten wir zwischen Mai und Oktober 2026 abgerufen haben, listeten 2 (7 %) in ihrer Sitemap URLs, die ihre eigene robots.txt ausschließt. Das ist nicht das häufigste Sitemap-Problem, aber dasjenige, das Seiten blockiert, die die Website bereits als wichtig deklariert hat.

Die versehentlichen Muster, mit Vorher und Nachher

Jedes der folgenden Muster ist eine Regel, die genau so funktioniert hat, wie sie geschrieben war, und mehr blockiert hat als beabsichtigt.

1. Die Staging-Datei, die live ging. Eine Entwicklungsumgebung wird komplett gesperrt, und die Datei gelangt mit dem Rest des Builds in die Produktion.

# Before: copied from staging
User-agent: *
Disallow: /

# After: block only what should never be crawled
User-agent: *
Disallow: /cart/
Disallow: /account/

Sitemap: https://www.example.com/sitemap.xml

2. Ein zu kurzes Präfix. Google gleicht eine Regel ab dem Anfang des URL-Pfads ab, Disallow: /search blockiert also /search?q=shoes, aber auch /search-engine-basics/, einen echten Artikel.

# Before
Disallow: /search

# After: block only the search results
Disallow: /search/
Disallow: /search?

3. Eine Wildcard, die Landingpages erfasst. * steht für eine beliebige Zeichenfolge, und Googles Abgleich schließt den Query-String ein. Disallow: /*? blockiert jede URL mit einem Parameter, auch paginierte Kategorieseiten wie /shoes/?page=2, die gecrawlt werden sollten, damit die Produkte darauf gefunden werden.

# Before
Disallow: /*?

# After: keep pagination crawlable, block the rest
Disallow: /*?
Allow: /*?page=

Dieselbe Falle gilt für Dateiendungen. Auf einer Website, deren Seiten auf .php enden, blockiert Disallow: /*.php den gesamten Katalog.

4. Eine vergessene Googlebot-Gruppe. Laut Googles robots.txt-Spezifikation folgt ein Crawler nur der spezifischsten Gruppe, die ihn nennt, und spezifische Gruppen werden nicht mit der *-Gruppe zusammengeführt. Eine User-agent: Googlebot-Gruppe, die vor Jahren für eine Migration geschrieben wurde, gilt für Googlebot weiter, während das Team nur die *-Gruppe bearbeitet und sich die Sperre nicht erklären kann.

# Before: Googlebot reads only its own group
User-agent: Googlebot
Disallow: /blog/

User-agent: *
Disallow: /cart/

Die Lösung: die alte Gruppe löschen oder die aktuellen Regeln in sie übernehmen. Dieselbe Regel erklärt einen häufigen Nebeneffekt von Richtlinien für KI-Crawler: Eine Website, die benannte Gruppen für bestimmte Bots ergänzt, muss jede gemeinsame Regel in jeder dieser Gruppen wiederholen. Unsere Entscheidungstabelle für robots.txt und KI-Crawler zeigt Muster, die Regeln für Suche und KI sauber trennen.

5. Blockierte Ressourcen für das Rendering. Disallow: /assets/ oder Disallow: /static/ blockiert das CSS und JavaScript, das Ihre Seiten laden. Laut Googles Einführung in die robots.txt dürfen Sie unwichtige Ressourcen sperren, aber keine, ohne die Google die Seite schlechter versteht. Solche blockierten Dateien tauchen im Bericht zur Seitenindexierung selten als Seiten auf, suchen Sie daher von der Seite aus: Führen Sie in der URL-Prüfung einen Live-Test aus, öffnen Sie „Getestete Seite anzeigen“ und dann „Weitere Informationen“, um die Seitenressourcen zu sehen, die Google geladen hat. Prüfen Sie auch den Asset-Host: Die robots.txt gilt pro Host, Protokoll und Port, Dateien von cdn.example.com folgen also der eigenen robots.txt dieses Hosts. Ein blockiertes Skript, das den Seiteninhalt aufbaut, wiegt am schwersten auf Websites, die im Browser rendern; das behandelt unser Leitfaden zum JavaScript-Rendering.

So testen Sie eine robots.txt-Regel an einer URL

Um Googles Entscheidung vorherzusagen, brauchen Sie kein Tool. Googles Spezifikation macht daraus 4 Schritte.

flowchart TD
    A["Zu testende URL"] --> B["robots.txt auf demselben Host und Protokoll öffnen"]
    B --> C{"Gibt es eine Gruppe für Googlebot?"}
    C -->|ja| D["Nur diese Gruppe verwenden"]
    C -->|nein| E["Die *-Gruppe verwenden"]
    D --> F["Jedes Allow und Disallow auflisten, das zum Pfad passt"]
    E --> F
    F --> G{"Gibt es einen Treffer?"}
    G -->|nein| H["Erlaubt"]
    G -->|ja| I["Der längste Regelpfad gewinnt"]
    I --> J{"Allow und Disallow gleich lang?"}
    J -->|ja| H
    J -->|nein| K["Die längste Regel anwenden"]

1. Die Datei wählen. Öffnen Sie /robots.txt auf genau dem Host und Protokoll der URL. https://www.example.com/robots.txt gilt nicht für https://shop.example.com/.
2. Die Gruppe wählen. Verwenden Sie die spezifischste User-agent-Gruppe, die auf Googlebot passt. Bei User-Agent-Namen spielt die Groß-/Kleinschreibung keine Rolle.
3. Passende Regeln finden. Eine Regel passt, wenn ihr Pfad auf den Anfang von URL-Pfad und Query passt. * steht für beliebige Zeichen, $ markiert das Ende der URL, und bei Pfaden zählt die Groß-/Kleinschreibung: /Shop/ passt nicht auf /shop/.
4. Den Gewinner bestimmen. Die Regel mit dem längsten Pfad gewinnt. Bei Gleichstand zwischen Allow und Disallow verwendet Google die weniger einschränkende, also das Allow.

So sieht die Methode angewendet auf die „Nachher“-Datei aus Muster 3 aus, ergänzt um Disallow: /search:

Um Googles eigene Lesart statt Ihrer zu prüfen, führen Sie die URL-Prüfung für die URL aus. In den Crawling-Details zeigt „Crawling zulässig?“, ob eine robots.txt-Regel Google blockiert, und ein Live-Test wendet die Datei an, die Google gerade abrufen kann. Google veröffentlicht seinen robots.txt-Parser außerdem als Open-Source-Bibliothek, mit der Entwickler einen Dateientwurf testen können, bevor er live geht.

Die Regel korrigieren, dann prüfen

Ändern Sie die Datei so, dass die Seiten, die gecrawlt werden sollen, nicht mehr erfasst werden. Grenzen Sie ein breites Disallow ein, ergänzen Sie für die Ausnahme ein längeres Allow oder entfernen Sie eine übrig gebliebene Gruppe. Dann:

1. Rufen Sie die Live-Datei ab, um zu bestätigen, dass der Server Ihre Änderung ausliefert und keine zwischengespeicherte oder beim Build erzeugte Kopie: curl -s https://www.example.com/robots.txt.
2. Fordern Sie ein erneutes Crawling der robots.txt an, über den robots.txt-Bericht in der Search Console. Google speichert die Datei in der Regel bis zu 24 Stunden im Cache, und die Hilfe zum Bericht nennt das Freigeben wichtiger URLs als Grund für ein erneutes Crawling. Der Bericht zeigt, wann Google die Datei zuletzt abgerufen hat, sowie etwaige Fehler oder Warnungen; eine fehlerhafte Zeile wird ignoriert.
3. Führen Sie für 2 oder 3 betroffene URLs einen Live-Test in der URL-Prüfung aus. „Crawling zulässig?“ sollte jetzt „Ja“ anzeigen. Nutzen Sie „Indexierung beantragen“ für die wichtigsten Seiten; laut Googles Hilfe kann die Indexierung bis zu ein oder zwei Wochen dauern.
4. Klicken Sie auf „Fehlerbehebung überprüfen“, sobald die Regel korrigiert ist, und zwar beim Problem im Bericht zur Seitenindexierung. Laut Googles Dokumentation dauert die Validierung in der Regel bis zu etwa 2 Wochen und kann deutlich länger dauern.

Laut Googles Hilfe zum erneuten Crawling kann das Crawling einige Tage bis einige Wochen dauern; rechnen Sie also damit, dass die Zahl nach und nach sinkt. Die URLs, die danach im Bericht bleiben, sollten die sein, die Sie absichtlich sperren.

Bevor Sie eine Seite freigeben, die monatelang verborgen war, sehen Sie sie sich so an, wie ein Crawler es tun wird: Statuscode, Robots-Meta-Tag und Canonical. Eine Seite, die niemand crawlen konnte, trägt womöglich ein vergessenes noindex und würde dann direkt zu URL als „noindex“ markiert wechseln. Unsere Analyse von Indexierbarkeitskonflikten erklärt, wie diese Signale zusammenwirken.

Die Search Console zeigt Ihnen, welche URLs blockiert sind. Eine vollständige SEOReport-Diagnose gleicht die Seiten, die Ihre Sitemap listet, mit Ihren robots.txt-Regeln ab und nennt die Seiten, die Suchmaschinen finden sollen, obwohl Sie ihnen das Crawling verbieten. Außerdem meldet sie ein websiteweites Disallow und eine fehlende robots.txt. Sie liest die Regeln, die für alle Crawler gelten; eine Gruppe nur für Googlebot sollten Sie also weiterhin in der URL-Prüfung bestätigen.

Häufige Fragen

Schadet eine große Zahl blockierter URLs meiner Website?

Nein, nicht für sich genommen. Tausende blockierte Parameter- oder Such-URLs sind ein Zeichen dafür, dass die robots.txt ihre Aufgabe erfüllt. Zählen Sie die blockierten URLs aus Ihrer Sitemap und die blockierten Seiten, die ranken sollen; nur diese kosten Sie etwas.

Was passiert, wenn meine robots.txt fehlt oder einen Fehler zurückgibt?

Googles Spezifikation behandelt eine 404 oder eine andere 4xx-Antwort (außer 429) so, als gäbe es keine robots.txt; dann ist nichts blockiert. Ein 5xx-Fehler ist etwas anderes: Google stellt das Crawling der Website für die ersten 12 Stunden ein und verwendet danach bis zu 30 Tage lang die letzte gültige Kopie. Timeouts und DNS-Fehler bei der Datei behandelt Google genauso; eine robots.txt, die in ein Timeout läuft, kann also das Crawling einer Website anhalten, die gar keine Sperrregeln hat.

Sollten blockierte URLs aus meiner Sitemap entfernt werden?

Ja. Eine Sitemap listet die URLs, die indexiert werden sollen, und sollte daher keine URL enthalten, die die robots.txt blockiert. Entfernen Sie gewollt gesperrte URLs aus der Sitemap und geben Sie die versehentlich gesperrten frei. Unser Leitfaden zu XML-Sitemaps erklärt, was sonst noch in die Datei gehört.

Kann ich mit der robots.txt eine Seite aus Google entfernen?

Nein. Die robots.txt steuert das Crawling, und Google kann eine blockierte URL trotzdem indexieren, wenn andere Seiten auf sie verlinken. Um eine Seite aus der Suche herauszuhalten, lassen Sie Google sie crawlen und ergänzen Sie noindex. Der Leitfaden zu robots.txt und Crawling-Zugriff erklärt, welches Werkzeug welche Aufgabe erfüllt.

Wirkt sich eine robots.txt auf einer Subdomain oder unter HTTP auf meine Hauptwebsite aus?

Nein. Jede Kombination aus Host, Protokoll und Port hat ihre eigene Datei, und robots.txt-Dateien in Unterverzeichnissen liest Google nicht. Eine Sperrdatei auf staging.example.com kann www.example.com nicht blockieren, aber die robots.txt auf Ihrem Asset- oder CDN-Host entscheidet sehr wohl, ob Google die Dateien abrufen kann, die Ihre Seiten laden.