WordPress-Updates vor dem Einspielen prüfen: Changelogs lesen und Risiken einschätzen

Ein Klick auf „Jetzt aktualisieren“ dauert Sekunden, ein fehlerhaftes Update kann dagegen das Kontaktformular, den Shop oder die ganze Website lahmlegen. Die meisten Probleme lassen sich vorher erkennen: Versionsnummer, Änderungsprotokoll, Kompatibilitätsangaben und Mindestanforderungen verraten, wie groß der Sprung ist und was sich ändert. Diese Anleitung zeigt, wie Sie vor dem Einspielen eines Plugin-, Theme- oder Core-Updates in wenigen Minuten eine belastbare Einschätzung treffen und danach entscheiden: sofort einspielen, erst testen oder bewusst warten.

Voraussetzungen

• WordPress: eine aktuelle Installation, im Test WordPress 7.1.2 mit deutschem Sprachpaket. Die Menüpunkte heißen in älteren Versionen teils anders.
• PHP: Die Version Ihres Servers müssen Sie kennen, weil Updates Mindestanforderungen mitbringen. Sie finden sie unter „Werkzeuge > Website-Zustand“ im Reiter „Bericht“ oder per php -v. WordPress empfiehlt laut Versions-API derzeit mindestens PHP 7.4, im Test lief PHP 8.4.
• Zugriff: ein Benutzerkonto mit der Rolle Administrator im Backend. Für die WP-CLI-Variante zusätzlich SSH-Zugang und WP-CLI (im Test Version 2.12.0).
• Backup: ein aktuelles, wiederherstellbares Backup von Dateien und Datenbank, bevor Sie ein Update tatsächlich einspielen. Die Prüfung selbst ändert nichts an der Website.
• Optional: eine Staging-Umgebung, also eine Kopie der Website zum Testen, etwa wie in der Anleitung WordPress auf dem Synology NAS als Staging-Umgebung beschrieben.

Schritt 1: Anstehende Updates vollständig erfassen

Bevor Sie ein einzelnes Update bewerten, brauchen Sie die Gesamtliste. Sonst übersehen Sie Abhängigkeiten zwischen Plugins.

Im Backend öffnen Sie „Dashboard > Aktualisierungen“. WordPress zeigt dort Core, Plugins, Themes und Übersetzungen getrennt. Bei jedem Plugin steht eine Zeile wie „Kompatibilität mit WordPress 7.1.2: Ja (laut Autor)“ oder „nicht getestet“. Unter „Plugins > Installierte Plugins“ erscheint zusätzlich der Hinweis „Eine neue Version von … ist verfügbar“ mit dem Link „Details der Version … anzeigen“.

Auf der Kommandozeile erhalten Sie dieselbe Übersicht mit den Anforderungen der neuen Version in einer Tabelle:

wp core check-update
wp plugin list --update=available --fields=name,version,update_version,requires,requires_php,auto_update
wp theme list --update=available --fields=name,version,update_version

Im Labor mit einer absichtlich veralteten Version von Contact Form 7 sah das so aus:

Success: WordPress is at the latest version.
name            version  update_version  requires  requires_php  auto_update
contact-form-7  6.0      6.1.7           6.7       7.4           off

Die Spalten requires und requires_php beziehen sich auf die neue Version aus dem Plugin-Verzeichnis. Die installierte Version 6.0 nannte in ihrer readme.txt noch „Requires at least: 6.6“, die neue verlangt WordPress 6.7. Solche Anhebungen sehen Sie nur, wenn Sie gezielt hinschauen.

Verifizieren: Sie haben eine Liste aller anstehenden Updates mit installierter Version, Zielversion und Mindestanforderungen. Die Zahl der Einträge stimmt mit dem Zähler an „Dashboard > Aktualisierungen“ überein.

Schritt 2: Den Versionssprung einordnen

Die Versionsnummer ist der schnellste Hinweis auf das Risiko. Das WordPress-Plugin-Handbuch empfiehlt Plugin-Autoren die Schreibweise nach Semantic Versioning (SemVer), schreibt sie aber nicht vor. Viele Plugins halten sich daran, verlassen dürfen Sie sich darauf nicht.

Sprung	Beispiel	Typischer Inhalt	Einschätzung
Patch	6.0 auf 6.0.6	Fehlerkorrekturen, Sicherheitskorrekturen	geringes Risiko, zügig einspielen
Minor	6.0 auf 6.1.7	neue Funktionen, geänderte Anforderungen	Änderungsprotokoll lesen, Kernfunktionen danach testen
Major	5.x auf 6.0	Umbauten, entfernte Funktionen, Datenbankänderungen	Backup und Staging-Test, Termin planen

