WordPress-Core-Updates sicher einspielen: Backup, Staging, Update und Kontrolle

Ein WordPress-Core-Update dauert meist weniger als eine Minute. Riskant wird es, wenn niemand weiß, welche Version vorher lief, ob das Backup vollständig ist und wie man zurückkommt, falls ein Plugin nach dem Update streikt. Diese Anleitung beschreibt einen festen Ablauf für kleine Unternehmen: Stand erfassen, sichern, auf einer Kopie testen, auf der Live-Website aktualisieren und das Ergebnis prüfen. Sie zeigt den Weg im Backend und mit WP-CLI. Alle Befehle und Meldungen stammen aus einem Test mit WordPress 7.0 und 7.1.2 auf PHP 8.4.

Voraussetzungen

• WordPress: eine Installation ab Version 3.7, denn seit dieser Version gibt es die Aktualisierung per Klick. Die Anleitung wurde mit 7.0.6 und 7.1.2 (aktuelle Version am 30.09.2026) getestet.
• PHP: mindestens die von WordPress empfohlene Version. Die Update-API von wordpress.org nennt aktuell PHP 7.4 als Mindestwert, sinnvoll ist eine noch unterstützte PHP-8-Version.
• Zugang: ein Benutzerkonto mit der Rolle Administrator. Für die WP-CLI-Variante zusätzlich SSH-Zugang zum Server, für den Notfall FTP- oder SFTP-Zugang und Zugriff auf die Datenbank (etwa über das Kundenmenü Ihres Hosters).
• Backup: ein Speicherort außerhalb des Webspace, zum Beispiel ein lokaler Rechner oder ein externer Speicher. Ein Backup, das nur auf demselben Server liegt, hilft nicht, wenn der Server selbst das Problem ist.
• Zeitfenster: etwa 30 Minuten zu einer Zeit mit wenig Besuchern.
• Optional: eine Staging-Kopie der Website. Viele Hoster bieten das im Kundenmenü an, alternativ eine eigene Testinstanz, etwa wie in der Anleitung zu WordPress auf dem Synology NAS beschrieben.

Schritt 1: Stand erfassen und Update-Art bestimmen

Öffnen Sie im Backend „Dashboard > Aktualisierungen“. Die Seite heißt „WordPress-Aktualisierungen“ und zeigt oben „Aktuelle Version“ sowie, falls vorhanden, den Hinweis „Eine neue WordPress-Version ist verfügbar.“ Notieren Sie beide Versionsnummern. Die Unterscheidung ist wichtig: Ändert sich nur die dritte Stelle (etwa 7.0.5 auf 7.0.6), ist es eine Wartungs- und Sicherheitsversion. Ändert sich die zweite Stelle (7.0 auf 7.1), ist es eine Hauptversion mit neuen Funktionen und damit höherem Risiko für Plugins und Themes.

Auf der Kommandozeile liefert WP-CLI dieselbe Information, getrennt nach Update-Art:

wp core version
wp core check-update

Im Test auf einer Installation mit Version 7.0 ergab wp core check-update zwei Zeilen:

version  update_type  package_url
7.0.6    minor        https://downloads.wordpress.org/release/de_DE/wordpress-7.0.6.zip
7.1.2    major        https://downloads.wordpress.org/release/de_DE/wordpress-7.1.2.zip

Notieren Sie außerdem aktive Plugins und Themes und ob für sie Updates anstehen:

wp plugin list --fields=name,status,version,update
wp theme list --fields=name,status,version,update

Verifizieren: Sie haben die installierte Version, die Zielversion, die Update-Art (minor oder major) und die Liste aktiver Plugins und Themes schriftlich festgehalten.

Schritt 2: Datenbank und Dateien sichern

Das WordPress-Backend weist auf der Update-Seite selbst darauf hin, vorher Datenbank und Dateien zu sichern. Beides gehört zusammen. Die Datenbank enthält Beiträge, Seiten, Einstellungen und Benutzer, die Dateien enthalten Plugins, Themes, Uploads, wp-config.php und .htaccess. Die offizielle Update-Dokumentation nennt ausdrücklich auch die .htaccess, weil sie eigene Weiterleitungen und Schutzregeln enthalten kann.

Mit WP-CLI erstellen Sie den Datenbank-Export und ein Archiv der Dateien. Führen Sie die Befehle im WordPress-Verzeichnis aus und passen Sie den Zielordner an:

