Structured content in the CMS: More freedom for editorial teams

«Für die Kampagne in einem Monat brauchen wir noch schnell eine Landingpage.»

Klingt nach einer einfachen Aufgabe. Ist es aber nur, wenn das CMS dafür gemacht ist.

In manchen Systemen kann die Redaktion eine neue Seite selbst aus bestehenden Inhaltselementen zusammenstellen: Text, Bild, Teaser, Downloads, Formular – fertig. In anderen gibt es für jede Seite ein festes Template. Fehlt dort etwas, muss zuerst die Entwicklung ran: neues Feld ergänzen, Template anpassen, testen, deployen.

Aus «noch schnell eine Landingpage» wird so plötzlich ein kleines Projekt.

Genau hier zeigt sich, wie viel Freiheit ein CMS der Redaktion wirklich gibt.

Je genauer das Seitentemplate, desto schneller kommt die Ausnahme

Websites werden meistens in Seiten gedacht. Über uns. Leistungen. Karriere. Landingpages. News. Das ist logisch. Genau diese Seiten sehen Besucher*innen schliesslich auch.

Also liegt es nahe, im CMS dieselbe Struktur abzubilden: ein Modell für Karriere, eines für Leistungen, eines für Landingpages. Eine Landingpage bekommt dann zum Beispiel:

• Titel
• Intro
• Bild
• drei Teaser
• Call-to-Action

Funktioniert wunderbar. Solange die nächste Landingpage genau gleich aussieht.

Für die neue Kampagne brauchen wir aber vielleicht ein Video. Darunter drei passende Angebote. Dann einen Download. Und ganz unten ein Formular. Also noch ein Feld. Noch eine Option. Vielleicht noch ein Toggle. Zagg.

Aus dem übersichtlichen Seitentemplate wird langsam das Formular aus der Hölle. Das eigentliche Problem: Mit jedem Template bilden wir nicht nur ab, was die Website heute braucht. Wir versuchen gleichzeitig vorauszusagen, wie sie in zwei Jahren aussehen wird. Das können wir erstaunlich schlecht.

Wir modellieren lieber Inhalte als Seiten

Wir drehen die Sache deshalb lieber um. Statt zu definieren, wie eine Landingpage aussehen muss, überlegen wir uns, aus welchen Inhaltselementen sie bestehen kann. Zum Beispiel: Text, Bild, Teaser, Zitat, Video, Download-Liste, Kontakt, Formular.

Unsere Kampagnen-Landingpage könnte damit so aussehen: Text → Video → Teaser → Download → Formular

Die nächste Landingpage vielleicht: Text → Teaser → Teaser → Kontakt

Und die Karriereseite: Text → Benefits → Jobs → Kontakt

Die Seiten sind unterschiedlich. Die Bausteine sind dieselben.

Damit verschiebt sich für die Redaktion eine ziemlich entscheidende Frage. Nicht mehr: «Welches Seitentemplate brauche ich?» Sondern: «Welche Inhalte brauche ich, um diese Geschichte zu erzählen?»

Das ist für uns der Kern einer guten Editor Experience.

Mehr Freiheit heisst nicht: Alle dürfen alles

Jetzt könnte man natürlich einfach einen komplett freien Page Builder ins CMS stellen. Schriftgrösse? Auswählbar. Abstände? Auswählbar. Spalten? Auswählbar. Buttonfarbe? Warum nicht.

Das gibt maximale Freiheit. Und nach zwei Jahren vermutlich sieben verschiedene Varianten desselben Teasers.

Unsere Vorstellung von Freiheit ist deshalb eine andere: Viel Freiheit beim Inhalt. Wenig unnötige Entscheidungen bei der Gestaltung.

Daraus ergeben sich drei Dinge, die wir für Redaktionen besonders wichtig finden.

Die Redaktion kann neue Seiten selbst zusammenstellen

Zurück zu unserer Kampagne. Niemand hat beim Relaunch vorhergesehen, dass wir genau diese Landingpage brauchen werden. Muss auch niemand.