Beim WordPress-Core gilt eine eigene Zählung: Die erste und zweite Stelle zusammen bilden die Hauptversion. Ein Wechsel von 7.0 auf 7.1 ist ein Major-Release mit neuen Funktionen, 7.1.1 auf 7.1.2 ein Wartungs- und Sicherheitsrelease. Laut WordPress-Dokumentation spielen die meisten Websites solche kleinen Core-Updates seit Version 3.7 automatisch im Hintergrund ein, für Hauptversionen ist ein Klick nötig.

WP-CLI kann den Sprung gezielt begrenzen. Im Labor zeigte der Probelauf mit --patch nur das Update auf 6.0.6, mit --minor das auf 6.1.7:

wp plugin update contact-form-7 --patch --dry-run
wp plugin update contact-form-7 --minor --dry-run

Das ist nützlich, wenn Sie eine Sicherheitskorrektur sofort brauchen, den größeren Sprung aber erst nach einem Test machen möchten.

Verifizieren: Jedes Update in Ihrer Liste trägt eine Einstufung Patch, Minor oder Major. Der Probelauf mit --dry-run meldet „Available plugin updates“ und zeigt die erwartete Zielversion, ohne etwas zu ändern.

Schritt 3: Das Änderungsprotokoll lesen

Das Änderungsprotokoll (Changelog) beantwortet die wichtigste Frage: Was ist anders? Im Backend öffnen Sie es über „Details der Version … anzeigen“ und dort den Reiter „Änderungsprotokoll“. Die Inhalte stammen aus der readme.txt des Plugins im WordPress.org-Verzeichnis. Contact Form 7 etwa führt im Änderungsprotokoll für die Versionen 6.1.x nur Links auf die Release-Beiträge von contactform7.com, für 6.0.2 steht direkt „Removes unnecessary type declaration from nullable arguments to avoid deprecation warnings in PHP 8.4“. Folgen Sie in solchen Fällen dem Link, die eigentliche Information steht dort.

Lesen Sie alle Einträge zwischen Ihrer installierten Version und der Zielversion, nicht nur den obersten. Bei einem Sprung von 6.0 auf 6.1.7 sind das rund ein Dutzend Versionen. Achten Sie auf diese Signalwörter:

• Security, Sicherheit, XSS, CSRF, SQL-Injection, CVE: Das Update schließt eine Lücke. Warten erhöht Ihr Risiko, nicht das Einspielen.
• Removed, Deprecated, Breaking: Funktionen, Shortcodes, Hooks oder Einstellungen entfallen. Prüfen Sie, ob Ihre Website oder ein Zusatz-Plugin sie nutzt.
• Requires, minimum, PHP: Mindestanforderungen steigen, Details in Schritt 4.
• Database, migration, Datenbank: Das Update ändert Tabellen. Ein Rückschritt auf die alte Version reicht dann oft nicht, Sie brauchen das Datenbank-Backup.
• Integration, API, Payment: Anbindungen an Zahlungsanbieter, Newsletter-Dienste oder CRM ändern sich. Das betrifft Umsatz und Leads direkt.

Fehlt ein Änderungsprotokoll ganz oder steht dort über Jahre nur „Bug fixes“, ist das selbst ein Befund: Sie können das Risiko nicht einschätzen und sollten dieses Plugin eher auf einer Testkopie aktualisieren.

Verifizieren: Zu jedem Minor- oder Major-Update haben Sie eine kurze Notiz: Sicherheitskorrektur ja oder nein, entfernte Funktionen ja oder nein, Datenbankänderung ja oder nein.

Schritt 4: Kompatibilität und Mindestanforderungen prüfen

Plugins deklarieren im Kopf ihrer Hauptdatei die Felder „Requires at least“ (niedrigste WordPress-Version) und „Requires PHP“ (niedrigste PHP-Version), optional „Requires Plugins“ für Abhängigkeiten von anderen Plugins. So steht es im Plugin-Handbuch auf developer.wordpress.org. In der Detailansicht des Backends heißen die Felder „Erforderliche WordPress-Version“ und „Erforderliche PHP-Version“.

Erfüllt Ihr Server die PHP-Anforderung nicht, blendet WordPress den Link „jetzt aktualisieren“ aus und meldet sinngemäß, dass die neue Version nicht mit Ihrer PHP-Version kompatibel ist. Das ist ein Schutz, kein Fehler: Aktualisieren Sie zuerst PHP, dann das Plugin.

