Wirtschaftlichkeit von headless WordPress 2026: wann es sich rechnet und wann nicht

#Wirtschaftlichkeit von headless WordPress 2026: wann es sich rechnet und wann nicht

Die meisten Aussagen nach dem Muster “mit headless haben wir die Hosting-Kosten um 70 Prozent gesenkt” sind Buchhaltungsfiktion. Sie zählen die neue Rechnung, nicht die Migrationskosten, die sie hervorgebracht haben, und sie ignorieren die Zeit erfahrener Entwickler, die die neue Architektur am Laufen hält. Headless WordPress rechnet sich durchaus, nur eben nicht automatisch.

Dieser Artikel beschreibt das Schema, mit dem wir mit Kunden entscheiden, bevor die Migration beginnt. Er ist das Gegenstück aus Betreibersicht zur Leistung headless WordPress und zur Entscheidungsmatrix Next.js oder Astro.

Die Ausgangslage ist einfach und wird trotzdem oft übersehen: Ein Wechsel der Abstraktionsebene ist nicht kostenlos. Die wirtschaftliche Frage lautet, ob die Einsparung auf der neuen Ebene die Kosten des Umzugs übersteigt.

#Ist headless WordPress die Kosten wert

• Headless senkt die Hosting-Kosten für öffentlichen Traffic, weil PHP pro Anfrage wegfällt.
• Headless bringt einmalige Migrationskosten mit sich, dominiert vom SEO-Erhalt.
• Headless bringt laufende Edge-Laufzeitkosten mit sich, die mit dem Traffic wachsen.
• Bei einer Content-Website liegt die Gewinnschwelle meist bei einigen Monaten. Bei einer sehr kleinen Website nie.
• Der größere Ertrag kommt von der Conversion, nicht von den Kosten: Core Web Vitals bringen Umsatz. Reine Shopify-Builds werden mit einem Shopify-Entwickler kalkuliert, nicht als Nebenjob im WordPress-Budget.

#Welche drei Kostenspalten gibt es bei headless WordPress

Es “Hosting-Kosten” zu nennen, ist der erste Fehler. Es gibt drei Spalten.

Spalte eins: Infrastruktur für öffentlichen Traffic. Was Sie zahlen, um einen Besucher zu bedienen. Bei einem WordPress-Monolithen ist das die Rechnung des PHP-Hosters plus CDN. Bei headless ist es die Edge-Laufzeit (zum Beispiel Cloudflare Workers) plus ein kleinerer WordPress-Origin, der nur Redakteure und die REST API bedient.

Spalte zwei: Aufbau und Migration. Was Sie einmalig zahlen, um von einer Architektur zur anderen zu wechseln. Zeit erfahrener Entwickler, SEO-Erhalt, Mapping der Weiterleitungen, Bildmigration, Schulung des Content-Teams, Parallelbetrieb beider Stacks während der Umstellung.

Spalte drei: laufende Entwicklungsarbeit. Was Sie jeden Monat zahlen, um die neue Architektur zu betreiben. CI-Minuten, Framework-Updates, Verwaltung des Cloudflare-Kontos, Monitoring, die Kosten eines erfahrenen Frontend-Entwicklers, der für das Frontend-Framework verantwortlich ist.

Ein seriöser Vergleich summiert alle drei Spalten über denselben Zeitraum. Die meisten Marketing-Aussagen summieren nur Spalte eins und präsentieren die Differenz als Einsparung.

#Was kostet das Hosting bei headless WordPress

Ein WordPress-Monolith bei einem typischen PHP-Hoster bezahlt Kapazität. Ob die Website einen Besucher hat oder tausend, ein Server läuft. Die Rechnung ist fix. CDN-Kosten wachsen mit dem Traffic. Datenbank, Object Cache und Full-Page-Cache senken die CPU-Last pro Anfrage, beseitigen sie aber nicht.

