Was ist Headless WordPress?

Headless WordPress ist eine Architektur, bei der WordPress nur als Content Management System (CMS) und Content-API genutzt wird, während das öffentliche Frontend mit einem separaten Technologie-Stack gebaut wird. Die klassische WordPress-Theme-Ebene (PHP, Template Hierarchy, jQuery) wird entfernt oder ignoriert, und die Frontend-Anwendung holt die Inhalte über die WordPress-REST-API (seit WordPress 4.7 im Dezember 2016) oder einen GraphQL-Endpunkt des WPGraphQL-Plugins (über 60.000 aktive Installationen Stand 2025). Beliebte Frontend-Frameworks für Headless WordPress sind Next.js (React, von Vercel), Astro, Nuxt (Vue), SvelteKit, Gatsby (Static Site Generator), Remix, Eleventy und Hugo. Das Frontend wird separat deployed, oft als statisches HTML auf einem CDN (Vercel, Netlify, Cloudflare Pages, AWS Amplify) oder als serverseitig gerenderter Node.js am Edge. Treiber der Verbreitung sind schnellere Ladezeiten, bessere Core Web Vitals, moderne Developer Experience und Multi-Channel-Publishing in Web, native Apps und Smart TVs aus einer Quelle.

Wie unterscheidet sich Headless WordPress von klassischem WordPress?

Bei klassischem WordPress rendert derselbe PHP-Prozess, der die Inhalte speichert, auch das HTML. Der Besucher erhält eine Seite, die von einem Theme wie Twenty Twenty Four, Astra, GeneratePress, Divi oder Elementor erzeugt wurde. Bei Headless dient die PHP-Installation nur als JSON-API. Typischer Request Flow:

1. Besucher öffnet https://shop.example.de (das Next.js-Frontend auf Vercel).
2. Das Frontend ruft zur Build- oder Request-Zeit https://cms.example.de/wp-json/wp/v2/posts auf (das WordPress-Backend auf einer anderen Domain).
3. WordPress liefert JSON mit Titel, Inhalt, Featured-Image-URL, Autor und so weiter.
4. Das Frontend rendert die Seite als React- oder Vue-Komponenten und liefert HTML plus ein kleines JavaScript-Bundle aus.

Der WordPress-Admin bleibt unverändert: Redakteure loggen sich weiter unter cms.example.de/wp-admin ein, schreiben in Gutenberg und verwalten Medien wie gewohnt. Nur das eigene Theme erscheint nicht auf der öffentlichen Seite.

Welche APIs nutzt Headless WordPress?

Welche Vorteile bietet Headless WordPress?

• Performance: eine statische Seite vom CDN am Edge wird global in 20 bis 80 Millisekunden ausgeliefert. Klassisches WordPress mit DB-Abfrage und PHP-Render liegt ohne Caching typisch bei 300 bis 1500 ms TTFB.
• Core Web Vitals: LCP unter 2,5 s, INP unter 200 ms und CLS unter 0,1 leichter erreichbar, weil das Frontend nur das nötige JavaScript für Hydration liefert.
• Moderne Developer Experience: React, Vue, Svelte, TypeScript, Komponentenbibliotheken (Tailwind, shadcn/ui, Radix), Hot Module Reload, Git Deployment, Preview Builds pro Pull Request.
• Kleinere Angriffsfläche: die öffentliche Domain führt kein PHP aus. XML-RPC-Brute-Force, Plugin-CVEs und SQL Injection treffen das Frontend nicht. Der WordPress-Admin kann hinter VPN, Basic Auth oder IP-Allowlist verborgen werden.
• Multi-Channel-Publishing: ein WordPress-Backend versorgt Website, React-Native-App, Flutter-App, Smart TV, Slack-Bot und Alexa-Skill aus denselben Inhalten.
• Skalierung: Traffic-Spitzen erreichen das WordPress-Origin nicht, wenn das Frontend Incremental Static Regeneration (ISR) oder Full Static Export nutzt.
• Editor unverändert: Gutenberg, Custom Fields, ACF, wiederverwendbare Blöcke, Scheduling und Revisions bleiben erhalten.

Welche Nachteile hat Headless WordPress?

• Höhere Kosten: zwei Systeme zu hosten, monitoren, aktualisieren. Zwei CI/CD-Pipelines. Zwei Domains und Zertifikate.
• Preview kaputt: der WYSIWYG-Preview in Gutenberg zeigt das ungenutzte Theme, nicht die echte Seite. Workarounds: WPGraphQL Smart Cache plus Preview Mode in Next.js oder Faust.js von WP Engine.
• Plugins mit HTML-Injection brechen: Kontaktformular-Plugins (Contact Form 7, WPForms), Page Builder (Elementor, Divi, Beaver Builder) und viele SEO-Plugin-Funktionen brauchen das WordPress-Theme. Yoast SEO und Rank Math haben WPGraphQL-Brücken, Shortcodes von Drittanbieter-Plugins brauchen Eigenarbeit.
• SEO mit Sorgfalt: Canonical URL, hreflang, Sitemap, robots.txt, Open Graph und Twitter Cards müssen manuell aus der API ins Frontend-HTML gemappt werden.
• Build-Zeit: voll statische Seiten mit tausenden Posts brauchen 5 bis 30 Minuten. ISR und On-Demand-Regeneration helfen.
• Kommentare und Formulare: native WordPress-Kommentare erscheinen nicht. Entweder abschalten, auf Disqus wechseln oder ein eigenes UI bauen, das per REST-API postet.
• Kosten der Expertise: React-Entwickler sind in den meisten Märkten teurer als PHP-Theme-Entwickler.

