WordPress als Headless CMS: Der Entwicklerleitfaden [2026]

WordPress als Headless CMS: Der Entwicklerleitfaden [2026]

WordPress betreibt laut W3Techs 43 % aller Websites, und immer mehr Teams reißen das PHP-Frontend komplett heraus und nutzen WordPress als Content-API. Hier erfahren Sie alles, was Sie über den Betrieb von WordPress im Headless-Modus wissen müssen -- von der Wahl zwischen REST API und WPGraphQL bis zum Deployment eines Next.js-Frontends auf Vercel mit ISR.

Was ist Headless WordPress? (Und warum sollte das interessieren?)

Headless WordPress ist ein Setup, bei dem WordPress das Content Management und die Datenspeicherung übernimmt, während eine separate Frontend-Anwendung -- gebaut mit Next.js, Nuxt, Astro oder einem anderen Framework -- die Inhalte über eine API abruft. WordPress behält sein Admin-Dashboard, den Editor, das Plugin-Ökosystem und die MySQL-Datenbank. Statt Seiten mit PHP-Themes zu rendern, stellt es Inhalte über die WordPress REST API oder WPGraphQL bereit, und das Frontend übernimmt vollständig die Präsentationsschicht.

Vereinfacht ausgedrückt: WordPress wird zur Küche, und das Frontend-Framework ist das Restaurant. Die Küche bereitet das Essen (Inhalte) zu, aber das Restaurant entscheidet, wie es angerichtet wird, wie der Gastraum aussieht und wie Gäste das Erlebnis wahrnehmen.

Traditionelle vs. Headless-Architektur

Bei traditionellem WordPress ist alles ein Monolith. Ein Besucher ruft eine Seite auf, PHP verarbeitet die Anfrage, fragt MySQL ab, verarbeitet das Ergebnis durch die Template-Dateien des Themes und schickt fertiges HTML zurück. Das Theme steuert Layout, Styling und Routing -- alles.

Bei Headless WordPress wird diese gesamte Rendering-Schicht entfernt. WordPress sitzt hinter einer API, meist auf Managed Hosting wie WP Engine oder Kinsta. Das Frontend -- eine React-, Vue- oder Svelte-App -- stellt API-Anfragen, um Inhalte abzurufen, und rendert sie nach eigenen Vorstellungen. Beide Systeme können auf völlig unterschiedlichen Servern, Tech-Stacks und Deployment-Pipelines laufen.

Es gibt eine Nuance, die 9 von 10 Anleitungen übergehen: Decoupled und Headless bedeuten nicht exakt dasselbe. Decoupled WordPress kann für bestimmte Seiten (wie den Admin-Bereich oder Legacy-Routen) noch auf PHP-Rendering zurückfallen. Vollständig Headless bedeutet, dass das WordPress-Frontend komplett deaktiviert ist -- reine API, kein Theme-Rendering. In diesem Leitfaden geht es um den vollständig Headless-Ansatz.

Wann Headless sinnvoll ist (und wann man besser traditionell bleibt)

Headless lohnt sich, wenn das Team Frontend-Entwickler hat, die mit modernen Tools arbeiten wollen, wenn Inhalte über mehrere Kanäle (Web, Mobile App, Digital Signage) ausgespielt werden sollen, oder wenn Performance keine Kompromisse erlaubt. Für alle passt es nicht, und das ehrlich einzugestehen spart wochenlangen Aufwand.

Headless, wenn...

• Das Team bereits React/Vue/Svelte beherrscht. Frontend-Entwickler, die den ganzen Tag JSX schreiben, in PHP-Themes zu zwingen fühlt sich an, als würde man einen Koch nur mit der Mikrowelle kochen lassen.
• Multi-Channel-Delivery erforderlich ist. Ein WordPress-Backend kann Marketing-Website, Mobile App und Store-Kiosk über dieselbe API bedienen.
• Performance ein hartes Kriterium ist. Statische Seiten vom CDN-Edge schlagen PHP-Rendering auf einem Shared Server immer.
• Headless WooCommerce geplant ist. Komplexe E-Commerce-Frontends profitieren enorm von maßgeschneiderten React/Next.js-Storefronts.
• Modernes Developer Experience gewünscht wird. Hot Module Replacement, TypeScript, Komponentenbibliotheken, CI/CD -- die vollständige Frontend-Toolchain.