mkdir -p ~/wp-backup
wp db export ~/wp-backup/vor-update-$(date +%F).sql
tar -czf ~/wp-backup/dateien-$(date +%F).tar.gz --exclude=wp-content/cache .

Der Export meldet im Erfolgsfall Success: Exported to '…'. Kopieren Sie beide Dateien anschließend auf einen Speicher außerhalb des Servers. Ohne SSH nutzen Sie die Backup-Funktion Ihres Hosters. „Werkzeuge > Export“ ist kein Ersatz, es exportiert nur Inhalte als XML.

Ein Backup ist erst dann eines, wenn es sich zurückspielen lässt. Prüfen Sie mindestens, dass die Dateien nicht leer sind und das Archiv lesbar ist:

ls -lh ~/wp-backup/
tar -tzf ~/wp-backup/dateien-$(date +%F).tar.gz | grep -c .
grep -c "CREATE TABLE" ~/wp-backup/vor-update-$(date +%F).sql

Wie Sie das Zurückspielen regelmäßig üben, beschreibt die Anleitung Backup-Restore-Test als feste Routine etablieren.

Verifizieren: Datenbank-Export und Dateiarchiv liegen mit plausibler Größe auf einem externen Speicher, das Archiv lässt sich auflisten und der SQL-Export enthält CREATE TABLE-Zeilen.

Schritt 3: Hauptversionen zuerst auf Staging testen

Bei Wartungsversionen können Sie diesen Schritt überspringen. Bei einer Hauptversion zeigt der Test auf einer Kopie Probleme mit Plugins oder Theme, bevor Kunden sie sehen.

Die Staging-Kopie braucht denselben Stand wie die Live-Website: gleiche Plugin-, Theme- und PHP-Versionen. Spielen Sie dort das Update wie in Schritt 4 ein und prüfen Sie anschließend die Punkte aus Schritt 5. Klicken Sie außerdem die Abläufe durch, die für Ihr Unternehmen zählen, etwa Kontaktformular und Shop-Bestellung.

Wenn Sie die Datenbank der Live-Website in eine Staging-Instanz mit anderer Adresse übernehmen, ersetzen Sie die Adresse mit wp search-replace und nicht per SQL-Befehl. Ein SQL-Replace beschädigt serialisierte Daten in Optionen und Widgets:

wp search-replace 'https://www.example.com' 'https://staging.example.com' --dry-run
wp search-replace 'https://www.example.com' 'https://staging.example.com'

Schalten Sie auf der Staging-Kopie den Debug-Modus ein, damit Warnungen im Log landen. Wie das geht, steht in der Anleitung WordPress Debug-Modus aktivieren.

Verifizieren: Auf der Staging-Kopie läuft die Zielversion, die wichtigsten Abläufe funktionieren und das Debug-Log enthält keine neuen fatalen Fehler.

Schritt 4: Update auf der Live-Website einspielen

Im Backend klicken Sie unter „Dashboard > Aktualisierungen“ auf die Schaltfläche „Auf Version 7.1.2 aktualisieren“. In deutschen Installationen zeigt WordPress zwei Schaltflächen, eine mit dem Zusatz de_DE und eine mit en_US. Wählen Sie die Variante mit de_DE, sonst wird die Oberfläche auf Englisch umgestellt.

Mit WP-CLI geht es so, getrennt nach Update-Art:

# nur Wartungs- und Sicherheitsversion der laufenden Hauptversion
wp core update --minor

# auf die aktuelle Version, danach Datenbankschema anpassen
wp core update
wp core update-db

Der Parameter --minor sichert die laufende Reihe ab, während Sie die Hauptversion noch testen. Im Test brachte wp core update --minor eine Installation von 7.0 auf 7.0.6, ohne auf 7.1 zu wechseln. wp core update-db meldet Success: WordPress database already at latest db version …, wenn kein Schemawechsel nötig war. Das ist kein Fehler.

Während des Updates legt WordPress im Stammverzeichnis die Datei .maintenance an. Besucher erhalten dann den HTTP-Status 503 und eine kurze Wartungsseite. Nach erfolgreichem Update entfernt WordPress die Datei selbst.

Aktualisieren Sie Plugins und Themes getrennt vom Core, am besten direkt danach und einzeln. So wissen Sie bei einem Fehler, welche Komponente ihn ausgelöst hat.

