WordPress-Updates: Reihenfolge, Backup und WordPress 7

Ein WordPress-Update heißt: Kern, Plugins, Themes und Übersetzungen auf den neuesten Stand bringen, in dieser Reihenfolge und mit einer Sicherung davor. Einen Teil davon erledigt WordPress längst selbst. Den Rest machst du einmal pro Woche, Sicherheitsupdates am selben Tag. Der Weg dauert auf einer gewöhnlichen Website zehn bis fünfzehn Minuten.

Das Risiko liegt nicht im Update, sondern im fehlenden Rückweg. Die WordPress-Dokumentation sagt es deutlich: Ohne eine vor dem Update gezogene Sicherung von Dateien und Datenbank ist ein Zurückgehen auf die alte Version „near impossible“ (developer.wordpress.org, Upgrading WordPress). Wer Updates aus Angst aufschiebt, tauscht ein kleines, planbares Risiko gegen ein großes: veraltete Plugins sind der häufigste Weg, über den eine Website übernommen wird. Was du davon prüfen solltest, steht in WordPress-Sicherheit prüfen.

Was WordPress von selbst aktualisiert#

Lieber abgeben? Updates mit Sicherung und Prüfung, 49 €/Monat: frische Sicherung vor jedem Update, danach Startseite, Formular und Kasse geprüft, monatlich kündbar.

Seit WordPress 3.7 laufen automatische Hintergrund-Updates. Standardmäßig betreffen sie „minor core releases and translation files only“, also Wartungs- und Sicherheitsversionen wie 7.1.1 auf 7.1.2 und Übersetzungen. Neue Installationen seit WordPress 5.6 aktualisieren zusätzlich Hauptversionen automatisch (Upgrading WordPress). Ältere Installationen, die nur aktualisiert wurden, behalten das alte Verhalten.

Plugins und Themes laufen nicht automatisch, solange du es nicht je Erweiterung einschaltest. Wie das im Backend geht und warum ein Plugin ohne Pflege schlimmer ist als eines ohne Auto-Update, steht im Punkt 1 der Sicherheitsliste.

Gesteuert wird das Verhalten in der wp-config.php über zwei Konstanten:

// Kern: true = alle Updates, false = keine, 'minor' = nur Wartung/Sicherheit
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Schaltet sämtliche automatischen Updates ab, auch Übersetzungen
define( 'AUTOMATIC_UPDATER_DISABLED', true );

Für Plugins, Themes und Übersetzungen gibt es die Filter auto_update_plugin, auto_update_theme und auto_update_translation (Configuring Automatic Background Updates). Eine vernünftige Grundeinstellung für eine kleine Firmen-Website ist 'minor' für den Kern: Sicherheitskorrekturen kommen ohne dein Zutun, Hauptversionen machst du selbst, wenn du Zeit zum Testen hast.

Die einzige Einstellung, die du nicht setzen solltest, ist AUTOMATIC_UPDATER_DISABLED. Sie schaltet auch die Sicherheitsversionen ab, und dann hängt die Website an deinem Kalender.

Wie weit die Installationen dem Kern tatsächlich folgen, zeigt die Statistik-Schnittstelle von wordpress.org. Sie zählt jede Installation, die bei der Update-Prüfung ihre Version meldet. Abgerufen am 08.10.2026:

Eine Installation auf 7.0 oder 6.9 kann trotzdem die Wartungsversionen ihrer Reihe bekommen, denn mehr nimmt die Automatik bei älteren Installationen nicht. Wer bei den 7,6 % vor 6.0 steht, hat dagegen seit Mai 2022 keine Hauptversion mehr eingespielt.

Wie oft#

Die Release-Seite von WordPress.org nennt immer nur die neueste Version einer Reihe als gepflegt; am 08.10.2026 ist das 7.1.3 vom 6. Oktober, nach 7.1.2 vom 22. September, 7.1.1 vom 17. September und 7.1 vom 19. August (WordPress Releases). Vier Versionen in sieben Wochen sind normal.

• Sicherheitsupdates des Kerns oder eines Plugins: am selben Tag. Beim Kern übernimmt das die Automatik, bei Plugins nur, wenn sie eingeschaltet ist.
• Alles andere: einmal pro Woche an einem festen Termin, nicht am Freitagnachmittag.
• Hauptversionen des Kerns, etwa 7.1 auf 7.2: ein, zwei Wochen nach Erscheinen, wenn die erste Wartungsversion draußen ist und die großen Plugins nachgezogen haben.

WordPress 7: was die Hauptversion beim Update ändert#

WordPress 7.0 „Armstrong“ ist am 20. Mai 2026 erschienen, 7.1 „Mary Lou“ am 19. August 2026. Am 13.10.2026 ist 7.1.3 vom 6. Oktober die aktuelle Version; die Reihe 7.0 bekommt parallel noch Wartungsversionen, zuletzt 7.0.7 am selben Tag (WordPress Releases). Die Statistik-Schnittstelle meldet am 13.10.2026 61,5 % aller Installationen auf 7.1 und 8,5 % auf 7.0.

