Updates: warum sie zuerst auf die Testumgebung gehören

Updates gehören zuerst auf eine Testumgebung, weil du dort siehst, ob etwas kaputtgeht, bevor es deine Besucher sehen. Aufschieben ist keine Alternative: Angriffe auf bekannte Lücken in WordPress-Plugins laufen automatisiert und beginnen oft innerhalb von Stunden. Direkt auf der laufenden Website „Alle aktualisieren" zu klicken, geht meistens gut — und wenn nicht, ist die Seite weg und du weißt nicht, welches der elf Updates schuld war. Eine Testumgebung ist der Weg zwischen beiden Fehlern: eine Kopie der Website, auf der du ausprobierst, bevor es ernst wird.

Warum Updates nicht warten können

Patchstack, ein Anbieter für WordPress-Sicherheit, zählt in seinem Bericht „State of WordPress Security in 2026" für das Jahr 2025 11.334 neue Schwachstellen im WordPress-Umfeld, 42 Prozent mehr als im Jahr davor. 91 Prozent davon steckten in Plugins, 9 Prozent in Themes, im WordPress-Kern selbst waren es sechs.

Und es geht schnell. Bei den massenhaft angegriffenen Lücken lag der Median bis zur ersten massenhaften Ausnutzung bei fünf Stunden; rund die Hälfte der Lücken mit hoher Auswirkung wurde innerhalb von 24 Stunden ausgenutzt.

Das heißt: Niemand hat sich deine Website ausgesucht. Ein Programm durchsucht das Netz nach Websites mit einer bestimmten Plugin-Version. Deine Website ist nicht zu klein, um interessant zu sein — für dieses Programm ist sie eine Zeile in einer Liste.

Was WordPress schon selbst tut

WordPress nimmt dir einen Teil der Arbeit ab, und es lohnt sich zu wissen, welchen:

Was	Wie	Seit
kleine Kern-Versionen (Wartung und Sicherheit)	aktualisieren sich standardmäßig selbst; WordPress rät dringend davon ab, das abzuschalten	—
Plugins und Themes	automatische Updates lassen sich je Plugin und Theme einschalten, WordPress prüft zweimal täglich und schickt eine Mail	5.5
Absturzschutz	bei einem fatalen Fehler zeigt WordPress eine Fehlermeldung und schickt eine Mail mit einem Link in den Wiederherstellungsmodus	5.2
Rückroller bei automatischen Plugin-Updates	nach dem Update ruft WordPress die Startseite auf; tritt ein fataler PHP-Fehler auf, wird die alte Version zurückgespielt	6.6

Das ist ein Sicherheitsnetz, keine Prüfung. Der Rückroller erkennt nur fatale PHP-Fehler auf der Startseite. Ein Formular, das keine Mail mehr verschickt, ein verrutschtes Layout oder eine kaputte Kasse fallen ihm nicht auf. Große Kern-Versionen, Theme-Wechsel und große Sprünge bei zentralen Plugins gehören deshalb weiter auf die Testumgebung.

Was eine Testumgebung ist

Eine zweite Kopie deiner Website — mit denselben Inhalten, denselben Plugins, denselben Einstellungen — die nicht öffentlich erreichbar ist und auf der du ausprobieren kannst, ohne dass es jemand mitbekommt.

Viele Hoster bieten das mit einem Klick an: Kopie erzeugen, arbeiten, dann verwerfen oder zurückspielen. Wo nicht, lässt sich eine Kopie auf einer Unteradresse einrichten.

Zwei Bedingungen machen sie brauchbar:

• Sie muss aktuell sein. Eine Kopie von vor sechs Monaten testet eine Website, die es nicht mehr gibt. Das Auffrischen gehört in die regelmäßige Wartung und immer vor größere Vorhaben.
• Sie muss geschützt sein. Eine öffentlich erreichbare Kopie erzeugt doppelte Inhalte. Google schreibt, dass Inhalte, die nicht öffentlich sein sollen, mit einem Passwort geschützt werden müssen. Ein Passwortschutz auf Serverebene hält Suchmaschinen und Neugierige zugleich draußen.

Der Ablauf, der funktioniert

Vorher:

1. Backup anlegen. WordPress.org rät selbst dazu, vor jedem Update zu sichern. Nicht auf die nächtliche Sicherung verlassen — eine frische anlegen und nachsehen, ob sie da ist.
2. Testumgebung auf den aktuellen Stand bringen.
3. Die Änderungsprotokolle lesen. Bei einer neuen Hauptversion eines Plugins steht dort oft, was sich grundlegend ändert. Das sind die Updates, bei denen genaues Hinsehen lohnt.

