Wenn du einem Softwareprodukt einen Blog, einen Changelog oder ein Hilfecenter hinzufügst, ist die erste Weggabelung eine Architekturfrage: Willst du ein CMS, das deine Seiten für dich rendert, oder eines, das dir Inhalte über eine API liefert und sich aus deinem Frontend heraushält?
Das ist der ganze Unterschied zwischen einem klassischen CMS und einem Headless-CMS. Alles andere – Preise, Plugins, Hosting – folgt aus dieser Entscheidung.
Was ein klassisches CMS macht
Ein klassisches (oder „gekoppeltes“) CMS wie WordPress bündelt drei Dinge in einem System: die Oberfläche zum Bearbeiten, die Datenbank mit den Inhalten und die Rendering-Schicht, die aus Inhalten HTML macht. Du wählst ein Theme, Redakteure schreiben Beiträge, und das CMS liefert fertige Seiten von seinem eigenen Server aus.
Dieses Modell ist hervorragend, wenn die Website selbst das Produkt ist: ein Magazin, die Seite eines Restaurants, eine Firmenbroschüre. Du bekommst eine funktionierende Website ohne eine Zeile Frontend-Code und ein ausgereiftes Ökosystem an Plugins, und Redakteure ohne Technikkenntnisse können fast alles ändern.
Die Kosten zeigen sich, wenn das CMS Teil eines größeren Produkts sein muss:
Die Rendering-Schicht gehört dem CMS, nicht dir. Dein Blog sieht aus wie ein Theme, nicht wie deine App. Um dein Designsystem umzusetzen, musst du gegen die Template-Schicht ankämpfen.
Du betreibst einen zweiten Stack. Eine PHP-Anwendung mit eigener Datenbank, eigenen Updates und Sicherheitspatches, die neben deinem eigentlichen Produkt läuft.
Inhalte stecken in einer einzigen Darstellung fest. Derselbe Hilfeartikel kann nicht ohne Weiteres eine Webseite, ein Widget in der App und einen Suchindex speisen, weil er als Seite geschrieben wurde, nicht als Daten.
Was ein Headless-CMS macht
Ein Headless-CMS behält die Oberfläche zum Bearbeiten und die Datenbank mit den Inhalten und streicht die Rendering-Schicht. Inhalte kommen als strukturiertes JSON über eine API heraus, und deine eigene Anwendung rendert sie mit deinen eigenen Komponenten auf deiner eigenen Domain.
Konkret rufst du Inhalte über ein SDK aus deinem Server-Code ab:
const posts = await kookee.blog.list({ limit: 10 });
const article = await kookee.help.getBySlug('getting-started');Dein Framework – Next.js, Astro, Nuxt, SvelteKit oder alles andere, was JSON abrufen kann – macht daraus HTML, genauso wie es den Rest deines Produkts rendert.
Der Tausch ist klar: Du schreibst das Frontend einmal und bekommst dafür volle Kontrolle über Markup, Styling, Routing und Performance. Für ein SaaS-Team, das schon ein Designsystem und ein laufendes Frontend hat, ist das meist ein gutes Geschäft, weil die Frontend-Arbeit nur eine dünne Schicht über Komponenten ist, die du schon hast.
Der Vergleich, auf den es ankommt
Die meisten Vergleiche „Headless vs. klassisch“ zählen abstrakte Vor- und Nachteile auf. Für ein SaaS-Produkt entscheiden vier Fragen.
Wem gehört das Design?
Klassisch: dem Theme, und du passt es innerhalb seiner Grenzen an. Headless: dir, vollständig. Wenn dein Blog und dein Hilfecenter aussehen sollen wie dein Produkt – gleiche Navigation, gleiche Typografie, gleicher Dark Mode –, kommst du nur mit Headless ohne Hacks dorthin.
Wo sollen die Inhalte erscheinen?
Ein klassisches CMS erzeugt Seiten. Ein Headless-CMS erzeugt Daten, und Daten können überallhin: auf deine Marketing-Website, in ein Changelog-Panel in der App, in einen Support-Chat, der aus deinen Hilfeartikeln antwortet, in einen RSS-Feed, in eine mobile App. Steht auf deiner Roadmap irgendein Kanal außer „eine Website“, zahlt es sich sofort aus, Inhalte als strukturierte Daten zu schreiben.
Wer wartet die Infrastruktur?
Ein selbst gehostetes klassisches CMS heißt: Du patchst es für immer. Bei einer gehosteten Headless-Plattform betreibt der Anbieter Editor, Datenbank, API und CDN, und dein einziges Artefakt ist Frontend-Code in deinem bestehenden Repository – deployt, reviewt und zurückgerollt genau wie der Rest deiner App.
Was passiert mit dem SEO?
Das ist der häufigste Einwand gegen Headless („Wenn Inhalte aus einer API kommen, sieht Google sie dann überhaupt?“), und das Problem ist gelöst. Mit serverseitigem Rendering oder statischer Generierung bekommt der Crawler gewöhnliches HTML unter deiner URL. Woher die Inhalte stammen, sehen Suchmaschinen nicht; es zählt die Domain, die das HTML ausliefert, und bei Headless ist das deine. Das ist eindeutig besser, als deinen Blog auf der Subdomain eines Anbieters zu hosten, wo die aufgebaute Autorität der Website eines anderen zugutekommt.
Wo welches gewinnt
Nimm ein klassisches CMS, wenn:
die Website eigenständiger Inhalt ohne Anwendung drumherum ist.
niemand im Team Frontend-Code schreibt und das auch niemand will.
ein Theme, das zu 90 % passt, gut genug ist.
Nimm ein Headless-CMS, wenn:
die Inhalte in oder neben einem Produkt mit eigenem Frontend leben.
dieselben Inhalte mehrere Kanäle speisen: Web, App, Suche, Feeds.
du Inhalte auf deiner Domain, in deinem Design und über deine Deployment-Pipeline ausliefern willst.
Der Mittelweg: Headless mit Notausgang
Die echte Schwäche von Headless ist der erste Tag: Bevor es dein Frontend gibt, hast du eine API und nichts zu zeigen. Manche Plattformen schließen diese Lücke mit einem gehosteten Portal, einer fertigen öffentlichen Website für dein Feedback-Board, deine Roadmap, deinen Changelog und dein Hilfecenter, die funktioniert, bevor du eine Zeile Code geschrieben hast.
Kookee geht diesen Weg: Jedes Projekt bekommt sofort ein optionales Portal unter einer öffentlichen URL, und du ersetzt es Bereich für Bereich durch eigene Seiten, sobald du sie gegen die API gebaut hast. Mit dem Portal bist du am Launch-Tag live; mit dem SDK hast du später alles selbst in der Hand, ohne Inhalte zwischen Systemen umzuziehen.
Was zu einem SaaS-Produkt passt
Für reine Content-Websites bleibt ein klassisches CMS eine gute Standardwahl. Bei SaaS-Produkten hat sich das Muster klar durchgesetzt: Inhalte werden im Dashboard geschrieben, als JSON ausgeliefert und vom eigenen Frontend des Produkts auf seiner eigenen Domain gerendert. Du behältst dein Designsystem, dein SEO kommt deiner Domain zugute, und deine Inhalte bleiben portable Daten statt eingesperrter Seiten.
So entscheidest du praktisch: Bau einen Prototyp des Headless-Wegs für einen Bereich. Rendere deine fünf neuesten Beiträge mit deinen bestehenden Komponenten. Dauert das einen Nachmittag (und mit einem typisierten SDK ist das meist so), hast du deine Antwort.