Headless-WordPress-Architektur 2026: wann Entkopplung sich lohnt

Die Frage 2026 lautet nicht, ob WordPress ohne Theme laufen kann. Das kann es. Die Frage lautet, welche Topologie Gutenberg, Vorschau, Login und Checkout übersteht, ohne dass Origin zu einem öffentlichen PHP-Endpunkt wird.

Jahrelang bedeutete Headless WordPress, dass die Redaktion die Vorschau verlor, Menüs zu JSON-Handarbeit wurden und jedes Formular eine eigene REST-Route brauchte. Diese Löcher sind geschlossen. WordPress 7.0 (Armstrong) erschien am 20. Mai 2026. WordPress 7.1 auf PHP 8.4 ist die Origin, gegen die wir bauen. Gutenberg liefert Blockbäume als JSON. WPGraphQL kennt persisted Queries. Astro 7 liefert HTML mit JavaScript nur auf Islands. Next.js 16 liefert Partial Prerendering und Server Actions. Was bleibt, ist Architektur: wer den Datenvertrag besitzt, wo der Cache liegt, und wie die Origin hinter Zero Trust, C5 und einer nachvollziehbaren Softwarestückliste (SBOM) steht.

Das ist ein Architekturtext. Das Vierjahres-Kostenmodell mit CapEx und OpEx steht im TCO-Leitfaden Headless versus Monolith. Die Tabelle gehört nicht hierher. Lesen Sie sie, wenn Sie ein Budget verteidigen. Lesen Sie diesen Text, wenn Sie Kästen und Pfeile zeichnen.

#Wann Entkopplung die richtige Topologie ist

Entkopplung lohnt sich, wenn Content mehr als einen Konsumenten hat oder wenn die Security-Policy verbietet, PHP öffentlich ins Internet zu stellen. Sie lohnt sich nicht als Dekoration auf einer Marketing-Site mit drei Redakteuren, die jede Woche Gutenberg-Landings ausliefern.

Wählen Sie Headless, wenn mindestens eines davon gilt:

1. Derselbe Text muss aufs Web, in die App, auf Filialbildschirme und als Quelle für interne Assistenten, ohne dass die Redaktion dreimal paste.
2. Das Frontend-Team besitzt ein Designsystem in Astro oder React, und WordPress darf kein Markup diktieren.
3. wp-admin und die Datenbank liegen im privaten Netz hinter SSO. Öffentliche Origin sind statische Dateien und gecachte Dokumente.
4. TTFB unter 50 ms global ist Anforderung, und Sie akzeptieren, dass der Cache am Edge mit Tag-Invalidierung lebt.

Bleiben Sie beim Monolithen, wenn:

1. Marketing Landingpages in Gutenberg baut, ohne für jede neue Blockvariante auf einen Frontend-Entwickler zu warten.
2. Der WooCommerce-Checkout Erweiterungen nutzt, die HTML, Shortcodes und eigene Session-Cookies im gleichen Request wie den Shop schreiben.
3. Das Team PHP-Kapazität hat und keinen TypeScript-Owner. Zwei Pipelines ohne Owner sind keine Architektur. Das ist eine Incident-Warteschlange.

Ein moderner Monolith auf PHP 8.4 mit Full Site Editing, Redis und Page Cache ist kein „altes WordPress“. Er verliert bei Multi-Channel und bei der Angriffsfläche. Er gewinnt bei redaktioneller Geschwindigkeit. Wählen Sie die Architektur gegen den Verlust, den Sie wirklich haben, nicht gegen einen Vortrag mit dem Titel Headless.

Zwei Fälle, die wir gemessen haben, bevor wir die Kästen zeichneten:

1. Ein WooCommerce-Katalog mit über 30 Plugins und TTFB um 1,8 s auf Kategorieseiten. Das PHP-Theme baute verwandte Produkte, Reviews, Schema und ein Mega-Menü bei jedem Request. Der Katalog wanderte nach Astro 7 mit getaggten GraphQL-Reads. Checkout blieb auf Next.js 16, weil Session und Zahlungsplugins weiterhin einen request-gebundenen Runtime brauchten.
2. Eine Elementor-Marketingseite, die unter Cyber-Week-Last (der deutschen Black-Friday-Woche) einknickte. Der Page Builder setzte voraus, dass PHP jede Variante malt. Es gab keine Cache-Tag-Story, nur „alles purgen“. Headless hat das Projekt nicht gerettet. Wir haben den Builder entfernt, ein gekoppeltes Theme behalten und Redis plus Page Cache davor gesetzt. Einen Page-Builder-Stack zu entkoppeln ist eine Umschrift des redaktionellen Modells, kein Hosting-Wechsel.

Preis und Ownership über vier Jahre sind eine andere Frage. Nutzen Sie den TCO-Leitfaden, wenn Sie CapEx im ersten Jahr mit späterem Betrieb vergleichen. Hier endet die Topologie.

#Frontend zuerst: Astro 7 Islands und Next.js 16

Wählen Sie das Framework danach, wie viel der Seite Dokument und wie viel Anwendung ist. Content-lastige Flächen gehören in Astro 7. Flächen mit Session, Warenkorb und Echtzeitfiltern gehören in Next.js 16. Beide lesen dieselbe WordPress-Origin.

Astro 7 kompiliert Seiten zu HTML. Der Standard-First-Paint ist null Kilobyte JavaScript. Interaktive Teile (Suche, Filter, Mini-Cart, Login) hydrieren als Islands mit client:visible oder client:idle. Das passt zu einer redaktionellen WordPress-Installation: die meisten URLs sind Artikel, Landings und Archive. Sie brauchen keine React-Runtime im <head>.

Next.js 16 ist die richtige Wahl, wenn große Teile der Ansicht von Login-Status, Personalisierung oder einem Warenkorbbaum abhängen, der sich nicht vorab rendern lässt. App Router, React Server Components und Partial Prerendering halten die Shell statisch und füllen Löcher am Edge (Preis, Bestand, Bezahlknopf). Server Actions ersetzen eigene REST-Endpunkte für Formulare, solange die Action WordPress hinter Zero Trust aufruft und kein Admin-Cookie an den Browser gibt.

Ein Hybrid ist üblich: Astro 7 für Magazin, Marke und Docs, Next.js 16 für Mein Konto und Checkout. WordPress bleibt eine Origin. Zwei Fronts brauchen einen gemeinsamen Block-zu-Komponenten-Katalog und ein GraphQL-Schema. Ohne diesen Katalog divergieren die Views innerhalb eines Quartals.

Faust.js und ähnliche WordPress-spezifische Next-Schichten können Preview-Cookies abkürzen. Sie sind keine Anforderung. Ein schlanker Preview-Endpunkt mit HMAC und Draft Mode leistet dieselbe Arbeit und funktioniert gegen Astro und gegen Next. Lassen Sie keinen Vendor-Starter die Topologie wählen.

Client (Browser)
        |
        v
Edge (Cloudflare): HTML, Assets, Cache-Tags
        |
        +-- Treffer: fertiges Dokument, kein PHP
        |
        +-- Miss (Vorschau, Mein Konto, Checkout)
               |
               v
        Frontend-Runtime (Astro 7 / Next.js 16)
               |
               v
        Zero-Trust-Gateway
               |
               v
        WordPress 7.1 / PHP 8.4 / WPGraphQL
               |
               v
        MySQL + Redis

Wenn rund 80 Prozent der Seitentreffer nie PHP erreichen, haben Sie eine Headless-Architektur. Wenn jeder Treffer Origin anfasst, um „dynamisch zu bleiben“, haben Sie einen teureren Monolithen mit Extra-Hop.

#Datenvertrag: WPGraphQL, REST und persisted Queries

WPGraphQL ist der Lesepfad für reiche Seiten. REST ist der Schreibpfad für einfache Ereignisse. Die Mischung ist Absicht, kein Kompromiss, den Sie „später aufräumen“.