Das Feld „Tested up to“ in der readme.txt gibt an, mit welcher WordPress-Hauptversion der Autor getestet hat. Laut Handbuch ignoriert es die kleinen Versionen, weil Plugins bei Wartungsreleases nicht brechen sollen. Die Warnung, das Plugin sei nicht mit der aktuellen WordPress-Version getestet, bedeutet also nicht, dass es defekt ist, sondern dass der Autor keine Aussage gemacht hat. Wirklich kritisch ist die Kombination: Plugin seit langer Zeit ohne Aktualisierung, nicht getestet und geschäftskritisch.

Für die eigenen Versionen genügen zwei Befehle:

wp core version
wp eval 'echo PHP_VERSION . PHP_EOL;'

Prüfen Sie außerdem Zusatz-Plugins, die sich auf ein Haupt-Plugin beziehen, etwa Erweiterungen für Shop oder Formulare. Deren Änderungsprotokoll nennt oft, ab welcher Version des Haupt-Plugins sie arbeiten. Aktualisieren Sie das Haupt-Plugin zu früh, fällt die Erweiterung aus.

Verifizieren: Für jedes Update gilt: WordPress-Version und PHP-Version Ihres Servers liegen auf oder über den Anforderungen der Zielversion. Wo nicht, steht in Ihrer Liste die nötige Vorarbeit.

Schritt 5: Risiko bewerten und Reihenfolge festlegen

Aus den Schritten 2 bis 4 ergibt sich eine einfache Entscheidung. Zwei Fragen genügen: Wie groß ist die Änderung, und wie schlimm wäre ein Ausfall dieses Plugins für Ihr Geschäft?

Situation	Vorgehen
Sicherheitskorrektur, beliebiger Sprung	am selben Tag einspielen, vorher Backup
Patch ohne Befund	im nächsten regulären Update-Termin
Minor, Plugin nicht geschäftskritisch	Backup, einspielen, Funktion prüfen
Minor oder Major bei Shop, Formular, Zahlung, Mitgliederbereich	zuerst auf Staging testen, dann live außerhalb der Hauptgeschäftszeit
Anforderung nicht erfüllt	zurückstellen, zuerst PHP oder WordPress aktualisieren

Warten ist keine neutrale Option. Eine bekannte, geschlossene Lücke in einem verbreiteten Plugin ist ein beliebtes Angriffsziel, gerade weil viele Websites das Update nicht einspielen. Trade-off: Wer sehr früh aktualisiert, trifft eher auf Fehler der neuen Version. Ein bis zwei Tage Abstand bei reinen Funktionsupdates ohne Sicherheitsbezug sind deshalb vertretbar, bei Sicherheitskorrekturen nicht.

Für die Reihenfolge hat sich bewährt: erst WordPress-Core, dann Haupt-Plugins, dann deren Erweiterungen, zuletzt Themes und Übersetzungen. Spielen Sie Updates einzeln ein, nicht alle auf einmal. Bricht etwas, wissen Sie sofort, welches Update die Ursache war.

Diese Prüfung ist keine einmalige Aufgabe. Mit jedem zusätzlichen Plugin kommen regelmäßig neue Versionen hinzu, und jede verdient den kurzen Blick. Wer diese Routine nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate spielt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden an Werktagen mit Kompatibilitätsprüfung ein und legt wöchentliche Backups auf externem Speicher ab.

Verifizieren: Jedes Update in Ihrer Liste hat eine Entscheidung (sofort, regulär, erst Staging, zurückgestellt) und eine Position in der Reihenfolge.

Schritt 6: Backup anlegen und Entscheidung dokumentieren

Unmittelbar vor dem Einspielen sichern Sie Datenbank und Dateien. Die WordPress-Dokumentation zum Aktualisieren nennt das Backup ausdrücklich als ersten Schritt. Mit WP-CLI geht die Datenbanksicherung in einem Befehl; legen Sie die Datei außerhalb des öffentlich erreichbaren Webverzeichnisses ab und verschieben Sie sie danach auf einen anderen Speicher:

wp db export ~/backup/vor-update-$(date +%F).sql
ls -la ~/backup/

Halten Sie das Ergebnis Ihrer Prüfung in wenigen Zeilen fest. Das kostet eine Minute und hilft bei jeder Fehlersuche, weil Sie wissen, welche Version vorher lief:

Datum:        30.09.2026
Plugin:       Contact Form 7, 6.0 auf 6.1.7 (Minor)
Anforderung:  WordPress 6.7, PHP 7.4 (erfüllt: 7.1.2 / 8.4)
Changelog:    keine Sicherheitskorrektur gefunden, Details auf Herstellerseite gelesen
Entscheidung: nach Backup einspielen, danach Testformular absenden
Backup:       vor-update-2026-09-30.sql

