Headless CMS oder klassisches CMS: Was passt zu Ihrer Website?

Kurz gefasst: Ein klassisches CMS wie WordPress oder TYPO3 verwaltet Inhalte und erzeugt gleichzeitig die Website. Ein Headless CMS wie Storyblok, Contentful, Sanity, Strapi oder Payload verwaltet nur die Inhalte und liefert sie per API an ein separates Frontend, etwa eine Next.js-Anwendung. Headless lohnt sich, wenn Inhalte auf mehreren Kanälen erscheinen, Performance und individuelles Design wichtig sind oder die Website Teil einer größeren Anwendung ist. Für eine überschaubare Unternehmensseite, die das Marketing selbst pflegt, ist ein klassisches CMS oft die einfachere Wahl.

Der Unterschied in einem Satz

Beim klassischen CMS sind Redaktionsoberfläche, Datenbank und Darstellung ein System. Beim Headless CMS fehlt der "Kopf", also die Darstellung: Das CMS ist eine Inhaltsdatenbank mit Redaktionsoberfläche und Schnittstelle, und das Frontend ist eine eigene Anwendung.

Daraus folgen fast alle Vor- und Nachteile.

Wann ein klassisches CMS die bessere Wahl ist

WordPress und TYPO3 sind im deutschen Mittelstand weit verbreitet, und das aus guten Gründen. Redakteure sehen beim Bearbeiten direkt, wie die Seite aussieht. Themes und Plugins decken viele Anforderungen ohne Entwicklung ab. Agenturen und Freelancer, die sich damit auskennen, gibt es reichlich.

Die Kehrseite zeigt sich mit der Zeit. Viele Plugins bedeuten viele Updates und eine größere Angriffsfläche. Performance leidet oft unter schweren Themes und Seitenbaukästen. Und sobald die Website Funktionen braucht, die über Inhalte hinausgehen, etwa ein Kundenportal oder eine Produktkonfiguration, wird es im CMS umständlich.

Ein klassisches CMS passt gut, wenn die Website vor allem Marketing-Inhalte zeigt, das Team ohne Entwickler pflegen will und kein zweiter Kanal geplant ist.

Wann sich ein Headless CMS lohnt

Mehrere Kanäle, ein Inhalt

Wenn dieselben Inhalte auf Website, App, Kundenportal oder Infoterminal erscheinen sollen, ist Headless klar im Vorteil. Inhalte werden einmal gepflegt und über eine API überall ausgeliefert.

Performance und Design-Freiheit

Das Frontend ist eine eigenständige Anwendung, zum Beispiel mit Next.js. Seiten können statisch erzeugt oder serverseitig gerendert und über ein CDN ausgeliefert werden. Das ergibt sehr kurze Ladezeiten und volle Kontrolle über das Design ohne die Grenzen eines Themes. Welche Rendering-Strategie wann passt, erklären wir im Artikel zu Server- und Client-Side-Rendering.

Sicherheit

Die öffentliche Website hat bei Headless-Architekturen keinen direkten Zugriff auf die Redaktionsoberfläche. Bei statisch erzeugten Seiten gibt es auf dem Webserver kaum etwas anzugreifen. Die Angriffsfläche ist dadurch deutlich kleiner als bei einem öffentlich erreichbaren Admin-Login mit Plugins.

Teil einer größeren Anwendung

Ist die Website eng mit einer Web-App, einem Shop oder einem Login-Bereich verzahnt, passt ein Headless CMS besser in die Architektur. Inhalte werden zu einer Datenquelle unter mehreren, ganz im Sinne eines API-First-Ansatzes.

Die Kosten und Fallstricke von Headless

Headless braucht Entwicklung. Jede neue Inhaltsart, jeder Seitentyp und jede Komponente muss im Frontend umgesetzt werden. Ohne Entwickler kann das Marketing keine völlig neuen Layouts bauen, es arbeitet mit den vereinbarten Bausteinen.

Die Vorschau ist ein zweiter Punkt. Redakteure wollen sehen, wie ein Entwurf aussieht, bevor er live geht. Gute Headless-Systeme wie Storyblok oder Sanity bieten dafür visuelle Editoren und Live-Vorschau, sie muss aber im Frontend angebunden werden. Planen Sie das von Anfang an ein.

Bei den Kosten gibt es zwei Modelle. SaaS-Systeme wie Contentful oder Storyblok rechnen nach Nutzern, Inhalten oder API-Aufrufen ab. Open-Source-Systeme wie Strapi oder Payload sind lizenzfrei, müssen aber selbst betrieben werden. Für Hosting in Deutschland und volle Datenkontrolle ist die selbst gehostete Variante oft attraktiv.

Wie wir die Entscheidung angehen

Wir fragen zuerst, wer die Inhalte pflegt und wie oft, welche Kanäle es gibt oder geben wird und welche Funktionen neben den Inhalten nötig sind. Danach ist die Wahl meist klar. Für Projekte, die wir ohnehin mit Next.js umsetzen, ist ein Headless CMS naheliegend; warum wir dieses Framework standardmäßig nutzen, erklären wir im Beitrag Warum wir Next.js gewählt haben.

Häufige Fragen (FAQ)

Ist ein Headless CMS schwerer zu bedienen?

Für Redakteure nicht unbedingt. Moderne Systeme haben aufgeräumte Oberflächen und visuelle Editoren. Der Unterschied liegt eher darin, dass Layouts aus vordefinierten Bausteinen bestehen und nicht frei zusammengeklickt werden.

Kann ich WordPress headless nutzen?

Ja. WordPress bietet eine REST-API, und mit WPGraphQL auch eine GraphQL-Schnittstelle. So bleibt die gewohnte Redaktionsoberfläche erhalten, und das Frontend wird separat gebaut. Viele Plugins, die Inhalte im Frontend ausgeben, funktionieren dann allerdings nicht mehr.

Ist ein Headless CMS besser für SEO?

Nicht automatisch. Es ermöglicht sehr schnelle Seiten und saubere Auszeichnung, aber Metadaten, Sitemaps und strukturierte Daten müssen im Frontend umgesetzt werden. Ein klassisches CMS bringt dafür fertige Plugins mit.

Wie aufwendig ist ein Umstieg von WordPress auf Headless?

Inhalte lassen sich meist per Skript übertragen. Den größeren Aufwand machen das neue Frontend, das Inhaltsmodell und die Weiterleitungen alter URLs. Gut geplant, ist ein Umstieg ohne Verlust an Sichtbarkeit möglich.

Fazit

Die Wahl zwischen Headless und klassischem CMS ist vor allem eine Frage, wer Inhalte pflegt und wohin sie fließen. Wer nur eine Website mit Marketing-Inhalten braucht, ist mit einem klassischen System gut bedient. Wer Inhalte als Teil eines größeren digitalen Produkts sieht, gewinnt mit Headless langfristig Flexibilität.

Wenn Sie vor dieser Entscheidung stehen, sprechen Sie mit uns über Webentwicklung.