WordPress-Updates per WP-CLI: Core, Plugins und Themes auf der Kommandozeile aktualisieren

Wer mehrere WordPress-Websites betreut oder per SSH auf den Server kommt, spielt Updates mit WP-CLI schneller und nachvollziehbarer ein als über das Backend. Jeder Befehl liefert eine klare Ausgabe mit alter und neuer Version, Probeläufe zeigen vorab, was passieren würde, und einzelne Plugins lassen sich gezielt ausnehmen. Diese Anleitung führt Sie in einer sicheren Reihenfolge durch Core, Datenbank, Plugins, Themes und Übersetzungen und zeigt, wie Sie bei Problemen auf eine ältere Version zurückgehen. Alle Befehle und Ausgaben stammen aus einem Test mit WordPress 7.1.2 und WP-CLI 2.12.0.

Voraussetzungen

• WordPress: eine laufende Installation, getestet mit WordPress 7.1.2. Die Befehle funktionieren seit vielen Versionen gleich.
• WP-CLI: auf dem Server installiert, getestet mit Version 2.12.0. Die Version zeigt wp cli version.
• PHP: WP-CLI nutzt das PHP der Kommandozeile. Im Test lief PHP 8.4, WordPress empfiehlt laut Update-API mindestens PHP 7.4.
• Zugriff: SSH-Zugang zum Server oder Webhosting mit Shell-Zugriff. Reine FTP-Zugänge reichen nicht.
• Rechte: Schreibrechte im WordPress-Verzeichnis als Benutzer des Webservers (unter Debian und Ubuntu meist www-data) sowie ein Administratorkonto im Backend für die Kontrolle danach.
• Backup: eine aktuelle Sicherung von Datenbank und wp-content, die Sie zurückspielen können. Schritt 1 zeigt eine schnelle Sicherung per WP-CLI.

Falls Sie noch keinen SSH-Schlüssel nutzen, richten Sie ihn vorher ein: SSH-Key-Authentifizierung einrichten.

Schritt 1: Richtig anmelden und eine Sicherung ziehen

Wechseln Sie in das WordPress-Verzeichnis, also den Ordner mit der wp-config.php. WP-CLI sucht die Installation im aktuellen Verzeichnis, alternativ geben Sie den Pfad mit --path an. Führen Sie die Befehle als Benutzer des Webservers aus. Arbeiten Sie als root, gehören neu entpackte Dateien root, und spätere Updates aus dem Backend scheitern an fehlenden Schreibrechten. WP-CLI verweigert den Betrieb als root deshalb standardmäßig, der Schalter --allow-root umgeht das nur, löst das Rechteproblem aber nicht.

cd /var/www/html
sudo -u www-data wp core version --extra

Die Ausgabe im Test:

WordPress version: 7.1.2
Database revision: 61833
TinyMCE version:   4.9110 (49110-20250317)
Package language:  en_US

Sichern Sie danach die Datenbank. wp db export liest die Zugangsdaten aus der wp-config.php, Sie müssen kein Passwort eintippen. Legen Sie die Datei außerhalb des Webroots ab, damit sie nicht über den Browser abrufbar ist, und packen Sie wp-content zusätzlich ein, denn dort liegen Plugins, Themes und Uploads.

sudo install -d -o www-data -m 700 /var/backups/wordpress
sudo -u www-data wp db export /var/backups/wordpress/vor-update-$(date +%F).sql
sudo tar -czf /var/backups/wordpress/wp-content-$(date +%F).tar.gz wp-content

Verifizieren: wp db export meldet Success: Exported to '...sql'., und ls -lh /var/backups/wordpress zeigt SQL-Datei und Archiv mit plausibler Größe.

Schritt 2: Anstehende Updates prüfen, ohne etwas zu ändern

Bevor Sie etwas ändern, verschaffen Sie sich einen Überblick. Das ist der größte Vorteil gegenüber dem Klick auf „Alle aktualisieren“: Sie sehen alte und neue Versionsnummer nebeneinander und erkennen große Sprünge.

sudo -u www-data wp core check-update
sudo -u www-data wp plugin list --update=available --fields=name,status,version,update_version
sudo -u www-data wp theme list --update=available --fields=name,version,update_version

Im Test waren absichtlich ältere Versionen installiert. Die Ausgabe:

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

