Ein Inhalt, alle Kanäle: Warum ein Headless CMS Web und App gleichzeitig speisen sollte

Website, iOS-App, Android-App: drei Kanäle, ein Inhalt, und trotzdem wird er dreimal gepflegt. Ein Headless CMS löst diese Mehrfacharbeit auf, indem es Inhalte als strukturierte Daten über APIs an alle Frontends liefert. Dieser Artikel erklärt, was hinter dem Ansatz steckt, wie die Architektur konkret aussieht und wann sich der Umstieg rechnet.

Ein Headless CMS verwaltet Inhalte ohne eigene Präsentationsschicht und liefert sie über APIs als strukturierte Daten aus. Dadurch können Website, iOS-App und Android-App denselben Inhaltsbestand nutzen: einmal gepflegt, überall zeitgleich aktuell. Für Unternehmen mit mehr als einem Kanal ist das der wirksamste Weg, Doppelpflege, Inkonsistenzen und träge App-Release-Zyklen zu vermeiden.

Ein fiktives, aber alltägliches Beispiel: Ein Möbelhändler betreibt eine Website auf WordPress und hat vor zwei Jahren eine App entwickeln lassen. Das Marketing plant eine Rabattaktion, Start Freitag um 9 Uhr, auf allen Kanälen gleichzeitig. Auf der Website ist das Banner in zehn Minuten eingepflegt. In der App nicht: Die Aktionstexte stecken teils fest im App-Code, teils in einem eigenen Admin-Panel der damaligen Agentur. Für die hartcodierten Texte braucht es ein App-Update samt Prüfung durch App Store und Play Store; ob das bis Freitag durch ist, kann niemand garantieren.

Am Montag stimmen die Preise in der App noch immer nicht mit der Website überein. Das Problem ist kein schlampiges Projektmanagement. Das Problem ist eine Architektur, in der jeder Kanal seine eigene Inhaltsverwaltung mitbringt.

Was ist ein Headless CMS?

Ein Headless CMS ist ein Content-Management-System, das nur aus dem Backend besteht: Redaktionsoberfläche, Content-Repository, Rollen, Workflows und Versionierung. Auf den „Head“, also die Präsentationsschicht, verzichtet es bewusst. Inhalte liegen als strukturierte, präsentationsneutrale Daten vor und werden über APIs ausgeliefert, in der Regel als JSON über REST oder GraphQL.

Ein klassisches CMS wie WordPress oder TYPO3 erledigt dagegen zwei Aufgaben in einem System: Es verwaltet Inhalte, und es rendert sie über Templates und Themes zu fertigen HTML-Seiten. Speicherung und Präsentation sind fest gekoppelt; das CMS ist zugleich Redaktionssystem und Website.

Beim Headless-Ansatz entscheidet jedes Frontend selbst, was es aus den Daten macht: Eine Next.js-Website rendert HTML, eine iOS-App baut native Views mit SwiftUI, eine Android-App mit Jetpack Compose. Das CMS weiß nicht und muss nicht wissen, wo seine Inhalte erscheinen. Die wichtigsten Unterschiede im Überblick:

	Gekoppeltes CMS (z. B. WordPress)	Headless CMS (z. B. Contentful, Strapi)
Architektur	Backend und Präsentation in einem System	Nur Backend; Frontends werden getrennt entwickelt
Auslieferung	Fertige HTML-Seiten über Templates	Strukturierte Daten (JSON) über REST oder GraphQL
Kanäle	Primär die eigene Website	Beliebig viele: Web, iOS, Android, weitere
App-Anbindung	Nachrüstung über Plugins, WebViews oder Zweitsystem	Gleichberechtigter Abnehmer derselben APIs
Redaktionsvorschau	Eingebaut, direkt an der Seite	Wird pro Kanal eingerichtet (Preview API, Visual Editor)

Dieser Ansatz ist keine Nische mehr, sondern ein Baustein der MACH-Prinzipien (Microservices, API-first, Cloud-native, Headless), die die MACH Alliance als Referenz für zusammensetzbare Unternehmensarchitekturen etabliert hat. Der Markt ist entsprechend breit: Auf der SaaS-Seite stehen Anbieter wie Contentful, Storyblok, Hygraph oder Contentstack, auf der Open-Source-Seite selbst betreibbare Systeme wie Strapi 5, Directus oder Payload. Wie ernst die Branche das Thema nimmt, zeigt Figmas Übernahme des Payload-Teams auf der Config 2025; Payload bleibt nach Angaben von Figma Open Source.

Warum erreichen klassische CMS die App nicht?

