Was ist ein Headless CMS und wann passt es?

Ein Headless CMS ist ein Content-Management-System ohne eigenes Frontend: Redakteure pflegen Texte, Bilder und Produktinformationen im CMS, und das System liefert diese Inhalte über eine Schnittstelle (API) an eine Website, eine App oder einen Shop. Wie die Inhalte aussehen, bestimmt eine separat entwickelte Anwendung, zum Beispiel mit Next.js. Der Name kommt vom abgetrennten „Kopf“, also der Darstellungsschicht, die bei klassischen Systemen wie WordPress fest mit dem Redaktionssystem verbunden ist.

Für Unternehmen bedeutet das mehr Freiheit bei Design, Ladezeit und Ausspielkanälen und mehr Aufwand in der Entwicklung. Unten finden Sie, wie ein Headless CMS arbeitet, für welche Vorhaben es passt, was für SEO wichtig ist und welche Systeme es gibt.

Was ist ein Headless CMS?

Klassische Content-Management-Systeme wie WordPress, TYPO3 oder Joomla bestehen aus zwei Teilen, die gemeinsam installiert und betrieben werden: dem Backend, in dem die Redaktion Inhalte pflegt, und dem Frontend, das aus Templates und Themes die fertige HTML-Seite erzeugt. Wer das Design ändern will, arbeitet innerhalb der Template-Sprache des Systems.

Ein Headless CMS verzichtet auf den zweiten Teil. Es speichert Inhalte als strukturierte Daten, etwa einen Inhaltstyp „Referenzprojekt“ mit den Feldern Titel, Branche, Kurztext und Bild, und stellt sie über eine REST- oder GraphQL-API bereit. Welche Anwendung die Daten abruft und wie sie sie darstellt, legt das CMS nicht fest. Dieselbe Produktbeschreibung kann so auf der Website, in einer App und auf einem Messe-Display erscheinen und wird trotzdem nur an einer Stelle gepflegt.

So funktioniert ein Headless CMS

Die Architektur besteht aus vier Gliedern, die nacheinander arbeiten:

1. Content-Modell: Bevor die erste Zeile Text entsteht, legen Entwickler und Redaktion fest, welche Inhaltstypen es gibt (Seite, Blogbeitrag, Teammitglied, Stellenanzeige) und welche Felder jeder Typ hat. Das Modell übernimmt die Rolle der Seitenvorlage eines klassischen CMS.

2. Redaktion: Redakteure füllen die Felder in der Web-Oberfläche des CMS, legen Übersetzungen an und veröffentlichen. Systeme wie Storyblok zeigen dabei eine Live-Vorschau der späteren Seite.

3. API: Das CMS gibt veröffentlichte Inhalte als JSON über eine Content-Delivery-API aus, meist über ein CDN. Beim Veröffentlichen schickt es eine Nachricht (Webhook) an das Frontend.

4. Frontend: Eine eigene Anwendung, etwa mit Next.js, Nuxt oder Astro, fragt die API ab und erzeugt daraus HTML. Das passiert beim Build (Static Site Generation), bei jedem Aufruf am Server (Server-Side Rendering) oder zeitgesteuert im Hintergrund (Incremental Static Regeneration). Der Webhook aus Schritt 3 stößt den Neuaufbau einer geänderten Seite an, sodass sie kurz darauf live ist.

Besucher merken von dieser Kette nichts, sie rufen eine gewöhnliche Website auf. Das CMS selbst erreichen sie nicht: Es läuft beim SaaS-Anbieter oder auf einer eigenen Subdomain hinter einem Login.

Vorteile eines Headless CMS

• Freie Wahl der Frontend-Technik. Ihr Entwicklerteam baut die Oberfläche mit den Werkzeugen, die es beherrscht, und gestaltet jede Seite frei.

• Kurze Ladezeiten. Vorab erzeugte Seiten kommen als fertiges HTML aus dem CDN, beim Seitenaufruf läuft keine Datenbankabfrage. Gute Core Web Vitals sind so leichter zu erreichen; garantiert sind sie nicht, schwere Bilder und Skripte bremsen auch ein Headless-Frontend.

• Ein Inhalt, mehrere Kanäle. Website, App, Shop oder ein Display im Showroom lesen dieselben Datensätze. Öffnungszeiten, Produkttexte oder Stellenanzeigen pflegen Sie einmal.

