Manchmal liegt ein SEO-Problem nicht am Inhalt, nicht an der internen Verlinkung und auch nicht an der Qualität einer Seite. Die Ursache kann viel früher entstehen: Google versucht eine Website zu crawlen, stößt dabei auf eine robots.txt-Datei, kann sie nicht abrufen oder interpretiert Regeln anders als erwartet. Genau deshalb ist der robots.txt-Bericht in der Google Search Console so wichtig. Er zeigt, welche robots.txt-Dateien Google für eine Property gefunden hat, wann sie zuletzt abgerufen wurden und ob dabei Warnungen oder Fehler aufgetreten sind. Laut Google zeigt der robots.txt-Bericht die gefundenen robots.txt-Dateien für die wichtigsten Hosts einer Website, den letzten Abrufzeitpunkt sowie mögliche Warnungen oder Fehler; außerdem kann in Notfällen ein erneuter Abruf angefordert werden.
Wichtig ist jedoch: Der robots.txt-Bericht ist nicht in jeder Property sichtbar. Google stellt den Bericht nur für Properties auf Domain-Ebene bereit. Dazu gehören Domain-Properties sowie URL-Präfix-Properties ohne Pfad, etwa https://example.com/, nicht jedoch Properties wie https://example.com/blog/. Genau dieser Punkt erklärt, warum viele Website-Betreiber den Bericht in der Search Console nicht sofort finden.
Was ist der robots.txt-Bericht?
Der robots.txt-Bericht ist ein spezieller Bericht innerhalb der Google Search Console, der zeigt, ob Google die robots.txt-Datei einer Website abrufen und verarbeiten konnte. Die robots.txt-Datei liegt normalerweise im Stammverzeichnis einer Domain, zum Beispiel unter https://www.beispiel.de/robots.txt. Sie enthält Anweisungen für Crawler, welche Bereiche einer Website gecrawlt werden dürfen und welche nicht. Google erklärt, dass robots.txt vor allem dazu dient, Crawler-Zugriffe auf eine Website zu steuern; sie ist jedoch kein zuverlässiges Mittel, um eine Webseite aus den Google-Suchergebnissen herauszuhalten. Dafür sind andere Methoden wie noindex oder Passwortschutz geeigneter.
Der Bericht ist besonders nützlich, weil er nicht nur die aktuell erreichbare Datei zeigt, sondern auch, wie Google sie zuletzt verarbeitet hat. Das ist ein wichtiger Unterschied. Eine robots.txt-Datei kann im Browser erreichbar sein, während Google beim letzten Abruf dennoch ein Problem hatte. Ebenso kann eine alte Version zwischengespeichert sein, obwohl bereits Änderungen vorgenommen wurden. Der Bericht hilft dabei, solche Situationen besser einzuordnen.
In der Search Console werden unter anderem Dateipfad, Abrufstatus, letzter Prüfzeitpunkt, Dateigröße und mögliche Probleme angezeigt. Der Abrufstatus kann beispielsweise zeigen, ob die Datei erfolgreich abgerufen wurde oder ob sie nicht gefunden beziehungsweise aus einem anderen Grund nicht abgerufen werden konnte. Google weist darauf hin, dass ein 404-Status bei einer nicht vorhandenen robots.txt-Datei grundsätzlich kein Problem ist: Fehlt die Datei, kann Google im Allgemeinen alle URLs der Website crawlen.
Der robots.txt-Bericht ist damit ein Kontrollinstrument für Crawling-Regeln. Er ersetzt keine vollständige technische SEO-Analyse, liefert aber wichtige Hinweise, wenn Google Seiten nicht crawlen kann, wichtige Bereiche versehentlich blockiert werden oder eine robots.txt-Datei nicht erreichbar ist. Besonders bei Relaunches, CMS-Umstellungen, Serverwechseln und geänderten Crawling-Regeln ist der Bericht sehr wertvoll.
Wo ist der robots.txt-Bericht in der Search Console zu finden?
Der robots.txt-Bericht ist in der Google Search Console nicht immer prominent im Hauptmenü sichtbar. Der Zugriff erfolgt über den entsprechenden Bericht innerhalb der Search-Console-Oberfläche beziehungsweise über Googles Hilfeseite zum robots.txt-Bericht. Entscheidend ist, dass die richtige Property geöffnet ist. Der Bericht ist nur für Properties verfügbar, die auf Domain-Ebene arbeiten: eine Domain-Property wie beispiel.de oder eine URL-Präfix-Property ohne Pfad wie https://www.beispiel.de/. Eine URL-Präfix-Property mit einem Unterverzeichnis, etwa https://www.beispiel.de/ratgeber/, unterstützt diesen Bericht nicht.
Der häufigste Grund, warum der Bericht nicht auffindbar ist, liegt genau an dieser Property-Auswahl. Viele Websites sind nur als URL-Präfix mit einem bestimmten Pfad eingerichtet oder es wurde versehentlich die falsche Variante gewählt. Wenn eine Website beispielsweise unter https://www.beispiel.de/ betrieben wird, aber in der Search Console nur eine Unterverzeichnis-Property eingerichtet ist, kann der robots.txt-Bericht fehlen. In solchen Fällen sollte zusätzlich eine Domain-Property oder eine passende URL-Präfix-Property ohne Pfad eingerichtet werden.
In einer Domain-Property kann der Bericht mehrere Hosts berücksichtigen. Google erklärt, dass der Bericht in einer Domain-Property robots.txt-Dateien der wichtigsten Hosts der Property enthält. Für jeden Host können HTTP- und HTTPS-Varianten geprüft werden, wodurch je nach Struktur mehrere Zeilen entstehen können. Das ist besonders relevant bei Websites mit Subdomains wie www, shop, blog oder m.
Praktisch bedeutet das: Zuerst sollte geprüft werden, ob in der Search Console die richtige Property geöffnet ist. Danach kann der robots.txt-Bericht aufgerufen werden. Wenn er nicht verfügbar ist, liegt die Ursache meist nicht an der Website selbst, sondern an der Art der Property. Eine Domain-Property ist für diesen Bericht in den meisten Fällen die sauberste Lösung.
Schritt-für-Schritt: robots.txt-Bericht öffnen
Der Ablauf beginnt mit dem Öffnen der Google Search Console. Danach wird im Property-Auswahlfeld die passende Property gewählt. Für eine vollständige Prüfung ist eine Domain-Property besonders geeignet, weil sie alle relevanten Hosts einer Domain erfassen kann. Alternativ kann eine URL-Präfix-Property ohne Pfad verwendet werden. Wichtig ist, dass nicht versehentlich eine Property mit Unterverzeichnis genutzt wird, da der robots.txt-Bericht dort nicht verfügbar ist.
Anschließend wird der robots.txt-Bericht geöffnet. Dort erscheinen die robots.txt-Dateien, die Google für die wichtigsten Hosts der Property gefunden oder geprüft hat. Für jede Datei werden Informationen wie Dateipfad, Abrufstatus, letzter Prüfzeitpunkt, Größe und mögliche Probleme angezeigt. Wenn eine Datei erfolgreich abgerufen wurde, lautet der Status entsprechend „Fetched“ beziehungsweise in der deutschen Oberfläche sinngemäß „Abgerufen“. Wenn keine Datei gefunden wurde, kann ein 404-Status erscheinen. Das ist nicht automatisch kritisch, solange keine spezielle Crawling-Steuerung benötigt wird.
Ein sinnvoller Prüfablauf sieht so aus: Zuerst wird kontrolliert, ob die richtige robots.txt-URL angezeigt wird. Danach wird der Abrufstatus geprüft. Anschließend werden Warnungen und Fehler betrachtet. Wenn Probleme vorhanden sind, sollte die Datei geöffnet und die markierten Stellen geprüft werden. Google ermöglicht im Bericht das Anzeigen der zuletzt abgerufenen Version; Fehler und Warnungen können dort hervorgehoben werden.
Wenn eine robots.txt-Datei kürzlich geändert wurde, kann ein erneuter Abruf angefordert werden. Diese Funktion sollte vor allem bei dringenden Fällen genutzt werden, etwa wenn versehentlich wichtige Bereiche blockiert wurden. Nach der Korrektur der Datei kann eine erneute Verarbeitung sinnvoll sein. Dennoch sollte beachtet werden, dass Suchmaschinenverarbeitung nicht immer sofort vollständig abgeschlossen ist. Der Bericht zeigt den Abrufstatus, aber Indexierungsänderungen können zusätzlich Zeit benötigen.
Warum der robots.txt-Bericht nicht angezeigt wird
Wenn der robots.txt-Bericht nicht sichtbar ist, liegt die Ursache häufig an der Property-Art. Google stellt den Bericht nur für Domain-Properties oder URL-Präfix-Properties ohne Pfad bereit. Eine Property wie https://www.beispiel.de/blog/ erfüllt diese Voraussetzung nicht. In diesem Fall sollte eine neue passende Property eingerichtet werden. Besonders empfehlenswert ist eine Domain-Property, weil sie Subdomains und Protokollvarianten umfassender abdeckt.
Ein weiterer Grund kann sein, dass für den betreffenden Host keine robots.txt-Datei in den relevanten letzten Abrufen angezeigt wird. Google erklärt, dass eine URL im Bericht nur erscheint, wenn sie innerhalb des betrachteten Zeitraums den Status „abgerufen“ oder „nicht abgerufen“ hatte; eine robots.txt-Datei, die als nicht gefunden gemeldet wurde, kann nach einer gewissen Zeit aus dem Bericht verschwinden, obwohl Google im Hintergrund weiter prüft. Das kann erklären, warum bestimmte Hosts nicht dauerhaft sichtbar bleiben.
Auch die Auswahl der falschen Subdomain kann zu Verwirrung führen. Eine robots.txt-Datei gilt immer für einen bestimmten Host und ein bestimmtes Protokoll. https://www.beispiel.de/robots.txt ist nicht automatisch dasselbe wie https://shop.beispiel.de/robots.txt oder http://www.beispiel.de/robots.txt. Google weist darauf hin, dass robots.txt-Dateien nicht von Subdomains oder übergeordneten Domains geerbt werden. Daher muss für jede relevante Host-Variante die passende Datei geprüft werden.
Wenn der Bericht trotz korrekter Property nicht auffindbar ist, sollte zusätzlich geprüft werden, ob Zugriff auf die Property mit ausreichenden Berechtigungen besteht. Bei eingeschränkten Zugriffsrechten können bestimmte Funktionen oder Berichte weniger vollständig nutzbar sein. In der Praxis ist die Property-Art jedoch deutlich häufiger die Ursache als ein tatsächlicher Fehler im Bericht.
Was die einzelnen Statusmeldungen bedeuten
Der robots.txt-Bericht zeigt nicht nur, ob eine Datei vorhanden ist, sondern auch, ob Google sie abrufen konnte. Der Status „Fetched“ beziehungsweise „Abgerufen“ bedeutet, dass Google beim letzten Abruf erfolgreich eine robots.txt-Datei erhalten hat. Das heißt jedoch nicht automatisch, dass alle Regeln sinnvoll oder fehlerfrei sind. Wenn Parsing-Probleme vorhanden sind, werden diese separat als Warnungen oder Fehler angezeigt. Google verwendet laut eigener Beschreibung die Regeln, die verarbeitet werden können, und ignoriert Zeilen mit Problemen.
Der Status „Not Fetched – Not found“ beziehungsweise „Nicht abgerufen – nicht gefunden“ bedeutet, dass unter der erwarteten robots.txt-URL keine Datei gefunden wurde. Ein 404 für robots.txt ist nicht automatisch ein SEO-Problem. Wenn keine robots.txt vorhanden ist, kann Google grundsätzlich alle URLs crawlen, sofern keine anderen technischen Hindernisse bestehen. Kritisch wird es eher dann, wenn eigentlich bewusst Crawling-Regeln benötigt werden oder wenn eine Datei vorhanden sein sollte, aber wegen falschem Pfad, Serverkonfiguration oder Weiterleitung nicht erreichbar ist.
Der Status „Not Fetched – Any other reason“ kann auf andere Abrufprobleme hinweisen. Dazu gehören Serverfehler, Netzwerkprobleme, blockierte Zugriffe, fehlerhafte Weiterleitungen oder andere technische Hindernisse. Solche Meldungen sollten genauer geprüft werden, weil eine nicht erreichbare robots.txt-Datei das Crawling beeinflussen kann. In solchen Fällen lohnt sich ein Blick in Serverlogs, Hosting-Einstellungen, Firewall-Regeln und die Live-Erreichbarkeit der Datei.
Die Spalte „Issues“ beziehungsweise „Probleme“ zeigt Parsing-Warnungen oder Fehler. Fehler können dazu führen, dass bestimmte Regeln nicht verwendet werden. Warnungen verhindern die Verwendung nicht zwingend, sollten aber trotzdem geprüft werden. Ein sauberer robots.txt-Bericht hat idealerweise einen erfolgreichen Abrufstatus und keine relevanten Fehler. Entscheidend bleibt jedoch immer, welche Bereiche tatsächlich blockiert oder freigegeben werden sollen.
robots.txt direkt im Browser prüfen
Neben dem Bericht in der Search Console kann eine robots.txt-Datei auch direkt im Browser geöffnet werden. Dafür wird die Domain bis zum Host gekürzt und /robots.txt angehängt. Aus https://www.beispiel.de/ratgeber/seite/ wird also https://www.beispiel.de/robots.txt. Google beschreibt genau dieses Prinzip: Alles nach dem Host wird entfernt, anschließend wird /robots.txt ergänzt.
Diese einfache Prüfung ist sehr hilfreich, weil sie zeigt, ob die Datei öffentlich erreichbar ist. Wenn die Datei im Browser nicht geladen wird, kann Google sie möglicherweise ebenfalls nicht abrufen. Wird eine 404-Seite angezeigt, existiert keine robots.txt unter dieser Adresse. Das ist nicht automatisch problematisch. Wird jedoch ein 403-Fehler, ein 500-Fehler oder eine Login-Seite angezeigt, sollte die technische Konfiguration geprüft werden.
Wichtig ist die korrekte Host-Variante. Eine Website kann mehrere Varianten haben: https://beispiel.de/robots.txt, https://www.beispiel.de/robots.txt, https://shop.beispiel.de/robots.txt oder http://beispiel.de/robots.txt. Jede Variante kann theoretisch eine eigene robots.txt-Datei besitzen. Deshalb reicht es nicht immer, nur die Hauptdomain zu prüfen. Bei Subdomains, Shops, Staging-Umgebungen oder mobilen Versionen sollte jede relevante Variante einzeln betrachtet werden.
Die Browserprüfung ersetzt den Search-Console-Bericht nicht vollständig, weil sie nur den aktuellen Live-Zugriff zeigt. Der Bericht zeigt zusätzlich, was Google zuletzt abgerufen und verarbeitet hat. Beide Prüfungen ergänzen sich: Der Browser zeigt die aktuelle Erreichbarkeit, die Search Console zeigt Googles zuletzt gespeicherte Sicht.
Was robots.txt kann und was nicht
Eine robots.txt-Datei steuert Crawling, nicht zuverlässig Indexierung. Dieser Unterschied ist entscheidend. Google erklärt ausdrücklich, dass robots.txt nicht dafür gedacht ist, Webseiten aus Google herauszuhalten; wenn eine Seite nicht in Suchergebnissen erscheinen soll, sind noindex oder Passwortschutz die passenden Methoden. Wird eine URL nur per robots.txt blockiert, kann sie unter bestimmten Umständen trotzdem als URL in Suchergebnissen erscheinen, wenn andere Seiten darauf verlinken.
robots.txt ist sinnvoll, um unwichtige oder technische Bereiche vom Crawling auszuschließen. Beispiele sind interne Suchergebnisse, bestimmte Filterseiten, Parameterbereiche, Warenkorbseiten oder technische Verzeichnisse. Der Einsatz sollte jedoch sorgfältig erfolgen. Werden wichtige CSS-, JavaScript- oder Bildressourcen blockiert, kann Google eine Seite möglicherweise schlechter verstehen. Google weist darauf hin, dass blockierte Ressourcen problematisch sein können, wenn ihre Abwesenheit das Verständnis der Seite erschwert.
Ein häufiger Fehler besteht darin, sensible Inhalte mit robots.txt schützen zu wollen. Das ist nicht sicher. robots.txt ist öffentlich abrufbar und zeigt sogar, welche Bereiche nicht gecrawlt werden sollen. Für private Inhalte sind Passwortschutz, Zugriffsbeschränkungen oder serverseitige Sicherheitsmechanismen notwendig. robots.txt ist eine Crawler-Anweisung, keine Sicherheitsfunktion.
Ein weiterer Fehler entsteht bei der Kombination aus robots.txt und noindex. Wenn eine Seite per robots.txt blockiert ist, kann Google den noindex-Tag auf der Seite nicht zuverlässig sehen, weil die Seite nicht gecrawlt werden darf. Soll eine Seite aus dem Index entfernt werden, sollte sie crawlbar sein und einen noindex-Tag enthalten, bis Google diese Anweisung verarbeiten konnte. Danach kann je nach Ziel anders gesteuert werden.
Häufige Probleme im robots.txt-Bericht
Ein typisches Problem ist eine versehentliche Blockierung wichtiger Bereiche. Besonders kritisch ist Disallow: /, weil damit für den betreffenden User-Agent grundsätzlich die gesamte Website blockiert werden kann. Solche Regeln entstehen manchmal in Entwicklungsumgebungen und werden nach dem Livegang vergessen. Der robots.txt-Bericht kann helfen, solche Blockierungen sichtbar zu machen, wenn Google die Datei verarbeitet und Probleme oder betroffene Crawling-Regeln sichtbar werden.
Ein weiteres Problem sind falsch platzierte robots.txt-Dateien. Die Datei muss im Stammverzeichnis des jeweiligen Hosts liegen. https://www.beispiel.de/robots.txt ist korrekt. Eine Datei unter https://www.beispiel.de/assets/robots.txt steuert das Crawling der Website nicht. Google beschreibt, dass robots.txt am Root von Protokoll und Domain liegt. Wenn eine Datei an der falschen Stelle liegt, wird sie für Crawling-Regeln nicht wie erwartet verwendet.
Auch Serverfehler können problematisch sein. Wenn Google eine robots.txt-Datei nicht abrufen kann, kann das Crawling beeinträchtigt werden. Ursachen können Hosting-Ausfälle, Firewall-Regeln, Bot-Schutz, fehlerhafte Weiterleitungen oder überlastete Server sein. Der Crawl-Stats-Bericht kann ergänzend helfen, Crawling-Probleme und Serverantworten zu untersuchen, da er Googles Crawling-Verlauf, Anfragen, Serverantworten und Verfügbarkeitsprobleme zeigt.
Parsing-Fehler sind ebenfalls häufig. Sie entstehen durch falsche Syntax, ungültige Direktiven, fehlerhafte Schreibweisen oder unklare Regeln. Nicht jede Warnung führt sofort zu einem großen SEO-Problem, aber sie sollte geprüft werden. Je wichtiger die betroffenen Bereiche sind, desto höher ist die Priorität der Korrektur.
Änderungen an der robots.txt richtig prüfen
Nach Änderungen an der robots.txt-Datei sollte nicht nur die Datei im CMS oder auf dem Server gespeichert werden. Entscheidend ist, ob Google die neue Version abrufen kann. Zuerst sollte die Datei direkt im Browser geöffnet werden. Dort muss die neue Version sichtbar sein. Falls weiterhin die alte Version erscheint, können Caching, CDN, Serverkonfiguration oder falsche Upload-Orte die Ursache sein.
Danach sollte der robots.txt-Bericht in der Search Console geprüft werden. Wenn die alte Version noch angezeigt wird, bedeutet das nicht zwingend, dass die Änderung falsch ist. Google zeigt dort die zuletzt abgerufene Version. Bei wichtigen Änderungen kann ein erneuter Abruf angefordert werden. Google beschreibt, dass der robots.txt-Bericht einen erneuten Abruf für Notfallsituationen ermöglicht. Das ist besonders wichtig, wenn versehentlich zentrale Seiten blockiert wurden.
Zusätzlich kann die URL-Prüfung verwendet werden, um einzelne betroffene URLs zu kontrollieren. Wenn eine Seite als „durch robots.txt blockiert“ angezeigt wird, bestätigt das ein konkretes Problem. Google empfiehlt bei blockierten Seiten, die URL-Prüfung zu öffnen und im Bereich Seitenindexierung zu prüfen, ob dort „Blocked by robots.txt“ beziehungsweise eine entsprechende Blockierung angezeigt wird.
Nach einer Korrektur sollte nicht sofort mit vollständiger Ranking-Erholung gerechnet werden. Zuerst muss Google die robots.txt neu abrufen, danach die betroffenen URLs crawlen und anschließend Indexierungs- oder Rankingänderungen verarbeiten. Je nach Website, Crawling-Frequenz und Wichtigkeit der URLs kann das unterschiedlich lange dauern.
robots.txt-Bericht und URL-Prüfung gemeinsam nutzen
Der robots.txt-Bericht zeigt den Zustand der robots.txt-Datei auf Host-Ebene. Die URL-Prüfung zeigt dagegen, wie eine konkrete URL von Google bewertet wird. Beide Werkzeuge beantworten unterschiedliche Fragen und sollten gemeinsam genutzt werden. Der robots.txt-Bericht beantwortet: Kann Google die robots.txt-Datei abrufen und verarbeiten? Die URL-Prüfung beantwortet: Ist eine bestimmte Seite durch robots.txt blockiert oder indexierbar?
Ein praktisches Beispiel: Eine Produktseite erscheint nicht in Google. Der robots.txt-Bericht zeigt, dass die robots.txt-Datei erfolgreich abgerufen wurde. Das allein reicht aber nicht. Die URL-Prüfung kann zeigen, ob genau diese Produktseite durch eine Regel wie Disallow: /produkte/ blockiert wird. Wenn ja, liegt das Problem nicht in der Erreichbarkeit der robots.txt, sondern in ihrer Regelwirkung.
Ein anderes Beispiel: Der robots.txt-Bericht zeigt „Not Fetched“. Dann sollte zunächst geprüft werden, ob die Datei im Browser erreichbar ist. Wenn die Datei nicht erreichbar ist, kann dies ein Server- oder Pfadproblem sein. Wenn sie im Browser erreichbar ist, aber Google sie nicht abrufen konnte, können Bot-Schutz, Firewall, DNS-Probleme oder temporäre Serverfehler beteiligt sein. Ergänzend kann der Crawl-Stats-Bericht Hinweise auf Serverantworten und Verfügbarkeitsprobleme liefern.
Die Kombination dieser Berichte verhindert Fehldiagnosen. Eine fehlerfreie robots.txt-Datei bedeutet nicht automatisch, dass alle wichtigen URLs crawlbar sind. Eine blockierte URL bedeutet nicht automatisch, dass die Datei selbst fehlerhaft ist. Erst die gemeinsame Auswertung zeigt, ob ein technisches Abrufproblem, ein Regelproblem oder ein anderes Indexierungsproblem vorliegt.
Entscheidungshilfe: Wann ist Handlungsbedarf vorhanden?
Handlungsbedarf besteht, wenn wichtige Seiten versehentlich vom Crawling ausgeschlossen werden, die robots.txt-Datei für Google nicht erreichbar ist oder Parsing-Fehler zentrale Regeln betreffen. Besonders kritisch sind Regeln, die ganze Verzeichnisse blockieren, in denen wichtige Inhalte liegen. Auch Blockierungen von CSS- oder JavaScript-Dateien können relevant sein, wenn Google dadurch die Seite nicht richtig rendern oder verstehen kann.
Weniger kritisch ist eine nicht vorhandene robots.txt-Datei, sofern keine speziellen Crawling-Regeln benötigt werden. Google erklärt, dass eine fehlende robots.txt-Datei grundsätzlich bedeutet, dass Google alle URLs der Website crawlen kann. In vielen kleinen Websites ist das völlig ausreichend. Eine leere oder minimale robots.txt kann dennoch sinnvoll sein, wenn eine Sitemap angegeben oder bestimmte Bereiche bewusst gesteuert werden sollen.
Bei Warnungen sollte die Priorität vom betroffenen Bereich abhängen. Eine Warnung in einer unwichtigen Zeile ist weniger dringend als ein Fehler in einer zentralen Disallow-Regel. Bei Serverproblemen ist die Priorität höher, wenn der Abruf wiederholt scheitert oder wenn gleichzeitig Crawling- und Indexierungsprobleme auftreten. Ein einzelner temporärer Fehler ist weniger problematisch als ein dauerhaft nicht erreichbarer robots.txt-Endpunkt.
Die beste Entscheidung entsteht durch drei Fragen: Ist die Datei erreichbar? Sind die Regeln korrekt? Sind wichtige URLs crawlbar? Wenn diese Fragen positiv beantwortet werden, besteht meist kein akuter Handlungsbedarf. Wenn eine dieser Fragen negativ beantwortet wird, sollte die Ursache strukturiert geprüft werden.
Typische Fehler vermeiden
Ein häufiger Fehler ist der Versuch, Seiten mit robots.txt aus Google zu entfernen. Das ist fachlich falsch, weil robots.txt Crawling steuert und keine verlässliche Indexierungsentfernung ist. Für das Entfernen aus Suchergebnissen sind noindex, Zugriffsschutz oder Entfernungsfunktionen besser geeignet. Google weist ausdrücklich darauf hin, robots.txt nicht als Methode zum Verbergen von Webseiten in Google zu verwenden.
Ein weiterer Fehler ist das Blockieren wichtiger Ressourcen. Wenn CSS- oder JavaScript-Dateien blockiert werden, kann Google Seiten unter Umständen nicht korrekt darstellen. Besonders moderne Websites sind stark von Skripten und Stylesheets abhängig. Werden diese Ressourcen blockiert, können Layout, Navigation oder Inhalte für Google schwerer verständlich werden.
Auch die falsche Property in der Search Console führt häufig zu Missverständnissen. Wenn der robots.txt-Bericht nicht sichtbar ist, wird manchmal ein technisches Problem der Website vermutet. Tatsächlich liegt es oft daran, dass eine URL-Präfix-Property mit Pfad geöffnet wurde. In diesem Fall ist der Bericht nicht verfügbar. Die Lösung besteht in einer Domain-Property oder einer URL-Präfix-Property ohne Pfad.
Ein weiterer Fehler ist das ungeprüfte Kopieren von robots.txt-Vorlagen. Regeln, die für eine Website sinnvoll sind, können auf einer anderen Website wichtige Bereiche blockieren. Besonders CMS-, Shop- und Filterstrukturen unterscheiden sich stark. Eine robots.txt-Datei sollte immer zur konkreten Website-Struktur passen.
Fazit
Der robots.txt-Bericht in der Google Search Console zeigt, welche robots.txt-Dateien Google für eine Website beziehungsweise deren wichtigste Hosts gefunden hat, wann sie zuletzt abgerufen wurden und ob Warnungen oder Fehler vorhanden sind. Der Bericht ist vor allem für technische SEO wichtig, weil er zeigt, ob Google Crawling-Regeln abrufen und verarbeiten kann. Sichtbar ist er nur bei passenden Properties: Domain-Properties oder URL-Präfix-Properties ohne Pfad.
Eine robots.txt-Datei steuert das Crawling, nicht zuverlässig die Indexierung. Wer Seiten aus Google entfernen möchte, sollte nicht allein auf robots.txt setzen. Google empfiehlt für das Fernhalten von Webseiten aus Suchergebnissen andere Mechanismen wie noindex oder Passwortschutz. Dieser Unterschied ist entscheidend, um technische Fehler zu vermeiden.
Für eine saubere Prüfung empfiehlt sich ein klarer Ablauf: richtige Property öffnen, robots.txt-Bericht prüfen, Datei im Browser testen, Statusmeldungen auswerten, betroffene URLs mit der URL-Prüfung kontrollieren und bei dringenden Änderungen einen erneuten Abruf anstoßen. So lässt sich zuverlässig erkennen, ob Google eine robots.txt-Datei korrekt abrufen kann und ob wichtige Seiten versehentlich blockiert werden.
FAQ
Wie kann der robots.txt-Bericht in der Google Search Console geöffnet werden?
Der robots.txt-Bericht kann in der Google Search Console geöffnet werden, wenn eine passende Property ausgewählt ist. Verfügbar ist der Bericht für Domain-Properties sowie für URL-Präfix-Properties ohne Pfad. Wenn eine Property mit Unterverzeichnis geöffnet ist, etwa https://www.beispiel.de/blog/, wird der Bericht nicht bereitgestellt.
Der erste Schritt besteht daher darin, die richtige Property zu wählen. Danach kann der robots.txt-Bericht geöffnet und geprüft werden. Dort erscheinen die robots.txt-Dateien, die Google für die wichtigsten Hosts der Property gefunden oder geprüft hat.
Warum sehe ich den robots.txt-Bericht nicht?
Der häufigste Grund ist eine ungeeignete Property. Google stellt den Bericht nicht für URL-Präfix-Properties mit Pfad bereit. Eine Domain-Property oder eine URL-Präfix-Property ohne Pfad ist erforderlich.
Ein weiterer Grund kann sein, dass bestimmte Hosts aktuell nicht im Bericht erscheinen, weil keine relevante Abrufinformation angezeigt wird. Auch falsche Subdomain-Auswahl kann zu Verwirrung führen. Bei Subdomains sollte geprüft werden, ob die passende Property eingerichtet wurde.
Ist es schlimm, wenn keine robots.txt-Datei vorhanden ist?
Nicht unbedingt. Wenn keine robots.txt-Datei vorhanden ist und der Abruf mit 404 endet, bedeutet das grundsätzlich, dass Google alle URLs crawlen kann, sofern keine anderen Hindernisse bestehen. Google weist darauf hin, dass eine nicht vorhandene robots.txt-Datei in diesem Sinne in Ordnung sein kann.
Problematisch wird es nur, wenn bestimmte Bereiche bewusst vom Crawling ausgeschlossen werden sollen oder wenn eigentlich eine Datei vorhanden sein sollte, aber falsch ausgeliefert wird.
Was bedeutet „durch robots.txt blockiert“?
Diese Meldung bedeutet, dass Google eine bestimmte URL aufgrund einer Regel in der robots.txt-Datei nicht crawlen darf. Die URL-Prüfung kann zeigen, ob eine konkrete Seite von einer solchen Blockierung betroffen ist. Google empfiehlt zur Bestätigung, die URL-Prüfung zu verwenden und im Bereich Seitenindexierung auf den Status zu achten.
Wenn eine wichtige Seite betroffen ist, sollte die robots.txt-Regel angepasst werden. Danach muss Google die Datei erneut abrufen und die betroffene URL erneut verarbeiten.
Kann robots.txt eine Seite aus Google entfernen?
robots.txt ist nicht die richtige Methode, um Webseiten zuverlässig aus Google zu entfernen. Sie steuert Crawling, nicht sicher die Indexierung. Eine blockierte URL kann unter Umständen weiterhin ohne Beschreibung in Suchergebnissen erscheinen, wenn sie von anderen Seiten bekannt ist. Google empfiehlt für das Fernhalten von Webseiten aus Suchergebnissen noindex oder Passwortschutz.
robots.txt eignet sich vor allem zur Steuerung von Crawler-Zugriffen und zur Vermeidung unnötigen Crawlings.
Wo muss die robots.txt-Datei liegen?
Die robots.txt-Datei muss im Stammverzeichnis des jeweiligen Hosts liegen. Für https://www.beispiel.de/seite/ wäre die passende Datei https://www.beispiel.de/robots.txt. Google beschreibt, dass alles nach dem Host entfernt und /robots.txt ergänzt wird.
Subdomains benötigen eigene robots.txt-Dateien. Eine Datei auf der Hauptdomain gilt nicht automatisch für shop.beispiel.de oder blog.beispiel.de.
Wann sollte ein erneuter Abruf der robots.txt angefordert werden?
Ein erneuter Abruf ist sinnvoll, wenn eine dringende Korrektur vorgenommen wurde. Das gilt besonders, wenn versehentlich wichtige Seiten blockiert wurden oder wenn eine fehlerhafte Datei schnell ersetzt werden musste. Der robots.txt-Bericht ermöglicht laut Google einen erneuten Abruf in Notfallsituationen.
Bei normalen Änderungen reicht häufig abzuwarten, bis Google die Datei erneut crawlt. Bei kritischen Blockierungen ist eine erneute Abrufanfrage sinnvoller.
Welche Rolle spielt der Crawl-Stats-Bericht?
Der Crawl-Stats-Bericht ergänzt die robots.txt-Prüfung, weil er zeigt, wie Google eine Website crawlt, welche Anfragen gestellt wurden und welche Serverantworten oder Verfügbarkeitsprobleme aufgetreten sind. Google beschreibt ihn als Bericht zur Crawling-Historie, inklusive Anfragen, Serverantworten und möglichen Verfügbarkeitsproblemen.
Wenn der robots.txt-Bericht Abrufprobleme zeigt, kann der Crawl-Stats-Bericht helfen, Server- oder Verfügbarkeitsprobleme besser einzuordnen.