Der Kern des Problems: Ein gekoppeltes Web-CMS produziert HTML-Seiten, eine native App braucht aber strukturierte Daten. In der Praxis führt das zu drei typischen Notlösungen, die alle Folgekosten erzeugen.

Erstens: Inhalte werden in der App hartcodiert. Dann ist jede Textänderung eine Code-Änderung, die den kompletten Release-Zyklus durchläuft: Build, Test, Einreichung, Store-Review, gestaffelter Rollout. Der Review-Prozess der Stores ist der falsche Takt für Inhalte, die sich wöchentlich oder täglich ändern. Herstellerdokumentationen für Mobile-Content beschreiben genau dieses Muster: Jede inhaltliche Änderung gilt als App-Änderung und muss neu eingereicht werden.

Zweitens: Die App bekommt ein eigenes kleines Content-Backend. Damit existieren zwei Redaktionssysteme mit zwei Freigabeprozessen, und die Konsistenz zwischen Web und App hängt an Disziplin und Copy-and-paste. Inkonsistente Preise oder abweichende Produkttexte sind dann keine Ausnahme, sondern eingebaute Eigenschaft der Architektur.

Drittens: Die App zeigt Website-Inhalte in WebViews an. Das spart Pflegeaufwand, kostet aber die Vorteile, für die man eine native App überhaupt baut: flüssige Bedienung, Offline-Fähigkeit, native Navigation. Nutzer merken den Unterschied schnell, etwa an Ladezeiten und an Gesten, die sich nicht nativ anfühlen.

Alle drei Wege behandeln die App als Sonderfall. Ein Headless CMS dreht die Logik um: Inhalte sind der gemeinsame Kern, und jeder Kanal, Web wie App, ist ein gleichberechtigter Abnehmer.

Wie sieht die Architektur mit einem Content-Hub aus?

Im Zentrum steht das Headless CMS als Content-Hub, und darin ein Content-Modell, das Inhalte als Typen mit Feldern beschreibt statt als Seiten: ein Produkt mit Name, Beschreibung, Preisfeld und Bildern; ein Artikel mit Titel, Teaser und Inhaltsblöcken; eine Kampagne mit Laufzeit und Bannermotiven. Wichtig ist Präsentationsneutralität: keine HTML-Fragmente in Textfeldern, keine Feldnamen wie „linke Spalte“, denn eine linke Spalte gibt es auf dem Smartphone nicht.

Die Auslieferung übernimmt eine Delivery API, die publizierte Inhalte als JSON weltweit über ein CDN verteilt; bei Contentful heißt sie Content Delivery API. Daneben existieren typischerweise eine Preview API für unveröffentlichte Entwürfe, eine Management API für programmatische Imports, etwa aus PIM oder ERP, sowie eine Images API, die Bilder on-the-fly skaliert und in moderne Formate wie WebP konvertiert: dieselbe Bildquelle, aber passende Varianten für Desktop, Tablet und Smartphone. Mit GraphQL fragt jedes Frontend genau die Felder ab, die es braucht:

query {
  campaign(id: "sommeraktion-2026") {
    title
    teaser
    validUntil
    heroImage {
      url(transform: { width: 800, format: WEBP })
    }
  }
}

Die Website fordert zusätzlich SEO-Felder an, die App nur die kompakten Inhalte für ihre Kartenansicht; beide sprechen mit derselben API und demselben Inhaltsstand. Auf der App-Seite helfen offizielle SDKs für Swift und Kotlin samt Caching und Offline-Persistenz, damit Inhalte auch ohne Netzverbindung verfügbar bleiben. Auf der Web-Seite kombiniert sich das CMS mit Server-side Rendering oder Static Site Generation; Webhooks stoßen bei Publikation automatisch neue Builds oder Cache-Invalidierungen an. Auch Lokalisierung profitiert: Übersetzungen werden einmal im CMS gepflegt und stehen sofort allen Kanälen zur Verfügung.

Das Diagramm zu diesem Artikel zeigt diesen Aufbau: Redaktion und Fachsysteme speisen den Content-Hub, die Delivery API verteilt über das CDN an Website, iOS- und Android-App.

Vorteile eines Headless CMS für Web und Apps

Ein Headless CMS zahlt auf vier Ziele ein, die Entscheider direkt betreffen: Konsistenz, Geschwindigkeit, Teamproduktivität und Zukunftsfähigkeit.

Der erste Gewinn ist Konsistenz durch einmalige Pflege. Ein Inhalt, ein Freigabe-Workflow, ein Publikationszeitpunkt; eine Rabattaktion geht um 9 Uhr auf allen Kanälen gleichzeitig live, ohne dass jemand drei Systeme synchron halten muss.

