Staging-Umgebung: Änderungen testen, bevor Besucher sie sehen

Eine Staging Umgebung ist eine Kopie Ihrer Website, auf der Sie Updates, neue Plugins oder ein neues Design ausprobieren, bevor Sie es auf der echten Seite tun. Geht dort etwas schief, merkt es kein Besucher. Drei Dinge machen eine gute Kopie aus: Sie gleicht technisch der Live-Seite, sie ist vor Suchmaschinen und Fremden geschützt, und sie löst keine Mails, Zahlungen oder Bestellungen aus. Der heikelste Teil kommt am Ende, wenn die getesteten Änderungen zurück auf die Live-Seite sollen.

Wofür eine Staging Umgebung gut ist

Die meisten Ausfälle kleiner Websites entstehen nicht durch Angriffe, sondern durch Updates. Ein Plugin verträgt die neue PHP-Version nicht, ein Theme-Update überschreibt Anpassungen, ein Shop-Update ändert den Ablauf an der Kasse. Auf einer Staging Umgebung sehen Sie das vorher. Typische Anlässe sind:

• Updates von CMS, Plugins und Themes, vor allem größere Sprünge der Version
• ein Wechsel der PHP-Version
• neue Erweiterungen oder ein neues Design
• Änderungen am Bestellablauf oder an Formularen
• Fehlersuche, ohne die Live-Seite in den Wartungsmodus zu setzen

Größere Teams arbeiten mit drei Stufen: einer Umgebung für die Entwicklung auf dem eigenen Rechner, der Staging Umgebung auf dem Server und der Live-Seite. Für die meisten kleinen Websites reichen Staging und Live.

Drei Wege zur Staging Umgebung

Staging-Funktion des Hosters

Viele Hoster bieten Staging inzwischen per Klick an, vor allem bei Tarifen für WordPress. In Plesk erledigt das das WordPress Toolkit mit der Funktion Klonen, bei cPanel oft Softaculous. Die Kopie landet auf einer Subdomain mit eigener Datenbank. Gute Umsetzungen spielen Änderungen später auch zurück und fragen dabei, ob nur Dateien, nur die Datenbank oder beides übertragen werden soll. Beim Managed Hosting gehört eine Staging-Funktion fast immer dazu.

Staging per Plugin

Ohne Funktion des Hosters hilft bei WordPress ein Plugin wie WP Staging. Die kostenlose Version legt die Kopie in einem Unterordner an und nutzt dieselbe Datenbank mit eigenen Tabellen. Das geht schnell, hat aber Nachteile: Live-Seite und Kopie teilen sich Speicher und Rechenleistung, und ein Fehler in der gemeinsamen Datenbank kann im ungünstigen Fall beide treffen. Das Zurückspielen von Änderungen gibt es bei vielen Plugins nur in der Bezahlversion. Für Joomla eignet sich Akeeba Backup: Sie sichern die Seite und stellen sie mit dem mitgelieferten Werkzeug Kickstart auf einer Subdomain wieder her.

Staging von Hand

Der Weg von Hand funktioniert mit jedem CMS und zeigt am besten, was dabei passiert. Sie brauchen eine Subdomain wie staging.beispiel.de, eine leere Datenbank und einen SSH-Zugang:

1. Subdomain anlegen und auf einen eigenen Ordner zeigen lassen, etwa ~/staging
2. Dateien kopieren: rsync -a ~/html/ ~/staging/
3. Datenbank kopieren: mysqldump livedb | mysql stagingdb, die Zugangsdaten stehen dabei in ~/.my.cnf
4. In der Konfiguration der Kopie die Zugangsdaten der neuen Datenbank eintragen
5. Alle Adressen der Live-Seite durch die Staging-Adresse ersetzen

