Eine Großküche, die niemals selbst serviert.

Stellen Sie sich das vor: Es wird geschnitten, gewürzt, angerichtet. Aber keinen eigenen Gastraum gibt es, keine festen Tische, keine Speisekarte im Goldrahmen an der Wand. Was hier entsteht, geht hinaus. An ein Restaurant, an einen Foodtruck, an einen Lieferdienst, an ein Catering-Zelt drei Straßen weiter. Die Küche kümmert sich um die Substanz. Wo der Teller landet, entscheiden andere.

Genau so arbeitet ein Headless CMS.

Ein Headless CMS verwaltet Inhalte zentral und liefert sie per API flexibel an verschiedene Ausgabekanäle aus.

Was ist ein Headless CMS?

Ein Headless CMS ist ein Content-Management-System, das Inhalte im Hintergrund strukturiert pflegt und über Schnittstellen (APIs wie REST oder GraphQL) an beliebige Ausgabekanäle ausliefert, ohne selbst eine Darstellung mitzuliefern. Der „Kopf“, also die Präsentationsschicht, fehlt mit Absicht. Übrig bleibt der Körper: ein reines Content-Backend, das seine Inhalte überallhin reicht. Website, App, Smartwatch, Verkaufsdisplay, Sprachassistent.

Ein Topf, viele Teller.

Traditionell, decoupled, headless: der feine Unterschied

Drei Bauweisen, ein Spektrum.

Das klassische, gekoppelte CMS ist das Restaurant mit eigenem Gastraum: Küche und Service unter einem Dach, fest verdrahtet. Bequem, solange Sie nur an diesem einen Ort servieren wollen.

Ein decoupled System trennt Küche und Service bereits, liefert aber oft noch einen vorgefertigten Gastraum mit. Sie können ihn nutzen. Sie müssen nicht.

Headless geht den Schritt zu Ende: nur noch Küche, nur noch Durchreiche. Den Gastraum bauen Sie selbst, wo und wie Sie wollen.

Daraus folgt ein Satz, den viele verwechseln. Headless ist immer entkoppelt, aber nicht jedes entkoppelte System ist headless. Entscheidend ist allein, ob die Präsentationslogik vollständig außerhalb des Systems liegt. Damit hängt die Wahl weniger an „modern gegen altmodisch“ als an Kanalbreite, Flexibilität und Ressourcen.

Wie ein Headless CMS aufgebaut ist

Drei Schichten, mehr braucht es nicht.

Die Vorratskammer ist das Content-Repository. Hier liegen die Inhalte als strukturierte Datensätze, nicht als fertige Seiten: „Artikel“, „Produkt“, „Teammitglied“, jeweils in saubere Felder zerlegt. Die Redaktion arbeitet in Eingabemasken, mit Workflows und Freigaben. Es ist das Mise en place des Contents. Alles vorbereitet, beschriftet, griffbereit.

Die Durchreiche ist der API-Layer. Über REST oder GraphQL verlassen die Inhalte das System. GraphQL hat dabei einen hübschen Vorzug: Das Frontend bestellt genau die Felder, die es braucht, nicht den ganzen Datensatz. Weniger Netzwerklast, agilere Frontends. Strapi zeigt in seiner GraphQL-Dokumentation, wie sich solche Abfragen an das eigene Content-Schema anlehnen.

Der Service ist der Delivery-Layer. Hier wird angerichtet. Web-Frontends mit Next.js oder Nuxt, Mobile-Apps, Digital Signage, Commerce-Oberflächen, Intranets. Ein und derselbe Content, an jedem Ausgabepunkt anders geplattet.

Diese Trennung passt zur Jamstack-Philosophie: vorgerendertes Markup, ausgeliefert über CDN, erweitert durch JavaScript und wiederverwendbare APIs. Den Begriff prägte 2015 Netlify-Mitgründer Matt Biilmann, und er beschreibt im Kern genau diese Entkopplung von Backend-Logik und Auslieferung.

Warum Unternehmen umsteigen

Der Reiz ist schnell erzählt.

Ein Backend, viele Kanäle. Inhalte landen konsistent auf Website, App, Display und Kiosk, ohne dass jemand sie von Hand kopiert. Wer heute mehr als einen Ausspielort bedient, spart sich das ewige Nachpflegen an fünf Stellen.