Traditionell bleiben, wenn...

• Content-Editoren Live-Preview und Page-Builder brauchen. Gutenberg, Elementor und WPBakery setzen ein traditionelles Theme voraus. Headless bricht die meisten visuellen Editing-Workflows.
• Solo-Entwickler oder kleines Team. Headless erhöht die Setup-Komplexität um 40--60 %. Bei einem einzelnen Blog ist ein traditionelles Theme einfacher.
• Viele Frontend-Plugins im Einsatz sind. Kontaktformulare, SEO-Plugins (Yoast rendert Meta-Tags serverseitig), Cookie-Consent-Banner -- all diese setzen PHP-Rendering voraus.
• Budget knapp ist. Separates Hosting für WordPress und Frontend bedeutet zwei Rechnungen statt einer.

REST API vs. WPGraphQL: Die Datenschicht wählen

WordPress bietet im Headless-Setup zwei Wege, Inhalte abzurufen: die eingebaute REST API und das WPGraphQL-Plugin. Die REST API ist in WordPress Core seit Version 4.7 (Dezember 2016) enthalten und funktioniert ohne Konfiguration -- keine Plugins nötig. WPGraphQL erfordert die Installation eines Plugins, erlaubt aber, exakt die benötigten Felder abzufragen, was das Over-Fetching-Problem der REST API löst. Unserer Erfahrung nach gewinnt WPGraphQL bei den meisten Projekten, aber die REST API hat einen unterschätzten Vorteil: natives HTTP-Caching.

WordPress REST API: Die eingebaute Option

Die REST API ist auf jeder WordPress-Installation seit Version 4.7 verfügbar. /wp-json/wp/v2/posts aufrufen und JSON kommt zurück. Einfach, gut dokumentiert, funktioniert ohne Konfiguration.

Der Haken? Over-Fetching. Beim Abruf eines Beitrags gibt WordPress alles zurück: gerenderten Inhalt, Rohinhalt, Auszug, Autor-ID, Featured-Media-ID, Kategorien, Tags, Meta-Felder, GUID, Kommentar-Status, Ping-Status, Template und noch etwa 15 weitere Felder, die man wahrscheinlich nicht braucht. Für eine Blog-Listenseite, auf der nur Titel, Slugs und Auszüge benötigt werden, überträgt man 3- bis 5-mal mehr Daten als nötig.

// REST API: Fetch 5 recent posts with author and categories
const res = await fetch(
  'https://your-site.com/wp-json/wp/v2/posts?per_page=5&_embed'
);
const posts = await res.json();

// The _embed parameter includes author and category objects
// But also includes EVERY field on each post -- ~8KB per post
// For 5 posts, you're looking at ~40KB of JSON

Mit dem _fields-Parameter lässt sich einschränken, welche Felder zurückgegeben werden (?_fields=id,title,slug,excerpt), aber das hilft bei eingebetteten Ressourcen nicht, und für verknüpfte Daten sind trotzdem mehrere Anfragen nötig.

WPGraphQL: Nur das Nötige abfragen

WPGraphQL ist ein kostenloses Open-Source-Plugin von Jason Bahl (jetzt von WP Engine gepflegt), das WordPress eine vollständige GraphQL-API hinzufügt. Man schreibt eine Abfrage mit exakt den gewünschten Feldern und erhält exakt das zurück -- nicht mehr.

# WPGraphQL: Same query -- 5 recent posts with author and categories
query RecentPosts {
  posts(first: 5) {
    nodes {
      title
      slug
      excerpt
      date
      author {
        node {
          name
        }
      }
      categories {
        nodes {
          name
          slug
        }
      }
    }
  }
}

# Response: ~2KB of precisely structured JSON
# No extra fields, no bloat

Code-Vergleich nebeneinander

So sehen die Response-Payloads tatsächlich aus:

Was sollte man wählen?

