Headless WordPress: Was es ist und wann sich der Mehraufwand lohnt

💡 Kurzfassung:
Was ist das? WordPress verwaltet die Inhalte, während eine separate Frontend-Anwendung sie über REST oder GraphQL abruft und für Besucher darstellt.
Wann passt es? Wenn dieselben Inhalte mehrere Kanäle versorgen, das Frontend Anwendungslogik oder unabhängige Releases benötigt und das Team zwei Systeme betreiben kann.
Was kostet es? Performance und Sicherheit entstehen nicht automatisch. Plugins aus der Theme-Schicht, Vorschauen, Weiterleitungen, Metadaten, Formulare und die Aktualisierung zwischengespeicherter Inhalte müssen ausdrücklich umgesetzt werden.

Headless WordPress behält WordPress als Inhalts-Backend bei, während eine separate Frontend-Anwendung das darstellt, was Besucher sehen. Diese Architektur kann richtig sein, wenn Inhalte mehrere Produkte erreichen sollen, die öffentliche Oberfläche eher einer Anwendung gleicht oder das Frontend unabhängig veröffentlicht werden muss. Als pauschales Performance-Upgrade für einen Blog oder eine einfache Unternehmenswebsite ist sie selten gerechtfertigt.

Klassisches WordPress verbindet bereits ein ausgereiftes CMS, ein Theme-System und ein Plugin-Ökosystem in einer Bereitstellung. Genau diese Integration ist sein größter Vorteil. Headless lohnt sich nur, wenn die Anforderungen an die Auslieferung schwerer wiegen als das, was WordPress bereits automatisch bereitstellt.

Was ist Headless WordPress?

Eine CMS-Architektur, die Inhaltsverwaltung und Darstellung trennt, wird allgemein als Headless CMS bezeichnet. Bei Headless WordPress verbleiben Administrationsbereich, Inhalte, Benutzer und Medien in WordPress. Die Inhalte werden über die integrierte REST API oder ein GraphQL-Plugin bereitgestellt; ein separates Frontend übernimmt Routing und Darstellung. Die Dokumentation der WordPress REST API beschreibt dieselbe Schnittstelle als Möglichkeit, WordPress-Inhalte in eigene Frontends und andere Anwendungen zu übernehmen.

Warum Headless WordPress?

Vorteile von Headless WordPress

Headless WordPress bietet folgende Vorteile:

Wird statt eines fertigen Themes ein individuelles Design entwickelt, kann sich das Frontend-Team auf die clientseitige Entwicklung konzentrieren, ohne individuelle WordPress-Themes oder die Backend-Strukturen von WordPress beherrschen zu müssen. Für das Frontend lässt sich jeder Technologie-Stack wählen, sogar unterschiedliche Stacks für verschiedene Zielgeräte.
Die enge Kopplung von Frontend und Backend entfällt. Eine Frontend-Anwendung kann Daten aus mehreren Quellen beziehen, darunter ein oder mehrere WordPress-Backends.
Weil Frontend und Backend entkoppelt sind, lassen sie sich unabhängig skalieren.
Eine Quelle kann mehrere Kanäle versorgen. Website, mobile Anwendung und andere Clients können dieselbe API nutzen.

Vergleich: Klassisches WordPress und Headless WordPress

Merkmal	Klassisches WordPress	Headless WordPress
Entwicklungsgeschwindigkeit	Schnell, wenn Themes und Plugins die Anforderungen erfüllen	Mehr Anfangsaufwand, da Frontend und Integrationen individuell entwickelt werden
Ladegeschwindigkeit	Mit schlankem Theme und wirksamem Caching schnell möglich	Mit SSG, SSR und CDN-Caching schnell möglich, aber von der Umsetzung abhängig
Gestaltungsfreiheit	Innerhalb des Theme-, Block- und Plugin-Ökosystems	Mehr Kontrolle für das Frontend-Team, verbunden mit der Verantwortung für diesen Code
Sicherheit	Eine Anwendungsoberfläche, die weiterhin bei Themes, Plugins und Server abgesichert werden muss	Kann die öffentliche WordPress-Oberfläche reduzieren, ergänzt aber APIs, Frontend-Abhängigkeiten, Token und Bereitstellungsflächen
Omnichannel-Unterstützung	Über APIs und Integrationen möglich	Von Grund auf für mehrere Clients ausgelegt, die dieselbe Inhalts-API nutzen

Wann eignet sich Headless WordPress nicht?

Nachteile von Headless WordPress

Headless WordPress kann sowohl beim Budget als auch bei der Zeit teurer sein. Warum?

Eine klassische WordPress-Installation liefert Plugins, Themes und zentrale Funktionen zur Website-Verwaltung direkt mit. Eine Headless-Architektur erfordert dagegen eine eigene Frontend-Entwicklung. Auch im Backend braucht es Entwickler oder ein Team mit Erfahrung in Headless-Konfigurationen und individuellen REST-/GraphQL-Integrationen.
Für Backend und Frontend können getrennte Server-Infrastrukturen erforderlich sein. Kleine Installationen können zwar auf einem Server laufen, bei einer einfachen Website sollte man dennoch prüfen, ob Headless wirklich nötig ist.
WordPress-Plugins verhalten sich in einer Headless-Installation nicht alle gleich. Plugins, die Daten im Backend verwalten, können weiter funktionieren, wenn diese Daten über die API verfügbar sind. Plugins, die Markup oder Skripte über die Theme-Schicht einfügen, visuelle Seitenerstellung ermöglichen oder voraussetzen, dass WordPress die öffentliche Seite rendert, benötigen eine eigene Frontend-Integration. Der ACF-Leitfaden zu Headless WordPress erläutert diesen Unterschied ausführlicher.

