Headless CMS erklärt: Inhalte per API

Was ist ein Headless CMS?

Ein klassisches Content-Management-System wie WordPress kombiniert zwei Aufgaben in einem Programm: Es verwaltet Inhalte (Texte, Bilder, Seitenstruktur) und erzeugt daraus mit Themes und Plugins das HTML für Besucher. In der Bildsprache sind Körper und Kopf eine Einheit. Ein Headless CMS trennt beides: Es bleibt der „Körper“ mit Inhaltsmodellen, Rollen, Medienverwaltung und Redaktionsoberfläche, der „Kopf“ in Form der sichtbaren Webseite entfällt.

Stattdessen liefert das System Inhalte über eine Schnittstelle aus, typischerweise REST oder GraphQL. Ein eigenständiges Frontend ruft diese Daten ab und setzt sie in Seiten um. Das kann eine Webanwendung mit Next.js sein, eine mobile App oder ein Infoterminal. Der Vorteil: Dieselben Inhalte lassen sich in mehreren Kanälen verwenden, und das Frontend ist technisch frei wählbar.

Wie funktioniert die Trennung in der Praxis?

Ein typischer Ablauf mit Next.js sieht so aus:

1. Redakteurinnen und Redakteure pflegen Inhalte im Backend, etwa Leistungsseiten, Artikel oder Referenzen.
2. Beim Build oder bei einer Anfrage ruft das Frontend die Inhalte per API ab.
3. Next.js erzeugt daraus statisches HTML oder rendert serverseitig (SSR).
4. Änderungen werden per Neuaufbau, ISR oder Webhook aktiviert.
5. Das Ergebnis wird über ein CDN ausgeliefert.

Ein Headless CMS muss kein eigener Dienst sein. Auch Markdown- oder MDX-Dateien in einem Repository, eine Datenbank mit Redaktionsmaske oder WordPress über die REST API erfüllen das Prinzip. Wichtig ist die Trennung von Inhaltsdaten und Darstellung.

Wann lohnt sich Headless, wann nicht?

Sinnvoll ist es, wenn die Darstellung individuell und performant sein soll, wenn Inhalte in mehreren Kanälen laufen oder wenn ein Redaktionsteam strukturierte Inhalte pflegt. Auch bei einer Content-Migration aus einem überladenen System schafft die Trennung Ordnung, weil Inhalt und Layout nicht mehr vermischt sind.

Weniger sinnvoll ist es bei kleinen Webseiten mit wenigen Änderungen im Jahr. Dann entstehen zusätzliche Kosten für Vorschau, Zugänge, Updates und Hosting zweier Systeme, ohne dass sich der Nutzen zeigt. Auch bei Shops, die viel Logik im Backend haben, etwa in einer WooCommerce-Migration, muss man sauber abwägen, welcher Teil headless wird.

Was bedeutet Headless für GEO und Performance?

Ein Headless-Aufbau erlaubt schlankes, semantisches HTML ohne Pagebuilder-Ballast. Das hilft Core Web Vitals und der Extrahierbarkeit für KI-Systeme. Gleichzeitig entstehen neue Risiken: Wird das Frontend nur clientseitig gerendert, sieht ein Crawler eine leere Hülle. Deshalb gilt die Regel: Der Inhalt muss im ausgelieferten HTML stehen. Ein Headless CMS ist kein GEO-Gewinn an sich, sondern eine Voraussetzung für saubere Auslieferung, die du konsequent nutzen musst.

Wie handhaben wir das bei Modern Stack?

Wir halten die Architektur bewusst schlank. Fachinhalte liegen strukturiert in Content-Dateien und einer Wissensdatenbank, Kundenanfragen laufen in einer eigenen Datenbank. Das Frontend wird mit Next.js statisch oder serverseitig erzeugt. Für Kunden, die einen gewohnten Editor behalten wollen, prüfen wir, ob ein bestehendes WordPress als Datenquelle taugt oder ob eine Umstellung auf ein einfacheres Redaktionsmodell kostengünstiger ist. Details zur Architektur findest du unter SSR/SSG-Stack.

Typische Fehler

• Headless wählen, weil es modern klingt, ohne Bedarf für mehrere Kanäle.
• Clientseitiges Rendering ohne vorgerendertes HTML.
• Keine Vorschau für Redakteure, sodass Änderungen riskant wirken.
• Inhaltsmodelle zu starr oder zu locker, sodass Seiten wieder Layout-Chaos enthalten.

Verwandte Themen

• Content-Migration
• Next.js
• SSR
• WooCommerce-Migration
• Webseite modernisieren