Wie hältst du die Staging-Umgebung aus Google heraus und trotzdem testbar?

Was ist eine Staging-Umgebung?

Eine Staging-Umgebung ist eine Kopie der Website unter einer eigenen Adresse, zum Beispiel staging.example.com. Je nach Team heißt sie auch DEV, Testumgebung, Testsystem oder Pre-Prod. Dort laufen neue Releases, bevor sie live gehen. Entwicklung, Redaktion und SEO prüfen Änderungen, und beim Relaunch steht dort oft die komplette neue Website.

Für SEO muss die Staging-Umgebung zwei Anforderungen erfüllen. Sie darf nicht in den Google-Index geraten. Gleichzeitig soll sie sich so verhalten wie die spätere Live-Seite, damit Tests aussagekräftig sind.

Was passiert, wenn Google die Staging-Umgebung findet?

Google findet neue Adressen über Links, etwa aus einer erreichbaren Sitemap, einem Canonical oder einem Link, der versehentlich auf der Live-Seite steht. Ist die Umgebung offen erreichbar, kann Google die Seiten crawlen und indexieren. Dann gibt es zwei fast gleiche Versionen deiner Inhalte, und Google muss entscheiden, welche es als kanonische URL wählt. Dazu kommen Inhalte, die noch gar nicht öffentlich sein sollen, etwa neue Produkte, Preise oder Kampagnen.

Die Methoden im Vergleich

Vier Methoden begegnen dir in der Praxis immer wieder, dazu das Canonical als Signal. Nur zwei davon halten Bots wirklich fern.

Warum du Staging nicht komplett per robots.txt sperren solltest

Viele Teams legen auf der Staging-Umgebung eine robots.txt an, die allen Bots alles verbietet. Sie sieht so aus.

Die Idee dahinter ist verständlich. Google beschreibt die robots.txt aber als Werkzeug, um das Crawling zu steuern, und schreibt ausdrücklich, dass sie kein Mittel ist, um eine Seite aus Google herauszuhalten. Verlinken andere Seiten auf eine gesperrte URL, kann sie trotzdem in den Suchergebnissen erscheinen, dann ohne Beschreibung. Der Standard RFC 9309 hält fest, dass die Regeln keine Zugangskontrolle sind. Bots, die sich nicht an die Datei halten, rufen die Seiten trotzdem ab.

Nutze die echte robots.txt schon auf Staging

Die kurze Sperrdatei ist nicht die Datei, die die Website live braucht. Die echte robots.txt ist meist länger und sperrt gezielt einzelne Bereiche, etwa Filter, die interne Suche oder den Checkout. Lege diese Datei schon auf der Staging-Umgebung ab. Das hat zwei Vorteile.

• Du kannst das spätere Crawl-Verhalten auf Staging nachstellen. Ein Crawler, der die robots.txt beachtet, zeigt dir, ob alle wichtigen Seiten intern verlinkt und erreichbar sind, auch wenn gesperrte Bereiche wegfallen. Er zeigt auch, wo Crawling auf Seiten verloren geht, die eigentlich gesperrt sein sollten.
• Die Sperrdatei kann beim Go-live gar nicht erst auf den Live-Server kommen. Das ist wichtig, weil Google die robots.txt in der Regel bis zu 24 Stunden im Cache hält. Eine versehentliche Komplettsperre wirkt also nach, auch wenn du sie schnell korrigierst.

Die robots.txt gilt nur für den Host, das Protokoll und den Port, unter dem sie liegt. Eine Staging-Subdomain hat deshalb ihre eigene Datei. Liegt Staging in einem Verzeichnis der Live-Domain, etwa unter /staging/, gilt die robots.txt der Live-Seite.

Warum noindex auf allen Seiten genauso riskant ist

Etwas seltener steht auf allen Seiten der Staging-Umgebung ein noindex, als Meta-Tag <meta name="robots" content="noindex"> im Template oder als HTTP-Header X-Robots-Tag: noindex. Auch hier soll die Indexierung verhindert werden, und die Probleme sind dieselben.

Vor dem Go-live willst du prüfen, welche Seiten korrekt auf noindex stehen und bei welchen es noch fehlt. Steht alles auf noindex, ist diese Prüfung nicht möglich. Geht die Regel mit live, verschwindet die neue Website nach und nach aus dem Index, denn Google entfernt eine Seite, sobald es das noindex beim nächsten Crawl findet.