name            status    version  update_version
akismet         inactive  5.3      5.7.2
classic-editor  active    1.6.3    1.7.0

name               version  update_version
twentytwentythree  1.0      1.7

Ist nichts zu tun, meldet wp core check-update Success: WordPress is at the latest version. Für Plugins gibt es zusätzlich einen echten Probelauf, der dieselbe Auswahl trifft wie der spätere Befehl:

sudo -u www-data wp plugin update --all --dry-run

Bei einem Sprung in der ersten oder zweiten Versionsstelle lohnt vorher ein Blick in das Änderungsprotokoll auf der Plugin-Seite bei wordpress.org.

Verifizieren: Sie haben eine Liste aller anstehenden Updates mit alter und neuer Version, und der Probelauf hat nichts verändert (wp plugin list zeigt weiterhin die alten Versionen).

Schritt 3: WordPress-Core und Datenbank aktualisieren

Aktualisieren Sie den Core zuerst, weil neue Plugin-Versionen oft eine aktuelle WordPress-Version voraussetzen. Für den laufenden Betrieb reicht meist die vorsichtige Variante: --minor spielt nur Wartungs- und Sicherheitsversionen innerhalb derselben Hauptversion ein, also etwa von 7.1.1 auf 7.1.2, nicht aber auf 7.2.

sudo -u www-data wp core update --minor
sudo -u www-data wp core update-db

Die Ausgabe im Test beim Sprung von 7.1.1 auf 7.1.2:

Updating to version 7.1.2 (de_DE)...
Herunterladen der Aktualisierung von https://downloads.wordpress.org/release/de_DE/wordpress-7.1.2.zip ...
Entpacken der aktualisierten Version ...
Success: WordPress updated successfully.
Success: WordPress database already at latest db version 61833.

WP-CLI lädt dabei automatisch das Paket in der Sprache der Installation. Ein Hauptversions-Update starten Sie ohne --minor mit wp core update. Planen Sie es bewusst ein, am besten nach einem Test auf einer Kopie der Website. wp core update-db bringt das Datenbankschema auf den Stand des neuen Codes. Mit --dry-run sehen Sie vorher, ob eine Änderung ansteht.

Verifizieren: wp core version zeigt die neue Version, wp core check-update meldet WordPress is at the latest version., und wp core verify-checksums endet mit Success: WordPress installation verifies against checksums.

Schritt 4: Plugins gezielt aktualisieren

Für Plugins bietet WP-CLI mehrere Stufen. Welche Sie wählen, hängt davon ab, wie viel Risiko Sie in einem Durchgang eingehen wollen.

Befehl	Wirkung	Beispiel aus dem Test
wp plugin update --all	alle Plugins auf die neueste Version	akismet 5.3 auf 5.7.2
wp plugin update --all --minor	nur innerhalb der ersten Versionsstelle	akismet 5.3 auf 5.7.2
wp plugin update --all --patch	nur innerhalb der zweiten Versionsstelle	akismet 5.3 auf 5.3.7
wp plugin update --all --exclude=NAME	alle außer den genannten Plugins	„Skipped updates for: classic-editor“
wp plugin update NAME	nur das genannte Plugin	akismet 5.3 auf 5.7.2

Die Option --patch ist die vorsichtigste Stufe und eignet sich für geschäftskritische Plugins wie Shop oder Formulare, bei denen Sie größere Sprünge erst prüfen möchten. Mit --exclude nehmen Sie Plugins aus, deren Update Sie separat begleiten wollen. Für eine Website mit wenigen, gut gepflegten Plugins reicht in der Regel:

sudo -u www-data wp plugin update --all

Die Ausgabe im Test:

Wartungsmodus wird aktiviert …
Herunterladen der Aktualisierung von https://downloads.wordpress.org/plugin/akismet.5.7.2.zip ...
Das Plugin wurde erfolgreich aktualisiert.
Herunterladen der Aktualisierung von https://downloads.wordpress.org/plugin/classic-editor.1.7.0.zip ...
Das Plugin wurde erfolgreich aktualisiert.
Wartungsmodus wird deaktiviert …
name            old_version  new_version  status
akismet         5.3          5.7.2        Updated
classic-editor  1.6.3        1.7.0        Updated
Success: Updated 2 of 2 plugins.

