Lohnt es sich, WordPress zu aktualisieren? Risiken, Sicherheit und Update-Strategien

Im täglichen Betrieb von Unternehmenswebsites begegnet man häufig zwei gegensätzlichen Lagern: Auf der einen Seite Administratoren, die jedes Update am Tag des Erscheinens ohne Vorabprüfung einspielen; auf der anderen Seite Website-Betreiber, die das WordPress-Backend aus Angst vor Systemabstürzen über Monate oder gar Jahre unberührt lassen, nach dem Motto: “Never touch a running system”.

Beide Extreme bergen erhebliche Risiken. Laut W3Techs läuft WordPress auf 40,0 Prozent aller Websites weltweit (abgerufen am 14.10.2026). Aufgrund dieser enormen Marktpräsenz scannen automatisierte Exploits das Web rund um die Uhr nach ungepatchten Sicherheitslücken ab. Wer Updates aufschiebt, spart keine Arbeitszeit, sondern baut technische Schulden auf, die bei einem Versionssprung oder einem Sicherheitsvorfall ein Vielfaches kosten.

Die richtige Frage lautet deshalb nicht “Lohnt es sich, WordPress zu aktualisieren”, sondern “Kann ich mir das Risiko leisten, Software mit bekannten Schwachstellen zu betreiben”. Die Kosten einer gehackten Website (SEO-Einbußen, Datenverlust, Bereinigungshonorare, Imageschaden) übersteigen die 15 bis 20 Minuten für ein sauber geführtes Update immer.

In diesem technischen Leitfaden analysieren wir, warum sich Updates strategisch lohnen, welche Unterschiede zwischen Core-, Plugin- und Theme-Releases bestehen, was WordPress inzwischen selbst bei fehlgeschlagenen Updates tut und wie Sie einen sicheren vierstufigen Update-Workflow etablieren.

Wenn Sie den Wartungsaufwand und das Ausfallrisiko an erfahrene Spezialisten delegieren möchten, informieren Sie sich über unsere Wartung von WordPress-basierten Websites.

#Wo Angreifer bei veralteten WordPress-Installationen ansetzen

Es ist ein weit verbreiteter Irrglaube, dass vor allem der WordPress-Kern (Core) unsicher sei. Der Jahresbericht von Patchstack zu 2024, State of WordPress Security in 2025, zählt 7966 neue Schwachstellen im WordPress-Ökosystem in diesem Jahr und zeichnet ein klares Bild:

Derselbe Bericht hält fest, dass 33 % der Schwachstellen zum Zeitpunkt der Veröffentlichung keinen Patch hatten, viele davon in aufgegebenen Plugins, die wahrscheinlich nie mehr korrigiert werden, und dass Lücken häufig schon wenige Stunden nach der Veröffentlichung ausgenutzt werden.

Sobald ein Sicherheits-Patch für ein populäres Plugin öffentlich erscheint, analysieren Angreifer die Code-Änderungen und füttern damit Bots, die Millionen von Websites nach der ungepatchten Version absuchen. Wenn eine Sicherheitslücke in einem Formular-Plugin oder einem Slider-Modul bekannt wird, sind nicht aktualisierte Websites schutzlos ausgeliefert. Angreifer nutzen SQL-Injections, Cross-Site Scripting (XSS) oder unautorisierte Datei-Uploads, um Backdoors zu installieren, Spam-Seiten einzuschleusen, Besucher auf schädliche Seiten umzuleiten oder sensible Kundendaten abzugreifen.

#Minor-Updates vs. Major-Updates im Core

WordPress unterscheidet sauber zwischen zwei Release-Typen:

1. Minor-Releases (z. B. 6.6.1 auf 6.6.2): Diese Versionen enthalten Fehlerbehebungen und dringende Sicherheitspatches. Seit WordPress 3.7 werden Minor-Updates standardmäßig im Hintergrund automatisch eingespielt. Diese Funktion sollte in fast allen Szenarien aktiv bleiben, da sie das Zeitfenster für Angreifer minimiert.
2. Major-Releases (z. B. 6.5 auf 6.6): Diese Releases bringen neue Core-Funktionen, Änderungen an der Block-Editor-API und gelegentlich veraltete Funktionen (Deprecations) mit sich. Major-Updates sollten niemals ungetestet direkt im Produktivbetrieb aktiviert werden.

