WordPress-Staging: drei Wege zur Testumgebung

Eine Staging-Umgebung ist eine Kopie deiner WordPress-Seite unter einer eigenen Adresse, meist eine Subdomain wie staging.deine-domain.at. Dort spielst du eine neue Hauptversion, ein großes Plugin-Update oder ein neues Theme zuerst ein, siehst nach, ob Startseite, Formular und Kasse noch gehen, und wiederholst es erst dann auf der echten Seite. Das kostet beim ersten Mal eine halbe Stunde und danach ein paar Minuten je Update.

Staging ist keine Sicherung. Die Kopie fängt Fehler ab, bevor sie live passieren. Geht live trotzdem etwas schief, hilft nur eine Sicherung, die sich zurückspielen lässt; wie die aussieht, steht in WordPress-Backup.

Wann sich eine Testumgebung lohnt#

Update-Probe vor dem Live-Update: In der Wartung für 49 € im Monat laufen größere Updates erst auf einer Kopie, danach mit frischer Sicherung auf der echten Seite.

Für eine Visitenkarten-Seite mit fünf Plugins ist Staging bei Wartungsversionen übertrieben; dort reichen eine Sicherung und ein Blick auf die Seite danach. Sinnvoll wird es bei:

• Hauptversionen des Kerns, etwa 7.0 auf 7.1. Welche Version gerade aktuell ist, steht in Aktuelle WordPress-Version.
• Shops und Mitgliederbereichen, bei denen ein Fehler Geld oder Kundendaten kostet.
• Plugins, die tief eingreifen: Seitenbaukästen, Mehrsprachigkeit, Caching, Sicherheits-Plugins.
• Theme-Wechsel und PHP-Umstellungen. Eine neue PHP-Version lässt sich bei vielen Hostern je Subdomain einstellen; die Kopie zeigt, ob alles mitgeht.

Die Reihenfolge der Updates selbst, Plugins und Themes vor dem Kern, gilt auf Staging genauso wie live. Sie steht in WordPress-Updates.

Weg 1: Staging beim Hoster#

Viele Hoster bieten Staging im Kundenmenü an, meist unter „Staging“, „Testumgebung“ oder „Klonen“. Ein Klick legt eine Kopie von Dateien und Datenbank unter einer eigenen Adresse an, oft mit einem zweiten Klick, der Änderungen zurück auf live schiebt.

Das ist der bequemste Weg, und auf Servern mit genug Platz auch der schnellste. Drei Dinge sind trotzdem zu prüfen, weil jeder Hoster es anders löst: ob die Kopie automatisch hinter einem Passwort steht, ob der Mailversand auf der Kopie abgeschaltet ist und was „auf live übertragen“ genau überträgt. Ein Knopf, der die ganze Datenbank zurückschiebt, überschreibt alles, was live seit dem Anlegen der Kopie passiert ist.

Weg 2: Staging per Plugin#

Gibt der Hoster nichts her, legen Plugins eine Kopie an, meist in einem Unterverzeichnis derselben Installation oder auf einer Subdomain. Das funktioniert, hat aber zwei Grenzen. Die Kopie liegt auf demselben Server und derselben PHP-Version wie live, eine PHP-Umstellung lässt sich damit also oft nicht testen. Und das Plugin selbst ist ein weiteres Plugin mit Schreibrechten auf die ganze Installation, das gepflegt werden will. Wie man ein Plugin vor der Installation prüft, steht in WordPress-Plugins.

Weg 3: von Hand mit WP-CLI#

Mit SSH-Zugang und WP-CLI ist die Kopie in wenigen Befehlen gebaut, und du weißt genau, was passiert. Voraussetzung: eine Subdomain mit eigenem Verzeichnis und eine leere zweite Datenbank, beides im Kundenmenü des Hosters angelegt.

# auf live: Datenbank exportieren
cd ~/live
wp db export ~/staging.sql

# Dateien kopieren (ohne Caches und alte Sicherungen)
rsync -a --exclude 'wp-content/cache' ~/live/ ~/staging/

# in der Kopie: wp-config.php auf die zweite Datenbank umstellen
cd ~/staging
wp config set DB_NAME staging_db
wp config set DB_USER staging_user
wp config set DB_PASSWORD 'neues-passwort'
wp config set WP_ENVIRONMENT_TYPE staging

# Datenbank einspielen und Adressen umschreiben
wp db import ~/staging.sql
wp search-replace 'https://www.deine-domain.at' 'https://staging.deine-domain.at' --all-tables --dry-run
wp search-replace 'https://www.deine-domain.at' 'https://staging.deine-domain.at' --all-tables --skip-columns=guid

Zwei Hinweise dazu. Adressen nie mit einem einfachen Suchen-und-Ersetzen in der SQL-Datei ändern. WordPress speichert viele Einstellungen als serialisierte PHP-Daten, in denen die Länge jeder Zeichenkette mitgespeichert ist; ändert sich die Länge der Adresse, sind diese Einträge kaputt. wp search-replace behandelt serialisierte Daten laut Dokumentation richtig. Und --dry-run zeigt zuerst, wie viele Ersetzungen in welcher Tabelle anfallen, ohne etwas zu speichern. --all-tables nimmt auch Tabellen von Plugins mit, die WordPress selbst nicht kennt; die Spalte guid bleibt nach der Empfehlung der WP-CLI-Beispiele unverändert.

Die Datei ~/staging.sql danach löschen. Sie enthält die ganze Datenbank, samt Benutzern und Passwort-Hashes.

WP_ENVIRONMENT_TYPE: was die Einstellung tut, und was nicht#