Auf der Testumgebung:

4. Einzeln aktualisieren, nicht alles auf einmal. Bei fünf Plugins auf einmal weißt du im Fehlerfall nicht, welches es war. Das ist auch das Verfahren, das WordPress.org zur Fehlersuche empfiehlt: alle Plugins abschalten und einzeln wieder einschalten.
5. Nach jedem Schritt kurz prüfen.

Prüfen heißt konkret:

• Sieht die Startseite noch richtig aus?
• Funktionieren die Formulare — und kommt die Mail tatsächlich an?
• Die wichtigsten Seiten durchklicken: Startseite, Leistungen, Kontakt.
• Die Konsole im Browser (F12) auf JavaScript-Fehler prüfen.
• Die mobile Ansicht anschauen.

Der Punkt mit der Mail wird am häufigsten übersehen. Ein Formular, das eine Bestätigung anzeigt, hat noch keine Mail verschickt. Prüf im Postfach, nicht auf dem Bildschirm.

Danach:

6. Auf die Live-Website übertragen — je nach Aufbau durch Zurückspielen der Testumgebung oder durch Wiederholen derselben Schritte.
7. Dieselbe Prüfung noch einmal live. Die Live-Website ist nicht identisch mit der Testumgebung: andere Adresse, anderer Zwischenspeicher, echte Formularempfänger, echte Zahlungsanbindung.
8. Zwischenspeicher leeren. Sonst siehst du den alten Stand und hältst ihn für den neuen.

Was zuerst dran ist

Nicht jedes Update ist gleich dringend.

• Sicherheitsupdates gehen vor. Wenn ein Update eine Lücke schließt, die schon ausgenutzt wird, ist das Risiko des Wartens größer als das Risiko eines Darstellungsfehlers. Dann wird eingespielt und danach geprüft — nicht umgekehrt.
• Kleine Kern-Versionen laufen ohnehin automatisch.
• Große Kern-Versionen und Hauptversionen zentraler Plugins — Seitenbaukasten, Shop, Formulare — gehören auf die Testumgebung.

Die PHP-Version wird gern vergessen, obwohl alles darauf läuft. Jede PHP-Version bekommt zwei Jahre volle Pflege und zwei weitere Jahre nur Sicherheitskorrekturen; danach gar nichts mehr. Das PHP-Projekt warnt, dass Nutzer einer ausgelaufenen Version ungepatchten Lücken ausgesetzt sein können. WordPress empfiehlt PHP 8.3 oder neuer. Der Wechsel ist meist ein Klick beim Hoster — und genau deshalb gehört er auf die Testumgebung, weil alte Plugins daran brechen können.

Wenn doch etwas kaputtgeht

Auf der Testumgebung: nichts. Genau dafür ist sie da. Ursache suchen, Plugin ersetzen oder auf die alte Version zurück, weitermachen.

Auf der Live-Website:

1. Ruhe. Hektisch weitere Dinge zu ändern, macht die Fehlersuche schwerer.
2. Ins Postfach schauen. Meldet WordPress einen kritischen Fehler auf der Website, schickt es an die Adresse des Administrators eine Mail mit Details und einem Link in den Wiederherstellungsmodus.
3. Das zuletzt aktualisierte Plugin deaktivieren.
4. Wenn du nicht ins Backend kommst: Per Dateizugriff im Ordner wp-content den Ordner plugins umbenennen, etwa in plugins-alt. WordPress findet die Plugins dann nicht mehr und schaltet sie alle ab. Danach zurückbenennen und einzeln wieder einschalten.
5. Wenn das nicht hilft: Backup einspielen.
6. Danach die Ursache klären, bevor dasselbe Update erneut versucht wird.

Eine weiße Seite ist meist ein PHP-Fehler, ausgelöst durch ein Plugin oder das Theme. WordPress.org rät, den Debug-Modus in der wp-config.php einzuschalten und das Protokoll in wp-content/debug.log zu lesen — dort steht in der Regel, welche Datei betroffen ist. Danach den Debug-Modus wieder ausschalten.

Der Rhythmus

Updates, die „wenn Zeit ist" gemacht werden, werden nicht gemacht. Ein fester Rhythmus funktioniert:

