Im vorherigen Beitrag zu WordPress 7.0 habe ich beschrieben, was sich mit dem Major-Release verändert: Echtzeit-Kollaboration, die Abilities-API, DataViews und client-seitige Medienverarbeitung. Dieser Artikel geht einen Schritt weiter und beantwortet die wichtigste Frage für Website-Betreiber: Ist meine Website überhaupt bereit für das Update?

Anders als kleinere Minor-Updates greift 7.0 an mehreren Stellen tief in den Core ein. Plugins, die Beitrags-Listenansichten verändern, Themes mit eigenen Patterns und Code-Snippets mit veralteten Funktionen können brechen. Die folgende Checkliste basiert auf den offiziellen Dev-Notes und dem Test-Guide aus Februar 2026.

Server-Anforderungen: Was die Maschine können muss

Die offizielle Mindestanforderung steigt auf PHP 7.4, das WordPress-Core-Team empfiehlt jedoch ausdrücklich PHP 8.3 oder neuer. Wer noch auf PHP 7.2 oder 7.3 läuft, muss zuerst die PHP-Version anheben, bevor das Update möglich ist. Für die neue AI-Client-API ist PHP 8.1+ technisch erforderlich.

Prüfen Sie Ihre aktuelle Konfiguration im Dashboard unter Werkzeuge > Website-Zustand > Bericht. Dort sehen Sie PHP-Version, MySQL-Version, Speicher-Limits und Plugin-Warnungen auf einen Blick.

Die wichtigsten Anforderungen im Überblick

PHP-Version: Mindestens 7.4, empfohlen 8.3 oder höher
MySQL / MariaDB: MySQL 8.0+ oder MariaDB 10.5+ (ältere Versionen funktionieren noch, werden aber nicht mehr empfohlen)
HTTPS: Pflicht für Echtzeit-Kollaboration und für alle Login-Bereiche
PHP-Memory-Limit: Mindestens 256 MB, bei aktiver Kollaboration 512 MB empfohlen
HTTP-Polling: Standard-Synchronisation läuft über HTTP, optional WebSocket-Provider

Plugin-Kompatibilität: Wo es typischerweise bricht

Die gefährlichste Stelle beim Update auf 7.0 sind Plugins. Mehrere Architekturänderungen können bestehende Erweiterungen lahmlegen, ohne dass im Dashboard eine Warnung erscheint. Prüfen Sie vor dem Update besonders folgende Plugin-Kategorien:

Plugins mit Custom Listenansichten

DataViews ersetzt die klassischen Listenansichten für Beiträge, Seiten und Medien. Plugins, die dort eigene Spalten oder Filter einfügen, müssen angepasst werden. Betroffen sind unter anderem Yoast SEO (Snippet-Spalten), Advanced Custom Fields (ACF-Felder in Listen), WooCommerce (Produktlisten) und viele Custom-Post-Type-Plugins.

Klassische Meta-Boxen und Real-Time Collaboration

Klassische Post-Meta-Boxen werden bei aktiver Echtzeit-Kollaboration nicht synchronisiert. Wenn zwei Redakteure gleichzeitig an einem Beitrag arbeiten und unterschiedliche Werte in eine Meta-Box eintragen, kann der zuletzt gespeicherte Wert den anderen überschreiben. Das ist eine echte Datenverlust-Gefahr in Redaktionsteams.

Auch der Core/Freeform-Block (klassischer HTML-Editor) ist mit der Echtzeit-Kollaboration inkompatibel. Wenn Sie noch Inhalte mit dem Classic-Editor pflegen, können diese in 7.0 beim parallelen Bearbeiten Probleme verursachen.

Block-Plugins mit eigenen Patterns

Unsynced Patterns laufen in 7.0 standardmäßig im contentOnly-Modus. Block-Attribute, die nicht explizit als Content markiert sind, lassen sich nicht mehr direkt editieren. Für selbst entwickelte Gutenberg-Blocks mit Timber/Twig bedeutet das: Block-Attribute brauchen "role": "content", sonst können Redakteure sie im Pattern nicht mehr ändern.

Verse-Block wird zu Poetry-Block

Der bisherige core/verse heißt in 7.0 core/poetry. Im Hintergrund läuft eine automatische Migration, aber Plugins oder Themes, die den Block-Namen hart codiert haben (etwa in Block-Filtern oder allowedBlocks-Listen), müssen aktualisiert werden.

Theme-Kompatibilität prüfen

Auch Themes brauchen unter Umständen Anpassungen. Block-Themes mit eigenen Patterns sollten vor dem Update im Staging getestet werden. Klassische Themes laufen weiter, profitieren aber nicht von den neuen Features wie der Font Library für klassische Themes.

