Flyo Headless CMS: visueller Editor und Hosting in der Schweiz

Nein, für den laufenden Betrieb nicht. Der visuelle Editor ist so gestaltet, dass Redaktionen ohne HTML-, CSS- oder PHP-Kenntnisse Seiten anlegen, Inhalte pflegen und die Navigation umbauen können. Wer mit einem Textverarbeitungsprogramm umgehen kann, kommt damit zurecht.

Für die Ersteinrichtung ist technisches Wissen dagegen sinnvoll: Inhaltstypen definieren, Design-Komponenten anlegen und das Frontend anbinden sind Aufgaben, die einmalig anfallen und typischerweise von einer Agentur oder dem eigenen Entwicklungsteam übernommen werden. Danach arbeitet die Redaktion eigenständig.

Eine Einführung für ein Redaktionsteam dauert erfahrungsgemäss rund 90 Minuten.

Ja. Flyo unterstützt beliebig viele Sprachen, und Mehrsprachigkeit ist auf Feldebene gelöst statt auf Seitenebene.

Der Unterschied ist im Alltag erheblich. Bei klassischen Systemen entsteht pro Sprache eine eigene Seite, die separat gepflegt wird. Ändert sich ein Preis oder ein Datum, muss die Korrektur in jeder Sprachversion einzeln nachgezogen werden. In Flyo entscheidest du pro Feld, ob es übersetzt wird: Titel und Beschreibung sind mehrsprachig, Datum, Ort, Preis und Bild existieren nur einmal. Eine Preisänderung wirkt dadurch sofort in allen Sprachen.

Es braucht dafür kein Plugin und kein separates Sprachsystem. Übersetzungen lassen sich zudem automatisiert erzeugen und anschliessend redaktionell überarbeiten, sodass eine zweite Sprache keine Verdopplung des Redaktionsaufwands bedeutet.

Ja. Das Flyo CMS ist Teil des integrierten Content Hubs: Website-Inhalte stehen damit automatisch auch für andere Kanäle zur Verfügung, ohne doppelte Datenpflege.

Konkret lassen sich dieselben Inhalte ausspielen auf Digital-Signage-Screens, in Newsletter-Kampagnen, auf Social Media, als PDF-Druckvorlage für Programme und Menükarten sowie über Schnittstellen an externe Portale. Für die Eventbranche bestehen fertige Anbindungen an Guidle und Eventfrog; für Gestaltung und Shop gibt es Integrationen zu Canva, Shopify, Webflow und Mailjet.

Jeder Kanal bekommt dabei keine Kopie, sondern greift auf denselben Datensatz zu. Eine Korrektur auf der Website ist deshalb im selben Moment auch auf dem Screen und im nächsten Newsletter korrekt.

Ja. Flyo lässt sich in bestehende Infrastrukturen integrieren und unterstützt einen schrittweisen Übergang, ein Big-Bang-Relaunch ist nicht nötig.

In der Praxis gibt es zwei Optionen. Mit Option 1 bleibt die bestehende Website zunächst bestehen, und einzelne Bereiche werden über Embed-Codes aus Flyo bespielt. Typischerweise beginnt man mit dem Veranstaltungskalender oder dem Newsbereich, weil dort der Pflegeaufwand am höchsten ist. Bei der zweiten Option wird das Frontend neu gebaut und holt seine Inhalte über die Content Delivery API; bestehende Inhalte werden dabei über die API importiert.

Ein Umstieg über Embed-Codes, etwa nur für Blog oder Veranstaltungskalender ist meist in wenigen Tagen produktiv, weil das bestehende Frontend unverändert bleibt und lediglich einzelne Bereiche aus Flyo bespielt werden. Ein vollständiger Frontend-Neubau über die Content Delivery API dauert in unseren Projekten 3 bis 5 Monate; diese Spanne gilt für einen Auftritt mit mehreren Inhaltstypen und einem bestehenden Bestand strukturierter Inhalte, Design, Inhaltsmigration und Abnahme sind darin enthalten.

Welcher Weg sinnvoll ist, hängt vom Zustand der aktuellen Website und von der Menge strukturierter Inhalte ab.

Headless-Architektur ist die Voraussetzung dafür, dass KI-Systeme Inhalte zuverlässig auslesen und zitieren können. Der Grund liegt in der Datenhaltung: In klassischen Systemen sind Inhalt und Darstellung vermischt, und ein Veranstaltungsdatum steht als Zeichenkette irgendwo im HTML. In einem Headless CMS liegt dasselbe Datum als Datumsfeld in einem strukturierten Datensatz, maschinell eindeutig interpretierbar.

Flyo setzt dabei auf einen Entity-First-Ansatz: Personen, Produkte, Orte und Events werden als eigenständige Einheiten mit definierten Feldern erfasst, nicht als Fliesstext auf einer Seite. Aus diesen Strukturen lassen sich Schema.org ↗-Auszeichnungen wie Organization, Event oder Person automatisch erzeugen, die von Google AI Overviews, ChatGPT und Perplexity als Grundlage für Antworten verwendet werden.

Der zweite Effekt betrifft die Zugänglichkeit: Weil die Inhalte über eine API serverseitig ausgeliefert werden, sind sie auch für KI-Crawler lesbar, die kein JavaScript ausführen, anders als bei rein clientseitig gerenderten Websites.

WordPress ist ein klassisches CMS, das ursprünglich für Entwickler:innen gebaut wurde und über Plugins erweitert wird. Das Flyo CMS ist ein Schweizer System, das einen visuellen Editor für Redaktionen mit einer API-first-Infrastruktur kombiniert.

