WooCommerce-Staging: Shop auf einer Kopie testen, ohne Bestellungen zu verlieren

Bei einem normalen WordPress-Auftritt ist eine Staging-Kopie schnell erklärt: Website kopieren, dort testen, Änderungen übernehmen. Bei einem WooCommerce-Shop kommen zwei Probleme dazu. Während Sie auf der Kopie testen, gehen im Live-Shop weiter Bestellungen ein, und die Kopie enthält echte Kundendaten, Zahlungszugänge und Webhooks. Wer die Datenbank der Kopie später zurückspielt, löscht alle Bestellungen seit dem Kopierzeitpunkt. Wer die Kopie nicht abschottet, verschickt womöglich Bestellmails an echte Kunden oder löst Zahlungen aus. Diese Anleitung zeigt, wie Sie eine Staging-Kopie Ihres Shops sicher einrichten und Änderungen übertragen, ohne eine einzige Bestellung zu verlieren.

Voraussetzungen

• WordPress ab Version 6.x mit WooCommerce, getestet mit WordPress 7.1.2 und WooCommerce 11.1.2 unter PHP 8.4.
• Zugriff auf die Dateien per SSH oder SFTP und auf die Datenbank, idealerweise mit WP-CLI auf beiden Systemen.
• Eine Subdomain oder ein Verzeichnis für die Kopie mit eigener, leerer Datenbank. Viele Hoster bieten dafür eine Staging-Funktion an.
• Die Rolle Administrator im Shop.
• Ein aktuelles Backup von Dateien und Datenbank des Live-Shops, frisch erstellt vor dem Kopieren.
• Eine Liste der aktiven Zahlungsanbieter, Webhooks und Erweiterungen mit eigenen Zugangsdaten, etwa für Versanddienstleister oder Buchhaltung.

Schritt 1: Die Regel verstehen, die Bestellungen schützt

Ein Datenbankimport ersetzt den gesamten Inhalt der Zieldatenbank. Das ist beim Anlegen der Kopie gewollt, beim Zurückspielen aber fatal. Im Labor haben wir das nachgestellt: Wir haben die Datenbank mit einer Bestellung exportiert, danach eine zweite Bestellung angelegt und den Export wieder importiert. Anschließend zeigte wp wc shop_order list nur noch die erste Bestellung. Die zweite war ohne Rückfrage verschwunden, mitsamt Kundendaten und Zahlungsstatus.

WooCommerce verteilt Bestellungen auf mehrere Tabellen, dazu kommen Kundenkonten, Lagerbestände, Gutscheine und Statistiktabellen wie wc_order_stats. Ein Teilimport einzelner Tabellen ist deshalb kaum zuverlässig. Daraus folgt die wichtigste Regel dieser Anleitung:

Was	Richtung	Weg
Datenbank	Nur Live zu Staging	Export, Import, wp search-replace
Plugins, Themes, eigener Code	Staging zu Live	Update auf Live wiederholen oder Dateien übertragen
Einstellungen	Staging zu Live	Auf Live nachstellen, anhand Ihrer Notizen
Bestellungen, Kunden, Bestände	Bleiben immer auf Live	Nie überschreiben

Verifizieren: Sie haben festgelegt, welche Änderungen Sie testen wollen, und wissen für jede, wie sie ohne Datenbankimport auf den Live-Shop kommt.

Schritt 2: Die Kopie erstellen und als Staging kennzeichnen

Wie Sie Dateien und Datenbank kopieren und die Adressen umschreiben, beschreibt die Anleitung Staging-Umgebung mit WP-CLI einrichten ausführlich. Für den Shop gilt dasselbe Vorgehen, mit einer Ergänzung: Führen Sie wp search-replace zuerst mit --dry-run aus. Im Labor meldete der Probelauf 17 Ersetzungen, bevor irgendetwas geändert wurde.

wp search-replace 'https://www.example.de' 'https://staging.example.de' --dry-run --report-changed-only
wp search-replace 'https://www.example.de' 'https://staging.example.de'

Danach setzen Sie auf der Kopie den Umgebungstyp. Laut WordPress-Referenz kennt wp_get_environment_type() die Werte local, development, staging und production, ohne Angabe gilt production. Hoster mit Staging-Funktion sollen den Wert selbst auf staging setzen, prüfen Sie das trotzdem:

wp config set WP_ENVIRONMENT_TYPE staging
wp eval 'echo wp_get_environment_type(), "\n";'

Einige Erweiterungen reagieren auf eine geänderte Adresse. WooCommerce Subscriptions etwa merkt sich laut eigener Dokumentation die Adresse, unter der es zuerst aktiviert wurde. Auf einer Kopie mit anderer Adresse schaltet es in einen Staging-Modus und stellt automatische Zahlungen und Abo-E-Mails ab. Verlassen Sie sich nicht darauf, dass jede Erweiterung so arbeitet.

Verifizieren: Die Kopie ist unter der Staging-Adresse erreichbar, der Befehl gibt staging aus, und wp option get home zeigt die Staging-Adresse.

Schritt 3: E-Mails, Webhooks und Zahlungen abschalten

Die Kopie enthält echte Kundenadressen. Löst ein Test eine Statusänderung aus, verschickt WooCommerce sonst die passende E-Mail an den echten Kunden. Ein kleines Must-Use-Plugin verhindert das zuverlässig, weil es nicht versehentlich deaktiviert werden kann. Legen Sie auf der Kopie die Datei wp-content/mu-plugins/staging-schutz.php an:

<?php
/**
 * Plugin Name: Staging-Schutz
 * Description: Verhindert auf der Staging-Kopie den E-Mail-Versand.
 */

defined( 'ABSPATH' ) || exit;

if ( 'production' !== wp_get_environment_type() ) {
	add_filter( 'pre_wp_mail', '__return_false' );
}

Der Filter pre_wp_mail beendet wp_mail(), bevor eine Nachricht erzeugt wird. Im Labor lieferte wp_mail() mit diesem Plugin sofort false, ohne einen Versuch, einen Mailserver zu erreichen. Mit dem Umgebungstyp production versuchte WordPress dagegen zu senden. Weil die Abfrage am Umgebungstyp hängt, schadet die Datei nicht, falls sie einmal auf den Live-Shop gelangt. Nutzen Sie ein SMTP-Plugin, sehen Sie zusätzlich in dessen Einstellungen nach, wie in der Anleitung zum E-Mail-Versand per SMTP beschrieben.

Webhooks melden neue Bestellungen an Warenwirtschaft, Versand oder Buchhaltung. Auf der Kopie würden Testbestellungen dort als echte Aufträge ankommen. Pausieren Sie alle Webhooks unter WooCommerce > Einstellungen > Erweitert > Webhooks oder per WP-CLI:

wp wc webhook list --user=1 --fields=id,name,status
wp wc webhook update 1 --user=1 --status=paused

Bei den Zahlungsanbietern unter WooCommerce > Einstellungen > Zahlungen gehen Sie jeden aktiven Anbieter durch. Stellen Sie auf den Testmodus des Anbieters um oder entfernen Sie die Live-Zugangsdaten, sodass keine echte Zahlung möglich ist. Die Bezeichnungen unterscheiden sich je Anbieter, maßgeblich ist dessen Dokumentation. Dasselbe gilt für Erweiterungen mit eigenen Zugängen, etwa für Versandetiketten.

Verifizieren: wp eval 'var_dump( wp_mail( "test@example.invalid", "Test", "Test" ) );' gibt bool(false) aus. Die Webhook-Liste zeigt überall paused. Kein Zahlungsanbieter arbeitet mit Live-Zugangsdaten.

Schritt 4: Geplante Aktionen und Sichtbarkeit prüfen

WooCommerce arbeitet viele Aufgaben im Hintergrund über den Action Scheduler ab, etwa Folgezahlungen von Abos, Erinnerungen oder Synchronisierungen mit externen Diensten. In der Kopie liegen dieselben ausstehenden Aufgaben wie im Live-Shop, und sie laufen dort ebenfalls los. Im Labor standen direkt nach der Installation fünf Aufgaben auf „ausstehend“. Sehen Sie sich die Liste unter WooCommerce > Status > Geplante Aktionen an oder per WP-CLI:

wp action-scheduler action list --status=pending --fields=hook,schedule

Ordnen Sie jeden Hook einer Erweiterung zu. Aufgaben, die nach außen wirken, stoppen Sie über die Einstellungen der jeweiligen Erweiterung oder brechen sie auf der Kopie ab. Interne Aufgaben von WooCommerce, etwa zum Aufräumen, dürfen weiterlaufen.