Headless auf Cloudflare Workers zahlt pro Anfrage und pro CPU-Millisekunde. Die Antwort mit vorgerendertem HTML am Edge braucht einen Bruchteil einer CPU-Millisekunde. Der WordPress-Origin läuft nur, wenn ein Redakteur speichert, wenn ein Webhook auslöst oder wenn das Frontend neue Daten braucht. Bei öffentlichem Traffic, der überwiegend aus Lesezugriffen besteht, ist das strukturell günstiger.

Bei einem WooCommerce-Shop ist das Bild differenzierter. Personalisierte Seiten und Routen für angemeldete Nutzer kosten im Frontend weiterhin CPU. Statische Katalogseiten nicht. Sobald sich der Katalog stabilisiert hat, spricht die Aufteilung meist trotzdem für headless.

#Preise von Cloudflare Workers für ein headless WordPress-Frontend

Cloudflare veröffentlicht die Tarife auf der Preisseite von Workers. Die kostenlose Stufe erlaubt 100.000 Anfragen pro Tag und 10 Millisekunden CPU-Zeit pro Aufruf. Für Workers Paid gilt eine Mindestgebühr von 5 USD im Monat pro Konto. Im Standard-Abrechnungsmodell sind 10 Millionen Anfragen und 30 Millionen CPU-Millisekunden im Monat enthalten. Jede weitere Million Anfragen kostet 0,30 USD, jede weitere Million CPU-Millisekunden 0,02 USD.

Für die headless Rechnung sind zwei Sätze aus dieser Dokumentation wichtiger als die Tarife. Erstens: Anfragen an statische Assets sind kostenlos und unbegrenzt. Vorgerendertes HTML, das als statisches Asset ausgeliefert wird, verursacht also keine Gebühr pro Anfrage. Abgerechnet werden nur Routen, die Worker-Code ausführen: Suche, Formulare, Warenkorb, Entwurfsvorschau. Der zweite Satz steht auf der Seite mit den Limits: Wartezeit im Netzwerk, also fetch()-Aufrufe, KV-Lesezugriffe und Datenbankabfragen, zählt nicht zur CPU-Zeit. Ein Worker, der Daten aus der WordPress REST API holt und auf den Origin wartet, bezahlt seine eigene Rechenzeit und nicht einen langsamen Origin.

Die CPU-Limits entscheiden über die Stufe. In der kostenlosen Stufe hat ein HTTP-Aufruf 10 ms CPU-Zeit. In Workers Paid liegt der Standardwert bei 30 Sekunden pro Anfrage, anhebbar auf 5 Minuten. Der Unterschied zählt bei SSR, weil jedes Rendern auf Anfrage in dieses Budget passen muss. Ein vollständig statisches Frontend liefert kostenlose statische Assets aus und berührt das CPU-Limit gar nicht.

#Vollständiger Rebuild oder ISR bei headless WordPress

Die Kosten für das Aktualisieren von Inhalten fallen an einer von zwei Stellen an: beim Build oder bei der Anfrage.

Beim vollständigen statischen Build löst jede Veröffentlichung in WordPress einen Webhook und einen neuen Build aus. Die Limits von Cloudflare Pages zeigen, wo die Grenzen liegen: 500 Builds im Monat in Free, 5.000 in Pro und 20.000 in Business, bei einem Build gleichzeitig in Free, fünf in Pro und zwanzig in Business. Ein Build bricht nach 20 Minuten ab. Free nimmt bis zu 20.000 Dateien pro Website an, die kostenpflichtigen Stufen bis zu 100.000. Eine Redaktion, die 20 Mal am Tag speichert und nach jedem Speichern baut, braucht rund 600 Builds im Monat, also mehr, als Free hergibt. Eine mehrsprachige Website mit Tausenden Beiträgen und Bildern kann stattdessen an das Dateilimit stoßen. Beide Grenzen lassen sich umgehen, etwa durch gebündelte Builds oder Bilder außerhalb des Deployments, aber das ist Arbeit, die in Spalte zwei geplant gehört und nicht erst nach dem Start auffallen sollte.

