WordPress Staging: Updates testen, ohne die Live-Seite zu riskieren

WordPress Staging heißt: Du spielst Updates und Änderungen zuerst auf einer Kopie deiner Website ein, prüfst dort Formular, Tracking und Darstellung und übernimmst sie erst danach auf die Live-Seite. Für jede Website, die professionell Anfragen oder Umsatz bringen soll, gehört das für mich zum Standard. Ein Ladenlokal renoviert man auch nicht während der Öffnungszeiten.

Die Anleitungen, die bei Google zu WordPress Staging oben stehen, enden fast alle beim Einrichten der Kopie. Was dort fehlt: Eine Kopie deiner Website bringt alles mit, was nach außen wirkt. Sie kann echte Mails verschicken, Conversions an dein Werbekonto melden und Kontakte im Newsletter-Tool anlegen. Wer das nicht abschaltet, schützt die Live-Seite vor kaputten Updates und schickt dafür womöglich Testmails an Kunden.

In diesem Artikel zeige ich dir, wie Updates eine Live-Seite still kaputtmachen, wie mein Ablauf von der Testkopie bis zur Live-Seite aussieht, was eine Testkopie abgeschaltet braucht und welche Updates bei mir sofort live gehen.

Was WordPress Staging ist

WordPress Staging ist eine vollständige Kopie deiner Website mit Dateien und Datenbank, die unter einer eigenen Adresse läuft, zum Beispiel auf einer Subdomain. Sie ist nirgends verlinkt, aber erreichbar ist sie trotzdem, solange niemand eine Anmeldung davorsetzt. Auf der Kopie kannst du Plugins aktualisieren, das Theme wechseln oder eine neue Seite bauen, ohne dass Besucher der Live-Seite etwas davon merken. Testumgebung, Staging-Site und Staging-Umgebung meinen dasselbe.

Eine Kopie lässt sich auch lokal auf dem eigenen Rechner anlegen; IONOS beschreibt beide Varianten (IONOS Digital Guide). Für Updates einer laufenden Website ziehe ich eine Kopie auf demselben Hosting vor, weil PHP-Version, Server und Caching dort dieselben sind wie auf der Live-Seite.

Warum Updates direkt auf der Live-Seite ein Risiko sind

Ein Update kann eine Website auf drei Arten kaputtmachen, und nur eine davon fällt sofort auf:

• Kritischer Fehler: Die Seite zeigt eine Fehlermeldung oder bleibt weiß. Das merkst du schnell.
• Zerschossenes Layout: Die Seite ist erreichbar, sieht aber falsch aus, etwa weil ein Pagebuilder-Element nach dem Update anders dargestellt wird.
• Still kaputt: Die Seite sieht normal aus, aber das Formular sendet nicht mehr, der Warenkorb rechnet falsch oder das Tracking zählt nichts.

Besonders tückisch wird es mit Cache. Ein Caching-Plugin liefert Besuchern fertige Seiten aus dem Zwischenspeicher aus. Wie das funktioniert, steht im Artikel zu WP Rocket und Redis Object Cache. Liegt dort noch die funktionierende Fassung, bekommst du den Fehler gar nicht mit, bis der Cache sich erneuert.

Wie still so ein Fehler sein kann, habe ich auf meiner eigenen Website nach dem Wechsel auf ein neues Kontaktformular erlebt. Das war kein Update. Die Wirkung ist aber dieselbe: Contact Form 7 hat jede Absendung als Spam abgewiesen, und die Seite sah dabei völlig normal aus. Aufgefallen ist es nur, weil ich das Formular selbst abgeschickt habe. Die Ursache steht im Artikel zu Borlabs mit dem Google Tag Manager.

Mein Ablauf: Kopie aktualisieren, Update, Test, live

Reguläre Updates laufen bei mir in einem festen Rhythmus über die Testumgebung, in vier Schritten. Sicherheitsupdates sind die Ausnahme, dazu weiter unten mehr.

1. Kopie frisch von der Live-Seite holen. Die Testumgebung braucht den aktuellen Stand. Sonst testest du gegen alte Inhalte und alte Plugin-Versionen.
2. Updates auf der Kopie einspielen. In der Reihenfolge aus dem Artikel zur WordPress Wartung: Plugins, Themes, zuletzt der Core.
3. Prüfen, was Geld bringt. Formular abschicken und kontrollieren, ob die Benachrichtigung ankommt. Das wichtigste Tracking-Ereignis auslösen und in der Vorschau des Tag Managers prüfen, ob es feuert. Startseite und eine Unterseite in einem privaten Fenster ansehen. Die Ladezeit grob mit PageSpeed Insights vergleichen. Bei Shops gehört eine Testbestellung dazu.
4. Live übernehmen. Hat sich die Live-Seite seit dem letzten täglichen Backup verändert, lege ich vorher zusätzlich ein Backup von Hand an. Dann spiele ich die getesteten Updates auf der Live-Seite ein, leere den Cache und prüfe die Live-Seite ohne Anmeldung. Die Datenbank der Kopie übertrage ich nicht auf die Live-Seite, weil dabei Bestellungen und Anfragen aus der Zwischenzeit verloren gehen könnten.