#Welche WordPress-Versionen noch Sicherheitsupdates bekommen

Die Sicherheitsseite von WordPress.org (About security) stellt klar, dass offiziell nur die jeweils neueste WordPress-Version unterstützt wird. Das Sicherheitsteam portiert Korrekturen aus Kulanz auf ältere Zweige zurück, damit auch Websites, die noch nicht auf das neueste Major-Release gewechselt sind, kritische Patches über die automatischen Updates erhalten.

Zwei datierte Beispiele zeigen, wie das in der Praxis aussieht:

• WordPress 6.4.3 (30. Januar 2024) schloss eine Umgehung der PHP-Datei-Upload-Sperre über den Plugin-Installer (Administratorrechte erforderlich) und eine RCE-Schwachstelle über POP-Chains. Dazu kamen 5 Core- und 16 Block-Editor-Bugfixes; die Patches wurden auf alle Zweige ab 4.1 zurückportiert (Release-Ankündigung).
• WordPress 6.5.5 (24. Juni 2024) behob zwei XSS-Schwachstellen (in der HTML API und im Template-Part-Block) sowie ein Path-Traversal-Problem auf Windows-Servern (Release-Ankündigung).

Beide Ankündigungen weisen darauf hin, dass der Update-Prozess auf Websites mit automatischen Hintergrund-Updates von selbst startet. Das ist das stärkste Argument dafür, Minor-Updates nie abzuschalten: Der Patch kommt an, auch wenn sich niemand ins Backend einloggt.

#Wie Updates, Core Web Vitals und PHP-Kompatibilität zusammenhängen

Ein weiterer entscheidender Faktor für regelmäßige Updates ist die Ausführungsgeschwindigkeit. WordPress investiert über das Core Performance Team kontinuierlich in die Kernleistung:

• Optimierte Datenbankabfragen: Major-Releases verfeinern regelmäßig Abfragen und Object-Caching.
• Verbesserte Ladezeiten: Modernes Script-Loading und optimierte Bildverarbeitung verbessern die Core Web Vitals messbar, etwa die native AVIF-Unterstützung ab WordPress 6.5. Wie sich das messen lässt, zeigt unser Core-Web-Vitals-Audit.
• Unterstützung moderner PHP-Versionen: Webhosting-Anbieter schalten veraltete PHP-Versionen (wie PHP 7.4 oder 8.0) regelmäßig ab. Ältere WordPress- und WooCommerce-Versionen sind jedoch nicht mit PHP 8.2 oder 8.3 kompatibel. Wer seine Website nicht schrittweise aktualisiert, erlebt beim Zwangsupgrade des Hosters den gefürchteten Fatal Error (“White Screen of Death”).

Moderne PHP-8.x-Zweige bringen zudem Verbesserungen an Engine und Speicherverwaltung, die sich in Anwendungen wie WordPress bemerkbar machen. Wer auf alten Versionen bleibt, betreibt freiwillig langsameren Code.

Außerdem stellen populäre Plugins und Themes irgendwann die Unterstützung alter WordPress-Versionen ein. Dann lassen sich auch die Plugins nicht mehr aktualisieren, und es entsteht ein Dominoeffekt, bei dem jede Komponente der Website schrittweise veraltet und angreifbarer wird.

#Welche PHP-Version Sie 2026 mit WordPress betreiben sollten

Die Anforderungsseite von WordPress empfiehlt PHP 8.3 oder höher, MySQL 8.0 oder MariaDB 10.11 oder höher sowie HTTPS. Das technische Minimum liegt niedriger: Die Versions-API von WordPress.org bietet WordPress 7.1.3 mit einem Minimum von PHP 7.4 an. Dass WordPress auf PHP 7.4 startet, macht dieses PHP aber nicht sicher. Der offizielle PHP-Zeitplan (unterstützte Versionen und nicht mehr unterstützte Zweige) sieht so aus:

Im Oktober 2026 heißt das: PHP 8.1 erhält keine Patches mehr, PHP 8.2 nur noch bis zum Jahresende. Eine Website, die heute auf 8.2 läuft, sollte den Wechsel auf 8.3 oder 8.4 jetzt auf Staging planen. Die praktische Reihenfolge: WordPress, Plugins und Theme auf Versionen bringen, die Kompatibilität deklarieren, auf Staging mit der neuen PHP-Version testen und erst dann PHP in der Produktion umstellen.