WordPress schaltet während der Plugin-Updates selbst den Wartungsmodus ein und danach wieder aus. Besucher sehen in diesen Sekunden eine kurze Wartungsseite.

Verifizieren: Die Tabelle zeigt bei jedem Plugin Updated, wp plugin list --update=available liefert keine Zeilen mehr, und wp plugin verify-checksums --all meldet Success: Verified 3 of 3 plugins. (Anzahl je nach Installation). Plugins, die nicht aus dem Verzeichnis auf wordpress.org stammen, kann dieser Abgleich nicht prüfen.

Schritt 5: Themes und Übersetzungen nachziehen

Themes aktualisieren Sie mit denselben Optionen wie Plugins. Achten Sie besonders auf das aktive Theme: Haben Sie Dateien darin direkt geändert, überschreibt das Update diese Änderungen. Eigene Anpassungen gehören deshalb in ein Child-Theme.

sudo -u www-data wp theme update --all
sudo -u www-data wp language core update
sudo -u www-data wp language plugin update --all
sudo -u www-data wp language theme update --all

Im Test aktualisierte wp theme update --all Twenty Twenty-Three von 1.0 auf 1.7. Die Sprachbefehle sind wichtig, weil Übersetzungen eigene Pakete sind: Nach einem Plugin-Update lud wp language plugin update --all die deutsche Übersetzung für Classic Editor 1.7.0 nach.

Verifizieren: wp theme list --update=available ist leer, und wp language core update meldet Success: Translations are up to date.

Schritt 6: Website kontrollieren und bei Bedarf zurückgehen

Ein erfolgreicher Befehl bedeutet nicht, dass die Website funktioniert. Rufen Sie die Startseite, eine Unterseite, das Kontaktformular und, falls vorhanden, den Shop auf. Melden Sie sich im Backend an und öffnen Sie Werkzeuge > Website-Zustand. Auf der Kommandozeile hilft ein schneller Blick auf den HTTP-Status:

curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/

Erwartet wird 200. Macht ein Plugin nach dem Update Probleme, installieren Sie die vorherige Version erneut. Die Versionsnummer kennen Sie aus Schritt 2:

sudo -u www-data wp plugin install akismet --version=5.3 --force

Im Test ersetzte der Befehl die Version 5.7.2 durch 5.3 („Die alte Version des Plugins wird entfernt“), das Plugin blieb dabei aktiv beziehungsweise inaktiv wie vorher. Für den Core funktioniert der Weg zurück entsprechend mit wp core update --version=7.1.1 --force, im Test ließ sich so von 7.1.2 auf 7.1.1 zurückgehen. Das ist ein Notbehelf: Datenbankänderungen einer neueren Hauptversion macht er nicht rückgängig. Nach einem Hauptversions-Update ist deshalb das Backup aus Schritt 1 der sichere Weg zurück.

Schreibt das Update PHP-Fehler, finden Sie die Ursache schneller mit aktiviertem Fehlerprotokoll, wie in WordPress Debug-Modus aktivieren beschrieben.

Verifizieren: Die wichtigsten Seiten liefern Status 200, der Website-Zustand zeigt keine neuen kritischen Probleme, und nach einem Rückschritt zeigt wp plugin list die gewünschte Version.

Updates als Routine

Die Befehle lassen sich in ein kleines Shell-Skript schreiben, das Sie regelmäßig ausführen. Automatisch per Cron sollten Sie höchstens Wartungsversionen einspielen, und nur mit vorheriger Datenbanksicherung und Kontrolle der Ausgabe. Hauptversionen und große Plugin-Sprünge brauchen einen Menschen, der danach die Website prüft. Wie Sie WP-CLI grundsätzlich über den System-Cron laufen lassen, zeigt WordPress Cron Job einrichten.

Updates sind keine einmalige Aufgabe: Sicherheitsversionen erscheinen unregelmäßig, und jede Woche ohne Kontrolle vergrößert den Abstand. Wer diese Arbeit nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden mit Kompatibilitätsprüfung ein und sichert die Website wöchentlich auf externen Speicher.

Typische Fehler

