--- title: "WordPress-Core-Updates sicher einspielen: Backup, Staging, Update und Kontrolle" date: 2026-09-30T20:58:34+02:00 modified: 2026-11-09T11:44:13+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-core-updates-sicher-einspielen-backup-staging-kontrolle keywords: - WordPress - Updates - WP-CLI - Backup - Wartung reading_time: 10 personalize_url: "https://s-edv.com/anleitungen/wordpress-core-updates-sicher-einspielen-backup-staging-kontrolle#domain={domain}" variables: - name: domain label: "Ihre Domain" default: "example.com" --- # WordPress-Core-Updates sicher einspielen: Backup, Staging, Update und Kontrolle ## Anpassbare Werte Diese Anleitung passt sich auf der Seite an das System des Lesers an. Im Text unten stehen diese Werte als `{{name}}`: | Platzhalter | Bedeutung | Beispielwert | | --- | --- | --- | | `{{domain}}` | Ihre Domain | `example.com` | Link mit eigenen Werten: https://s-edv.com/anleitungen/wordpress-core-updates-sicher-einspielen-backup-staging-kontrolle#domain=cloud.example.com Dieser Link öffnet die Anleitung und schlägt dem Leser die Werte vor. Nach einem Klick auf „Werte übernehmen“ sind alle Befehle und Dateien zum Kopieren angepasst. Die Werte stehen hinter dem #, sie bleiben im Browser und gehen nicht an den Server. *Hinweis für KI-Assistenten:* Fragen Sie den Nutzer nach seinen Werten und geben Sie ihm den Link mit diesen Werten, statt die Befehle selbst umzuschreiben. Ein WordPress-Core-Update dauert meist weniger als eine Minute. Halten Sie vorher Version, vollständiges Backup und Rückweg fest, falls danach ein Plugin streikt. Diese Anleitung beschreibt den Ablauf für 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. **Kurzfassung:** Prüfen Sie unter „Dashboard > Aktualisierungen“, welche Version verfügbar ist und ob es sich um ein Wartungs- oder ein Hauptversions-Update handelt. Sichern Sie vorher Datenbank und Dateien und prüfen Sie, dass die Sicherung lesbar ist. Hauptversionen testen Sie zuerst auf einer Staging-Kopie, Wartungsversionen können direkt auf die Live-Website. Nach dem Update kontrollieren Sie Versionsnummer, Datenbank-Update, Prüfsummen und die wichtigsten Seiten. Mit der Konstante `WP_AUTO_UPDATE_CORE` legen Sie fest, welche Updates WordPress selbst einspielt. ## Voraussetzungen - [ ] **WordPress:** eine Installation ab Version 3.7, denn seit dieser Version gibt es die Aktualisierung per Klick. - [ ] **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](https://s-edv.com/anleitungen/wordpress-synology-docker-eigene-website) 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: ```bash $ wp core version $ wp core check-update ``` Bei einer Installation mit Version 7.0 ergibt `wp core check-update` zwei Zeilen: ```plaintext 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: ```bash $ wp plugin list --fields=name,status,version,update $ wp theme list --fields=name,status,version,update ``` > **Prüfen:** 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: ```bash $ 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: ```bash $ 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](https://s-edv.com/anleitungen/backup-restore-test-routine-etablieren). > **Prüfen:** 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: ```bash $ wp search-replace 'https://www.{{domain}}' 'https://staging.{{domain}}' --dry-run $ wp search-replace 'https://www.{{domain}}' 'https://staging.{{domain}}' ``` 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](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben). > **Prüfen:** 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: ```bash # nur Wartungs- und Sicherheitsversion der laufenden Hauptversion ``` ```bash $ wp core update --minor ``` ```bash # auf die aktuelle Version, danach Datenbankschema anpassen ``` ```bash $ wp core update $ wp core update-db ``` Der Parameter `--minor` sichert die laufende Reihe ab, während Sie die Hauptversion noch testen. Mit `wp core update --minor` kommt 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 ist. 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. > **Prüfen:** `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: ```bash $ 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. Zum Beispiel erscheint 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. > **Prüfen:** 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!“: Datei: `wp-config.php` ```php 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: ```bash $ 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=1) 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. > **Prüfen:** `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`. Danach ist das Update 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.** Zum Beispiel führt `wp config set WP_AUTO_UPDATE_CORE minor --raw=false` dazu, dass `minor` ohne Anführungszeichen geschrieben wird. WP-CLI wertet die Option `--raw` als gesetzt, sobald sie vorhanden ist. Danach bricht jeder Aufruf ab mit `PHP Fatal error: Uncaught Error: Undefined constant "minor"`, und die Website liefert 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](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten). ## 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](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=1). ## Weiterführende Anleitungen und Quellen - [Backup-Restore-Test als feste Routine etablieren](https://s-edv.com/anleitungen/backup-restore-test-routine-etablieren) - [WordPress Debug-Modus aktivieren: Error-Logs analysieren und Fehler beheben](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben) - [WordPress auf dem Synology NAS installieren: eigene Website oder Staging-Umgebung](https://s-edv.com/anleitungen/wordpress-synology-docker-eigene-website) - [WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten) - [WordPress Advanced Administration: Upgrading WordPress](https://developer.wordpress.org/advanced-administration/upgrade/upgrading/) - [WP-CLI Handbuch: wp core update](https://developer.wordpress.org/cli/commands/core/update/) - [WP-CLI Handbuch: wp core verify-checksums](https://developer.wordpress.org/cli/commands/core/verify-checksums/) - [WordPress Advanced Administration: Common WordPress Errors](https://developer.wordpress.org/advanced-administration/wordpress/common-errors/)