WordPress als Headless CMS: Wann ergibt es Sinn?

WordPress als „Headless CMS” nutzen bedeutet: WordPress übernimmt das Backend (Inhaltsverwaltung, Medien, Benutzerrollen) — aber das Frontend wird von einer separaten Technologie gerendert. Astro, Next.js oder Nuxt holen die Daten via REST API oder GraphQL und liefern statisches oder server-gerendertes HTML aus.

Wann ist dieser Aufwand gerechtfertigt? Und wann ist er überengineering?

Was „Headless WordPress” bedeutet

Traditionelles WordPress

Browser ← [HTTP] ← PHP + WordPress + Theme → MySQL

WordPress rendert HTML serverseitig mit PHP. Theme-Templates bestimmen das Erscheinungsbild. Vorteil: einfaches Setup, Redakteure sehen WYSIWYG-Vorschau.

Headless WordPress

Browser ← [HTTP] ← Frontend (Astro/Next.js)
                        ↕ [REST API / GraphQL]
                     WordPress CMS
                         ↕
                       MySQL

WordPress wird zum reinen Daten-Backend. Das Frontend fragt via API ab und rendert unabhängig. Vorteil: Frontend kann modernes Framework nutzen, unabhängig von PHP-Templating.

REST API vs. WPGraphQL

WordPress hat eine eingebaute REST API (/wp-json/wp/v2/). Alternativ: WPGraphQL, ein kostenloses Plugin das eine vollständige GraphQL-API bereitstellt.

REST API: Einfacher Einstieg

// Beiträge abrufen via REST API
const response = await fetch('https://cms.mein-projekt.de/wp-json/wp/v2/posts?per_page=10&_embed');
const posts = await response.json();

Vorteile der REST API:

• Kein zusätzliches Plugin nötig
• Breit dokumentiert, viele Beispiele
• Einfache Authentifizierung via Application Passwords

Nachteile:

• Over-fetching: jeder API-Call liefert mehr Daten als gebraucht
• N+1-Problem: mehrere Requests für verknüpfte Daten (Posts + Kategorien + Bilder)
• Keine typsichere Schema-Definition

WPGraphQL: Präzise Datenabfragen

query GetPosts {
  posts(first: 10) {
    nodes {
      id
      title
      excerpt
      date
      slug
      featuredImage {
        node {
          sourceUrl(size: LARGE)
          altText
        }
      }
      categories {
        nodes {
          name
          slug
        }
      }
    }
  }
}

Vorteile von WPGraphQL:

• Exakt die benötigten Felder abrufen — kein Over-fetching
• Verknüpfte Daten in einem Request
• Starke Typisierung durch das GraphQL-Schema
• WPGraphQL Smart Cache (Granulares Cache-Invalidation)

Empfehlung: Für komplexe Projekte mit vielen Beziehungen: WPGraphQL. Für einfache Blog-Projekte: REST API reicht aus.

Headless WordPress mit Astro

Astro eignet sich besonders gut für statische Headless-WordPress-Sites. Astro baut zur Build-Zeit alle Seiten aus den WordPress-Daten.

Setup-Beispiel für Blog-Posts

---
// src/pages/blog/[...slug].astro
import { fetchPosts } from '../../lib/wordpress';

export async function getStaticPaths() {
  const posts = await fetchPosts();
  return posts.map(post => ({
    params: { slug: post.slug },
    props: { post }
  }));
}

const { post } = Astro.props;
---

<article>
  <h1>{post.title}</h1>
  <Fragment set:html={post.content} />
</article>

// src/lib/wordpress.ts
const WP_BASE = import.meta.env.WP_API_URL; // https://cms.mein-projekt.de/wp-json/wp/v2

export async function fetchPosts() {
  const res = await fetch(`${WP_BASE}/posts?per_page=100&_embed`);
  if (!res.ok) throw new Error(`WordPress API error: ${res.status}`);
  return res.json();
}

Inkrementelle Builds via Webhooks

Bei statischen Sites muss ein Rebuild ausgelöst werden, wenn Inhalte in WordPress geändert werden. Netlify und Vercel bieten Build Hooks:

// WordPress mu-plugin: Build-Hook auslösen bei Post-Veröffentlichung
add_action('publish_post', function($post_id) {
  wp_remote_post('https://api.netlify.com/build_hooks/WEBHOOK_ID', [
    'method' => 'POST',
    'body' => ''
  ]);
});

Vorteil: Kein manuelles Deployment nötig. Nachteil: Bei vielen Änderungen viele Rebuilds.

Wann Headless WordPress sich lohnt

Ja: Diese Kriterien sprechen dafür

1. Redakteure kennen WordPress und sollen nach Frontend-Migration nicht umschulen
2. Performance-Anforderungen sind hoch (Ziel LCP < 1,5s, PageSpeed 95+)
3. Multi-Channel-Ausgabe: Dieselben Inhalte für Web, App und E-Mail
4. Komplexes Plugin-Ökosystem mit ACF, WooCommerce oder Events-Plugins ist bereits aufgebaut
5. Sicherheits-Isolation: WordPress nicht öffentlich erreichbar, nur API

Nein: Diese Kriterien sprechen dagegen

1. Einfache Brochure-Website (unter 20 Seiten, selten aktualisiert) → Astro mit MDX Content Collections effizienter
2. Kein Entwickler-Budget für zwei separate Stacks → Traditionelles WordPress einfacher zu warten
3. Echtzeit-Preview für Redakteure kritisch → Headless macht Preview-Workflows komplexer
4. WooCommerce-Heavy-E-Commerce → Headless WooCommerce ist 2026 noch nicht reif genug für komplexe Shop-Anforderungen
5. Schnelle Launchzeit Priorität → Ein Stack weniger Komplexität

Kosten-Nutzen-Realität

Headless WordPress erhöht die initiale Entwicklungszeit um ca. 30–50% gegenüber traditionellem WordPress oder reinem Astro. Das ist gerechtfertigt wenn:

• Das Projekt langfristig läuft (Amortisation über Zeit)
• Performance messbar zum Geschäftserfolg beiträgt (E-Commerce, Conversion-Rate)
• Frontend-Technologie sich weiterentwickeln muss (z.B. von Next.js 14 auf 16)

Für typische KMU-Websites in Sachsen: Die meisten Projekte profitieren nicht vom Headless-Overhead. Entweder traditionelles WordPress oder reines Astro sind effizienter.

Preview und Redaktions-Workflow

Der größte Headless-Nachteil für Redakteure: kein Live-Preview im WordPress-Editor. Lösungen:

WordPress Preview-API + Astro Dev-Mode:

// Astro On-Demand Rendering für Preview
export const prerender = false; // Diese Seite server-side rendern

// Preview-Modus via WordPress-Preview-Parameter
const isPreview = Astro.url.searchParams.get('preview') === 'true';

Headless Preview Plugins:

• WP Headless Preview von WP Engine
• Next.js Preview Mode (nur für Next.js Frontends)

Diese Komplexität muss in der Projekt-Planung eingeplant werden.

Sicherheitsarchitektur bei Headless

Ein oft übersehener Vorteil von Headless: WordPress kann aus dem öffentlichen Internet entfernt werden.

Internet → Astro/Next.js (öffentlich)
                ↓ interne API-Anfragen
         WordPress (privat, nur intern erreichbar)

Das WordPress-Admin-Interface ist so nicht von außen angreifbar. Particularly relevant wenn WordPress auf einem eigenen Server läuft.

Fazit und Empfehlung

Headless WordPress ist ein legitimer Architekturansatz — kein Allheilmittel. Empfehlung:

• Neue Projekte ohne WordPress-Abhängigkeit: Astro mit Content Collections
• Bestehende WordPress-Sites mit Redaktionsworkflows: Traditionelles WordPress optimieren (WP Rocket, GeneratePress, CDN)
• Projekte mit starkem Performance-Bedarf UND WordPress-Redakteuren: Headless WordPress ernsthaft evaluieren

Wir beraten Unternehmen in Sachsen neutral zu diesen Architekturentscheidungen. Details zu beiden Stacks: Astro vs. WordPress 2026. Unsere Leistungen für WordPress-Webdesign und moderne Astro-Projekte geben einen vollständigen Überblick.