Blockbasierte Inhaltsmodelle: Schemata statt freier Editoren
Warum blockbasierte Inhaltsmodelle in modernen CMSes so verbreitet sind - und wie typisierte Block-Schemata das Design jahrelanger Kundeneditierungen standhalten lassen.
So betrachten wir die Inhaltsmodellierung für kleine bis mittelgroße Agenturen.
TL;DR. Blockbasierte Inhaltsmodelle ersetzen den großen HTML-Block durch typisierte Einheiten (Hero, FAQ, Preise, Galerie), die jeweils nur die von der Agentur definierten Felder freischalten. Designs überstehen jahrelange Kundenbearbeitung, weil die Struktur im Code lebt und nicht in der Datenbank. Versionierung, Lokalisierung und strukturierte Datenausgabe entstehen fast nebenbei. Der Aufwand liegt in der Schema-Vorarbeit, die sich über ein Portfolio ähnlicher Sites schnell amortisiert.
TL;DR (zum Überfliegen)
- Freie Editoren führen oft dazu, dass Designs im Laufe der Zeit zerstört werden, da Kunden rohes HTML einfügen.
- Blockbasierte Editoren erzwingen Struktur und stellen sicher, dass Designs jahrelange Kundenbearbeitung überstehen.
- Der anfängliche Aufwand zur Definition von Block-Schemata zahlt sich für Agenturen aus, die viele ähnliche Websites verwalten.
Die Abkehr von freien WYSIWYG-Editoren hin zu blockbasierten Inhaltsmodellen ist eine der folgenreichsten Entwicklungen, die moderne CMSes durchlaufen haben. Es handelt sich nicht um eine UI-Mode. Sie verändert grundlegend, welche Fehler überhaupt möglich sind - und welche Designs jahrelange Kundenbearbeitung überstehen.
Freier Editor vs. blockbasierter Editor
Freie Editoren geben unstrukturierte HTML-Blöcke aus, die anfällig für Layoutbrüche sind, während blockbasierte Editoren typisierte Datenstrukturen erzwingen, die Inhalt von Präsentation trennen.
Ein freier Editor (wie der klassische WordPress-Editor oder klassisches CKEditor) bietet dem Redakteur ein großes Textfeld mit Formatierungswerkzeugen. Er kann HTML einfügen, Bilder beliebig platzieren, Überschriftsebenen wählen, Inline-Styles setzen. Das Ergebnis ist ein großer HTML-Block in der Datenbank.
Ein blockbasierter Editor unterteilt Inhalte in diskrete Einheiten. Jeder Block hat einen Typ (Hero, FAQ, Galerie, Kontaktinfo), einen definierten Satz bearbeitbarer Felder und eine bekannte Darstellungsweise. Der Redakteur sieht eine Liste von Blöcken, keinen HTML-Brei.
Dieser Unterschied wirkt sich auf jeder Ebene aus.
Was Blockmodelle richtig machen
Blockmodelle verankern das Design im Code, machen die Ausgabe strukturierter Daten automatisch und stellen sicher, dass Inhalte Designüberarbeitungen überstehen.
Designs überstehen jahrelange Kundenbearbeitung. Ein freier Editor ist eine Einladung, das Design zu beschädigen. Kunden fügen farbigen Text ein, verwenden uneinheitliche Überschriften, laden Bilder in voller Breite hoch, die eigentlich halbe Breite haben sollten. Nach sechs Monaten sieht die Seite kaum noch wie das ursprüngliche Design aus. Ein Blockmodell stellt dem Redakteur nur die Felder zur Verfügung, die die Agentur definiert hat. Das Design hält stand.
Inhalte sind von Haus aus strukturiert. Ein FAQ-Block enthält eine Liste von Frage-Antwort-Paaren. Ein Pricing-Block hat Tarife mit Name, Preis, Feature-Liste und CTA. Das Frontend kann diese Struktur beliebig rendern - und später umgestalten, wenn sich das Design ändert - ohne die Inhalte neu schreiben zu müssen.
SEO-Ausgabe entsteht automatisch. Strukturierte Inhalte sind das, worum jede SEO-Best-Practice (wie die von Schema.org formulierten) seit Jahren bittet. Ein FAQ-Block kann FAQPage-JSON-LD ausgeben, ohne dass der Redakteur etwas tun muss. Ein Pricing-Block kann Product-Schema emittieren. KI-Suche priorisiert strukturierte Daten stark - Blockmodelle liefern sie automatisch.
Lokalisierung ist unkompliziert. Ein als lokalisiert markiertes Blockfeld bekommt eine sprachspezifische Version genau dieses Felds. Die Blockstruktur ist gemeinsam; der lokalisierte Text variiert. Ein freier HTML-Körper muss jedes Mal als Ganzes übersetzt werden, ohne Werkzeug-Unterstützung für “dieser Abschnitt hat sich nicht geändert, bitte nicht neu übersetzen.”
Versionierung und Rollback funktionieren sauber. Ein Block-Dokument ist ein strukturiertes Objekt. Der Vergleich zweier Versionen ergibt etwas Sinnvolles: “Block X hatte seinen Titel von A nach B geändert.” Ein Diff eines freien HTML-Blocks ist eine Suche im Tag-Chaos.
Was Blockmodelle kosten
Weniger Ausdrucksfreiheit für den Redakteur. Der Kompromiss ist real. Ein Redakteur, der gewohnt ist, “etwas Text einzugeben und ein Bild dazuzuplatzieren”, fühlt sich eingeschränkt, wenn er nur definierte Felder bearbeiten kann. Für technische Inhalte schließt oft ein reicherer Textblock (Markdown oder eingeschränkter Rich Text) diese Lücke.
Vorarbeit beim Design. Die Blockbibliothek zu definieren ist echte Arbeit. Jeder Block braucht ein Schema, einen Renderer, ein Admin-Formular und idealerweise einen Hilfetext. Für eine einmalige kleine Site ist dieser Aufwand übertrieben. Für eine Multi-Site-Agentur, die dieselben Blocktypen über viele Kunden-Websites nutzt, amortisiert er sich schnell.
Blocktyp-Drift zwischen Kunden. Eine kleine Agentur kann dem gut gegensteuern. Eine wachsende hat es schwerer. Wenn jeder Kunde eine leicht abweichende “Hero-Variante” oder “Feature-Grid-Variante” bekommt, bläht sich die Blockbibliothek auf. Die meisten Agenturen, die blockbasierte Inhalte gut handhaben, landen bei einer überschaubaren Kernbibliothek (15 bis 30 Blöcke) plus einigen wenigen kundenspezifischen Blöcken für besondere Anforderungen.
Eine gute Blockbibliothek gestalten
Einige Muster bewährten sich gut. Ein Block pro Inhaltsform - ein Hero-Block ist ein Hero-Block, kein generischer “Bereich”. Pflichtfelder sind auf Schema-Ebene verpflichtend. Für jedes nicht offensichtliche Feld gibt es einen Hilfetext in der Verwaltungsoberfläche. Lokalisierung nur dort, wo sie sinnvoll ist - Textfelder lokalisieren, strukturelle Felder wie Ausrichtung nicht. Bilder in einem Seitenverhältnis pro Block. Eine flexible Inhaltszone für einmalige Layouts, bei denen der Kunde eine Liste von Blöcken selbst zusammenstellen soll.
Wo Kernset sich einordnet
Nach unserer Erfahrung ist Kernset von Grund auf um blockbasierte Inhalte herum aufgebaut. Block-Schemata leben in TypeScript neben dem übrigen Quellcode der Agentur. Der Editor rendert gegen das Schema. Kunden bearbeiten die Felder, die die Agentur freigeschaltet hat - und nur diese. Lokalisierung, Versionierung und strukturierte Datenausgabe sind erstklassige Funktionen.
Die Blockbibliothek, die Kernset mitbringt, umfasst über 30 Standardblöcke sowie eine Fabrik für kundenspezifische Blöcke. Das Muster der flexiblen Inhaltszone deckt die Fälle ab, in denen der Kunde Blöcke innerhalb eines Bereichs hinzufügen und umordnen möchte. Wir haben festgestellt, dass es das richtige Werkzeug für betreute KMU-Sites ist, bei denen das Design jahrelange Kundenbearbeitung überstehen muss.
Häufige Fragen
Bedeuten blockbasierte Editoren, dass der Kunde keine neuen Layouts erstellen kann?
Im Allgemeinen ja. Blockbasierte CMS schränken Redakteure absichtlich auf vordefinierte Layouts (Blöcke) ein, die von der Agentur entwickelt wurden. Dies nimmt dem Kunden zwar die Layoutfreiheit, verhindert aber, dass er das Designsystem der Website beschädigt.
Gegen Ihre Blockbibliothek testen
Wenn Sie abwägen, ob typisierte Block-Schemata die Schema-Vorarbeit wert sind, ist der schnellste Weg zur Entscheidung ein Vergleich von Kernsets Blockbibliothek mit zwei Ihrer schwierigsten Kunden-Websites. Frühzugang anfragen - jede Nachricht liest ein Mensch.