• Weniger Angriffsfläche. Auf der Website-Domain läuft nur das Frontend, das fertige Seiten ausliefert. Das Redaktionssystem mit Login liegt getrennt davon.

• Relaunch mit bestehenden Inhalten. Ein neues Design liest dieselbe API wie das alte. Die Inhalte bleiben im CMS, nur das Frontend wird ersetzt.

• Strukturierte Inhalte. Felder statt formatierter Textblöcke lassen sich filtern, übersetzen und als strukturierte Daten nach Schema.org ausgeben.

Nachteile eines Headless CMS

Die Trennung bringt Entwicklungsarbeit mit sich. Alles, was bei WordPress ein Theme oder ein Plugin erledigt, entsteht im Frontend.

• Mehr Aufwand beim Start. Jede Seitenvorlage, jede Komponente und jedes Formular wird programmiert.

• Die Vorschau muss eingerichtet werden. Damit Redakteure sehen, wie ein Entwurf aussieht, braucht das Frontend einen Vorschau-Modus. Fehlt er, pflegen sie Formularfelder, ohne die Seite zu sehen.

• Funktionen entstehen im Frontend. Kontaktformular, Cookie-Banner, Suche und Weiterleitungen baut oder integriert das Entwicklerteam selbst.

• Zwei Systeme im Betrieb. Sie zahlen die Lizenz des CMS-Anbieters oder betreiben ein Open-Source-CMS selbst, dazu das Hosting des Frontends. Beide brauchen Updates und Überwachung, am einfachsten im Rahmen einer laufenden Betreuung.

• Neue Layouts brauchen Entwickler. Redakteure kombinieren vorhandene Bausteine frei. Einen neuen Baustein, etwa eine Vergleichstabelle, programmiert jemand.

Für eine Unternehmenswebsite mit zehn Seiten, einer Sprache und einer Person, die zweimal im Jahr etwas ändert, ist ein Headless CMS meist überdimensioniert. Ein klassisches CMS oder ein gepflegter Website-Baukasten ist dort schneller aufgesetzt und reicht aus.

Headless CMS vs. klassisches CMS vs. hybrides CMS

Zwischen den beiden Polen gibt es eine dritte Variante. Ein hybrides Headless CMS, auch Decoupled CMS genannt, rendert weiterhin eigene Seiten und bietet zusätzlich eine API. WordPress hat seit Version 4.7 eine REST-API im Kern, Drupal liefert JSON:API mit, für TYPO3 gibt es die Erweiterung „headless“. Eine bestehende Website bleibt so erhalten, und ein neuer Kanal wie eine App liest dieselben Inhalte über die API.

Welches System zu Ihren Anforderungen passt, zeigen wir mit Kriterien und Einsatzfällen im CMS-Vergleich.

Headless CMS und SEO

Suchmaschinen crawlen das Frontend, das CMS selbst sehen sie nicht. Im Frontend kommt es deshalb auf diese Punkte an:

• Rendering. Eine Single-Page-App, die Inhalte erst im Browser per JavaScript lädt, liefert Crawlern zunächst eine fast leere Seite. Google rendert JavaScript nach, teils mit Verzögerung, und nicht jeder andere Crawler führt JavaScript aus. Mit Next.js erzeugen Sie das HTML vorab (Static Site Generation) oder am Server (Server-Side Rendering), sodass jeder Crawler den vollständigen Text bekommt.

• SEO-Felder im Content-Modell. Meta-Title, Meta-Description, Canonical-URL, Social-Media-Bild und ein Noindex-Schalter gehören als Felder in jeden Seitentyp. Manche Systeme bringen dafür Erweiterungen mit, etwa das SEO-Plugin von Payload; ausgeben muss die Werte in jedem Fall das Frontend.

• Technische Grundlagen im Code. XML-Sitemap, robots.txt, hreflang für mehrere Sprachen und strukturierte Daten (JSON-LD) erzeugt das Frontend aus den CMS-Daten. Next.js hat dafür eigene Dateikonventionen für Sitemap und robots.txt sowie eine Metadata-API.

• Weiterleitungen. Beim Umzug von einem klassischen CMS ändern sich oft URLs. Legen Sie vor dem Launch eine Liste aller alten und neuen Adressen an und pflegen Sie Weiterleitungen im Code oder als eigenen Inhaltstyp im CMS, damit die Redaktion neue selbst anlegen kann.

