Headless WordPress: Entkoppeltes Frontend verstehen und erkennen

Headless WordPress bezeichnet eine Architektur, bei der WordPress als Content-Management-System und Datenquelle fungiert, das eigentliche Frontend aber von einem separaten System übernommen wird. Das CMS und die Darstellungsschicht sind voneinander getrennt, was dem Konzept den Namen gegeben hat: Der “Kopf” (das Frontend) ist abgetrennt vom “Rumpf” (dem Backend).

Warum Headless WordPress?

Die klassische WordPress-Architektur koppelt Backend und Frontend fest zusammen. Themes steuern das Erscheinungsbild, PHP rendert die HTML-Seiten serverseitig, und der Browser empfängt fertige Seiten. Das ist für viele Anwendungsfälle ausreichend, bringt aber Einschränkungen mit sich: PHP-Rendering kann bei hoher Last zum Flaschenhals werden, Themes begrenzen die gestalterische Freiheit, und das Zusammenspiel mit modernen JavaScript-Frameworks ist aufwendig.

Headless WordPress löst diese Einschränkungen, indem WordPress nur noch folgende Aufgaben übernimmt:

• Inhalte verwalten und speichern
• Benutzern und Redakteuren eine vertraute Bearbeitungsoberfläche bieten
• Inhalte über eine API bereitstellen

Das Frontend wird separat entwickelt, als eigenständige Anwendung, und kommuniziert mit WordPress ausschließlich über Schnittstellen.

REST API: die klassische Schnittstelle

WordPress liefert seit Version 4.7 eine eingebaute REST API. Unter dem Endpunkt /wp-json/wp/v2/ sind alle Inhaltstypen abrufbar:

• /wp-json/wp/v2/posts gibt Beiträge zurück
• /wp-json/wp/v2/pages gibt statische Seiten zurück
• /wp-json/wp/v2/media gibt Mediendateien zurück
• /wp-json/wp/v2/categories gibt Kategorien zurück

Die API gibt JSON-Daten zurück und unterstützt Filterung, Paginierung und authentifizierte Anfragen für nicht-öffentliche Inhalte. Das Frontend fragt diese Endpunkte ab und rendert die Inhalte selbstständig.

Ein Headless-Setup ist daran erkennbar, dass diese Endpunkte auf dem WordPress-Backend erreichbar sind, das sichtbare Frontend aber keine klassischen WordPress-Merkmale aufweist. Wer die Domain einer Website kennt, kann prüfen, ob unter einem separaten Backend-Pfad eine WordPress-REST-API erreichbar ist.

WPGraphQL: flexiblere Datenabfragen

Eine Alternative zur REST API ist GraphQL, implementiert durch das WPGraphQL-Plugin. Während die REST API feste Endpunkte mit vordefinierten Datenstrukturen liefert, erlaubt GraphQL präzise Abfragen: Das Frontend fordert exakt die Felder an, die es benötigt, nicht mehr und nicht weniger.

WPGraphQL stellt einen einzigen Endpunkt bereit, üblicherweise unter /graphql. Abfragen werden als POST-Anfragen mit einer Query-Syntax geschickt:

query \{
  posts \{
    nodes \{
      title
      excerpt
      slug
    \}
  \}
\}

Dieses Modell ist besonders attraktiv für komplexe Inhaltsstrukturen mit vielen verschachtelten Beziehungen, zum Beispiel Beiträge mit Autoren, Kategorien, Tags und Mediendateien.

Typische Frontend-Stacks

In der Praxis werden mit Headless WordPress vor allem folgende Frameworks kombiniert:

Next.js ist die beliebteste Wahl. Es unterstützt sowohl statische Generierung (Static Site Generation) als auch serverseitiges Rendering und bietet eine gute Integration mit der WordPress-REST-API und WPGraphQL.

Gatsby war lange Zeit der Standard für WordPress-Headless-Projekte, hat aber seit dem Aufstieg von Next.js an Popularität verloren. Gatsby stützt sich stark auf GraphQL und eignet sich besonders für statische Websites.

Nuxt.js ist das Vue.js-Pendant zu Next.js und wird in Headless-WordPress-Projekten eingesetzt, wenn das Entwicklungsteam Vue bevorzugt.

Astro gewinnt an Bedeutung, da es minimales JavaScript ausliefert und flexibel zwischen statischer Generierung und Server-Rendering wechseln kann.

Erkennungsmerkmale im Frontend

Ein vollständig entkoppeltes Frontend enthält in der Regel keine klassischen WordPress-Signale mehr. Das bedeutet:

• Keine wp-content/-Pfade in Stylesheet- oder Skript-URLs
• Keine elementor-*-Klassen oder WordPress-Body-Klassen
• Kein wp-includes/-Verzeichnis in Asset-Pfaden
• Keine WordPress-spezifischen Cookies

Was bleibt, sind gelegentlich schwache Signale:

• Ein X-Powered-By: WordPress-Header, falls das Backend Anfragen direkt beantwortet
• Ein offener /wp-json/-Endpunkt auf einer Subdomain, die das Backend hostet
• Generator-Meta-Tags wie <meta name="generator" content="WordPress 6.x">, falls das Theme diese ausgibt (in Headless-Setups oft deaktiviert)

Der Analyzer erkennt WordPress anhand der Signale, die im gelieferten HTML des Frontends vorhanden sind. Ist das Frontend vollständig entkoppelt, fehlen diese Signale. Eine Erkennung des zugrunde liegenden CMS ist dann nur möglich, wenn das Backend direkt analysiert wird.

Vor- und Nachteile des Headless-Ansatzes

Headless WordPress bringt klare Vorteile für bestimmte Anforderungen:

• Performance: Das Frontend kann als statische Seite vorgebaut und über ein CDN ausgeliefert werden. Server-Rendering-Zeiten für PHP entfallen.
• Technologiefreiheit: Das Entwicklungsteam wählt das Frontend-Framework nach fachlichen Kriterien, unabhängig vom CMS.
• Skalierbarkeit: Frontend und Backend können getrennt skaliert werden. Das CMS-Backend bleibt unsichtbar für Besucher.

Die Nachteile sind nicht unerheblich:

• Komplexität: Zwei getrennte Systeme müssen deployiert, aktualisiert und überwacht werden.
• Echtzeit-Inhalte: Vorgebaufte statische Seiten erfordern einen Rebuild-Prozess, wenn sich Inhalte ändern. Cache-Invalidierung wird zum Kernproblem.
• Kosten: Hosting für zwei Systeme, ein Build-System und ein CDN summieren sich.
• Plugin-Kompatibilität: Viele WordPress-Plugins setzen ein klassisches Theme voraus und funktionieren im Headless-Betrieb nicht oder nur eingeschränkt.

Headless WordPress ist kein Allzweckwerkzeug. Es eignet sich besonders für Websites mit hohem Traffic, strikten Performance-Anforderungen und Teams, die bereits in modernen JavaScript-Ökosystemen arbeiten. Für kleinere Websites und Projekte ohne diese spezifischen Anforderungen überwiegen in der Regel die Nachteile.