Ein klassischer REST-Call gegen /wp-json/wp/v2/posts liefert Dutzende Felder, die ein Archiv nicht braucht. Eine Seite mit Beitrag, Autor, drei verwandten Posts und einem ACF-Repeater wird zu mehreren HTTP-Runden. WPGraphQL löst den Baum in einem Call, DataLoader fasst ID-Lookups zu WHERE ID IN (...) zusammen. Deshalb hat GraphQL auf entkoppelten WordPress-Flächen gewonnen, nicht weil GraphQL Mode ist.

Drei Regeln für das Schema:

1. Exponieren Sie, was die Redaktion besitzt, nicht was das Theme besaß. Custom Post Types, Taxonomien und Felder. Nicht the_content als HTML-Sack voller Shortcodes, die eine PHP-Runtime erwarten.
2. Persisted Queries in Produktion. Der Client sendet einen Hash, keine beliebige Query. Introspection ist aus. Maximale Tiefe und Komplexität sind gesetzt. Ohne das ist GraphQL ein offenes Fenster in die Datenbank.
3. Cache-Tags auf der Antwort. post-1425, tax-thema-headless, author-8, lang-de. Ohne Tags leeren Sie den ganzen Edge, sobald jemand einen Tippfehler korrigiert.

REST behält die Jobs, in denen GraphQL schwach ist: eingehende Webhooks, Zahlungsereignisse, Formular-Posts von einem dünnen Endpunkt und CRUD aus internen Tools. Diese Endpunkte authentifizieren mit App Passwords oder kurzen JWTs, nie mit einem unendlichen Application Password im Frontend-Repo.

<?php
declare(strict_types=1);

add_action('graphql_register_types', static function (): void {
    register_graphql_field('Post', 'heroKicker', [
        'type' => 'String',
        'description' => 'Kurzer Kicker über dem Hero, redaktionell geführt.',
        'resolve' => static fn ($post) => get_post_meta($post->databaseId, 'hero_kicker', true) ?: null,
    ]);
});

Lässt sich ein Feld nicht in einem Satz für eine Redakteurin beschreiben, gehört es nicht ins öffentliche Schema. Ein Feld wie heroKicker wirkt trivial. Es ist der Vertrag, der Astro und Next erlaubt, den LCP-Text ohne Raten vorzuladen. Das Schema ist die Architektur. Ohne es wird jede Seite eine Ad-hoc-Query, und die Cache-Schlüssel stimmen nicht mehr.

#WordPress 7.1 als Origin, nicht als Seiten-Renderer

Das ist der Default, den wir ausliefern: WordPress ist Content-Origin, nicht HTML-Fabrik. Das Theme-Verzeichnis auf Origin ist entweder leer von öffentlichen Templates oder auf einen Stub reduziert, der anonyme GET mit 403 beantwortet. Redakteure leben weiter in wp-admin. Besucher nie.

WordPress 7.1 zählt hier, weil der Block-Editor bereits einen Baum serialisiert, keinen String aus PHP-gerendertem Markup. Behandeln Sie diesen Baum als Vertrag. Custom Post Types, Taxonomien und ACF-Felder sind first-class. the_content als HTML-Sack ist Fallback für Legacy-Posts, die Sie noch nicht gemappt haben, nicht die Zielform.