Verifizieren: wp core version gibt die Zielversion aus, und im Backend zeigt „Dashboard > Aktualisierungen“ die neue Nummer unter „Aktuelle Version“.

Schritt 5: Ergebnis kontrollieren

Prüfen Sie zuerst die Core-Dateien. WP-CLI vergleicht jede Datei mit den offiziellen Prüfsummen von wordpress.org:

wp core version --extra
wp core verify-checksums

Die Ausgabe Success: WordPress installation verifies against checksums. bedeutet, dass alle Core-Dateien unverändert sind. Warnungen der Form File should not exist: … weisen auf zusätzliche Dateien in wp-admin oder wp-includes hin. Das können Reste alter Versionen oder eingeschleuster Code sein. Im Test erschien die Warnung für wp-config-docker.php, eine Datei des offiziellen Docker-Images. Prüfen Sie jede unbekannte Datei, bevor Sie sie löschen.

Danach folgt die Sichtprüfung: Startseite, eine Unterseite, ein Beitrag, das Kontaktformular und bei Shops der Warenkorb. Im Backend zeigt „Werkzeuge > Website-Zustand“, ob WordPress neue Probleme meldet.

Verifizieren: Prüfsummen bestätigt, Website-Zustand ohne neue kritische Probleme, die wichtigsten Seiten und Formulare funktionieren.

Schritt 6: Automatische Updates bewusst einstellen

WordPress spielt Updates auch selbst ein. Laut offizieller Dokumentation erhalten Installationen, die ab Version 5.6 neu angelegt wurden, standardmäßig automatische Updates für Wartungs- und Hauptversionen. Ältere Installationen erhalten standardmäßig nur Wartungsversionen. Unter „Dashboard > Aktualisierungen“ steht, welche Einstellung gilt, zum Beispiel „Diese Website wird durch alle neuen WordPress-Versionen automatisch auf dem neuesten Stand gehalten.“ Darunter finden Sie den Link „Auf automatische Aktualisierungen nur für Wartungs- und Sicherheitsaktualisierungen wechseln“.

Für Unternehmenswebsites mit vielen Plugins ist ein guter Kompromiss: Wartungsversionen automatisch, Hauptversionen nach Test von Hand. Diese Einstellung legen Sie dauerhaft in der wp-config.php fest, oberhalb der Zeile „That's all, stop editing!“:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Die Konstante kennt drei Werte: true aktiviert alle Core-Updates, false schaltet alle ab, 'minor' erlaubt nur Wartungsversionen. Ist sie gesetzt, überschreibt sie die Einstellung im Backend. Mit WP-CLI setzen Sie sie so:

wp config set WP_AUTO_UPDATE_CORE minor
wp config get WP_AUTO_UPDATE_CORE

Von AUTOMATIC_UPDATER_DISABLED rät die WordPress-Dokumentation ausdrücklich ab, denn damit fallen auch Sicherheitsupdates weg. Wenn Sie automatische Updates abschalten, übernehmen Sie die Pflicht, jede Sicherheitsversion zeitnah selbst einzuspielen.

Ein Core-Update ist also keine einmalige Aufgabe: Wartungsversionen erscheinen mehrmals im Jahr, dazu kommen Plugin- und Theme-Updates und die Sicherung davor. Wer diese Routine nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung innerhalb von 48 Stunden ein (Servicezeiten Montag bis Freitag, 8 bis 18 Uhr) und sichert die Website wöchentlich auf externen Speicher.

Verifizieren: wp config get WP_AUTO_UPDATE_CORE gibt minor aus, und die Seite „Dashboard > Aktualisierungen“ nennt nur noch Wartungs- und Sicherheitsaktualisierungen als automatisch.

Typische Fehler

„Momentan wird eine andere Aktualisierung durchgeführt.“ WordPress sperrt parallele Updates über die Option core_updater.lock. Bleibt die Sperre nach einem Abbruch stehen, verweigern Backend und WP-CLI jedes weitere Update. Prüfen Sie, dass wirklich kein Update läuft, und löschen Sie dann die Sperre mit wp option delete core_updater.lock. Im Test war das Update danach sofort wieder möglich.

Website bleibt im Wartungsmodus. Bricht das Update ab, bleibt die Datei .maintenance im Stammverzeichnis liegen, und alle Seiten antworten mit HTTP 503. Löschen Sie die Datei per FTP oder mit wp maintenance-mode deactivate. Prüfen Sie danach mit wp core verify-checksums, ob das Update vollständig war, und spielen Sie es sonst erneut ein.

