WordPress-Updates: Reihenfolge, Backup, Auto-Updates

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#

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.

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. 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.

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.

Häufige Fragen#

Stand 08.10.2026. Verhalten an der Dokumentation auf developer.wordpress.org und make.wordpress.org am 04.10.2026 geprüft; Release-Seite und Versionsstatistik von WordPress.org am 08.10.2026 abgerufen.