- Headless WordPress trennt das CMS komplett vom Frontend: WordPress liefert nur Daten per REST API oder WPGraphQL, ein separates JavaScript-Framework zeigt sie an.
- Das lohnt sich für Teams mit eigenem Frontend-Stack, App-plus-Web-Projekte oder extrem hohe Performance-Anforderungen.
- Für die meisten KMU ist Headless ein schlechter Tausch: doppeltes Hosting, kein Gutenberg-Komfort, viele Plugins funktionieren nicht mehr, und ein gut optimiertes klassisches WordPress erreicht dieselben Ladezeiten.
- Die ehrliche Entscheidungsregel: Wenn Sie keinen dedizierten Frontend-Entwickler haben, ist Headless fast immer das falsche Werkzeug.
Der Begriff klingt nach echter technischer Substanz: WordPress Headless, entkoppelte Architektur, JAMstack. In Entwickler-Blogs ist das seit Jahren ein heißes Thema, und in Kundengesprächen taucht es inzwischen auch bei kleineren Unternehmen auf. Die Frage dahinter ist eine wirtschaftliche: Lohnt sich dieser Umbau, oder kauft man sich damit vor allem Probleme?
Die meisten KMU brauchen kein Headless-WordPress. Sie scheitern nicht am Konzept, sondern daran, dass sie den Wartungsaufwand zweier entkoppelter Systeme unterschätzen. Ein gut gebautes, optimiertes klassisches WordPress löst das eigentliche Problem in fast allen Fällen.
Was WordPress Headless bedeutet
Im klassischen WordPress ist alles in einem System: PHP-Backend, Datenbank und das Theme, das HTML ausgibt, laufen zusammen. Seiten werden serverseitig gerendert und direkt ausgeliefert. Das funktioniert seit 20 Jahren zuverlässig.
Beim Headless-Ansatz wird dieser Verbund aufgetrennt. WordPress bleibt als Content-Management-System im Hintergrund, hat aber kein aktives Frontend mehr. Es gibt keine Theme-basierte Seitenausgabe. Stattdessen stellt WordPress seine Daten über eine Schnittstelle bereit, die REST API oder alternativ über WPGraphQL. Ein separates Frontend-Framework holt sich von dort die Inhalte und baut die Seiten eigenständig zusammen.
Das separate Frontend ist typischerweise ein JavaScript-Framework wie Next.js, Astro oder ein React-Projekt. Es kann als statische Seite auf einem CDN liegen oder als eigene Node.js-Anwendung laufen.
Das Bild, das in der Praxis hilft: Stellen Sie sich WordPress wie eine Bibliothek vor, die Bücher verwaltet und auf Anfrage Texte herausgibt. Das Frontend ist der Laden, der diese Texte aufbereitet und dem Kunden präsentiert. In der klassischen Installation sind Bibliothek und Laden ein Gebäude. Headless macht beides zu getrennten Gebäuden, die über einen Boten kommunizieren.
Wie die Architektur technisch funktioniert
Die WordPress REST API ist seit Version 4.7 (2016) fester Bestandteil des Systems. Sie liefert Beiträge, Seiten, Kategorien und benutzerdefinierte Felder als JSON-Daten an jede Anwendung, die danach fragt. Eine Anfrage an /wp-json/wp/v2/posts gibt die letzten Beiträge als strukturiertes JSON zurück, das ein Frontend direkt verarbeiten kann.
Das Frontend-Framework fragt bei jedem Seitenaufruf oder beim Build-Prozess die WordPress-API ab, rendert daraus HTML und liefert es an den Besucher. Das Rendering kann serverseitig (SSR), beim Build (statisch) oder im Browser (CSR) passieren. Welche Strategie die besten Performance-Ergebnisse bringt, beschreibt web.dev ausführlich.
Wann Headless wirklich Sinn macht
Es gibt echte Anwendungsfälle, in denen Headless das richtige Werkzeug ist. Sie sind weniger häufig, als die Diskussionen vermuten lassen, aber sie existieren.
App und Website aus einer Datenquelle. Wenn ein Unternehmen sowohl eine native App als auch eine Website betreibt und beide dieselben Inhalte zeigen sollen, macht eine zentrale API-Quelle Sinn. Redakteure pflegen Inhalte einmal in WordPress, und beide Kanäle holen sich die Daten. Das spart doppelten Pflegeaufwand, wenn die App-Entwicklung ohnehin stattfindet.
Eigenes Frontend-Dev-Team mit JavaScript-Kompetenz. Ein Unternehmen, das ohnehin React oder Next.js-Entwickler beschäftigt, kann davon profitieren, das Frontend im gewohnten Stack zu bauen. Die Voraussetzung ist, dass das Team tatsächlich da ist und die WordPress-API sauber in den eigenen Build-Prozess integrieren kann.
Sehr hohe Performance-Anforderungen mit statischem Build. Wenn eine Website mit statisch vorgenerierten Seiten auf einem CDN ausgeliefert wird, ist die Ladezeit theoretisch minimal. Kein PHP-Prozess, kein Datenbank-Query zur Laufzeit. Das ist für Nachrichtenportale mit unveränderlichem Inhalt interessant, weniger für eine KMU-Website, auf der sich Produkte, Preise und Öffnungszeiten ändern.
Strikte Entkopplung aus Sicherheitsgründen. Wenn WordPress vollständig vom öffentlichen Netz abgetrennt ist und nur intern als Redaktionssystem läuft, ist die Angriffsfläche kleiner. Das ist ein legitimes Sicherheitsargument für größere Installationen mit sensiblen Inhalten.
Was Headless kostet und was verloren geht
Hier ist der Teil, der in Entwickler-Blogs gern klein gehalten wird. Headless hat eine lange Liste echter Nachteile, die für KMU entscheidend sind.
Doppeltes Hosting. WordPress läuft weiterhin auf einem PHP-fähigen Server. Das Frontend braucht eine eigene Infrastruktur, typischerweise einen Node.js-Host oder einen CDN-Dienst wie Vercel oder Netlify. Das bedeutet zwei Systeme, zwei Abrechnungen, zwei Stellen, an denen etwas schiefgehen kann.
Gutenberg-Vorschau und Page Builder funktionieren nicht mehr. Der WordPress-Editor zeigt immer noch die Beiträge, aber eine Live-Vorschau, wie der Inhalt im fertigen Frontend aussieht, gibt es nicht ohne erheblichen Aufwand. Wer gewohnt ist, einen Beitrag zu speichern und sofort im Theme zu sehen, wie er wirkt, verliert diesen Komfort komplett. Divi, Elementor, WPBakery, all diese Page Builder sind in einer Headless-Installation sinnlos, weil sie Markup für ein WordPress-Theme erzeugen, das nicht mehr existiert.
Plugins funktionieren oft nicht mehr. Kontaktformulare, WooCommerce, SEO-Plugins wie Yoast, Mitgliedschaftstools, Buchungssysteme: Die meisten WordPress-Plugins erzeugen PHP-seitiges HTML und setzen das WordPress-Frontend voraus. In einer Headless-Installation sind sie entweder nutzlos oder müssen mühsam über die API nachgebaut werden. Wer seinen Shop über WooCommerce betreibt und auf Headless umstellt, muss den Checkout, die Produktseiten, den Warenkorb und die Bezahlabwicklung im Frontend selbst bauen oder eigene Headless-Plugins einsetzen.
Komplexe Build-Kette und Deployment. Jede Inhaltsänderung muss entweder einen neuen Build auslösen (bei statischen Sites) oder das Frontend kennt einen Weg, aktuelle Daten ohne Build abzurufen. Das klingt lösbar und ist es auch, aber es braucht Infrastruktur, die aufgebaut und gepflegt werden muss. Redakteure, die einen Beitrag speichern und dann warten, bis der neue Build fertig ist, sind keine Ausnahme, sondern der Normalfall.
Deutlich höhere Entwicklungskosten. Eine klassische WordPress-Website kann ein erfahrener Entwickler in bekanntem Terrain bauen. Eine Headless-Installation braucht zusätzlich solide Next.js- oder Astro-Kenntnisse, API-Architektur, Build-Pipelines, Caching-Strategien für das Frontend und oft Erfahrung mit Cloud-Deployments. Das multipliziert die Entwicklungszeit und die Stundensätze. Für einmalige Lösungen ist das selten wirtschaftlich.
Laufende Wartung ist aufwändiger. Zwei Systeme veralten. API-Breaking-Changes in WordPress können das Frontend brechen. Updates müssen koordiniert werden. Das ist strukturell mehr Aufwand als ein klassisches WordPress, das meist problemlos aktualisiert werden kann. Die wahren Betriebskosten steigen erheblich.
Klassisch vs. Headless: Die Entscheidungstabelle
| Kriterium | Klassisches WordPress | Headless WordPress |
|---|---|---|
| Hosting-Aufwand | Ein Server, ein System | WordPress-Server plus Frontend-Infrastruktur |
| Entwicklungskosten | Bekanntes Terrain, breiter Markt | Deutlich höher, spezialisiertes Know-how nötig |
| Plugin-Ökosystem | Fast alle Plugins nutzbar | Viele Plugins nicht kompatibel |
| Redakteur-Komfort | Vorschau, Page Builder, sofortige Wirkung | Eingeschränkt, Build-Verzögerung |
| Performance-Potenzial | Hoch mit Caching und gutem Hosting | Sehr hoch bei statischem Build auf CDN |
| Wartungsaufwand | Gering bis mittel | Höher, zwei Systeme |
| WooCommerce | Vollständig integriert | Muss im Frontend neu gebaut werden |
| Sinnvoll für KMU | Fast immer | Selten, klare Ausnahmen gibt es |
Alternativen für KMU ohne Entwickler-Team
Die meisten Performance-Probleme bei KMU-Websites haben andere Ursachen als die Architektur: zu schwaches Hosting, zu viele Plugins, große unkomprimierte Bilder, kein Caching. Diese Probleme löst Headless nicht, sie entstehen unabhängig von der Architektur.
Was tatsächlich hilft: ein auf Performance getrimmtes gutes Hosting, eine saubere Caching-Strategie und ein Theme ohne unnötigen Ballast. Wie das konkret aussieht, zeigt der Artikel WordPress Speed-Optimierung: Die 10 Maßnahmen mit dem besten Aufwand-Nutzen. Was Caching dabei leistet und wo die Grenzen liegen, lohnt ebenfalls ein Blick.
Für Unternehmen, die echte Web-App-Logik brauchen und dabei WordPress als Datenbasis nutzen wollen, ist eine hybride Lösung manchmal der bessere Kompromiss: Ein separates Tool oder eine kleine Custom-Anwendung greift per API auf WordPress zu, während der Haupt-Webauftritt klassisch bleibt. Das ist pragmatisch und hält die Wartbarkeit auf einem beherrschbaren Niveau.
Ein Beispiel aus der Praxis
In einem Projekt haben wir mit einem mittelständischen Unternehmen gesprochen, das von einer Agentur eine Headless-Lösung auf Basis von Next.js und WordPress angeboten bekommen hatte. Das Angebot klang technisch überzeugend. Im Gespräch stellte sich heraus: Das Unternehmen betreibt eine informationelle Website mit Produktkatalog, keine App, kein zweiter Kanal, zwei Redakteure ohne Entwicklungshintergrund. Der erhoffte Performance-Vorteil hätte sich mit einem CDN-fähigen Caching-Plugin auf der bestehenden Installation zu einem Bruchteil des Aufwands erzielen lassen.
Das Headless-Angebot war technisch korrekt, für diesen Fall aber klar überdimensioniert. Die zwei Redakteure hätten keine Vorschau mehr gehabt, das gewohnte Seitenbearbeitungs-Interface wäre verschwunden, und bei jedem strukturellen Inhaltsänderungswunsch wäre ein Entwickler nötig geworden. Wir haben zur klassischen Installation geraten, mit Caching, Bildoptimierung und gutem Hosting. Die Seite ist heute schnell und bleibt ohne Entwickler wartbar.
Das ist kein Einzelfall. Headless verkauft sich gut als Modernisierung, ist aber oft das falsche Werkzeug für die eigentliche Aufgabe.
Entscheidungs-Checkliste: Headless oder nicht?
- Haben Sie einen dedizierten Frontend-Entwickler mit JavaScript-Framework-Erfahrung?
- Betreiben Sie parallel eine native App, die dieselben Inhalte zeigen soll?
- Haben Sie eine konkrete Performance-Anforderung, die ein optimiertes klassisches WordPress nachweislich nicht erfüllt?
- Können Sie den höheren Entwicklungsaufwand und die dauerhaft höheren Betriebskosten wirtschaftlich rechtfertigen?
- Sind Sie bereit, auf Gutenberg-Vorschau, Page Builder und viele Plugins dauerhaft zu verzichten?
- Gibt es einen klaren Plan für die Build-Pipeline und das Deployment?
- Ist die Wartung langfristig gesichert, auch wenn der initiale Entwickler nicht mehr verfügbar ist?
Wer mehr als drei dieser Fragen mit Nein beantwortet, sollte bei klassischem WordPress bleiben und dort optimieren.
- Headless WordPress ist keine Modernisierung per se, sondern ein Architekturentscheid mit echten Kosten und Einschränkungen.
- Die Stärken liegen bei Multi-Kanal-Projekten, eigenem Dev-Team und statischen Inhalten mit sehr hohem Traffic.
- KMU ohne Frontend-Entwickler verlieren mehr, als sie gewinnen: Redakteur-Komfort, Plugin-Ökosystem, einfache Wartung.
- Ein gut optimiertes klassisches WordPress ist für die meisten KMU-Websites die bessere Wahl und bleibt dauerhaft beherrschbar.
Häufige Fragen
Was ist der Unterschied zwischen WordPress Headless und klassischem WordPress?
Im klassischen WordPress erzeugt PHP aus Datenbankinhalten direkt HTML, das der Browser anzeigt. Bei Headless WordPress übernimmt das ein separates Frontend-System, das Daten per REST API oder WPGraphQL aus WordPress abruft und eigenständig rendert. WordPress selbst hat kein aktives Theme mehr und keine öffentliche Seite.
Kann WooCommerce headless betrieben werden?
Technisch ja, aber mit erheblichem Aufwand. WooCommerce stellt eine REST API bereit, über die Produkte, Warenkorb und Bestellungen angesprochen werden können. Checkout, Zahlungsintegration und Nutzerkonto müssen im Frontend eigenständig implementiert werden. Das ist machbar für Teams mit dieser Erfahrung, aber für die meisten KMU keine wirtschaftlich sinnvolle Option.
Ist Headless WordPress schneller als klassisches WordPress?
Nicht automatisch. Ein statisch generiertes Headless-Frontend auf einem CDN kann extrem schnell sein. Ein schlecht gebautes Headless-Setup mit serverseitigem Rendering und schlechtem Caching kann langsamer sein als ein gut optimiertes klassisches WordPress mit Caching-Plugin und gutem Hosting. Architektur allein garantiert keine Performance.
Welche JavaScript-Frameworks werden mit WordPress Headless eingesetzt?
Am häufigsten Next.js, weil es serverseitiges Rendering, statische Generierung und eine ausgereifte Infrastruktur mitbringt. Astro ist eine gute Wahl für primär statische Seiten mit wenig JavaScript. React-Anwendungen ohne Next.js werden ebenfalls eingesetzt, erfordern aber mehr eigene Infrastrukturarbeit. Die Wahl des Frameworks hängt von den Anforderungen und der Teamkompetenz ab.
Funktionieren SEO-Plugins wie Yoast oder Rank Math bei Headless?
Teils. Diese Plugins können Meta-Daten und Schema-Informationen per REST API bereitstellen, die das Frontend dann in seinen HTML-Output einbaut. Das muss aber explizit implementiert werden. Die automatische Meta-Tag-Ausgabe, die diese Plugins im klassischen WordPress übernehmen, entfällt, weil kein WordPress-Frontend mehr gerendert wird.
Was ist WPGraphQL und wann ist es besser als die REST API?
WPGraphQL ist ein Plugin, das WordPress um einen GraphQL-Endpunkt erweitert. GraphQL erlaubt es, in einer einzigen Anfrage exakt die Felder abzurufen, die das Frontend braucht, ohne unnötige Daten zu laden. Das ist bei komplexen Frontends mit vielen verschachtelten Datenbeziehungen effizienter als mehrere REST-API-Aufrufe. Für einfachere Projekte ist die REST API ausreichend und einfacher einzurichten.
Lohnt sich Headless WordPress für eine kleine Firmenwebsite?
In fast allen Fällen nicht. Eine kleine Firmenwebsite mit einigen Seiten, einem Blog und einem Kontaktformular braucht keine entkoppelte Architektur. Der Entwicklungsaufwand ist unverhältnismäßig, der Redakteur-Komfort leidet und das Sicherheits- und Wartungsrisiko steigt. Ein schlankes, gut optimiertes WordPress erreicht hier dieselbe Nutzererfahrung zu einem Bruchteil des Aufwands.
Gibt es Hosting-Anbieter, die Headless WordPress vereinfachen?
Ja, einige Managed-WordPress-Hoster bieten integrierte Lösungen, bei denen WordPress als Backend und ein CDN-Dienst als Frontend-Host eng zusammenspielen. Das senkt den Infrastrukturaufwand, löst aber die grundlegenden Einschränkungen, zum Beispiel den Verlust des Plugin-Ökosystems, nicht. Auch beim besten Hoster bleibt Headless ein Architekturentscheid mit seinen inhärenten Kompromissen.