CMS und Website: Direktzugriff oder entkoppelte Auslieferung?

Ein Direktzugriff der Website auf das Redaktionssystem genügt bei einem Ausgabekanal, niedriger Änderungsfrequenz und ohne geplante Ablösung. Kommen weitere Kanäle, hohe Last oder eine Systemablösung hinzu, lohnt sich ein entkoppelter Auslieferungsindex mit Content-API.

Wer heute über ein Redaktionssystem entscheidet, entscheidet selten nur über ein Redaktionssystem.

Was kostet uns der nächste Ausgabekanal? Die Antwort auf diese Frage steht nicht im Lastenheft des Redaktionssystems. Sie steht im Datenfluss dahinter. Ist die Website direkt an das Redaktionssystem angebunden, kostet jeder weitere Kanal eine eigene Anbindung, mit allen Folgen für Last, Kopplung und Betrieb. Liegt zwischen Redaktion und Auslieferung eine saubere Schichtung, kostet er eine Integration gegen eine bestehende Schnittstelle.

Die entscheidende Frage lautet daher nicht nur: Welches Redaktionssystem setzen wir ein? Sondern: Wie sieht der Datenfluss aus, der unsere Inhalte in alle Kanäle bringt, die wir heute noch nicht kennen?

Dieser Beitrag beschreibt die Architektur, die wir in Kundenprojekten dafür einsetzen: NovaDB als führendes Content-Repository (Content-Hub), Elasticsearch als Auslieferungsindex und eine Content-API als gemeinsamer Zugang für alle Kanäle. Er beschreibt ebenso, wann sich dieser Aufwand nicht rechnet.

Der Weg eines Inhalts besteht aus drei Abschnitten: InBound nimmt Änderungen aus den Quellsystemen auf und überführt sie in das einheitliche Dokumentmodell der NovaDB, OutBound baut daraus den Auslieferungsindex, und die Auslieferung stellt die Inhalte den Kanälen bereit. Alle drei werden bewusst unabhängig voneinander betrieben, getestet und abgenommen.

1. InBound: Änderungen aufnehmen, ohne sie zu verlieren

Redaktionelle Systeme melden Änderungen per Webhook: Veröffentlichung, Aktualisierung, Depublizierung, Löschung, Medien-Update. Diese Meldungen landen nicht direkt in der Verarbeitung, sondern auf einem persistenten, replizierten Message-Stream. Von dort holen spezialisierte Worker das vollständige Dokument ab, lösen Referenzen und IDs auf, prüfen Linkziele, importieren Medien und überführen das Ergebnis in das einheitliche Dokumentmodell der NovaDB.

Der häufigste Fehler an dieser Stelle ist, Webhooks direkt zu verarbeiten. Wer das tut, verliert Ereignisse in genau dem Moment, in dem ein Dienst neu startet oder ein Import scheitert. Und wer den Ereignisspeicher nachträglich einzieht, schreibt die Importlogik ein zweites Mal.

2. OutBound: Auslieferung aufbauen, ohne die Redaktion zu belasten

Nach jedem erfolgreichen Schreibvorgang wird ein Folgeereignis publiziert. Die OutBound-Worker lesen das Dokument über die NovaDB-API, mappen es auf ein indexierbares Suchdokument mit Volltext, Metadaten, Facetten, Autocomplete-Feldern und SEO-Pfad und schreiben es nach Elasticsearch.

Entscheidend ist, was diese Strecke nicht weiß. Sie kennt keine Quellsysteme, sondern nur eine Dokument-ID und den Weg zur NovaDB. Dieser bewusste Verzicht ist der Grund, dass die Anbindung eines zusätzlichen Quellsystems später eine neue InBound-Pipeline kostet und sonst nichts.

3. Auslieferung: Änderungen in Sekunden sichtbar machen

Die Website liest aus dem Index und hält einen lokalen Cache. Ein eigener Hintergrunddienst hört auf die Indexierungsereignisse und verwirft gezielt genau die betroffenen Cache-Einträge. Redaktionelle Änderungen werden dadurch innerhalb von Sekunden sichtbar, ohne dass pauschal Caches geleert oder Anwendungen neu gestartet werden müssen.

