ROI von Headless vs traditionellem WordPress: Finanzanalyse 2026

Headless WordPress 2026 ist eine geklärte Engineering-Entscheidung mit ungeklärtem Business Case. Die Frage ist nicht, ob Next.js oder Astro WordPress-Inhalte gut rendern können, denn beides können sie. Die Frage ist, was Sie mit der zweiten Codebasis kaufen, und die ehrliche Antwort steht in WordPress Core: ein entkoppeltes Frontend zahlt bar für jede Bequemlichkeit, die der Monolith umsonst bekommt.

Die meisten Vergleiche bepreisen das als Multiplikator. Headless kostet zwei- oder dreimal einen Theme-Build, eine Zahl, die niemand prüfen kann und jeder zitiert. Die nützliche Version ist eine Liste der konkreten Dinge, die Core für Sie nicht mehr tut, sobald das Frontend kein PHP-Theme mehr ist, denn das sind die Positionen, die die Agentur tatsächlich in Rechnung stellt. Die Liste ist kurz, im Voraus bekannt, und sie ist das ganze Jahr null.

Dieser Artikel ist die Entscheidung selbst. Das ausführliche Finanzmodell mit vier Jahren Cashflow rechnet der TCO-Leitfaden Headless vs Monolith WordPress 2026 durch, und die einzelnen Kostenspalten (Hosting, kompletter Rebuild gegen inkrementelle Regeneration, Migration) zerlegt die Wirtschaftlichkeit von Headless WordPress.

#Was kostet eine Headless-WordPress-Website

Beginnen Sie damit, was die API tatsächlich liefert, denn die Lücke zwischen dem und einer funktionierenden Site ist der Build.

Core liefert REST, nicht GraphQL. REST_API_VERSION ist 2.0 in wp-includes/rest-api.php, Routen sind seit 4.4 registrierbar, und der Namespace wp/v2 ist das, worauf eine Stock-Installation von WordPress 7.1.3 antwortet. GraphQL ist WPGraphQL, das im Oktober 2024 kanonisches Plugin wurde, mit Automattic-Backing nach dem Wechsel von Jason Bahl. Canonical ist ein starkes Wartungssignal. Es ist nicht Core. Sie installieren, versionieren und patchen es, und jedes Agenturangebot, das sagt „WordPress spricht GraphQL“, hat eine Abhängigkeit übersprungen.

Dann die konkreten Dinge, für die Sie einen JavaScript-Entwickler bezahlen:

Die Navigation. wp/v2/menus existiert, WP_REST_Menus_Controller ist seit 5.9 in Core und beantwortet keine anonyme Anfrage. check_has_read_only_access() liefert true nur für edit_theme_options, edit_posts oder eine Bearbeitungsberechtigung auf einem öffentlichen Post Type, sofern jemand den Filter rest_menu_read_access umdreht. Die Frontend authentifiziert sich bei jedem Build, oder Sie schreiben einen kleinen öffentlichen Endpunkt und besitzen dessen Cache. Das meint jeder Headless-Beitrag mit „Sie müssen das Menü bauen“, ohne je zu sagen warum.

Vorschau. Entwürfe sind keine öffentlichen Daten, und Core hat Recht. Unveröffentlichten Inhalt lesen heißt authentifizierte Anfrage: Application Passwords (Core seit 5.6) oder JWT-Plugin, plus Preview-Route im Frontend, plus einen Weg, dass ein Redakteur in wp-admin auf Vorschau klickt und dort landet. Drei bewegliche Teile, keines optional, keines im Framework-Starter.

Block-CSS. Der Filter should_load_separate_core_block_assets steht weiterhin standardmäßig auf false, aber Core lässt ihn nicht dort: _add_default_theme_supports() setzt ihn für Block-Themes auf true, und wp_load_classic_theme_block_styles_on_demand() (seit 6.9) macht dasselbe für klassische Themes. Eine Stock-7.x-Site druckt die Styles der genutzten Blöcke aus wp_head() und wp_footer(). Ihr Frontend ruft keines davon auf. Entweder importieren Sie das Stylesheet, oder Sie stylen jeden Core-Block neu, den Redakteure einfügen können: columns, gallery, quote, table, buttons, separator, cover. Das ist keine schwere Arbeit. Es ist Arbeit zum Scopen, und sie steht selten im Estimate.