Was eine Testkopie alles mitbringt

Eine Kopie deiner Website ist erst einmal eine zweite, voll funktionsfähige Website. Sie nutzt dieselben Zugänge für Mailversand, Newsletter-Tool und Werbekonten wie das Original. Löst du dort eine Testanfrage oder Testbestellung aus, kann Folgendes passieren:

• Mails gehen an echte Kunden oder in das Postfach, in dem sonst echte Anfragen landen.
• Der Testkontakt landet im Newsletter-Tool.
• Das Werbekonto zählt eine Conversion, die es nie gab, und eine automatische Gebotsstrategie lernt daraus.
• Suchmaschinen indexieren die Kopie, wenn sie öffentlich erreichbar ist.

Raidboxes, selbst Anbieter von WordPress-Hosting mit Staging-Funktion, sieht das entspannter: Alles, was du auf der Testumgebung testest, bleibe isoliert von sensiblen Kundendaten, Bestellungen oder E-Mails (Raidboxes). Ob das auf deine Testumgebung zutrifft, hängt davon ab, was dein Hoster oder dein Plugin tatsächlich abschaltet. Beim Plugin WP Staging legst du beim Anlegen der Kopie in den erweiterten Einstellungen fest, ob die Kopie Mails verschicken darf (Dokumentation des Herstellers). Laut der Anleitung der WordPress-Agentur WP-Ninjas gibt es diese Einstellungen nur in der Pro-Fassung, und der Haken für den Mailversand ist dort von Haus aus gesetzt (WP-Ninjas). Prüf deshalb mit einer Testanfrage an deine eigene Adresse, was deine Kopie tatsächlich tut.

Praxisfall: Die alte Testumgebung nahm Bestellungen an

Bei einem Kunden war die alte Testumgebung ohne Anmeldung erreichbar. Sie war voll funktionsfähig, nahm Bestellungen an und verschickte Mails. Wer die Adresse kannte, hätte dort echte Bestellungen auslösen können. Der geplante Schutz der Kopie war nie umgesetzt worden.

Für die neue Testumgebung habe ich einen Schutzschalter gebaut. Er erkennt am Umgebungstyp von WordPress und am Hostnamen, dass er auf der Kopie läuft. Den Umgebungstyp gibt es seit WordPress 5.5, mögliche Werte sind local, development, staging und production (WordPress-Entwicklerdokumentation). Auf der Kopie fängt der Schalter alle Mails ab und protokolliert sie, auch wenn ein SMTP-Plugin den Versand übernimmt. Er sperrt die Verbindungen zu Newsletter-, Übersetzungs- und KI-Diensten, lässt nur angemeldete Nutzer herein, schließt Suchmaschinen per noindex aus und entschärft die Tracking-Codes. Noindex ist eine Anweisung an Suchmaschinen, die Seite nicht in ihren Index aufzunehmen. Auf der Live-Seite tut der Schalter nichts.

Abgeglichen wird über zwei Knöpfe. Einer holt einen frischen Stand der Live-Seite auf die Kopie und liest die Live-Seite dabei nur. Der andere überträgt ausschließlich die selbst entwickelte Erweiterung auf die Live-Seite, legt vorher eine Sicherung an und nimmt die Änderung bei einem Fehler automatisch zurück.

Die Kehrseite: Was von einem gesperrten Dienst abhängt, lässt sich auf der Kopie nicht prüfen. Neue englische Texte zum Beispiel entstehen dort nicht, weil der Übersetzungsdienst gesperrt ist.

Geteilter Cache: wenn die Kopie die Live-Seite trifft

Auch eine abgeschottete Kopie kann die Live-Seite treffen. Beim selben Kunden nutzten Live-Seite und Testumgebung anfangs dieselbe Redis-Datenbank ohne eigenes Präfix für die Cache-Schlüssel. Redis ist ein Zwischenspeicher, der häufige Datenbankabfragen im Arbeitsspeicher vorhält. Die Kopie legte ihre eigene Adresse im Cache ab, die Live-Seite las sie von dort und schickte Besucher acht Minuten lang auf die Anmeldeseite der Testumgebung. Seitdem läuft Redis auf der Kopie nicht mehr. Wie du zwei Installationen auf einem Redis-Server trennst, steht im Artikel zu WP Rocket und Redis.

Staging beim Hoster, per Plugin oder selbst gebaut