Das pauschale Cache-Leeren ist die Lösung, die in der ersten Projektwoche funktioniert und im ersten Lastfall nicht mehr. Ein Neustart nach jeder Freigabe ist keine Betriebsstrategie.

Die Aufteilung in InBound und OutBound wirkt zunächst nach zusätzlichem Aufwand, zahlt sich aber an vier Stellen aus, und jede davon hat einen Preis, wenn sie fehlt.

• Ausfälle bleiben folgenlos. Ist ein nachgelagerter Dienst kurzzeitig nicht erreichbar, gehen keine Ereignisse verloren. Sie werden verarbeitet, sobald der Dienst zurück ist. Ohne diese Eigenschaft ist jeder Ausfall ein manueller Nachimport mit unklarem Umfang.
• Fehler sind lokalisierbar. Ein Importproblem ist ein Importproblem, ein Indexproblem ein Indexproblem. Wer schon einmal eine Suchindexierung debuggt hat, die gleichzeitig Importlogik enthielt, kennt den Unterschied im Zeitaufwand.
• Die Auslieferung ist von der Redaktion entkoppelt. Lastspitzen auf der Website erreichen das Redaktionssystem nicht. Damit lässt sich die Website skalieren, ohne die Redaktionslizenzen oder die Infrastruktur des Redaktionssystems mitzuskalieren.
• Quellsysteme sind austauschbar. Ob der Inhalt aus einem Headless-CMS, einem weiteren Fremdsystem oder direkt aus der NovaDB stammt, ist für die Auslieferung ohne Bedeutung. Auslieferung, Suche, Caching und Frontend bleiben bei jeder Erweiterung unberührt.

Ein Content-Hub ist ein führendes Content-Repository, das nicht nur redaktionelle Artikel führt, sondern alles, was eine Seite ausmacht: Teaser, Formulare, Banner, Navigationen und Seitenmodule als kanalneutrale Dokumenttypen.

Bis hierher beschreibt der Datenfluss redaktionelle Inhalte. Eine reale Seite besteht aber aus deutlich mehr: kuratierten Teasern, Newsletter- und Kontaktformularen, Hinweisbannern, Kampagnenelementen, Navigationen, Landingpage-Modulen und rechtlichen Texten. Genau diese Elemente sind in klassischen Redaktionssystemen selten vorgesehen.

In der Praxis landen sie deshalb an einer von drei Stellen, und keine davon trägt langfristig:

• Fest verdrahtet im Frontend. Jede Änderung wird zum Deployment, die Redaktion kann nicht selbst handeln.
• In einem zweiten kleinen System oder einer Konfigurationsdatei. Damit entstehen ein zweiter Pflegeprozess, ein zweites Rechtemodell und ein zweiter Aktualisierungsstand.
• In den Seitenvorlagen des Quellsystems. Die unauffälligste und zugleich teuerste Variante.

Der dritte Fall verdient besondere Aufmerksamkeit, weil er die Argumentation des vorigen Abschnitts aushebelt. Liegt die Seitenkomposition in den Templates des Redaktionssystems, lässt sich zwar die Artikelquelle austauschen, die Seite aber nicht. Die Austauschbarkeit der Quellsysteme besteht dann nur auf dem Papier, und sie fällt genau dann auf, wenn eine Ablösung ansteht.

Wir modellieren diese Elemente deshalb als eigene Dokumenttypen in der NovaDB. Sie durchlaufen dieselbe OutBound-Strecke, liegen im selben Index und sind über denselben Zugang erreichbar wie redaktionelle Inhalte. Damit wird aus dem führenden Content-Repository ein Content-Hub für alles, was eine Seite ausmacht, und nicht nur für ihren Fließtext.

Der Gewinn ist unmittelbar:

• Teaserstrecken und Kampagnenelemente sind über dieselbe Vorschau prüfbar wie Artikel.
• Formulardefinitionen unterliegen derselben Schema-Validierung. Pflichtfelder und Einwilligungstexte sind damit technisch prüfbar statt organisatorisch vereinbart.
• Die gezielte Cache-Invalidierung gilt auch für Navigation und Teaser. Ein Seitenumbau erfordert keinen Neustart.
• Rechte, Freigaben und Nachvollziehbarkeit gelten einheitlich und nicht getrennt nach Inhaltsart.

