Es ist eine gängige Praxis, ganze Staging-Umgebungen per robots.txt zu blockieren - wir sehen, dass etwa 50% unserer Website-Migrationskunden das tun. Hier ist der Grund, warum das keine gute Idee ist.
Wenn Webmaster eine Website-Migration vorbereiten, entscheiden sie sich oft dafür, eine robots.txt-Datei mit dem folgenden Inhalt in die Staging-Umgebung der neuen Website einzufügen:
User-Agent: *
Nicht zulassen: /
Diese Anweisungen fordern Robots auf, sich von allen Seiten der Website fernzuhalten. Die Idee hinter einer solchen Implementierung ist, zu verhindern, dass der Inhalt der Staging-Umgebung von Suchmaschinen indiziert wird.
Verwende die “echte” robots.txt-Datei
Die kurze und einfache robots.txt-Datei, die wir oben gesehen haben, ist natürlich nicht diejenige, die benötigt wird, wenn die neue Website online geht. Die “echte” robots.txt wird ein bisschen komplexer sein. Aus folgenden Gründen ist es ratsam, diese endgültige robots.txt bereits in die Staging-Umgebung einzufügen:
- Erstens kannst du bereits in der Staging-Umgebung mit einem Crawler, der die robots.txt-Datei beachtet, und ohne benutzerdefinierte robots.txt-Einstellungen das echte Crawling-Verhalten simulieren. Auf diese Weise kannst du zum Beispiel überprüfen, ob alle Seiten intern korrekt verlinkt sind, auch wenn gesperrte Seiten nicht gecrawlt werden, oder ob Crawl-Ressourcen auf Seiten verschwendet werden, die über die robots.txt-Datei gesperrt werden sollten, es aber noch nicht sind.
- Zweitens: Indem du die “echte” robots.txt-Datei in der Staging-Umgebung verwendest, vermeidest du das Risiko, mit einer robots.txt-Datei live zu gehen, die deine gesamte Website blockiert. Die meisten SEOs haben wahrscheinlich schon von mehrere Fälle wo das passiert ist und viel Schmerz verursacht hat.
Verwende auch nicht “noindex” für alle Staging-Seiten
Eine sehr ähnliche (aber weniger verbreitete) Angewohnheit ist es, alle Seiten in der Staging-Umgebung auf “noindex” zu setzen. Auch hier soll verhindert werden, dass sie indiziert werden, aber die Probleme sind dieselben wie die oben beschriebenen:
Du möchtest überprüfen können, welche Seiten korrekt auf “noindex” gesetzt sind, bevor die Website online geht, oder welche Seiten auf “noindex” gesetzt werden müssen, es aber noch nicht sind. Und du willst auf keinen Fall, dass deine neue Website live geht, wenn alle Seiten auf “noindex” gesetzt sind.
Genauso wie du alle Seiten in deiner Staging-Umgebung per robots.txt blockierst, ist es auch keine gute Idee, sie alle auf “noindex” zu setzen.
Wie du deine Staging-Umgebung richtig schützt
Es ist natürlich äußerst wichtig, dass deine Staging-Umgebung nicht von Suchmaschinen indiziert wird, aber alle Seiten per robots.txt zu blockieren oder auf “noindex” zu setzen, ist nicht der richtige Weg. Staging-Umgebungen sollten mit einem HTTP-Benutzernamen und einem Passwort geschützt werden, oder der Zugang sollte auf bestimmte IP-Adressen beschränkt werden.
In beiden Fällen können die Crawler, die du für deine Pre-Migrationsanalyse verwendest, weiterhin auf die Staging-Umgebung zugreifen, wenn sie richtig konfiguriert sind. Fast alle Crawling-Tools können sich mit einem HTTP-Benutzernamen und einem Kennwort in die Staging-Umgebung einloggen, und die meisten von ihnen können deine Staging-Umgebung auch mit einer statischen IP-Adresse crawlen, die du auf eine Whitelist setzen kannst.
Indem du die robots.txt- und “noindex”-Einstellungen verwendest, die du brauchst, wenn die Seite live geht, kannst du sicherstellen, dass du das echte Crawling-Verhalten in der Staging-Umgebung simulierst. Ein weiterer Vorteil der hier empfohlenen Methoden ist, dass sie viel sicherer sind - robots.txt und “noindex”-Anweisungen können von Crawlern immer ignoriert werden, während HTTP-Authentifizierung und IP-Beschränkung sie definitiv fernhalten.
Was sind deine Gedanken und Erfahrungen?
Was hältst du davon, ganze Staging-Umgebungen über robots.txt-Dateien zu sperren? Wir würden uns freuen, deine Meinung in den Kommentaren zu hören.
English 
German
5 Antworten
Hallo Eoghan! Danke für diesen tollen Beitrag.
Ich denke, du hast Recht, wenn du sagst, dass die beste Lösung darin besteht, den Zugriff auf die Staging-Website nur von bestimmten IPs aus zuzulassen, oder mit einem Benutzer und einem Passwort, was übrigens auch die Verwaltung komplexer macht.
Für IPs, wenn du Remote-Mitarbeiter (ohne gemeinsames VPN), externe Mitarbeiter, automatisierte Tests durch Drittanbieterdienste usw. einsetzt. Das kann ganz schön mühsam werden. Die Eingabe von Benutzern und Passwörtern macht das Crawlen und Testen etwas komplizierter, aber mit den heutigen Tools sollte das kein Problem sein.
Wenn ich mit guten, verteilten Teams mit automatisierten Tests arbeite, verwenden wir nur robots.txt, weil das in den meisten Fällen sicher genug ist. Wenn ich weiß, dass das Team seltsame Dinge tun kann und die Zeit bis zur Bereitstellung lang ist, verwende ich Benutzer und Passwort, um das Projekt zu schützen.
Danke fürs Teilen!
Hallo Esteve,
Vielen Dank, dass du deine Gedanken mit uns teilst. Ich stimme zu, dass die IP-Beschränkung ein Problem sein kann, vor allem, wenn du Leute hast, die keine statische IP haben, oder wenn du Tools verwenden willst, die diese Funktion nicht bieten. Meine Lieblingslösung ist auch HTTP-Benutzer und Passwort.
Hallo Eoghan, ich habe eine Frage, die weiter geht. Angenommen, ich möchte einige Tests mit GSC in der Staging-Umgebung durchführen: developing.example.com. Ich müsste doch eine robots.txt haben, die die URL, die ich teste, zulässt, oder? Wenn ich mich nicht irre, kann ich das nicht über http-Benutzer+Passwort und auch nicht über blockierte IP-Methoden machen. Irgendeine Idee/Lösung? Vielen Dank im Voraus!!!
Vielen Dank für deinen Kommentar. Was möchtest du mit GSC in einer Staging-Umgebung testen? GSC ist für Live-Seiten interessant, aber mir fallen nicht viele Anwendungsfälle für eine Staging-Umgebung ein. Was sind deine Ideen?
Wenn du an Tools wie das Structured Data Testing Tool oder das Mobile-Friendly Test Tool denkst, Tunnelbau könnte eine Option für dich sein. Ist das hilfreich?
Hallo, Eoghan. Danke für deine Antwort. Ich denke über diese Anwendungen nach:
- Ich würde das neue Web gerne auf Fetch & Render testen
- Ich möchte viele Seiten aus dem Index entfernen, die zu einem früheren Zeitpunkt indiziert wurden, als die IP-Wand noch nicht aufgebaut war.
Tunneling ist eine tolle Lösung, die ich nicht kannte. Danke dafür!