Headless WordPress mit Astro: Wann der Aufwand lohnt

Headless WordPress trennt das, was viele für untrennbar halten: das Redaktionssystem und die ausgespielte Website. WordPress bleibt als Backend für die Inhaltspflege, Astro übernimmt das Frontend und liefert statische HTML-Seiten aus. Das Ergebnis sind kürzere Ladezeiten und mehr Flexibilität - aber nur, wenn der Anwendungsfall stimmt. Dieser Artikel zeigt, wann sich der Mehraufwand rechnet und wann nicht.

Was Headless WordPress eigentlich bedeutet

Klassisches WordPress macht beides: Es verwaltet Ihre Inhalte und rendert bei jedem Seitenaufruf das HTML über PHP und die MySQL-Datenbank. Bei Headless WordPress wird genau diese zweite Aufgabe abgekoppelt.

WordPress dient dann nur noch als Content-Backend. Redakteure pflegen Beiträge, Seiten und Custom Fields wie gewohnt im vertrauten Editor. Die Inhalte werden aber nicht mehr direkt ausgespielt, sondern über eine Schnittstelle abgerufen - per REST API oder GraphQL. Ein separates Frontend, in unserem Fall Astro, holt diese Daten ab und baut daraus fertige HTML-Seiten.

Astro eignet sich dafür besonders gut, weil es zur Build-Zeit statisches HTML erzeugt. Der Besucher bekommt keine PHP-Ausführung und keine Datenbankabfrage zu sehen, sondern eine fertige, vorgerenderte Datei. Warum Static Site Generatoren für SEO so stark sind, vertiefen wir im Artikel Astro für schnelle, suchmaschinenfreundliche Websites.

Der Reiz dieser Trennung: Sie behalten den Komfort von WordPress für die Redaktion und gewinnen die Performance und Sicherheit eines statischen Frontends.

Use-Cases, die sich wirklich lohnen

Headless ist kein Selbstzweck. Es zahlt sich in konkreten Situationen aus:

• Hohe Last. Eine Seite, die regelmäßig Traffic-Spitzen abbekommt - etwa nach einem TV-Auftritt oder einer Kampagne -, knickt mit klassischem PHP-WordPress schnell ein. Statisches HTML lässt sich über ein CDN praktisch unbegrenzt ausliefern.
• Performance als Wettbewerbsfaktor. Wenn die Core Web Vitals direkt aufs Geschäft einzahlen, etwa im E-Commerce, bringt die statische Auslieferung messbare Vorteile bei Ladezeiten unter 1 Sekunde.
• Multi-Channel-Ausspielung. Sie wollen dieselben Inhalte auf Website, App und einem Kiosk-Display nutzen? Über eine zentrale API füttern Sie beliebig viele Frontends aus einer einzigen Redaktionsquelle.
• Erhöhte Sicherheit. Das WordPress-Backend liegt abgeschottet im Hintergrund und ist von außen nicht erreichbar. Die Angriffsfläche der öffentlichen Seite sinkt drastisch, weil dort kein ausführbarer Code läuft.

Allen Fällen gemeinsam ist: Es geht um Skalierung, Geschwindigkeit oder Reichweite über mehrere Kanäle. Für eine reine Visitenkarten-Website mit fünf Unterseiten trifft nichts davon zu.

GraphQL- oder REST-Endpoint einrichten

Der technische Einstiegspunkt ist die Schnittstelle, über die Astro die WordPress-Inhalte abruft. Hier gibt es zwei Wege.

Die WordPress REST API ist bereits eingebaut und ohne Plugin nutzbar. Unter /wp-json/wp/v2/posts liefert WordPress Ihre Beiträge als JSON. Das ist unkompliziert, hat aber einen Haken: Sie bekommen oft mehr Daten zurück, als Sie brauchen, und für verschachtelte Inhalte sind mehrere Anfragen nötig. Wie Sie die REST API SEO-sauber nutzen, behandeln wir ausführlich im Beitrag WordPress REST API für SEO richtig nutzen.

GraphQL über das Plugin WPGraphQL löst dieses Problem. Sie fragen in einer einzigen Abfrage exakt die Felder ab, die Sie benötigen - Titel, Slug, Beitragsbild, ausgewählte Custom Fields. Das spart Bandbreite und vereinfacht den Code im Frontend.

In Astro sieht ein einfacher Datenabruf zur Build-Zeit so aus:

// src/lib/wp.js
export async function getPosts() {
  const res = await fetch('https://cms.ihre-domain.de/graphql', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      query: `{ posts { nodes { title slug excerpt } } }`
    })
  });
  const { data } = await res.json();
  return data.posts.nodes;
}

Diese Funktion rufen Sie in einer dynamischen Route wie src/pages/blog/[slug].astro über getStaticPaths() auf. Astro generiert daraus zur Build-Zeit für jeden Beitrag eine statische Seite.