#Wie ein sicheres WordPress-Update in vier Stufen abläuft

Um maximale Stabilität zu garantieren, empfiehlt sich ein strukturierter Ablauf, der menschliche Fehler minimiert und jederzeit eine sofortige Rückkehr zum funktionierenden Zustand erlaubt:

#Stufe 1: Vollständige Datensicherung (Backup)

Vor jedem Klick auf “Aktualisieren” muss ein vollständiges, konsistentes Backup existieren. Dies umfasst:

• Die SQL-Datenbank (inklusive aller Tabellen und Zeichensätze).
• Das Verzeichnis /wp-content/ (insbesondere uploads, plugins und themes).

Verlassen Sie sich nicht allein auf monatliche Host-Backups. Erstellen Sie vor dem Wartungsfenster einen frischen Snapshot. Ein Backup ist nur so viel wert wie seine Wiederherstellung: Planen Sie mindestens einmal pro Quartal eine Test-Wiederherstellung ein.

#Stufe 2: Prüfung auf der Staging-Umgebung

Kritische Websites (wie Onlineshops oder B2B-Lead-Portale) sollten niemals direkt im Produktivsystem aktualisiert werden. Eine ausführliche Anleitung finden Sie in unserem Staging-Workflow:

1. Klonen Sie die Live-Website auf eine identisch konfigurierte Staging-Instanz (Subdomain mit Passwortschutz).
2. Führen Sie alle anstehenden Updates (Core, Plugins, Theme) in der Staging-Umgebung durch, und zwar einzeln: zuerst der Core, dann kritische Plugins wie Cache, Sicherheit und SEO, danach die übrigen Plugins und zum Schluss das Theme.
3. Aktivieren Sie den WordPress-Debug-Modus in der wp-config.php:

// Debugging-Konfiguration für Staging
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', '0');

4. Überprüfen Sie das Fehlerprotokoll unter /wp-content/debug.log auf PHP-Fatal-Errors, Warnungen oder veraltete Funktionsaufrufe, und kontrollieren Sie nach jedem einzelnen Update die Browser-Konsole (F12) auf JavaScript-Fehler.

Klicken Sie nie auf “Alle aktualisieren”. Wer Plugins einzeln aktualisiert, weiß bei einem Fehler sofort, welches Plugin der Auslöser war.

#Stufe 3: Funktions- und Regressionstests

Nach dem Update auf Staging erfolgt der Funktionstest der Kernprozesse:

• Funktioniert der Warenkorb und der Checkout-Prozess bis zum Zahlungsanbieter?
• Werden Kontaktformulare korrekt versendet und im CRM erfasst?
• Gibt es Layout-Verschiebungen (CLS) durch verändertes Plugin-CSS?
• Sind alle individuellen Code-Anpassungen im Child-Theme weiterhin aktiv?

Bei geschäftskritischen Websites reicht ein kurzer Blick nicht. Werkzeuge für visuelle Regressionstests wie Percy oder BackstopJS vergleichen Screenshots vor und nach dem Update und finden pixelgenaue Abweichungen, die man beim Durchklicken übersieht. Das ist besonders wichtig nach Updates von Themes oder Page Buildern wie Elementor, Divi oder WPBakery, weil diese das Erscheinungsbild jeder Seite steuern.

#Stufe 4: Produktiv-Rollout im Wartungsfenster

Sind alle Tests auf Staging erfolgreich durchlaufen, wird das Update im Produktivsystem eingespielt:

• Wählen Sie ein Zeitfenster mit geringem Besucheraufkommen (z. B. spätabends oder am frühen Sonntagmorgen).
• Aktivieren Sie kurzzeitig den Wartungsmodus.
• Führen Sie das Update durch und validieren Sie die Kernseiten.
• Beobachten Sie Server-Logs, Traffic-Statistiken und Fehlerberichte in den folgenden 24 bis 48 Stunden.

#Was WordPress bei einem fehlgeschlagenen Plugin-Update tut

