WordPress betreibt nach wie vor einen beachtlichen Teil des Webs – aber die Art, wie Unternehmen die Plattform einsetzen, verschiebt sich. Statt WordPress sowohl Inhalte als auch Darstellung überlassen, trennen immer mehr Teams beides bewusst: WordPress kümmert sich ums Verwalten der Inhalte, ein separates Frontend um die Darstellung. Dieses Prinzip nennt sich „Headless WordPress“ – auch wenn „Decoupled“ technisch treffender wäre, denn WordPress hat immer ein Theme-System im Rücken, selbst wenn es ungenutzt bleibt.
Bislang war der Umstieg oft ein Kompromiss: mehr Performance und Flexibilität, aber auch mehr Komplexität, doppelte Infrastruktur und der Verlust vertrauter Editor-Funktionen wie der Live-Vorschau. Mit WordPress 7.0, veröffentlicht am 9. April 2026, hat sich diese Rechnung an mehreren Stellen spürbar verändert.
Was „Headless“ konkret bedeutet
In einer klassischen WordPress-Installation übernimmt eine einzige Software drei Aufgaben gleichzeitig: das Admin-Interface, die Datenhaltung und das Ausliefern von HTML-Seiten per PHP-Theme. Im Headless-Modell wird dieser letzte Schritt herausgelöst. WordPress bleibt Backend für Beiträge, Seiten, Nutzer, Taxonomien, Medien und benutzerdefinierte Felder – ausgeliefert wird der Inhalt aber über eine API, meist REST oder WPGraphQL. Ein separates Frontend, gebaut mit Next.js, Astro, Nuxt oder SvelteKit, holt sich die Daten und entscheidet eigenständig, wie sie dargestellt werden.
Der Vorteil: Das Redaktionsteam arbeitet weiter im gewohnten WordPress-Editor. Das Entwicklungsteam kann mit modernem Tooling arbeiten, auf Edge-Infrastruktur ausliefern und ist nicht länger an Theme-PHP gebunden.
Was sich mit WordPress 7.0 tatsächlich geändert hat
Drei neue Core-Bausteine machen den Unterschied für Headless-Setups aus.
Abilities API. Bislang waren WordPress-Berechtigungen an Nutzerrollen gebunden (edit_posts, manage_options und so weiter) – praktikabel für Menschen im wp-admin, unhandlich für externe Anwendungen, die oft nur eine einzige, klar umrissene Aktion ausführen sollen. Die Abilities API, in 6.9 eingeführt und mit 7.0 stabilisiert, ersetzt dieses Modell durch eine maschinenlesbare Registry einzelner Fähigkeiten wie create-draft oder generate-excerpt, jede mit eigener Ein-/Ausgabe-Schema-Definition und eigener Berechtigungsprüfung. Für ein Headless-Frontend bedeutet das: Es lässt sich exakt eine Fähigkeit freischalten, statt ein komplettes Editor-Konto samt Token zu vergeben.
Connectors API. Bisher baute jedes Plugin seine eigene Einstellungsseite für API-Schlüssel. Die neue Connectors API bündelt externe Serviceanbindungen zentral unter Einstellungen > Connectors. Zum Start sind KI-Anbieter wie OpenAI, Anthropic und Google eingebunden, das Muster funktioniert aber für jede Art von Zugangsdaten – Analytics, Zahlungsdienstleister, Suche, Mail. Für einen Headless-Stack heißt das: WordPress bleibt die zentrale Quelle für Integrationen, das Frontend muss keine eigenen Geheimnisse verwalten.
AI Client. Während Connectors die Zugangsdaten verwalten, nutzt der neue AI Client sie. Die Funktion wp_ai_client_prompt() ist eine anbieterunabhängige PHP-Schnittstelle, über die jedes Plugin einen Prompt gegen das vom Administrator gewählte Modell ausführen kann – ohne den Anbieter fest im Code zu verdrahten.
php
$response = wp_ai_client_prompt(
'Fasse diesen Blogartikel in zwei Sätzen zusammen: ' . $post_content
);Kombiniert eröffnet das etwas Praktisches: Ein externer Client kann abfragen, welche Fähigkeiten eine WordPress-Site anbietet, sie gezielt aufrufen, und die Site entscheidet selbst, wie sie diese ausführt – gegebenenfalls über einen Connector bis hin zu einem LLM. Genau dafür ist das Model Context Protocol gedacht, und ein offizieller MCP-Adapter macht aus jeder WordPress-Instanz einen MCP-Server.
Was sich für Headless-Projekte konkret verbessert
- Saubere Authentifizierung: Ein Frontend erhält ein auf einzelne Fähigkeiten begrenztes Token statt einer Nutzerrolle mit breiten Rechten. Ein kompromittiertes Token verursacht entsprechend weniger Schaden, Rotation wird unkritischer.
- Weniger Eigenbau: Für KI-Funktionen im Frontend – Zusammenfassungen, Alt-Texte, Übersetzungen, semantische Suche – muss kein eigener Endpunkt mit eigenem Schlüsselmanagement mehr gebaut werden. Eine Fähigkeit wird registriert, das Frontend ruft sie auf, WordPress routet zum konfigurierten Anbieter.
- Bessere Performance ab Werk: REST-Antworten unterstützen im Core standardmäßig Conditional GET (ETag,
If-None-Match) und Gzip, wodurch CDNs und Frontends korrekt cachen, ohne dass eigene Header gesetzt werden müssen. WPGraphQL 2.x bringt Persisted Queries und Dataloader-Batching mit, was verschachtelte Post-Meta-Abfragen spürbar entlastet. - Nachvollziehbare KI-Anbindung: Ein Agent kann prüfen, was eine Site tatsächlich kann, nicht nur, welche Beiträge existieren – aus „Schreibe einen Entwurf zu Thema X“ wird eine Abfolge regulärer API-Aufrufe statt einer proprietären Integration.
REST API oder WPGraphQL
Beide Ansätze haben ihre Berechtigung. Die REST API eignet sich, wenn der Weg des geringsten Widerstands gefragt ist, wenn genutzte Plugins ohnehin nur REST-Endpunkte mitbringen oder wenn das Frontend lediglich eine Handvoll Collections benötigt – WordPress-Core hat hier in den letzten Versionen spürbar nachgelegt: konsistente Paginierung, Conditional Requests, verlässliche Rechteprüfung.
WPGraphQL lohnt sich, sobald Seiten tief verschachtelte Daten in einer einzigen Anfrage benötigen – ein Beitrag mit Autor, Beitragsbild, verwandten Artikeln und mehreren Ebenen benutzerdefinierter Feldgruppen zieht über REST schnell viele Einzelanfragen nach sich, die eine einzelne GraphQL-Query ersetzt. WPGraphQL 2.x gilt inzwischen als praxiserprobtes Standard-Plugin.
Wichtig ist, sich für einen Ansatz zu entscheiden und ihn konsequent zu nutzen, statt beide parallel zu betreiben.
Wann sich Headless lohnt – und wann nicht
Headless ist kein Ersatz für klassisches WordPress, sondern eine zusätzliche Option für bestimmte Situationen:
Sinnvoll, wenn ein und derselbe Content mehrere Ausgabekanäle bedient – Website, App, Kiosksystem; wenn ein Design-System mit einer Produkt-App geteilt wird; wenn Performance-Budgets mit klassischem PHP-Theming nicht mehr erreichbar sind; wenn mehrere Backends – etwa WordPress für Content, ein Shop-System für Commerce, ein CRM für Mitgliederverwaltung – über ein gemeinsames Frontend zusammengeführt werden sollen; oder wenn das Redaktionsteam am WordPress-Editor hängt, das Entwicklungsteam aber nicht in Theme-PHP arbeiten möchte.
Eher nicht sinnvoll, bei einer kleinen Unternehmenspräsenz, einem einzelnen Blog oder einem einfachen WooCommerce-Shop – der Koordinationsaufwand zwischen zwei Codebasen übersteigt hier schnell den Performance-Gewinn. Auch bei kleinen, bereits ausgelasteten Teams ist Vorsicht angebracht: Headless verdoppelt die Angriffsfläche an Verantwortlichkeiten – Frontend-Deployments, Preview-Workflow, Cache-Invalidierung bei Content-Änderungen, Auth-Fluss zwischen beiden Seiten müssen jeweils eigenständig betreut werden. Und wer stark auf theme-gebundene Plugins, Page-Builder oder bestimmte WooCommerce-Erweiterungen setzt, sollte prüfen, ob diese sich überhaupt sauber über eine API abbilden lassen – viele setzen intern voraus, innerhalb eines WordPress-Themes zu rendern.
Ein hybrider Ansatz deckt oft den Mittelweg ab: statisch generierte Seiten aus WordPress, während klassisches WordPress parallel einen Bereich wie /shop oder /account bedient. Es muss nicht alles oder nichts sein.
Fazit
Headless WordPress ist 2026 ein anderes Werkzeug als noch vor zwei Jahren. Die mit Version 7.0 eingeführten Bausteine – Abilities API, Connectors API und AI Client – lösen reale Probleme rund um Authentifizierung, Integrationsaufwand und KI-Anbindung, die den Ansatz bisher unnötig komplex gemacht haben. Das ändert nichts daran, dass Headless für die meisten kleinen und mittleren WordPress-Sites weiterhin die falsche Wahl ist. Für Unternehmen mit mehreren Ausgabekanälen, klaren Performance-Anforderungen oder einem Frontend-Team, das lieber in modernem JavaScript-Tooling als in Theme-PHP arbeitet, ist der Ansatz aber inzwischen deutlich praxistauglicher geworden als früher.
Wenn Sie prüfen möchten, ob sich ein Headless-Setup für Ihre WordPress-Website lohnt – von der technischen Machbarkeitsanalyse bis zur konkreten Umsetzung mit modernem Frontend – sprechen Sie uns gerne an.