Formulare und alles mit Verhalten. Abschnitt vier, weil das die Kosten nach dem Launch sind.

Nichts davon macht Headless zur schlechten Entscheidung. Es macht Jahr null zum leichten Call: wenn Sie kein Frontend-Team bereits finanzieren, gewinnt der Monolith bei den Aufbaukosten jedes Mal, weil WordPress Core unbezahlte Arbeit für Sie erledigt.

#Wartungskosten und Sicherheit bei Headless WordPress

#Sicherheit

Die gängige Version sagt, eine entkoppelte Architektur trenne die Angriffsfläche, sodass ein verwundbares Formular-Plugin die Datenbank nicht mehr erreiche. Das ist so formuliert falsch. Das Plugin läuft weiterhin in derselben WordPress-Installation, gegen dieselbe Datenbank, mit denselben Capabilities. Decoupling hat das Rendering verschoben. Die Schwachstelle nicht.

Was Decoupling wirklich kauft, ist eine Option, die der Monolith nicht hat: weil die öffentliche Site nicht mehr WordPress ist, können Sie den Origin hinter IP-Allowlist, VPN oder privatem Netz platzieren und nur das Frontend sowie die nötigen Endpunkte exponieren. Ein Monolith kann das nicht. Sitzt Ihr Headless WordPress auf einem öffentlichen Hostname mit von überall erreichbarem wp-admin, und die meisten sitzen so, haben Sie für die Architektur bezahlt und den Nutzen übersprungen.

Die zweite Hälfte ist weniger schmeichelhaft. Sie patchen zwei Runtimes in zwei Takten. WordPress liefert Minor Releases mit automatischen Hintergrund-Updates, und der 7.1-Zweig bekam drei davon in drei Wochen, 7.1.1 am 17. September, 7.1.2 am 22. September und 7.1.3 am 6. Oktober 2026, ohne dass jemand im Team etwas tat. Nichts in Ihrem JavaScript-Dependency-Tree verhält sich so. Next.js 16.3.5 erschien am 11. September 2026, Astro 7.3.3 am 16. September 2026, und Nodes LTS-Linien laufen nach eigenem Kalender aus (Node 18 Hydrogen bekam am 27. März 2025 das letzte Release). Ein Monolith hat ein Upgrade-Laufband. Headless hat zwei, und das schnellere ist das, das niemand budgetiert hat.

#Redesigns

Das Agilitätsargument ist der stärkste echte Punkt für Headless und wird meist um ein Wort übertrieben. „Die Frontend ist reines React oder Vue“ trifft auf Astro nicht zu, das standardmäßig kein Client-JavaScript ausliefert. Die genaue Behauptung: wenn das Content-Modell stillhält, lässt sich ein entkoppeltes Frontend neu bauen, ohne WordPress anzufassen, und das ist wirklich billiger als gegen Page-Builder-Markup oder ein Theme mit zehn Jahren bedingter Templates zu kämpfen.

Der Vorbehalt ist derselbe Satz rückwärts. Wenn das Redesign ändert, welcher Content existiert, nicht nur wie er aussieht, editieren Sie zwei Repositories, koordinieren zwei Deploys und schreiben eine Migration, die in beiden landen muss. Die Hälfte der Redesigns, die als „nur Frontend“ verkauft werden, brauchen am Ende ein neues Feld, und das ist der Tag, an dem das zweite Repository aufhört, gratis zu sein.

Für den US-öffentlichen Sektor: die finale DOJ-Regel unter ADA Title II (Federal Register, 24. April 2024) setzt WCAG 2.1 Level AA für Webinhalte von Bundesstaaten und Kommunen, mit Fristen 2027 und 2028 je nach Bevölkerungsgröße. Läuft ohnehin ein Rebuild, ist das der günstigste Moment für Accessibility. In Deutschland erfasst das Barrierefreiheitsstärkungsgesetz (BFSG) seit dem 28. Juni 2025 unter anderem Dienstleistungen im elektronischen Geschäftsverkehr, also auch viele Shops, die gerade neu gebaut werden. Barrierefreiheit gehört dort von Anfang an in den Umfang des Umbaus, in beiden Architekturen.

#Ist Headless WordPress schneller und konvertiert besser

Der Performance-Case für Headless war 2020 stark. Er ist von beiden Enden her schmaler geworden, und beide Änderungen sind datierbar.

