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: eine entkoppelte 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 die 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. Langes Modell mit Vierjahres-Cashflow: TCO-Leitfaden Headless vs Monolith WordPress 2026.
1. Aufbaukosten zu Beginn (Jahr 0)
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.1 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 auf der 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(). Ihre 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.
2. Wartung und Betrieb (Jahr 1-3)
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 die 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 7.1.1 landete am 17. September 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 eine entkoppelte 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. Im DACH-Raum dasselbe über BFSG: Barrierefreiheit gehört in den Umbau-Scope, nicht als späteres Layer.
3. Performance und Conversion Rate
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.
4. Die „Plugin-Steuer“
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.
5. Hosting-Kosten
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 die 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 die Frontend erreicht. Auf einem Monolith invalidiert das Veröffentlichen Object Cache und Page Cache. Auf einer 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.
6. Das Urteil: wann Headless wählen?
Traditionelles WordPress nutzen, wenn
- Das Budget einen Build deckt, danach keinen stehenden Frontend-Engineer.
- Marketing visuelle Plugins ohne Entwickler in der Schleife installiert.
- Informative Site: Speculative Loading und Cache liefern schon den Großteil des Geschwindigkeitsgewinns.
- Keine interne JS-Kompetenz und kein Hire-Plan. Die Agentur baut; jemand muss es am Leben halten.
Headless WordPress nutzen, wenn
- Sie an mehr als ein Ziel aus einem Workflow publizieren (Website + App / Content-Fläche im Produkt).
- Sie den WordPress-Origin vom Netz nehmen; Compliance oder Threat Model rechtfertigt das.
- Performance ist Umsatz, Volumen trägt ein stehendes Team, JS ist Opt-in.
- WordPress ist ein System unter ERP/CRM, Content-Modell stabil.
Headless ist eine Staffing-Entscheidung mit angehängter Architektur. Wer schreibt die Frontend in Monat achtzehn, und steht die Person auf der Payroll? Unklare Antwort heißt Monolith.
Wir bauen beides; Headless nur wenn die Zahlen zu seinen Gunsten ausfallen. Astro auf der Shortlist: Astro-Entwicklung. Scope: Kontakt.
