Headless WordPress: Wann lohnt sich die Trennung?

1,3 % Adoption, 3x Setup-Kosten, doppelte Infrastruktur. Headless WordPress verspricht Performance und Flexibilität – aber für die meisten KMU-Projekte ist es Overengineering. Zahlen, Pain Points und eine Checkliste.

Headless WordPress trennt das Backend (Inhalte, Redaktion, Plugins) vom Frontend (das, was Besucher sehen). WordPress liefert Daten per REST API oder WPGraphQL, ein separates Frontend in Next.js, Astro oder Nuxt rendert die Seiten. Das Versprechen: schnellere Ladezeiten, mehr Flexibilität, bessere Developer Experience. Die Realität: dreifache Kosten, doppelte Infrastruktur und eine lange Liste von Dingen, die kaputtgehen.

Dieser Artikel zeigt dir, wann Headless WordPress die richtige Architektur ist, wann du es besser lässt und was die Entscheidung konkret kostet. Keine Hype-Argumente, nur Zahlen und Praxiserfahrung aus DACH-KMU-Projekten.

Wie Headless WordPress funktioniert

Bei einer klassischen WordPress-Installation erledigt PHP alles: Inhalte aus der Datenbank holen, HTML zusammenbauen, an den Browser schicken. Theme, Plugins und Content leben auf demselben Server. Das ist einfach, bewährt und der Grund, warum WordPress 43 % des Webs antreibt.

Headless zerschneidet diese Verbindung. WordPress wird zum reinen Content-Management-System. Es speichert Texte, Bilder und Metadaten, stellt sie aber nicht mehr als fertige Webseite dar. Stattdessen fragt ein separates Frontend die Inhalte per API ab und rendert sie selbst.

In der Praxis sieht das so aus:

• Backend: WordPress mit deaktiviertem Theme, WPGraphQL oder REST API aktiv. Redakteure arbeiten weiterhin im bekannten WordPress-Dashboard.
• API-Schicht: REST (im Core enthalten, gut cachebar, Over-Fetching) oder GraphQL (exakte Queries, eine Anfrage für verschachtelte Daten, CPU-intensiver).
• Frontend: Eine separate Anwendung in Next.js, Astro, Nuxt oder einem anderen Framework. Läuft auf einem eigenen Server oder CDN.

Der Vorteil: Das Frontend ist nicht an PHP gebunden. Du kannst React-Komponenten bauen, Seiten statisch pre-rendern oder am Edge ausliefern. Der Nachteil: Alles, was WordPress normalerweise automatisch macht (Themes, Plugins, Preview, SEO-Tags), musst du im Frontend selbst implementieren. Für eine detaillierte Einordnung, wann sich WordPress oder Next.js für KMU eignet, haben wir einen separaten Vergleich.

Performance-Vergleich: Die Zahlen

Das stärkste Argument für Headless ist Performance. Aber die Unterschiede hängen vom Setup ab. Ein WordPress auf gutem Managed Hosting mit Caching ist kein lahmer Server. Ein schlecht konfiguriertes Headless-Setup ist kein Performance-Wunder.

TTFB (Time to First Byte) im Vergleich:

Die Unterschiede sind real, aber kontextabhängig. Ein WordPress auf einem 3,49-EUR-Hetzner-VPS mit Redis Object Cache und WP Super Cache liefert TTFB-Werte unter 200 ms. Das reicht für die meisten KMU-Websites. Headless lohnt sich bei Performance erst, wenn du Millionen Seitenaufrufe pro Monat hast, globale Auslieferung brauchst oder Echtzeit-Personalisierung im Frontend baust.

Für eine 20-Seiten-Unternehmenssite oder einen Blog mit 50 Artikeln ist der Performance-Unterschied zwischen gecachtem WordPress und Headless im Alltag nicht spürbar. Beide laden in unter einer Sekunde.

Kosten-Vergleich: Setup, Betrieb und 3-Jahres-TCO

Hier wird es teuer. Headless WordPress ist ein Architektur-Upgrade, kein Plugin. Die Kosten für eine Website steigen in jeder Phase.

Kostenfaktor	Traditionelles WP	Headless WP
Setup	3.000–5.000 EUR	15.000+ EUR
Stundensatz Entwicklung	40–80 EUR	80–150 EUR
Hosting/Monat	15–50 EUR	30–120 EUR (2 Services)
Wartung/Monat	50–150 EUR	150–400 EUR
3-Jahres-TCO	5.340–12.200 EUR	21.480–33.720 EUR

