So überprüfst du deine robots.txt (und die Zeile, die eine ganze Website deindexiert)

Um deine robots.txt zu überprüfen und zu testen, öffnest du https://deinewebsite.de/robots.txt im Browser, liest jede User-agent-Gruppe und suchst nach Disallow-Regeln, die Seiten abdecken, die in der Suche erscheinen sollen, allen voran ein nacktes Disallow: /. Auf einer kleinen Website dauert dieser robots.txt-Check eine Minute. Danach bestätigst du im robots.txt-Bericht der Search Console, was Google tatsächlich abgerufen hat, denn die Datei, die du siehst, und die Datei, die Googlebot bekommen hat, sind nicht immer dieselbe.

Die meisten robots.txt-Dateien bestehen aus einer Handvoll Zeilen, und genau deshalb liest sie kaum jemand. Sie gelten außerdem für den gesamten Host, eine einzige falsche Zeile betrifft also jede URL darauf.

Crawling, nicht Indexierung

Die robots.txt sagt Crawlern, welche URLs sie abrufen dürfen. Sie entscheidet nicht darüber, was in den Suchergebnissen erscheint. Eine per robots.txt blockierte URL kann trotzdem indexiert werden, wenn andere Seiten auf sie verlinken. Google zeigt sie dann ohne Beschreibung an, und die Search Console führt sie als „Indexiert, obwohl durch robots.txt-Datei blockiert“.

Das wird wichtig, sobald die robots.txt benutzt wird, um Seiten zu verstecken. Blockierst du eine Seite und setzt zusätzlich ein noindex, kann Google die Seite nicht crawlen, sieht das noindex nie, und die URL bleibt womöglich im Index. Um eine Seite aus den Ergebnissen zu nehmen, lässt du sie crawlbar und lieferst noindex aus. Der noindex-Tag erklärt behandelt diese Seite des Themas.

Wo die Datei liegt

Die robots.txt liegt immer im Root eines Hosts, zum Beispiel unter https://example.com/robots.txt. Ihre Regeln gelten nur für das Protokoll, den Host und den Port, unter dem sie ausgeliefert wird. https://shop.example.com braucht also eine eigene Datei.

Auf vielen Plattformen gibt es gar keine physische Datei zum Öffnen. WordPress erzeugt eine virtuelle robots.txt, solange du keine echte ins Web-Root hochlädst, und SEO-Plugins wie Yoast und Rank Math lassen dich die Datei im Backend bearbeiten. Shopify liefert eine Standarddatei aus, die du anpasst, indem du dem Theme ein robots.txt.liquid-Template hinzufügst. Wenn du dich per FTP verbindest und die Datei nicht findest, liegt es meistens daran.

Die robots.txt Zeile für Zeile lesen

