Updates sind der Moment, in dem ein Shop besonders verletzlich ist. Nicht weil das neue Release schlecht wäre, sondern weil zwischen dem alten und dem neuen Zustand eine Lücke klafft: halb kopierte Dateien, laufende Datenbankmigrationen, ein noch kalter Cache. Wer in dieser Lücke Kunden auf den Shop lässt, riskiert Fehlerseiten mitten im Kaufprozess. Genau hier endet die klassische Beratung: Tests und eine Staging-Umgebung mit Produktions-Parität fangen Fehler vor dem Go-Live ab -- aber sie sagen nichts darüber, wie das Release sauber auf die Produktion kommt. Dieser Artikel behandelt genau diese Ausführungsseite: das traffic-arme Wartungsfenster, den korrekten HTTP-503-Wartungsmodus, das Cache-Warmup und einen belastbaren Rollback-Plan aus Git-Tag und Datenbank-Dump.
Das Wichtigste in Kürze
- Ausfallkosten liegen bei rund 5.600 US-Dollar (Gartner) pro Minute, und bei über 90 Prozent (ITIC) der mittelgroßen und großen Unternehmen kostet eine Ausfallstunde mehr als 300.000 US-Dollar. Auch ein Shop mit kaltem Cache zählt als Ausfall.
- Das Wartungsfenster gehört in das nachweisbare Umsatztal der eigenen Analytics -- bei vielen deutschsprachigen Shops zwischen 3 und 5 Uhr (Projekterfahrung). Während des Fensters gilt ein Change-Freeze: nur das geplante Release, keine spontanen Nebenänderungen.
- Während der Wartung antwortet jede URL mit 503 Service Unavailable plus Retry-After, nicht mit 200 OK: Eine Wartungsseite mit Status 200 kann Google als Soft-404 einstufen, und über ein bis zwei Tage hinaus droht Deindexierung (Google Search Central).
- Shopware bringt einen Wartungsmodus je Sales-Channel mit IP-Allowlist und den Deployment-Helper für Migrationen, Theme-Kompilierung und Assets mit. WordPress sendet über die Datei .maintenance automatisch 503 mit Retry-After: 600 (WordPress Developer Documentation).
- Das Fenster endet erst, wenn der Shop wieder schnell antwortet: Anwendungs-Cache aufbauen, die wichtigsten Sitemap-URLs einmal abrufen und den 503-Schalter erst entfernen, wenn diese Aufrufe mit 200 und gewohnten Antwortzeiten zurückkommen.
- Der Rückweg besteht aus einem Git-Tag auf den letzten stabilen Stand und einem frischen Datenbank-Dump unmittelbar vor der ersten Migration. Der Code kehrt per Symlink in Sekunden zurück, eine unwiderrufliche Migration ohne Dump nicht.
Warum Updates Umsatz kosten, wenn niemand hinschaut
Ein Deployment ist selten ein einzelner Augenblick. Es ist eine Abfolge: Abhängigkeiten werden nachgeladen, Assets kompiliert, Datenbankmigrationen ausgeführt, Caches geleert und neu aufgebaut. Während dieser Sekunden bis Minuten kann der Shop in einem inkonsistenten Zustand sein -- ein Template referenziert eine Klasse, die es noch nicht gibt, oder eine Migration hat eine Spalte umbenannt, auf die der alte Code noch zugreift. Trifft ein Kunde in diesem Fenster auf die Kategorieseite oder den Checkout, sieht er im besten Fall eine Wartungsmeldung, im schlechtesten einen Serverfehler. Beides unterbricht den Kauf.
Die Kosten sind messbar. Gartner beziffert die durchschnittlichen Ausfallkosten seit Jahren mit rund 5.600 US-Dollar (Gartner) pro Minute, was etwa 336.000 US-Dollar je Stunde entspricht. Aktuellere Zahlen der ITIC-Erhebung 2024 zeigen, dass für über 90 Prozent (ITIC) der mittelgroßen und großen Unternehmen eine einzige Stunde Ausfall mehr als 300.000 US-Dollar kostet. Für reine Online-Shops ist die Rechnung noch direkter: Während der Störung fällt der digitale Umsatz weitgehend weg. Wer die konkreten Ausfallkosten des eigenen Shops kalkulieren will, rechnet Bestellwert mal Bestellungen pro Stunde -- die Summe macht schnell klar, warum ein sauberes Wartungsfenster keine Kür ist.
Hinzu kommt ein psychologischer Effekt. Der Kaufprozess im E-Commerce ist ohnehin fragil: Das Baymard Institute ermittelt seit Jahren eine durchschnittliche Warenkorb-Abbruchrate von rund 70 Prozent (Baymard Institute). Jede zusätzliche Reibung -- eine Fehlerseite, ein Timeout, ein leerer Warenkorb nach dem Reload -- verschiebt Kaufinteressenten in genau diese Abbruchstatistik. Ein Update, das den Shop fünf Minuten lang wackeln lässt, kostet also nicht nur die fünf Minuten, sondern auch die Kunden, die in diesem Moment kurz vor der Kaufentscheidung standen.
Der stille Ausfall
Das Wartungsfenster: den richtigen Zeitpunkt wählen
Ein Wartungsfenster ist ein bewusst geplanter, kommunizierter Zeitraum, in dem Änderungen an der Produktion vorgenommen werden. Der Sinn ist einfach: Wenn sich ein kurzer Umschaltmoment nicht vollständig vermeiden lässt, dann soll er dann stattfinden, wenn ihn möglichst wenige Kunden bemerken. Die Kunst besteht darin, den Zeitpunkt datenbasiert zu wählen statt nach Bauchgefühl. Die eigene Analytics zeigt die Traffic- und Umsatzkurve über den Tag -- das Fenster gehört in das nachweisbare Tal, nicht in die selbst vermutete ruhige Zeit.
Für die meisten deutschsprachigen Shops liegt das Umsatztal in den frühen Morgenstunden, typischerweise zwischen etwa 3 und 5 Uhr (Projekterfahrung). Wichtige Ausnahmen bestätigen die Regel: Shops mit internationaler Kundschaft haben kein einheitliches Tal, und B2B-Shops mit Bestellungen zum Monatsanfang brauchen andere Fenster als ein B2C-Shop im Weihnachtsgeschäft. Deshalb ersetzt keine Faustregel den Blick in die eigenen Zahlen. Genauso wichtig wie der Zeitpunkt ist die Freeze-Regel: Während eines Fensters wird nur das geplante Release ausgerollt, keine spontanen Nebenänderungen -- so bleibt im Fehlerfall eindeutig, was die Ursache war.
- Traffic- und Umsatzkurve auswerten und das nachweisbare Tagestal als Fenster festlegen.
- Fensterdauer realistisch schätzen -- inklusive Migration, Cache-Warmup und Puffer für den Rollback.
- Änderung ankündigen: intern an Betrieb und Support, bei längeren Fenstern auch an Kunden.
- Change-Freeze für alle anderen Deployments während des Fensters aktivieren.
- Rollback-Kriterien vorab definieren, damit im Ernstfall keine Zeit mit Diskussionen verloren geht.
Kurz statt selten
HTTP 503 richtig einsetzen -- der SEO-sichere Wartungsmodus
Wenn während des Fensters kurz keine echten Inhalte ausgeliefert werden können, entscheidet der HTTP-Statuscode darüber, ob das Fenster spurlos bleibt oder Ranking kostet. Der korrekte Code ist 503 Service Unavailable: Er sagt Browsern und Suchmaschinen, dass die Nichterreichbarkeit vorübergehend ist. Google beschreibt in der Search Central genau dieses Verhalten -- ein 503 signalisiert eine temporäre Störung, und Googlebot kommt später wieder, ohne die Seite abzuwerten (Google Search Central). Der häufigste Fehler ist stattdessen, eine Wartungsseite mit Status 200 OK auszuliefern: Google wertet eine solche Seite als regulären Inhalt und kann sie als Soft-404 einstufen, was das Ranking gefährdet (Google Search Central).
| Antwort während der Wartung | Was Google versteht | Folge fürs Ranking |
|---|---|---|
| 503 Service Unavailable | Temporär nicht erreichbar, später wiederkommen | Ranking bleibt erhalten |
| 200 OK mit Wartungstext | Das ist jetzt der Seiteninhalt | Soft-404-Risiko, Ranking fällt |
| 302 Redirect auf Wartungsseite | Inhalt ist umgezogen | Verwirrende Signale, Indexierung leidet |
| Timeout ohne Statuscode | Server unzuverlässig | Crawl-Rate sinkt, Fehler häufen sich |
Zum 503 gehört der optionale Retry-After-Header, der die voraussichtliche Dauer nennt -- entweder als Sekundenwert oder als konkretes Datum. Er ist ein Hinweis für Googlebot, wann sich ein erneuter Besuch lohnt (Google Search Central). Entscheidend ist die Dauer: Beobachtet Googlebot 503-, 500- oder 429-Antworten über mehrere Tage auf denselben URLs, können diese aus dem Index entfernt werden (Google Search Central). Google empfiehlt deshalb ausdrücklich, den 503-Modus nur für wenige Stunden bis maximal ein bis zwei Tage einzusetzen (Google Search Central). Für ein nachts geplantes Wartungsfenster von Minuten ist das unkritisch -- der 503 ist genau das richtige Werkzeug, solange er kurz bleibt.
# nginx: SEO-sicheres Wartungsfenster über einen Schalter
# Fenster an: touch /var/www/maintenance.on
# Fenster aus: rm /var/www/maintenance.on
location / {
if (-f /var/www/maintenance.on) {
return 503;
}
try_files $uri $uri/ /index.php$is_args$args;
}
# Eigene Wartungsseite mit korrektem Status ausliefern
error_page 503 @maintenance;
location @maintenance {
root /var/www/maintenance;
rewrite ^ /503.html break;
add_header Retry-After 600 always; # in ~10 Minuten zurück
add_header Cache-Control "no-store" always;
}Die Wartungsseite selbst muss 503 senden
Plattform-Wartungsmodus: Shopware und WordPress
Beide großen Plattformen bringen einen Wartungsmodus mit -- man muss ihn nur richtig nutzen. Shopware kennt einen Wartungsmodus pro Sales-Channel, den man im Admin unter dem jeweiligen Verkaufskanal aktiviert. Damit man selbst während der Wartung testen kann, gibt es eine IP-Allowlist: Nur die dort hinterlegten Adressen sehen den Shop, alle anderen erhalten die Wartungsantwort (Shopware Documentation). Für das eigentliche Ausrollen empfiehlt Shopware den Deployment-Helper, der Migrationen, Theme-Kompilierung, Asset-Installation und einmalige Aufgaben in einer definierten Reihenfolge abarbeitet -- die Grundlage für ein reproduzierbares Fenster (Shopware Documentation). Wer die Details der Shopware-Update-Strategie vertiefen will, findet dort den Ablauf von Composer bis Plugin-Kompatibilität.
WordPress schaltet automatisch in den Wartungsmodus, sobald ein Update läuft: Der Core legt eine Datei namens .maintenance im Wurzelverzeichnis an und liefert währenddessen eine Wartungsantwort. Diese Antwort ist bereits sauber gebaut -- die Funktion wp_maintenance() sendet Status 503 zusammen mit einem Header Retry-After: 600 (WordPress Developer Documentation). Der Standardmodus gilt allerdings nur für ein Zeitfenster von zehn Minuten und zeigt eine karge Standardmeldung. Für ein geplantes Fenster ersetzt man sie durch eine eigene maintenance.php im Verzeichnis wp-content -- ein sogenanntes Drop-in, das WordPress automatisch statt der Standardseite ausliefert (WordPress Developer Documentation).
Shopware-Wartungsmodus
Pro Sales-Channel aktivierbar, mit IP-Allowlist für den eigenen Testzugriff während des Fensters.
Shopware Deployment-Helper
Migrationen, Theme-Kompilierung und Asset-Installation in fester Reihenfolge -- reproduzierbar statt manuell.
WordPress .maintenance
Automatischer 503-Modus während des Updates; per maintenance.php-Drop-in durch eine eigene Seite ersetzbar.
Webserver-503
Ein Schalter auf Webserver-Ebene fängt jede URL ab -- auch dann, wenn die Anwendung selbst gerade nicht antwortet.
IP-Allowlist
Das Team prüft den frisch deployten Shop live, während Kunden weiterhin die 503-Wartungsseite sehen.
Konsistenter Statuscode
Jede angefragte URL antwortet mit 503 und Retry-After -- die Voraussetzung für ein SEO-neutrales Fenster.
<?php
// Eigenes WordPress-Wartungs-Drop-in mit SEO-sicherem 503
$protocol = $_SERVER['SERVER_PROTOCOL'] ?? 'HTTP/1.1';
header("$protocol 503 Service Unavailable", true, 503);
header('Retry-After: 600'); // in ~10 Minuten zurück
header('Content-Type: text/html; charset=utf-8');
?>
<!doctype html>
<html lang="de"><head><meta charset="utf-8">
<title>Kurz nicht verfügbar</title></head>
<body>
<h1>Wir sind gleich zurück</h1>
<p>Wir spielen gerade ein geplantes Update ein.
In wenigen Minuten ist der Shop wieder erreichbar.</p>
</body></html>Cache-Warmup: kalt in den Verkauf zu gehen ist auch ein Ausfall
Der Wartungsmodus endet nicht in dem Moment, in dem der 503 verschwindet -- sondern erst, wenn der Shop wieder schnell antwortet. Nach einem Deploy sind die Caches typischerweise geleert: der Framework-Cache, der HTTP-Cache, oft auch der Objekt-Cache. Der erste Besucher nach dem Umschalten trifft dann auf einen kalten Cache, jede Seite wird neu berechnet, die Antwortzeiten steigen. Shopware bezeichnet den HTTP-Cache ausdrücklich als Must-have für jedes Produktivsystem (Shopware Documentation) -- ein Shop, der kalt in den Verkauf geht, läuft technisch, verkauft aber schlecht. Deshalb gehört das Cache-Warmup noch in das Fenster, bevor der 503 abgeschaltet wird.
Das Warmup läuft in zwei Stufen. Zuerst wird der Anwendungs-Cache aufgebaut, etwa mit dem Symfony-Kommando cache:warmup. Danach wird der HTTP-Cache gefüllt, indem die wichtigsten URLs einmal aufgerufen werden -- am pragmatischsten über die Sitemap, deren Einträge genau die Seiten enthalten, die Kunden ansteuern. Ein einfaches Skript ruft die Top-URLs parallel ab und misst die Statuscodes. Erst wenn diese Aufrufe sauber mit 200 antworten und die Antwortzeiten im gewohnten Rahmen liegen, wird der Wartungsschalter deaktiviert.
#!/usr/bin/env bash
set -euo pipefail
# Cache vorwärmen, BEVOR der 503-Schalter fällt
SITEMAP="https://shop.example/sitemap.xml"
# 1) Anwendungs-Cache aufbauen
php bin/console cache:warmup --env=prod
# 2) HTTP-Cache über die wichtigsten URLs aus der Sitemap füllen
curl -s "$SITEMAP" \
| grep -oE '<loc>[^<]+' | sed 's/<loc>//' \
| head -n 500 \
| xargs -P4 -n1 curl -s -o /dev/null -w '%{http_code} %{time_total}s %{url_effective}\n'
# 3) Erst bei sauberen 200ern und normalen Zeiten: 503-Schalter entfernen
# rm /var/www/maintenance.onErst warm, dann live
Der Rollback-Plan: Git-Tag plus Datenbank-Dump
Auch ein gut geprobtes Fenster braucht einen Rückweg. Kein Regressionstest nach dem Update deckt jede Datenkonstellation ab, und manche Probleme zeigen sich erst unter echter Last. Ein belastbarer Rollback-Plan ruht auf zwei Säulen: dem Code-Stand und dem Datenstand. Für den Code wird vor dem Deploy ein Git-Tag gesetzt, das den letzten bekannten guten Zustand markiert -- ein Rollback bedeutet dann, dieses Tag erneut auszurollen, im Idealfall per Symlink-Switch in Sekunden. Für die Daten wird unmittelbar vor der Migration ein frischer Datenbank-Dump gezogen, nicht das nächtliche Standard-Backup, sondern der Stand exakt vor dem Eingriff.
- Git-Tag auf den letzten stabilen Release-Stand setzen, bevor das Fenster beginnt.
- Frischer Datenbank-Dump unmittelbar vor der ersten Migration -- getrennt vom Routine-Backup.
- Vorheriges Release-Verzeichnis behalten, damit der Symlink in Sekunden zurückzeigen kann.
- Rollback-Schwellen definieren: etwa erhöhte Fehlerrate oder eingebrochene Checkout-Quote.
- Rollback im Staging mit Stoppuhr proben, damit die Wiederherstellungszeit bekannt ist.
- Migrationen rückwärtskompatibel gestalten, damit alter Code mit neuem Schema noch läuft.
Ein Deploy ohne getesteten Rückweg ist kein Deploy, sondern eine Wette. Der Rollback wird nicht im Ernstfall erfunden -- er wird vorher geprobt.
Migrationen sind die eigentliche Hürde
Vom Risiko zur Routine: der Ablauf in der Praxis
Die einzelnen Bausteine greifen zu einem festen Ablauf ineinander. Am Anfang steht das datenbasiert gewählte Fenster im Umsatztal. Zu Fensterbeginn wird der 503-Schalter gesetzt, sodass jede URL SEO-sicher mit Retry-After antwortet. Dann läuft das eigentliche Release: Abhängigkeiten, Migrationen, Assets. Ein kurzer Smoke-Test prüft die kritischen Pfade -- lädt die Startseite, funktioniert der Checkout, antworten die wichtigen Endpunkte. Anschließend wird der Cache vorgewärmt, und erst wenn die Aufrufe sauber und schnell zurückkommen, fällt der 503-Schalter. Der ganze Weg bleibt durch Git-Tag und Dump jederzeit rückholbar.
- Fenster im nachweisbaren Traffic-Tal, Change-Freeze aktiv.
- Git-Tag gesetzt, frischer Datenbank-Dump gezogen.
- 503-Modus aktiv, jede URL antwortet mit Retry-After.
- Release ausgerollt, Migrationen durchgelaufen, Smoke-Test grün.
- Cache aufgebaut und über die Sitemap vorgewärmt.
- 503-Schalter entfernt, Antwortzeiten im gewohnten Rahmen, Monitoring übernimmt.
Dieser Ablauf ist zum großen Teil automatisierbar -- und genau das macht ihn zuverlässig, weil jeder Lauf gleich abläuft, ohne vergessene Schritte. Der Aufwand für die Einrichtung amortisiert sich schnell, denn ein einziger vermiedener Ausfall im Verkaufstag wiegt oft schwerer als der gesamte Aufbau. Genau hier setzt unsere Managed Maintenance für Shopware und WordPress an: Wir planen die Fenster, fahren Updates im 503-Modus mit Cache-Warmup und halten Git-Tag und Dump für den Sofort-Rollback bereit. Flankiert von kontinuierlichem Uptime-Monitoring und einem SLA-Wartungsvertrag mit klaren Reaktionszeiten wird aus dem riskanten Go-Live eine planbare Routine. Wer die regulatorische Seite mitdenkt, findet die passende Einordnung in unserem Beitrag zu den NIS2-Pflichten für Online-Shops und zur Härtung über HTTP-Security-Header und CSP.
Quellen und Studien