Seit einigen Versionen hat der Core zwei eigene Sicherheitsnetze für Updates von Erweiterungen. Es lohnt sich zu wissen, was sie abdecken und was nicht, denn keines ersetzt das Backup.

WordPress 6.3: Wiederherstellung nach einem fehlgeschlagenen manuellen Update. Laut Dev-Note zu 6.3 verschiebt WordPress vor dem Update eines Plugins oder Themes die installierte Version nach wp-content/upgrade-temp-backup/plugins/ bzw. wp-content/upgrade-temp-backup/themes/. Schlägt die Installation des Pakets fehl (leeres Paket, Zielordner lässt sich nicht leeren oder anlegen), wird die vorherige Version zurückverschoben. Ist das Update erfolgreich, wird die Sicherung gelöscht. Einen PHP-Fatal-Error, der erst nach erfolgreicher Installation auftritt, erkennt diese Funktion nicht, und der Ordner taugt nicht für ein späteres Zurückrollen.

WordPress 6.6: Rollback automatischer Plugin-Updates. Der Field Guide zu 6.6 nennt das automatische Zurückrollen von Plugin-Auto-Updates bei erkannten PHP-Fatal-Errors. Der Merge-Vorschlag beschreibt den Mechanismus: Nach dem Update sendet WordPress einen Loopback-Request an die Startseite; erkennt es dabei einen Fatal Error, stellt es die vorherige Plugin-Version wieder her und benachrichtigt die Admin-E-Mail-Adresse. Während der automatischen Updates bleibt die Website im Wartungsmodus, und das zurückgerollte Plugin wird bei der nächsten Update-Prüfung erneut versucht.

Die wichtige Einschränkung ist der Loopback-Request selbst. Blockiert der Server ihn (etwa durch eine Firewall-Regel oder HTTP-Authentifizierung), wird das laut Vorschlag wie ein Fatal Error behandelt und das Update zurückgerollt. Ein Plugin, das nur den Checkout oder eine Unterseite beschädigt, bleibt ebenfalls unbemerkt, weil nur die Startseite geprüft wird. Deshalb brauchen Shops weiterhin manuelle Checkout-Tests.

#Wie Sie automatische WordPress-Updates konfigurieren

Die offizielle Dokumentation (Upgrading WordPress) erklärt, dass automatische Hintergrund-Updates mit WordPress 3.7 eingeführt wurden, und unterscheidet vier Typen: Core (Entwicklungs-, Minor- und Major-Versionen), Plugins, Themes und Übersetzungsdateien.

Die Standardeinstellungen:

• Minor-Core-Updates und Übersetzungen sind standardmäßig aktiv.
• Seit WordPress 5.6 erhalten Neuinstallationen auch Major-Versionen automatisch, sofern kein Versionskontroll-Checkout erkannt wird.
• Plugins und Themes aktualisieren sich nur in Sonderfällen selbst, über die die WordPress.org-API entscheidet, oder wenn der Administrator es einschaltet.

Diesen Schalter pro Plugin und Theme gibt es seit WordPress 5.5, erschienen am 11. August 2020: Seitdem lassen sich automatische Updates für jede Erweiterung direkt in den Ansichten Plugins und Themes ein- und ausschalten (Release-Ankündigung 5.5).

Um die Richtlinie im Code festzuschreiben, akzeptiert die wp-config.php folgende Konstanten:

// Nur Minor-Core-Updates (Sicherheit und Wartung)
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// true: Entwicklungs-, Minor- und Major-Updates; false: keines davon
// define( 'WP_AUTO_UPDATE_CORE', true );

// Deaktiviert alle automatischen Updates (nicht empfohlen)
// define( 'AUTOMATIC_UPDATER_DISABLED', true );

Für feinere Steuerung gibt es die Filter auto_update_plugin und auto_update_theme, für den Core allow_major_auto_core_updates und allow_minor_auto_core_updates. Eine sinnvolle Konfiguration für einen Shop: WP_AUTO_UPDATE_CORE auf 'minor', Auto-Updates nur für risikoarme Plugins, alles rund um Zahlungen und Bestellungen manuell nach Staging. Wer mit AUTOMATIC_UPDATER_DISABLED alles abschaltet, schneidet die Website von genau den Patches ab, die das Sicherheitsteam über diesen Kanal verteilt.

#Wie Sie WordPress-Updates effizient mit WP-CLI verwalten