Welche Frameworks sind für Headless WordPress am beliebtesten?

• Next.js (Vercel): die häufigste Wahl. SSR, SSG, ISR, Edge Functions. Viele Starter (Vercel-Beispiel mit WordPress, Faust.js von WP Engine).
• Astro: liefert standardmäßig null JavaScript, perfekt für Content-Seiten. Astro 4.0 (Dezember 2023) brachte View Transitions.
• Nuxt (Vue 3): Pendant zu Next.js im Vue-Ökosystem. Nuxt 3 seit 2022 mit Nitro-Server.
• SvelteKit: kleinste Bundle-Größen, wachsende Community.
• Gatsby: war einst die erste Wahl für WordPress (gatsby-source-wordpress). Im Februar 2023 von Netlify übernommen, Entwicklung verlangsamt.
• Eleventy (11ty): einfacher SSG ohne JS-Framework.
• Remix: seit November 2024 mit React Router 7 zusammengelegt.

Wie hoste ich Headless WordPress?

• WordPress-Backend: jeder Managed-WordPress-Hoster funktioniert (Kinsta, WP Engine, Cloudways, Hetzner mit eigenem Stack, SiteGround). Manche bieten dezidierte Headless-Pläne: WP Engine Atlas, Kinsta Headless, Pantheon Decoupled.
• Frontend: Vercel (Heimat von Next.js), Netlify, Cloudflare Pages, AWS Amplify, Cloudflare Workers, Render, Railway, Fly.io. Statische Exports auch auf S3 + CloudFront oder einem normalen Webserver.
• Content Delivery: API-Antworten am Edge cachen (Cloudflare Workers, Vercel Edge Cache) oder ISR nutzen, sodass das WordPress-Origin maximal einmal pro Minute pro Seite getroffen wird.

Beispiel mit Next.js und WPGraphQL

// app/page.tsx im Next.js 15 App Router
async function getPosts() {
  const res = await fetch('https://cms.example.de/graphql', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      query: `{ posts(first: 10) { nodes { id title slug excerpt date } } }`,
    }),
    next: { revalidate: 60 },
  });
  const json = await res.json();
  return json.data.posts.nodes;
}

export default async function Home() {
  const posts = await getPosts();
  return (
    <main>
      {posts.map(p => (
        <article key={p.id}>
          <h2>{p.title}</h2>
          <p>{p.excerpt}</p>
        </article>
      ))}
    </main>
  );
}

Die Seite revalidiert alle 60 Sekunden, kommt aus dem Vercel Edge Cache und trifft WordPress nur, wenn der Cache abgelaufen ist.

Wann sollte man NICHT auf Headless setzen?

• Kleine Content-Seite unter 50 Seiten ohne Performance-Probleme. Klassisches WordPress mit schnellem Theme (GeneratePress, Astra, Kadence), Caching-Plugin (WP Rocket, LiteSpeed Cache) und Cloudflare reicht.
• Page Builder werden für visuelles Editieren benötigt und das Team kann kein React oder Vue.
• Hunderte Plugins, die Frontend-HTML einspielen (Buchungskalender, Anzeigeneinsteller, Membership Flows).
• WooCommerce mit komplexem Checkout, auch wenn WooCommerce-REST-API und WPGraphQL for WooCommerce Produktkataloge möglich machen.

Wie steht es um SEO in Headless WordPress?

Suchmaschinen rendern JavaScript, sicherer ist aber Server-Side-Rendering oder Static Generation, sodass HTML auf den ersten Response bereits Inhalt enthält. Notwendige Mappings aus WordPress ins Frontend:

• Title, Meta Description, Canonical, Open Graph, Twitter Card. Yoast und Rank Math liefern diese über WPGraphQL.
• XML-Sitemap. Entweder /sitemap_index.xml proxyen oder aus der API generieren.
• robots.txt.
• JSON-LD strukturierte Daten.
• Redirects von alten WordPress-URLs auf neue Frontend-URLs (Redirection-Plugin-Export plus Frontend-Rewrite-Regeln).

Wie hilft InspectWP bei Headless WordPress?

InspectWP analysiert die öffentliche URL und erkennt anhand der Response-Header (x-vercel-id, x-nf-request-id, cf-ray) und HTML-Signaturen, ob die Seite von einem CDN wie Vercel, Netlify oder Cloudflare Pages statt von einem klassischen WordPress-Origin geliefert wird. Die WordPress-Erkennung läuft gegen den API-Endpunkt, falls eine separate CMS-Subdomain gefunden wird.