Dazu kommt Freiheit im Frontend. Die Teams wählen Framework, Render-Strategie und Werkzeuge selbst. Die Ausgabe wird nicht vom CMS diktiert. Das beschleunigt Experimente und befreit aus der Abhängigkeit von einem Templating-System, das vor zehn Jahren einmal modern war.

Statisches Vor-Rendern und CDNs drücken die Ladezeit und machen die Auslieferung widerstandsfähiger. Und weil Frontend und Redaktion getrennt arbeiten, gefährdet ein Designwechsel nie das Redaktionssystem. Zwei Teams, zwei Tempi, kein Stolpern übereinander.

Der letzte Punkt ist der strategische. Headless zahlt auf composable Architekturen ein: Suche, Commerce, Personalisierung und Analytics lassen sich lose ankoppeln und ebenso wieder austauschen. Sie verbauen sich nichts.

Wo es wehtut

So weit das Versprechen. Jetzt die Rechnung.

Headless verlangt Bauarbeit. Frontend, Preview-Strecken, SEO-Funktionen, Komponentenbibliotheken: all das, was ein gekoppeltes System mitbringt, müssen Sie hier selbst stellen. Die englische Wikipedia fasst das zentrale Manko trocken zusammen. Mehr Setup, mehr Konfiguration, mehr technisches Wissen.

Am deutlichsten spürt es die Redaktion. Ohne mitgeliefertes Templating fehlt die Vorschau auf Knopfdruck, fehlt das Bearbeiten direkt in der Seite. Diese Annehmlichkeiten entstehen nicht von allein, sie müssen über Preview-Umgebungen und Draft-Endpoints gebaut werden. Wer den Redaktionsalltag dabei vergisst, hat am Ende ein technisch sauberes System, das niemand gern bedient. Das Smashing Magazine widmet der „Editor Experience“ deshalb zu Recht viel Platz.

Eine Frage, bevor Sie weiterlesen: Wer in Ihrem Haus tippt am Ende die Texte ein, und würde diese Person das neue System lieben oder fürchten?

Dann die Sache mit der Sichtbarkeit. Wer rein im Browser rendert, riskiert, dass Suchmaschinen die Inhalte erst spät oder gar nicht sehen. Dazu gleich mehr.

Schließlich die Governance. Rechte und Rollen, Übersetzungen, Versionierung, Medien-Pipelines, Datenschutz, Datenresidenz. Nichts davon erledigt sich nebenbei. SaaS-Plattformen wie Contentstack nehmen Ihnen viel Betrieb ab, kosten dafür laufend Gebühren und setzen API-Limits.

Headless und Suchmaschinen

Halten wir kurz inne. Hier entscheidet sich, ob Headless ein SEO-Segen wird oder ein Schuss ins eigene Knie.

Alles hängt an der Render-Strategie. Drei Wege stehen offen:

• SSG (Static Site Generation) erzeugt das HTML schon zur Build-Zeit. Schnell, robust, ideal für überwiegend statische Seiten.
• SSR (Server-Side Rendering) liefert pro Anfrage fertiges HTML. Stark bei häufig wechselnden oder personalisierten Inhalten.
• ISR und Hybrid mischen beides: vorgerendert, aber zeitgesteuert neu gebaut.

Was Sie meiden sollten, ist reines Client-Side Rendering als Dauerlösung. Google nennt das sogenannte „Dynamic Rendering“ ausdrücklich einen Behelf, keine langfristige Antwort, und empfiehlt stattdessen Server-Side Rendering, Static Rendering oder Hydration.

Und ein Punkt, der vor wenigen Jahren noch niemanden interessierte: Die neue Generation von KI-Crawlern rendert in der Regel kein JavaScript. Wer Inhalte erst im Browser zusammensetzt, ist für diese Bots schlicht unsichtbar. Vorgerendertes HTML ist damit nicht mehr nur eine Google-Frage. Es ist die Frage, ob Sie überhaupt gefunden werden.

Der Rest ist solides Handwerk. Saubere Meta-Angaben, Titel, Canonical, hreflang und robots-Steuerung. Sitemaps und strukturierte Daten als JSON-LD. Lazy Loading und Bildoptimierung über ein CDN. Die Grundlagen-Leitfäden von Google Search Central bündeln das kompakt.