Incremental Static Regeneration in Next.js verlagert diese Kosten auf den Zeitpunkt der Anfrage. Die ISR-Dokumentation beschreibt zwei Modi: zeitbasierte Aktualisierung über revalidate und Aktualisierung auf Abruf über revalidatePath oder revalidateTag, die ein WordPress-Webhook nach dem Speichern eines Beitrags aufrufen kann. Dieselbe Seite nennt Einschränkungen, die die Rechnung verändern. ISR funktioniert nur mit der Node.js-Runtime und nicht beim statischen Export. Bei mehreren Instanzen ist der Standard-Cache im Dateisystem pro Instanz getrennt, und eine Aktualisierung auf Abruf invalidiert nur die Instanz, die den Aufruf erhält, deshalb braucht es einen gemeinsamen Cache-Handler. Die Regeneration im Hintergrund läuft auf der Instanz, die die Anfrage bedient hat, und zählt auf Plattformen mit Abrechnung pro Anfrage als zusätzliche Rechenleistung. ISR spart also Builds, bringt aber Infrastruktur und einen Posten für Rechenzeit mit. Der vollständige Build bleibt einfacher, solange er in die Limits passt.

#Warum ist die Migration der größte Kostenposten bei headless WordPress

Der größte einmalige Kostenposten in jedem headless WordPress-Projekt ist die Migration selbst, genauer gesagt die Arbeit am SEO-Erhalt. Jedes der sieben Muster aus dem Artikel SEO-Muster für headless WordPress kostet Zeit. Eines davon auszulassen, kostet mehr.

Konkrete Bestandteile:

• Jede bestehende kanonische URL erfassen.
• Die Weiterleitungshistorie sichern, einschließlich stiller Weiterleitungen aus /wp-content und Länderumschaltern.
• Metadaten aus Yoast oder Rank Math in das Frontend-Rendering übernehmen.
• hreflang als selbstreferenzierendes HTML neu aufbauen, nicht nur als JSON.
• Die Parität der strukturierten Daten in den Berichten zu Rich-Suchergebnissen der Search Console prüfen.
• Den alten WordPress-Origin für den Suchindex unsichtbar machen.
• Alt-Texte und strukturierte Bilddaten für die Bildersuche neu aufbauen.

Eine Migration, die diese Arbeit sauber erledigt, braucht Wochen an Zeit erfahrener Entwickler. Eine Migration, die sie auslässt, kostet später Monate der Schadensbehebung. Zugespitzt: Jede Fallstudie mit “wir haben 70 Prozent gespart”, in der das Unternehmen auch “nach drei Monaten das SEO neu machen” musste, ist ein Fall, in dem die Migrationskosten zweimal bezahlt wurden.

#Was kostet der Betrieb von headless WordPress

Ein headless-Aufbau fügt dauerhafte Betriebsfläche hinzu. Die CI führt nicht mehr nur Plugin-Updates für WordPress aus, sondern auch Framework-Upgrades, Abhängigkeitsprüfungen und Frontend-Build-Pipelines. Die Nutzung von Cloudflare Workers muss überprüft werden. Das Verhalten des Edge-Caches muss überwacht werden. Ein erfahrener Frontend-Entwickler muss eingebunden sein, wo einen Monolithen manchmal ein reiner Backend-Generalist betreiben konnte.

Konkret ist zu erwarten:

• Ein CI-Workflow für den WordPress-Origin (Plugins, Themes, Core).
• Ein CI-Workflow für Build und Deployment des Frontends.
• Eine Observability-Ebene für Edge-Laufzeit, Workers-Fehler und den Zustand der REST API.
• Eine Person in Bereitschaft für beide Stacks, die die Grenze zwischen ihnen wirklich versteht.

