WordPress Update-Checkliste

1 Vor dem Update

• Backup gezogen und Wiederherstellungsweg bekannt

  Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung. Einmal testweise wiederherstellen, bevor es ernst wird.

• Zugang zu SFTP und Datenbank griffbereit

  Bei einem Fatal Error ist das Backend nicht erreichbar. Wer dann erst Zugangsdaten sucht, verliert Stunden.

• Core-, PHP- und Plugin-Versionen dokumentiert

  Ohne Inventar lässt sich hinterher nicht sagen, welche Änderung das Problem ausgelöst hat.

• Lizenzstatus kommerzieller Plugins und Themes geprüft

  Ohne gültige Lizenz erscheint das Sicherheitsupdate gar nicht erst. Betrifft vor allem Themes wie Avada.

• Staging ist ein echter Klon der Produktion

  Inklusive Daten, aller Plugins und aller Lizenzen. Eine bereinigte Staging-Umgebung testet nicht das System, das live geht.

• Wartungsfenster kommuniziert

  Bei Shops und Buchungssystemen gehört der Zeitpunkt abgestimmt, nicht nur der Ablauf.

2 Update-Typ bestimmen

Nicht jedes Update verdient dieselbe Vorsicht. Security-Patches sofort, alles andere getestet.

3 Testprotokoll, pro Website

Auf Staging durchlaufen, nicht auf Produktion. „Sieht gut aus“ ist kein Test. Der Durchlauf dauert wenige Minuten und fängt den Großteil dessen ab, was in der Praxis schiefgeht.

• Startseite lädt mit HTTP-Status 200

  Ein Fatal Error liefert 500. Das fällt nur auf, wenn jemand hinsieht.

• Ein Beitrag und eine Seite im Editor öffnen und speichern

  Nicht nur laden, sondern tatsächlich bearbeiten. Editor-Fehler zeigen sich erst beim Benutzen.

• Jeden selbst gebauten Block auf einer Testseite einfügen

  Custom Blocks brechen bei Core-Updates zuerst, besonders bei Änderungen am Block-Editor.

• Kontaktformular absenden und Zustellung prüfen

  Auch im Spam-Ordner nachsehen. Ein stumm ausgefallenes Formular fällt oft erst Wochen später auf.

• Bei Shops: Produkt in den Warenkorb, Checkout bis zur Zahlungsauswahl

  Der Schritt, der am meisten kostet, wenn er bricht.

• Login und Logout

  Betrifft Mitgliederbereiche, Kundenkonten und alles mit eigener Rollenlogik.

• debug.log nach dem Durchlauf prüfen

  Deprecation-Warnungen hier sind die Fehler des nächsten Major-Releases.

4 Nach dem Ausrollen

• Frontend auf fehlende Block-Styles geprüft

  Besonders bei Inhalten, die per AJAX oder aus externen Quellen nachgeladen werden.

• Uptime-Monitoring aktiv und auf Statuscode konfiguriert

  Nicht nur "Server antwortet", sondern "Server antwortet mit 200".

• Caching geleert, Cache-Plugin auf aktuellem Stand

  Caching-Plugins sind die häufigste Quelle für Fehler nach Core-Updates.

• Ergebnis im Inventar nachgetragen

  Sonst stimmt beim nächsten Vorfall der Versionsstand nicht, auf den du dich verlässt.