Headless CMS Vergleich 2026: 9 Anbieter für den Schweizer Markt

Für die Ersteinrichtung ja, für den laufenden Betrieb hängt es vom System ab.

Bei der Einrichtung muss in jedem Fall das Frontend gebaut und an die API angebunden werden. Das ist der Kern des Headless-Ansatzes und gilt für alle Anbieter gleichermassen. Dazu kommt die Definition des Inhaltsmodells: welche Inhaltstypen es gibt und aus welchen Feldern sie bestehen.

Danach trennen sich die Systeme. Lösungen mit visuellem Editor wie Flyo, Storyblok oder Magnolia sind auf redaktionelle Selbstständigkeit ausgelegt: Seiten werden aus vordefinierten Blöcken aufgebaut, die Navigation per Drag-and-drop geändert, das Ergebnis ist in der Live-Vorschau sichtbar. Formularbasierte Systeme wie Strapi oder Directus erfassen Inhalte in Eingabefeldern; für Layoutänderungen ist weiterhin Entwicklungsarbeit nötig.

Für die Systemwahl ist deshalb weniger die Technik entscheidend als die Frage, wer nach dem Go-live tatsächlich publiziert und ob diese Person für eine Layoutänderung Entwicklungsressourcen anfordern muss oder nicht.

TYPO3 ist ein klassisches CMS, lässt sich aber über die Erweiterung «headless» API-fähig machen. Das ist ein nachgerüsteter Betriebsmodus, kein von Grund auf API-first gebautes System.

Der Unterschied ist im Betrieb spürbar. Architektur, Datenmodell und Wartungsaufwand bleiben die eines klassischen CMS: TYPO3 erscheint weiterhin in LTS-Versionen mit befristetem Zeitraum kostenloser Sicherheitsupdates, danach steht ein Update auf die nächste LTS-Version an oder eine kostenpflichtige Verlängerung über ELTS, abgerechnet pro Instanz und Jahr. Auch der Erweiterungsbestand bleibt zu pflegen, unabhängig davon, ob das Frontend die Inhalte über die API oder über Fluid-Templates bezieht.

Für die Entscheidung heisst das: Wer TYPO3 headless betreibt, gewinnt die freie Frontend-Wahl, behält aber den Unterhaltsaufwand eines klassischen Systems. Wer den Aufwand reduzieren will, ändert damit nicht den Betriebsmodus, sondern das System. Auch die Redaktionsoberfläche bleibt dieselbe: «Headless» beschreibt bei TYPO3 den Auslieferungsweg der Inhalte, nicht die Art, wie sie erfasst werden.

Das hängt vom Datenmodell ab, nicht vom Marketingversprechen. Systeme mit offener API-Spezifikation und nicht-proprietären Feldtypen erlauben einen vollständigen Export in strukturierter Form; Systeme mit eigenen Formaten und undokumentierten Endpunkten machen die Migration zum Entwicklungsprojekt.

Vor der Entscheidung gehören drei Fragen konkret gestellt: Gibt es eine OpenAPI-Spezifikation? Sind die Inhaltstypen frei definierbar oder vorgegeben? Existiert ein dokumentierter Bulk-Export?

Bei Flyo lautet die Antwort auf alle drei Ja. Die Content Delivery API ist über eine vollständige OpenAPI-Spezifikation dokumentiert, aus der sich Clients für beliebige Programmiersprachen generieren lassen. Inhaltstypen und Felder werden pro Projekt selbst definiert, es gibt kein vorgegebenes Schema für «Seite» oder «Beitrag».

Zu beachten ist in jedem Fall: Der Aufwand einer Migration liegt selten beim Datenexport, sondern beim Neubau des Frontends und bei der Definition des Inhaltsmodells im Zielsystem.

Nein, das revidierte Datenschutzgesetz (revDSG) verlangt keinen Schweizer Serverstandort. Ein Schweizer Standort ist eine Vereinfachung, keine gesetzliche Pflicht.

Seit Inkrafttreten des revDSG im September 2023 müssen Schweizer Organisationen aber dokumentieren, wo personenbezogene Daten verarbeitet werden. Bei Datenexport ins Ausland braucht es zusätzlich geeignete Garantien, sin der Regel vom EDÖB anerkannte Standardvertragsklauseln und einen Auftragsverarbeitungsvertrag mit dem Anbieter. Dieser Aufwand fällt einmalig an und ist danach im Verzeichnis der Bearbeitungstätigkeiten nachzuführen.

Wer die Daten in der Schweiz hält, vermeidet diesen Schritt vollständig. Praktisch relevant wird der Unterschied vor allem bei Ausschreibungen der öffentlichen Hand und im Gesundheitswesen, wo Schweizer Datenhaltung häufig als Anforderung formuliert wird und nicht als Wunsch.

