Major-Update von WordPress vorbereiten: Checkliste für Unternehmenswebsites

Ein Major-Update von WordPress, etwa von 7.0 auf 7.1, bringt neue Funktionen im Editor, in der Mediathek und in der Verwaltung und ändert Schnittstellen, auf die Plugins und Themes aufbauen. Für eine Unternehmenswebsite mit Kontaktformular, Shop oder Buchungssystem ist das kein Klick zwischendurch, sondern ein kleines Projekt mit Vorlauf. Diese Anleitung ist eine Checkliste für die Wochen vor dem Update: Termine im Blick behalten, Erweiterungen inventarisieren, einen Testplan für die geschäftskritischen Funktionen schreiben, eine Staging-Kopie vorbereiten und den Rückweg proben. Das eigentliche Einspielen beschreibt die Anleitung WordPress-Core-Updates sicher einspielen.

Voraussetzungen

• WordPress: eine Installation auf dem letzten Wartungsstand der aktuellen Hauptversion. Im Test: 7.0.6 als Ausgangsstand, 7.1.2 als Ziel (aktuelle Version am 30.09.2026).
• PHP: eine Version, die die Zielversion unterstützt. Die Versions-API von wordpress.org nennt für 7.1.2 PHP 7.4 als Mindestwert, im Test lief PHP 8.4. Wie Sie PHP umstellen, zeigt die Anleitung PHP-Version für WordPress aktualisieren.
• Zugriff: Benutzerkonto mit der Rolle Administrator im Backend, für die WP-CLI-Befehle zusätzlich SSH und WP-CLI (im Test 2.12.0).
• Backup: ein aktuelles Backup von Dateien und Datenbank, das Sie schon einmal erfolgreich zurückgespielt haben.
• Staging: eine Kopie der Website auf einer eigenen Subdomain oder beim Hoster, alternativ eine lokale Testumgebung.
• Zeit: etwa zwei Stunden verteilt auf zwei bis drei Wochen, plus ein ruhiges Zeitfenster für die Umstellung.

Schritt 1: Termine und Änderungen der neuen Version kennen

WordPress-Hauptversionen folgen einem öffentlichen Ablauf mit Beta-Versionen, Release Candidates (RC) und dem finalen Release. Die Termine stehen auf make.wordpress.org/core. Während der RC-Phase erscheint dort der „Field Guide“, eine Übersicht der wichtigsten Änderungen für Entwickler, einschließlich Änderungen, die bestehenden Code brechen können. Der Field Guide zu WordPress 7.1 erschien am 5. August 2026, das finale Release „Mary Lou“ am 19. August 2026, die Wartungsversionen 7.1.1 und 7.1.2 folgten am 17. und 22. September.

Diese Abfolge ist typisch und für Ihre Planung wichtig: Kurz nach einer Hauptversion erscheinen häufig Wartungsversionen mit Fehlerkorrekturen. Laut Core-Handbuch sind diese Minor-Releases für Fehlerkorrekturen und Verbesserungen gedacht. Für Unternehmenswebsites hat sich deshalb bewährt, nicht am Release-Tag umzustellen, sondern die erste Wartungsversion abzuwarten und in der Zwischenzeit zu testen.

Lesen Sie den Field Guide nicht Zeile für Zeile, sondern mit Blick auf Ihre Website. Bei 7.1 etwa betreffen die Abschnitte zur Mediathek (unendliches Scrollen als Standard in der Rasteransicht), zum erzwungenen Iframe-Editor und zum klassischen Block Websites, die viel mit Medien arbeiten oder ältere Editor-Erweiterungen nutzen.

Verifizieren: Sie kennen Release-Datum und aktuelle Wartungsversion der Zielversion und haben aus dem Field Guide eine kurze Liste der Punkte notiert, die Ihre Website betreffen könnten.

Schritt 2: Plugins und Themes inventarisieren

Die meisten Probleme nach einem Major-Update entstehen nicht im WordPress-Kern, sondern in Erweiterungen. Erstellen Sie deshalb eine vollständige Liste. Im Backend finden Sie sie unter „Plugins > Installierte Plugins“ und „Design > Themes“, per WP-CLI in einem Schritt:

wp plugin list --status=active --fields=name,version,update_version,auto_update
wp theme list --status=active --fields=name,version,update_version
wp plugin list --status=inactive --fields=name,version