REST API verwenden, wenn man etwas schnell bauen will, das Team GraphQL nicht kennt, oder aggressives HTTP-Caching ohne zusätzliches Tooling benötigt wird.

WPGraphQL verwenden, wenn ein Produktions-Frontend mit komplexen Datenanforderungen gebaut wird, kleinere Payloads gewünscht sind, oder das Team bereits anderswo GraphQL einsetzt.

Klares Urteil: Für ein ernsthaftes Headless-WordPress-Projekt mit Next.js ist WPGraphQL die bessere Wahl. Die Payload-Einsparungen, das Developer-Experience mit GraphiQL IDE und das Single-Request-Datenabrufen machen die Plugin-Abhängigkeit wett.

WordPress als Headless CMS einrichten

WordPress als Headless CMS einzurichten dauert sechs Schritte: WordPress installieren, die richtigen Plugins hinzufügen, das Content-Modell konfigurieren, das Frontend-Theme deaktivieren, Authentifizierung einrichten und die API testen. Der gesamte Prozess dauert etwa 30--45 Minuten, wenn man es schon einmal gemacht hat, oder ein paar Stunden beim ersten Mal.

Schritt 1: Mit einer frischen WordPress-Installation auf Managed Hosting beginnen. Kinsta, WP Engine und Cloudways bieten Umgebungen an, die für WordPress optimiert sind. Wer nur experimentieren möchte, ist mit einer lokalen Installation über LocalWP gut bedient.

Schritt 2: Die notwendigen Plugins installieren:

Schritt 3: Das Content-Modell mit ACF erstellen. Feldgruppen definieren, die den Frontend-Komponenten entsprechen. Ein Portfolio-Post-Typ könnte Felder für projectUrl, techStack (Repeater), clientName und projectYear haben.

Wesentliche Plugins

WPGraphQL for ACF verdient besondere Aufmerksamkeit. Ohne dieses Plugin erscheinen ACF-Felder nicht in GraphQL-Abfragen. Nach der Installation lassen sich benutzerdefinierte Felder wie folgt abfragen:

query PortfolioProjects {
  projects(first: 10) {
    nodes {
      title
      slug
      projectFields {
        projectUrl
        clientName
        techStack
        projectYear
      }
    }
  }
}

Das WordPress-Frontend deaktivieren

Schritt 4: Man möchte nicht, dass Besucher die WordPress-URL aufrufen und ein kaputtes Theme sehen. Dazu folgendes in functions.php des Themes oder als mu-Plugin hinzufügen:

// Redirect all frontend requests to the API
add_action('template_redirect', function () {
    if (!is_admin() && !wp_doing_ajax() && !defined('REST_REQUEST') && !defined('GRAPHQL_REQUEST')) {
        wp_redirect('https://your-frontend-domain.com');
        exit;
    }
});

Schritt 5: Application Passwords für die Authentifizierung einrichten. Unter Benutzer > Profil > Application Passwords ein Passwort generieren und für authentifizierte API-Anfragen verwenden (z. B. Inhalte aus externen Tools erstellen oder aktualisieren).

Die API testen

Schritt 6: Im Browser https://your-site.com/graphql aufrufen -- die GraphiQL IDE sollte erscheinen. Dann Beiträge abfragen. Bei REST-Nutzung https://your-site.com/wp-json/wp/v2/posts aufrufen und prüfen, ob JSON zurückkommt.

Pro-Tipp: Die GraphiQL IDE, die mit WPGraphQL ausgeliefert wird, ist ausgesprochen gut für die Schema-Erkundung geeignet. Autocomplete, Dokumentation und Abfrageverlauf sind enthalten -- der schnellste Weg, um herauszufinden, welche Felder verfügbar sind und wie ACF-Daten strukturiert sind.

Ein Next.js-Frontend mit WPGraphQL bauen

Der sauberste Weg, 2026 ein Headless-WordPress-Frontend zu bauen, ist Next.js 15s App Router mit React Server Components. Server Components rufen Daten serverseitig ab, ohne JavaScript an den Client zu schicken, und WPGraphQL liefert präzise Abfragen -- eine natürliche Kombination. Als ich WPGraphQL erstmals mit dem Next.js App Router eingerichtet habe, war Image-Handling der größte Fallstrick -- aber dazu kommen wir noch.