Die gute Nachricht zum Schluss dieses Abschnitts: Headless ist kein SEO-Nachteil. Hygraph und Ahrefs argumentieren übereinstimmend, dass Performance, klare Informationsarchitektur und ein konsistentes Content-Modell die Rankings sogar heben können. Vorausgesetzt, Rendering und Markup stimmen.

Die Anbieter im Überblick

Der Markt ist breit. Von API-first-SaaS über Open Source bis zu Enterprise-Plattformen, die sich im Headless-Modus betreiben lassen. Eine Auswahl etablierter Namen, ohne Anspruch auf Vollständigkeit.

API-first-SaaS

Contentful mit starkem Fokus auf composable Architekturen. Contentstack mit umfangreicher Dokumentation zu Architektur und Workflows. Sanity mit konfigurierbarem Studio und Echtzeit-Kollaboration. Hygraph (früher GraphCMS), GraphQL-nativ und auf präzise Abfragen ausgelegt. Storyblok mit visuellem Editor und Live-Vorschau. Dazu Prismic, DatoCMS, Kontent.ai, Agility CMS und Umbraco Heartcore, die gemanagte Headless-Variante des Open-Source-CMS Umbraco.

Open Source und Self-Hosted

Strapi, JavaScript- und TypeScript-basiert, developer-first, wahlweise selbst gehostet oder in der Cloud. Directus legt sich auf bestehende SQL-Datenbanken und erzeugt sofort REST- und GraphQL-APIs samt Admin-Oberfläche. Payload, code-first auf TypeScript und React. KeystoneJS, schemagetrieben, mit automatisch bereitgestellter GraphQL-API.

Enterprise-Plattformen mit Headless-Fähigkeiten

Adobe Experience Manager Headless mit Inhaltsfragment-Modellen und GraphQL-API. Magnolia als Hybrid-Headless mit kräftiger Autoren-Oberfläche. Bloomreach Content mit Commerce-Schwerpunkt. Sitecore XM Cloud als cloud-native, headless-orientierte Weiterentwicklung der Sitecore-Plattform.

Bekannte CMS im Headless-Modus

WordPress lässt sich über die REST API oder WPGraphQL headless betreiben und kombiniert so das vertraute Redaktions-Backend mit modernen Frontends. Drupal liefert strukturierte Inhalte standardkonform über das Core-Modul JSON:API.

Lohnt sich Headless für Sie?

Keine Schablone. Drei ehrliche Wenn-dann-Sätze.

Bespielen Sie heute mehrere Kanäle oder planen Sie es?
Dann lohnt sich Headless, weil Sie zentral pflegen und überall ausspielen.

Brauchen Sie maximale Freiheit im Frontend und eine Architektur, die in fünf Jahren noch erweiterbar ist?
Dann sind Sie richtig.

Betreiben Sie dagegen eine rein webzentrische Seite, mit überschaubarem Änderungsbedarf und kleinem Team?
Dann kann ein decoupled CMS oder sogar ein modernes Monolith-Setup das ehrlichere Werkzeug sein. Headless ist kein Statussymbol.

Bei der Auswahl zählt am Ende weniger die Feature-Liste als die Frage, wer täglich damit arbeitet. Prüfen Sie die Redaktions-Oberfläche so streng wie die API. Schauen Sie auf Internationalisierung, auf Rechte und Rollen, auf Datenresidenz in der EU, auf die laufenden Kosten aus Lizenz, Traffic und Build-Minuten. Und testen Sie nicht eine Plattform, sondern zwei oder drei an einem kleinen, echten Stück Ihrer Inhalte.

Die eigentliche Frage ist selten technisch. Sie lautet: Wollen Sie Ihre Inhalte an einen Ort binden, oder wollen Sie sie frei haben für Kanäle, die es heute noch gar nicht gibt?

Ein Headless CMS macht aus Ihren Inhalten Zutaten statt fertiger Gerichte. Das ist anstrengender, ja. Sie decken jeden Tisch selbst. Aber Sie kochen einmal und servieren überall. Und die Küche bleibt offen, auch wenn die Gasträume von morgen ganz anders aussehen.