• Aktualität. Bei vorab erzeugten Seiten muss eine Änderung im CMS einen Neuaufbau auslösen, per Webhook oder zeitgesteuert. Fehlt das, zeigt die Website und damit auch Google bis zum nächsten Build die alte Version.

Beispiele: bekannte Headless-CMS-Systeme

Die folgenden fünf Systeme sind im deutschsprachigen Raum verbreitet und decken die üblichen Betriebsmodelle ab, von SaaS bis selbst gehostet.

Storyblok

SaaS-CMS aus Linz in Österreich. Sein Merkmal ist der Visual Editor: Redakteure bearbeiten Inhalte in einer Live-Vorschau der Seite und setzen Seiten aus Komponenten zusammen, die das Entwicklerteam vorher definiert hat. Das kommt Teams entgegen, die von WordPress oder TYPO3 die Seitenansicht gewohnt sind. Storyblok bietet unter anderem eine Datenregion in der EU.

Wie wir Storyblok-Projekte aufsetzen, beschreiben wir auf der Seite Storyblok Agentur.

Contentful

SaaS-CMS, in Berlin gegründet und verbreitet bei größeren Unternehmen mit vielen Marken, Sprachen und Redaktionsrollen. Die Stärken liegen bei Content-Modellierung, Berechtigungen und Freigabe-Workflows. Die Tarife unterscheiden sich unter anderem bei Nutzern, Sprachen und API-Aufrufen, und der kostenlose Tarif ist laut Anbieter zum Testen gedacht.

Strapi

Open-Source-CMS auf Node.js-Basis, das Sie auf eigenen Servern betreiben können, zum Beispiel in einem deutschen Rechenzentrum. Die Community-Version steht unter MIT-Lizenz, Betrieb, Backups und Updates übernehmen Sie selbst oder Ihr Dienstleister. Als gehostete Variante gibt es Strapi Cloud.

Sanity

SaaS-Backend mit einer Redaktionsoberfläche namens Sanity Studio, die als Open-Source-Anwendung auf React-Basis ausgeliefert und per Code angepasst wird. Abgefragt werden Inhalte mit der eigenen Abfragesprache GROQ oder per GraphQL. Sanity passt zu Teams, die die Redaktionsoberfläche stark an ihre Abläufe anpassen wollen.

Payload

Open-Source-CMS in TypeScript, das sich seit Version 3 direkt in eine Next.js-Anwendung installieren lässt. CMS und Frontend liegen dann in einem Projekt und auf einem Server, als Datenbank dient zum Beispiel PostgreSQL, MongoDB oder SQLite. Für Teams mit eigener Next.js-Erfahrung ist das eine schlanke Variante, die komplett auf eigener Infrastruktur läuft.

Tarife und Funktionsumfang dieser Systeme ändern sich regelmäßig. Aktuelle Preise finden Sie direkt bei den Anbietern, etwa auf der Preisseite von Storyblok.

Headless CMS im Online-Shop

Shops nutzen dieselbe Architektur zweimal: Ein Shopsystem wie Shopware oder Shopify liefert Produkte, Preise und Warenkorb über seine API, ein Headless CMS liefert Ratgebertexte, Landingpages und Markenseiten, und ein gemeinsames Frontend führt beides zusammen. Wie das mit Next.js und Shopware aussieht, beschreibt unser Beitrag zu Headless Commerce.

Wann passt ein Headless CMS zu Ihrem Unternehmen?

Ein Headless CMS passt gut, wenn mindestens zwei dieser Punkte zutreffen:

• Sie spielen Inhalte auf mehr als einem Kanal aus, etwa Website und App oder Website und Shop.

• Sie betreiben mehrere Sprachen oder mehrere Marken-Websites aus einem Datenbestand.

• Ladezeit und Core Web Vitals sollen deutlich besser werden, als es das aktuelle Theme zulässt.

• Ein Relaunch steht ohnehin an, und ein Entwicklerteam betreut die Website auch nach dem Launch.

Trifft höchstens einer davon zu, passt meist ein klassisches CMS. Ihre Ausgangslage sehen wir uns gern gemeinsam mit Ihnen im Erstgespräch an. Als Headless-CMS-Agentur planen wir Content-Modell, Frontend und Migration mit Ihnen. Websites mit klassischem CMS bauen wir als Website-Agentur.