Staging auf Live übertragen — der heikelste Klick im Projekt.
Auf der Kopie ist alles fertig, getestet und schön. Jetzt soll es live. Genau hier passieren die teuersten Fehler: zwei Wochen Bestellungen weg, Kommentare gelöscht, plötzlich die Staging-Adresse im Google-Index. Mit einer klaren Reihenfolge lässt sich das komplett vermeiden.
Vor dem Übertragen die wichtigste Frage klären: Was hat sich wo geändert? Nur Dateien geändert, also Theme, Plugins, Code — dann ist es einfach. Nur Inhalte auf Staging geändert — dann geht alles verloren, was live seitdem passiert ist. Beides geändert — dann wird gezielt übertragen. Immer gilt: frisches Backup, ruhige Uhrzeit, danach Prüfliste abarbeiten.
Die drei Fälle.
| Fall | Was geändert wurde | Vorgehen |
|---|---|---|
| 1 | Theme, Child-Theme, eigene Plugins, Code | Dateien übertragen, Datenbank live unangetastet lassen |
| 2 | Nur Inhalte und Einstellungen auf Staging, live passiert nichts | Komplett übertragen, live vorher einfrieren |
| 3 | Beides, und live laufen Bestellungen oder Kommentare weiter | Selektiv übertragen, Handarbeit |
Fall 1: nur Dateien.
Der unkomplizierte Fall. Die geänderten Ordner werden per SFTP oder über die Funktion des Hosters übertragen, die Datenbank bleibt, wie sie ist. Danach Caches leeren und die Seite durchklicken. Zwei Stolpersteine: Erstens dürfen keine Dateien mit übertragen werden, die auf Staging anders sein müssen — etwa eine wp-config.php mit anderen Zugangsdaten oder ein Plugin, das nur auf Staging aktiv sein soll. Zweitens können neue Theme-Dateien Einstellungen erwarten, die in der Datenbank noch fehlen. Dann werden diese Einstellungen nachträglich im Live-Backend gesetzt.
Fall 2: nur Inhalte.
Typisch beim Relaunch: Die neue Seite entsteht komplett auf Staging, live läuft die alte weiter. Vor der Übertragung wird die Live-Seite eingefroren — also niemand pflegt dort noch etwas ein, und bei Formularen wird geprüft, ob zwischenzeitlich Anfragen eingegangen sind. Dann wird die komplette Staging-Kopie übertragen, entweder mit der Funktion des Hosters oder per Migrations-Plugin. Danach unbedingt prüfen: Adressen, Permalinks, Weiterleitungen alter URLs und dass die Seite nicht mehr auf noindex steht (nicht bei Google gefunden).
Fall 3: beides.
Der Fall, der Handarbeit verlangt. Möglichkeiten, je nach Situation:
- Tabellenweise übertragen: Viele Hoster-Werkzeuge erlauben, einzelne Datenbanktabellen auszuwählen. Bestell- und Nutzertabellen bleiben dann unangetastet.
- Änderungen nachbauen: Bei überschaubaren Anpassungen ist es sicherer, sie auf der Live-Seite noch einmal einzustellen — mit der Staging-Seite als Vorlage daneben.
- Inhalte exportieren: Neue Seiten und Beiträge lassen sich einzeln exportieren und importieren, statt die ganze Datenbank zu tauschen.
- Zeitfenster wählen: Nachts oder am Wochenende, wenn kaum Bestellungen eingehen, und Besucher währenddessen auf eine kurze Wartungsseite schicken (Wartungsmodus).
Shops und Mitgliederbereiche.
Hier gilt die eiserne Regel: Bestellungen, Kundenkonten und Lagerbestände werden nie von Staging nach Live übertragen. Sie ändern sich ständig, und die Staging-Kopie ist immer veraltet. Außerdem müssen vor dem Livegang die Testeinstellungen zurückgesetzt werden: Zahlungsanbieter aus dem Testmodus holen, Webhooks auf die Live-Adresse zeigen lassen, Mailversand wieder scharf schalten und die Sperre für Suchmaschinen entfernen. Danach eine echte Testbestellung mit kleinem Betrag, die anschließend erstattet wird (WooCommerce-Support).
Checkliste vorher.
- Vollständiges Backup der Live-Seite, extern gespeichert und geprüft.
- Notieren, was auf Staging geändert wurde — Dateien, Inhalte, Einstellungen.
- Prüfen, was live seit dem Erstellen der Kopie passiert ist.
- Staging aufräumen: Testinhalte löschen, Testbestellungen entfernen, Entwicklungs-Plugins deaktivieren.
- Rückweg festlegen: Wie kommst du in zehn Minuten zum alten Stand zurück?
- Uhrzeit wählen, zu der wenig los ist.
Checkliste nachher.
- Startseite, wichtige Unterseiten, Blog, Suche und 404-Seite ansehen.
- Einstellungen, Lesen: Sperre für Suchmaschinen aus.
- Permalinks einmal speichern, alle Caches leeren — Plugin, Server, CDN.
- Formular absenden, Bestellprozess testen, Bestätigungsmails prüfen.
- Adressen kontrollieren: Keine Verweise mehr auf die Staging-Adresse im Quelltext.
- Mobil prüfen und Ladezeit messen.
- Am Folgetag die Search Console auf neue Fehler ansehen.
# Im Quelltext der Startseite
curl -s https://deine-domain.de/ | grep -o "staging[^\"' ]*" | sort -u
# In der Datenbank (WP-CLI, auf der Live-Seite)
wp search-replace 'https://staging.deine-domain.de' 'https://deine-domain.de' --all-tables --dry-runDer Trockenlauf zeigt erst nur an, was geändert würde. Erst ohne --dry-run wird wirklich ersetzt, und davor gehört ein Backup.
Was schiefgeht.
- Bestellungen überschrieben, weil die komplette Datenbank übertragen wurde.
- Seite auf noindex, weil die Sperre von Staging mitgewandert ist — der Klassiker, der Rankings kostet.
- Zahlungen im Testmodus, Kunden bestellen, aber es wird nichts abgebucht.
- Alte Adressen in der Datenbank, Bilder und Stile laden nicht (Layout kaputt).
- Weiterleitungen vergessen, wenn sich URLs geändert haben — alte Adressen laufen ins Leere (404 auf Unterseiten).
- Kein Rückweg, weil das Backup nie getestet wurde.
Wenn du nicht weiterkommst.
Livegänge mit Shop, vielen Inhalten oder gewachsener Struktur mache ich regelmäßig — inklusive Rückweg, Prüfliste und Nachkontrolle. Ich richte das ein, prüfe die Einbindung und erkläre dir, worauf es ankommt: WordPress-Hilfe. Damit es dauerhaft sauber bleibt: WordPress-Wartung.
Wer hilft.
Ich bin Manuel Killert, WordPress-Entwickler aus Quakenbrück. Seit 2020 baue und betreue ich WordPress-Websites — für Handwerksbetriebe, Industrie, Gastronomie, Start-ups und Vereine —, entwickle eigene Plugins und unterrichte WordPress als Dozent an der KW Design Akademie. Das heißt: Ich kenne die typischen Fehler nicht nur aus Foren, sondern aus eigenen Projekten, und ich kann sie so erklären, dass du sie beim nächsten Mal selbst erkennst. Du erreichst mich direkt, ohne Ticketsystem.
Echte Projekte — live ansehen.
WordPress-Websites, die ich gebaut habe oder laufend betreue.
Markenfest
Stärkerer Online-Shop — Webdesign, Content und individuelle Shop-Funktionen.
Website ansehen ↗
KT Bodenteam
Professioneller Auftritt für einen Bodenleger — Vorher-Nachher-Slider und regionale SEO.
Website ansehen ↗
Potassco Solutions
Klare Website für ein KI-Unternehmen, die komplexe Technologie verständlich macht.
Website ansehen ↗FAQ — Staging auf Live übertragen.
Wie übertrage ich Staging auf Live?
Je nach Fall: Nur Dateien übertragen, wenn sich Theme, Plugins oder Code geändert haben. Komplett übertragen, wenn live nichts passiert ist. Selektiv übertragen, wenn beides geändert wurde und Bestellungen oder Kommentare weiterlaufen.
Gehen beim Übertragen Bestellungen verloren?
Wenn die komplette Datenbank übertragen wird, ja. Bei Shops werden Bestell-, Kunden- und Lagerdaten nie von Staging übernommen, sondern nur die tatsächlich geänderten Teile.
Was muss ich nach dem Livegang sofort prüfen?
Dass die Sperre für Suchmaschinen aus ist, Permalinks gespeichert und Caches geleert wurden, Formulare und Bestellprozess funktionieren und im Quelltext keine Staging-Adressen mehr stehen.
Warum steht meine Seite nach dem Relaunch auf noindex?
Weil die Einstellung Suchmaschinen davon abhalten von der Staging-Kopie mitübertragen wurde. Sie steht unter Einstellungen, Lesen und muss nach dem Livegang deaktiviert werden.
Wann ist der beste Zeitpunkt für den Livegang?
Zu einer Zeit mit wenig Verkehr, also abends oder am Wochenende, und nie kurz vor Feierabend oder Urlaub. Für kurze Arbeiten hilft ein Wartungsmodus mit Statuscode 503.
Brauche ich vorher ein Backup?
Ja, ein vollständiges und extern gespeichertes, dessen Wiederherstellung schon einmal getestet wurde. Ohne getesteten Rückweg sollte kein Livegang starten.
Das bin ich – rechts im BildErzähl mir, was nicht funktioniert.
Domain und eine kurze Beschreibung reichen — du bekommst eine ehrliche Einschätzung, was los ist und was die Behebung kostet.
Antwort meist innerhalb von 24 Stunden · hallo@manuelkillert.de