Projekt-Setup und Umgebungsvariablen

Mit einem frischen Next.js-Projekt beginnen. Vercel bietet auch ein offizielles WordPress-Starter-Template als Referenzarchitektur an.

npx create-next-app@latest my-wp-frontend --typescript --app
cd my-wp-frontend

.env.local mit den WordPress-Endpunkten anlegen:

WORDPRESS_API_URL=https://your-wordpress-site.com
NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT=https://your-wordpress-site.com/graphql

Jetzt ein schlankes GraphQL-Fetch-Utility erstellen. Für Server Components braucht man weder Apollo noch urql -- normales fetch funktioniert perfekt, da es keinen clientseitigen State zu verwalten gibt:

// lib/wordpress.ts
const API_URL = process.env.NEXT_PUBLIC_WORDPRESS_GRAPHQL_ENDPOINT!;

export async function fetchGraphQL<T>(
  query: string,
  variables?: Record<string, unknown>
): Promise<T> {
  const res = await fetch(API_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ query, variables }),
    next: { revalidate: 3600 }, // ISR: revalidate every hour
  });

  const json = await res.json();
  if (json.errors) {
    throw new Error(json.errors[0].message);
  }
  return json.data;
}

Für einen Vergleich der React-Framework-Optionen lohnt sich unser Artikel über Next.js vs. React mit Vite -- es gibt nachvollziehbare Gründe, das Framework wegzulassen, aber für Headless-CMS-Arbeit macht SSR und ISR von Next.js es zur praktischen Wahl. Wer zwischen Next.js und Remix abwägt, findet eine Entscheidungshilfe in unserem Beitrag über warum wir Next.js für die meisten Projekte empfehlen.

Beiträge mit Server Components abrufen

Hier ist die Blog-Listenseite als Server Component -- kein useEffect, keine Ladezustände, kein clientseitiges Hydrating:

// app/blog/page.tsx
import { fetchGraphQL } from '@/lib/wordpress';
import Link from 'next/link';

interface PostsData {
  posts: {
    nodes: Array<{
      title: string;
      slug: string;
      excerpt: string;
      date: string;
      author: { node: { name: string } };
    }>;
  };
}

const POSTS_QUERY = `
  query AllPosts {
    posts(first: 20, where: { status: PUBLISH }) {
      nodes {
        title
        slug
        excerpt
        date
        author {
          node {
            name
          }
        }
      }
    }
  }
`;

export default async function BlogPage() {
  const data = await fetchGraphQL<PostsData>(POSTS_QUERY);

  return (
    <main>
      <h1>Blog</h1>
      {data.posts.nodes.map((post) => (
        <article key={post.slug}>
          <Link href={`/blog/${post.slug}`}>
            <h2>{post.title}</h2>
          </Link>
          <p>{post.author.node.name} · {new Date(post.date).toLocaleDateString()}</p>
          <div dangerouslySetInnerHTML={{ __html: post.excerpt }} />
        </article>
      ))}
    </main>
  );
}

Dynamische Beitragsseiten

Einzelne Beitragsseiten nutzen generateStaticParams, um alle Beiträge beim Build-Prozess statisch zu rendern, während ISR neue Inhalte aufgreift:

// app/blog/[slug]/page.tsx
import { fetchGraphQL } from '@/lib/wordpress';
import { notFound } from 'next/navigation';

const POST_QUERY = `
  query PostBySlug($slug: ID!) {
    post(id: $slug, idType: SLUG) {
      title
      content
      date
      author {
        node {
          name
          avatar {
            url
          }
        }
      }
      categories {
        nodes { name slug }
      }
    }
  }
`;

export async function generateStaticParams() {
  const data = await fetchGraphQL<{
    posts: { nodes: Array<{ slug: string }> };
  }>(`query { posts(first: 100) { nodes { slug } } }`);

  return data.posts.nodes.map((post) => ({ slug: post.slug }));
}

export default async function PostPage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const data = await fetchGraphQL<{ post: any }>(POST_QUERY, {
    slug,
  });

  if (!data.post) notFound();

  return (
    <article>
      <h1>{data.post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: data.post.content }} />
    </article>
  );
}