noindex wirkt außerdem nur, wenn Google die Seite crawlen darf. Sperrt die robots.txt dieselbe Seite, sieht Google die Regel nie. Disallow: / und noindex zusammen schützen deshalb nicht besser als eine der beiden Maßnahmen allein.

Möchtest du zusätzlich zum Passwortschutz ein X-Robots-Tag setzen, gehört es in die Serverkonfiguration des Staging-Hosts. Dann ist die Regel an die Umgebung gebunden und geht nicht mit dem Code live. Für Tests der noindex-Angaben stellst du deinen Crawler so ein, dass er diesen Header ignoriert.

So schützt du die Staging-Umgebung richtig

Sicher ist eine Staging-Umgebung erst, wenn Unbefugte sie gar nicht erreichen. Dafür gibt es zwei bewährte Wege, den Passwortschutz per HTTP-Authentifizierung und die Freigabe für bestimmte IP-Adressen. Google empfiehlt für vertrauliche Inhalte einen Passwortschutz. Ohne Zugangsdaten antwortet der Server mit dem Statuscode 401. Google behandelt alle 4xx-Antworten außer 429 gleich und nimmt solche URLs aus dem Index, falls sie dort schon waren.

In der Praxis ist der Passwortschutz meist die einfachere Wahl. Beide Wege lassen sich kombinieren, etwa eine IP-Freigabe für das Firmennetz und ein Passwort für alle anderen. Manche Teams geben Crawler zusätzlich über einen eigenen HTTP-Header frei. Wichtig ist, dass auch die robots.txt und die Sitemap der Staging-Umgebung hinter dem Schutz liegen.

So bleibt Staging testbar

• Echte Regeln verwenden. Auf Staging gelten dieselbe robots.txt und dieselben noindex-Angaben wie später live. Den Schutz übernimmt das Passwort oder die IP-Freigabe.
• Hostnamen aus der Konfiguration. Canonicals, hreflang, Sitemaps und interne Links beziehen den Hostnamen aus einer Einstellung je Umgebung. Google empfiehlt im Canonical absolute URLs. Ein Crawl auf Staging zeigt dann, ob alle Verweise einheitlich sind, und nach dem Go-live zeigt keiner auf die Staging-Adresse.
• Zugang für den Crawler. Hinterlege im SEO-Crawler Benutzername und Passwort oder gib seine feste IP-Adresse frei. Dann crawlst du die Staging-Umgebung so, wie Google später die Live-Seite sieht.
• Google-Tools per Tunnel. Testtools wie der Test für Rich-Suchergebnisse rufen die Seite als Google ab und erreichen keine geschützten Seiten. Für lokale oder per Firewall geschützte Seiten beschreibt Google einen Tunnel, etwa mit ngrok.
• Fehlende Daten einplanen. Auf Staging fehlen oft Produktdaten, Bilder oder Texte. Prüfe dort vor allem Templates und Regeln, die später auf allen Seiten eines Typs gelten.

Was tun, wenn Staging schon im Google-Index ist?

1. Schütze die Umgebung mit einem Passwort oder einer IP-Freigabe. Beim nächsten Crawl bekommt Google einen 401 oder 403 und nimmt die URLs nach und nach aus dem Index.
2. Beschleunigen kannst du das mit dem Tool „Entfernen“ der Search Console. Du brauchst dafür eine Property, die den Staging-Host umfasst. Eine Domain-Property, die du per DNS-Eintrag bestätigst, schließt alle Subdomains ein. Mit der Option „Alle URLs mit diesem Präfix entfernen“ erfasst du die ganze Umgebung. Laut Google hält die Sperre etwa sechs Monate.
3. Sperre die URLs nicht zusätzlich per robots.txt. Google rät davon ab, weil es dann die neue Antwort des Servers nicht sieht.

Welche Staging-Einstellungen dürfen beim Go-live nicht mitgehen?

Beim Go-live wird die Staging-Umgebung zur Live-Seite oder ihr Code zieht auf den Live-Server um. Was dabei an Schutz und Sonderregeln mitkommt, wirkt auf der Live-Seite weiter.

Wie du jedes Release vor und nach dem Go-live Schritt für Schritt prüfst, zeigt der Ratgeber SEO-Check vor dem Go-live. Für einen kompletten Relaunch hilft die Relaunch-Checkliste.

Checkliste für die Staging-Umgebung

Häufige Fragen