Make WordPress Slack (#core-editor, #hosting) und das Block Editor Handbook sind die Referenzen für die JSON-Form, kein Drittanbieter-Kurs mit dem Label Headless. Hat ein Block kein save-Output und nur ein render.php, ist er PHP-only. Er überlebt Entkopplung nicht, solange Sie keinen JSON-Renderer nachziehen.

In deutschen Redaktionen sehen wir oft denselben Fehler: Elementor oder ein Page Builder bleibt „für den Übergang“ auf Origin, während Astro die öffentlichen URLs bedient. Dann gibt es zwei Wahrheiten für denselben Beitrag. Die Vorschau in wp-admin zeigt den Builder, die Live-Site zeigt den Block-Katalog. Entfernen Sie den Builder, bevor Sie entkoppeln, oder bleiben Sie gekoppelt. Beides ist ehrlich. Beides gleichzeitig ist Incident-Warteschlange.

#Gutenberg als JSON, nicht als HTML-Sack

Der Standard 2026 ist Block-zu-Komponenten-Mapping. WordPress serialisiert jeden Block mit name, attributes und innerBlocks. Das Frontend hat ein Dictionary: core/paragraph wird zu <Prose>, core/image zu <Figure>, acf/pricing-table zu <PricingTable>. Unbekannte Blocknamen rendern in Staging einen sichtbaren Fallback und in Produktion einen leeren Knoten plus Logzeile. Stilles Verwerfen ist der Start von Design-Drift.

Senden Sie nicht the_content und hoffen, React werde „einfach das HTML rendern“. Shortcodes, do_shortcode, Gravity-Forms-Markup und Elementor-Widgets setzen PHP voraus. Sie sehen in der wp-admin-Vorschau gegen das alte Theme korrekt aus und auf der Astro-Site falsch. Das ist der Zwei-Wochen-Vertrauensbruch aus der Einleitung, nur mit anderem Hut.

Halten Sie einen Katalog. Wenn Magazin Astro 7 und Checkout Next.js 16 ist, importieren beide dasselbe Mapping-Modul. Ein neuer Block, der nur in einem Frontend existiert, ist ein Produktbug, kein Nice-to-have.

Das Block Editor Handbook und Trac-Tickets um parse_blocks / serialize_blocks sind die Quelle für den Baum. Vendor-Kits „Gutenberg to React“ veralten in dem Moment, in dem Core ein Block-Attribut ergänzt.

Konsequenz für die Redaktion: jeder neue Gutenberg-Block braucht eine Komponente im Katalog. Das ist die echte Kostenstelle von Headless, und sie gehört in den TCO-Leitfaden, nicht in einen Absatz über „Freiheit“. Begrenzen Sie die Palette. Ein Designsystem mit zwölf Blöcken schlägt ein Theme mit achtzig Blöcken, die niemand gemappt hat.

Bilder laufen durch die Frontend-Bildpipeline (Astro Assets oder next/image) nach AVIF mit Breiten, die zum Layout passen. WordPress speichert das Original. Origin soll kein helden-4000px.jpg an Mobile ausliefern.

#Vorschau ohne den Produktionscache zu zerstören

Vorschau ist ein Feature mit Sprint-Budget. Sie ist kein Häkchen im Hosting-Panel.

Ablauf, den wir ausliefern:

1. Die Redaktion klickt Vorschau in wp-admin.
2. WordPress signiert ein kurzlebiges HMAC-Token gebunden an Post-ID, User-ID und Ablauf.
3. Der Browser öffnet die Frontend-Route /preview mit diesem Token.
4. Die Frontend-Runtime umgeht den anonymen Cache, holt den Entwurf über WPGraphQL mit dem Token und rendert denselben Komponentenbaum wie Produktion.
5. Der Produktionscache der Live-URL bleibt unberührt.

Holt die Vorschau den Live-Permalink statt des Entwurfs, „korrigiert“ die Redaktion Text, der schon veröffentlicht ist. Teilt die Vorschau den anonymen Cache-Schlüssel, leckt ein Entwurf zum nächsten Besucher. Beide Bugs sind schlimmer als eine fehlende Vorschau.

Draft Mode in Next.js und eine no-store-Astro-Preview-Route sind Implementierungsdetails. Der Vertrag lautet: signiert, zeitlich begrenzt, post-scoped und vom öffentlichen Cache-Schlüssel isoliert.

Geplante Veröffentlichung nutzt denselben Pfad: ein Webhook bei future nach publish purgt die Tags. Das Preview-Cookie ist für anonyme Treffer irrelevant. Faust.js kann die Cookie-Arbeit für Next.js tragen. In Astro 7 schreiben Sie die Route selbst. Das sind fünfzig Zeilen, keine Framework-Entscheidung.

#Cache-Tags am Edge

Der Edge ist der HTML-Speicher. Origin ist die Invalidierungsquelle.

Bei Publish, Update oder Delete feuert WordPress einen Webhook mit den geänderten Tags. Cloudflare (oder das Äquivalent) purgt diese Tags. Ein Tippfehler in Beitrag 1425 purgt post-1425 und vielleicht tax-news. Er purgt nicht die Homepage jeder Locale.

Stale-while-revalidate ist für anonyme Dokumente erlaubt. Für Vorschau, Warenkorb oder Mein Konto nicht. Diese Routen sind Cache-Bypass by construction.

Wir hosten das Frontend nicht „auf Vercel oder Netlify“ als Markenwahl. Wir legen HTML auf Cloudflare, weil Cache-Tags und HTML dasselbe Produkt sind. Eine Plattform, die nur per URL oder „alles“ purgen kann, treibt Sie zurück zu Full Rebuilds. Full Rebuilds sind der Weg, auf dem Headless-Projekte langsamer werden als das PHP-Theme, das sie ersetzt haben.

Cache-Control: public, s-maxage=31536000, stale-while-revalidate=86400 plus Cache-Tag: post-1425 lang-de ist der Vertrag. Bei save_post sendet Origin einen asynchronen Purge dieser Tags. Startseite, Autorenarchiv und der eine Artikel fallen. Der Rest der zehntausend Magazin-URLs bleibt stehen.

Frankfurt gegen eine Datenbank in Amsterdam ist egal, solange der Treffer an einem POP in Deutschland endet. Frankfurt gegen Origin bei jedem HTML-Request ist die Verzögerung, die Leute „Headless ist langsam“ nennen.

Für Performance-Zahlen speziell im Shop siehe Headless WooCommerce auf Astro. Dieser Artikel bleibt beim Invalidierungsmodell.

#C5-Hoster und TR-03183 SBOM an der Origin

Headless in Deutschland steuert Compliance an Origin und Pipeline, nicht daran, ob das Frontend React heißt. Wenn Host, Stückliste und Logaufbewahrung nicht zur Zeichnung gehören, ist die Entkopplung eine schöne Schale um dieselbe PHP-Risikofläche.

BSI C5 Typ 2 trifft den Host der WordPress-Origin. Cloud Computing Compliance Criteria Catalogue ist der deutsche Prüfkatalog für Cloud-Anbieter. Typ 2 bedeutet: ein Wirtschaftsprüfer hat über einen Zeitraum geprüft, nicht nur eine Momentaufnahme (Typ 1). Für die Architektur heißt das: wp-admin und MySQL sitzen bei einem Anbieter, der C5 Typ 2 vorweisen kann, hinter Zero Trust, nicht auf demselben öffentlichen Hostnamen, den Kunden treffen. Der Edge, der HTML ausliefert, kann ein anderes Produkt sein (Cloudflare Pages oder Workers). Die Origin, die Entwürfe, Nutzerdaten und Plugin-Updates trägt, ist der C5-relevante Kasten. „Wir sind Headless, also brauchen wir kein C5“ ist falsch. Sie brauchen C5 dort, wo die Datenbank und die Admin-Oberfläche liegen. Ein globaler Managed-WordPress-Plan ohne C5-Bericht und mit Shared-Admin-URL ist für viele deutsche Einkaufsprozesse spätestens bei der Sicherheitsfreigabe tot, egal wie schnell Astro rendert.

TR-03183 (BSI Technische Richtlinie zur Softwarestückliste) verlangt eine SBOM entlang der Lieferkette. In der Headless-Zeichnung sind das zwei Stücklisten, nicht eine: (1) PHP-Plugins und Themes auf Origin, exportierbar über Composer-Lock oder ein Plugin-Inventar; (2) die Frontend-Pipeline mit package-lock.json / pnpm-lock.yaml, die Astro 7 oder Next.js 16 baut. Die SBOM gehört in den CI-Artefakt-Store und in den Incident-Runbook, nicht in eine PDF, die niemand aktualisiert. Wenn CVE-2024-irgendwas in einer Transitiven Dependency auftaucht, müssen Sie in Minuten wissen, ob sie im Storefront-Bundle oder nur im Dev-Tooling sitzt. Ohne Lockfile-SBOM raten Sie. Raten ist keine Architektur.

GoBD-nahe Logaufbewahrung (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern) betrifft hier Storefront- und Origin-Logs, nicht die DATEV-Rechnungsschreibung. Das ERP-Thema gehört in einen anderen Leitfaden. Für Headless heißt es: Zugriffe auf Checkout, Preisänderungen, Admin-Logins und Purge-Webhooks müssen nachvollziehbar und für die vereinbarte Frist abrufbar sein. Edge-Logs allein reichen nicht, wenn der Trace zwischen Cloudflare, Frontend-Runtime und WPGraphQL abreißt. Halten Sie strukturierte Logs (Zeitstempel, Request-ID, Actor, Aktion) hinter demselben Zero-Trust-Netz wie Origin, mit Retention, die Ihr Steuerberater und Ihre IT-Sicherheit gemeinsam unterschreiben. Eine 7-Tage-Cloudflare-Log-Probe ist kein GoBD-Konzept. Eine 10-Jahres-PDF-Ablage ohne Suchbarkeit auch nicht.

Diese drei Punkte (C5 Typ 2 für Origin-Host, TR-03183-SBOM für Frontend-Lockfile und Plugin-Inventar, GoBD-nahe Retention für Storefront/Origin-Logs) sind der deutsche Frame um dieselbe Topologie. Sie ersetzen weder Cache-Tags noch den Datenvertrag. Sie erklären, warum eine „Headless Woo-Vorlage“ von einem globalen Theme in deutschen Ausschreibungen scheitert: Einkauf fragt nach Prüfberichten und Stücklisten, nicht nach dem Framework-Logo im Footer.

#Authentifizierung hinter Origin

Öffentliche Origin spricht keine Admin-Cookies. wp-admin sitzt hinter Zero Trust (Cloudflare Access oder gleichwertiges SSO). Application Passwords für das Frontend leben im Worker oder auf dem Server, nicht in einer öffentlichen Env-Datei, die in den Browser wandert.

JWT-Plugins mit unendlicher Lebensdauer sind ein Fußangeln. Wenn Sie JWT nutzen: rotieren, an Audience binden, Private Key aus dem Astro-Bundle halten. App Passwords scoped auf einen Bot-User (headless-read) sind für read-only GraphQL einfacher.

Rate Limits gehören ans Gateway, nicht in ein Must-Use-Plugin, das jeder Request bezahlt. Das Gateway sieht GraphQL-Hashes. Das MU-Plugin sieht PHP. Bevorzugen Sie das Gateway.

wp-login.php und /xmlrpc.php liegen nicht auf dem öffentlichen Hostnamen. Passkeys oder SSO in Admin, nicht „starke Passwörter“ als einzige Kontrolle. Observability gehört in dieselbe Kette: propagieren Sie W3C traceparent vom Edge durch den Frontend-Fetch bis WPGraphQL. Loggen Sie Cache-Tag-Set, Persisted-Query-Hash und Origin-Status. Wenn LCP regressiert, wollen Sie wissen, ob das Dokument Cache-Hit, Frontend-Render oder PHP-Miss war, nicht „die Site fühlt sich langsam an“. OpenTelemetry reicht. Erfinden Sie kein viertes Dashboard.

#Vertragstests in CI

Jede GraphQL-Schema-Änderung ist eine Frontend-Änderung. CI muss fehlschlagen, wenn:

• ein Persisted-Query-Hash fehlt
• ein Blockname in Fixtures keine Komponente hat
• ein Pflichtfeld nullable wurde
• Introspection in der Produktionskonfiguration an ist
• die SBOM-Stufe (Lockfile-Hash) vom letzten freigegebenen Artefakt abweicht, ohne dass Security das abgezeichnet hat

Wir laufen diese Checks am Pull Request gegen eine Staging-Origin, die einen bereinigten Produktionsdump restored hat. Ein Schema, das nur in localwp eines Entwicklers existiert, ist kein Vertrag.

E2E für Vorschau: ein Entwurf in WordPress muss mit gültigem Token sichtbar und ohne Token unsichtbar sein. E2E für Cache: das Veröffentlichen von Beitrag 1425 darf die Startseite nicht 404en. Das ist billiger, als es montags in der Redaktion zu entdecken.

#Was WPPoland baut

Wir betreiben Headless WordPress so, wie wir Headless WooCommerce betreiben: das CMS bleibt Origin, das Frontend kommt separat, Vorschau ist First-Class-Feature.

In der Praxis:

• Ein REST- oder WPGraphQL-Vertrag, dokumentiert bevor das Frontend startet, damit Redaktion weiß, welche Felder, Taxonomien und Blockschemas durchverdrahtet sind.
• Preview-URLs, die ein Draft-Token in WP signieren und über die Frontend-Draft-Route auflösen, inklusive ACF und Gutenberg-Blockinhalt.
• Eine Redirect-Map aus der bestehenden Site vor Launch, damit Legacy-URLs auf der neuen Struktur landen und Search Console keinen Regressions-Spike zeigt.
• Ein Rollback-Plan: das PHP-Theme bleibt deploybar, bis das neue Frontend mindestens einen vollen Publikationszyklus Produktionstraffic gehalten hat.
• Origin hinter C5-fähigem Hosting, SBOM aus Lockfile und Plugin-Inventar im CI, Log-Retention, die zur GoBD-nahen Vereinbarung passt.

Wenn Discovery kleines redaktionelles Volumen, einen Plugin-Stack mit Abhängigkeit vom PHP-Frontend oder keine JS-Engineering-Kapazität findet, sagen wir das und empfehlen gekoppelt zu bleiben. Headless ist Werkzeug, kein Statussymbol. Die kommerzielle Fläche ist die Headless-WordPress-Leistung. Das Budgetgespräch ist der TCO-Leitfaden.

Für den Cutover von gekoppelt nach Headless starten Sie mit der Migration zu Next.js und Astro oder der Seite Astro-Entwicklung. Der Spike dauert eine Woche: drei Traffic-stärkste Templates, ein Entwurf mit Vorschau, eine Redirect-Zeile. Die Reibung dieser Woche ist die Reibung, die Sie ein Jahr lang hätten.

#Fazit

Entkoppeln Sie, wenn Content mehr als einen Konsumenten hat, wenn PHP nicht öffentlich sein darf, oder wenn das Frontend-Team das Designsystem schon besitzt. Bleiben Sie gekoppelt, wenn Gutenberg die Landing-Fabrik ist und Checkout weiterhin HTML in PHP schreibt.

WordPress 7.1 auf PHP 8.4 ist eine starke Origin. Astro 7 und Next.js 16 sind starke Fronts. Die Architektur ist der Vertrag dazwischen: persisted Queries, Block-Mapping, HMAC-Vorschau, Cache-Tags, Zero Trust, plus in Deutschland C5 Typ 2 an der Origin und eine TR-03183-SBOM an der Frontend-Pipeline. Fehlt eines davon, haben Sie kein Headless gebaut. Sie haben einen langsameren Monolithen mit Extra-Hops.

Wenn die Spike-Woche sauber ist (drei Templates, ein Entwurf mit Vorschau, eine Redirect-Zeile), haben Sie Evidenz, keine Folie. Wenn sie nicht sauber ist, bleiben Sie gekoppelt und legen das Geld in Redis, Page Cache und das Löschen von Plugins, die bei jedem Request HTML malen. Das ist immer noch Architektur. Sie ist nur ehrlich über das Team, das Sie haben.