Zuerst änderte sich die Metrik. INP ersetzte FID als Core Web Vital am 12. März 2024. FID maß, wie lange der Browser brauchte, um die erste Interaktion anzunehmen, fast gratis für servergerenderte Seiten. INP misst die Latenz von Interaktionen über den ganzen Besuch, direkt Main-Thread-Arbeit. Eine hydration-schwere React-Frontend ist konstruktionsbedingt die Architektur, die am meisten Main-Thread-Arbeit ausliefert. SSR bringt Headless auf Augenhöhe mit einem PHP-Theme bei Paint. Es setzt ihn nicht voraus, und bei INP kann es ihn zurückwerfen. Ein Build, der JavaScript als Opt-in behandelt (Astro Islands oder React Server Components), ist die Version, die dieses Argument gewinnt.

Core bewegte sich am anderen Ende. Speculative Loading landete in WordPress 6.8, dokumentiert in der Dev Note vom 6. März 2025. Auf einer Site mit Pretty Permalinks emittiert Core für Ausgeloggte Speculation Rules, und 7.1 fügte WP_SPECULATIVE_LOADING_DEFAULT_MODE und WP_SPECULATIVE_LOADING_DEFAULT_EAGERNESS hinzu. Default ist prefetch mit conservative Eagerness. Das ist Prefetch, kein Prerender. Es nimmt trotzdem einen Teil dessen weg, was ein JavaScript-Router früher der sichtbare Grund war, auf einem Stock-Theme ohne Router.

Bleibt der Business Case auf Ihren eigenen Zahlen. Nehmen Sie Ihre Conversion Rate, addieren Sie einen Prozentpunkt, multiplizieren Sie mit einem Jahr Bestellungen und dem durchschnittlichen Bestellwert, und vergleichen Sie das mit einem Headless-Build plus stehendem Frontend-Engineer. Bei einem Hochvolumen-Shop trägt der Lift die Kosten im ersten Jahr. Bei einer Katalogseite mit bescheidenem Volumen trägt er sie nie, und die ehrliche Empfehlung ist die, die die meisten Agenturen überspringen: dasselbe Geld in Caching, Bilder und Checkout stecken und beim Theme bleiben.

#Warum funktionieren WordPress-Plugins nicht headless

Das sind die Kosten nach dem Launch, die den Goodwill des Marketingteams beenden, und sie haben einen präzisen Mechanismus.

In WP_REST_Posts_Controller::prepare_item_for_response() wird das Content-Feld so gebaut:

$data['content']['rendered'] = post_password_required( $post )
    ? ''
    : apply_filters( 'the_content', $post->post_content );

the_content läuft. Shortcodes expandieren, Block-Callbacks laufen, Markup kommt zurück. Was nicht zurückkommt, ist alles, was das Plugin auf wp_enqueue_scripts registriert, in wp_head() gedruckt oder an wp_footer() gehängt hat. Das Ergebnis sieht wie ein Bug aus: Slider-Shortcode liefert div mit richtigen Klassen, ohne Stylesheet, ohne Initializer. Preistabelle ohne CSS. Formular ohne Submit-Handler. Der Redakteur sieht es in wp-admin funktionieren (noch Monolith), sieht es in Produktion kaputt und öffnet ein Ticket gegen das Frontend-Team.

Die Steuer heißt nicht „finde eine React-Bibliothek für ein Glücksrad“. Sie heißt: jedes Plugin, das Marketing installiert, kommt halb an. Zwei Plugins im Jahr sind Rauschen. Zwei im Monat sind ein Retainer.

Ausnahme: WooCommerce pflegt die Store API unter wc/store, sodass Warenkorb und Checkout gegen einen dokumentierten Vertrag baubar sind. Die überwältigende Mehrheit des Plugin-Verzeichnisses hat kein Äquivalent und bekommt keines.

Kehrseite: der Install-Button ist auch die größte Haftung des Monolithen. Headless macht jede Installation zu einem Gespräch mit einem Engineer. Ist Ihr Governance-Problem, dass jeder alles installieren kann, ist diese Reibung ein Feature, für das Sie bewusst zahlen.

#Was kostet Hosting für Headless WordPress

Zwei Runtimes bedeuten zwei Rechnungen, und das ist der uninteressanteste Teil der Zahl.