Eine Abgrenzung ist dabei entscheidend und wird in Projekten regelmäßig übersehen: In den Hub gehört das kanalneutrale Modul, nicht das gerenderte Website-Fragment. Ein Teaser ist eine kuratierte Referenz mit Absicht und Reihenfolge, kein fertiger HTML-Block. Ein Formular ist eine Definition aus Feldern, Validierungsregeln und Einwilligungstext, kein Website-Widget. Wo diese Module auf welcher Seite erscheinen, löst der jeweilige Kanal auf.

Wer stattdessen Website-Layout in den Hub schreibt, bindet ihn an genau einen Kanal zurück und verliert damit den Vorteil, für den die Entkopplung gebaut wurde.

Unverändert bleibt die Laufzeit: Der Hub beschreibt ein Formular, er verarbeitet keine Einsendungen. Absenden, Spam-Schutz, Double-Opt-in und Einwilligungsprotokoll bleiben Aufgabe des Kanals oder eines dafür vorgesehenen Dienstes.

Ein Content-Hub bündelt Inhalte in einem Dokumentmodell, die Pflege bleibt aber je Inhaltsart im passenden Werkzeug. Der naheliegende Schluss, dass auch die Pflege an einer Stelle stattfinden sollte, ist meist falsch.

Inhaltsarten unterscheiden sich nicht im Detail, sondern im Prozess. Technische Dokumentation lebt von Modularisierung, Variantensteuerung, Validierung gegen ein Schema und einem Übersetzungsprozess. Produktdaten leben von Klassifikation, Attributvererbung und kanalspezifischer Ausleitung. Webinhalte leben von Kampagnenplanung, Terminierung, Vorschau und schneller Veröffentlichung. Diese Prozesse haben wenig gemeinsam, und die Werkzeuge, die sie gut unterstützen, ebenfalls.

Wer alle drei in ein System zwingt, erhält ein System, mit dem zwei von drei Redaktionen gegen ihr Werkzeug arbeiten. Das Ergebnis ist in Projekten gut beobachtbar: Schattenprozesse in Excel und Word, Freigaben per Mail und Tickets an die IT für Änderungen, die eine Redaktion selbst vornehmen können müsste.

Ein entkoppelter Datenfluss löst diesen Zielkonflikt auf. Jede Inhaltsart bleibt in dem System, in dem sie sich am besten pflegen lässt: Technische Dokumentation im Redaktionssystem für TechDoc, Produktdaten im PIM, Webinhalte und Seitenmodule in der NovaDB. Die Vereinheitlichung findet im Dokumentmodell statt, nicht im Werkzeug. Für die Auslieferung und für alle angebundenen Kanäle ist die Herkunft ohne Bedeutung.

Die Frage in Auswahlprojekten lautet damit nicht mehr, welches System am meisten kann, sondern welche Redaktion mit welchem Prozess arbeitet. Das sind zwei sehr verschiedene Fragen, und nur die zweite lässt sich belastbar beantworten.

Zwei Einschränkungen gehören dazu. Jedes zusätzliche Quellsystem kostet eine InBound-Pipeline, ein Mapping in das gemeinsame Dokumentmodell und Betriebsverantwortung. Die Architektur macht die Wahl möglich, nicht kostenlos. Und die Konsolidierung auf ein System bleibt eine legitime Entscheidung. Sie ist dann nur eine Entscheidung und keine technische Vorgabe.

Der eigentliche Gewinn liegt in der Reversibilität: Die Wahl wird je Inhaltsart getroffen und je Inhaltsart korrigierbar. Niemand legt sich mit einer einzigen Beschaffung für alle Inhalte auf Jahre fest.

Zwei getrennte Indizes lösen einen Konflikt, der in der Konzeption regelmäßig zu spät bedacht wird: Die Redaktion möchte Entwürfe sehen, Endnutzer dürfen sie nicht sehen.