Der praktische Unterschied zeigt sich im Betrieb. Eine gewachsene WordPress-Installation bringt typischerweise zwanzig bis dreissig Erweiterungen mit, die bei jedem Core-Update auf Kompatibilität geprüft werden müssen; Sicherheitslücken gelangen in aller Regel über genau diese Erweiterungen ins System. Flyo hat keine Plugin-Architektur: Mehrsprachigkeit, Versionierung, Workflows und Social-Media-Publishing sind Teil des Produkts und werden zentral aktualisiert, ohne dass Kundenprojekte angepasst werden müssen.

Der zweite Unterschied betrifft die Reichweite der Inhalte. WordPress-Inhalte gehören zur Website. Flyo-Inhalte liegen strukturiert im Content Hub und lassen sich zusätzlich auf Newsletter, Digital-Signage-Screens, Social Media und Druckvorlagen ausspielen, ohne zweite Datenpflege. Für Entwickler:innen bedeutet das ausserdem: Inhalte fliessen über eine dokumentierte REST-API in jedes Frontend, statt an ein PHP-Theme gebunden zu sein.

Multi-Channel bedeutet, dass du deine Zielgruppen über mehrere Kanäle erreichst, Website, Newsletter, Social Media, Screens, diese Kanäle aber jeweils eigenständig gepflegt werden. Omnichannel bedeutet, dass alle Kanäle auf denselben zentralen Datenbestand zugreifen.

Der Unterschied zeigt sich bei einer Änderung. Multi-Channel: Eine verschobene Veranstaltung wird in vier Systemen korrigiert, und beim vierten vergisst sie jemand. Omnichannel: Der Datensatz wird einmal geändert, alle Kanäle zeigen im selben Moment die neue Zeit.

Ein Headless CMS ist die technische Voraussetzung dafür, weil es Inhalte strukturiert und layoutneutral vorhält und über eine Schnittstelle an beliebig viele Abnehmer ausliefert. Flyo ergänzt das um fertige Anbindungen für die häufigsten Kanäle, Social Media, Newsletter, Digital Signage, Druckvorlagen sowie Portale wie Guidle und Eventfrog.

Flyo speichert eine vollständige Versionshistorie für jeden Inhalt. Du siehst, wer wann was geändert hat, kannst zwei Versionen vergleichen und jederzeit zu einer früheren zurückkehren, auch einzelne Felder, nicht nur ganze Seiten.

Zusätzlich erstellt Flyo täglich automatische Snapshots des gesamten Datenbestands. Selbst wenn ein grösserer Fehler erst nach Tagen auffällt, lässt sich der Stand davor wiederherstellen. Die Daten liegen dabei in der Schweiz, bei Mironet AG in Münchenstein bei Basel und einem AWS-Cluster in Zürich.

Ein klassisches CMS koppelt Inhaltspflege und Darstellung: Die Inhalte liegen in derselben Anwendung, die auch das HTML rendert, meist gebunden an ein Theme oder Template-System. Ein Headless CMS trennt beides. Inhalte werden strukturiert gespeichert und über eine Schnittstelle ausgeliefert, das Frontend ist ein beliebiger Abnehmer.

• Darstellung: Klassisch liegt das Template im CMS. Headless entscheidet das Frontend, was mit den Feldern passiert: statisch generiert, serverseitig gerendert oder als Single-Page-Application.
• Anzahl Abnehmer: Klassisch ist ein Inhalt eine Seite. Headless ist ein Inhalt ein Datensatz, den Website, App, Newsletter, Screen und Portal gleichzeitig beziehen.
• Framework-Wechsel: Klassisch bedeutet ein Technologiewechsel eine Inhaltsmigration. Headless betrifft er nur das Frontend; die Inhalte bleiben, wo sie sind.

Flyo liefert dafür strukturiertes JSON über eine dokumentierte REST-API mit vollständiger OpenAPI-Spezifikation. Ausführlicher Vergleich:

→ Vergleich Wordpress vs Flyo ↗

Flyo ist eine 100%ige Eigenentwicklung der Heartbeat GmbH ↗ und kombiniert verschiedene Technologien in einer Mikroservice-Architektur. Flyo läuft in einem Managed Kubernetes Cluster in Münchenstein bei Basel (managed by Mironet ↗ im IWB-Datenzentrum ↗).

Services wie Edge Layer Caching (Varnish Cache), oder On the Fly Image Processing sorgen für eine hohe Performance und Entwicklerfreundlichkeit.

Die Daten werden in Zürich auf einem AWS-RDS-Aurora-Cluster gehostet, die Assets unserer Kunden (Bilder, PDFs und weitere Dateien) ebenfalls bei AWS in der Schweiz. Cloudflare dient als Edge-Security-Layer.

Asynchrone Prozesse, interne Caching-Algorithmen und ein Persistenzlayer sorgen für die sofortige Verarbeitung von Dateninputs über alle Publikationskanäle hinweg.

Für die kontinuierliche Gewährleistung der technischen Sicherheit arbeiten wir mit Compass Security ↗ zusammen, setzen auf kontinuierliches Uptime ↗- und Error-Monitoring. Häufige Releases sorgen für regelmässig Updates und lassen sich im Changelog ↗ transparent nachvollziehen. DevOps-Engineering und umfangreiche Testing-Routinen gewährleisten eine hohe Uptime ↗.

Belegbar sind diese Werte: Über das Jahr 2025 beantwortete die Content Delivery API 132 Millionen Requests bei einer Verfügbarkeit von 99,980 %. Im Tagesdurchschnitt sind es rund 850'000 Server-Requests.