Seit WordPress 5.5 gibt es die Funktion wp_get_environment_type(). Sie liest die Konstante oder Umgebungsvariable WP_ENVIRONMENT_TYPE und kennt vier Werte: local, development, staging und production. Ohne Angabe, oder bei einem unbekannten Wert, gilt production.

Der Kern selbst macht aus staging erstaunlich wenig. Bei development und local schaltet er WP_DEBUG ein, wenn es nicht gesetzt ist, und bei local erlaubt er Anwendungspasswörter auch ohne HTTPS. Die Prüfungen auf Seitencache und Objekt-Cache im Website-Zustand laufen nur in production. Für staging gibt es im Kern keine eigene Sonderbehandlung. Der Wert ist ein Signal an Plugins, die damit etwa Zahlungen, Mails oder Synchronisation abschalten können, sofern sie ihn abfragen. Ob deine es tun, steht in ihrer Dokumentation, nicht im Kern. Setzen solltest du ihn trotzdem, weil er nichts kostet und manche Erweiterungen davon abhängen.

Die Kopie vor Google schützen#

Unter „Einstellungen → Lesen“ gibt es den Haken „Suchmaschinen davon abhalten, diese Website zu indexieren“. Er setzt die Option blog_public auf 0, und WordPress gibt dann auf jeder Seite noindex aus. Das ist besser als nichts, aber es reicht nicht: noindex wirkt erst, wenn Google die Seite abruft, und die Kopie ist trotzdem für jeden erreichbar, der die Adresse kennt.

Google empfiehlt für Inhalte, die niemand außer dir sehen soll, den Passwortschutz. Das heißt hier: ein Passwort auf Ebene des Webservers vor die ganze Subdomain, über das Kundenmenü des Hosters oder per .htaccess. Dann sieht weder ein Suchmaschinen-Crawler noch ein neugieriger Besucher eine zweite Ausgabe deiner Seite. Nebenbei verhinderst du so, dass die Kopie als doppelter Inhalt in den Index rutscht. Den Haken in den Einstellungen setzt du zusätzlich, für den Fall, dass der Passwortschutz einmal fehlt.

Mails und Zahlungen auf Staging abschalten#

Eine Kopie mit Shop schickt Bestellbestätigungen, Erinnerungen und Newsletter genauso wie das Original, an echte Kunden. Wer auf Staging eine Bestellung testet oder ein Cron-Ereignis nachholt, kann so echte Menschen anschreiben.

Am sichersten ist es, den Mailversand der Kopie ganz abzuschalten. WordPress hat dafür seit 5.7 den Filter pre_wp_mail: Gibt er etwas anderes als null zurück, verschickt wp_mail() nichts. Als Mu-Plugin, also eine Datei in wp-content/mu-plugins/, die nur auf der Kopie liegt:

<?php
// Nur auf Staging: keine Mails verschicken.
if ( 'staging' === wp_get_environment_type() ) {
	add_filter( 'pre_wp_mail', '__return_false' );
}

Verschickt ein Plugin Mails an wp_mail() vorbei, über die Schnittstelle eines Versanddienstes etwa, greift das nicht; dann gehört dessen Zugang auf der Kopie entfernt. Zahlungsanbieter stellst du auf der Kopie in den Testmodus, und geplante Aufgaben wie Abo-Verlängerungen oder Synchronisationen mit Warenwirtschaft und Newsletter-Dienst prüfst du einzeln.

Der Rückweg auf live#

Hier passieren die teuren Fehler. Zwischen dem Anlegen der Kopie und dem Ende des Tests ist live weitergelaufen: neue Bestellungen, Kommentare, Formulareinträge, neue Benutzer. Wer die Datenbank von Staging auf live zurückspielt, löscht all das.

Der sichere Weg für Updates ist deshalb, sie auf Staging zu prüfen und live einfach zu wiederholen, nach einer frischen Sicherung, in derselben Reihenfolge. Für Änderungen an Theme oder eigenen Plugins überträgst du nur die Dateien. Nur bei einer Seite, auf der live nachweislich nichts passiert ist, keine Bestellungen, keine Kommentare, keine Formulare mit Speicherung, ist das Zurückspielen der ganzen Datenbank vertretbar, dann mit wp search-replace in die umgekehrte Richtung.

Was nicht hilft#

Eine Kopie im Unterverzeichnis ohne Schutz. deine-domain.at/test/ mit derselben Seite noch einmal ist das klassische Duplikat im Index, und oft findet man sie Monate später noch dort.

Nur den Haken „Suchmaschinen abhalten“. Er sagt Google, die Seite nicht aufzunehmen, wenn Google sie abruft. Er hält niemanden fern.

Staging anlegen und vergessen. Eine alte Kopie mit veralteten Plugins ist eine zweite Installation mit denselben Lücken, oft ohne Updates und ohne Überwachung. Nach dem Test löschen oder mitpflegen.

Den Knopf „auf live übertragen“ drücken, ohne zu wissen, was er überträgt. Bei einem Shop mit laufenden Bestellungen ist das die schnellste Art, Kundendaten zu verlieren.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. In der WordPress-Wartung für 49 € im Monat laufen größere Updates mit Sicherung davor und Prüfung danach, bei Bedarf zuerst auf einer Kopie. Ist die Seite nach einem Update schon kaputt, hilft die WordPress-Soforthilfe mit Fehlerdiagnose und Reparatur für 149 €.

Häufige Fragen#

Stand 13.10.2026. WordPress-Quelltext (load.php, default-constants.php, class-wp-site-health.php, user.php, pluggable.php, robots-template.php), WP-CLI-Dokumentation und Google Search Central an diesem Tag gelesen.