Alert bei Änderungen an der robots.txt

Ein Alert bei Änderungen an der robots.txt meldet dir, wenn die Crawl-Regeln einer Website bearbeitet wurden, damit ein verirrtes Disallow: / zurückgenommen wird, bevor es die Website ihr Crawling kostet. Die robots.txt ist eine schlichte Textdatei, die Googlebot den Abruf jeder URL einer Domain verbieten kann, und wenn das passiert, sieht auf der Website nichts kaputt aus.

Ein typischer Ablauf sieht so aus. Ein Deploy kopiert die Staging-Konfiguration in die Produktion, Disallow: / geht live, und die Website lädt für Besucher und Uptime-Checks ganz normal weiter. Ein, zwei Wochen später beginnen die Impressionen in der Search Console zu sinken, und erst dann öffnet jemand die Datei. In diesem Leitfaden geht es darum, früher davon zu erfahren. Wie du die Datei selbst liest und prüfst, steht in so überprüfst du deine robots.txt.

Welche Änderungen an der robots.txt einen Alert verdienen

Viele Änderungen an der robots.txt sind harmlos, etwa wenn ein Plugin eine Regel für seinen eigenen Admin-Pfad ergänzt. Um diese hier solltest du dich noch am selben Tag kümmern.

Änderung	Wirkung	Dringlichkeit
Disallow: / unter User-agent: *	Sperrt jede URL für jeden Crawler	Wie einen Produktionsvorfall behandeln
Neues Disallow auf einem Content-Verzeichnis wie /blog/ oder /products/	Nimmt einen ganzen Bereich aus dem Crawling	Am selben Tag
Neue Gruppe User-agent: Googlebot	Googlebot folgt nur noch dieser Gruppe und ignoriert die *-Regeln	Am selben Tag, Inhalt der Gruppe lesen
Datei liefert plötzlich einen 5xx	Google pausiert das Crawling und stützt sich dann auf eine Kopie aus dem Cache	Am selben Tag
Datei gelöscht oder liefert 404	Google behandelt die Website als uneingeschränkt, die Sitemap:-Zeile ist weg	Prüfen, selten dringend
Sitemap:-Zeile entfernt oder auf eine alte URL gerichtet	Neue Seiten werden langsamer entdeckt	Niedrig
Regeln für GPTBot, ClaudeBot, PerplexityBot oder Google-Extended hinzugefügt	Sperrt KI-Crawler, ohne Auswirkung auf die Google-Suche	Klären, ob das gewollt war

Die Googlebot-Zeile erwischt Leute in beide Richtungen. Jemand legt für Googlebot eine Gruppe mit einem einzigen Disallow: /search an, und weil Googlebot jetzt die *-Gruppe ignoriert, gelten die Regeln für /cart/ und /checkout/, die bisher auch ihn betrafen, für ihn nicht mehr. Kopier den kompletten Regelsatz in die neue Gruppe, sonst ist sie lockerer als beabsichtigt.

Die Zeile zu den KI-Crawlern ist mal eine bewusste Grundsatzentscheidung und mal eine Voreinstellung, die ein Sicherheits- oder SEO-Plugin aktiviert hat, ohne dass jemand zugestimmt hätte. So oder so sollte der Kunde davon wissen.

Eine blockierte Seite kann trotzdem indexiert sein

Die robots.txt steuert das Crawling, noindex steuert die Indexierung. Eine per robots.txt blockierte URL kann weiterhin in den Ergebnissen auftauchen, meist ohne Beschreibung, weil Google sie über Links kennt, sie aber nie abrufen durfte. Die Search Console führt solche URLs als „Indexiert, obwohl durch robots.txt-Datei blockiert“.

Die Falle ist, beides zu kombinieren. Setzt du ein noindex auf eine Seite und blockierst sie zusätzlich in der robots.txt, crawlt Google die Seite nie, liest das noindex nie, und die URL kann im Index bleiben. Um eine Seite aus den Ergebnissen zu nehmen, lässt du sie crawlbar und lieferst noindex aus. Diese Hälfte deckt der Leitfaden zum noindex-Tag ab.

Was dir die Search Console sagt, und wann

Der robots.txt-Bericht in der Search Console (Einstellungen > robots.txt) zeigt die Versionen, die Google abgerufen hat, wann das war und ob der Abruf erfolgreich war oder auf Verarbeitungsprobleme stieß. Für die Diagnose ist er nützlich, sobald du weißt, dass etwas nicht stimmt, aber er schickt dir keine E-Mail, wenn sich eine Zeile ändert. Das erste automatische Signal ist meist ein Anstieg bei „Durch robots.txt-Datei blockiert“ im Seiten-Bericht, und der erscheint erst, nachdem Google URLs unter den neuen Regeln neu gecrawlt hat. Außerdem hält Google die robots.txt bis zu 24 Stunden im Cache, selbst Googles eigener Abruf kann der Änderung also einen Tag hinterherhinken.

Einen einfachen Check selbst bauen

Bei einer Handvoll Websites und Zugriff auf einen Server deckt ein kleines Skript, das stündlich per Cron läuft, die Grundlagen ab:

#!/bin/sh
mkdir -p /var/lib/robots-watch && cd /var/lib/robots-watch || exit 1
touch last.txt
curl -s -o new.txt -w "%{http_code}" https://example.com/robots.txt > status.txt
if ! grep -qx 200 status.txt; then
  mail -s "robots.txt-Fehler" du@example.com < status.txt
  exit 1
fi
if ! cmp -s new.txt last.txt; then
  diff last.txt new.txt | mail -s "robots.txt geändert" du@example.com
fi
mv new.txt last.txt

Es prüft neben dem Inhalt auch den Statuscode, und das ist wichtig, weil ein anhaltender 5xx genauso ernst ist wie eine falsche Regel. Die Schwächen zeigen sich, sobald die Liste der Websites wächst. Du brauchst einen Eintrag pro Website und einen funktionierenden Mailversand, du erfährst nichts über noindex- oder Sitemap-Änderungen aus demselben Deploy, und niemand merkt, wenn der Cronjob nicht mehr läuft.

Den robots.txt-Alert mit Deltio einrichten

Deltio ruft die robots.txt jeder Website, die du hinzufügst, im Rahmen seines täglichen Checks ab, vergleicht sie mit der Version aus dem vorherigen Check und schickt einen Alert an Slack und per E-Mail für die betreffende Website, wenn sie sich geändert hat. Derselbe Durchlauf prüft noindex, Canonicals, Titles und die URLs in der Sitemap. Ein Staging-Deploy, das mehrere Dinge auf einmal kaputtmacht, kommt dadurch als ein zusammenhängender Satz Alerts bei dir an. Was alles abgedeckt ist, listet der Artikel zu SEO-Änderungsalerts.

Die ehrliche Grenze ist die Frequenz. Bei einem täglichen Check wird eine Änderung, die kurz nach einem Check passiert, am folgenden Tag gemeldet, während ein stündliches Skript wie das obige sie früher erwischen würde. Rechnet man Googles eigenes Caching der Datei und die Zeit für einen erneuten Crawl mit ein, kommt ein Alert am selben oder nächsten Tag trotzdem normalerweise an, bevor sich der Schaden in der Search Console zeigt.

Als erste Website eignet sich die, die dir die meisten Sorgen macht, ob wegen des dichtesten Deploy-Kalenders oder wegen der Entwickler, die dir am wenigsten erzählen. Alle Pläne kannst du 14 Tage kostenlos testen.