Besucher und Suchmaschinen haben auf der Kopie nichts verloren. Unter WooCommerce > Einstellungen > Sichtbarkeit der Website wählen Sie „Demnächst verfügbar“. Im Labor sahen nicht angemeldete Besucher danach eine Platzhalterseite, der angemeldete Administrator weiterhin den Shop. Zusätzlich aktivieren Sie unter Einstellungen > Lesen die Option „Suchmaschinen davon abraten, diese Website zu indexieren“. Beides ist kein Zugriffsschutz. Die Kopie enthält personenbezogene Daten Ihrer Kunden, deshalb gehört ein Passwortschutz auf Webserver-Ebene davor, wie in der Staging-Anleitung beschrieben.

Verifizieren: Ein Aufruf der Staging-Adresse in einem privaten Browserfenster verlangt ein Passwort. Nach Eingabe des Passworts erscheint ohne WordPress-Anmeldung die Platzhalterseite. Keine ausstehende Aktion wirkt nach außen.

Schritt 5: Auf der Kopie testen

Jetzt spielen Sie auf der Kopie ein, was Sie prüfen wollen, zum Beispiel ein größeres WooCommerce-Update, einen Theme-Wechsel oder eine neue Zahlungsart. Führen Sie Protokoll über jede Änderung: welches Plugin in welcher Version, welche Einstellung mit welchem Wert. Diese Notizen brauchen Sie in Schritt 6.

Testen Sie den kompletten Kaufablauf mit einem eigenen Testkonto und einer Testadresse, nicht mit echten Kundenkonten. Prüfen Sie Warenkorb, Kasse, Bestellbestätigung im Adminbereich, Lagerbestand und die Darstellung auf dem Smartphone. Worauf Sie bei Updates von WooCommerce besonders achten sollten, zum Beispiel auf überschriebene Vorlagen und Datenbank-Updates, beschreibt die Anleitung WooCommerce-Updates sicher einspielen.

Ist die Kopie älter als einige Tage, erstellen Sie sie vor einem wichtigen Test neu. Nur so testen Sie mit dem aktuellen Stand von Plugins, Einstellungen und Datenmenge.

Verifizieren: Eine Testbestellung durchläuft den Ablauf bis zum gewünschten Status. Im Postfach des Testkontos kommt keine E-Mail an, weil der Versand abgeschaltet ist, und in angebundenen Systemen erscheint kein neuer Auftrag.

Schritt 6: Änderungen auf den Live-Shop übertragen

Erstellen Sie unmittelbar vorher ein frisches Backup des Live-Shops. Die Anleitung Datenbank mit WP-CLI sichern und wiederherstellen zeigt die Befehle. Wählen Sie eine Zeit mit wenig Bestellungen. Dann wiederholen Sie die getesteten Schritte auf dem Live-Shop anhand Ihres Protokolls: dieselben Plugin-Versionen installieren, dieselben Einstellungen setzen, eigene Dateien wie Child-Theme oder Plugins per SFTP oder Versionsverwaltung übertragen.

Das klingt umständlicher als ein Knopfdruck, ist aber der einzige Weg, bei dem keine Bestellung verloren geht. Staging-Funktionen mancher Hoster bieten ein „Push zu Live“ an. Prüfen Sie vorher genau, ob dabei auch die Datenbank übertragen wird. Falls ja, schließen Sie die Datenbank aus oder verzichten Sie auf die Funktion.

Auf dem Live-Shop entfällt der Staging-Schutz aus Schritt 3 automatisch, weil dort kein Umgebungstyp staging gesetzt ist. Übertragen Sie trotzdem weder wp-config.php noch die Datei staging-schutz.php, damit keine Staging-Einstellung versehentlich live landet.

Verifizieren: Die Bestellungsliste im Live-Shop enthält alle Bestellungen bis zur aktuellen Minute. Plugins und Versionen stimmen mit Ihrem Protokoll überein, und eine echte Testbestellung mit anschließender Stornierung läuft fehlerfrei durch.

Ein Staging-Test vor jedem größeren Update ist Routine, die im Tagesgeschäft schnell hinten herunterfällt. Wer diese Aufgaben nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de übernimmt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung und wöchentliche Backups auf externen Speicher mit vier Wochen Aufbewahrung.