Ein Preview-Index enthält den jeweils aktuellen Redaktionsstand, ein Live-Index ausschließlich Veröffentlichtes. Das Speichern eines Entwurfs schreibt nur in den Preview-Index, erst die Freigabe schreibt in beide. Eine Depublizierung entfernt das Dokument aus dem Live-Index, belässt es aber als Entwurf in der Vorschau.

Die Redaktion erhält damit eine belastbare Vorschau über exakt denselben Auslieferungspfad, den auch die Endnutzer durchlaufen. Vorschau und Live unterscheiden sich nur im Index, nicht in der Renderlogik. Abweichungen zwischen Vorschau und veröffentlichtem Stand sind konstruktiv ausgeschlossen.

Weil auch Teaser, Banner und Seitenmodule im Hub liegen, gilt das nicht nur für einzelne Artikel. Eine umgebaute Teaserstrecke oder ein geänderter Kampagnenhinweis lässt sich vollständig prüfen, bevor er live geht. In Setups, in denen diese Elemente außerhalb des Redaktionssystems liegen, ist genau das nicht möglich.

Wird dieser Punkt übersehen, fällt er in der Abnahme auf. Die Nachrüstung erzeugt dann in der Regel einen zweiten Renderpfad neben der bestehenden Auslieferung. Zwei Renderpfade laufen dauerhaft auseinander, und der Wartungsaufwand dafür übersteigt die einmaligen Kosten des zweiten Index um ein Vielfaches.

Eine Content-API ist die schlanke Schnittstelle vor dem Auslieferungsindex, über die jeder Kanal, nicht nur die Website, Inhalte abruft.

Bis hierher beschreibt der Datenfluss eine Website. Interessant wird die Architektur an der Stelle, an der man aufhört, sie als Website-Architektur zu denken.

Der Auslieferungsindex enthält bereits alles, was ein Kanal braucht: aufbereitete Inhalte, aufgelöste Referenzen, Medien-URLs, Metadaten und Facetten sowie die kanalneutralen Module aus dem Hub, in einer einheitlichen, quellenunabhängigen Struktur. Was fehlt, ist lediglich ein definierter Zugang. Deshalb setzen wir vor den Index eine schlanke Content-API, die Dokumente über eine stabile Adressierung ausliefert und dabei explizit zwischen Live- und Vorschaustand unterscheidet.

Damit verschiebt sich das Bild grundlegend:

• Die Website ist nur noch ein Konsument. Sie hat keine Sonderstellung mehr, sondern nutzt denselben Zugang wie jeder andere Kanal.
• Neue Kanäle sind Integrationen, keine Projekte. Apps, Newsletter-Strecken, Partner- und Syndication-Angebote, Microsites, Landingpages, Kioske oder interne Anwendungen greifen auf dieselbe Quelle zu, ohne dass die Content-Pipeline erweitert werden muss.
• Redaktionelle Vorschau funktioniert kanalübergreifend. Weil die Vorschau über denselben Mechanismus läuft, lässt sie sich in jedem angebundenen Kanal anbieten, nicht nur auf der Website.
• Die Governance bleibt an einer Stelle. Zugriffsschutz, Ratenbegrenzung, Versionierung und Monitoring liegen in der API, nicht verstreut in den Konsumenten.

So entsteht aus einer Website-Architektur eine Content-Plattform. Nicht als späterer Umbau, sondern als Nebenprodukt einer sauberen Schichtung. Die zugesicherte Dokumentstruktur aus der Schema-Validierung ist dabei keine Formalie, sondern die Voraussetzung dafür, dass sich mehrere Kanäle überhaupt auf dieselbe Schnittstelle verlassen können.

Die entkoppelte Architektur entfaltet ihren Nutzen besonders dann, wenn ein Redaktionssystem abgelöst werden soll.

Weil die Konsumenten gegen ein vereinheitlichtes Inhaltsmodell arbeiten und nicht gegen ein bestimmtes Redaktionssystem, können altes und neues Quellsystem parallel betrieben werden. Inhaltsbereiche wandern in Wellen, jede Welle ist einzeln abnehmbar und rückholbar. Es gibt keinen Stichtag, an dem alles gleichzeitig funktionieren muss, und keinen Feature-Stillstand während der Umstellung.

Für die angebundenen Kanäle ist der Wechsel des Quellsystems im Idealfall gar nicht wahrnehmbar.