Build-Trigger-Strategie

Hier liegt die größte konzeptionelle Hürde. Bei statischem HTML existiert eine Seite erst, nachdem der Build gelaufen ist. Veröffentlicht ein Redakteur einen Beitrag, ist er nicht sofort live - er erscheint erst nach dem nächsten Build.

Drei bewährte Strategien lösen das:

• Webhook bei Änderung. WordPress schickt bei jedem Speichern einen Webhook an Ihren Hosting-Dienst (Netlify, Vercel, Cloudflare Pages), der automatisch einen neuen Build startet. Plugins wie WP Webhooks erledigen das ohne Programmierung.
• Zeitgesteuerte Builds. Ein Cron-Job baut die Seite etwa stündlich neu. Geeignet für Inhalte, bei denen ein paar Minuten Verzögerung unkritisch sind.
• Manueller Build-Button. Im WordPress-Dashboard sitzt ein Button, den die Redaktion nach einer Änderung selbst auslöst.

Meine Empfehlung aus der Praxis: Der Webhook-Ansatz ist für die meisten Projekte der richtige Mittelweg. Er hält die Seite aktuell, ohne unnötige Builds zu produzieren. Bei sehr großen Seiten mit tausenden Beiträgen lohnt sich ein Blick auf inkrementelle Builds, die nur geänderte Seiten neu erzeugen - das spart wertvolle Build-Minuten.

SEO-Implikationen: Vorteile und Fallstricke

Aus SEO-Sicht spielt Headless WordPress mit Astro seine größte Stärke bei der Performance aus. Statisches HTML lädt im Schnitt 40 bis 60 % schneller als dynamisch gerendertes PHP, und schnelle Core Web Vitals sind ein direkter Rankingfaktor. Die Grundlagen dieser Architektur und ihrer SEO-Effekte beschreiben wir im Detail unter Headless CMS und SEO.

Die wichtigsten Vorteile:

• Saubere Ladezeiten ohne Server-Rendering bei jedem Aufruf.
• Volle Kontrolle über das HTML, weil Astro genau das ausgibt, was Sie definieren - kein aufgeblähter Theme-Code.
• Reduzierte Angriffsfläche und damit weniger Risiko von Hacks, die das Ranking schädigen.

Die Fallstricke werden oft unterschätzt:

• Plugins funktionieren nicht mehr. SEO-Plugins wie Yoast oder Rank Math rendern ihre Meta-Tags im klassischen Frontend. Im Headless-Setup müssen Sie Title, Description, Canonical und Schema-Markup selbst im Astro-Frontend abbilden. Die Daten lassen sich zwar per API auslesen, aber die Ausgabe ist Handarbeit.
• Sitemap und Redirects. Auch XML-Sitemap und 301-Weiterleitungen müssen im Frontend neu gelöst werden, nicht im Plugin.
• Vorschau-Funktion. Die WordPress-Vorschau zeigt nicht das echte Astro-Frontend. Eine Live-Vorschau erfordert zusätzlichen Aufwand.

Wer diese Punkte ignoriert, riskiert SEO-Schäden, die jeden Performance-Gewinn auffressen. Headless ist technisch elegant, verlagert aber Verantwortung von Plugins auf den Entwickler.

Der ehrliche Effort-Vergleich: Wann es NICHT lohnt

Jetzt die unbequeme Wahrheit: Für die meisten kleinen und mittleren Websites lohnt sich Headless WordPress nicht. Der Mehraufwand steht in keinem Verhältnis zum Nutzen.

Ein klassisches WordPress mit gutem Caching-Plugin und schnellem Hosting liefert für eine lokale Praxis, einen Handwerksbetrieb oder eine Agentur-Website völlig ausreichende Ladezeiten. Sie bekommen SEO-Plugins, Vorschau und Drag-and-Drop-Editoren ohne jeden Zusatzaufwand.

Headless verursacht dagegen laufende Kosten an mehreren Stellen:

Gegen Headless spricht es, wenn Ihr Team nicht-technisch ist, die Seite überschaubar groß ist oder Sie keine Build-Pipeline betreiben wollen. Sie verwalten dann faktisch zwei Systeme statt einem, und jede Änderung an der Architektur kostet Entwicklerzeit.

Dafür spricht Headless, wenn Sie nachweislich an Performance-Grenzen stoßen, Inhalte über mehrere Kanäle ausspielen oder maximale Kontrolle über das Frontend brauchen. Dann ist der Aufwand gerechtfertigt - und zahlt sich in Geschwindigkeit und Skalierbarkeit aus.

Unsere Empfehlung: Starten Sie nicht mit Headless, weil es modern klingt. Starten Sie damit, wenn ein konkretes Problem es verlangt. Die beste Architektur ist die, die zu Ihrem tatsächlichen Bedarf passt - nicht die technisch anspruchsvollste.