Die Form ist ein PHP-Origin für WordPress plus ein separater Host für das Frontend, Node-Runtime oder statischer Build, typisch auf Vercel, Netlify oder Cloudflare. WP Engines Headless-Plattform paart eine Node-Umgebung mit WordPress-Hosting unter einem Vendor. In jedem Fall betreiben Sie zwei Dinge, wo Sie eines betrieben haben.

Die Position, die übersehen wird, ist nicht die zweite Rechnung. Es ist die Publikation, die das Frontend erreicht. Auf einem Monolith invalidiert das Veröffentlichen Object Cache und Page Cache. Auf einem statisch generierten Frontend muss Publizieren etwas triggern: On-Demand-Revalidation-Webhook, Targeted Purge oder Scheduled Rebuild. Dieser Pfad ist Code, fragil wie Webhooks, und wenn er ausfällt, beharrt der Redakteur, ein Post sei live, während die Site widerspricht. Jemand muss ihn besitzen, monitoren und Freitags um siebzehn Uhr erreichbar sein.

Die zweite übersehene Position ist Observability. Ein Monolith hat ein Log. Ein entkoppelter Stack hat PHP-Fehler an einem Ort, Frontend-Build-Fails an einem anderen, die Requests dazwischen an einem dritten, und der erste ernste Produktionsvorfall ist der Moment, in dem sich zeigt, dass niemand sie korreliert hat.

#Wie hoch ist der ROI von Headless WordPress über drei Jahre

Legen Sie die Posten von oben in eine Tabelle für eine Unternehmenswebsite mit mittlerem Traffic, und die Form der Antwort steht fest, bevor irgendeine Zahl auftaucht.

Interessant ist die Asymmetrie. Den Headless-Aufschlag kennen Sie vor dem Start, der Zusatzumsatz ist eine Prognose. Headless rechnet sich, wenn Traffic und Wert pro Conversion hoch genug sind, dass ein moderater Conversion-Zuwachs einen bereits feststehenden Aufschlag übertrifft. Auf einer Website mit wenig Traffic deckt die Umsatzdifferenz ihn nie.

Für die Prognose gibt es eine gemessene Zahl, die als Größenordnung taugt und nicht als Versprechen. Die Deloitte-Studie für Google, Milliseconds Make Millions (2020), beobachtete im Einzelhandel 8,4 % mehr Conversions bei einer Verbesserung von 0,1 Sekunden über vier mobile Geschwindigkeitsmetriken. Die Zahl stammt aus einem Panel bestimmter Marken, und niemand erbt sie durch einen Architekturwechsel.

Die Variablen, die entscheiden, sind Ihre eigenen:

Die ersten beiden haben Sie gemessen. Die dritte ist eine Hypothese und sollte so behandelt werden. Die vierte entscheidet: Bei hohem Lead-Wert bezahlt schon ein kleiner Conversion-Zuwachs den Architekturunterschied, bei niedrigem nicht, selbst wenn die Website doppelt so schnell wird. Deshalb funktioniert Headless bei Versicherungen, Banken oder im industriellen B2B und selten bei einem Unternehmensblog.

#Wann lohnt sich Headless statt klassischem WordPress

#Traditionelles WordPress nutzen, wenn

1. Das Budget einen Build deckt, danach aber keinen festen Frontend-Engineer. Das ist der verlässlichste einzelne Hinweis darauf, dass ein Headless-Projekt schiefgeht.
2. Ihr Marketing visuelle Plugins selbstständig installieren und konfigurieren muss, ohne Entwickler dazwischen.
3. Die Website vor allem informiert und Speculative Loading im Core plus ein ordentlicher Cache schon den Großteil der Geschwindigkeit liefern, die ein Rebuild kaufen würde.
4. Sie keine JavaScript-Kompetenz im Haus haben und keine Einstellung planen. Eine Agentur kann es bauen. Jemand muss es danach am Leben halten.

#Headless WordPress nutzen, wenn

1. Sie aus einem Redaktionsprozess an mehr als ein Ziel publizieren, eine Website plus eine native App oder eine Content-Fläche im eigenen Produkt. Darauf hat der Monolith keine Antwort.
2. Sie den WordPress-Origin tatsächlich vom öffentlichen Internet nehmen können und Compliance oder Bedrohungsmodell die Netzwerkarbeit rechtfertigen.
3. Performance messbar Umsatz ist, Ihr Bestellvolumen hoch genug ist, dass ein Prozentpunkt Conversion ein festes Team trägt, und Ihr Frontend-Plan JavaScript als Zusatz behandelt, statt jedem Besucher ein Framework auszuliefern.
4. WordPress bereits ein System unter mehreren ist, per API mit ERP oder CRM verbunden, und das Content-Modell so stabil ist, dass das Frontend ihm nicht hinterherlaufen muss.

