Die meisten Artikel über Headless WordPress werden von Tool-Anbietern geschrieben, die versuchen, Sie von ihrem Stack zu überzeugen. Das ist nicht das. Nach Headless-Migrationen und Greenfield-Builds für Kunden in den letzten zwei Jahren ist hier, was tatsächlich 2026 funktioniert, was nicht, und die Fallstricke, die die meisten Projekte zum Entgleisen bringen.WordPress are written by tool vendors trying to sell you on their stack. This is not that. After running headless migrations and greenfield builds for clients in the last two years, here is what actually works in 2026, what does not, and the pitfalls that derail most projects.
Kernaussage: Headless WordPress nutzt WordPress als Content-Backend mit einem Next.js- oder Astro-Frontend; verwende es nur, wenn du Performance oder Architektur benötigst, die klassische Themes nicht leisten können.Headless WordPress uses WordPress as the content back end with a Next.js or Astro front end; use it only when you need performance or architecture classic themes cannot deliver.
Schnelle Definitionen, dann der eigentliche Inhalt
Headless WordPress bedeutet, WordPress rein als Content-Backend zu nutzen. Das Admin-Interface und die Datenbank bleiben. Die PHP-gerenderte Theme-Schicht entfällt. Eine separate Frontend-Anwendung – normalerweise Next.js, Astro, SvelteKit oder Nuxt – ruft Inhalte über REST oder GraphQL ab und rendert die öffentliche Website.Next.js, Astro, SvelteKit, or Nuxt -- fetches content via REST or GraphQL and renders the public site.
Entkoppelt und headless bedeuten in der Praxis grob dasselbe. Manche unterscheiden, dass entkoppelt das WordPress-Frontend als Fallback verfügbar hält. 2026 spielt die Unterscheidung für Entscheidungsträger, die das lesen, keine echte Rolle.
Warum diese Diskussion 2026 anders ist
Die Headless-Diskussion 2020 drehte sich um Performance. WordPress-Themes waren langsam, JavaScript-Frameworks fühlten sich schnell an, und Headless sah wie die Lösung aus. Diese Framing ist heute weitgehend überholt. Moderne Block-Themes erfüllen Core Web Vitals zuverlässig. Headless ist nicht mehr der einzige Weg zu einer schnellen WordPress-Site.
Die Frage 2026 geht also nicht um Geschwindigkeit. Es geht um die Organisationsstruktur. Headless gewinnt, wenn du eine scharfe Trennung zwischen redaktioneller Autonomie und Engineering-Kontrolle brauchst. Es verliert, wenn die Trennung mehr Arbeit schafft, als sie spart.
Die Stack-Landschaft 2026
Die Mainstream-Stacks für Headless WordPress dieses Jahr:
Next.js + WPGraphQL (am häufigsten)
Immer noch der Standard für ernsthafte Headless-WordPress-Projekte. WPGraphQL ist ausgereift, das Faust.js-Framework vereinfacht Preview Mode und Authentifizierung, und die Vercel-Bereitstellung ist gut dokumentiert. Die beste Wahl, wenn du bereits ein Next.js-Engineering-Team hast oder Komponenten mit einer Next.js-App teilen möchtest.
Astro + WPGraphQL oder REST (wächst schnell)
Astro ist meine Standard-Empfehlung für inhaltsgesteuerte Headless-WordPress-Projekte im Jahr 2026 geworden. Es hat standardmäßig null JavaScript auf dem Client, was bedeutet, dass LCP-Scores wie statisches HTML aussehen. Die Integration mit WordPress ist unkompliziert – Astro ruft zur Build-Zeit oder über On-Demand-Rendering ab, und du erhältst React-, Svelte- oder Vue-Komponenten nur dort, wo du tatsächlich Interaktivität brauchst.
SvelteKit + REST (Nische, aber wachsend)
Wenn dein Team bereits in Svelte arbeitet, ist SvelteKit + WordPress REST API eine saubere Paarung. Kleinere Community als der Next.js-Weg, aber die Developer Experience ist hervorragend und die Runtime ist klein.
Nuxt + WPGraphQL (Vue-Shops)
Vue-first-Organisationen bekommen eine ähnliche Story wie Next.js mit Nuxt 3. Produktionsreif, gut dokumentiert, und die Vue-Community ist gesund. Wähle dies, wenn du Vue-Engineers hast, sonst nutze Next.js oder Astro als Standard.
WPGraphQL oder REST: was man verwenden sollte
Verwende WPGraphQL als Standard, es sei denn, du hast einen spezifischen Grund, es nicht zu tun. Die Datenstruktur ist vorhersehbarer, du rufst nur die Felder ab, die du brauchst, und die meisten modernen Frontend-Frameworks haben erstklassiges GraphQL-Tooling.
REST ist immer noch die richtige Antwort, wenn dein Projekt klein ist, dein Editorial-Team sehr wenige Custom Fields nutzt, oder du mit einem System integrierst, das bereits REST spricht. Die WordPress-Core-REST-API ist zuverlässig. Sie ist nur ausschweifend bei komplexen Queries.
Eine Sache zu beachten: Falls du Advanced Custom Fields nutzt, brauchst du WPGraphQL für ACF. Die kostenlose Version von WPGraphQL stellt ACF-Felder nicht zur Verfügung. Die Pro-Lizenz kostet etwa 250 USD pro Jahr und lohnt sich bei jedem größeren Projekt.
Echte Performance-Zahlen aus einer kürzlichen Migration
Im letzten Quartal haben wir eine 400-seitige B2B-Marketing-Website von einem Standard-WordPress-Theme zu einem Headless-Setup migriert. Die Zahlen, vorher und nachher:
- LCP: 2,8s → 0,7s (75 Prozent Verbesserung)
- CLS: 0,18 → 0,01 (praktisch eliminiert)
- Time to Interactive: 5,1s → 1,2s
- Gesamtseitengröße: 3,2MB → 480KB
- Build-Zeit: von Theme-Deploys zu einem 4-Minuten-Frontend-Build (akzeptabler Kompromiss)
Stack verwendet: WordPress auf Kinsta, WPGraphQL, Next.js auf Vercel mit ISR. Die Migration dauerte 11 Wochen für ein kleines Team und kostete etwa 90.000 USD all-in. Die Hosting-Kosten sanken nach der Migration, weil der mittlere Kinsta-Plan den bisherigen überdimensionierten dedizierten Server ersetzte.
Hosting: wo Headless-Deployments eigentlich hingehen
Headless teilt dein Hosting in zwei Teile auf. Beide spielen eine Rolle.
WordPress-Backend-Hosting
- Kinsta: unsere Standardwahl für Client-Backends, je nach Traffic etwa 35 bis 600 USD/Monat
- WP Engine: unternehmensfreundlich, tiefere Integrationen, ähnliche Preisklasse
- Cloudways: günstigere Option für kleinere Projekte, etwa 15 bis 80 USD/Monat
- Selbstverwaltung auf Hetzner oder DigitalOcean: am günstigsten, aber du trägst die operative Last
Frontend-Hosting
- Vercel: beste Next.js-Experience, kostenloser Tier für kleine Sites, skaliert bis Enterprise
- Netlify: stark für Astro und SvelteKit, großzügiger kostenloser Tier, ähnliche Preisgestaltung wie Vercel
- Cloudflare Pages: günstigster bei größerem Umfang, schnellster globaler Edge, etwas weniger polierte DX
Die monatlichen Gesamtkosten für eine typische Mid-Market-Headless-WordPress-Site liegen bei beiden Hosting-Providern zwischen 100 und 400 USD. Das ist wettbewerbsfähig mit All-in-One-Managed-WordPress, teilweise günstiger bei höherem Traffic.
Die fünf Fallstricke, die die meisten Headless-Projekte scheitern lassen
1. Vorschaumodus ist schwieriger als erwartet
Bei traditionellem WordPress klicken Redakteure auf Vorschau und sehen ihren Beitrag. Bei Headless erfordert die Vorschau eine funktionierende Verbindung zwischen WordPress-Admin und Frontend, normalerweise mit einem Draft-API-Endpoint und Token-Austausch. Faust.js kümmert sich darum für Next.js. Für Astro und SvelteKit musst du es selbst bauen. Kalkuliere mindestens einen Sprint ein.
2. Plugin-Kompatibilitätslotterie
Jedes WordPress-Plugin geht davon aus, dass es das Frontend kontrolliert. Yoast SEO gibt Meta-Tags aus. Gravity Forms rendert HTML. Die meisten E-Commerce-Plugins nehmen Seiten-Level-Templating an. Bei Headless replizierst du entweder die Frontend-Ausgabe des Plugins selbst, oder wählst die kleine Menge an Plugins, die schön mit REST und GraphQL spielen. Überprüfe deine Plugin-Liste, bevor du dich auf Headless festlegst.
3. Editor-Disconnect
Bei traditionellem WordPress zeigt der Admin ungefähr, wie die öffentliche Website aussieht. Bei Headless können Admin und Live-Site auseinanderdriften. Redakteure veröffentlichen und die Änderung erscheint zwei Minuten später auf dem Frontend – oder gar nicht, wenn die Build-Pipeline unterbrochen ist. Das ist eine Workflow-Änderung, kein technisches Problem, und es braucht explizite Kommunikation.
4. Build-Zeit im großen Maßstab
Static Site Generation funktioniert wunderbar bis zu einigen tausend Seiten. Bei 10.000 Seiten dauern Builds 20+ Minuten. Bei 100.000 Seiten brauchst du Incremental Static Regeneration oder On-Demand-Rendering, was die Komplexität erhöht. Plane deine Rendering-Strategie, bevor die URL-Zahl wächst.
5. Authentifizierung und geschützte Inhalte
WordPress handhabt Authentifizierung von Haus aus. Bei Headless musst du entweder WordPress-Auth durch das Frontend proxyen, einen separaten Auth-Provider wie Auth0 oder Clerk nutzen, oder Session-Synchronisation zwischen beiden aufbauen. Nichts davon ist schnell eingerichtet. Wenn deine Website kostenpflichtige Inhalte, geschützte Downloads oder nur für Mitglieder zugängliche Bereiche hat, rechne mit zwei bis vier Wochen Engineering-Aufwand.
Wann du NICHT zu Headless gehen solltest
Das ist der Abschnitt, den die meisten Artikel überspringen. Ehrliche Fälle, in denen ich Clients sage, sie sollen bei traditionellem WordPress bleiben:
- Dein Editorial-Team macht mehr als die Hälfte deines Content-Aufkommens aus
- Du veröffentlichst mehr als 10 Posts pro Woche mit häufigen Bearbeitungen
- Dein Engineering-Team besteht aus zwei Personen oder weniger
- Dein Traffic liegt unter 100.000 monatlichen Besuchen und Core Web Vitals bestehen bereits
- Du verlässt dich auf Plugins, die keine guten Headless-Äquivalente haben (LMS-Plugins, komplexe Membership-Systeme)
Wenn du von einem Enterprise-CMS wie Sitecore oder Typo3 kommst, ist die Headless-Frage oft verfrüht. Steig erst auf Standard-WordPress um, dann bewerte Headless nach 12 Monaten. Das Sitecore- und Typo3-zu-WordPress-Migrations-Playbook behandelt die erste Phase dieser Reise.Sitecore and Typo3 to WordPress migration playbook covers the first leg of that journey.
Wenn Headless gewinnt
Fälle, in denen ich Headless ohne zu zögern empfehle:
- Front-End-Performance ist ein messbarer Umsatztreiber (E-Commerce, konversionsoptimierte Landing Pages)
- Du teilst Komponenten mit einer separaten Next.js oder Astro App
- Dein redaktioneller Rhythmus und dein Engineering-Rhythmus müssen vollständig getrennt sein
- Du musst mehrere Frontends bedienen – Web, Mobile App, Kiosks – von einem Content-Backend aus
- Du migrierst von einem langsamen WordPress-Build weg und ein vollständiger Theme-Rebuild kostet mehr als ein Headless-Rebuild
Der minimal viable Headless WordPress Stack
Wenn du heute anfängst und den Weg mit dem niedrigsten Risiko willst, ist das der Stack, auf den ich mich einlassen würde:
- Backend: WordPress auf Kinsta Starter Plan
- Plugins: WPGraphQL, WPGraphQL for ACF, ACF Pro, Yoast SEO, the WP Headless plugin
- Frontend: Astro 6 für Content-Sites, Next.js 15 für App-ähnliche Sites
- Frontend-Hosting: Vercel für Next.js, Netlify oder Cloudflare Pages für Astro
- Bildverwaltung: WordPress für Upload, Cloudinary oder das Host-CDN für Auslieferung
- Formulare: externer Formulare-Provider (Tally, Formspark) statt Gravity Forms
Dieses Setup kostet für eine kleine Site etwa 100 USD/Monat, skaliert sauber bis zum Mid-Market und vermeidet die häufigsten Fallstricke.
Wie Seahawk Headless-Projekte handhabt
Wir haben Headless-WordPress-Sites für Clients im SaaS-, B2B-Services- und Ecommerce-Bereich gebaut und gepflegt. Durchschnittliche Projektgröße ist 8 bis 14 Wochen. Wir setzen standardmäßig auf Astro oder Next.js, je nach Team. Wenn du durchgehen möchtest, ob Headless für deine Situation passt, kontaktiere uns -- wir gehen deinen Stack, dein Team und deine Roadmap durch und sagen dir ehrlich, ob sich Headless auszahlt.get in touch -- we will walk through your stack, your team, and your roadmap, and tell you honestly whether headless will pay off.
Weiterführende Lektüre
→WordPress vs Next.js in 2026: mein ehrlicher VergleichWordPress vs Next.js in 2026: my honest comparison
→Wie man 2026 das beste WordPress-Hosting wähltHow to choose the best WordPress hosting in 2026
→Meine Woche mit EmDash CMS: die WordPress-Alternative getestetMy week with EmDash CMS: the WordPress alternative tested
→WordPress-Wartung handelt vor allem von PflegeWordPress Maintenance Is Mostly About Care
→Sitecore und Typo3 zu WordPress: ein Migrations-PlaybookSitecore and Typo3 to WordPress: a migration playbook
Häufig gestellte Fragen
Was ist Headless WordPress?
Headless WordPress nutzt WordPress rein als Content-Backend und liefert die öffentliche Website über ein separates Frontend aus, meist Next.js oder Astro, via API. Editoren behalten die vertraute wp-admin; Besucher bekommen eine schnellere, entkoppelte Website. Es trennt die Bearbeitungserfahrung von der Rendering-Schicht.
Wann solltest du Headless WordPress nutzen?
Nutze es, wenn du WordPress-Bearbeitung plus eine Performance oder Architektur brauchst, die Themes nicht liefern können: App-ähnliche Interaktivität, mehrere Frontends aus einer Content-Quelle oder strikte Core Web Vitals. Überspringe es für eine Standard-Marketing-Website, wo klassisches WordPress billiger, einfacher und schnell genug ist.
Was sind die Nachteile von Headless WordPress?
Es ist komplexer und teurer, ein Headless-System zu bauen und zu pflegen, die Vorschau funktioniert nicht ohne zusätzliche Arbeit, und einige Plugins brauchen extra Konfiguration. Zudem verwaltest du jetzt zwei Systeme statt eines. Die Performance und Flexibilität sind real, aber der Overhead auch. Geh diesen Weg nur, wenn der Nutzen die Kosten klar rechtfertigt.
Headless vs. reguläres WordPress – welches ist schneller?
Headless ist üblicherweise auf dem Frontend schneller, weil es ein modernes optimiertes Framework statt eines Themes ausliefert und höhere Core Web Vitals erreichen kann. Aber eine gut gehostete, gut gebaute klassische WordPress-Site ist für die meisten schnell genug. Der Geschwindigkeitsvorteil zählt vor allem bei großem Maßstab oder wenn Performance für deine Brand zentral ist.