Ergänzen Sie für jedes aktive Plugin, bis zu welcher WordPress-Version der Autor getestet hat. Die Angabe steht in der readme.txt im Feld „Tested up to“ und in der Detailansicht unter „Kompatibel bis zu“. Auf dem Server lesen Sie sie für alle Plugins auf einmal aus:

grep -H -m1 -i "Tested up to" wp-content/plugins/*/readme.txt

Im Labor ergab das vor dem Update auf 7.1:

wp-content/plugins/classic-editor/readme.txt:Tested up to: 7.0
wp-content/plugins/contact-form-7/readme.txt:Tested up to: 7.1
wp-content/plugins/akismet/readme.txt:Tested up to: 7.1

Ein Plugin mit „7.0“ ist damit nicht defekt, der Autor hat die neue Version nur noch nicht bestätigt. Solche Einträge gehören auf die Testliste. Markieren Sie außerdem jedes Plugin als geschäftskritisch oder nicht: Formulare, Shop, Zahlung, Buchung, Mitgliederbereich, Mehrsprachigkeit und Caching fallen fast immer in die erste Gruppe. Inaktive Plugins, die Sie nicht mehr brauchen, entfernen Sie am besten schon jetzt, denn jede überflüssige Erweiterung ist zusätzlicher Prüfaufwand.

Verifizieren: Die Liste enthält jedes aktive Plugin und Theme mit Version, „Tested up to“ und der Markierung geschäftskritisch ja oder nein. Nicht mehr genutzte Plugins sind entfernt.

Schritt 3: Einen Testplan für die geschäftskritischen Funktionen schreiben

Ein Test ohne Plan endet oft mit „Startseite lädt, passt“. Fehler zeigen sich aber im Formularversand, im Warenkorb oder im Editor. Schreiben Sie deshalb fünf bis zehn Prüfungen auf, die Sie vor und nach dem Update identisch durchführen. Beispiel für eine typische Firmenwebsite:

Prüfung	Erwartetes Ergebnis
Startseite, Leistungsseite, Impressum, Datenschutz aufrufen	Seiten laden vollständig, Layout unverändert
Kontaktformular absenden	Bestätigung erscheint, Nachricht kommt an
Beitrag im Editor öffnen, ändern, als Entwurf speichern	Editor lädt ohne Fehlermeldung, Speichern funktioniert
Bild in die Mediathek hochladen	Upload und Vorschaubilder werden erzeugt
Anmeldung als Redakteur	Login und Menü wie gewohnt
Shop: Testbestellung bis zur Zahlungsauswahl	Warenkorb und Kasse funktionieren
„Werkzeuge > Website-Zustand“	keine neuen kritischen Probleme

Führen Sie den Plan einmal vor dem Update durch und notieren Sie das Ergebnis. Nur so erkennen Sie später, ob ein Fehler neu ist oder schon vorher bestand. Aktivieren Sie auf der Staging-Kopie zusätzlich das Debug-Log, wie in der Anleitung zum WordPress-Debug-Modus beschrieben. Viele Warnungen zu veralteten Funktionen erscheinen nur dort.

Verifizieren: Der Testplan liegt schriftlich vor und wurde auf dem aktuellen Stand einmal vollständig durchlaufen, mit Ergebnis je Prüfung.

Schritt 4: Staging-Kopie vorbereiten und das Update dort einspielen

Die Staging-Kopie muss dem Live-System möglichst genau entsprechen: gleiche PHP-Version, gleiche Plugin-Versionen, aktueller Datenbankstand. Sonst testen Sie etwas anderes als das, was Sie später umstellen. Zwei Punkte werden dabei oft vergessen:

• Suchmaschinen aussperren: Unter „Einstellungen > Lesen“ aktivieren Sie „Suchmaschinen davon abraten, diese Website zu indexieren“. Per WP-CLI: wp option update blog_public 0. Zusätzlich schützt ein Passwortschutz auf Webserver-Ebene vor Zufallsbesuchern.
• Ausgehende Aktionen abschalten: Kopierte Shops und Formulare verschicken sonst echte E-Mails an Kunden oder lösen Zahlungen im Live-Modus aus. Stellen Sie Zahlungs-Plugins auf den Testmodus und leiten Sie E-Mails um oder unterdrücken Sie sie.

Legen Sie auf der Staging-Kopie ein Datenbank-Backup an und spielen Sie das Update ein:

wp db export ~/backup/staging-vor-major.sql
wp core update --version=7.1.2
wp core update-db
wp core verify-checksums
wp core version

Im Labor meldete WP-CLI nacheinander Success: WordPress updated successfully., Success: WordPress database already at latest db version 61833. und Success: WordPress installation verifies against checksums., die Versionsabfrage lieferte 7.1.2. Danach arbeiten Sie den Testplan aus Schritt 3 vollständig ab und aktualisieren anschließend die Plugins, für die neue Versionen mit Kompatibilitätsangabe erschienen sind.

Verifizieren: Die Staging-Kopie läuft mit der Zielversion, wp option get blog_public liefert 0, alle Prüfungen des Testplans sind bestanden oder als Befund mit Ursache notiert.

Schritt 5: Den Rückweg proben

Ein Plan B, der nie ausprobiert wurde, ist keiner. Proben Sie auf der Staging-Kopie, wie Sie zur alten Version zurückkommen. Dazu gehören zwei Teile: die Dateien des WordPress-Kerns und die Datenbank, denn ein Major-Update kann das Datenbankschema anheben.

wp core update --version=7.0.6 --force
wp db import ~/backup/staging-vor-major.sql
wp core version
wp core verify-checksums

Im Labor stand die Installation danach wieder auf 7.0.6, die Prüfsummen stimmten. Messen Sie, wie lange der Rückweg dauert. Diese Zahl brauchen Sie für die Entscheidung, in welchem Zeitfenster Sie live umstellen. Beachten Sie den Trade-off: Ein Datenbank-Import setzt auch alle Inhalte zurück, die seit dem Backup entstanden sind, etwa Bestellungen oder Formulareinträge. Auf der Live-Website planen Sie das Update deshalb in einer Zeit mit wenig Betrieb und legen das Backup unmittelbar davor an.

Verifizieren: Nach dem Rückweg zeigt wp core version die alte Version, wp core verify-checksums meldet Erfolg, und der Testplan läuft auf der Staging-Kopie wie vor dem Update.

Schritt 6: Live-Termin festlegen und Beteiligte informieren

Legen Sie den Termin für die Live-Umstellung fest, wenn drei Bedingungen erfüllt sind: Die Zielversion hat mindestens eine Wartungsversion, alle geschäftskritischen Plugins haben auf Staging funktioniert, und der Rückweg ist geprobt. Bis dahin halten Sie die Live-Website mit wp core update --minor auf dem neuesten Stand der alten Hauptversion. Im Labor antwortete WP-CLI auf 7.0.6 mit Success: WordPress is at the latest minor release., ein Sprung auf 7.1 fand nicht statt.

Informieren Sie alle, die an der Website arbeiten: Redaktion, Vertrieb, gegebenenfalls die Agentur, die das Theme betreut. Vereinbaren Sie, dass während des Zeitfensters niemand Inhalte ändert. Das Vorgehen am Umstellungstag selbst, von Backup bis Kontrolle, beschreibt die Anleitung zum sicheren Core-Update.

Diese Vorbereitung wiederholt sich mit jeder Hauptversion, 2026 waren das bisher 7.0 und 7.1, dazwischen kommen die laufenden Wartungs- und Plugin-Updates. Wer diesen Rhythmus nicht selbst im Kalender halten möchte, kann ihn abgeben: Die WordPress-Wartung von wordpressupdate spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein und sichert die Website wöchentlich auf externen Speicher.

Verifizieren: Der Live-Termin steht im Kalender, die Beteiligten sind informiert, und die Live-Website läuft bis dahin auf der neuesten Wartungsversion der alten Hauptversion.

Typische Fehler

• Am Release-Tag umgestellt: Fehler der neuen Version treffen Sie dann als Erster. Die erste Wartungsversion abzuwarten kostet wenige Wochen und nimmt Risiko heraus, sofern keine Sicherheitslücke drängt.
• Staging weicht vom Live-System ab: Andere PHP-Version, veraltete Plugins oder eine alte Datenbankkopie führen zu Tests, die nichts aussagen. Kopieren Sie den Live-Stand kurz vor dem Test neu.
• Staging im Suchindex: Ohne „Suchmaschinen davon abraten, diese Website zu indexieren“ und Passwortschutz erscheinen Testseiten in Suchergebnissen und erzeugen doppelte Inhalte.
• Rückweg nur mit Dateien: Ein Zurücksetzen der Core-Dateien ohne Datenbank-Import kann nach einer Schemaänderung Fehler verursachen. Zum Rückweg gehören beide Teile.
• Warnung zu fremden Dateien übersehen: wp core verify-checksums meldete im Labor zusätzlich Warning: File should not exist: wp-config-docker.php. Die Datei stammt aus dem Docker-Image und ist dort erwartbar. Auf einem normalen Webspace sollten Sie jede solche Meldung prüfen, weil unbekannte Dateien im Core-Verzeichnis auch auf eine Manipulation hindeuten können.
• Nur die Startseite getestet: Formulare, Kasse, Editor und Uploads zeigen Probleme früher als das Frontend. Der schriftliche Testplan verhindert das.

Häufige Fragen

Wie lange darf ich bei der alten Hauptversion bleiben?

Die Sicherheitsdokumentation auf developer.wordpress.org empfiehlt ausdrücklich, stets die neueste Version zu nutzen, und hält fest, dass ältere Versionen keine Sicherheitsupdates mehr erhalten. Ein paar Wochen Vorbereitung sind vertretbar, eine dauerhafte Verzögerung nicht. Halten Sie die alte Hauptversion bis zur Umstellung auf dem neuesten Wartungsstand.

Brauche ich das Plugin „WordPress Beta Tester“?

Nur, wenn Sie schon während der Beta- und RC-Phase testen möchten. Das Plugin (Version 4.0.1, getestet bis 7.1.2) stellt eine Website auf Nightly-, Beta- oder RC-Versionen um. Verwenden Sie es ausschließlich auf Staging, niemals auf der Live-Website.

Was, wenn ein geschäftskritisches Plugin auf Staging nicht funktioniert?

Verschieben Sie die Live-Umstellung, melden Sie den Fehler im Support-Forum des Plugins auf wordpress.org oder beim Hersteller und prüfen Sie, ob eine neue Plugin-Version erscheint. Ein Major-Update ist es nicht wert, das Kontaktformular oder die Kasse zu verlieren.

Gilt die Checkliste auch für Multisite-Installationen?

Im Grundsatz ja, der Aufwand steigt aber mit jeder Unterseite und jedem netzwerkweit aktivierten Plugin. Diese Anleitung wurde nur mit einer Einzelinstallation getestet.

Testumfang

Wir haben in einer Testinstanz ein WordPress mit einigen Plugins auf 7.1.2 aktualisiert und danach wieder auf den alten Stand zurückgesetzt. Für den Rückweg haben wir die alte Version mit --force eingespielt und den zuvor gesicherten Datenbank-Export wieder importiert.

Shop-Plugins, Multisite und die Staging-Funktionen einzelner Hoster haben wir nicht geprüft. Wenn Sie so etwas nutzen, probieren Sie das Vorgehen bitte zuerst auf einer Kopie Ihrer Seite aus.

Fazit

Ein Major-Update wird planbar, wenn Sie es wie ein kleines Projekt behandeln: Änderungen der neuen Version kennen, Erweiterungen inventarisieren, einen Testplan schreiben, zuerst auf Staging umstellen und den Rückweg proben. Mit diesen Vorarbeiten dauert die eigentliche Umstellung auf der Live-Website nur noch Minuten, und Sie wissen im Voraus, was im Fehlerfall zu tun ist. Wer die wiederkehrenden Updates und Backups dauerhaft abgeben möchte, findet bei der WordPress-Wartung von wordpressupdate eine persönliche Betreuung dafür.

Weiterführende Anleitungen und Quellen

• WordPress-Core-Updates sicher einspielen: Backup, Staging, Update und Kontrolle
• WordPress-Updates vor dem Einspielen prüfen: Changelogs lesen und Risiken einschätzen
• PHP-Version für WordPress aktualisieren
• WordPress Debug-Modus aktivieren
• Make WordPress Core: WordPress 7.1 Field Guide
• Core-Handbuch: Release Cycle
• Advanced Administration Handbook: Hardening WordPress
• WordPress-Dokumentation: Updating WordPress
• WP-CLI-Handbuch: wp core update