Typische Fehler

Fehlerbild	Ursache	Lösung
Bestellungen der letzten Tage fehlen im Live-Shop	Datenbank der Kopie wurde auf Live importiert	Backup von direkt vor dem Import zurückspielen, fehlende Bestellungen aus dem Backup übernehmen
Kunden erhalten Bestellmails aus der Kopie	E-Mail-Versand auf der Kopie aktiv	Must-Use-Plugin aus Schritt 3, Umgebungstyp prüfen
Testbestellung erscheint in Warenwirtschaft oder Versandtool	Webhook oder Erweiterung mit Live-Zugang aktiv	Webhooks pausieren, Zugangsdaten der Erweiterungen entfernen
Staging-Schutz greift nicht	WP_ENVIRONMENT_TYPE fehlt, WordPress nimmt production an	wp config set WP_ENVIRONMENT_TYPE staging
Kopie erscheint in Suchergebnissen	Kein Passwortschutz, nur Suchmaschinen-Hinweis gesetzt	HTTP-Authentifizierung auf dem Webserver einrichten
Links auf der Kopie führen zum Live-Shop	Adressen nicht vollständig ersetzt	wp search-replace erneut mit --dry-run prüfen

Häufige Fragen

Kann ich nicht einfach nur die geänderten Tabellen übertragen?

Theoretisch ja, praktisch ist das riskant. Einstellungen, Bestellungen und Plugin-Daten liegen teils in denselben Tabellen, etwa in wp_options und wp_postmeta. Wer eine davon überträgt, überschreibt fast immer auch Live-Daten. Nachstellen anhand eines Protokolls ist verlässlicher.

Darf die Kopie echte Kundendaten enthalten?

Eine Kopie ist eine weitere Verarbeitung personenbezogener Daten. Halten Sie sie so kurz wie möglich vor, schützen Sie sie per Passwort und löschen Sie sie nach dem Test. Wer dauerhaft testet, sollte mit anonymisierten Daten arbeiten.

Reicht der Wartungsmodus statt einer Kopie?

Nein. Im Wartungsmodus testen Sie direkt am Live-Shop, und Kunden können in dieser Zeit nicht bestellen. Geht etwas schief, betrifft es sofort die echten Daten.

Wie oft sollte ich die Kopie neu erstellen?

Vor jedem größeren Test. Eine Kopie mit dem Stand von vor Wochen enthält andere Plugin-Versionen und weniger Daten, dann sagt der Test wenig über den Live-Shop aus.

Testumfang

Wir haben alle Schritte auf einer Testinstallation mit WordPress 7.1.2 und WooCommerce samt Testbestellungen durchgespielt. Auffällig war, dass der Import eines älteren Datenbankstands die neuere Bestellung tatsächlich löschte und damit die Grundregel dieser Anleitung bestätigte.

Echte Zahlungsanbieter und WooCommerce Subscriptions konnten wir im Labor nicht prüfen. Wenn Sie diese einsetzen, testen Sie deren Verhalten besonders sorgfältig auf einer Kopie.

Fazit

Eine Staging-Kopie macht Shop-Updates planbar, solange eine Regel gilt: Die Datenbank fließt nur vom Live-Shop zur Kopie. Mit gekennzeichneter Umgebung, abgeschaltetem Mailversand, pausierten Webhooks und Testmodus bei den Zahlungen bleibt die Kopie folgenlos für Ihre Kunden. Getestete Änderungen stellen Sie auf dem Live-Shop nach, statt Daten zurückzukopieren. Wenn Sie Updates und Backups Ihres Shops lieber in feste Hände geben, finden Sie bei der WordPress-Wartung von Marcel Schönfelder persönliche Betreuung aus Dresden.

Weiterführende Anleitungen und Quellen

• WordPress-Staging-Umgebung mit WP-CLI einrichten
• WooCommerce-Updates sicher einspielen
• WordPress-Datenbank mit WP-CLI sichern und wiederherstellen
• WordPress Developer Reference: wp_get_environment_type()
• WordPress Developer Reference: pre_wp_mail
• WooCommerce: How Subscriptions Handles Staging Sites
• WooCommerce: How to Test for Conflicts