Einen Projektplan für diesen Weg beschreibt unser Beitrag Praxisnaher Projektplan für die Ablösung von CMS und Redaktionssystemen.

Die entkoppelte Auslieferung mit Index und Content-API ist keine Empfehlung für jedes Vorhaben. Sie kostet zusätzliche Komponenten, zusätzlichen Betrieb und zusätzliche Kompetenz im Team.

Wir empfehlen sie nicht, wenn alle folgenden Punkte zutreffen:

• Es gibt genau einen Ausgabekanal, und es ist kein weiterer absehbar.
• Die Änderungsfrequenz ist niedrig, ein Ausliefern im Minutenbereich genügt.
• Redaktion und Website liegen im selben Verantwortungsbereich und im selben Betriebsmodell.
• Eine Ablösung des Redaktionssystems steht nicht zur Diskussion.

In diesem Fall ist ein Direktzugriff mit vorgeschaltetem Cache die wirtschaftlich richtige Entscheidung. Sobald jedoch einer dieser Punkte kippt, und in der Regel kippt zuerst die Kanalfrage, verschiebt sich die Rechnung deutlich.

In der Praxis zeigen sich vier Ausbaustufen:

Welche Stufe sinnvoll ist, hängt ab von:

• Anzahl heutiger und geplanter Ausgabekanäle
• geforderter Aktualität redaktioneller Änderungen
• Last- und Verfügbarkeitsanforderungen des Portals
• Anzahl und Austauschwahrscheinlichkeit der Quellsysteme
• Anzahl, Eigenständigkeit und Prozessunterschiede der beteiligten Redaktionen
• Anforderungen an redaktionelle Vorschau und Freigabe
• geplanter Nutzung der Inhalte durch KI- und Assistenzsysteme

Ein Content-Datenfluss ist keine Nebensache der Auswahl des Redaktionssystems. Er ist die Struktur, die über Betriebsstabilität, Migrationsfähigkeit und Weiterentwicklungsgeschwindigkeit entscheidet.

Die hier beschriebenen Prinzipien lassen sich unabhängig von der konkreten Systemlandschaft anwenden: ereignisgetriebene Entkopplung, persistente Ereignisverarbeitung, ein führendes Content-Repository (Content-Hub), ein separater Auslieferungsindex, getrennte Vorschau- und Live-Stände, Schema-Validierung an beiden Enden und eine Content-API als gemeinsamer Zugang.

Sie sind der Grund dafür, dass in unseren Projekten die Anbindung eines weiteren Quellsystems eine Erweiterung bleibt und keine Umbaumaßnahme. Und dass ein zusätzlicher Ausgabekanal eine Integration ist statt eines Projekts.

Entscheidungssicherheit statt Nachrüsten

Die Schichtung eines Content-Datenflusses ist eine Entscheidung, die sich später nur mit erheblichem Aufwand korrigieren lässt. Umso wichtiger ist es, sie früh und fundiert zu treffen.

Aus Projekten in Web-Systemen und Portalen, in der Produktkommunikation und in der Technischen Dokumentation unterstützen wir Sie dabei,

• die heutige Kopplung zwischen Redaktionssystem und Kanälen sichtbar zu machen
• die sinnvolle Ausbaustufe anhand Ihrer Kanal- und Lastanforderungen zu bestimmen
• Aufwand, Betriebsfolgen und Risiken jeder Stufe transparent zu bewerten
• je Inhaltsart das Pflegesystem zu bestimmen, das zum tatsächlichen Redaktionsprozess passt
• Teaser, Formulare und Seitenmodule aus dem Frontend zurück in die Redaktionshoheit zu holen
• eine Ablösung des Quellsystems als wellenweises Vorhaben ohne Stichtag zu planen
• Inhalte so zu strukturieren, dass KI- und Assistenzsysteme sie ohne zweite Aufbereitung nutzen können

Sie prüfen die Ablösung eines Redaktionssystems oder planen zusätzliche Ausgabekanäle und fragen sich, wie der Datenfluss dahinter aussehen sollte? Sprechen Sie uns an. Wir schauen uns Ihre Systemlandschaft gerne an.