WordPress 7.0 Update-Checkliste: Welche Anforderungen deine Website jetzt erfüllen muss

7.0 bringt die Abilities-API, DataViews an der Stelle der klassischen Listenansichten und ein neu gebautes Admin-Interface. Zwei Dinge, die lange als Kernfeatures angekündigt waren, sind es nicht geworden: die Echtzeit-Kollaboration wurde zwölf Tage vor dem Release gestrichen, die client-seitige Medienverarbeitung in Beta 6 zurückgenommen. Für Betreiber zählt ohnehin eine andere Frage: 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üf deine aktuelle Konfiguration im Dashboard unter Werkzeuge > Website-Zustand > Bericht. Dort siehst du 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 alle Login-Bereiche

PHP-Memory-Limit

Mindestens 256 MB, bei vielen Plugins eher 512 MB

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üf 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.

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. Aktivier auf einer Staging-Umgebung WP_DEBUG und beobacht 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

1. Vollständiges Backup: Datenbank und Dateisystem, getestete Wiederherstellung. Ohne Backup kein Update.
2. PHP-Version prüfen: Im Hosting-Panel oder per php -v. Bei Bedarf vorab auf PHP 8.3 anheben.
3. Site-Health-Check: Im Dashboard alle kritischen Probleme lösen, bevor das Update startet.
4. Plugins aktualisieren: Alle Plugins auf die neueste Version, Changelogs auf 7.0-Kompatibilität prüfen.
5. Nicht genutzte Plugins löschen: Jedes inaktive Plugin ist ein potenzielles Sicherheits- und Kompatibilitätsrisiko.
6. Staging-Klon erstellen: Update zuerst auf einer 1:1-Kopie der Live-Site testen.
7. Deprecation-Warnungen prüfen: Mit aktivem WP_DEBUG alle Seiten und kritischen Workflows durchgehen.
8. Frontend prüfen: Layouts, Formulare, Suche, WooCommerce-Checkout, Login, Kontaktformular, alles testen.
9. 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 beobacht 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 solltest du warten?

Der Release liegt zurück, dein Update-Termin ist er damit nicht automatisch. Die Wartezeit staffelt sich nach Risiko, und die Staffel gilt bei jeder Major-Version gleich:

• Rein redaktionelle Sites ohne komplexe Plugins: 1 bis 2 Wochen. In dieser Zeit arbeiten Plugin-Hersteller Hotfixes ein, und bekannte Probleme landen im ersten Patch-Release.
• Viele Plugins oder eigener Code im Admin: 2 bis 3 Wochen, bis die Plugin-Autoren nachgezogen haben.
• Geschäftskritische E-Commerce-Site oder Multi-User-Redaktion: 4 bis 6 Wochen.

Stand September 2026 ist diese Frist längst verstrichen: Die 7.0-Reihe endete mit 7.0.4 am 12. August, seit dem 19. August steht 7.1. Wer 7.0 jetzt noch vor sich hat, plant den Sprung sinnvollerweise gleich auf die aktuelle Version und liest dazu die Breaking Changes in 7.1.

Fazit

Das WordPress-7.0-Update ist kein Klick auf „Aktualisieren“. Die Arbeit liegt vorher: PHP-Version, Plugin-Kompatibilität, Theme und Custom Code geprüft, damit der Aufwand vorher bekannt ist und nicht erst, wenn die Seite steht. Wie sich derselbe Ablauf über mehrere Installationen hinweg organisieren lässt, steht in WordPress-Updates sicher ausrollen.

---