Was Headless-Entwickler wissen müssen

Als ich meine Website erstmals von klassischem WordPress wegführte, setzte ich zunächst auf eine Headless-WordPress-Architektur. Das Backend war eine gewöhnliche WordPress-Instanz, die Daten über GraphQL bereitstellte; das Frontend entstand mit Next.js (React.js). (Hinweis: Die aktuelle Version dieser Website wurde inzwischen auf ein vollständig statisches Nuxt.js-System migriert.)

Eine vergleichbare WordPress-Website hätte mit einem klassischen Theme in drei bis vier Tagen fertig sein können. Der Aufbau der ersten Headless-Version dauerte dagegen mehr als einen Monat. Unter anderem musste ich folgende Aufgaben selbst übernehmen, statt mich auf die Theme- und Plugin-Schicht zu verlassen:

Ich implementierte eine GraphQL-basierte API, weil mir die Standard-REST-API bei komplexen Schemata umständlicher erschien.
Eigene Inhaltstypen, benutzerdefinierte Felder und Mehrsprachigkeit sind in klassischem WordPress unkompliziert. In einer Headless-Installation müssen sie einzeln abgefragt und ihre Beziehungen im Frontend manuell zugeordnet werden. Beispiel: Yoast SEO zu installieren genügt nicht. Sie müssen die Metadaten über die API abrufen und die passenden Tags selbst im Dokumentkopf des Frontends ausgeben.
Code oder Skripte, die ein Plugin gewöhnlich über das WordPress-Theme einfügt, erscheinen im getrennten Frontend nicht automatisch. Die benötigten Daten müssen bereitgestellt und die entsprechende Ausgabe selbst gerendert werden.
Weiterleitungen benötigen eigene Routing-Logik im Frontend. In klassischem WordPress würden Sie diese bequem über Yoasts Weiterleitungsfunktion oder das Plugin Redirection verwalten. Da die Frontend-Anwendung den Besucher empfängt, muss sie die Weiterleitung ausführen; dafür ist abgestimmter Code in Frontend und Backend nötig.
Das Plugin Redirection erfasst und protokolliert 404-Fehler in einer klassischen Installation automatisch. Nun müssen Sie Code schreiben, der diese Fehler im Frontend erkennt und im Backend die Erstellung eines Protokolleintrags auslöst.
Formulare, die sonst einfache Plugins abwickeln, werden komplexer. Sollen Formulare dynamisch im Backend gepflegt statt fest im Code hinterlegt werden, benötigen Sie eigene Logik für Abruf, Darstellung, Validierung und Übertragung der Formulardaten.
Die WordPress-Vorschau entspricht standardmäßig nicht mehr dem öffentlichen Frontend. Entwürfe benötigen eine authentifizierte Verbindung zwischen WordPress und Frontend sowie eine zuverlässige Darstellung unveröffentlichter Inhalte.
Werden Seiten im Frontend vorab gebaut oder zwischengespeichert, bedeutet eine Veröffentlichung in WordPress nicht automatisch, dass Besucher die Änderung sofort sehen. Sie brauchen einen Webhook oder einen Revalidierungsprozess und müssen erkennen können, wenn dieser scheitert.
Sie können nicht mehr einfach ein Plugin installieren und sofortige Funktion erwarten. Ist eine Plugin-Funktion wesentlich, müssen Sie wahrscheinlich Integrationscode auf beiden Seiten schreiben. In manchen Fällen ist es sinnvoller, die Funktion neu zu entwickeln.

Obwohl ich die Headless-Umstellung zeitweise bereute, arbeitete ich mich durch die Herausforderungen, weil ich gern neue Konzepte lerne und Entwicklungsprobleme löse.

Für einen persönlichen Blog oder eine einfache Unternehmenswebsite ist Headless WordPress meist komplexer als nötig. Eine Prüfung lohnt sich, wenn dieselben Inhalte mehrere Produkte oder Kanäle versorgen müssen, das Frontend Anwendungslogik oder unabhängige Releases benötigt, ein messbarer Engpass bei Rendering oder Skalierung besteht und das Team beide Systeme warten kann. Hoher Traffic oder E-Commerce allein genügen nicht. Headless Commerce verlagert zusätzlich Warenkorbstatus, Checkout, Sitzungen und Erweiterungsintegrationen in das individuelle Frontend.

Headless-WordPress-Entwicklung

Meine Erfahrung war Full Stack: Ich entwickelte sowohl die WordPress-Backend-API als auch den Next.js-Code des Frontends. Der Prozess war anspruchsvoll, aber lehrreich. Ich plane eigene Beiträge zu den Umsetzungsschritten vieler dieser Funktionen. Diese Leitfäden werden nur ein Ausgangspunkt sein. Eigene Recherche und praktische Versuche bleiben nötig.

Ich freue mich, Sie in den nächsten Beiträgen dieser Reihe wiederzusehen.