Für die meisten Unternehmer empfehle ich WordPress Staging über den Hoster, wenn er eine Staging-Funktion anbietet. Sie legt die Kopie mit wenigen Klicks an, und du musst keine Datenbank von Hand kopieren. Nicht jeder Tarif enthält sie, und auch eine Kopie beim Hoster verschickt Mails, solange niemand das abschaltet. Prüfe vor dem ersten Einsatz deshalb vier Punkte:

• Schutz vor Besuchern und Suchmaschinen: Eine Sperre per robots.txt reicht nicht. Google schreibt selbst, dass robots.txt kein Mittel ist, um eine Seite aus Google herauszuhalten, und empfiehlt noindex oder einen Passwortschutz (Google Search Central).
• Mailversand: Schick auf der Kopie ein Formular mit deiner eigenen Adresse ab und schau, wo die Benachrichtigung landet.
• Tracking: Prüfe in der Vorschau des Tag Managers oder in den Entwicklertools des Browsers, ob auf der Kopie Tracking-Codes laden.
• Cache: Frag deinen Hoster, ob Kopie und Live-Seite sich einen Objekt-Cache wie Redis teilen.

Bietet dein Hoster keine Staging-Funktion an, ist ein Plugin wie WP Staging die Alternative. Eine selbst gebaute Lösung wie im Praxisfall braucht Zugriff auf den Server und muss gepflegt werden.

Welche Updates sofort live gehen dürfen

Sicherheitsupdates spiele ich sofort auf der Live-Seite ein, auch bei Plugins, und teste die Seite direkt danach. Alle anderen Updates laufen im festen Rhythmus über die Testumgebung: erst auf der Kopie, dann der Test, danach live.

WordPress selbst setzt noch stärker auf Automatik. Kleinere Core-Updates spielt WordPress standardmäßig automatisch ein, und seit Version 5.6 sind bei neuen Installationen auch die großen Core-Updates automatisch aktiviert (WordPress-Dokumentation). Das hat einen nachvollziehbaren Grund, und er ist auch meiner bei Sicherheitsupdates: Ein Sicherheitsupdate, das wochenlang auf den nächsten Testlauf wartet, lässt die Lücke so lange offen.

Ein automatisches Update prüft aber nicht, ob dein Formular danach noch sendet. Deshalb gehört zu jedem Sicherheitsupdate direkt danach der kurze Test aus Schritt 3: Formular, Tracking, Darstellung. Große Core-Updates sollen bei mir dagegen über die Kopie laufen. Wer das genauso halten will, muss es bei neuen Installationen aktiv einstellen: unter Dashboard, Aktualisierungen oder per Eintrag WP_AUTO_UPDATE_CORE mit dem Wert minor in der wp-config.php (WordPress-Dokumentation). Wie du den Umgang mit Updates in einem Wartungsvertrag festhältst, steht im Artikel zum WordPress Wartungsvertrag.

Was du selbst prüfen kannst

1. Gibt es für deine Website ein WordPress Staging? Und wann wurde die Testumgebung zuletzt von der Live-Seite aktualisiert?
2. Ist sie geschützt? Ruf die Adresse der Kopie in einem privaten Fenster auf. Ohne Anmeldung sollte dort nichts zu sehen sein.
3. Verschickt sie Mails? Schick dort ein Formular mit deiner eigenen Adresse ab und prüfe, wo die Benachrichtigung ankommt.
4. Was läuft automatisch? Prüfe unter Dashboard, Aktualisierungen und in der Plugin-Übersicht, welche Updates automatisch eingespielt werden.
5. Wurde nach dem letzten Update getestet? Formular abgeschickt, Tracking geprüft? Wenn du das nicht sicher sagen kannst, hol es jetzt nach.

Häufige Fragen zu WordPress Staging

Fazit

Ein Update auf der Live-Seite ist ein Test im laufenden Betrieb, und am meisten kosten nach meiner Erfahrung die Fehler, die du nicht siehst: ein Formular, das nicht mehr sendet, oder ein Tracking, das nichts mehr zählt. Eine Testumgebung fängt das ab, solange sie selbst abgeschottet ist und keine Mails, Conversions oder Cache-Einträge in den Live-Betrieb trägt.

Wenn du heute nur eine Sache prüfst, dann diese: Ruf deine Testumgebung in einem privaten Fenster auf und schick dort ein Formular an deine eigene Adresse. Danach weißt du, ob die Kopie dich schützt oder selbst ein Risiko ist.

Wenn du unsicher bist, ob deine Updates gerade ungetestet auf die Live-Seite gehen: Im Erstgespräch schauen wir gemeinsam an, welcher nächste Schritt sich bei dir rechnet. Wie ich WordPress-Websites baue und warte, steht auf der Seite zur WordPress-Entwicklung.