Monatlich: WordPress-Kern, Plugins und Themes prüfen und einspielen, PHP-Version prüfen, Sicherungen prüfen, Sicherheitsscan, Fehlerprotokoll ansehen, Kontaktformular bis ins Postfach testen, Ladezeit messen.

Quartalsweise: Plugin-Liste durchgehen, Datenbank aufräumen, Zertifikat prüfen, tote Links prüfen, Testumgebung auffrischen.

Jährlich: vollständiger Sicherheitsdurchgang, Hosting-Paket und Domainverlängerung prüfen, Datenschutzerklärung und Impressum auf Aktualität prüfen, Barrierefreiheit stichprobenartig testen.

Die Lücke, die Sorgfalt nicht schließt

Ein ehrlicher Zusatz: Bei 46 Prozent der Schwachstellen gab es laut Patchstack zum Zeitpunkt der Veröffentlichung noch keine Korrektur des Herstellers. Selbst wer vorbildlich aktualisiert, hat dann eine Lücke — und die schließt schnelleres Aktualisieren nicht, weil es nichts zu aktualisieren gibt.

Die übliche Antwort ist eine vorgelagerte Schutzschicht, die das Angriffsmuster blockiert, bevor das Plugin selbst korrigiert ist. Sicherheitsanbieter wie Patchstack verkaufen solche Regeln. Für eine kleine Visitenkartenseite ist das oft mehr, als nötig ist. Für einen Betrieb, dessen Website Anfragen oder Bestellungen entgegennimmt, ist es die naheliegende Ergänzung.

Das ist kein Argument gegen Updates, sondern dagegen, Updates für die ganze Antwort zu halten.

Was zu tun ist

1. Richte eine Testumgebung ein, wenn du keine hast. Frag deinen Hoster — bei vielen ist sie enthalten. Und schütz sie mit einem Passwort.
2. Hör auf, direkt auf der Live-Website zu aktualisieren. Auch wenn es bisher gutgegangen ist.
3. Lass die kleinen Kern-Updates an und überleg für einfache, gut gepflegte Plugins die automatischen Updates — mit Backup im Hintergrund.
4. Leg einen festen Termin fest. Ein fester Tag im Monat.
5. Prüf die PHP-Version. Der am häufigsten übersehene Punkt.
6. Frisch die Testumgebung regelmäßig auf. Eine veraltete Testumgebung testet die falsche Website.
7. Und wenn dir das zu viel ist: Genau dafür gibt es Wartungsverträge. Nicht weil es kompliziert wäre, sondern weil es regelmäßig sein muss — und Regelmäßigkeit ist das, was neben dem Tagesgeschäft als Erstes wegfällt.

Quellen

• Patchstack, State of WordPress Security in 2026 — 11.334 Schwachstellen 2025, plus 42 Prozent, 91 Prozent Plugins, 9 Prozent Themes, 6 im Kern, 46 Prozent ohne Korrektur, Median fünf Stunden, rund die Hälfte binnen 24 Stunden: patchstack.com
• WordPress.org, Upgrading WordPress — Backup vor dem Update, automatische kleine Versionen, Fehlersuche durch einzelnes Einschalten der Plugins: developer.wordpress.org
• WordPress.org, Plugin and themes auto-updates — seit 5.5, zweimal täglich, Mail-Benachrichtigung: wordpress.org
• Make WordPress Core, Merge Proposal: Rollback Auto-Update — Rückroller bei fatalem Fehler über Aufruf der Startseite, Wiederherstellungsmodus seit 5.2: make.wordpress.org
• Make WordPress Core, WordPress 6.6 Field Guide — Rückroller für automatische Plugin-Updates in 6.6: make.wordpress.org
• WordPress.org, Common WordPress Errors — kritischer Fehler und Mail, Plugin-Ordner umbenennen, Debug-Modus und debug.log: developer.wordpress.org
• WordPress.org, Requirements — PHP 8.3 oder neuer empfohlen, ausgelaufene Versionen als Sicherheitsrisiko: wordpress.org
• PHP, Supported Versions — zwei Jahre volle Pflege, zwei Jahre Sicherheitskorrekturen, Warnung vor ausgelaufenen Versionen: php.net
• Google Search Central, Control what you share with Google — private Inhalte mit Passwort schützen: developers.google.com
• WordPress.org, Hardening WordPress — Plugins aktuell halten: developer.wordpress.org