Der zweite ist Geschwindigkeit. Inhaltliche Änderungen erreichen die App in Minuten statt in Release-Zyklen, denn der Store-Review bleibt nur noch für das relevant, wofür er gedacht ist: neue Funktionen. Content und Code bekommen getrennte Taktung, und das Marketing muss für eine Textkorrektur kein Entwicklungsticket mehr schreiben.

Der dritte ist Teamproduktivität. Web-Team, App-Team und Backend-Team arbeiten parallel gegen dieselbe API und können ihre Technologie frei wählen; das CMS gibt keinen Framework-Zwang vor. Für das Unternehmen heißt das auch: Ein Relaunch der Website erzwingt keinen Umbau der App, und umgekehrt.

Der vierte ist Zukunftsfähigkeit. Kommt ein neuer Kanal dazu, etwa ein Kundenportal, digitale Beschilderung im Laden oder Inhalte für Sprach- und KI-Assistenten, entsteht ein neues Frontend, aber kein neues Content-System. Strukturierte, sauber modellierte Inhalte sind zudem genau das Format, das maschinelle Abnehmer gut verarbeiten können; warum das strategisch wichtiger wird, beschreibt unser Artikel Von SEO und ASO zu GEO. Dass sich konsistente Kanalerlebnisse auch betriebswirtschaftlich auszahlen, legt eine von Agility CMS zitierte McKinsey-Analyse nahe: Durchgängige Omnichannel-Journeys ermöglichen demnach Umsatzsteigerungen von 5 bis 15 Prozent.

Ehrliche Einordnung: Aufwand und Grenzen

Ein Headless CMS ist kein Selbstläufer, und drei Punkte gehören auf den Tisch, bevor entschieden wird.

Erstens die Redaktionserfahrung. Ein gekoppeltes CMS zeigt der Redakteurin beim Bearbeiten die fertige Seite; ein Headless CMS zeigt zunächst Formularfelder. Ohne Gegenmaßnahmen leidet die Akzeptanz im Content-Team. Die Anbieter haben reagiert: Storyblok rendert die Website-Vorschau live neben dem Editor und verbindet beide über eine Preview Bridge, Contentful bietet eine Preview API für Entwürfe. Solche Vorschau-Setups funktionieren gut, sind aber Projektaufwand, den man einplanen muss; für die App-Vorschau gilt das doppelt.

Zweitens die Gesamtkosten. Das Headless CMS liefert keine Website und keine App mit; die Frontends müssen entwickelt werden. Wer nur eine Marketing-Website betreibt und auf absehbare Zeit keine App und keine weiteren Kanäle plant, fährt mit einem gekoppelten CMS oft günstiger. Die Rechnung dreht sich in dem Moment, in dem der zweite Kanal real wird, denn dann konkurriert das Headless-Setup nicht mehr mit „WordPress“, sondern mit „WordPress plus App-Sonderlösung plus dauerhafter Doppelpflege“.

Drittens Betriebsmodell und Datenschutz. SaaS-Angebote nehmen Betrieb und Skalierung ab, ihre Kosten wachsen aber mit Nutzung und Nutzerzahlen, und der Standort der Datenverarbeitung muss zur DSGVO-Strategie passen; Contentful bietet dafür etwa dedizierte EU-Endpunkte an. Selbst betriebene Systeme wie Strapi, das mit Version 5 aktiv weiterentwickelt wird, bieten volle Datenhoheit, verlangen aber eigenes Hosting, Updates und Monitoring. Beides ist legitim; es sollte nur eine bewusste Entscheidung sein, inklusive eines Blicks auf die Exportierbarkeit der Inhalte gegen Lock-in-Risiken.

Checkliste: So planen Sie den Umstieg

Für die Praxis hat sich folgendes Vorgehen bewährt:

1. Kanal-Inventur: Welche Kanäle existieren heute, welche kommen laut Roadmap in den nächsten 24 Monaten? Wo werden Inhalte heute doppelt gepflegt, und was kostet das pro Monat?
2. Content-Modell entwerfen: Inhalte als präsentationsneutrale Typen mit Feldern modellieren, gemeinsam mit Redaktion und Entwicklung. Keine HTML-Blobs, keine layoutbezogenen Feldnamen.
3. API-Strategie festlegen: REST oder GraphQL, Caching-Ebenen, Rate Limits und ein realistisches Mengengerüst für Abrufe aus Web und App.
4. App-Architektur klären: Lokales Caching und Offline-Verhalten, Bildvarianten über eine Images API, definierte Fallbacks bei Netzwerkfehlern. Keine redaktionellen Inhalte mehr im App-Code.
5. Redaktions-Workflow absichern: Vorschau je Kanal, Rollen und Freigaben, Lokalisierung, geplante Publikationszeitpunkte.
6. Betriebsmodell entscheiden: SaaS oder Self-Hosting, Datenresidenz, Backup-Konzept und die Kosten über drei Jahre statt über drei Monate vergleichen.
7. Schrittweise migrieren: Mit einem Content-Typ oder einem Kanal starten, etwa den News-Bereich, und das alte System erst ablösen, wenn der neue Pfad trägt.