Den letzten Schritt erledigen Sie bei WordPress mit WP-CLI. Ein einfaches Suchen und Ersetzen in der SQL-Datei reicht nicht, weil WordPress viele Einstellungen serialisiert speichert. Dabei steht die Länge jedes Textes mit in der Datenbank, und eine längere oder kürzere Adresse macht den Eintrag unlesbar. WP-CLI rechnet diese Längen richtig um:

cd ~/staging
wp search-replace 'https://www.beispiel.de' 'https://staging.beispiel.de' --skip-columns=guid --dry-run

Zeigt der Probelauf mit --dry-run plausible Treffer, starten Sie den Befehl ohne diese Option. Alle Parameter beschreibt die Dokumentation von WP-CLI. Beim TYPO3-Hosting stellen Sie stattdessen die Site-Konfiguration auf die neue Domain um und setzen den Kontext auf Staging. Bei Joomla passen Sie in der configuration.php die Zugangsdaten und die Pfade für Logs und temporäre Dateien an.

Die Kopie vor Fremden schützen

Eine ungeschützte Staging Umgebung ist ein öffentliches Duplikat Ihrer Website. Suchmaschinen können sie finden, und Fremde sehen unfertige Inhalte oder schlimmstenfalls Kundendaten. Am wirksamsten ist ein Passwort vor der ganzen Seite. Bei Hostern mit Apache geht das im Kundenmenü als Verzeichnisschutz oder mit einer Datei .htaccess im Ordner der Kopie:

AuthType Basic
AuthName "Staging"
AuthUserFile /home/benutzer/.htpasswd
Require valid-user

Die Datei .htpasswd legen Sie außerhalb des Webverzeichnisses an, etwa mit htpasswd -c ~/.htpasswd tester, und tragen in der .htaccess ihren vollständigen Pfad ein. Eine Sperre in der robots.txt reicht nicht. Sie verbietet nur das Crawlen, und eine verlinkte Adresse kann trotzdem in den Suchergebnissen auftauchen. Als zweite Sicherung aktivieren Sie in WordPress die Option „Suchmaschinen davon abhalten“ oder setzen den Header X-Robots-Tag: noindex.

Was auf der Kopie abgeschaltet werden muss

Die Kopie enthält alle Einstellungen der Live-Seite, auch die Verbindungen nach außen. Ohne Gegenmaßnahmen verschickt sie Bestellbestätigungen an echte Kunden, bucht Zahlungen oder meldet Lagerbestände an Ihre Warenwirtschaft. Gehen Sie deshalb gleich nach dem Anlegen diese Liste durch:

• E-Mails: Versand abschalten oder alle Mails an eine Testadresse umleiten. Bei WordPress gibt es dafür Plugins, und viele SMTP-Plugins haben eine eigene Option.
• Zahlungen: Zahlungsanbieter in den Testmodus stellen und die Live-Schlüssel entfernen. PayPal, Stripe und andere bieten dafür eigene Testzugänge.
• Cronjobs: Geplante Aufgaben wie Newsletter, Exporte oder Abgleiche laufen nur auf der Live-Seite. Bei einer Kopie von Hand übernehmen Sie die Crontab nicht.
• Schnittstellen: Verbindungen zu Warenwirtschaft, Marktplätzen oder Buchhaltung trennen, sonst landen Testbestellungen in echten Systemen.
• Statistik: Tracking abschalten, damit Testaufrufe Ihre Zahlen nicht verfälschen.

Seit WordPress 5.5 lässt sich die Umgebung in der wp-config.php mit define('WP_ENVIRONMENT_TYPE', 'staging'); kennzeichnen. Manche Plugins reagieren darauf und schalten heikle Funktionen ab. Verlassen Sie sich aber nicht darauf und prüfen Sie jeden Punkt der Liste selbst.

Was Sie auf der Kopie testen

Ein Blick auf die Startseite reicht nicht. Viele Fehler zeigen sich erst an Stellen, die selten jemand aufruft. Gehen Sie nach jedem Update dieselbe kurze Liste durch, am besten schriftlich, damit nichts untergeht:

1. Startseite, ein Beitrag, eine Kategorie und die Suche
2. Kontaktformular absenden und prüfen, ob die Mail an der Testadresse ankommt
3. Anmeldung im Backend und, falls vorhanden, im Kundenkonto
4. bei Shops eine Testbestellung bis zur Bestätigung, mit dem Zahlungsanbieter im Testmodus
5. die Ansicht auf dem Smartphone
6. das Fehlerprotokoll des Servers und die Konsole im Browser (Taste F12)

Das Fehlerprotokoll zeigt oft Probleme, die auf der Seite noch nicht sichtbar sind, etwa Warnungen zu veralteten PHP-Funktionen. Aus ihnen werden beim nächsten Update echte Fehler. Bei WordPress schreiben Sie solche Meldungen auf der Kopie mit define('WP_DEBUG', true); und define('WP_DEBUG_LOG', true); in eine Datei. Setzen Sie zusätzlich WP_DEBUG_DISPLAY auf false, damit die Meldungen nicht auf der Seite erscheinen.

Datenschutz auf der Testkopie

Die Kopie eines Shops enthält Namen, Adressen und Bestellungen echter Kunden. Für diese Daten gelten dieselben Regeln wie auf der Live-Seite: Zugriff nur für Berechtigte, Verarbeitung beim selben Hoster mit Vertrag zur Auftragsverarbeitung und Löschen, sobald die Kopie nicht mehr gebraucht wird. Besser ist es, Kundendaten in der Kopie zu anonymisieren oder für Tests nur eigene Testkonten zu nutzen. Mehr dazu im Ratgeber zum DSGVO-konformen Hosting.

Änderungen von der Staging Umgebung auf die Live-Seite übertragen

Hier passieren die meisten Fehler. Während Sie testen, läuft die Live-Seite weiter: Es kommen Bestellungen, Kommentare und Einträge aus Formularen dazu. Überschreiben Sie die Datenbank der Live-Seite mit der Kopie, sind all diese Daten weg.

Die sichere Regel lautet deshalb: Übertragen Sie Dateien, nicht die Datenbank. Bei den meisten Updates heißt das, Sie testen auf der Staging Umgebung, ob alles funktioniert, und führen dasselbe Update danach auf der Live-Seite noch einmal aus. Das ist kein doppelter Aufwand, sondern der Normalfall. Die Kopie hat gezeigt, dass das Update klappt und welche Einstellungen danach nötig sind.

Bei einem neuen Design oder größeren Umbauten wiederholen Sie Einstellungen im Backend von Hand oder exportieren sie, soweit das CMS es erlaubt. Muss die Datenbank doch komplett hinüber, etwa bei einer reinen Firmenseite ohne Bestellungen und Kommentare, gehen Sie so vor:

1. ein frisches Website-Backup der Live-Seite anlegen
2. die Seite für die Dauer der Übertragung in den Wartungsmodus setzen
3. Datenbank und Dateien übertragen und die Adressen zurück auf die Live-Domain ersetzen
4. Cache leeren, dann Startseite, Formulare und Login prüfen

Shops behandeln Sie strenger. Bei einem Onlineshop kopieren Sie die Datenbank grundsätzlich nicht von Staging nach Live. Funktionen des Hosters, die einzelne Tabellen auswählen lassen, helfen nur, wenn Sie genau wissen, wo Ihr Shop welche Daten ablegt.

Die Kopie aktuell halten

Eine Kopie veraltet schnell. Nach ein paar Wochen fehlen neue Inhalte, und Tests zeigen nicht mehr das echte Verhalten. Legen Sie die Staging Umgebung deshalb vor jedem größeren Update neu an oder gleichen Sie sie mit der Funktion Ihres Hosters ab. Achten Sie darauf, dass PHP-Version und Erweiterungen auf beiden Seiten gleich sind. Wer auf der Kopie mit PHP 8.4 testet und live noch 8.2 betreibt, testet etwas anderes, als er später einspielt.