Die Rechnung: Ein traditionelles WordPress-Projekt kostet dich über drei Jahre zwischen 5.340 und 12.200 EUR (Setup + 36 Monate Hosting und Wartung). Ein Headless-Projekt landet bei 21.480 bis 33.720 EUR. Das ist Faktor 2,5 bis 3.

Die höheren Stundensätze kommen daher, dass Headless-Entwickler sowohl WordPress-Backend als auch moderne Frontend-Frameworks beherrschen müssen. React + WordPress + API-Design + Deployment-Pipelines: Das ist ein anderes Profil als jemand, der ein Starter-Theme anpasst. Dazu kommen doppelte Hosting-Kosten (WordPress-Server plus Frontend-Hosting bei Vercel, Netlify oder einem eigenen Node-Server) und doppelte CI/CD-Pipelines.

Die 5 größten Pain Points

Headless bricht Dinge, die bei traditionellem WordPress selbstverständlich sind. Bevor du dich für die Architektur entscheidest, solltest du diese fünf Probleme kennen:

1. Plugins funktionieren nicht. Contact Form 7, WPForms, Elementor, Divi, Yoast SEO, WooCommerce-Checkout-Seiten: Alles, was PHP-basiertes Frontend-Rendering braucht, fällt weg. Du kannst die Backend-Funktionalität über die API abfragen, aber das Frontend muss jedes Feature selbst bauen. Bei einem Shop mit 20 Plugins bedeutet das: 20 Features, die du im React-Frontend neu implementieren musst.

2. Preview ist kaputt. In traditionellem WordPress klickst du "Vorschau" und siehst die Seite so, wie Besucher sie sehen. Bei Headless zeigt dir Gutenberg ein ungenutztes Theme, nicht dein reales Frontend. Du musst eine eigene Preview-Route im Frontend bauen und mit WordPress verbinden. Das ist möglich (Faust.js macht das), aber Aufwand, den viele Projekte unterschätzen.

3. Jeder Gutenberg-Block braucht ein Frontend-Pendant. Du hast 30 Core-Blocks und 15 Custom-Blocks? Jeder einzelne muss im Frontend-Framework explizit gerendert werden. Neue Blocks, die Redakteure hinzufügen, erscheinen ohne Entwickler-Eingriff nicht auf der Website. Das schränkt die Redaktionsfreiheit ein.

4. SEO-Features musst du selbst bauen. Meta-Tags, Open-Graph-Daten, canonical URLs, XML-Sitemaps, Schema-Markup, hreflang-Tags: WordPress mit Yoast oder RankMath erledigt das per Klick. Im Headless-Setup musst du alles im Frontend implementieren. Das ist kein Hexenwerk, aber es kostet Zeit und vergessene Tags kosten Rankings.

5. Doppelte Infrastruktur. Zwei Server, zwei Deployments, zwei TLS-Zertifikate, zwei CI/CD-Pipelines, zwei Domains (oder Reverse-Proxy-Konfiguration). Wenn das WordPress-Backend down ist, liefert das Frontend keine neuen Inhalte. Wenn das Frontend down ist, sehen Besucher nichts. Du verdoppelst deine Angriffsfläche und deinen Wartungsaufwand. Wer schon bei einem Server ins Schwitzen kommt, sollte sich fragen, ob zwei Server die richtige Antwort sind.

REST API vs. WPGraphQL: Welche API-Schicht?

Wenn du dich für Headless entscheidest, brauchst du eine API. WordPress bringt die REST API ab Werk mit. WPGraphQL ist ein Plugin, das GraphQL-Endpunkte hinzufügt.

Kriterium	REST API	WPGraphQL
In WordPress Core	Ja	Nein (Plugin)
CDN-Caching	Gut (GET-Requests cachebar)	Schwieriger (POST-Requests)
Over-/Under-Fetching	Over-Fetching häufig	Exakte Queries möglich
Verschachtelte Daten	Mehrere Requests nötig	Ein Request reicht
Server-Last	Niedriger pro Request	Höher (Query-Parsing)
Lernkurve	Niedrig	Mittel

