Ein fehlgeschlagenes Shop-Update kann deinen Onlineshop für Stunden lahmlegen – und das zu einem denkbar ungünstigen Zeitpunkt. Wer eine Staging-Umgebung nutzt, Updates vor der Live-Schaltung testet und ein klares Rollback-Fenster einplant, verhindert genau das. Dieser Leitfaden zeigt dir, wie du Updates für WooCommerce, Shopware 6 und JTL-Shop 5 sicher durchführst – Schritt für Schritt, ohne Ausfallzeit und ohne böse Überraschungen.
Warum unkontrollierte Shop-Updates gefährlich sind
Ich habe in meiner Arbeit als E-Commerce-Manager schon einige Shop-Betreiber erlebt, die ein Sicherheits-Update „kurz mal eben“ eingespielt haben – mitten am Nachmittag, ohne Backup, ohne Staging-Test. Das Ergebnis: ein weißer Bildschirm, ein nicht mehr funktionierender Checkout oder ein Datenbankfehler, der sich erst nach Stunden beheben ließ. Nicht weil das Update fehlerhaft war, sondern weil jede Vorbereitung fehlte.
Shop-Software ist komplex. WooCommerce läuft auf WordPress und ist abhängig von dutzenden Plugins, die sich gegenseitig beeinflussen können. Shopware 6 setzt auf Symfony und Composer – ein Versionskonflikt im Dependency-Tree kann den gesamten Shop zum Absturz bringen. JTL-Shop 5 hat enge Abhängigkeiten zur JTL-Wawi: Updates, die die Datenbankstruktur verändern, müssen mit der Wawi-Version abgestimmt sein, sonst bricht die Schnittstelle.
Hinzu kommt geschäftlicher Druck: Sicherheitslücken müssen schnell gepatcht werden. Wer keine Routine hat, handelt entweder zu langsam – und riskiert einen Angriff – oder zu überstürzt – und riskiert Ausfall. Ein sauberer Update-Prozess mit Staging und Rollback-Plan löst beide Probleme gleichzeitig.
Was ist eine Staging-Umgebung?
Eine Staging-Umgebung ist eine exakte Kopie deines Live-Shops, die auf einem separaten Server oder einer Subdomain läuft. Dort spielst du Updates ein, testest sie gründlich – und nur wenn alles funktioniert, überträgst du die Änderungen auf den Live-Shop.
Der entscheidende Unterschied zu einer lokalen Testinstallation: Das Staging-System spiegelt die echte Server-Umgebung wider. Datenbankversion, PHP-Version, Apache- oder Nginx-Konfiguration – alles identisch zum Live-System. Fehler, die nur auf dem Produktionsserver auftreten, werden so sichtbar, bevor deine Kunden sie zu spüren bekommen.
Eine gute Staging-Umgebung enthält außerdem eine anonymisierte Kopie der Kundendaten. Du brauchst echte Bestellungen und Produktdaten zum Testen, aber keine echten Namen und E-Mail-Adressen. Das ist Datenschutz-Pflicht (DSGVO) – und verhindert gleichzeitig, dass versehentlich Test-E-Mails an echte Kunden gehen.
Staging für WooCommerce: Drei Wege im Vergleich
Bei WooCommerce hast du grundsätzlich drei Möglichkeiten, eine Staging-Umgebung einzurichten:
Option 1: Managed-Hoster mit eingebautem Staging
Viele Managed-WordPress-Hoster bieten Staging mit einem Klick an. Kinsta, WP Engine, Raidboxes und SiteGround haben diese Funktion standardmäßig integriert. Du klickst auf „Staging erstellen“, der Hoster kopiert deinen Shop auf eine Subdomain – fertig. Nach dem Test überträgst du die Änderungen mit „Push to Live“ zurück auf den Produktivserver.
Das ist die einfachste Variante, hat aber einen Nachteil: Du bist an die Möglichkeiten deines Hosters gebunden. Manche Hoster übertragen beim Push nur WordPress-Dateien, nicht aber Datenbankänderungen. Das ist problematisch bei Updates, die Datenbanktabellen verändern – was bei WooCommerce-Major-Updates regelmäßig der Fall ist.
Option 2: WP Staging als Plugin
Das Plugin WP Staging (kostenlose Basisversion verfügbar, Pro-Version für erweiterte Funktionen) erstellt eine Staging-Kopie direkt aus dem WordPress-Backend heraus. Die kostenlose Version legt das Staging auf dem gleichen Server an, die Pro-Version erlaubt Staging auf einem externen Server und das automatische Zurückspielen von Änderungen auf den Live-Shop.
Für kleine bis mittelgroße WooCommerce-Shops ist WP Staging eine solide Wahl. Bei sehr großen Shops mit umfangreichen Medienbibliotheken kann die Kopier-Phase aber erhebliche Zeit in Anspruch nehmen.
Option 3: Manuelles Staging über Plesk oder cPanel
Wer Zugriff auf Plesk oder cPanel hat, kann den Shop manuell auf eine Subdomain kopieren und dabei präzise steuern, welche Teile kopiert werden. Dateien per SSH oder FTP, Datenbank per Kommandozeile oder phpMyAdmin. Das ist mehr Aufwand, gibt dir aber die volle Kontrolle – besonders wenn du sicherstellst, dass die wp-config.php auf die Staging-Datenbank zeigt und alle WooCommerce-E-Mail-Versand-Funktionen im Staging deaktiviert sind.
Wenn du noch unsicher bist, welcher Hoster die beste Staging-Unterstützung für WooCommerce bietet, haben wir die wichtigsten Anbieter in unserem Onlineshop-Hosting-Vergleich 2026 gegenübergestellt.
Staging für Shopware 6: Der Composer-basierte Ansatz
Shopware 6 ist technisch anspruchsvoller als WooCommerce. Das System basiert auf Symfony und nutzt Composer für das Dependency-Management. Das macht Updates mächtiger – und bei Versionskonflikten potenziell gefährlicher.
Staging-Umgebung für Shopware 6 aufsetzen
Die sauberste Methode ist eine separate Subdomain auf demselben Server (identische PHP-Version, identische Datenbankversion) oder ein gleichartig konfigurierter zweiter Server. Gehe dabei so vor:
Schritt 1: Erstelle eine vollständige Kopie des Shopware-Verzeichnisses und passe die .env-Datei für das Staging an (APP_URL, Datenbankname, Mailer auf einen Test-Dienst umstellen).
Schritt 2: Exportiere die Live-Datenbank und importiere sie in eine frische Staging-Datenbank. Shopware 6 bietet ab Version 6.4 einen eingebauten Befehl zum Anpassen der Shop-Domain: bin/console sales-channel:update:domain staging.deindomain.de. Kundendaten lassen sich über den Anonymisierungs-Task in der Admin-Oberfläche pseudonymisieren.
Schritt 3: Führe das Update auf Staging per Composer aus: composer update shopware/platform --with-dependencies. Prüfe nach dem Update die Admin-Oberfläche, teste mindestens drei vollständige Kaufabwicklungen und überprüfe alle aktiven Plugins auf Kompatibilität.
Ein häufiger Fehler: Händler vergessen, alle Cache-Ebenen nach dem Update zu leeren. Bei Shopware 6 ist das zwingend – bin/console cache:clear – und anschließend bin/console dal:refresh:index, damit der Such- und Filterindex neu aufgebaut wird.
Wer gerade erst mit Shopware 6 arbeitet, findet im Shopware 6 Tutorial für Anfänger 2026 einen guten Einstieg in die Systemarchitektur – die Grundlage, um Updates eigenständig und sicher durchzuführen.
Staging für JTL-Shop 5: Besonderheiten durch die Wawi-Anbindung
JTL-Shop 5 ist in einer Hinsicht besonders komplex: Der Shop ist direkt mit der JTL-Wawi verknüpft, der Warenwirtschaft. Updates, die die Datenbankstruktur des Shops verändern, müssen deshalb mit der Wawi-Version abgestimmt sein. Wenn du JTL-Shop auf eine neue Hauptversion aktualisierst, aber die Wawi noch auf einem älteren Stand läuft, kann die Schnittstelle zwischen beiden Systemen brechen.
Staging-Prozess für JTL-Shop 5
JTL bietet selbst keine eingebaute Staging-Funktion. Folgendes Vorgehen hat sich in der Praxis bewährt:
Schritt 1: Erstelle einen vollständigen Datenbank-Dump: mysqldump -u user -p shopdb > backup_vor_update.sql. Prüfe, ob der Dump vollständig ist (Dateigröße kontrollieren, nicht nur den Befehlsstatus).
Schritt 2: Kopiere das Shop-Verzeichnis auf eine Staging-Subdomain. Passe die Konfigurationsdatei des Shops an (Datenbankzugangsdaten, URL). Deaktiviere in der Staging-Konfiguration alle externen Dienste (Zahlungsanbieter, Newsletter-Schnittstellen, DHL-Anbindung).
Schritt 3: Spiele das Update auf Staging ein und teste anschließend die Verbindung zur Wawi mit einer Test-Wawi-Instanz. JTL stellt für Händler und Agenturen Testlizenzen bereit.
Besonders wichtig bei JTL: Prüfe nach dem Update die Übernahme von Bestellungen in die Wawi und den Rückfluss von Lagerdaten in den Shop. Bei Template-Updates werden eigene Anpassungen – sogenannte Overrides – manchmal überschrieben. Dokumentiere deine individuellen Template-Dateien und sichere sie separat, bevor du ein Update einspielst.
Was JTL-Shop 5 als System auszeichnet und für wen es sich lohnt, erklärt unser ausführlicher JTL-Shop-5-Ratgeber 2026.
Backup-Strategie: Was wann gesichert werden muss
Ein Staging-System ersetzt kein Backup – es ergänzt es. Auch wenn du das Update auf Staging erfolgreich getestet hast, kann auf dem Live-System in den Minuten zwischen Staging-Test und Live-Einspielung etwas passieren. Vor jedem Live-Update gilt deshalb eine dreistufige Sicherung:
Ebene 1 – Datenbank
Ein vollständiger Datenbank-Dump unmittelbar vor dem Update. Nicht gestern, nicht heute Morgen – unmittelbar davor, maximal eine Stunde vorher. Bei WooCommerce kannst du UpdraftPlus nutzen oder direkt per phpMyAdmin oder mysqldump auf der Kommandozeile. Bei Shopware 6 und JTL immer per mysqldump auf der Kommandozeile, nicht ausschließlich über das Admin-Panel.
Ebene 2 – Dateisystem
Eine vollständige Kopie des Shop-Verzeichnisses. Bei WooCommerce besonders wichtig: das wp-content-Verzeichnis mit Plugins, Themes und Uploads. Bei Shopware 6: das custom-Verzeichnis mit eigenen Plugins und Themes. Bei JTL: die gesamte templates-Struktur inklusive aller individuellen Anpassungen.
Ebene 3 – Konfigurationsdateien
wp-config.php, .env (Shopware), .htaccess, JTL-Shopkonfiguration. Diese Dateien werden bei Updates manchmal überschrieben oder zurückgesetzt. Eine separate Kopie an einem sicheren Ort – zum Beispiel in einem Passwortmanager oder einem verschlüsselten Repository – spart im Ernstfall enorm viel Zeit.
Wie lange sollten Backups aufbewahrt werden? Für aktive Onlineshops empfehle ich mindestens 30 Tage tägliche Backups und zusätzlich je ein monatliches Backup der letzten 12 Monate. Gerade wenn ein Update-Problem erst Wochen später auffällt – etwa durch einen stillen Fehler in der Bestellverarbeitung – brauchst du Zugriff auf einen älteren Datenstand.
Das Rollback-Fenster: Planung ist alles
Ein Rollback-Fenster ist der geplante Zeitraum nach einem Live-Update, in dem du aktiv beobachtest, ob alles korrekt läuft – und in dem du bei Problemen noch schnell auf den vorherigen Stand zurückgehen kannst. Dieser Zeitraum wird von den meisten Shop-Betreibern systematisch unterschätzt.
Wie lang sollte das Rollback-Fenster sein?
Das hängt vom Update-Typ ab. Bei einem Minor-Update (etwa WooCommerce 8.3 auf 8.4, Shopware 6.6.1 auf 6.6.2): 2 bis 4 Stunden aktive Beobachtung direkt nach der Einspielung. Prüfe Bestelleingang, Zahlungsabwicklung, E-Mail-Versand und die wichtigsten Produktseiten.
Bei einem Major-Update (WooCommerce 8.x auf 9.x, Shopware 6.5 auf 6.6, JTL-Shop 5.2 auf 5.3): 48 bis 72 Stunden. Major-Updates können Probleme verursachen, die sich erst bei bestimmten Nutzeraktionen zeigen – etwa beim Checkout mit einem speziellen Zahlungsanbieter oder bei der Filtersuche mit bestimmten Produktkombinationen.
Während des Rollback-Fensters gilt eine klare Regel: kein weiteres Update einspielen, kein Plugin hinzufügen oder entfernen. Jede zusätzliche Änderung macht die Ursachenforschung bei einem Problem schwieriger.
Rollback durchführen: So gehst du schnell vor
Im Ernstfall musst du schnell handeln. Der Rollback-Prozess sollte deshalb vorbereitet und dokumentiert sein, bevor du das Update einspielst – nicht erst wenn der Fehler da ist.
Für WooCommerce: Datenbank-Dump vom Backup einspielen (phpMyAdmin oder Kommandozeile), dann Dateisystem aus dem Backup-Archiv wiederherstellen. Bei Managed-Hostern mit Snapshot-Funktion geht das oft per Klick.
Für Shopware 6: Datenbank zurückspielen, anschließend Composer-Abhängigkeiten auf den alten Stand zurücksetzen (per composer.lock aus dem Backup) und alle Cache-Ebenen leeren.
Für JTL-Shop 5: Datenbank zurückspielen, Shop-Verzeichnis aus dem Backup wiederherstellen, Wawi-Anbindung prüfen. Wenn die Wawi bereits an die neue Datenbankstruktur angepasst wurde, ist ein Rollback erheblich aufwendiger – das ist ein weiterer Grund, immer zuerst auf Staging zu testen.
Der vollständige Update-Prozess: Schritt für Schritt
Hier ist der Ablauf, den ich für alle drei Shopsysteme empfehle – angepasst an die unterschiedlichen technischen Gegebenheiten:
Phase 1: Vorbereitung (1 bis 2 Tage vor dem Update)
- Changelog des Updates lesen – besonders auf Breaking Changes, veränderte Datenbankstrukturen und PHP-Versionsanforderungen achten
- Plugin-Kompatibilität prüfen: Welche Plugins sind vom Hersteller oder den Plugin-Entwicklern offiziell für die neue Version freigegeben?
- Staging-System auf den aktuellen Live-Stand bringen
- Update auf Staging einspielen und vollständig testen
- Zeitfenster für das Live-Update festlegen (Dienstag oder Mittwoch, frühmorgens)
Phase 2: Live-Update (im geplanten Zeitfenster)
- Datenbank-Backup erstellen – unmittelbar vor dem Update
- Dateisystem-Backup erstellen
- Wartungsmodus aktivieren: bei WooCommerce per Plugin oder Hosting-Panel; bei Shopware 6 per
bin/console sales-channel:maintenance:enable --all; bei JTL unter Einstellungen → Wartungsmodus - Update einspielen
- Cache leeren, Datenbankmigration abwarten
- Wartungsmodus deaktivieren
Phase 3: Rollback-Fenster – aktiv überwachen
- Testbestellung durchführen – echter Bestellfluss, nicht nur Vorschau
- Zahlungseingang im Dashboard des Zahlungsanbieters prüfen (PayPal, Stripe, Klarna)
- Empfang der Bestellbestätigung per E-Mail verifizieren
- Server-Fehlerlog prüfen:
tail -n 200 /var/log/php_errors.log - Google Search Console auf Crawl-Fehler überwachen (24 Stunden nach dem Update)
Häufige Fehler beim Shop-Update – und wie du sie vermeidest
Fehler 1: Update direkt auf den Live-Shop ohne Staging. Der Klassiker. Auch wenn es bisher gut gegangen ist – irgendwann geht es schief. Besonders bei Major-Updates ist das Risiko erheblich.
Fehler 2: Backup vorhanden, aber nie getestet. Ein Backup, das nicht wiederhergestellt werden kann, hilft im Ernstfall nicht. Teste den Wiederherstellungsprozess mindestens einmal pro Quartal auf einer Testumgebung.
Fehler 3: Alle Plugins gleichzeitig updaten. Wenn nach einem Batch-Update etwas nicht stimmt, weißt du nicht welches Plugin die Ursache ist. Besser: Plugins in kleinen Gruppen updaten und nach jeder Gruppe testen.
Fehler 4: Update zur Stoßzeit. Freitag nachmittag ist die denkbar schlechteste Zeit für ein Shop-Update. Wähle ein Zeitfenster mit geringem Traffic und guter Erreichbarkeit von dir oder deinem technischen Ansprechpartner.
Fehler 5: PHP-Version ignorieren. WooCommerce 9.x setzt mindestens PHP 8.1 voraus, Shopware 6.6 benötigt PHP 8.2. Prüfe vor jedem Update, welche PHP-Version auf dem Server läuft – und ob sie der Mindestanforderung des Updates entspricht.
Beim Thema Shop-Sicherheit spielt regelmäßiges Patching übrigens eine zentrale Rolle: Ungepatchte Lücken sind einer der häufigsten Einfallswege für Angreifer. Was zu tun ist, wenn es trotzdem passiert, erklärt unser Artikel Onlineshop gehackt: Webshells erkennen und bereinigen 2026.
Update-Zeitplan: Wann ist der beste Moment?
Für Onlineshops mit deutschen Kunden gilt als Faustregel: Dienstag oder Mittwoch, frühmorgens zwischen 04:00 und 07:00 Uhr. Das ist der Zeitraum mit dem geringsten Traffic. Das Rollback-Fenster liegt dann vollständig im normalen Arbeitstag, sodass du bei Problemen schnell reagieren kannst.
Updates solltest du in folgenden Situationen grundsätzlich vermeiden:
- Freitagabend oder am Wochenende
- Rund um Aktionszeiträume (Black Friday, Cyber Monday, Weihnachten)
- Wenn du selbst nicht kurzfristig erreichbar bist
- Unmittelbar nach dem Start einer neuen Kampagne oder dem Launch eines neuen Produkts
Plane Updates proaktiv in deinen Kalender ein – als feste Termine, nicht als „machen wir irgendwann“. Vierteljährliche Update-Fenster für Minor-Updates, halbjährliche für Major-Updates sind ein bewährter Rhythmus für mittelgroße Shops. Sicherheits-Updates, die kritische Lücken schließen, spielst du schnellstmöglich ein – aber immer nach Staging-Test und mit Rollback-Plan.
Eine Staging-Umgebung ist eine exakte Kopie deines Live-Shops auf einem separaten Server oder einer Subdomain. Dort spielst du Updates ein und testest sie gründlich – erst wenn alles funktioniert, wird die Änderung auf den Live-Shop übertragen. Das verhindert Ausfälle durch fehlgeschlagene Updates.
Bei Minor-Updates reichen 2 bis 4 Stunden aktive Beobachtung nach dem Update. Bei Major-Updates solltest du 48 bis 72 Stunden einplanen, da sich manche Fehler erst bei bestimmten Nutzeraktionen zeigen – etwa beim Checkout mit einem spezifischen Zahlungsanbieter.
Sicherheits-Updates immer zeitnah einspielen – idealerweise innerhalb von 48 bis 72 Stunden, aber erst nach erfolgreichem Staging-Test. Minor-Updates kannst du vierteljährlich bündeln. Major-Updates empfehle ich halbjährlich, wenn die neue Version mindestens 4 bis 6 Wochen lang stabil war.
Ein Backup ist Pflicht, ersetzt Staging aber nicht vollständig. Mit einem Backup kannst du nach einem fehlgeschlagenen Update zurückgehen – das kostet aber Zeit und bedeutet Ausfallzeit für deinen Shop. Staging verhindert den Ausfall komplett, weil du das Update erst live schaltest, wenn du weißt, dass es funktioniert.
WP Staging ist die am weitesten verbreitete Lösung für WooCommerce. Die kostenlose Version erstellt eine Kopie auf demselben Server, die Pro-Version erlaubt externes Staging und automatisches Zurückspielen von Änderungen. Alternativ bieten viele Managed-Hoster wie Kinsta, Raidboxes oder SiteGround eigene Ein-Klick-Staging-Funktionen an.
Fazit: Kein Update ohne Vorbereitung
Shop-Updates sind keine Routine-Tätigkeit, die man nebenbei erledigt. Sie sind ein kleines IT-Projekt – mit Vorbereitung, Testsystem und einem Plan für den Ernstfall. Wer diese drei Säulen hat – Staging, Backup und definiertes Rollback-Fenster – kann Updates schnell und sicher einspielen, ohne den Betrieb zu riskieren.
Der Aufwand für eine ordentliche Staging-Umgebung fällt einmalig an. Danach läuft der Prozess routiniert durch. Und du weißt: Wenn etwas schiefgeht, hast du einen Plan – und kannst innerhalb von Minuten zurückrudern, statt stundenlang im Fehlerlog zu suchen.