Unter allen acht Punkten liegt dasselbe Muster: Headless ist kein Technologie-Upgrade, sondern eine Personalentscheidung mit angehängter Architektur. Fragen Sie, wer im achtzehnten Monat den Frontend-Code schreibt und ob diese Person auf der Gehaltsliste steht. Ist die Antwort unklar, lautet sie Monolith.

#Astro als Mittelweg

Astro bietet einen Mittelweg. Komponenten entstehen in HTML und CSS ohne React, die Lernkurve ist flacher als bei Next.js, standardmäßig wird kein Client-JavaScript ausgeliefert (die bequeme Position bei INP), und WordPress wird beim Build über REST gelesen, mit derselben Authentifizierung wie jeder andere Client. Astros eigener WordPress-Leitfaden nutzt genau diese eingebaute REST API und nennt WPGraphQL als Option. Es bleiben zwei Deployments und ein Webhook, der das Frontend beim Veröffentlichen invalidiert, also wieder das Problem aus dem Hosting-Abschnitt: Jemand muss dafür zuständig sein.

#Next.js, Astro oder Nuxt für Headless WordPress

#Next.js (React)

• Am besten für: interaktive Anwendungen, Dashboards, Commerce mit Login
• Performance: hängt davon ab, wie viel hydriert wird; mit keinem der drei verschlechtert man INP so leicht, wenn alles zum Client geht
• Personalkosten: hoch, erfahrene React-Entwickler
• Ökosystem: das größte, die ganze React-Welt

#Astro

• Am besten für: Content-Websites, Blogs, Unternehmensseiten, Dokumentation
• Performance: standardmäßig null Client-JavaScript, genau das, was INP belohnt
• Personalkosten: mittel, HTML und CSS plus JavaScript-Grundlagen
• Ökosystem: kleiner als das von React und wachsend; WordPress wird über seine REST API gelesen, nicht über ein offizielles Integrationspaket

#Nuxt (Vue)

• Am besten für: Teams, die bereits mit Vue arbeiten
• Performance: derselbe Hydration-Kompromiss wie bei Next.js
• Personalkosten: mittel bis hoch
• Ökosystem: ausgereift innerhalb von Vue

#Wie misst man den ROI einer Headless-Migration

Wenn Sie die Investition begründen müssen, messen Sie vier Dinge auf der heutigen Website, bevor Sie irgendetwas anfassen, und messen Sie sie neunzig Tage nach dem Launch erneut. Ohne Ausgangslage gibt es keinen ROI zu belegen, nur das Gefühl, dass die Website schneller wurde.

Vor der Migration erfassen:

• Mobilen PageSpeed und Feld-LCP statt Labor-LCP: Nutzen Sie CrUX-Daten, denn die verwendet Google
• Die durchschnittliche Position Ihrer zwanzig kommerziellen Suchbegriffe
• Organische Leads pro Monat, getrennt von Leads aus bezahlten Kampagnen
• Die reale Zeit, die das Marketing braucht, um eine Landingpage zu veröffentlichen

Nach der Migration, die Zeichen, dass die Rechnung aufgeht:

• Das LCP sinkt deutlich und bleibt unten, nicht nur auf der Startseite
• Die durchschnittliche Position verbessert sich bei Seiten, die in der unteren Hälfte der ersten Ergebnisseite standen, denn dort hat Geschwindigkeit noch Spielraum
• Organische Leads steigen, ohne dass sich das Akquisebudget geändert hat
• Die Veröffentlichungszeit ist nicht schlechter geworden, das typische Headless-Risiko

Die Reihenfolge zählt. Steigt die durchschnittliche Position, die Zahl der Leads aber nicht, lag das Problem nie in der Architektur, sondern im Angebot auf der Seite, und das repariert keine Migration.

Wir bauen beides und empfehlen Headless nur, wenn die Zahlen oben dafür sprechen. Steht Astro für Ihr Frontend auf der engeren Wahl, finden Sie hier unsere Astro-Entwicklung, und ein konkretes Projekt besprechen wir über den Kontakt.