WordPress-Updates erledige ich im Rahmen der Wartung nach einem festen Zeitplan: zuerst ein vollständiges Backup, dann das Update auf einer Testkopie der Website (Staging), Tests, ein Vergleich der Screenshots vor und nach der Änderung und erst dann die Veröffentlichung auf der Live-Website in einem vereinbarten Fenster. Ich installiere nicht automatisch jede neue Version. Kritische Sicherheitskorrekturen gehen außerhalb der Reihe durch, aber ebenfalls über Staging.
Diese Seite beschreibt, wie oft ich was aktualisiere, wie eine Update-Runde abläuft, was ich tue, wenn nach einem Update etwas nicht mehr funktioniert, und wie Updates in einem Shop mit Schnittstellen, auf einem Page Builder und in Systemen außerhalb von WordPress aussehen. Die gesamte Wartung mit Backups und Monitoring beschreibt die Seite WordPress-Wartung.
Wie oft ich WordPress aktualisiere
Zeitplan für die Wartung einer Website. Für einen Shop lege ich die Fenster gesondert fest.
Wöchentlich
- Kleine Korrekturen und Sicherheitsupdates für Core, Plugins und Themes
- Update per WP-CLI auf einem Staging-Klon
- Test der wichtigsten Abläufe und Screenshot-Vergleich
- Veröffentlichung auf der Live-Website im vereinbarten Fenster
Monatlich
- Prüfung der Hauptversionen von Plugins und ihrer Changelogs
- Entscheidung: jetzt aktualisieren oder Version zurückhalten
- Prüfung der Administratorkonten
- Messung der Core Web Vitals nach den Änderungen
Quartalsweise und halbjährlich
- Quartalsweise: Prüfung der Plugin-Liste, verwaiste Plugins entfernen
- Halbjährlich: Sicherheitsprüfung von Dateiintegrität, Administratorkonten, Berechtigungen und offenen Endpunkten
- Halbjährlich: Abgleich von Staging und Live-Website
- Wechsel auf eine neuere PHP-Version: nach Plan, sobald Plugins und Theme bereit sind
Sicherheitsupdates außerhalb des Zeitplans
Eine kritische Sicherheitskorrektur wartet nicht auf den Wochenzyklus. Sie geht zuerst durch, einzeln, aber auf demselben Weg: Backup, Staging, Test, Veröffentlichung. Das genaue Fenster für solche Korrekturen schreibe ich ins Angebot, weil es davon abhängt, welche Reaktionszeit Ihr Plan umfasst.
Von Sicherheitslücken erfahre ich aus Schwachstellendatenbanken, unter anderem Patchstack und WPScan. Taucht dort eine Lücke in einem Plugin auf, das auf Ihrer Website läuft, prüfe ich, ob es schon eine korrigierte Version gibt und ob die Lücke Ihre Konfiguration betrifft.
Das Sicherheitsteam von WordPress besteht laut eigener Darstellung aus mehr als 50 vertrauenswürdigen Fachleuten, darunter leitende Entwickler und Sicherheitsforscher. Nach derselben Seite wird offiziell nur die neueste WordPress-Version unterstützt, Korrekturen für ältere Zweige portiert das Team aus Kulanz zurück. Eine Website, die einige Versionen zurückliegt, kann also ohne Korrektur bleiben.
So läuft eine Update-Runde ab
Dieselbe Reihenfolge für Core, Plugins, Themes und PHP. Es ändert sich nur der Umfang der Tests.
Vollständiges Backup
Vor jeder Änderung sichere ich Datenbank und Dateien vollständig. Das Backup ist der Rückweg, falls auf der Live-Website etwas schiefgeht.
Update auf Staging
Updates gehen zuerst per WP-CLI auf einen Klon der Website. Hauptversionen von Plugins kommen erst nach dem Lesen des Changelogs dran.
Tests auf dem Klon
Ich prüfe die wichtigsten Abläufe: Formulare, Login, im Shop Warenkorb und Zahlung. Besteht ein Test nicht, geht die Änderung nicht weiter.
Screenshot-Vergleich
Ich erstelle Screenshots ausgewählter Unterseiten vor und nach dem Update und vergleiche sie. Ein verschobenes Layout, ein fehlender Button oder eine andere Schrift fällt hier auf, bevor ein Besucher es sieht.
Veröffentlichung im Wartungsfenster
Die Änderung geht im vereinbarten Fenster live, mit Snapshot und fertigem Rückfallplan.
Beobachtung nach der Veröffentlichung
24 Stunden nach der Veröffentlichung beobachte ich die Website verstärkt auf Nebenwirkungen. Das Uptime-Monitoring prüft sie alle 1 bis 5 Minuten.
Eintrag im Bericht
Updates, gefundene Fehler und zurückgenommene Änderungen stehen im Monatsbericht.
Ein Beispiel aus diesem Jahr: WP Rocket 3.23.2.2 lief zuerst auf dem Klon, bevor ich die Website auf WordPress 7.1 gehoben habe. Den Fehler und die Umgehung beschreibt der Beitrag WP Rocket, Fatal Error unter WordPress 7.1 und Cloudflare.php.
Screenshot-Vergleich nach dem Update
Ein Funktionstest prüft, ob das Formular abgeschickt wird und der Warenkorb ein Produkt annimmt. Er bemerkt nicht, dass nach einem Theme-Update der Header auf dem Smartphone das Menü verdeckt oder der Page Builder die Abstände im Preisbereich verändert hat. Deshalb vergleiche ich nach jedem Update Screenshots ausgewählter Unterseiten von vor und nach der Änderung. Welche Unterseiten in den Vergleich kommen, legen wir zu Beginn der Wartung fest: Startseite, die wichtigsten Leistungsseiten, das Formular, im Shop Produktseite, Warenkorb und Bestellabschluss. Auch das Cookie-Banner gehört auf die Liste, weil ein Update des Consent-Plugins es unbemerkt verschwinden lassen kann.
Zeigt der Vergleich einen Unterschied, prüfe ich, ob er aus einer geplanten Änderung stammt. Wenn nicht, bleibt das Update auf Staging, und ich suche die Ursache. Live geht erst eine Version, die gleich aussieht oder deren Unterschiede Sie kennen.
PHP-Update im Wartungsvertrag
Der Wechsel auf eine neuere PHP-Version ist Teil der Wartung, ohne eigenes Angebot. Ich plane ihn mit Vorlauf, weil er von drei Dingen abhängt: ob der Hoster die neuere Version anbietet, ob alle Plugins und das Theme sie unterstützen und ob eigener Code der Website Funktionen nutzt, die es in der neueren PHP-Version nicht mehr gibt. Zuerst läuft ein Klon der Website auf der neueren Version, dann folgen Tests und Screenshot-Vergleich, und erst dann stelle ich die Version auf der Live-Website um, im vereinbarten Fenster.
WordPress empfiehlt PHP 8.3 oder neuer, MariaDB 10.11 oder MySQL 8.0 und HTTPS. Laut dem Versionsdienst von WordPress.org liegt die Mindestversion von PHP für das aktuelle WordPress bei 7.4. Den PHP-Wechsel verbinde ich mit einer Prüfung der Plugin-Liste, denn ein Plugin ohne Update seit langer Zeit ist der erste Kandidat für einen Fehler unter der neueren Version.
WordPress nach Update kaputt: was ich dann tue
Die häufigsten Symptome nach einem Update von Core, Plugin, Theme oder PHP.
- Symptom: Kritischer Fehler oder weiße Seite nach einem Plugin-Update
- Was ich tueIch gehe per Snapshot auf den Stand vor der Änderung zurück. Die Ursache suche ich auf dem Klon, die korrigierte Version geht im nächsten Fenster live.
- Symptom: Eine Unterseite sieht anders aus als vor dem Update
- Was ich tueDer Screenshot-Vergleich hält so eine Änderung auf Staging fest. Ist der Unterschied doch live gegangen, nehme ich das Update zurück und korrigiere das Styling oder halte die Version zurück.
- Symptom: Warenkorb oder Zahlung im Shop funktionieren nicht mehr
- Was ich tueEine Änderung, die den Checkout-Test nicht bestanden hat, veröffentliche ich nicht. Zeigt sich der Fehler erst live, nehme ich das Update zurück und gehe zurück auf Staging.
- Symptom: Bestellungen kommen nicht mehr in der Warenwirtschaft oder Buchhaltung an
- Was ich tueIch prüfe auf Staging den Datenaustausch zwischen Shop und dem anderen System und halte die Version des Konnektors zurück, bis die Daten korrekt durchlaufen.
- Symptom: Das Cookie-Banner fehlt nach einem Update
- Was ich tueIch nehme das Update des Consent-Plugins zurück, prüfe auf Staging, warum das Banner nicht mehr eingebunden wird, und gebe Ihnen Bescheid, seit wann es fehlte.
- Symptom: Eine neue Plugin-Version verlangt Änderungen am Theme-Code
- Was ich tueIch halte die Version zurück und beschreibe, was umgebaut werden muss. Der Umbau liegt außerhalb der Wartung und bekommt ein eigenes Angebot.
- Symptom: Der Autor entwickelt ein Plugin nicht mehr weiter
- Was ich tueBei der quartalsweisen Prüfung der Plugin-Liste schlage ich Ersatz oder Entfernung vor.
- Symptom: Die Website hat sich über Nacht verändert, ohne dass jemand etwas entschieden hat
- Was ich tueIch prüfe, welche automatischen Updates aktiv sind, und stelle sie so ein, dass kritische Teile über Staging gehen.
Updates im Shop mit Zahlungsanbieter, Warenwirtschaft und E-Rechnung
In einem WooCommerce-Shop betrifft ein Update mehr als den Shop selbst. Zahlungsanbieter, Versand-Plugin, Konnektor zur Warenwirtschaft und Rechnungs-Plugin haben eigene Autoren und einen eigenen Release-Rhythmus, und jedes davon spricht mit einem System außerhalb Ihres Servers. Nach dem Update eines solchen Konnektors prüfe ich auf Staging, ob die Daten weiter in beide Richtungen fließen: Die Bestellung kommt in der Warenwirtschaft an, der Lagerbestand kommt zurück in den Shop, die Rechnung entsteht.
Die E-Rechnung ist dafür ein gutes Beispiel. Seit dem 1. Januar 2025 müssen inländische Unternehmen E-Rechnungen empfangen können, für das Ausstellen an Firmenkunden laufen Übergangsfristen bis Ende 2026 oder Ende 2027, wie die FAQ des Bundesfinanzministeriums erklären. WooCommerce erzeugt selbst keine Rechnungen. Die XRechnung oder ZUGFeRD-Datei kommt aus einem Plugin, einem Rechnungsdienst oder dem ERP, was der Beitrag E-Rechnung im WooCommerce-Shop beschreibt. Das Update eines solchen Plugins läuft über Staging wie jedes andere, aber der Test umfasst eine Testrechnung in der Testumgebung des Anbieters. Die Architektur der Verbindungen zwischen Shop und anderen Systemen beschreibe ich in den Leitfäden WooCommerce-ERP-Integration und WordPress API-first.
Zahlungsanbieter teste ich mit dem Ablauf Warenkorb, Daten, Versand, Zahlung, ohne echte Bestellung. Einen Shop, in dem das ständig geschehen soll und nicht nur nach einem Update, betreue ich im Store Reliability Plan. Dort hängt der Update-Rhythmus von der Stufe ab: von monatlichen Updates über Staging über Updates alle zwei Wochen bis zu einem wöchentlichen Update-Fenster.
Typisches Szenario: Shop mit Zahlungsanbieter und Konnektor zur Buchhaltung
Ein typischer Shop, mit dem Inhaber zu mir kommen, hat einen Zahlungsanbieter, ein Versand-Plugin, ein Rechnungs-Plugin mit Anbindung an die Buchhaltung und ein gutes Dutzend weiterer Plugins. In einer Woche können WooCommerce und das Plugin des Zahlungsanbieters gleichzeitig ein Update bekommen. Dann aktualisiere ich sie getrennt, innerhalb derselben Woche: zuerst WooCommerce, Test von Warenkorb und Rechnung, dann den Zahlungsanbieter, wieder Test. Geht etwas schief, ist sofort klar, welche Änderung es verursacht hat.
Updates auf Page-Builder-Websites
Websites auf Elementor, Divi oder WPBakery haben eine zusätzliche Schicht, die aktualisiert werden muss: den Builder selbst, seine Erweiterungen und oft ein eigenes Theme. Der Builder speichert das Layout in seinem eigenen Format, deshalb kann sein Update das Aussehen vieler Unterseiten auf einmal ändern. Die Unterschiede der Builder beschreibe ich im Beitrag Gutenberg, Elementor, Divi und WPBakery im Vergleich.
Eine typische Firmenwebsite mit 30 Plugins und Page Builder bekommt in den meisten Wochen mehrere Updates. Dort leistet der Screenshot-Vergleich die meiste Arbeit, weil der Funktionstest auch dann besteht, wenn ein Bereich auf der Startseite verrutscht.
WordPress selbst aktualisieren oder beauftragen
Die Antwort hängt davon ab, was auf Ihrer Website kaputtgeht, wenn ein Update scheitert.
Sie haben eine einfache Website mit wenigen Plugins, ein funktionierendes Backup und Zeit, die Website nach dem Update durchzusehen.
Sie können selbst aktualisieren. Sichern Sie vor jedem Update und lassen Sie kleinere Core-Updates automatisch laufen.
Die Website läuft auf einem Page Builder und hat Dutzende Plugins.
Updates über Staging mit Screenshot-Vergleich, in der Wartung der Firmenwebsite.
Sie betreiben einen Shop mit Zahlungsanbieter, Warenwirtschaft oder E-Rechnung.
Die Website liegt mehrere WordPress- oder PHP-Versionen zurück.
Beginnen Sie mit dem Startaudit der Wartung. Der Plan bis zu aktuellen Versionen ist sein Ergebnis.
Ein Update hat die Website schon beschädigt, und Sie haben keinen Wartungsvertrag.
Automatische Updates in WordPress und Updates im Wartungsvertrag
WordPress kann sich selbst aktualisieren. Laut der Dokumentation für Administratoren erhalten bestehende Installationen standardmäßig kleinere Core-Updates automatisch, neue Installationen ab Version 5.6 erhalten kleinere und große. Das Verhalten steuert die Konstante WP_AUTO_UPDATE_CORE in der Datei wp-config.php: Der Wert 'minor' lässt nur kleinere Updates zu, der Wert true schaltet alle ein.
Plugins und Themes funktionieren anders. Seit WordPress 5.5 aktiviert der Administrator automatische Updates einzeln für jedes Plugin und jedes Theme. Laut derselben Seite führt WordPress sie zweimal täglich aus und stützt sich dabei auf WP-Cron.
Ein automatisches Update installiert die neue Version ohne Backup und ohne Test auf Staging. Bei kleinen Core-Korrekturen ist das ein vertretbares Risiko. Für einen Shop, ein Zahlungs-Plugin oder ein Plugin, von dem das Bestellformular abhängt, ist es zu groß. In der Wartung lasse ich die Automatik deshalb dort, wo die Änderung klein ist, und führe kritische Teile von Hand über Staging.
Website seit einem Jahr ohne Updates: in Etappen zurück auf Stand
Typische Ausgangslage zu Beginn einer Wartung: eine Firmenwebsite, die seit einem Jahr niemand aktualisiert hat, mit einigen Dutzend Plugins, einer älteren PHP-Version und einem einzigen Backup von vor einigen Monaten. Auf so einer Website aktualisiere ich nicht alles auf einmal, weil sich bei einem Fehler sonst nicht feststellen lässt, welche Änderung ihn verursacht hat.
Ich beginne mit dem Startaudit, das im ersten Monat enthalten ist: Liste der Plugins mit Versionen, Prüfung, welche davon ihr Autor noch weiterentwickelt, PHP-Version und ob sich das vorhandene Backup zurückspielen lässt. Danach erstelle ich ein frisches, vollständiges Backup und einen Staging-Klon. Auf dem Klon aktualisiere ich in Etappen: zuerst den Core, dann die Plugins, von den einfachsten bis zu denen, an denen Formular oder Shop hängen, zuletzt das Theme. Nach jeder Etappe folgen Tests und Screenshot-Vergleich. Verwaiste Plugins bekommen Ersatz oder fliegen raus. Den Wechsel auf eine neuere PHP-Version plane ich als eigenen Schritt, wenn alle Plugins aktuell sind.
Erst wenn der Klon alle Tests besteht, übertrage ich die Änderungen im vereinbarten Fenster auf die Live-Website. Ab dann läuft die Website im normalen Wochenrhythmus. Taucht unterwegs ein Teil auf, das neuen Code braucht, beschreibe ich es und kalkuliere es separat.
Updates im Multisite-Netzwerk
In einem WordPress-Multisite-Netzwerk werden Plugins und Themes einmal für das ganze Netzwerk installiert, ihr Update betrifft also alle Subsites auf einmal. Jede Subsite kann ein Plugin aber anders nutzen: Die eine hat darauf ihr Bestellformular, die andere nur ein Banner. Auf dem Staging des Netzwerks teste ich deshalb die wichtigsten Abläufe auf jeder Subsite, die das Plugin nutzt, und der Screenshot-Vergleich umfasst Unterseiten mehrerer Subsites. Ein Multisite-Netzwerk kalkuliere ich individuell, abhängig von der Zahl der Subsites und den Anforderungen.
Neue WordPress-Hauptversion: nie am Erscheinungstag
Eine Hauptversion des Core, etwa WordPress 7.1, ändert mehr als eine Korrekturversion und bringt häufiger Unverträglichkeiten in Plugins zutage. Laut dem Versionsdienst von WordPress.org ist die aktuelle Version 7.1.3 (Stand 28. Oktober 2026). Eine Hauptversion installiere ich nie am Tag ihres Erscheinens. Zuerst prüfe ich auf Staging, ob Plugins und Theme mit der neuen Version laufen, vergleiche Screenshots und lese die Changelogs der Plugins, die ihre Kompatibilität noch nicht erklärt haben. Live geht die Hauptversion im vereinbarten Fenster, wenn der Klon die Tests besteht.
Auf einem solchen Klon zeigte sich der oben beschriebene Fehler von WP Rocket 3.23.2.2 mit WordPress 7.1. Blockiert ein Plugin die Hauptversion, bleibt die Website auf dem vorherigen Zweig, bis der Autor eine Korrektur veröffentlicht oder ich eine Umgehung finde, und das steht im Bericht.
Was von den Updates im Monatsbericht steht
Jede Update-Runde hinterlässt eine Spur im Monatsbericht: was aktualisiert wurde, welche Fehler auf Staging aufgetaucht sind, welche Versionen ich zurückgehalten habe und warum, ob eine Änderung von der Live-Website zurückgenommen wurde. So ist nach einem Ausfall klar, was sich wann auf der Website geändert hat, und bei einem Wechsel des Wartungsanbieters haben Sie eine Historie, die Sie weitergeben können.
Änderungen am eigenen Code bei Updates
Manchmal verlangt ein Update eine kleine Korrektur am eigenen Code der Website: im Child Theme, in einem für das Unternehmen geschriebenen Plugin oder in einer Funktion, die unter einer neueren PHP-Version nicht mehr läuft. Jede solche Änderung liegt in der Versionsverwaltung, damit nachvollziehbar ist, was, wann und warum geändert wurde, und sie sich zurücknehmen lässt. Den Code prüfe ich mit PHP_CodeSniffer und den Regeln der WordPress Coding Standards (WPCS), die statische Analyse mit PHPStan findet Typfehler und Aufrufe von Funktionen, die neuere PHP-Versionen nicht mehr kennen. Vor der Veröffentlichung sehe ich meine eigene Änderung noch einmal durch, getrennt vom Schreiben. Ein größerer Umbau bleibt außerhalb der Wartung und bekommt ein eigenes Angebot.
Updates für Drupal, TYPO3, Laravel und Symfony
Dasselbe Schema (Backup, Staging, Tests, Fenster, Rückfallplan) wende ich in Systemen außerhalb von WordPress an. Es unterscheiden sich die Werkzeuge und der Release-Rhythmus.
Drupal aktualisiere ich in einem wiederholbaren Ablauf mit Composer und Deployments über Drush. Drupal 7 bekommt seit dem 5. Januar 2025 keine Sicherheitsupdates mehr, und Drupal 10 erreicht am 9. Dezember 2026 sein Supportende. Was das für eine Website auf Drupal 10 bedeutet, beschreibt der Beitrag Drupal 10 End of Life: Upgrade oder Migration.
Bei TYPO3 zählen vor allem die Wechsel zwischen LTS-Versionen. Der kostenlose Support für TYPO3 12.4 endete am 30. April 2026, eine Website auf dieser Version braucht also einen Plan für den Umstieg auf 13 oder 14 LTS.
In einer Laravel-Anwendung erscheinen Korrekturversionen teils wöchentlich, und jede Hauptversion bekommt zwei Jahre lang Sicherheitsupdates. Korrekturen gehen innerhalb weniger Tage live, zusammen mit dem Update der Composer-Abhängigkeiten und einem Lauf von composer audit, immer zuerst auf dem Testserver. In Symfony bekommt Version 6.4 Fehlerbehebungen bis November 2026 und Sicherheitsupdates bis November 2027, daher beginnen viele Projekte mit einem Plan für den Umstieg auf 7.4. Code außerhalb von WordPress prüfe ich nach PSR-12.
Was der Update-Service nicht umfasst
In der Wartung aktualisiere ich Core, Plugins, Themes und PHP-Version. Außerhalb liegen der Umbau einer Funktion, die nach einem Update neuen Code braucht, große Änderungen an Theme oder Seitenarchitektur, der Bau neuer Schnittstellen und der Wechsel auf ein anderes System, etwa die Migration zu Next.js oder Astro. Solche Arbeit bekommt ein eigenes Angebot und beginnt nach Ihrer Bestätigung. Was die Wartung selbst kostet, steht auf der Seite WordPress-Wartung: Kosten.
Läuft die Website nach einem missglückten Update nicht mehr und Sie haben keinen Wartungsvertrag, beginnen Sie mit der WordPress-Reparatur. Tauchen nach einem Update fremde Dateien, Weiterleitungen oder eine Warnung von Google auf, lesen Sie weiter auf der Seite WordPress-Malware entfernen.
Nächster Schritt: Schicken Sie mir die Adresse der Website und die Liste der Plugins, die Sie für kritisch halten. Ich antworte, wie ich den Update-Zeitplan dafür aufbaue und was die Wartung kostet.