Nicht vergessen: next.config.ts für WordPress-Bilder konfigurieren:

// next.config.ts
const nextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'your-wordpress-site.com',
        pathname: '/wp-content/uploads/**',
      },
    ],
  },
};

export default nextConfig;

Headless WordPress in der Produktion deployen

Ein produktives Headless-WordPress-Setup verwendet Dual-Hosting: WordPress läuft auf Managed WordPress Hosting (WP Engine, Kinsta oder Cloudways), während das Next.js-Frontend auf einer Edge-Plattform wie Vercel oder Netlify deployed wird. Diese Trennung ermöglicht unabhängiges Skalieren beider Schichten -- WordPress kümmert sich um Content-Editing und API-Anfragen, während das Frontend statische und ISR-Seiten von CDN-Edge-Knoten weltweit ausliefert.

Hosting-Architektur

Der Datenfluss sieht so aus: Content-Editoren veröffentlichen im WordPress-Admin, WordPress speichert Inhalte in MySQL, das Next.js-Frontend ruft Inhalte über WPGraphQL ab, Vercel generiert statisches HTML am Edge, und Besucher treffen auf das CDN -- ohne WordPress direkt zu berühren.

Für die Wahl des Frontend-Hostings bietet unser Vercel vs. Netlify Vergleich eine detaillierte Aufschlüsselung. Beide funktionieren gut für Headless WordPress. Wer Container-basierte Alternativen in Betracht zieht, findet im Railway, Render und Fly.io Vergleich die entsprechenden Optionen.

ISR und On-Demand Revalidation

Das ist der Teil, der Headless WordPress in der Produktion wirklich einsatzfähig macht. Unserer Erfahrung nach lohnt sich der Aufwand für On-Demand Revalidation, denn ohne sie muss man zwischen veralteten Inhalten (lange Revalidierungsintervalle) und langsamen Builds (kurze Intervalle, die die WordPress-API belasten) wählen.

ISR ermöglicht das Setzen einer revalidate-Zeit je Seite. Nach diesem Intervall bekommt der nächste Besucher die gecachte Seite, während Next.js sie im Hintergrund neu generiert. Der eigentliche Mehrwert ist die On-Demand Revalidation -- ein Rebuild wird ausgelöst, sobald Inhalte veröffentlicht werden:

// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache';
import { NextRequest, NextResponse } from 'next/server';

export async function POST(request: NextRequest) {
  const secret = request.headers.get('x-revalidation-secret');

  if (secret !== process.env.REVALIDATION_SECRET) {
    return NextResponse.json({ message: 'Invalid secret' }, { status: 401 });
  }

  const body = await request.json();
  const slug = body.post?.post_name;

  if (slug) {
    revalidatePath(`/blog/${slug}`);
    revalidatePath('/blog'); // Also revalidate the listing page
  }

  return NextResponse.json({ revalidated: true });
}

Auf der WordPress-Seite einen Webhook hinzufügen, der bei publish_post ausgelöst wird -- entweder über ein Plugin wie WP Webhooks oder ein einfaches functions.php-Snippet, das den Vercel-/api/revalidate-Endpunkt aufruft. Inhalte gehen damit innerhalb von Sekunden nach dem Klick auf "Veröffentlichen" live -- keine vollständigen Rebuilds, kein Warten. Die Next.js ISR-Dokumentation enthält weitere Konfigurationsoptionen.

Kostenübersicht

WordPress Headless vs. Native Headless CMSes

Wer sowohl mit Headless WordPress als auch mit nativen CMSes wie Sanity, Contentful und Strapi gearbeitet hat, kommt zu folgendem ehrlichen Fazit: Headless WordPress ist die pragmatische Wahl, wenn man eine bestehende WordPress-Site oder ein eingespieltes Content-Team hat. Es ist selten die beste Wahl, wenn man von Grund auf neu startet.

Wo Headless WordPress punktet

