Staging-Umgebung: Warum robots.txt die Testseite nicht schützt

Eine Testumgebung mit einer robots.txt abzusichern ist die verbreitetste Lösung und die unsicherste. Der Grund ist ein Widerspruch, der in Googles Dokumentation klar benannt ist – man muss ihn nur einmal zu Ende denken.

Der Widerspruch

Googles Anleitung zum Ausschluss aus dem Index formuliert es deutlich: Damit die noindex-Regel wirksam ist, darf die Seite oder Ressource nicht durch eine robots.txt-Datei blockiert sein.

Das ist logisch zwingend. Eine noindex-Anweisung steht auf der Seite. Wer die Seite nicht abrufen darf, liest die Anweisung nicht. Eine per robots.txt gesperrte Seite mit noindex ist damit eine Seite ohne wirksames noindex – und sie kann über Verweise von außen weiterhin in den Ergebnissen erscheinen.

Und die naheliegende Abkürzung existiert nicht: Die Angabe von noindex in der robots.txt wird von Google nicht unterstützt. Es gibt genau zwei unterstützte Wege – das Meta-Tag <meta name="robots" content="noindex"> im Seitenkopf und den HTTP-Header X-Robots-Tag, letzterer auch für Dateien wie PDFs und Bilder.

Die Methoden im Vergleich

Die letzte Zeile verdient einen Hinweis: Die WordPress-Option unter Einstellungen → Lesen ist für eine Testumgebung besser als nichts, aber sie ist eine Bitte an Suchmaschinen, kein Schutz. Wer eine unfertige Website, Testdaten oder Kundeninhalte in der Testumgebung hat, will nicht, dass sie gelesen werden – und nicht bloß, dass sie nicht gelistet werden.

Warum es bei einem Relaunch besonders wehtut

Das eigentliche Risiko einer Testumgebung liegt nicht darin, dass sie indexiert wird. Es liegt darin, dass ihre Einstellungen mit auf die Produktivseite wandern.

Der Ablauf ist immer derselbe: In der Testumgebung steht ein globales noindex. Die Seite geht live. Das noindex bleibt. Zwei Wochen später fällt der Sichtbarkeitsverlust auf, und die Ursache ist eine Zeile im Seitenkopf. Dieser Fall steht in der Liste der technischen Kandidaten bei Rankingverlusten an erster Stelle – und er ist deshalb so heimtückisch, weil die Seite völlig normal aussieht.

Die Vorsorge ist eine Zeile auf der Startbereitschaftsliste: Nach dem Livegang den Quelltext auf noindex prüfen und die robots.txt aufrufen. Die vollständige Reihenfolge steht in Website-Relaunch und SEO.

Die Einrichtung, die funktioniert

1. Eigene Subdomain für die Testumgebung, nicht ein Unterverzeichnis der Produktivseite. Die Begründung steht in Subdomain oder Unterverzeichnis – hier ist es der eine Fall, in dem die Trennung eindeutig richtig ist.
2. Passwortschutz auf Serverebene, nicht über ein Plugin. Ein Plugin schützt erst, wenn WordPress lädt; eine Serverabfrage schützt vorher.
3. Zusätzlich noindex als zweite Sicherung, für den Fall, dass der Passwortschutz einmal ausfällt.
4. Keine Kundendaten in der Testumgebung. Wer eine Datenbank aus dem Produktivsystem kopiert, kopiert Bestellungen, Adressen und Nachrichten mit – und verarbeitet sie damit an einer weiteren Stelle.
5. Eine Checkliste für den Livegang, die noindex, robots.txt, Suchmaschinen-Einstellung und Weiterleitungen abfragt.

Punkt vier wird regelmäßig übersehen und ist der einzige, bei dem es nicht um Sichtbarkeit geht. Eine Testumgebung mit echten Kundendaten ohne Zugangsschutz ist ein Datenschutzvorfall, der nur noch nicht aufgefallen ist. Wie man die Installation im Übrigen absichert, steht in WordPress-Sicherheit.

Die Kontrolle

Zwei Abfragen, einmal im Quartal:

• site:staging.beispiel.de – steht die Testumgebung im Index? Wozu Suchoperatoren taugen und wozu nicht, steht in Suchoperatoren.
• Die Testumgebung im privaten Fenster aufrufen – kommt eine Passwortabfrage?

Dazu ein Blick in die eigene Logfile-Analyse, falls die Testumgebung Zugriffe verzeichnet, die nicht aus dem eigenen Haus kommen. Das ist der schnellste Hinweis darauf, dass die Adresse irgendwo aufgetaucht ist.