Wenn die benötigten Elemente bereits existieren, kann die Redaktion sie selbst kombinieren: Intro → Video → Teaser → Download → Formular

Kein neues Template. Keine zusätzlichen Felder. Kein Ticket für die Entwicklung.

Das ist für uns die wichtigste Form von Freiheit im CMS: Die Website darf sich verändern, ohne dass jede Veränderung zuerst durch die Entwicklung muss.

Natürlich funktioniert das nur innerhalb des vorhandenen Baukastens. Wenn plötzlich eine interaktive 3D-Produktdemo gebraucht wird, wird auch ein gutes CMS sie nicht herbeizaubern. Aber viele redaktionelle Anforderungen sind gar nicht neu. Sie sind nur neue Kombinationen von Dingen, die längst existieren. Genau dafür sollte eine Redaktion keine Entwickler*innen brauchen.

Einmal gelernt, funktioniert es überall

Seitenbasierte CMS entwickeln mit der Zeit gerne ihre eigenen kleinen Dialekte. Auf der einen Seite heisst ein Feld «Intro». Auf der nächsten «Lead». Auf der dritten «Einleitung». Hier kannst du drei Teaser hinzufügen. Dort fünf. Auf einer anderen Seite gibt es dieselben Teaser, aber irgendwie funktionieren sie anders.

Technisch ist das alles erklärbar. Redaktionell ist es mühsam.

Wiederverwendbare Inhaltselemente geben dem CMS dagegen eine konsistente Sprache. Text ist Text. Teaser ist Teaser. Download ist Download.

Wenn du einmal verstanden hast, wie ein Element funktioniert, kannst du es überall einsetzen, wo es vorgesehen ist. Das reduziert Schulungsaufwand. Vor allem reduziert es aber die kleinen Fragen im Alltag: «Wo war das nochmal?» «Warum geht das auf dieser Seite nicht?» «Was ist der Unterschied zwischen diesen beiden Feldern?»

Ein CMS, das dich nicht ständig überrascht, ist schon ziemlich viel wert.

Die Redaktion pflegt Inhalte, keine Pixel

Mehr Freiheit bedeutet nicht automatisch mehr Optionen. Oft ist das Gegenteil besser.

Eine Redaktorin sollte nicht entscheiden müssen, ob zwischen zwei Elementen 24 oder 32 Pixel Abstand gehören. Sie sollte sich auch nicht darum kümmern müssen, wie ein Element auf Mobile umbricht oder welche HTML-Struktur für Screenreader korrekt ist.

Ihre Entscheidung ist: Das ist ein Zitat. Nicht: Das ist 26 Pixel grosser Text mit 48 Pixel Abstand oben.

Die Redaktion kümmert sich um den Inhalt. Designsystem und Website kümmern sich um die Darstellung. Gute Editor Experience bedeutet für uns deshalb nicht maximale Freiheit. Sondern die richtigen Freiheiten an der richtigen Stelle.

Genau diese Leitplanken machen auch die Website besser

Das Schöne daran: Was die Arbeit im CMS einfacher macht, hilft gleichzeitig der Website. Denn strukturierte Inhalte geben uns klare Regeln. Und diese Regeln können wir einmal sauber lösen.

Ein Teaser bleibt überall ein Teaser

Wenn ein Teaser ein definiertes Inhaltselement ist, können wir seine Darstellung zentral festlegen. Ändert sich später das Design, ändern wir die Komponente einmal. Nicht jede Seite einzeln.

Dasselbe gilt für Zitate, Downloads, Formulare oder Kontaktblöcke. Die Redaktion kann die Elemente unterschiedlich kombinieren. Die Website sorgt dafür, dass sie trotzdem überall konsistent aussehen und funktionieren.

Freiheit bei der Zusammenstellung. Leitplanken bei der Darstellung. Das ist der Deal.

Wenn wir wissen, was etwas ist, können wir es besser behandeln

Ein grosser Rich-Text-Block kann für einen Menschen völlig verständlich aussehen. Technisch ist er zunächst einmal einfach Text.

