Headless CMS erklärt: Wann sich die Trennung von Inhalt und Frontend lohnt

Was „headless" bedeutet

Ein klassisches CMS ist „gekoppelt": Es verwaltet Inhalte und erzeugt zugleich die Seiten, die Besucher sehen, mit Themes oder Templates. Ein Headless CMS trennt das. Die Astro-Dokumentation beschreibt es so, dass das CMS beim Schreiben der Inhalte hilft, aber keine Website zur Anzeige erzeugt. Für die Darstellung bist du selbst zuständig: Dein Frontend, etwa ein Astro-Projekt, ruft die Inhalte ab und rendert daraus die Seiten.

Der „Kopf" ist also das Frontend, das fehlt. Was bleibt, ist ein Redaktionssystem mit einer Schnittstelle, meist REST oder GraphQL. Wenn dir der Begriff API noch nicht vertraut ist, hilft der Artikel zur API-Schnittstelle als Grundlage.

Die Trennung bringt zwei Dinge mit sich. Du bist frei in der Wahl der Technik für das Frontend, und derselbe Inhalt kann in mehreren Kanälen erscheinen, etwa auf der Website und in einer App. Und du übernimmst Aufgaben, die ein gekoppeltes System mitliefert: Vorschau, Navigation, Weiterleitungen und das Zusammenspiel von Redaktion und Deployment.

Gekoppelt oder getrennt: der Vergleich

Die Tabelle beschreibt Tendenzen der Bauart, nicht einzelner Produkte. Ob ein bestimmtes System Vorschau oder Kanäle gut löst, steht in dessen Dokumentation.

Drei Bauarten im Überblick

API-first-Systeme

Diese Systeme sind von Anfang an als Inhaltsverwaltung mit Schnittstelle gedacht. Du legst Inhaltstypen mit Feldern an, Redakteure pflegen Einträge, dein Frontend ruft sie ab. Ein Beispiel aus der Dokumentation: Strapi erzeugt automatisch API-Endpunkte, sobald du einen Inhaltstyp anlegst. Für Collection Types listet GET /api/:pluralApiId die Dokumente, einzelne Dokumente erreichst du über GET /api/:pluralApiId/:documentId. Antworten haben laut Strapi-5-Dokumentation die Form data, meta und optional error, mit direkt an data hängenden Attributen statt einer verschachtelten attributes-Ebene.

Strapi ist hier nur ein Beispiel. Die Astro-Dokumentation listet dutzende CMS-Anleitungen, darunter Contentful, Sanity, Storyblok, Strapi und WordPress; viele davon sind laut Seite noch Stubs. Eine Produktbewertung leitet sich daraus nicht ab.

Git-basierte Systeme

Hier liegen Inhalte als Dateien im Repository, neben dem Code. Decap CMS (früher Netlify CMS) ist laut Dokumentation ein quelloffenes CMS für Git-Workflows: Es ist eine React-App, die Git-Operationen über die APIs von GitHub, GitLab oder Bitbucket kapselt. Redakteure bekommen eine Weboberfläche mit Rich-Text-Editor, Vorschau und Drag-and-drop-Upload und müssen kein Git lernen. Die Anmeldung läuft über GitHub, GitLab oder Bitbucket.

Der Vorteil: Inhalte sind versioniert und liegen beim Code, es gibt keine zusätzliche Datenbank. Der Nachteil liegt in der Natur des Ansatzes. Jede Änderung ist ein Commit und löst in der Regel einen Build aus, und Beziehungen zwischen Inhalten sind einfacher in Datenbanken zu modellieren als in Dateien.

Headless WordPress

WordPress kann als reines Redaktionssystem dienen. Die REST-API liefert Inhalte als JSON, und laut Handbuch kannst du damit Inhalte in „komplett separate Anwendungen" holen. Jede Sprache, die HTTP-Anfragen senden und JSON lesen kann, eignet sich als Client. Öffentliche Inhalte sind allgemein abrufbar, während private, passwortgeschützte oder interne Inhalte sowie benutzerdefinierte Beitragstypen und Metadaten Authentifizierung oder gezielte Freigabe verlangen.

