Headless WordPress — warum überhaupt?
WordPress wurde nie als Headless-CMS konzipiert. Das hat in den letzten Jahren immer wieder zu Reibungspunkten geführt: Wer ein modernes Frontend (Next.js, Astro, Nuxt) auf WordPress aufsetzen wollte, musste sich mit einer REST-API zufriedengeben, die zwar erweiterbar, aber strukturell limitiert war. Custom Blocks im Editor sahen aus dem Frontend wie undurchsichtige HTML-Blöcke aus. Server-seitige Komponenten — der Hot-Spot moderner Frontend-Frameworks — waren mit WordPress kaum sinnvoll machbar.
Mit WordPress 7.0 ändert sich das. Die REST-API ist überarbeitet, Block-SSR wird erstmals offiziell unterstützt, und neue Endpoints liefern strukturierte Block-Daten statt vorgerendertes HTML. Damit ist Headless-WordPress nicht mehr ein Kompromiss, sondern eine echte Architektur-Option.
Bei Werbesofa setzen wir Headless-Setups bei spezifischen Mandantenanforderungen ein — meistens bei Mandantinnen und Mandanten mit komplexen Frontend-Anforderungen, hohen Performance-Erwartungen oder mehreren Frontends (Webseite + Mobile App + Marketing-Microsites), die alle auf dieselbe Inhalts-Basis zugreifen. Dieser Beitrag fasst zusammen, was WP 7.0 für solche Setups bringt.
Die überarbeitete REST-API
Die WordPress REST-API gibt es seit Jahren. Was sich in 7.0 ändert: Die Endpoints sind strukturierter, performanter und bringen Block-Daten in einer Form, die ein modernes Frontend direkt rendern kann. Statt bisher ein Beitrag-Endpoint, der das gerenderte HTML zurückgab (und damit jede Frontend-Logik zwang, das HTML nachzubereiten), liefert WP 7.0 wahlweise Block-JSON.
Block-JSON ist die Struktur, in der WordPress Blocks intern speichert. Jede Block-Instanz ist ein Objekt mit Block-Type, Attributen und verschachtelten Child-Blocks. Ein Frontend kann diese Struktur entgegennehmen und mit eigenen Render-Komponenten umsetzen — typischerweise React-Komponenten in einem Next.js-Projekt.
Das löst ein langjähriges Headless-Problem: Wenn ein Custom Block im Editor gepflegt wurde, musste das Frontend ihn früher wieder aus dem HTML parsen oder über separate Endpoints abfragen. Mit Block-JSON gibt es eine 1:1-Repräsentation des Editor-Inhalts im Frontend. Editor und Frontend bleiben strukturell synchron.
Block-SSR — was es konkret bedeutet
Block-Server-Side-Rendering ist die zweite große Neuerung. WordPress 7.0 kann beim Liefern eines Beitrags den Inhalt nicht mehr vollständig fertig-rendern, sondern Blocks markieren, die im Frontend serverseitig (z.B. in Next.js) gerendert werden sollen. Damit lassen sich Blocks bauen, die im Editor wie immer aussehen, aber im Frontend ein modernes React-Server-Component-Verhalten haben.
Praktisches Beispiel: Ein Werbesofa-Custom-Block für „aktuelle News“ zeigt im Editor eine Platzhalter-Liste mit Schema-Daten. Im Frontend wird der Block auf dem Next.js-Server gerendert, holt die aktuellen News über die WordPress-API und liefert das fertige HTML an den Browser. Caching, Inkremental-Static-Regeneration, dynamische Inhalte — alles greift modernes Frontend-Tooling.
Vorher musste man entweder die News im Block-Rendering im WordPress-PHP-Layer holen (langsam, schlecht cachebar) oder im Frontend nachhandeln (komplex, fehleranfällig). WP 7.0 Block-SSR schließt die Lücke.
Frontend-Frameworks im Detail
Next.js ist die populärste Wahl für Headless-WordPress-Projekte. Vercel und WP Engine bieten dedizierte Hosting-Stacks mit Caching-Layern und Build-Hooks. Mit WordPress 7.0 wird die Integration deutlich smoother: Vercel hat einen offiziellen WP-7-Connector, der Block-JSON direkt in Next.js-Server-Components mappt.
Astro eignet sich für Mandanten mit hohem Anteil statischer Inhalte und wenig Interaktivität. Astro-Sites mit WordPress als CMS-Backend können extrem performant sein, weil sie standardmäßig minimales JavaScript ausliefern.
Nuxt 4 (Vue-basiert) hat ähnliche Capabilities wie Next.js. Wer Vue im Team etabliert hat, kommt damit gut. Die WordPress-Integration ist nicht so glatt wie Next.js, aber funktionsfähig.
SvelteKit ist eine Option für sehr leichte, schnelle Frontends. Hier muss man mehr selbst integrieren, hat dafür aber sehr schlanke Bundles.
Wann lohnt sich Headless?
Headless ist nicht für jeden Mandanten sinnvoll. Die Setup-Komplexität ist deutlich höher als bei einer klassischen WordPress-Installation. Hosting wird teurer (zwei Systeme: WordPress + Frontend-Server). Wartung erfordert Frontend- und Backend-Kompetenz.
Sinnvoll ist Headless bei: hohem Performance-Bedarf jenseits dessen, was klassisches WordPress liefern kann; mehreren Frontends, die dieselben Inhalte konsumieren (Webseite + App); App-ähnlichen Interaktionen im Frontend; sehr großen Mandanten mit klar getrennten Teams (siehe auch Performance-Vergleich) für Inhalt und UI.
Nicht sinnvoll bei: kleinen bis mittleren Mandantenwebseiten mit überschaubarem Performance-Bedarf; Mandanten ohne Frontend-Entwickler-Ressource; redaktionellen Setups, in denen die Editor-Preview-Funktion eine zentrale Rolle spielt (Headless-Setups haben oft begrenzte Preview-Möglichkeiten).
Performance- und Kosten-Bilanz
Eine Headless-Architektur kann beeindruckende Performance liefern. LCP-Werte unter einer Sekunde, INP konstant unter 100 ms, perfekte Lighthouse-Scores — das ist bei guter Headless-Umsetzung machbar. Caching-Layer können extrem aggressiv arbeiten, weil das Frontend statische Builds produziert.
Die Kosten sind allerdings höher. Frontend-Hosting (Vercel, Netlify, eigene Server) kommt zu WordPress-Hosting dazu. Build-Zeiten müssen eingeplant werden — bei großen Mandantenwebseiten kann ein Full-Build mehrere Minuten dauern. Wir empfehlen Incremental-Static-Regeneration (ISR), wenn der Mandant viel publiziert.
Bei Werbesofa rechnen wir für ein typisches Headless-Setup mit dem ein-bis-eineinhalbfachen Hosting-Aufwand gegenüber einer klassischen WordPress-Site. Dafür spart man Plugins, weil viel Funktionalität direkt im Frontend gelöst wird.
Werbesofa-Praxis: ausgewählte Mandanten haben den Schritt gemacht
In unserem Mandantenportfolio sind in den letzten zwölf Monaten drei Mandanten auf Headless umgestellt. In allen drei Fällen war der Auslöser ein konkretes Problem — meist Performance bei sehr großem Mandanten-Traffic oder der Wunsch, parallel zur Webseite eine Mobile App zu betreiben (typische Anforderung für Mandanten, bei denen moderne Webentwicklung gefragt ist). Die Migration war jeweils ein mehrwöchiges Projekt, aber hat sich für die Mandanten gelohnt.
Die Lernkurve: Headless ist eine Architektur-Entscheidung, keine Plugin-Wahl. Wer den Schritt machen will, sollte sich mit Frontend-Frameworks, Caching-Strategien, Build-Pipelines und CDN-Konfiguration auskennen. Wir begleiten solche Projekte gerne — aber empfehlen Mandanten, die unsicher sind, zunächst einen klassischen WordPress-Setup zu optimieren, bevor sie auf Headless gehen.
Wer überlegt, ob Headless die richtige Architektur für die eigene Webseite ist, kann uns gerne ein Erstgespräch anfragen. Wir schauen uns die Anforderungen an und sagen ehrlich, ob Headless passt oder ob ein klassisches Setup ausreicht. In den meisten Fällen reicht das klassische Setup.
Migration-Pfad: vom klassischen Setup zu Headless
Wer überlegt, von einem klassischen WordPress-Setup auf Headless umzustellen, sollte die Migration als mehrwöchiges Projekt einplanen. Wir gliedern solche Migrationen in vier Phasen: Audit und Architektur-Entscheidung, Frontend-Aufbau, parallele Test-Phase, Cut-Over. Jede Phase hat eigene Risiken und eigene Erfolgs-Kriterien.
Phase 1 (Audit): Zwei bis drei Wochen. Inventur aller bestehenden Inhalte, Custom-Blocks, Plugins und Frontend-Verhalten. Welche Funktionalität ist business-kritisch? Welche kann verlustfrei in ein modernes Frontend überführt werden? Welche ist plugin-abhängig und müsste neu gebaut werden? Am Ende dieser Phase steht eine Entscheidung: Headless lohnt sich, oder eine klassische Optimierung ist besser.
Phase 2 (Frontend-Aufbau): Vier bis acht Wochen. Aufsetzen des gewählten Frontend-Frameworks (typischerweise Next.js), Anbindung an die WordPress-REST-API, Implementierung der Custom-Block-Renderer, SEO-Setup mit Server-Side-Rendering, Tracking-Integration, Caching-Strategie. Diese Phase ist die aufwendigste — und die mit dem höchsten Anteil an Frontend-Entwicklungs-Arbeit.
Phase 3 (Test-Phase): Zwei bis vier Wochen. Das neue Headless-Frontend läuft auf einer Sub-Domain parallel zum bestehenden System. Mandantinnen und Mandanten testen redaktionelle Workflows, Performance wird gemessen, Edge-Cases werden durchgegangen — was passiert mit gelöschten Inhalten, was bei Permalink-Änderungen, was bei großen Updates der WordPress-API. Erst wenn alles funktioniert, geht die Migration in die letzte Phase.
Phase 4 (Cut-Over): Wenige Stunden bis ein Tag. DNS-Umstellung von der alten Site auf das neue Headless-Frontend. Monitoring der ersten 48 Stunden besonders engmaschig. Bei guter Vorbereitung ist der Cut-Over unspektakulär — bei schlechter Vorbereitung beginnt hier das Drama. Wir empfehlen, den Cut-Over außerhalb der Hauptverkaufszeiten und mit klarem Rollback-Plan zu fahren.
Fazit zur Migration: Headless ist machbar, aber kein Wochenend-Projekt. Wer den Schritt geht, sollte einen Partner einbinden, der Erfahrung mit beiden Welten hat — WordPress-Backend und modernes Frontend. Wir haben mehrere solche Migrationen begleitet und helfen Mandanten, das Risiko sauber einzukreisen.
Werkzeug-Stack: was wir bei Headless-Projekten einsetzen
Für interessierte Mandanten oder Kollegen aus der Branche: Unser typischer Werkzeug-Stack bei Headless-WordPress-Projekten besteht aus mehreren Komponenten. Backend: WordPress 7.0 mit ausgewählten Plugins (ACF Pro für strukturierte Inhalts-Felder, WPGraphQL für GraphQL-API, RankMath für SEO-Metadaten). Frontend: Next.js 15 mit App Router und React Server Components.
Hosting: WordPress auf eigenen Hetzner-Servern im Falkenstein-Rechenzentrum. Next.js-Frontend auf Vercel (für ISR und Edge-Caching) oder auf eigenen Servern (für Mandanten mit speziellen Daten-Lokalitäts-Anforderungen). CDN: bunny.net für statische Assets, Cloudflare für DNS und initiales Edge-Caching.
Build-Pipeline: GitHub Actions, die bei Inhalt-Updates in WordPress automatisch Revalidate-Calls an Vercel schicken. Inkrementelles Build mit ISR — neue Beiträge sind in unter einer Minute live, ohne dass die ganze Site neu gebaut wird. Vorschau-Mechanismus: Editor-Preview-Mode in Next.js, der direkt aus WordPress die unveröffentlichte Version zieht.
Headless ist eine Architektur-Entscheidung mit Langzeit-Folgen. Wer einmal gewechselt hat, kommt selten zurück — die Frontend-Entwicklungs-Kompetenz, die in den Aufbau geflossen ist, will nicht aufgegeben werden. Umgekehrt: Wer in einem klassischen WordPress-Setup zufrieden ist, hat keinen Grund, den Mehraufwand auf sich zu nehmen. Headless ist kein Status-Symbol, sondern ein Werkzeug für spezifische Anforderungen. Wir beraten ehrlich — auch wenn ehrlich bedeutet, dass Headless für die jeweilige Mandantin oder den jeweiligen Mandanten gerade nicht passt.
Für Werbesofa-Mandanten gilt: Wer Interesse an Headless hat, kann ein kurzes Architektur-Gespräch mit uns vereinbaren. Wir schauen uns die aktuellen Anforderungen an, prüfen die mittelfristige Roadmap und sagen klar, ob Headless die richtige Antwort ist oder ob klassisches WordPress mit gezielter Optimierung ausreicht. Dieses Gespräch ist Teil unserer Beratungsleistungen und für bestehende Mandanten kostenfrei.