Bei strukturierten Inhalten wissen wir mehr. Das ist ein Bild. Das ist ein Job. Das ist ein Event. Das ist eine FAQ. Das ist ein Download.

Und weil wir wissen, was etwas ist, können wir Regeln daran knüpfen. Ein Bild braucht beispielsweise einen Alt-Text. Ein Event kann strukturierte Daten für Suchmaschinen bekommen. Eine Überschrift kann sauber in die semantische Hierarchie der Seite eingebaut werden. Ein Element kann so entwickelt werden, dass Tastaturbedienung und Screenreader-Verhalten einmal korrekt gelöst sind.

Und auch für LLMs wird diese Struktur interessanter: Klar abgegrenzte, semantische Inhalte lassen sich einfacher einordnen als eine grosse Wand aus Markup und Text.

Inhaltselemente machen eine Website deshalb nicht automatisch SEO-optimiert, barrierefrei oder AI-friendly. Aber sie geben uns einen Ort, an dem wir diese Dinge einmal sauber lösen können. Und nicht auf jeder Seite ein bisschen anders.

Neue Anforderungen erweitern den Baukasten

Irgendwann kommt natürlich trotzdem etwas, das es noch nicht gibt. Sagen wir: eine Timeline.

Dann bauen wir ein neues Inhaltselement. Wir definieren einmal:

• welche Inhalte es braucht
• wie es dargestellt wird
• wie es auf kleinen Screens funktioniert
• welche Accessibility-Regeln gelten

Danach gibt es im CMS einen neuen Baustein: Timeline.

Der wurde vielleicht ursprünglich für eine einzelne Seite gebaut. Danach steht er aber der ganzen Redaktion zur Verfügung. Eine neue Anforderung macht also nicht einfach das nächste Seitentemplate komplizierter. Sie erweitert den Werkzeugkasten. Das ist für uns deutlich nachhaltiger.

Nicht alles muss flexibel sein

Jetzt könnten wir daraus natürlich die Regel machen: Alles ist ein Inhaltselement. Würden wir nicht.

Ein Newsartikel hat meistens eine ziemlich klare Struktur. Ein Job ebenfalls. Dasselbe gilt oft für Personen, Events oder Produkte. Dort ist ein festes Content Model sinnvoll.

Und auch bei flexiblen Seiten sollte nicht jeder Absatz zum eigenen Block werden. Wenn du für jeden Textabschnitt zuerst «Text hinzufügen» klicken musst, haben wir zwar wunderschön strukturierte Daten gebaut, aber ein ziemlich nerviges CMS.

Die Frage ist deshalb nicht: Templates oder Inhaltselemente? Sondern: Wo braucht die Redaktion Struktur – und wo braucht sie Freiheit? Genau diese Grenze müssen wir bei jedem Projekt neu ziehen.

Unser einfachster CMS-Test

Wir haben dafür eine ziemlich einfache Frage: Was passiert, wenn die Redaktion morgen eine Seite bauen möchte, die wir heute noch nicht vorgesehen haben?

Zum Beispiel: «Für die Kampagne in einem Monat brauchen wir noch schnell eine Landingpage.»

Wenn die Antwort lautet:

«Wir müssen dafür zuerst ein neues Template bauen.»

…dann ist die Redaktion nur so flexibel wie unsere Vorstellungskraft beim Relaunch.

Wenn die Antwort lautet:

«Die Bausteine sind schon da.»

…haben wir wahrscheinlich einiges richtig gemacht.

Ein gutes CMS gibt Redaktionen nicht möglichst viele Optionen. Es gibt ihnen die richtigen Freiheiten. Die Freiheit, Inhalte neu zu kombinieren. Die Freiheit, auf neue Anforderungen zu reagieren. Und die Freiheit, sich nicht mit Breakpoints, HTML-Strukturen und Pixelabständen beschäftigen zu müssen.

Dann ist «noch schnell eine Landingpage» vielleicht tatsächlich genau das.

Noch schnell.