Der Schritt auf 7.0 ist der erste seit Jahren, der an der PHP-Version scheitern kann. WordPress 7.0 hat die Unterstützung für PHP 7.2 und 7.3 gestrichen; 7.0 und 7.1 laufen mit PHP 7.4 bis 8.5 (PHP-Kompatibilität im Core-Handbuch). Die Update-Schnittstelle von WordPress.org bietet 7.1.3 deshalb nur Servern ab PHP 7.4 an; ältere Server bekommen die Wartungsversionen der Reihe 6.9, die noch ab PHP 7.2.24 läuft (version-check, abgerufen am 13.10.2026). Wer im Dashboard keine 7.x angeboten bekommt, sollte zuerst die PHP-Version prüfen; wie das geht, steht in WordPress PHP-Version.

Was sich inhaltlich geändert hat, laut den Ankündigungen von WordPress.org:

• 7.0 bringt ein überarbeitetes Admin-Design über das ganze Dashboard, eine Befehlspalette (Strg+K), eine eigene Seite zur Schriftverwaltung und einen KI-Client im Kern, der zusammen mit der Abilities API generative KI-Modelle anbinden kann; die Zugänge dazu verwaltet eine neue Seite „Connectors“. Dazu kommen neue Blöcke, etwa Breadcrumbs und Icons (Ankündigung WordPress 7.0).
• 7.1 lädt den Beitragseditor jetzt für alle Themes in einem iframe wie den Website-Editor, verarbeitet Bilder (Komprimierung, Größen, Vorschaubilder) im Browser statt auf dem Server, unterstützt AVIF, HEIC und HDR-Bilder und bringt die Blöcke Playlist und Tabs (Ankündigung WordPress 7.1).

Für das Update heißt das zweierlei. Plugins und Themes, die das Backend oder den Editor mit eigenen Stilen verändern, sehen nach dem Sprung auf 7.0 oder 7.1 am ehesten anders aus oder brechen; genau für so eine Hauptversion lohnt die Probe auf einer Staging-Kopie. Und mit dem KI-Client gibt es eine neue Stelle, an der Zugangsschlüssel zu fremden Diensten liegen können: Wer Administrator ist, sieht und verwaltet sie, also gehört die Liste der Administratoren nach dem Update einmal angesehen. Welche Version gerade aktuell ist und welche Reihen noch Sicherheitskorrekturen bekommen, führt Aktuelle WordPress-Version.

Die Reihenfolge, in 15 Minuten#

1. Sicherung prüfen, nicht nur anlegen (3 Minuten). Datum der letzten Sicherung von Dateien und Datenbank ansehen. Die Dokumentation verlangt ausdrücklich, dass die Sicherung „there and usable“ ist. Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung.
2. Wartungsmodus bei größeren Updates (1 Minute). Bei einer Hauptversion oder vielen Plugins auf einmal die Website kurz in den Wartungsmodus schalten, damit Besucher keine halbe Seite sehen.
3. Plugins und Themes (5 Minuten). Unter „Dashboard → Aktualisierungen“ oder auf der Kommandozeile. Mit WP-CLI zeigt --dry-run vorher, was passieren würde, und --minor beschränkt auf kleine Versionssprünge (wp plugin update):

``bash wp plugin update --all --dry-run wp plugin update --all --minor wp theme update --all ``

Plugins vor dem Kern, weil ein Plugin-Update oft die Voraussetzung für die neue Kernversion ist, selten umgekehrt. 4. Kern (2 Minuten). wp core update und danach wp core update-db, falls die Datenbank angepasst werden muss. 5. Testen (4 Minuten). Startseite, eine Unterseite, das Kontaktformular abschicken, im Backend anmelden. Bei einem Shop zusätzlich einen Artikel in den Warenkorb. Danach den Wartungsmodus beenden.

Läuft die Website auf einer alten PHP-Version, kommt die Umstellung als eigener Schritt danach, nie im selben Durchgang. Wie das geht und welche Version WordPress empfiehlt, steht in Welche PHP-Version braucht WordPress?.

Staging: wann es sich lohnt#

Eine Staging-Umgebung ist eine Kopie der Website, auf der du Updates zuerst ausprobierst. Viele Hoster bieten sie mit einem Klick an; die drei Wege dazu stehen in WordPress-Staging. Für eine Website mit fünf Plugins und ohne Shop ist das bei Wartungsversionen übertrieben. Sinnvoll ist es bei Hauptversionen, bei einem Theme-Wechsel, bei Shop- und Mitgliederbereichen und bei Plugins, die tief eingreifen, etwa Seitenbaukästen oder Mehrsprachigkeit. Wichtig ist, dass die Kopie mit noindex oder Passwortschutz läuft, sonst landet sie als zweite Website in Google.

