Headless WordPress auf Next.js oder Astro, wp-admin behalten, Plugin-Abhängigkeit loswerden.

Headless WordPress ist richtig, wenn eine von drei Bedingungen erfüllt ist. Das klassische WordPress-Setup ist sonst die richtige Wahl, Headless bringt Engineering-Overhead mit sich und du solltest dafür nicht zahlen, ohne einen echten Grund zu haben.

Der erste Grund ist Performance. Eine reine WordPress-Site mit fünf oder sechs Plugins liefert etwa siebenhundert Kilobyte JavaScript aus, bevor das H1 rendert, und mit Elementor oder Divi plus typischem Addon-Stack liefern echte Seiten zwei bis drei Megabyte beim ersten Laden. Es gibt eine harte Grenze bei Lighthouse und CrUX-Felddaten selbst mit dem besten Caching-Plugin davor. Headless auf einem statischen oder ISR Next.js oder Astro Front-End knackt konstant über fünfundneunzig auf Lighthouse auf Shared Hosting und die Felddaten folgen.

Der zweite Grund ist Engineering-Erfahrung, ohne das Editorial-Team zu verlieren. Engineers, die täglich TypeScript schreiben, werden vom WordPress-Frontend-Stack frustriert. PHP-Templates, jQuery, Page-Builder-Shortcodes, die Programmiersprache ist falsch, das Tooling ist falsch, die Deployment-Story ist falsch. Headless ermöglicht es dem Engineering-Team, in einer Next.js- oder Astro-Codebasis mit Versionskontrolle, Type Checking, Edge-Deployment und komponentengesteuertem Design zu arbeiten, während Editoren wp-admin, Yoast und ACF unverändert nutzen.

Der dritte Grund ist Multi-Destination. Eine Marketing-Website, eine Mobile App, ein internes Portal und ein Partner-Portal alle lesend aus der gleichen Content-Quelle. Klassisches WordPress ist ein CMS, ein Front-End. Headless WordPress wird zum Editorial-Backend für welche Destinations du brauchst, jede mit ihrem eigenen Front-End-Framework optimiert für ihre Oberfläche.

Drei Entscheidungen prägen die meiste Engineering-Geschichte.

Das Frontend-Framework ist normalerweise Next.js mit App Router für Marketing-Seiten und Apps mit Auth oder Interaktivität. Astro ist der einfachste Weg für inhaltsintensive Seiten, die von Static Generation profitieren und nur auf spezifischen Komponenten partielle Hydration benötigen. Nuxt ist die richtige Wahl, wenn das Team bereits mit Vue arbeitet. Wir setzen standardmäßig auf Next.js plus WPGraphQL plus kleine Custom-Scaffolding statt auf Faust.js, weil Faust Meinungen mitbringt, denen wir teilweise widersprechen, aber Faust ist ausgezeichnet, wenn du möchtest, dass das Framework die Entscheidungen für dich trifft.

Die API-Schicht ist standardmäßig WPGraphQL. Typisierte Query-by-Shape-API, ACF-Unterstützung via WPGraphQL für ACF, Yoast-Unterstützung via Yoast SEO für WPGraphQL, RankMath-Äquivalent. WP REST funktioniert ohne Plugin und ist für einfache Websites in Ordnung, aber du fetchst mehr Daten als du brauchst und es gibt keine Schema-Introspektion im Front-End. Griff zu REST nur, wenn WPGraphQL durch Hosting-Policy blockiert ist oder wenn du einen sehr kleinen Datensatz hast.

Hosting trennt Frontend und Backend. Frontend auf Vercel, Netlify oder Cloudflare Pages je nach Team-Vorliebe. Backend auf Cloudways, Kinsta oder WP Engine auf einer nicht-öffentlichen Subdomain, cms.yourdomain.com, geschützt durch Cloudflare Access oder eine IP-Allowlist. Öffentlicher Traffic trifft WordPress nie direkt. WordPress wird unsichtbar aus dem öffentlichen Web; nur deine Editoren wissen, dass es dort ist.

Ein erfolgreiches Headless-WordPress-Build transportiert fünf Dinge von der WordPress-Seite zum öffentlichen Front-End ohne Qualitätsverluste auf dem Weg.

Content ist das Offensichtliche, jeden Post, jede Page, jeden Custom Post Type, jede Taxonomie und jedes ACF-Feld über WPGraphQL bei Build oder Revalidierung abrufen. Media folgt: jedes hochgeladene Bild mit WordPress-seitiger WebP-Optimierung falls verfügbar oder Frontend-seitiger Bild-Optimierung andernfalls. SEO-Metadaten sind das Dritte, Yoast- oder Rank-Math-Felder über Plugin-Companion-GraphQL-Schemas verbunden, gerendert als canonical, title, description, OG und Twitter Card aus der typisierten Response.

Schema ist das Vierte und die meisten Teams machen es falsch. Wir ersetzen von Plugins emittiertes JSON-LD durch handgeschriebene Templates im Frontend für saubere Ausgabe. Article, BlogPosting, Service, Product, BreadcrumbList, alle aus typisierten Daten generiert, bei Build-Time validiert. Redirects sind das Fünfte: Alles im Yoast Redirect Manager oder dem Redirection Plugin wird exportiert und als 301s in vercel.json oder _redirects auf Netlify ausgeliefert, niemals als JavaScript-Redirects, die das Ranking-Signal beim Transit verlieren.

Der Transport ist automatisiert. Wir bauen keine dieser Schichten pro Website von Hand. Das gleiche Scaffolding wird bei jedem Headless-Build genutzt, den wir machen, darum ist die Pro-Website-Kosten über Zeit gesunken, obwohl sich die Engineering-Oberfläche vergrößert hat.

Page Builder brechen zuerst. Elementor und Divi injizieren schwere CSS und HTML ins Frontend. Nichts davon läuft auf einem Headless-Frontend. Die meisten Migrationen liefern als Teil des Projekts ein Content-Rewrite, wir extrahieren den Content, formatieren ihn um, um die Component Library des neuen Frontends zu passen, und überspringen das Importieren der Visual-Builder-Schicht völlig. Editoren erhalten eine neue, einfachere Bearbeitungs-UX basierend auf Gutenberg Blocks plus ACF flexible content. Der Content bleibt erhalten, der Visual Builder nicht, und das Page Weight sinkt als Nebeneffekt erheblich.

Kommentare und Formulare brauchen auch ein Überdenken. Native WordPress-Kommentare rendern nicht headless, ohne das Rendering zu proxyen. Die meisten Teams ersetzen sie mit Disqus, Giscus oder einem Custom-Comment-System im Front-End. Formulare migrieren typischerweise zu ConvertKit, HubSpot Forms oder einem Custom-Next.js-Endpoint, der einen Email-Versand-Service aufruft. Contact Form 7 und Gravity Forms haben headless-freundliche Versionen, erfordern aber explizite GraphQL-Integration, die zusätzliche Arbeit bedeutet.

Frontend-Plugins sind das Dritte, das bricht. Alles, das HTML oder JavaScript ins WordPress-Frontend injiziert, funktioniert nicht mehr, Security-Plugins, Caching-Plugins, Schema-Plugins, Social-Share-Plugins. Jedes wird entweder durch Code im Frontend oder durch einen Managed Service ersetzt. Die Plugin-Anzahl sinkt typischerweise nach der Migration um siebzig bis achtzig Prozent. Das ist Teil des Gewinns, keine Regression.