Ein Headless CMS auswählen

Ein Headless CMS trennt, wo Inhalte gepflegt werden, von wo sie ausgespielt werden. Redakteure verwalten Inhalte in einer komfortablen Oberfläche; das Frontend holt sie per API ab und rendert sie nach Belieben. Diese Entkopplung ist mächtig – aber der Markt ist überfüllt, und eine Fehlentscheidung kostet Sie entweder ein frustriertes Content-Team oder eine brüchige Integration. Die richtige Wahl hängt weniger von Feature-Checklisten ab als davon, wer die Inhalte pflegt und wie diese strukturiert sind.

Die Kategorien, die wirklich zählen

Ignorieren Sie das Marketing. Headless-CMS-Lösungen lassen sich in einige echte Typen einteilen:

• API-first, entwicklerzentriert (Sanity, Contentful, Strapi): flexibles Content-Modellierung, starke APIs, Redakteure arbeiten in einem strukturierten Admin-UI.
• Git-basiert (Inhalte als Dateien im Repository): ideal für entwicklereigene Inhalte wie Dokumentationen, aber umständlich für nicht-technische Redakteure.
• Visuelle / Page-Builder-Hybride (Storyblok, Builder.io): Redakteure erhalten eine visuelle Vorschau – nicht-technische Teams lieben das, es koppelt Inhalt und Layout jedoch stärker aneinander.

Ihre erste Entscheidung lautet: Wer editiert – Entwickler, Marketing oder beide?

Worauf Sie achten sollten

1. Content-Modellierung. Lassen sich Ihre realen Strukturen abbilden – verschachtelte Referenzen, wiederverwendbare Blöcke, Lokalisierung – ohne Workarounds? Das ist der Punkt, an dem Sie täglich leiden, wenn Sie ihn falsch angehen.
2. Editor Experience. Wenn Marketer das Tool scheuen, werden sie es umgehen. Eine gute Vorschau und eine aufgeräumte Oberfläche wiegen schwerer als jede API-Funktion.
3. Developer Experience. Typisierte SDKs, eine vernünftige Query-Sprache, Webhooks für Rebuilds und lokale Entwicklung, die kein Live-Konto voraussetzt.
4. Preismodell. Achten Sie auf Per-Seat-Kosten, API-Call-Limits und Gebühren pro Environment. Manche Tools werden teuer, genau dann, wenn Sie Erfolg haben.
5. Lock-in. Wie aufwändig ist ein vollständiger Datenexport und ein Anbieterwechsel? Self-hosted-Optionen wie Strapi tauschen Komfort gegen Kontrolle.

Wann Sie gar kein CMS brauchen

Diesen Punkt überspringen die meisten Vergleiche. Ein CMS rechtfertigt sich, wenn nicht-technische Personen Inhalte regelmäßig bearbeiten. Wenn Ihre „Inhalte" eigentlich Applikationsdaten sind – Produkte, Listings, nutzergenerierte Datensätze – ist eine PostgreSQL-Datenbank mit einem schlanken Admin-UI oft einfacher, günstiger und flexibler, als ein CMS dafür zurechtzubiegen. Zahlen Sie nicht für eine Content-Management-Schicht, um Daten zu verwalten, die Ihre Applikation ohnehin besitzt.

Greifen Sie zu einem Headless CMS, wenn:

• Marketer oder Redakteure Inhalte ohne Entwicklerbeteiligung aktualisieren
• Inhalte sich wesentlich häufiger ändern als Code
• Sie aus einer Quelle auf mehreren Kanälen publizieren (Web, App, E-Mail)

Greifen Sie zur Datenbank, wenn es sich um strukturierte Applikationsdaten handelt, von denen Ihre Produktlogik abhängt.

Unsere Faustregel

Für content-lastige Marketing-Websites mit einem echten Redaktionsteam setzen wir auf ein strukturiertes, API-first CMS (Sanity oder Strapi, je nach Hosting-Präferenz) in Kombination mit einem statisch generierten oder ISR-Frontend für maximale Performance. Für Produktapplikationen, bei denen der „Content" Kerndaten sind, verzichten wir auf das CMS und bauen ein schlankes Admin-Interface direkt auf Postgres.

Das falsche CMS ist teuer rückzubauen, sobald Redakteure davon abhängen. Wenn Sie für ein Projekt ein CMS auswählen und Ihre Inhalte von Anfang an sauber modellieren möchten, sprechen Sie uns an.