Der letzte Punkt wird am häufigsten unterschätzt. Ich habe Migrationen geprüft, bei denen das ursprüngliche Entwicklungsteam nach der Umstellung ging und das nächste Team eine Architektur erbte, für die es sich nicht verantwortlich fühlte. Die Wirtschaftlichkeit einer solchen Lage ist düster, unabhängig von den Einsparungen in Spalte eins.

#Was der WordPress-Origin nach dem Umstieg auf headless noch braucht

Der Origin wird kleiner, aber er verschwindet nicht. Die Anforderungen von WordPress sind dieselben wie beim Monolithen: empfohlen werden PHP 8.3 oder höher, MySQL 8.0 oder MariaDB 10.11 oder höher sowie HTTPS-Unterstützung. Es ändert sich das Lastprofil, nicht die Liste der Aufgaben. Der Server braucht weiterhin Updates, Backups und Monitoring, er bedient nur Redaktion und Build statt Besucher.

Der Build holt Inhalte über die REST API, und das hat eine eigene Arithmetik. Die Dokumentation zur Paginierung begrenzt per_page auf 100 Datensätze, und die Header X-WP-Total und X-WP-TotalPages liefern die Zahl der Datensätze und Seiten. Ein vollständiger Build einer Website mit 10.000 Beiträgen bedeutet also mindestens 100 Anfragen allein für die Beitragsliste, bevor Seiten, Kategorien, Medien und jede weitere Sprachversion dazukommen. Ein Origin, der unter dieser Last langsam antwortet, verlängert jeden Build, und ein Build in Cloudflare Pages hat für alles 20 Minuten.

Die Vorschau von Entwürfen braucht Authentifizierung. Das REST API Handbook beschränkt die Cookie-Authentifizierung auf Anfragen aus WordPress selbst, deshalb nutzt ein externes Frontend Anwendungspasswörter (Application Passwords). Sie sind seit Version 5.6 im Core und erreichen die REST API über HTTPS als Basic Auth. Ein Anwendungspasswort ist ein weiteres Geheimnis, das in den Worker-Einstellungen liegt und regelmäßig gewechselt werden muss, also ein weiterer Posten in Spalte drei.

#Wann rechnet sich headless WordPress

Das Schema, mit dem wir mit Kunden arbeiten, ist konservativ. Wir modellieren 24 Monate und drei Spalten, mit Traffic-Profil und Veröffentlichungsrhythmus als Eingangsgrößen.

Headless rechnet sich meist innerhalb von 12 Monaten, wenn:

• Der öffentliche Traffic so hoch ist, dass die PHP-Hosting-Kapazität der Engpass ist.
• Mobile Core Web Vitals an den Umsatz gekoppelt sind (E-Commerce, Lead-Generierung).
• Das Redaktionsteam weiter mit WordPress arbeitet und vom gleichen Arbeitsablauf profitiert.
• Ein erfahrener Frontend-Entwickler bereits im Team ist oder für die gesamte Laufzeit beauftragt wird.

Die Bedingung zu den Core Web Vitals lässt sich nur mit einer Messung vor und nach der Migration prüfen. web.dev nennt die Schwellen für ein gutes Ergebnis: LCP innerhalb von 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1, gemessen am 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Erfüllt die Website diese Schwellen schon als Monolith, wird das Konversionsargument schwächer, und die Rechnung muss sich auf die übrigen Spalten stützen.

Innerhalb von 24 Monaten rechnet es sich nicht, wenn:

• Der öffentliche Traffic gering ist und ein kleiner PHP-Hoster ausreicht.
• Der Veröffentlichungsrhythmus niedrig ist (ein Beitrag pro Monat), sodass die Geschwindigkeit der Redaktion kein Engpass ist.
• Die Website von interaktiver Produktoberfläche dominiert wird, die ohnehin SSR und Client-Hydration braucht.
• Kein erfahrener Frontend-Entwickler verfügbar ist und der Orchestrierungsaufwand bei einem Generalisten landet.

#Was verändert die Rechnung bei den headless WordPress-Kosten

