Inhalt
Am 20. Mai 2026 ist mit WordPress 7.0 „Armstrong“ das umfangreichste Release seit Jahren erschienen — mit einem KI-Client direkt im Core, serverseitig registrierten Blöcken und einem überarbeiteten Editor (WordPress.org, Release-Ankündigung). Für klassische WordPress-Sites ist das ein grosses Update. Für ein entkoppeltes Setup stellt sich aber eine andere Frage: Was davon betrifft überhaupt Ihr Frontend — und was bleibt reine Backend-Angelegenheit?
Was ist neu in WordPress 7.0 Armstrong?
Die sichtbarsten Neuerungen betreffen Redaktion und Entwicklung, nicht die Auslieferung:
- Ein KI-Client im Core: eine provider-agnostische Schnittstelle, über die WordPress mit generativen Modellen kommuniziert, samt Abilities API für Inhalts-Workflows.
- Serverseitige Blockregistrierung: einfache Blöcke und Patterns lassen sich neu rein in PHP registrieren — ohne JavaScript-Build-Schritt.
- Ein modernisiertes Dashboard mit Command Palette (⌘K), neue Blöcke (Lightbox-Galerie, Heading, Breadcrumbs, Icons) und eine zentrale Schriftverwaltung.
- Unter der Haube: ein neues
@wordpress/boot-Paket, ein überarbeitetes@wordpress/scripts, Routing im Site-Editor und diverse Library-Updates (WordPress 7.0 Field Guide).
Was davon betrifft Ihr entkoppeltes Frontend?
In einem Headless-Setup bleibt WordPress das Backend, und Ihr Frontend bezieht Inhalte über REST oder WPGraphQL. Genau dieser Vertrag ändert sich mit 7.0 grundsätzlich nicht: Posts, Medien und Felder liegen weiter in WordPress, Ihr Next.js-Frontend rendert sie selbst.
Das bedeutet: Der Dashboard-Umbau, die Command Palette, die Schriftverwaltung und die neuen Editor-Blöcke betreffen die Redaktionsoberfläche — nicht die ausgelieferte Seite. Wie Gutenberg-Inhalte im entkoppelten Frontend ankommen, behandelt der Beitrag zu Gutenberg-Blöcken im Headless-Frontend; an diesem Prinzip ändert 7.0 nichts Grundlegendes.
Der KI-Client im Core — was heisst das für Headless?
Die strategisch interessanteste Neuerung ist der KI-Client im Core. WordPress bringt damit eine standardisierte, provider-agnostische Schnittstelle mit, über die sich generative Modelle anbinden lassen — plus eine Abilities API, die Inhalts-Workflows und Automatisierung zugänglich macht (WordPress 7.0 Field Guide).
Für ein Headless-Setup ist das aus zwei Gründen relevant. Erstens laufen diese Funktionen backend-seitig — also dort, wo ohnehin Ihre Inhalte liegen. Zweitens entsteht ein einheitlicher Ort für KI-gestützte Redaktionsschritte, statt verstreuter Einzel-Plugins. Ob und wie Sie das nutzen, ist eine inhaltliche Entscheidung; technisch sichtbar wird es im Frontend nur, wenn Sie die erzeugten Inhalte ausspielen. Wie Inhalte für Suchmaschinen wie ChatGPT, Perplexity und Gemini zitierbar werden, ist ein eigenes Thema — behandelt im Beitrag zu Headless WordPress in KI-Suchmaschinen.
Was Sie vor dem Update testen sollten
Auch wenn das Frontend entkoppelt ist: Ein Major-Release testet man nicht in Produktion. Der offizielle Field Guide dokumentiert die Breaking Changes für Entwickler — die folgende Liste übersetzt sie in die Punkte, die in einem Headless-Projekt zählen.
| Bereich | Warum prüfen | Konkret |
|---|---|---|
| API-Anbindung (REST/WPGraphQL) | Library-Updates und Plugin-Kompatibilität | Build gegen 7.0 auf Staging, alle Queries durchspielen |
| Eigene Blöcke | Geänderte Blockregistrierung, neues @wordpress/scripts | Block-Ausgabe in der API und Rendering im Frontend prüfen |
| Plugins der API-Schicht | Müssen 7.0-kompatibel sein | Auf aktuelle Versionen heben, Changelogs lesen |
| Redaktions-Workflow | Der Editor-Umbau betrifft das Team | Redaktion auf Staging durchklicken lassen |
Wie sich ein WordPress-Update ohne Überraschungen durchziehen lässt, zeigt der Beitrag zu den Stolperfallen bei der Headless-Migration.
Nächster Schritt
Sie planen das Update auf WordPress 7.0 oder ein neues Headless-Projekt und wollen die Architektur sauber aufsetzen? Vereinbaren Sie ein Erstgespräch — 15 Minuten, kostenlos. Einen Überblick über unser Vorgehen finden Sie auf der Seite Leistungen.