Für Entwickler und Administratoren ist die Befehlszeilenschnittstelle WP-CLI das verlässlichste Werkzeug. Sie spart Zeit und ermöglicht eine präzise Versionskontrolle:

# 1. Verfügbare Updates für den Core und Plugins auflisten
wp core check-update
wp plugin list --update=available

# 2. Schneller Datenbankexport vor Beginn
wp db export pre-update-backup-$(date +%Y%m%d%H%M).sql

# 3. Einzelnes Plugin gezielt aktualisieren
wp plugin update woocommerce

# 4. Falls ein Fehler auftritt: Gezielter Rollback auf Vorversion
wp plugin update woocommerce --version=9.1.2

# 5. Caches nach erfolgreichem Update leeren
wp cache flush

Mit WP-CLI lässt sich auch der Zustand nach einem Update binnen Sekunden überprüfen: wp plugin list --status=active zeigt sofort an, ob alle erforderlichen Module ordnungsgemäß geladen sind. Für den Weg zurück auf eine frühere Core-Version gibt es eine eigene Anleitung: frühere WordPress-Version wiederherstellen.

#Mehrere WordPress-Websites gleichzeitig aktualisieren

Wer viele Websites betreut, kann nicht jede einzeln von Hand pflegen. Diese Werkzeuge bündeln die Update-Verwaltung:

• ManageWP verwaltet Updates von Dutzenden oder Hunderten Websites in einem Dashboard, mit automatischem Backup vor jedem Update und visueller Prüfung danach.
• MainWP ist eine selbst gehostete Alternative, die als Plugin auf einer zentralen WordPress-Installation läuft und die Updates aller angebundenen Websites steuert.
• InfiniteWP bietet ähnliche Funktionen mit Fokus auf Agenturen mit vielen Websites.

Diese Werkzeuge erlauben geplante und selektive Updates, Kundenberichte und das Zurückrollen von Änderungen, wenn etwas schiefgeht.

#Was passiert, wenn Sie WordPress nicht aktualisieren

#Szenario 1: Gehackte Website mit SEO-Spam

Einer der häufigsten Angriffe auf veraltete WordPress-Websites ist das Einschleusen von SEO-Spam-Seiten. Angreifer legen Tausende versteckte Seiten an, die Arzneimittel, Raubkopien oder Glücksspiel bewerben. Google indexiert diese Seiten und bringt Ihre Domain mit Spam in Verbindung.

Die Folge kann eine manuelle Maßnahme von Google oder ein starker Einbruch des organischen Traffics sein. Die Erholung erfordert eine vollständige technische Bereinigung, einen Antrag auf erneute Überprüfung und Wochen oder Monate Wartezeit, bis die Suchmaschine der Domain wieder vertraut.

#Szenario 2: Datenleck in WooCommerce

Ein nicht aktualisierter WooCommerce-Shop kann Lücken haben, über die Angreifer an die Kundendatenbank gelangen. Namen, Adressen, E-Mails und sogar Teile von Zahlungsdaten können offengelegt werden. Neben den Pflichten aus der DSGVO (Bußgelder bis zu 4 % des weltweiten Jahresumsatzes) ist der Imageschaden schwer zu beziffern.

#Szenario 3: Website komplett offline

Im schlimmsten Fall übernimmt ein Angreifer den Server vollständig, löscht kritische Dateien und legt die Website lahm. Ohne aktuelles Backup kann der Wiederaufbau Tage oder Wochen dauern, mit Verlust von Inhalten, Konfiguration und Kundendaten.

#Wie sich fehlende Updates auf SEO auswirken

Google hat bestätigt, dass die Page Experience, einschließlich der Geschwindigkeit, zu den Ranking-Signalen gehört. Alte WordPress-Versionen auf veraltetem PHP sind langsamer. Das wirkt sich auf die Core Web Vitals aus, vor allem auf LCP (Largest Contentful Paint) und INP (Interaction to Next Paint).

Eine Website, die wegen fehlender Updates gehackt wurde, kann zudem in den Google-Suchergebnissen als kompromittiert markiert werden, was die Klickrate einbrechen lässt. Moderne Browser zeigen Sicherheitswarnungen an, wenn sie Malware erkennen, und vertreiben Besucher, bevor diese den Inhalt überhaupt sehen.