Nach dem Update prüfen Sie genau die Funktionen, die Sie in Schritt 3 als betroffen notiert haben: Formular absenden, Testbestellung, Login. Treten Fehler auf, hilft die Anleitung zum WordPress-Debug-Modus und den Error-Logs bei der Ursachensuche.

Verifizieren: Die Backup-Datei existiert und ist größer als wenige Kilobyte (im Labor rund 100 KB bei einer leeren Testinstallation). Die Update-Notiz liegt dort, wo Sie sie wiederfinden.

Typische Fehler

• Nur den obersten Changelog-Eintrag gelesen: Bei größeren Sprüngen stehen die entscheidenden Änderungen oft in einer Zwischenversion. Lesen Sie alle Einträge ab Ihrer installierten Version.
• „Nicht getestet“ mit „inkompatibel“ verwechselt: Die Warnung beschreibt nur ein nicht aktualisiertes Feld „Tested up to“. Relevanter ist, wann das Plugin zuletzt aktualisiert wurde („Zuletzt aktualisiert“ in der Detailansicht).
• Falsche Versionsnummer beim gezielten Update: WP-CLI meldet dann Error: Can't find the requested plugin's version 9.9.9 in the WordPress.org plugin repository (HTTP code 404). Die verfügbaren Versionen stehen im Reiter „Änderungsprotokoll“ der Detailansicht.
• Alle Updates gleichzeitig eingespielt: Bricht danach etwas, ist die Ursache unklar. Einzeln aktualisieren und nach jedem Schritt kurz prüfen.
• Premium-Plugin ohne Changelog im Backend: Plugins außerhalb des WordPress.org-Verzeichnisses liefern Details über den Hersteller. Das Änderungsprotokoll steht dann meist auf dessen Website oder im Kundenkonto.

Häufige Fragen

Soll ich automatische Updates einschalten statt jedes Update zu prüfen?

Für unkritische Plugins mit guter Update-Historie ist das eine vertretbare Entlastung, unter „Plugins > Installierte Plugins“ über „Automatische Aktualisierungen aktivieren“. Bei Shop-, Formular- und Zahlungs-Plugins verlieren Sie damit die Kontrolle über den Zeitpunkt. Dort bleibt die manuelle Prüfung sinnvoll.

Wie lange sollte ich nach einem Release warten?

Bei Sicherheitskorrekturen gar nicht, sobald ein Backup vorliegt. Bei reinen Funktionsupdates schaffen ein bis zwei Tage Abstand Zeit, in der andere Anwender Fehler melden und der Autor gegebenenfalls ein Patch-Release nachschiebt.

Woran erkenne ich, dass ein Plugin aufgegeben wurde?

Die Detailansicht zeigt „Zuletzt aktualisiert“. Liegt das Datum weit zurück und ist das Plugin nicht mit aktuellen WordPress-Hauptversionen getestet, sollten Sie Ersatz suchen.

Testumfang

Wir haben das Vorgehen in einer Testinstanz mit WordPress 7.1.2 durchgespielt und Contact Form 7 per Probelauf und gezieltem Update aktualisiert. Fordern Sie eine Version an, die es nicht gibt, gibt WP-CLI eine Fehlermeldung aus. Premium-Plugins, Multisite und eine nicht erfüllte PHP-Anforderung haben wir nicht geprüft. Testen Sie Updates deshalb vorher auf einer Kopie Ihrer Seite.

Fazit

Eine Update-Prüfung braucht pro Plugin selten mehr als ein paar Minuten: Versionssprung einordnen, Änderungsprotokoll ab der installierten Version lesen, Anforderungen gegen den Server prüfen, Entscheidung und Backup festhalten. Damit spielen Sie Sicherheitskorrekturen schnell und große Umbauten kontrolliert ein, statt jedes Update gleich zu behandeln. Wenn Sie diese wiederkehrende Prüfung lieber abgeben, übernimmt die WordPress-Wartung von wordpressupdate Updates mit Kompatibilitätsprüfung und wöchentliche externe Backups.

Weiterführende Anleitungen und Quellen

• WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler beheben
• WordPress auf dem Synology NAS: eigene Website oder Staging-Umgebung
• WP-Cron durch echten System-Cron ersetzen
• WordPress-Dokumentation: Updating WordPress
• Plugin-Handbuch: Header Requirements
• Plugin-Handbuch: How Your Plugin Readme File Works
• WP-CLI-Handbuch: wp plugin update