Die neue Website ist seit zwei Tagen online. Sie reichen die Sitemap in der Search Console ein und bekommen als Antwort „Konnte nicht abgerufen werden". Sie prüfen die Startseite mit dem Live-Test und lesen „Durch robots.txt-Datei blockiert". Dann öffnen Sie die robots.txt im Browser, und dort steht, dass alles erlaubt ist.
Genau das ist uns diese Woche bei einem Kundenprojekt passiert, einem Gebäudedienstleister im Taunus. Der Fall ist typisch für jeden Relaunch, bei dem die Seite vor dem Livegang eine Weile gesperrt war. Die Ursache liegt nicht auf Ihrem Server, sondern in zwei Zwischenspeichern, die Sie beide nicht direkt sehen.
Kurz gefasst: Google liest Ihre robots.txt nicht bei jedem Besuch neu, sondern hält eine Kopie vor. Steht in dieser Kopie noch die Sperre aus der Bauphase, blockiert Google die Seite, egal was auf dem Server inzwischen steht. Die Lösung ist ein erzwungenes Neu-Einlesen in der Search Console, und vorher die Kontrolle, was ein Besucher ohne Cache tatsächlich bekommt.
Was in der Search Console zu sehen war
Drei Meldungen, die auf den ersten Blick nach drei Problemen aussehen:
- Unter Sitemaps der Status „Konnte nicht abgerufen werden", Typ „Unbekannt", die Spalte „Zuletzt gelesen" leer.
- Im Live-Test der URL-Prüfung: „Seite kann nicht gecrawlt werden: Durch robots.txt-Datei blockiert".
- Bei der Startseite der Hinweis „Indexiert, obwohl durch robots.txt-Datei blockiert".
Alle drei haben dieselbe Wurzel. Während der Bauphase stand in der robots.txt ein „Disallow: /", damit die halbfertige Seite nicht im Index landet. Am Tag des Livegangs wurde die Datei auf „Allow: /" umgestellt. Google hatte die Sperre aber schon gelesen und arbeitete mit dieser Kopie weiter.
Zwischenspeicher eins: Google selbst
Google holt die robots.txt einer Domain nicht bei jeder Anfrage. Die Datei wird zwischengespeichert, in der Regel für bis zu 24 Stunden, in Einzelfällen länger. Solange diese Kopie gilt, entscheidet sie darüber, was der Googlebot anfassen darf. Ein Live-Test in der Search Console kann deshalb eine Sperre melden, die auf dem Server längst aufgehoben ist.
Sichtbar wird das im robots.txt-Bericht der Search Console. Er liegt unter „Einstellungen", dann „Crawling", dann „robots.txt". Dort steht, wann Google die Datei zuletzt geholt hat und mit welcher Größe. In unserem Fall stammte der Abruf aus der Zeit vor der Umstellung. Der Bericht zeigt außerdem nur den Host, den Google zuerst kannte, bei uns die Adresse ohne www. Das ist kein Fehler, Google folgt der Weiterleitung.
Google navigiert nach der Karte, die es zuletzt geholt hat. Bild KI-generiert.
Zwischenspeicher zwei: das CDN Ihres Hosters
Der zweite Speicher ist tückischer, weil er dazu führen kann, dass Google die neue Datei auch nach 24 Stunden noch nicht bekommt. Viele Hoster liefern Seiten heute über ein Content Delivery Network aus, das Dateien am Netzrand vorhält. Bei unserem Projekt lieferte dieser Rand nach dem Upload weiter die alte robots.txt mit der Sperre, obwohl auf dem Ursprungsserver längst die neue lag.
Der Grund war unscheinbar: Der Server gab für Textdateien keine Verweildauer mit, also hat sich das CDN selbst eine ausgedacht. Aufgefallen ist es nur, weil wir die Datei zusätzlich ohne Cache-Umgehung abgerufen haben. Die übliche Upload-Kontrolle mit einem Zufallsparameter in der Adresse fragt am Cache vorbei direkt beim Ursprung nach. Sie beantwortet die Frage „ist die Datei angekommen", nicht die Frage „was bekommt Google".
Zwei Fragen, zwei Prüfungen. Ist die Datei auf dem Server? Und: Was liefert die Domain einem Besucher, der keinen Trick benutzt?
Behoben haben wir das mit einer Zeile in der Serverkonfiguration, die für robots.txt und sitemap.xml eine kurze Verweildauer von fünf Minuten vorgibt. Danach hat das CDN neu geholt und die Freigabe ausgeliefert.
Die drei Schritte, in dieser Reihenfolge
1. Prüfen, was wirklich ausgeliefert wird
Rufen Sie die robots.txt im Browser auf, ohne Zusatzparameter, am besten aus einem privaten Fenster. Steht dort noch die Sperre, liegt das Problem beim Hoster oder CDN, und die Search Console kann nichts dafür. Erst wenn hier „Allow" steht, lohnt sich der nächste Schritt.
2. In der Search Console neu einlesen lassen
Im robots.txt-Bericht öffnen Sie das Menü neben der Datei und wählen „Erneutes Crawling anfordern". Google holt die Datei dann innerhalb von Minuten bis wenigen Stunden neu. Ohne diesen Schritt läuft die alte Kopie einfach ab, das dauert aber bis zu einem Tag.
3. Sitemap neu einreichen und Startseite anfordern
Löschen Sie die Sitemap in der Übersicht und reichen Sie dieselbe Adresse noch einmal ein. Prüfen Sie danach die Startseite per Live-Test. Steht dort „Seitenabruf: Erfolgreich", beantragen Sie die Indexierung. Die Sitemap-Datei selbst können Sie nicht zur Indexierung anmelden, das lehnt Google immer ab, weil eine XML-Datei keine Seite ist.
Wie Sie das beim nächsten Relaunch vermeiden
Der sauberste Weg ist, die Sperre gar nicht erst über die robots.txt zu setzen. Eine Seite in der Bauphase bekommt ein „noindex" im Seitenkopf. Google darf sie dann lesen, nimmt sie aber nicht in den Index. Dieser Hinweis wird pro Seite ausgewertet und hängt an keinem Zwischenspeicher der robots.txt. Beim Livegang entfernen Sie ihn, und Google verarbeitet die Freigabe beim nächsten Besuch.
Ein „Disallow: /" hat dagegen einen Nebeneffekt, den viele unterschätzen: Google darf die Seite nicht lesen und kann deshalb auch kein noindex sehen. Kennt Google die Adresse aus anderen Quellen, landet sie trotzdem im Index, nur ohne Inhalt. Genau daher kommt die Meldung „Indexiert, obwohl durch robots.txt-Datei blockiert".
Wenn Sie die Sperre trotzdem über die robots.txt gesetzt haben, planen Sie den Livegang mit einem Tag Vorlauf: Datei umstellen, ohne Cache prüfen, in der Search Console neu einlesen lassen, und erst dann die Sitemap einreichen. Dann sehen Sie am ersten Tag grüne Haken statt roter Meldungen.
Relaunch ohne Überraschungen in der Search Console
Wir begleiten Livegänge mit einer festen Prüfliste: robots.txt, Weiterleitungen, Sitemap, Cache und Indexierung, jeweils vor und nach dem Umschalten. Ein Gespräch von 30 Minuten reicht, um zu klären, was bei Ihrem Projekt ansteht.
Termin vereinbaren →Was Sie sich merken sollten
- „Durch robots.txt blockiert" beschreibt die Kopie, die Google hat, nicht die Datei auf Ihrem Server.
- Prüfen Sie die robots.txt immer auch ohne Cache-Umgehung. Sonst sehen Sie den Ursprung und nicht das, was Google sieht.
- Der robots.txt-Bericht in der Search Console zeigt Abrufdatum und Größe und bietet das erneute Einlesen an.
- Für die Bauphase ist noindex im Seitenkopf der bessere Schutz als eine Sperre in der robots.txt.
Wie ein Relaunch insgesamt abläuft, ohne Rankings zu verlieren, steht in unserer Relaunch-Checkliste. Was nach dem Livegang an Suchmaschinenarbeit folgt, beschreibt die Seite Suchmaschinen-Marketing.