#Was neuere WordPress-Versionen hinzugefügt haben

Wer mehrere Versionen zurückliegt, verliert nicht nur Patches. Einige Änderungen mit Datum und offizieller Quelle:

• WordPress 6.5 (2024) brachte AVIF-Unterstützung: AVIF-Bilder lassen sich hochladen, bearbeiten, skalieren und speichern, sofern die Bildbibliothek des Servers (Imagick oder GD) sie unterstützt; Site Health zeigt an, ob das der Fall ist (Dev-Note).
• WordPress 6.6 (16. Juli 2024) führte das oben beschriebene automatische Zurückrollen von Plugin-Auto-Updates ein.
• WordPress 6.8 (2025) aktivierte Speculative Loading im Frontend: Der Core lädt URLs per Prefetch mit konservativer Eagerness vor, außer für angemeldete Nutzer oder Websites ohne sprechende Permalinks; das Verhalten lässt sich mit dem Filter wp_speculation_rules_configuration anpassen (Dev-Note).
• WordPress 6.9 (Dezember 2025) führte die Abilities API ein, ein Register, in dem Core und Plugins mit Schemas und Berechtigungsprüfung festlegen, welche Aktionen sie ausführen können.

Moderne Plugins bauen zunehmend auf diesen APIs auf. Eine Website, die auf einer alten Version festhängt, kann solche Plugins irgendwann nicht mehr aktualisieren und verliert damit auch deren Sicherheitskorrekturen.

#Wie Sie mit Abandoned Software und verwaisten Plugins umgehen

Ein häufiger Grund, warum Betreiber Updates aufschieben, ist ein veraltetes Plugin, das seit mehreren Jahren keine Aktualisierungen mehr erhalten hat. Wird der WordPress-Core aktualisiert, bricht das verwaiste Plugin zusammen.

Ignorieren ist hier die denkbar schlechteste Lösung. Die Patchstack-Zahlen oben zeigen, warum: Ein großer Teil der ungepatchten Lücken steckt in aufgegebenen Plugins. Ein Plugin, das seit mehr als 18 Monaten nicht aktualisiert wurde, ist ein unkalkulierbares Sicherheitsrisiko. In solchen Fällen sollten Sie folgende Schritte einleiten:

1. Bedarfsprüfung: Wird die Funktion des Plugins überhaupt noch benötigt? Viele ältere Plugins lösen Probleme, die modernes WordPress heute nativ beherrscht (wie XML-Sitemaps oder Lazy-Loading von Bildern).
2. Ersatz finden: Suchen Sie nach aktiven, modernen Alternativen im offiziellen WordPress-Verzeichnis mit guter Wartungshistorie.
3. Individuelle Neuentwicklung: Handelt es sich um geschäftskritische Speziallogik, sollte die Funktion von einem spezialisierten Entwickler als sauberes, schlankes Modul neu programmiert werden.

#Wie oft Sie WordPress aktualisieren sollten

Sicherheitsrelevante Minor-Updates sollten unverzüglich, am besten automatisiert, eingespielt werden: kritische Patches innerhalb von 24 bis 48 Stunden. Für reguläre Plugin-Updates empfiehlt sich ein fester zweiwöchentlicher oder monatlicher Rhythmus innerhalb eines definierten Wartungsfensters, damit sich mehrere Updates gemeinsam auf Staging testen lassen. Bei Major-Releases des Core ist es vernünftig, ein bis zwei Wochen abzuwarten, bis die Community erste Probleme gemeldet hat und Plugin-Entwickler Kompatibilitäts-Updates veröffentlicht haben. Bei Premium-Themes lesen Sie vor dem Update das Changelog, weil integrierte Page Builder das Verhalten bestehender Komponenten ändern können.

#Fazit

Regelmäßige Updates sind kein lästiges Übel, sondern das Fundament einer professionellen, schnellen und sicheren Webpräsenz. Wer strukturierte Prozesse etabliert, minimiert Ausfallrisiken und schützt sein Unternehmen vor teuren Datenverlusten. Wenn Sie Unterstützung bei der Absicherung und Modernisierung Ihrer Infrastruktur suchen, sprechen Sie mit einem erfahrenen WordPress-Entwickler.