Headless CMS: Hype-Falle für die meisten
Headless wurde DAS Buzzword der Content-Welt. In 70 Prozent der Projekte kostet die Build-Pipeline mehr Zeit, als die Editorial Experience jemals zurückgibt. Hier die nüchterne Trennlinie.
Architektur statt Marketing
Headless löst ein Problem, das viele nicht haben
Decoupled-Architektur ist eine Antwort auf Multi-Channel-Publishing und parallele Frontends. Wer keine zwei Frontends hat, sucht eine Antwort auf eine Frage, die niemand gestellt hat.
Was Headless eigentlich bedeutet
Das Backend liefert Content über eine API (REST oder GraphQL). Das Frontend ist eine separate Anwendung - meist Next.js, Nuxt oder Astro - die diesen Content rendert. Vorteil: ein Backend, viele Frontends. Webseite, native App, Smart-TV-Anwendung, In-Store-Display. Nachteil: ein Build, mehrere Pipelines, mehrere Deployments, mehrere Schmerzpunkte.
Die versteckten Kosten
Was Headless wirklich kostet
JAMstack-Folien zeigen Performance-Scores. Sie zeigen nicht, was die Editorial Experience davon übrig lässt.
Build-Zeiten als Bremsklotz
Ein klassisches Statamic-Setup rendert Änderungen sofort - der Redakteur klickt „Speichern“, lädt die Seite neu, fertig. Bei Static-Site-Generation läuft erst ein Build: zwei, fünf, bei größeren Sites zwanzig Minuten. ISR und On-Demand Revalidation lindern das, aber dafür braucht es Edge-Caching, Webhooks und Logik, die jemand pflegen muss. Im Schnitt verlieren Redaktionen 30 bis 60 Minuten pro Woche allein an „Warum sehe ich meine Änderung noch nicht?“.
Preview wird zum Sonderprojekt
In Statamic ist Live-Preview ein eingebauter Klick. In einem Next.js-plus-Strapi-Setup ist Preview ein eigenes Deployment, ein eigener Build-Mode, ein eigenes Auth-Token und ein Konfigurations-Dokument, das niemand liest. Wir haben Projekte gesehen, in denen die Preview-Infrastruktur 15 Prozent des Initial-Budgets gefressen hat - für eine Funktion, die in klassischen CMS Standard ist.
Page-Builder verliert seinen Sinn
Headless-CMS-Felder sind oft generisch: Heading, RichText, Image. Layout-Entscheidungen wandern ins Frontend. Damit wird aus dem Editor ein Daten-Eingabe-Formular und aus dem Frontend ein Festungswall. Das Versprechen „Content-Editoren bauen Seiten“ stirbt unauffällig im Sprint Review. Statamic mit Bard, Replicator und Page-Builder gibt Redakteuren echte Kontrolle - ohne dass Entwickler nachziehen müssen.
CMS-Entscheidung steht an?
Wir vergleichen Statamic, Headless und klassisches CMS ehrlich für Ihren Use-Case.
Wann Headless trägt
Die seriösen Anwendungsfälle
Nicht jedes Headless-Projekt ist Hype. Es gibt klare Szenarien, in denen Decoupling wirklich der richtige Weg ist.
Echtes Multi-Channel
Webseite, native iOS-App, native Android-App, Smart-TV, In-Store-Display - alle ziehen denselben Content. Hier ist Headless objektiv überlegen. Ein Backend, eine Single Source of Truth, mehrere Konsumenten. Vorausgesetzt, die Kanäle existieren wirklich und werden gepflegt, nicht nur auf einer Roadmap-Folie aufgeführt.
Komplexes UI mit Datenintegration
Ein Frontend, das deutlich mehr macht als Content rendern - z. B. eine SaaS-Oberfläche mit Realtime-Daten, Filtern, komplexen Interaktionen. Hier hilft Headless, weil das Frontend ohnehin eine eigene Anwendung ist. Der CMS-Teil ist nur ein Datenlieferant unter mehreren. Das ist eine ehrliche Architektur - und genau dort liegt unser Sweet Spot bei Vue 3 und Inertia.
Sehr große Redaktions-Teams mit Workflows
Wenn 50 Redakteure parallel arbeiten, mit mehrstufigen Freigaben, Übersetzungen in zwölf Sprachen und granularen Rollen, lohnt sich ein spezialisiertes Headless-CMS wie Contentful oder Sanity. Für die meisten Mittelstands-Sites mit drei Redakteuren ist das mit Kanonen auf Spatzen geschossen - und teurer als die ganze Site zusammen.
Warum Statamic
Der pragmatische Mittelweg
Statamic 6 ist klassisch genug für Redaktions-Komfort und modern genug, um headless zu liefern, wenn Sie es wirklich brauchen.
Klassisch by Default, Headless on Demand
Statamic rendert Seiten direkt aus Antlers oder Blade - sofort, ohne Build-Step. Gleichzeitig liefert es eine GraphQL- und REST-API frei Haus. Wenn Sie nächstes Jahr eine native App bauen, drehen Sie die API auf, ohne das CMS wechseln zu müssen. Das ist die einzige Headless-Strategie, die wir empfehlen: optional, nicht obligatorisch.
Flat-File, Git-versioniert, kein API-Vendor-Lock
Statamic speichert Inhalte als Markdown- und YAML-Dateien im Repo. Das heißt: Content steht unter Versionierung, Pull-Request-Reviews sind möglich, Migrations sind ein git pull. Bei Contentful oder Sanity hängt Ihr Content an einer fremden API, deren Preisstruktur sich ohne Sie ändert. Wir mögen Eigenständigkeit.
Performance ohne Hypegestöhne
Mit Statamic-Static-Caching und Tailwind v4 liefern wir Seiten in unter 100 ms TTFB von einem Hetzner-Knoten in Falkenstein. Das ist schneller als die meisten Next.js-on-Vercel-Deployments im selben Use-Case - und kostet einen Bruchteil. SEO-Crawler kriegen serverseitig gerendertes HTML, ohne dass wir eine zweite Anwendung dafür betreiben.
Artikel teilen
Lassen Sie uns reden.
Bevor Sie ein Headless-Projekt aufsetzen, lohnt ein ehrliches Gespräch über Ihren Use-Case.
Wir zeigen Ihnen, wo Headless wirklich trägt - und wo ein klassisches Statamic Ihre Redaktion glücklicher macht, schneller liefert und weniger kostet. Kein Buzzword-Bingo, sondern eine Rechnung mit echten Zahlen aus Ihrem Kontext.