Fazit

Sobald ein Unternehmen mehr als einen Kanal bespielt, ist die Inhaltsverwaltung eine Architekturentscheidung und keine Redaktionsfrage mehr. Ein Headless CMS macht Inhalte zu dem, was sie in einer Mehrkanal-Welt sein müssen: ein zentral gepflegtes, strukturiert abrufbares Produkt, das Website, iOS- und Android-App im selben Takt erreicht. Wer nur eine Website betreibt, braucht diesen Umbau nicht. Wer aber Web und App parallel betreibt oder eine App plant, sollte die Content-Frage vor der Frontend-Frage klären; alles andere reproduziert eine Doppelpflege, die jede Woche Zeit und Vertrauen kostet.

Häufige Fragen

Was kostet ein Headless CMS?

Die Kosten setzen sich aus mehreren Posten zusammen: Lizenz oder Abo, Hosting, Einführung und Betrieb. Open-Source-Systeme wie Strapi oder Payload sind lizenzkostenfrei, verlangen aber eigenes Hosting und eigene Wartung; SaaS-Angebote wie Contentful oder Storyblok werden im Abo bezahlt und skalieren mit Nutzerzahl und API-Volumen. Der größte Posten ist meist die Einführung: Content-Modellierung, Migration und die Entwicklung der Frontends. Belastbar wird die Zahl erst mit Kanalzahl und Integrationsbedarf.

Headless CMS oder WordPress: Was ist die richtige Wahl?

Für eine reine Website ohne App und ohne weitere Kanäle ist ein gekoppeltes CMS wie WordPress meist die wirtschaftlichere Wahl. Sobald eine App real oder konkret geplant ist, kippt die Rechnung, weil Doppelpflege und App-Sonderlösungen dauerhaft Kosten erzeugen. Ein Zwischenschritt ist, WordPress über seine REST API headless zu betreiben; ein für Mehrkanal-Betrieb entworfenes Content-Modell ersetzt das aber nicht.

Für wen lohnt sich ein Headless CMS?

Ein Headless CMS lohnt sich für Organisationen, die dieselben Inhalte auf mindestens zwei Kanälen ausspielen, typischerweise Website plus iOS- und Android-App, oder die eine App in den nächsten 12 bis 24 Monaten planen. Je mehr Redaktionsaufwand, Kanäle und Sprachen im Spiel sind, desto größer der Effekt. Wer dauerhaft nur eine Website betreibt, profitiert kaum und trägt trotzdem die höhere Anfangsinvestition.

Funktioniert eine App mit Headless CMS auch offline?

Ja. Die App lädt Inhalte über die Delivery API und speichert sie lokal zwischen; bei Netzverlust zeigt sie den letzten Stand an und aktualisiert bei der nächsten Verbindung. Offizielle SDKs unterstützen das, Contentful bietet etwa Offline-Persistenz für die Swift-Bibliothek an. Wichtig ist, das Offline-Verhalten früh in der App-Architektur zu definieren: Was wird vorgehalten, wie lange, und was passiert bei Konflikten?

Sie betreiben Website und App und pflegen Inhalte noch mehrfach? Johnny Bytes, Agentur für App-, Web- und Backend-Entwicklung aus Köln, bringt beides zusammen: von der Auswahl und Modellierung des passenden Headless CMS über die API-Architektur bis zu den Frontends für Web, iOS und Android, alles aus einer Hand. Sprechen Sie uns an.

Quellen

• Headless CMS explained: A 2026 guide (Hygraph)
• Headless CMS for Mobile (Hygraph Academy)
• API basics: Content Delivery, Preview, Management, Images und GraphQL API (Contentful Docs)
• Offline persistence with the Swift client library (Contentful Docs)
• Omnichannel Content Delivery: How a Headless CMS Helps (Agility CMS)
• MACH at Different Levels (MACH Alliance)
• Visual Editor (Storyblok Documentation)
• Welcoming Payload to the Figma Team (Figma Blog)
• Releases: strapi/strapi (GitHub)
• REST API Handbook (WordPress Developer Resources)