Die Beiträge liegen unter GET /wp/v2/posts, erreichbar etwa unter https://example.com/wp-json/wp/v2/posts. Dokumentierte Parameter sind unter anderem per_page (Standard 10), page (Standard 1), slug, search, orderby, order und status (Standard publish):

https://example.com/wp-json/wp/v2/posts?per_page=20&page=1&orderby=date&order=desc

Der Reiz: Du behältst das vertraute Redaktionssystem, das Team muss nichts Neues lernen. Der Preis: Du betreibst WordPress weiter (mit Updates) und zusätzlich ein Frontend.

Inhalte per API abrufen

Der Abruf selbst ist unspektakulär: eine HTTP-Anfrage und JSON zurück. Das folgende Node.js-Skript holt veröffentlichte Beiträge von einem illustrativen Endpunkt. Die URL https://cms.example.com ist ein Platzhalter nach RFC 2606; Pfad und Antwortformat stehen für ein generisches API-first-System:

const BASE = process.env.CMS_URL ?? 'https://cms.example.com';

async function holeBeitraege() {
  const url = new URL('/api/beitraege', BASE);
  url.searchParams.set('status', 'published');

  const antwort = await fetch(url, { headers: { Accept: 'application/json' } });
  if (!antwort.ok) {
    throw new Error(`CMS antwortet mit HTTP ${antwort.status}`);
  }
  const { data } = await antwort.json();
  return data;
}

const beitraege = await holeBeitraege();
for (const b of beitraege) {
  console.log(`${b.slug}: ${b.title}`);
}

Gegen einen lokalen Testserver, der zwei Beiträge zurückgibt, erscheint diese Ausgabe:

hallo: Hallo Welt
zwei: Zweiter

In einem Astro-Projekt steht derselbe Abruf im Frontmatter einer Seite und läuft beim Build. Das Ergebnis ist statisches HTML, ohne dass der Besucher je mit dem CMS spricht:

---
interface Beitrag {
  slug: string;
  title: string;
  excerpt: string;
}

const antwort = await fetch('https://cms.example.com/api/beitraege?status=published');
if (!antwort.ok) {
  throw new Error(`CMS antwortet mit ${antwort.status}`);
}
const { data }: { data: Beitrag[] } = await antwort.json();
---
<ul>
  {data.map((b) => (
    <li><a href={`/blog/${b.slug}/`}>{b.title}</a>: {b.excerpt}</li>
  ))}
</ul>

Wichtig: Zugangsdaten für schreibende oder private API-Zugriffe gehören nie in Code, der im Browser läuft. Beim statischen Abruf zur Build-Zeit liegen sie als Umgebungsvariablen auf dem Build-Server; mehr dazu im Artikel zur API-Schnittstelle.

Wie Astro Inhalte aus Dateien und aus Fremdquellen als Collections behandelt, beschreibt der Artikel zu Astro und statischen Websites. Dort ist auch erklärt, warum ein Schema auf der Seite des Frontends sinnvoll bleibt, selbst wenn das CMS eigene Felder prüft.

Redaktionsworkflow und Vorschau

Der häufigste Grund, warum Headless-Projekte hakelig werden, ist nicht die Technik, sondern der Alltag der Redaktion. Drei Fragen solltest du vor der Entscheidung klären:

1. Wie sehen Redakteure ihre Änderungen vor der Veröffentlichung? Ein gekoppeltes CMS hat eine Vorschau eingebaut. Bei Headless musst du sie bauen: Das Frontend muss Entwürfe abrufen können und sie nicht zusammen mit veröffentlichten Seiten ausliefern. Strapi unterscheidet laut Dokumentation bei aktiviertem Draft & Publish über den Parameter status zwischen draft und published (Standard: published). Ob und wie ein bestimmtes System Vorschauen für dein Frontend unterstützt, musst du in dessen Dokumentation nachlesen.
2. Wie kommt eine Änderung auf die Seite? Bei statischem Rendering durch einen neuen Build, bei Rendering pro Anfrage sofort. Astro rendert standardmäßig vorab und bietet mit Adapter On-Demand-Rendering für einzelne Seiten an. Für ein Redaktionsteam bedeutet ein Build eine Wartezeit zwischen Klick und Live-Gang; ob die tragbar ist, hängt von der Seite ab.
3. Wer pflegt Rollen und Freigaben? Ein Freigabeprozess ist bei einem gekoppelten System oft Teil des Pakets. Bei Headless prüfst du, was das gewählte CMS bietet, und ergänzt den Rest im Prozess.

Kosten und Komplexität

Die Zahl der Systeme wächst von einem auf mindestens zwei: CMS und Frontend, dazu meist ein Hosting für das Frontend und ein Mechanismus, der Builds anstößt. Jede Verbindung kann ausfallen oder sich ändern: ein API-Update, ein abgelaufener Token, ein geändertes Feld.

Beim Geld gilt dasselbe wie bei jeder Software. Preise, Limits und Lizenzbedingungen unterscheiden sich je Anbieter und verändern sich; prüfe sie auf der Preisseite des Anbieters, bevor du rechnest, und achte auf das Preismodell (nach Nutzern, nach Anfragen, nach Speicher, selbst gehostet gegen Eigenbetrieb). Bei selbst gehosteten Systemen hängt es von der jeweiligen Lizenz ab, ob Gebühren anfallen; Betrieb, Updates und Absicherung liegen in jedem Fall bei dir.

Entscheidungskriterien

Wenn du bei den meisten Zeilen links landest, lohnt die Trennung. Sonst ist ein gekoppeltes System oder eine Git-basierte Lösung mit Markdown meist die einfachere Wahl.

SEO bei Headless

Suchmaschinen sehen nur die ausgelieferte Seite, nicht das CMS dahinter. Für das Ranking ist daher entscheidend, was im Frontend passiert, und weniger, welches System die Inhalte liefert. Fünf Punkte brauchen bei Headless besondere Aufmerksamkeit:

• Rendering: Die Inhalte sollten im ausgelieferten HTML stehen. Wenn dein Frontend sie erst im Browser per JavaScript nachlädt, hängt die Indexierung vom Rendering ab; wie Google damit umgeht, erklärt der Artikel zu JavaScript-SEO. Vorab gerenderte Seiten umgehen das Thema.
• Metadaten: Titel, Beschreibung und Canonical sind Felder, die das CMS liefern und das Frontend ausgeben muss. Fehlt das Feld im Redaktionsmodell, fehlt es auf der Seite. Wie Canonicals funktionieren, steht im Artikel zum Canonical Tag.
• Weiterleitungen und URLs: Ein gekoppeltes CMS verwaltet Weiterleitungen oft mit. Bei Headless ist das eine Aufgabe des Frontends oder des Hostings; sie muss geplant sein, besonders bei einer Migration.
• Vorschau-URLs: Vorschauen mit Entwürfen dürfen nicht indexiert werden, sonst entsteht doppelter oder unfertiger Inhalt.
• Statuscodes: Gelöschte Inhalte im CMS müssen auf der Seite sauber als 404 oder 410 enden, nicht als leere Seite mit Status 200.

Das technische Fundament dazu fasst der Leitfaden zu technischem SEO zusammen.

Dein nächster Schritt

Schreibe vor der Auswahl eines Produkts zwei Listen auf: Welche Inhaltstypen hast du (Artikel, Autorenprofil, Produkt) und wer pflegt sie mit welchen Rechten? Prüfe dann, ob Markdown-Dateien im Repository ausreichen. Wenn Redakteure ohne Entwickler publizieren sollen, nimm dir zwei bis drei Kandidaten aus den Bauarten oben vor, lege einen Inhaltstyp an und rufe ihn mit dem Skript aus diesem Artikel ab. Dabei siehst du sehr schnell, ob Vorschau und Build-Ablauf zu deinem Team passen.