Wenn nach dem Update etwas kaputt ist#

Weiße Seite oder „kritischer Fehler“. Seit WordPress 5.2 fängt WordPress fatale PHP-Fehler ab und schickt eine E-Mail an die Administrator-Adresse, mit einem Link in den Wiederherstellungsmodus. In diesem Modus wird das fehlerhafte Plugin oder Theme nur für dich pausiert, und du kommst wieder ins Backend (Fatal Error Recovery Mode in 5.2). Prüf deshalb vorher, ob die Administrator-Adresse unter „Einstellungen → Allgemein“ ein Postfach ist, das jemand liest.

Kommt keine Mail, hilft das Fehlerprotokoll. In der wp-config.php schaltet WP_DEBUG zusammen mit WP_DEBUG_LOG das Schreiben nach /wp-content/debug.log ein (wp-config.php):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Danach wieder abschalten. Ein offenes Fehlerprotokoll auf einer Live-Seite verrät Pfade und Versionen.

Was WordPress selbst zurücknimmt. Schlägt die Installation eines Plugin- oder Theme-Updates fehl, stellt WordPress seit 6.3 die vorherige Version aus wp-content/upgrade-temp-backup/ wieder her. Das gilt nur für Fehler beim Installieren, nicht für eine Seite, die nach einem erfolgreichen Update nicht mehr läuft (New in 6.3: Rollback). Für automatische Plugin-Updates kam in 6.6 eine zweite Stufe dazu: WordPress ruft nach dem Update die Startseite auf, und bei einem fatalen PHP-Fehler wird die alte Version zurückgespielt und eine Mail verschickt (Help test WordPress 6.6, Merge Proposal: Rollback Auto-Update). Beides fängt Abstürze ab, keine falsch dargestellten Seiten und kein kaputtes Formular.

Ein Plugin von Hand zurücknehmen. WP-CLI holt eine bestimmte Version aus dem Verzeichnis auf WordPress.org und überschreibt die installierte (wp plugin install):

wp plugin install kontaktformular-plugin --version=5.9.3 --force

Danach das automatische Update für dieses Plugin abschalten, bis der Hersteller den Fehler behoben hat. Den Kern zurückzusetzen empfiehlt die Dokumentation ausdrücklich nicht; hier ist die Sicherung der Weg.

Was nicht hilft#

Updates abschalten, „weil es läuft“. Es läuft, bis eine Lücke in einem der Plugins bekannt wird. Dann läuft es für jemand anderen. Wie das aussieht, beschreibt WordPress gehackt: was jetzt zu tun ist; wer es nicht selbst machen will: WordPress-Bereinigung.

Mehr Plugins als nötig. Jedes Plugin ist ein Update mehr und eine mögliche Lücke mehr. Weniger Updates gibt es nur mit weniger Plugins; wie man ausmistet, steht in WordPress-Plugins.

Alles auf einmal und ohne Test. Zwanzig Plugins, Kern und PHP in einem Durchgang heißt: Wenn danach etwas nicht geht, weißt du nicht, was.

Die Sicherung des Hosters als einzige Sicherung. Sie liegt beim selben Anbieter, oft mit wenigen Tagen Aufbewahrung, und ob sie sich zurückspielen lässt, hat niemand probiert.

Das Update-Plugin mit eigenem Zeitplan obendrauf. Ein zweites System, das ebenfalls aktualisiert, macht aus einer nachvollziehbaren Reihenfolge zwei, die sich nicht kennen.

Eine Terminfrage, keine Technikfrage#

WordPress aktuell zu halten ist keine Technikfrage, sondern eine Terminfrage. Die Automatik für den Kern bleibt an, die Plugins kommen einmal pro Woche dran, und vor jedem größeren Schritt steht eine Sicherung, die schon einmal zurückgespielt wurde. Wer den Termin nicht selbst halten will, kann ihn abgeben; genau das ist der Inhalt der WordPress-Wartung. Und wenn ein Update die Seite schon kaputt gemacht hat, weiße Seite oder kritischer Fehler, und der Rückweg fehlt: Das ist der Fall für die WordPress-Soforthilfe, Fehlerdiagnose und Reparatur zum Festpreis.

Häufige Fragen#

Stand 13.10.2026: Abschnitt zu WordPress 7 ergänzt, Ankündigungen zu 7.0 und 7.1, Release-Seite, PHP-Kompatibilitätstabelle, Update-Schnittstelle und Versionsstatistik an diesem Tag abgerufen. Verhalten der automatischen Updates an der Dokumentation auf developer.wordpress.org und make.wordpress.org am 04.10.2026 geprüft; die Grafik zeigt die Versionsstatistik vom 08.10.2026.