Bei Flyo liegen Applikation, Datenbank und Mediendateien vollständig auf Schweizer Infrastruktur: Kubernetes-Cluster in Münchenstein bei Basel, Datenbank und Assets in der AWS-Region Zürich. Der Datenexport ins Ausland entfällt damit als Thema, ebenso die zugehörige Dokumentationspflicht.

Ein Headless CMS trennt die Inhaltsverwaltung von der Darstellung und liefert Inhalte per API aus. Ein Content Hub geht einen Schritt weiter: Er bündelt zusätzlich die Ausspielung auf Newsletter, Social Media und Bildschirme in derselben Oberfläche.

Die Beziehung ist eindeutig: Jeder Content Hub ist ein Headless CMS aber nicht jedes Headless CMS ist ein Content Hub.

Praktisch zeigt sich der Unterschied bei der Frage, was ein zusätzlicher Kanal kostet. Bei einem reinen Headless CMS ist ein Newsletter ein zweites Tool mit eigener Datenpflege, ein Info-Screen ein drittes. Bei einem Content Hub ist beides ein weiterer Abnehmer derselben Datensätze.

Bei Flyo sind Website, Newsletter über Mailjet, Social Media, Digital Signage über SignageOS, Canva und PDF-Druckvorlagen fertig eingebaute Ausspielwege. Der Aufwand pro zusätzlichem Kanal besteht aus der einmaligen Einrichtung, nicht aus laufender Redaktionsarbeit. «Content Hub» beschreibt damit den Funktionsumfang, «headless» die zugrunde liegende Architektur.

Zwei Anbieter mit Schweizer Firmensitz sind im Markt relevant: Magnolia und Flyo.

Magnolia wurde 1997 in Basel gegründet und bedient das Enterprise-Segment mit einem Java-basierten hybriden System, das auf grosse Organisationen mit eigenem IT-Team ausgelegt ist.

Flyo wird seit 2021 von der Heartbeat GmbH in Aarau entwickelt und richtet sich an KMU. Applikation, Datenbank und Mediendateien liegen vollständig in der Schweiz: Kubernetes-Cluster in Münchenstein, AWS-Region Zürich. Abgerechnet wird in CHF, Vertragssprache und Support sind Deutsch.

Weitere Systeme werden zwar von Schweizer Agenturen betrieben, stammen aber von ausländischen Anbietern. Für Ausschreibungen mit Anforderung an den Anbietersitz ist das ein Unterschied, der geprüft werden sollte. Gefragt ist dort der Sitz der Anbieterin, nicht der Sitz der umsetzenden Agentur.

Flyo bietet eine vollständige Datenhaltung in der Schweiz: Applikation im Kubernetes-Cluster Münchenstein, Datenbank auf AWS RDS Aurora Zürich und Mediendateien im S3-Speicher der AWS-Region Europe (Zurich). Storyblok bietet EU, USA, Kanada, Australien und China; Contentful EU und USA, die Schweiz ist bei beiden nicht wählbar. Mit Open-Source-Systemen wie Strapi, Directus oder Payload lässt sich Schweizer Hosting frei umsetzen, dann allerdings in Eigenbetrieb.

Am günstigsten ist selten das System ohne Lizenzkosten. Entscheidend ist die Vollkostenrechnung über drei bis fünf Jahre.

Open-Source-Systeme wie Strapi, Directus oder Payload haben keine Lizenzkosten. Die Gesamtkosten entstehen bei Hosting für Anwendung, Datenbank und Dateispeicher, bei Betrieb und Monitoring, bei Sicherheitsupdates und bei Major-Upgrades. Sie liegen in einer ehrlichen Rechnung selten unter denen einer SaaS-Lösung.

Bei den gehosteten Anbietern entscheidet das Abrechnungsmodell, nicht der Listenpreis. Seat-basierte Modelle sind günstig bei kleinen, festen Redaktionsteams und werden teuer, sobald viele Personen gelegentlich publizieren. Verbrauchsbasierte Modelle drehen das um.

Flyo rechnet verbrauchsbasiert über Credits ab und begrenzt weder Benutzer noch Inhaltsmenge. Mehr Informationen zum Preismodell ↗.

Für eine mittlere Unternehmenswebsite mit einigen hundert Seiten sind drei bis sechs Monate realistisch, abhängig vom Umfang des Frontends und davon, wie strukturiert die Inhalte im Altsystem vorliegen. Der Aufwand liegt selten bei der Datenübernahme, sondern beim Neubau des Frontends und bei der Definition des Inhaltsmodells.

Der Geschwindigkeitsgewinn macht sich vor allem im Lifecycle bemerkbar. Soll die Seite erweitert oder nach einigen Jahren neu gebaut werden, sind durch die Entkoppelung von Backend und Frontend die eigentlichen Inhalte nicht vom Umbau betroffen.