• Content-Editoren kennen es bereits. Das WordPress-Admin-UI hat 20 Jahre Weiterentwicklung hinter sich. Ein nicht-technisches Team auf Sanity Studio oder die Contentful-Oberfläche zu schulen dauert Wochen.
• Plugin-Ökosystem. 60.000+ Plugins. Mehrsprachigkeit? WPML. E-Commerce? WooCommerce. SEO-Inhaltsanalyse? Yoast (funktioniert weiterhin im Admin). Kein natives Headless CMS kommt an diese Breite heran.
• Personalsuche. WordPress hat den größten Entwickler-Talentpool aller CMSes. Einen WordPress-Entwickler zu finden ist wesentlich einfacher als einen Sanity- oder Payload-Spezialisten.
• WooCommerce. Wer Headless-E-Commerce mit WordPress-Inhalten benötigt, ist mit WooCommerce + WPGraphQL bestens bedient. Saleor und Medusa sind Alternativen, aber WooCommerce hat den Marktanteil.

Wo native Headless CMSes punkten

• Content-Modellierung. Sanitys GROQ, Contentfuls Content-Typen und Payloads TypeScript-Schema wurden von Grund auf für strukturierte Inhalte entwickelt. WordPress's Post/Page/Custom-Post-Type-Modell wirkt zusammengestückelt.
• Echtzeit-Zusammenarbeit. Sanity bietet Google-Docs-ähnliches Echtzeit-Editing. Contentful hat Live-Kollaboration. WordPress? Es gibt einen "Dieser Beitrag wird gerade von jemand anderem bearbeitet"-Sperrbildschirm.
• API-First-Architektur. WPGraphQL ist brilliant, aber es ist immer noch ein Plugin auf einem PHP-Monolithen. Contentfuls API und Sanitys API wurden von Anfang an API-first konzipiert.
• Medien-Handling. Die WordPress-Medienbibliothek ist funktional, aber grundlegend. Sanitys Image-Pipeline mit automatischen Crops, Hotspots und CDN-Auslieferung ist eine andere Klasse. Contentful und Storyblok integrieren nativ mit Cloudinary.
• Developer Experience. Strapi und Payload bieten eine lokale Entwicklungsumgebung mit Hot-Reload bei Schema-Änderungen. WordPress erfordert einen Browser-Refresh im Admin und Datenbankmigrationen.

Urteil: Was passt besser?

Headless WordPress wählen, wenn: eine bestehende WordPress-Site mit jahrelangen Inhalten vorhanden ist, Editoren kein neues CMS erlernen wollen, WooCommerce benötigt wird, oder ein bestimmtes WordPress-Plugin keine Entsprechung anderswo hat.

Ein natives Headless CMS wählen, wenn: ein neues Projekt von Grund auf gestartet wird, Echtzeit-Zusammenarbeit benötigt wird, das Content-Modell komplex und strukturiert ist, oder das Team Developer Experience über Plugin-Breite stellt.

Bei Techsy haben wir Headless-WordPress-Frontends für Kunden gebaut, die von traditionellem WordPress migrieren. Unser typischer Ansatz: WPGraphQL + Next.js App Router auf Vercel, mit ISR für Performance und On-Demand Revalidation für Content-Aktualität. Kostenlose Beratung anfordern ->

WordPress MCP und die Abilities API: Die KI-Zukunft

WordPress 6.9 führte die Abilities API ein, die in WordPress 7.0 Core einfließt (April 2026). Sie schafft eine standardisierte, typisierte und entdeckbare Schnittstelle für WordPress-Funktionen -- vergleichbar damit, dass WordPress seine Fähigkeiten in einem maschinenlesbaren Format bereitstellt, das KI-Tools verstehen und nutzen können.

Der WordPress MCP Adapter verbindet diese Abilities API mit dem Model Context Protocol (MCP), dem offenen Standard für die Verbindung von KI-Systemen mit externen Tools. Was bedeutet das konkret? KI-Agenten in Claude, Cursor oder VS Code können nun herausfinden, was eine WordPress-Site kann, und diese Aktionen direkt ausführen.

Ein praktisches Beispiel: Claude kann einen WordPress-Beitrag erstellen, ACF-Felder mit strukturierten Daten befüllen, Kategorien zuweisen, ein Featured Image setzen und den Vercel-Revalidierungs-Webhook auslösen -- alles in einer Konversation. Kein Browser, kein Admin-Panel, kein Copy-Paste.

