Headless WordPress auf Next.js oder Astro — wp-admin behalten, Plugin-Steuer los.

Headless WordPress ist richtig, wenn eine von drei Sachen wahr ist. Das Standard-Setup von klassischem WordPress ist sonst falsch — Headless bringt Engineering-Overhead mit sich und du solltest nicht dafür zahlen ohne einen echten Grund.

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 die Editorial-Mannschaft zu verlieren. Ingenieure, die täglich TypeScript schreiben, werden vom WordPress Front-End-Stack frustriert. PHP-Templates, jQuery, Page-Builder-Shortcodes — die Sprache ist falsch, die Tools sind falsch, die Deploy-Story ist falsch. Headless ermöglicht es dem Engineering-Team, in einer Next.js oder Astro Codebasis mit Versionskontrolle, Typ-Checking, Edge-Deployment und Component-Driven Design zu arbeiten, während Redakteure wp-admin, Yoast und ACF unverändert behalten.

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 Front-End-Framework ist normalerweise Next.js mit App Router für Marketing-Websites und Apps mit Auth oder Interaktivität. Astro ist der einfachste Weg für inhaltsreiche Websites, die von statischer Generierung profitieren und nur auf spezifischen Komponenten partielle Hydration benötigen. Nuxt ist die richtige Wahl, wenn das Team bereits Vue nutzt. Wir setzen standardmäßig auf Next.js plus WPGraphQL plus ein kleines Custom-Scaffolding statt Faust.js, weil Faust Meinungen mitbringt, mit denen wir manchmal nicht einverstanden sind — aber Faust ist hervorragend, 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 das Front-End vom Back-End. Front-End auf Vercel, Netlify oder Cloudflare Pages je nach Team-Vorliebe. Back-End auf Cloudways, Kinsta oder WP Engine auf einer nicht öffentlichen Subdomain — cms.yourdomain.com — geschützt hinter Cloudflare Access oder einer IP-Allowlist. Öffentlicher Traffic trifft niemals direkt auf WordPress. WordPress wird unsichtbar aus dem öffentlichen Web; nur deine Redakteure 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 — jeder Post, jede Page, jeder Custom-Post-Type, jede Taxonomie und jedes ACF-Feld, gefetcht via WPGraphQL bei Build oder Revalidierung. Media folgt: jedes hochgeladene Bild mit WordPress-seitiger WebP-Optimierung wenn verfügbar oder Front-End-seitiger Bild-Optimierung sonst. SEO-Metadaten sind das Dritte — Yoast- oder Rank-Math-Felder verbunden via Plugin-Companion-GraphQL-Schemas, 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 Plugin-emittiertes JSON-LD durch handgeschriebene Templates im Front-End für saubere Ausgabe. Article, BlogPosting, Service, Product, BreadcrumbList — alle generiert aus typisierten Daten, validiert bei Build-Zeit. Redirects sind das Fünfte: alles im Yoast Redirect Manager oder im Redirection Plugin wird exportiert und als 301er in vercel.json oder _redirects auf Netlify verschickt, niemals als JavaScript-Redirects die Ranking-Signal im 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 schweres CSS und HTML ins Front-End. Nichts davon läuft auf einem headless Front-End. Die meisten Migrationen beinhalten ein Content-Rewrite als Teil des Projekts — wir extrahieren den Content, formatieren ihn neu, um mit der Komponentenbibliothek des neuen Front-Ends zu passen, und überspringen den Import der Visual-Builder-Schicht komplett. Redakteure bekommen eine neue, einfachere Editing-Oberfläche basierend auf Gutenberg Blöcken plus ACF flexible content. Der Content bleibt erhalten, der Visual Builder nicht, und das Seitengewicht sinkt erheblich als Nebeneffekt.

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.

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