Eine robots.txt besteht aus Gruppen. Jede Gruppe beginnt mit einer oder mehreren User-agent-Zeilen, auf die ihre Regeln folgen:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /*?s=
Disallow: /cart/

User-agent: GPTBot
Disallow: /

Sitemap: https://example.com/sitemap_index.xml

Liest man dieses Beispiel von oben, werden alle Crawler aus /wp-admin/ ferngehalten, mit Ausnahme von admin-ajax.php, außerdem aus den internen Suchergebnissen (?s=) und dem Warenkorb. GPTBot hat eine eigene Gruppe und ist von allem ausgeschlossen. Die Sitemap-Zeile gehört zu keiner Gruppe und gilt für die ganze Datei.

Ein paar Verarbeitungsregeln erklären die meisten Überraschungen. Ein Crawler befolgt nur die spezifischste Gruppe, die zu seinem Namen passt. Googlebot findet hier keine Gruppe User-agent: Googlebot und nutzt deshalb *. Gäbe es eine Googlebot-Gruppe, würde er die *-Regeln komplett ignorieren, statt sie zusammenzuführen. Pfade unterscheiden Groß- und Kleinschreibung, /Blog/ und /blog/ sind also verschiedene Regeln. * steht für eine beliebige Zeichenfolge und $ für das Ende der URL, womit Disallow: /*.pdf$ PDFs blockiert und sonst nichts. Wenn sowohl ein Allow als auch ein Disallow auf eine URL passen, folgt Google der längeren, spezifischeren Regel. Ein leeres Disallow: blockiert überhaupt nichts.

Crawl-delay- und Noindex-Zeilen in der robots.txt ignoriert Google. Bing dagegen beachtet Crawl-delay.

Die zwei Zeilen, die eine ganze Website sperren

User-agent: *
Disallow: /

Damit wird jedem Crawler gesagt, dass er sich von jeder URL fernhalten soll. Für eine Staging- oder Entwicklungsumgebung ist das die normale Einstellung, und genau so gelangt sie auf Live-Websites: Ein Deploy kopiert die Staging-Datei mit, oder eine Migration übernimmt die komplette Konfiguration. WordPress hat eine verwandte Falle. Wer unter Einstellungen > Lesen die Option „Suchmaschinen davon abhalten, diese Website zu indexieren“ anhakt, bringt aktuelle Versionen dazu, jeder Seite ein noindex-Robots-Meta-Tag hinzuzufügen. Nach einem Launch lohnt es sich also, sowohl die Datei als auch den Quelltext der Seiten zu prüfen.

Besucher merken davon nichts. Seiten laden, Formulare werden abgeschickt, Uptime-Checks bleiben grün. Das Crawling lässt nach, und in den folgenden Wochen fallen Seiten aus den Ergebnissen.

robots.txt testen: die Checks, die sich lohnen

1. Ruf /robots.txt direkt auf und achte neben dem Inhalt auch auf den HTTP-Status. Der Network-Tab in den Chrome DevTools zeigt ihn an. Du willst einen 200 und die Regeln, die du erwartest.
2. Durchsuch die Datei nach einem alleinstehenden Disallow: / und nach Regeln für Verzeichnisse mit Seiten, die ranken sollen, etwa /blog/, /products/ oder /category/.
3. Stell sicher, dass die Sitemap:-Zeile auf eine Sitemap zeigt, die lädt und aktuell ist, und nicht auf ein Überbleibsel eines früheren Plugins.
4. Öffne in der Search Console Einstellungen > robots.txt. Der Bericht listet die robots.txt-Dateien, die Google für die wichtigsten Hosts der Property gefunden hat, wann jede zuletzt gecrawlt wurde, den Abrufstatus und alle Zeilen, die nicht verarbeitet werden konnten. Nachdem du ein dringendes Problem behoben hast, kannst du dort einen erneuten Crawl anfordern.
5. Für eine einzelne URL nutzt du die URL-Prüfung. Ist die URL blockiert, steht im Abschnitt zur Seitenindexierung „Durch robots.txt-Datei blockiert“.
6. Auf größeren Websites lässt du einen Crawler wie Screaming Frog im Standardmodus laufen, der die robots.txt beachtet, und gehst die URLs durch, die er als blockiert meldet.

Den alten robots.txt-Tester hat Google 2023 eingestellt. Anleitungen, die dich dorthin schicken, sind veraltet.

Der Statuscode zählt genauso viel wie die Regeln. Einen 404 oder einen anderen 4xx-Code außer 429 behandelt Google so, als gäbe es keine robots.txt, es darf also alles gecrawlt werden. Ein 5xx wird anders behandelt: Google stellt das Crawling eine Zeit lang ein und greift dann auf eine zwischengespeicherte Kopie zurück, während es den Abruf weiter versucht. Außerdem speichert Google die Datei bis zu 24 Stunden im Cache und liest nur die ersten 500 KiB. Regeln, die in einer ungewöhnlich langen Datei jenseits dieser Grenze stehen, werden ignoriert.

Erfahren, wann sich die Datei ändert

Jeder dieser Checks sagt dir, was heute in der robots.txt steht. Keiner sagt dir, dass ein Plugin sie am Dienstag umgeschrieben oder ein Hosting-Umzug eine alte Version zurückgebracht hat. Bei einer einzelnen Website kannst du sie nach jedem Release wieder öffnen. Bei einem Kundenportfolio, in dem Entwickler ohne Vorwarnung deployen, wirst du das nicht tun, und das erste Anzeichen einer schlechten Änderung ist meist ein Crawl-Rückgang in der Search Console Wochen später. Welche Änderungen einen Alert verdienen, beschreibt der Leitfaden zu Alerts bei robots.txt-Änderungen.

Deltio ruft die robots.txt jeder Kunden-Website im Rahmen seines täglichen Checks ab, vergleicht sie mit der vorherigen Version und schickt für die betreffende Website einen Alert per Slack oder E-Mail, wenn sie sich geändert hat. Derselbe Durchlauf prüft noindex, Canonicals und die URLs in der Sitemap, weil ein Staging-Deploy meist mehrere davon gleichzeitig kaputtmacht. Der Check läuft einmal am Tag, eine Änderung wird also am selben oder am nächsten Tag gemeldet, nicht innerhalb von Minuten. Wie diese Alerts zugeschnitten sind, erklärt der Artikel zu SEO-Änderungsalerts, und wenn du eine Website hinzufügen willst, kannst du Deltio 14 Tage kostenlos testen.