Das ist noch in einem frühen Stadium, und der MCP-Adapter entwickelt sich weiter. Aber es signalisiert etwas Wichtiges: WordPress steht nicht still, während native Headless-CMSes innovieren. Die Kombination aus Abilities API und MCP könnte WordPress zu einem der KI-zugänglichsten CMSes machen -- mit dem Vorteil seines riesigen Plugin-Ökosystems auf eine Weise, die neuere, kleinere Plattformen nicht erreichen können. Die offizielle Ankündigung im WordPress Developer Blog enthält alle technischen Details.

Performance: Headless WordPress vs. traditionelles WordPress

Headless WordPress mit einem statischen Frontend verbessert die Performance gegenüber traditionellem PHP-gerenderten WordPress erheblich. Traditionelles WordPress bedient dynamische Seiten, indem auf jede Anfrage PHP ausgeführt wird -- was zu schlechtem Time to First Byte (TTFB) führt. Performance-Daten aus Mitte 2025 zeigen, dass nur 31 % der Desktop-WordPress-Clients und 24 % auf Mobile gute TTFB-Werte erzielen. Headless mit Next.js und ISR bedeutet, dass Seiten vorgerendert und von CDN-Edge-Knoten ausgeliefert werden, womit TTFB bei gecachten Seiten auf unter 100 ms fällt.

WP Engines Case Study über Android Authority zeigte eine 6-fache Verbesserung bei Lighthouse-Performance-Scores nach der Migration zu Headless WordPress. Core Web Vitals-Daten erzählen eine ähnliche Geschichte: Nur 45 % der WordPress-Sites bestehen alle drei CWV-Metriken auf Mobile, gegenüber 65 % bei Shopify und 83 % bei Duda.

Ein wichtiger Vorbehalt: Headless behebt kein langsames WordPress-Backend. Wenn die WordPress-API 3 Sekunden braucht, weil man auf günstigem Shared Hosting mit 40 Plugins läuft, wird auch die ISR-Regenerierung langsam sein. Das Frontend kann nicht schneller sein als die API, von der es abhängt. In qualitatives Managed Hosting zu investieren ist im Headless-Setup noch wichtiger als im traditionellen. Der Blog von WordPress-Performance-Lead Weston Ruter enthält ausgezeichnete Daten darüber, was bei der WordPress-Server-Performance wirklich den Unterschied macht.

FAQ

Was ist Headless WordPress?

Headless WordPress ist eine Architektur, bei der WordPress ausschließlich als Content-Management-Backend dient und das PHP-Frontend-Theme vollständig deaktiviert ist. Inhalte werden über die REST API oder WPGraphQL an eine separate Frontend-Anwendung geliefert, die mit Frameworks wie Next.js, Nuxt oder Astro gebaut ist. Das WordPress-Admin-Dashboard bleibt für Content-Editoren vollständig funktionsfähig.

Eignet sich WordPress als Headless CMS?

WordPress funktioniert gut als Headless CMS, wenn eine bestehende WordPress-Site vorhanden ist, Content-Editoren die Oberfläche kennen, oder das Plugin-Ökosystem (insbesondere WooCommerce) benötigt wird. Es ist weniger geeignet als native Headless-CMSes wie Sanity oder Contentful, wenn von Grund auf neu gebaut wird, da WordPress' Content-Modellierung und API nachgerüstet statt API-first konzipiert wurden.

Was sind die Nachteile von Headless WordPress?

Die Hauptnachteile sind: erhöhte Komplexität (zwei Hosting-Umgebungen statt einer), Verlust von visuellem Editing und Page-Builder-Funktionalität, Frontend-Plugins funktionieren nicht mehr (Yoast-Meta-Rendering, Kontaktformulare, Cookie-Banner), keine Echtzeit-Kollaboration bei Inhalten, und die GraphQL-API ist eine Plugin-Abhängigkeit statt Core-Funktionalität. Das Budget steigt außerdem, da für WordPress-Hosting und Frontend-Hosting bezahlt wird.