Pattern-Inhalte: Erreichen Redakteure noch alle Stellen, die sie editieren müssen?
Block-Visibility: Themes, die blockVisibility als Boolean parsen, müssen die neue Objekt-Struktur unterstützen
Allowed-Blocks-Listen: Verweise auf core/verse auf core/poetry umstellen
Script-Registrierung: Veraltete defer-Option durch strategy ersetzen

Custom Code: Deprecated Functions finden

Eigene Code-Snippets in functions.php, MU-Plugins oder benutzerdefinierten Plugins sollten gegen die Deprecation-Warnungen von 7.0 geprüft werden. Aktivieren Sie auf einer Staging-Umgebung WP_DEBUG und beobachten Sie die Logs:

// wp-config.php auf Staging
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', true);

Im Log unter wp-content/debug.log erscheinen alle Aufrufe veralteter Funktionen mit Stacktrace. So lassen sich Problemquellen präzise identifizieren, bevor sie auf der Live-Site auftreten.

Die Vorbereitungs-Checkliste in 9 Schritten

Vollständiges Backup: Datenbank und Dateisystem, getestete Wiederherstellung. Ohne Backup kein Update.
PHP-Version prüfen: Im Hosting-Panel oder per php -v. Bei Bedarf vorab auf PHP 8.3 anheben.
Site-Health-Check: Im Dashboard alle kritischen Probleme lösen, bevor das Update startet.
Plugins aktualisieren: Alle Plugins auf die neueste Version, Changelogs auf 7.0-Kompatibilität prüfen.
Nicht genutzte Plugins löschen: Jedes inaktive Plugin ist ein potenzielles Sicherheits- und Kompatibilitätsrisiko.
Staging-Klon erstellen: Update zuerst auf einer 1:1-Kopie der Live-Site testen.
Deprecation-Warnungen prüfen: Mit aktivem WP_DEBUG alle Seiten und kritischen Workflows durchgehen.
Frontend prüfen: Layouts, Formulare, Suche, WooCommerce-Checkout, Login, Kontaktformular — alles testen.
Performance messen: Lighthouse-Score vor und nach dem Update vergleichen, siehe WordPress Performance Lighthouse 90+.

Was nach dem Update zu tun ist

Auch nach dem erfolgreichen Update ist die Arbeit nicht beendet. In den ersten 14 Tagen beobachten Sie die Website besonders aufmerksam. Typische Probleme zeigen sich oft erst bei spezifischen Workflows oder bei bestimmten Seitentypen.

Search Console: 404-Fehler, Crawl-Probleme und Indexierungs-Auffälligkeiten beobachten
Google Analytics / Plausible: Bounce-Rate und Verweildauer auf vorherige Werte vergleichen
Server-Logs: PHP-Errors und 500er-Statuscodes prüfen
Editor-Workflow: Redakteure aktiv nach Problemen fragen, sie sehen oft als erste Auffälligkeiten

Wann sollten Sie warten?

Der Release am 20. Mai 2026 ist nicht zwingend Ihr Update-Termin. Bei Major-Versionen empfehle ich grundsätzlich, mindestens 1 bis 2 Wochen abzuwarten. In dieser Zeit arbeiten Plugin-Hersteller Hotfixes ein, und bekannte Probleme werden in einem 7.0.1-Release adressiert.

Wer eine geschäftskritische E-Commerce-Site, eine Multi-User-Redaktion oder Custom-Code-intensive Installation betreibt, sollte sogar 4 bis 6 Wochen warten. Für rein redaktionelle Sites ohne komplexe Plugins ist das Risiko geringer, hier reicht ein abgesicherter Test im Staging.

Update sicher durchführen lassen

Das WordPress-7.0-Update ist kein Klick auf "Aktualisieren". Wer eine produktive Website betreibt, sollte das Update nicht ungetestet einspielen. Ich biete einen kostenfreien Update-Check: Ich prüfe PHP-Version, Plugin-Kompatibilität, Theme und Custom Code Ihrer Website und gebe Ihnen eine ehrliche Einschätzung des Aufwands. Das Angebot ist transparent, ohne versteckte Kosten oder Pauschalen, die nicht zu Ihrer Site passen.

Mehr Hintergrund zur kommenden Version finden Sie im Feature-Überblick zu WordPress 7.0. Wenn Sie laufende Wartung suchen, lohnt sich ein Blick auf meine WordPress-Wartungspakete, in denen Major-Updates mit Staging-Test inklusive sind.