Drei Faktoren verschieben die Gewinnschwelle schneller als erwartet:

Erstens, KI-Funktionen am Edge. Cloudflare Workers AI, MCP-Server und am Edge gerenderte Personalisierung sind auf einer Workers-Laufzeit günstig und auf einem Shared-PHP-Hoster teuer (oft gar nicht möglich). Eine Website, die per LLM generierte Meta-Beschreibungen, agentenfreundliche Endpunkte oder regionale Preise ausliefern will, erreicht die headless-Gewinnschwelle schneller.

Zweitens, das Barrierefreiheitsrecht. Der European Accessibility Act (Richtlinie (EU) 2019/882) gilt in Deutschland über das BFSG, seit Juni 2025, und in Österreich über das Barrierefreiheitsgesetz (BaFG, BGBl. I Nr. 76/2023). Beide Gesetze sehen Sanktionen für Websites mit nicht barrierefreien Frontends vor, im unten beschriebenen Umfang. Migrations-Audits, die ohnehin die Barrierefreiheit korrigieren müssen, rechnen sich oft schon allein in der Spalte für rechtliche Risiken.

Drittens, KI-Commerce und Entdeckung durch Agenten. Da der Trial-Ring unseres Tech Radar das Universal Commerce Protocol enthält, wird für Agenten lesbarer Handel zum Kaufsignal. Headless-Architekturen stellen Produkte sauberer als Daten bereit als Monolithen.

#Wen der European Accessibility Act erfasst

Das rechtliche Argument aus dem vorigen Abschnitt greift nur dort, wo das Recht gilt. Die Richtlinie (EU) 2019/882 gilt für Dienstleistungen, die nach dem 28. Juni 2025 für Verbraucher erbracht werden, darunter Dienstleistungen im elektronischen Geschäftsverkehr. Die Richtlinie definiert sie als Dienstleistungen, die über Websites und mobile Anwendungen im Fernabsatz, elektronisch und auf individuelle Anfrage eines Verbrauchers im Hinblick auf den Abschluss eines Verbrauchervertrags erbracht werden. Artikel 4 Absatz 5 nimmt Kleinstunternehmen, die Dienstleistungen erbringen, von den Barrierefreiheitsanforderungen aus. Ein Kleinstunternehmen beschäftigt im Sinne der Richtlinie weniger als 10 Personen und hat einen Jahresumsatz oder eine Jahresbilanzsumme von höchstens 2 Millionen EUR.

Daraus folgt eine einfache Aufteilung. Ein Onlineshop oberhalb der Schwelle für Kleinstunternehmen trägt die Spalte für rechtliche Risiken unabhängig von der Architektur, und die Migration ist der Moment, in dem Korrekturen der Barrierefreiheit ohnehin ins Frontend gehen. Ein Kleinstunternehmen oder eine Website, die nicht an Verbraucher verkauft und keine der anderen in der Richtlinie genannten Dienstleistungen erbringt, hat diese Spalte nicht, und dort beschleunigt das rechtliche Argument die Amortisation nicht. Es ist derselbe Schluss wie im Abschnitt dazu, wann sich headless nicht rechnet: Kleinen Websites fehlen auf der Seite der Einsparungen die Posten, die die Migrationskosten decken würden.

#Weitere Leitfäden zu headless WordPress

Dieser Artikel unterstützt die Leistung headless WordPress, ergänzt den Artikel zu SEO-Mustern, verweist auf unseren TCO-Leitfaden headless oder Monolith WordPress 2026 für die mehrjährige Finanzmodellierung und bezieht sich auf die Entscheidungsmatrix Next.js oder Astro. Die Reihenfolge der Entscheidung: zuerst dieser Text für die Frage “lohnt sich der Tausch”; dann der TCO-Leitfaden für das vollständige Finanzmodell über vier Jahre; dann die SEO-Muster für “wie halten wir unsere Rankings”; zuletzt die Framework-Entscheidung für “welches Frontend braucht diese Last”.