Wie verbinde ich Next.js mit WordPress?

WPGraphQL auf der WordPress-Site installieren, dann ein Next.js-Projekt mit App Router erstellen. Den WordPress-GraphQL-Endpunkt als Umgebungsvariable setzen, eine einfache fetch-basierte GraphQL-Utility-Funktion schreiben und in Server Components nutzen, um Beiträge, Seiten und benutzerdefinierte Inhaltstypen abzufragen. Apollo oder urql werden nicht benötigt -- normales fetch reicht aus, da Server Components serverseitig laufen.

WPGraphQL vs. REST API -- was ist besser?

WPGraphQL ist für Produktions-Frontends besser, weil es nur die angeforderten Felder zurückgibt (Payload-Größe um 60--80 % reduziert), verschachtelte Abfragen in einer einzigen Anfrage unterstützt und eine GraphiQL IDE zur Schema-Erkundung bietet. Die REST API ist besser für schnelle Prototypen, Teams ohne GraphQL-Erfahrung oder Szenarien, in denen natives HTTP-Caching ohne zusätzliches Tooling entscheidend ist.

Was kostet Headless WordPress?

Ein minimales Headless-WordPress-Setup kostet etwa 14 $/Monat -- Cloudways für WordPress-Hosting plus Vercels kostenloser Hobby-Tarif für das Frontend. Ein Produktionssetup mit WP Engine und Vercel Pro kostet 40--70 $/Monat. Premium-Plugins wie ACF Pro und WPML kommen mit 0--50 $/Monat hinzu. Native Headless-CMSes haben oft großzügige Free Tiers, daher ist Kosten allein kein Argument für Headless WordPress.

Kann WooCommerce mit Headless WordPress genutzt werden?

Ja. WPGraphQL hat eine WooCommerce-Erweiterung (WPGraphQL WooCommerce oder "WooGraphQL"), die Produkte, Bestellungen, Warenkorb und Checkout über GraphQL bereitstellt. Das ermöglicht den Bau maßgeschneiderter React-Storefronts mit vollständigen E-Commerce-Funktionen. Der Checkout-Ablauf erfordert mehr Aufwand als bei traditionellen WooCommerce-Themes, aber die Performance- und UX-Gewinne sind bei hochfrequentierten Shops erheblich.

Brauche ich einen Entwickler für Headless WordPress?

Ja, ein Headless-WordPress-Setup erfordert Frontend-Entwicklungskenntnisse -- konkret React (oder Vue/Svelte) und Erfahrung mit APIs. Das Frontend muss von Grund auf oder aus einem Starter-Template heraus aufgebaut werden. Das ist keine No-Code-Lösung. Content-Editoren können den WordPress-Admin weiterhin normal nutzen, aber das initiale Setup und die laufende Frontend-Pflege erfordern Entwickler-Beteiligung.

Welche Plugins sind für Headless WordPress unverzichtbar?

Die unverzichtbaren Plugins sind WPGraphQL (GraphQL-API), Advanced Custom Fields oder ACF (strukturierte Content-Modellierung) und WPGraphQL for ACF (stellt benutzerdefinierte Felder über GraphQL bereit). Dringend empfohlen: Custom Post Type UI zum Registrieren von Post-Typen über den Admin, und ein Webhook-Plugin wie WP Webhooks, um bei Veröffentlichungen Frontend-Rebuilds auszulösen. Frontend-abhängige Plugins wie Yoasts Meta-Tag-Rendering oder Formular-Plugins sollten vermieden werden.

Ist Headless WordPress gut für SEO?

Headless WordPress kann bei korrekter Implementierung mit Next.js oder Nuxt ausgezeichnet für SEO sein, weil Server-Side-Rendering, schnellere Seitenladezeiten (verbesserte Core Web Vitals) und volle Kontrolle über Meta-Tags, strukturierte Daten und URL-Struktur vorhanden sind. Das Risiko: Die automatischen SEO-Plugin-Funktionen wie Yoasts Meta-Tag-Rendering fallen weg -- Meta-Tags, Sitemaps und strukturierte Daten müssen im Frontend-Code manuell umgesetzt werden.