Für einfache Websites (Blog, Unternehmensseite) reicht die REST API. Für komplexe Datenstrukturen mit verschachtelten Custom Fields, Taxonomien und Beziehungen spart WPGraphQL Requests und Bandbreite. Die meisten Headless-Projekte in der Praxis nutzen WPGraphQL, weil die Flexibilität den Mehraufwand beim Caching kompensiert.

Welcher Stack für welches Projekt?

Falls du dich für Headless entscheidest, stehen drei Frontend-Stacks zur Wahl. Jeder hat sein Profil:

• Next.js + WP (Faust.js): Marktführer bei Headless WordPress. React-basiert, Server-Side Rendering, Incremental Static Regeneration. Großes Ökosystem, viele Tutorials. 40 %+ der Headless-WP-Entwickler nutzen React als Frontend-Framework. Ideal für Projekte mit interaktiven Features, Dashboards oder personalisierten Inhalten.
• Astro + WP: Perfekt für content-lastige Sites. Astro liefert standardmäßig Zero JavaScript an den Browser und lädt Frameworks nur dort, wo Interaktivität gebraucht wird. Schnellstes Setup für Blogs, Docs und Marketingseiten. Unsere eigene Website läuft auf Astro, allerdings ohne WordPress im Backend.
• Nuxt + WP: Für Teams, die Vue.js bevorzugen. Vergleichbare Features wie Next.js (SSR, SSG, ISR), aber mit Vue-Ökosystem. Kleinere Community im Headless-WP-Bereich, funktioniert aber zuverlässig.

Die Stack-Wahl hängt weniger vom Projekt ab als vom Team. Wenn deine Entwickler React können, nimm Next.js. Wenn Performance und einfache Architektur Priorität haben, nimm Astro. Wenn Vue das Hausmittel ist, Nuxt. Die Unterschiede im Ergebnis sind für Besucher kaum spürbar.

Checkliste: Wann lohnt sich Headless?

Beantworte diese fünf Fragen. Wenn du bei mindestens vier davon "Ja" sagst, ist Headless eine Überlegung wert. Bei zwei oder weniger bleibst du mit traditionellem WordPress besser dran.

Kriterium	Ja	Nein
Budget über 15.000 EUR für Setup?	✔	✘ Traditionelles WP reicht
Entwickler-Team mit React/Vue-Erfahrung?	✔	✘ Headless braucht Frontend-Devs
Multi-Channel (Web + App + Kiosk)?	✔	✘ Ein Kanal = kein Headless nötig
Redakteure kommen ohne Live-Preview aus?	✔	✘ Page-Builder-Bedarf = traditionell
100.000+ Seitenaufrufe/Monat?	✔	✘ Caching löst das günstiger

Typische Projekte, bei denen Headless Sinn macht: ein Medienunternehmen, das Inhalte auf Web, App und Newsletter gleichzeitig ausspielt. Ein E-Commerce-Projekt mit hochindividuellem Frontend und 500+ Produkten. Eine Plattform mit nutzergenerierten Inhalten und Echtzeit-Updates.

Typische Projekte, bei denen Headless keinen Sinn macht: eine 5-Seiten-Unternehmenswebsite. Ein Blog mit 30 Artikeln. Ein kleiner Shop unter 100 Produkten. Eine Website, die Redakteure selbständig per Page-Builder pflegen sollen. 80 % der DACH-Agenturprojekte im KMU-Bereich fallen in diese Kategorie, und das ist kein Zufall.

Fazit: Headless ist ein Werkzeug, kein Upgrade

Headless WordPress ist die richtige Architektur für Projekte, die Multi-Channel-Delivery, maximale Frontend-Kontrolle oder globale CDN-Auslieferung brauchen. Für alles andere ist es Overengineering mit 3x Kosten und 2x Komplexität.

Die Adoption liegt bei 1,3 % der Top-Sites, und die wächst zwar um 22 % pro Jahr, aber von einer sehr kleinen Basis. Die meisten WordPress-Projekte im DACH-KMU-Bereich profitieren mehr von gutem Hosting, sauberem Caching und einem durchdachten Theme als von einer Architektur-Revolution.

Wenn du dir unsicher bist, ob dein nächstes Projekt traditionell oder Headless laufen sollte: Wir beraten dich auf Basis deiner konkreten Anforderungen. Keine Architektur-Dogmen, keine Stack-Religion. Nur die Lösung, die für dein Budget und deine Ziele passt. Mehr zu unserem Ansatz findest du auf unserer Webentwicklung-Seite.