Kritischer Fehler nach dem Update. Meist ist ein Plugin oder Theme nicht mit der neuen Version kompatibel. Starten Sie WP-CLI mit --skip-plugins, um zu prüfen, ob WordPress ohne Plugins lädt, und deaktivieren Sie das verdächtige Plugin mit wp plugin deactivate NAME --skip-plugins. Hilft das nicht, spielen Sie Datenbank und Dateien aus Schritt 2 zurück.

Falscher Wert in der wp-config.php. Im Test führte wp config set WP_AUTO_UPDATE_CORE minor --raw=false dazu, dass minor ohne Anführungszeichen geschrieben wurde. WP-CLI wertet die Option --raw als gesetzt, sobald sie vorhanden ist. Danach brach jeder Aufruf ab mit PHP Fatal error: Uncaught Error: Undefined constant "minor", und die Website lieferte HTTP 500. Lassen Sie --raw bei Textwerten weg und kontrollieren Sie die Zeile in der wp-config.php: Richtig ist define( 'WP_AUTO_UPDATE_CORE', 'minor' );.

Download fehlgeschlagen. Bei falscher Versionsnummer meldet WP-CLI Error: Der Download ist fehlgeschlagen. Prüfen Sie Nummer und ausgehende HTTPS-Verbindungen des Servers.

Häufige Fragen

Kann ich mehrere Hauptversionen auf einmal überspringen?

Ja, laut offizieller Dokumentation ist das mit vollständigem Backup möglich. Bei mehr als zwei übersprungenen Hauptversionen empfiehlt sie, schrittweise zu aktualisieren, um Konflikte und Schäden an der Datenbank zu vermeiden. Eine bestimmte Version spielen Sie mit wp core update --version=7.0.6 ein.

Wie komme ich auf die vorherige Version zurück?

Am saubersten mit dem Backup aus Schritt 2, weil dann Dateien und Datenbank zusammenpassen. WP-CLI kann mit wp core update --version=7.0.6 --force auch ältere Core-Dateien einspielen. Das Datenbankschema wird dabei aber nicht zurückgesetzt, daher ist das nur eine Notlösung.

Muss ich Plugins vor dem Core-Update deaktivieren?

Die Dokumentation verlangt es für das manuelle Update per FTP. Beim Update per Klick oder WP-CLI ist es mit Staging-Test und Backup nicht nötig.

Wie oft sollte ich nach Updates schauen?

Mindestens einmal pro Woche. Sicherheitsversionen spielt WordPress bei Standardeinstellungen selbst ein, Hauptversionen und Plugin-Updates brauchen einen festen Termin. Für zuverlässige geplante Aufgaben hilft ein echter Cronjob, siehe WP-Cron durch System-Cron ersetzen.

Testumfang

Wir haben das Update in einer Docker-Testumgebung mit deutschem WordPress durchgespielt, von Version 7.0 über 7.0.6 bis 7.1.2. Dabei haben wir verify-checksums mit einer absichtlich eingeschleusten Testdatei geprüft und den Wartungsmodus beobachtet, der die Seite mit HTTP 503 sperrt.

Updates über Hoster-Oberflächen, Multisite und Staging-Funktionen einzelner Hoster haben wir nicht getestet. Nutzen Sie so etwas, probieren Sie das Update zuerst auf einer Kopie aus.

Fazit

Ein Core-Update ist technisch einfach, sicher wird es durch den Ablauf drumherum: Stand notieren, Backup extern ablegen und prüfen, Hauptversionen auf einer Kopie testen, danach Prüfsummen und wichtige Seiten kontrollieren. Mit WP_AUTO_UPDATE_CORE auf 'minor' erhalten Sie Sicherheitsversionen automatisch und behalten Hauptversionen unter Kontrolle. Wenn Sie diese Routine dauerhaft abgeben möchten, übernimmt das eine WordPress-Wartung mit festen Update-Zeiten.

Weiterführende Anleitungen und Quellen

• Backup-Restore-Test als feste Routine etablieren
• WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler beheben
• WordPress auf dem Synology NAS installieren: eigene Website oder Staging-Umgebung
• WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen
• WordPress Advanced Administration: Upgrading WordPress
• WP-CLI Handbuch: wp core update
• WP-CLI Handbuch: wp core verify-checksums
• WordPress Advanced Administration: Common WordPress Errors