• Error: Momentan wird eine andere Aktualisierung durchgeführt. (englisch „Another update is currently in progress.“): Ein früheres Update wurde abgebrochen und hat die Sperre core_updater.lock hinterlassen. Prüfen Sie, dass wirklich kein Update läuft, dann: wp option delete core_updater.lock. Im Test lief das Update danach durch.
• Website zeigt „Wartungsmodus“ und HTTP-Status 503: Eine übrig gebliebene Datei .maintenance im WordPress-Verzeichnis. wp maintenance-mode status zeigt den Zustand, wp maintenance-mode deactivate beendet ihn. Ist die Datei beschädigt, meldet WP-CLI „Unable to read the maintenance file timestamp“, dann löschen Sie .maintenance von Hand.
• Warning: The 'NAME' plugin could not be found. gefolgt von Error: No plugins updated (1 failed).: Sie haben den Anzeigenamen statt des Ordnernamens verwendet. Den richtigen Namen zeigt die Spalte name in wp plugin list.
• Error: YIKES! It looks like you're running this as root.: Sie haben WP-CLI als root aufgerufen. Starten Sie den Befehl mit sudo -u www-data statt mit --allow-root, sonst gehören neue Dateien root.
• Backend meldet danach „Aktualisierung fehlgeschlagen“ oder fragt nach FTP-Daten: WP-CLI lief als root, und die neuen Dateien gehören root. Korrigieren Sie die Rechte mit chown -R www-data:www-data wp-content und nutzen Sie künftig sudo -u www-data.
• Warning: File should not exist: ... bei wp core verify-checksums: Im Core-Verzeichnis liegt eine Datei, die nicht zu WordPress gehört. Im Test war es eine Konfigurationsdatei des Docker-Images. Unbekannte PHP-Dateien sollten Sie prüfen, sie können auf eine Kompromittierung hinweisen.

Häufige Fragen

Ist WP-CLI sicherer als Updates über das Backend?

Die heruntergeladenen Pakete und der Update-Mechanismus sind dieselben. Der Gewinn liegt in der Kontrolle: Probelauf, gezieltes Ausnehmen einzelner Plugins, klare Ausgaben für ein Protokoll und keine Abbrüche durch Zeitlimits des Browsers.

Werden Premium-Plugins mit aktualisiert?

Nur wenn das Plugin seine Updates in den normalen WordPress-Update-Mechanismus einspeist und die Lizenz auf der Website aktiv ist. Prüfen Sie in Schritt 2, ob das Plugin in der Liste auftaucht. Fehlt es, obwohl der Hersteller eine neue Version anbietet, müssen Sie das Update über dessen Weg einspielen.

Wie aktualisiere ich mehrere Websites auf einem Server?

Mit dem globalen Parameter --path sprechen Sie jede Installation direkt an, zum Beispiel wp --path=/var/www/kunde1 plugin update --all. Führen Sie die Websites nacheinander aus und kontrollieren Sie jede einzeln.

Testumfang

Wir haben die Anleitung am 30.09.2026 auf einer Testinstanz durchgespielt, inklusive Core-Update von WordPress 7.1.1 auf 7.1.2 und Rückschritt von Plugin und Core. Auch typische Störungen wie eine Update-Sperre oder eine zurückgebliebene .maintenance-Datei haben wir gezielt nachgestellt. Premium-Plugins, Multisite und Updates auf eine neue Hauptversion haben wir nicht geprüft, testen Sie solche Fälle deshalb zuerst auf einer Kopie.

Fazit

Mit WP-CLI werden Updates planbar: Sicherung, Überblick, Core, Datenbank, Plugins, Themes und Übersetzungen in fester Reihenfolge, dazu ein erprobter Weg zurück. Entscheidend bleibt die Kontrolle danach, denn ein erfolgreicher Befehl ersetzt keinen Blick auf die Website. Wenn Sie diese Routine lieber abgeben möchten, übernimmt die WordPress-Wartung von Marcel Schönfelder Updates und externe Backups für Sie.

Weiterführende Anleitungen und Quellen

• WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen
• WordPress Debug-Modus aktivieren und Error-Logs analysieren
• WordPress nativ auf Ubuntu installieren
• WP-CLI-Handbuch: wp core update
• WP-CLI-Handbuch: wp plugin update
• WP-CLI-Handbuch: wp language
• WP-CLI-Handbuch: wp maintenance-mode