Redakteur:innen verloren keine Technik – sie verloren den Spiegel ihrer Arbeit. Headless gibt ihn zurück, wenn man sie mitbauen lässt.
Redaktionelle Arbeit hatte immer eine sichtbare Grundeinheit: die Seite. Text schreiben, Bild platzieren, Zwischenüberschrift verschieben, Ergebnis im Browser prüfen. Passt. Sieht aus wie gewollt. Weiter zum nächsten Stück. So war es im Print, so war es im Web, solange es hauptsächlich aus Browserfenstern bestand.
WYSIWYG – What You See Is What You Get – war das technische Rückgrat dieser Arbeitsweise. Man sah, was die Leser:innen sehen würden. Die Rückmeldung war unmittelbar, die Kontrolle spürbar. Was dabei entstand, wird selten benannt, weil es so selbstverständlich wirkt: Vertrauen in das eigene Werkzeug. Die Gewissheit, dass zwischen Eingabe und Ergebnis kein Graben liegt.
Dieses Modell funktioniert nicht mehr. Nicht, weil es schlecht war. Sondern weil sich die Welt verändert hat, in die hinein veröffentlicht wird. Ein Inhalt, der nur auf einer Seite existiert, kommt in einer Welt aus Apps, Sprachassistenten, Smartwatches, Digital Signage und Social-Media-Kanälen an den meisten Orten nicht an. Die Seite, einst der Rahmen für alles, ist zu einem von vielen Ausgabeformaten geworden. Oft nicht einmal zum wichtigsten.
Was aber geschieht mit denen, die gelernt haben, in Seiten zu denken?
Die technische Verschiebung lässt sich nüchtern beschreiben. In einem Headless CMS wird Inhalt nicht mehr als formatierter Text auf einer Seite erfasst, sondern als strukturiertes Objekt. Ein Artikel ist kein Fließtext mit eingebetteten Bildern mehr. Er ist ein Datensatz mit Feldern: Titel, Teaser, Autor:in, Kategorie, Hauptbild mit Alternativtext, Textabschnitte mit definierten Typen, verwandte Inhalte als Referenzen. Man schreibt nicht mehr auf etwas. Man füllt etwas aus.
Das klingt nach einem kleinen Unterschied. Wer es einmal erlebt hat, weiß, dass es ein fundamentaler ist.
In diesem Moment sehen Redakteur:innen nicht, wie ihr Inhalt jemals aussehen wird. Nicht auf der Website. Nicht in der App. Nicht im Newsletter. Sie sehen ein Formular. Felder. Strukturen. Und sie müssen darauf vertrauen, dass das, was sie dort eingeben, irgendwo anders – in einem System, das sie nicht kontrollieren und oft nicht verstehen – zu etwas Sinnvollem zusammengesetzt wird.
Die neuen Anforderungen sind erheblich. Man muss Taxonomien verstehen – also wissen, warum eine bestimmte Verschlagwortung darüber entscheidet, ob ein Inhalt auf der Startseite erscheint oder in einer App ausgespielt wird. Man muss Metadaten pflegen, nicht als lästige Pflichtübung, sondern als integralen Teil der Arbeit. Man muss die Konventionen des Content-Modells kennen: Welches Feld dient welchem Zweck? Warum gibt es drei verschiedene Textlängen für den Teaser? Warum darf das Bild keine eingebettete Schrift enthalten?
Und man muss etwas lernen, das dem bisherigen Berufsbild fremd ist: Multi-Channel-Denken. Ein Inhalt, viele Ausgaben. Was man schreibt, muss auf einem Smartphone genauso funktionieren wie auf einem Desktop, in einem Newsletter, in einer Push-Benachrichtigung. Das ist keine Frage der Formulierung allein. Es ist eine Frage der Architektur.
Die Zahlen bestätigen diese Verschiebung. Nahezu die Hälfte der befragten Organisationen arbeitet mit zwei bis drei verschiedenen Content-Management-Systemen gleichzeitig – getrieben durch Omnichannel-Anforderungen. Der Engpass ist dabei nicht technischer Natur: 38 Prozent nennen fehlendes Know-how in der Strukturierung von Inhalten als eines der größten Hindernisse bei CMS-Umstellungen. Fast vier von zehn Organisationen scheitern nicht an der Architektur. Sie scheitern daran, dass niemand den Beteiligten erklärt hat, wie man in Bausteinen denkt statt in Dokumenten.
Die Verschiebung von der Seite zum Modul, vom fertigen Dokument zum komponierbaren Baustein – sie ist technisch längst vollzogen. In den Köpfen, in den Arbeitsroutinen, in den Redaktionsräumen oft nicht.
Hier lohnt es sich, genauer hinzusehen.
Eine Redakteurin – sie steht für viele – hat seit fünfzehn Jahren Inhalte für ein mittelgroßes Medienunternehmen produziert. Sie hat mit Print angefangen, ist ins Digitale gewechselt, hat drei CMS-Wechsel mitgemacht. Beim letzten Wechsel, dem auf ein Headless-System, hat sie zum ersten Mal nicht verstanden, was sie verloren hat.
Es war nicht die Technik. Die Eingabemasken waren sogar aufgeräumter als zuvor. Es war die Tatsache, dass sie einen Artikel schrieb, auf Speichern drückte – und dann nichts sah. Keine Seite. Kein Layout. Kein Bild neben dem Text. Nur die Bestätigung, dass ein Datensatz gespeichert wurde.
Was verliert jemand, der nicht mehr sehen kann, was er gerade geschrieben hat?
Es ist leicht, diese Frage als sentimental abzutun. Aber der Rückkanal zwischen Eingabe und Ergebnis – das Sehen dessen, was man geschaffen hat – ist kein Komfort. Er ist ein Teil des Denkens. Schreibende Menschen denken mit ihren Augen. Sie korrigieren, weil etwas falsch aussieht. Sie entscheiden, weil etwas stimmig wirkt. Nimmt man ihnen die Sichtbarkeit, nimmt man ihnen ein Werkzeug des Urteilens.
Über die Hälfte aller CMS-Nutzer:innen – 52 Prozent – bezeichnen visuelle Bearbeitungsmöglichkeiten als unverzichtbar für ihre Arbeit. Das ist keine Vorliebe. Das ist ein Signal. Ebenso viele beklagen fehlenden technischen Support bei der Einführung neuer Systeme, 40 Prozent fehlen geeignete Vorlagen und Strukturhilfen, 37 Prozent berichten von unzureichendem Onboarding.
Die vielleicht bezeichnendste Zahl: 74 Prozent der Organisationen erwarten von neuen CMS-Systemen Produktivitätsgewinne. Aber nur 9 Prozent haben Trainingsprogramme aufgesetzt, um diese Gewinne zu ermöglichen. Drei Viertel hoffen. Weniger als jeder Zehnte tut etwas dafür, dass die Hoffnung Grund hat. Die Kluft zwischen dem, was man sich von einem Werkzeug verspricht, und dem, was man tut, damit Menschen es nutzen können, ist so groß, dass man sie kaum übersehen kann. Und doch wird sie übersehen – mit einer Zuverlässigkeit, die beinahe systematisch wirkt.
„Ein CMS ist kein Backend-Problem. Es ist der Arbeitsplatz von Menschen, die jeden Tag Inhalte verantworten. Wenn wir deren Perspektive nicht von Anfang an mitdenken, bauen wir Werkzeuge, die technisch funktionieren und menschlich scheitern."
— Marc Oliver Schürmann, Senior Principal UX, Triplesense Reply
Was das mit Redakteur:innen macht, zeigt sich in der Verlangsamung. In der Content Velocity, die sinkt, weil jeder Inhalt länger dauert – nicht weil das System langsam wäre, sondern weil die Menschen unsicher sind. Ein Zögern vor dem Klick. Ein Nachfragen bei der Kollegin, die es vielleicht weiß. Es zeigt sich in der Fluktuation, weil gute Redakteur:innen Unternehmen verlassen, in denen sie das Gefühl haben, gegen ihre Werkzeuge zu arbeiten statt mit ihnen. Hinter den Worten zu teuer, zu kompliziert liegt etwas, das schwerer wiegt: das Gefühl, nicht mehr gemeint zu sein. Die Erfahrung, dass ein System für Entwickler:innen gebaut wurde und man selbst die Person ist, an die zuletzt gedacht wurde. Wenn überhaupt.
Man könnte sagen: Das Werkzeug hat seine Benutzer:innen vergessen.
Es wäre unehrlich, im Verlust stehenzubleiben. Die Veränderung bringt nicht nur Verluste. Sie bringt neuen Einfluss, neuen Gestaltungsspielraum, neue Relevanz – aber nur, wenn die Rollen sich bewusst weiterentwickeln.
Die klassischen Redakteur:innen – Menschen, die schreiben, redigieren, kuratieren und publizieren – werden nicht verschwinden. Aber neben sie tritt eine Figur, die es vor zehn Jahren nicht gab: der:die Content Operator:in. Jemand, der nicht nur Inhalte schafft, sondern versteht, wie diese Inhalte durch Systeme fließen. Der weiß, welche Taxonomie welchen Kanal bedient. Der ein Content-Modell lesen kann wie Architekt:innen einen Grundriss.
Das ist nicht die Ablösung der Redakteur:innen durch Techniker:innen. Es ist die Erweiterung des redaktionellen Profils um strukturelles Denken. Erhebungen unter Medienhäusern bestätigen diesen Trend: Die Nachfrage nach Kompetenzen in Produkt, Daten und Engineering wächst spürbar, während die klassischen Kernfähigkeiten – Sprachgefühl, Urteilsvermögen, Themengespür – ihren Wert behalten. Was entsteht, sind hybride Rollenprofile, in denen beides zusammenkommt.
Damit diese Profile entstehen können, braucht es etwas, das in vielen Organisationen fehlt: klare redaktionelle Leitlinien für strukturierte Inhalte. Wie lang darf ein Teaser sein? Welche Bildformate sind zulässig? Welche Felder sind Pflicht, welche optional – und warum? Solche Guidelines existieren in den meisten Redaktionen für Sprache und Stil. Für Struktur existieren sie selten. Das ist eine Lücke, und sie lässt sich schließen – wenn man sie als redaktionelle Aufgabe begreift und nicht als technische.
Dazu gehört eine neue Form der Zusammenarbeit: die zwischen Redakteur:innen und Content-Architekt:innen. Wer modelliert die Inhaltstypen? Wer entscheidet, welche Felder ein Artikel hat? In vielen Organisationen liegt diese Entscheidung bei Entwicklungsteams – oft aus Pragmatismus, manchmal aus Unachtsamkeit. Die Folge sind Modelle, die technisch elegant und redaktionell unbenutzbar sind. Wenn Redakteur:innen in die Modellierungsphase einbezogen werden, entstehen Strukturen, die nicht nur skalierbar sind, sondern auch schreibbar. Das ist ein Unterschied, den man unterschätzt, bis man ihn erlebt hat.
Das CMS selbst verändert dabei seinen Charakter. Es ist nicht mehr nur ein Werkzeug zum Editieren, sondern wird zur Plattform – zur Qualitätsinfrastruktur, in die Prozesse wie Faktenprüfung, Freigabe und Übersetzungsmanagement eingebaut werden können. Wer das CMS als Plattform begreift, begreift auch, dass die Redaktion nicht nur Nutzer:in dieses Systems ist, sondern seine wichtigste Stakeholderin.
Bisher war viel von Schwierigkeiten die Rede. Wahr, aber nicht die ganze Wahrheit. Es gibt Headless-Umgebungen, die redaktionelle Arbeit nicht erschweren, sondern spürbar erleichtern. Der Unterschied liegt in einer einzigen Frage: Hat jemand an die Menschen gedacht, die damit arbeiten?
Das Offensichtlichste sind Preview-Mechanismen und visuelles Feedback. Wenn Redakteur:innen in einem strukturierten Eingabeformular arbeiten, aber in Echtzeit sehen können, wie ihr Inhalt aussehen wird, schließt sich der Rückkanal, der in rein formularbasierten Systemen gekappt ist. Bei Octopus Energy führte genau das dazu, dass ein Rollout ohne jedes Training gelang – Veröffentlichungszeit sank um bis zu zwei Tage, Anfragen an die Entwicklung gingen um zwei Drittel zurück.
„Visual Editing enables us to do a rollout with zero training. Editors just click on what they want to change." — Senior Front-end Developer, Octopus Energy
Die wirtschaftliche Dimension ist messbar: Eine Forrester-Studie beziffert den ROI einer führenden Headless-Plattform auf 272 Prozent bei Amortisierung in unter sechs Monaten.
Gute Headless-Umgebungen erkennt man nicht an ihren Datenblättern, sondern daran, wie die Menschen damit arbeiten. Sie sind strukturiert und trotzdem schreibbar – ihre Content-Modelle sind klar genug für Maschinen und intuitiv genug für Menschen, mit verständlichen Feldbezeichnungen und Hilfestellungen dort, wo man sie braucht. Sie bieten einen Rückkanal, der die Verbindung zwischen Eingabe und Ergebnis wiederherstellt: Live-Previews, visuelle Editoren, kanalspezifische Vorschauen – alles, was aus einem blinden Formular wieder einen Arbeitsplatz macht, an dem Urteilsvermögen möglich ist. Und sie beziehen Redakteur:innen früh ein – nicht als Testpersonen nach dem Launch, sondern als Mitgestaltende in der Modellierungsphase. Wer die Struktur mitbaut, versteht sie. Wer sie nur vorgesetzt bekommt, wehrt sich – oder resigniert. Beides ist teuer. Aber die Resignation ist teurer, weil man sie länger nicht bemerkt.
Exzellente redaktionelle Erfahrung ist kein Luxus. Sie ist eine wirtschaftliche Notwendigkeit.
Was verlieren Redakteur:innen durch Headless – und was gewinnen sie? Sie verlieren die Unmittelbarkeit. Sie gewinnen Reichweite, Konsistenz, Skalierbarkeit – wenn sie die neue Arbeitsweise verstehen. Verständnis entsteht nicht durch Schulungsfolien. Es entsteht durch Beteiligung.
Wie sollte ein Onboarding aussehen? Nicht als einmaliges Training, sondern als begleiteter Übergang. Mit Raum für die Frage: Was fällt dir jetzt schwerer als vorher – und warum?
Welche Fähigkeiten brauchen Redakteur:innen in zehn Jahren? Strukturelles Denken, taxonomisches Verständnis, die Fähigkeit, mit Content-Architekt:innen auf Augenhöhe zu sprechen. Und: dieselben Fähigkeiten wie heute — Sprachgefühl, Haltung, das Gespür dafür, wann ein Satz stimmt.
Am Ende ein Bild. Dieselbe Redakteurin, derselbe Schreibtisch. Sie hat die Felder gefüllt, die Taxonomie gewählt, die Metadaten gepflegt. Sie drückt auf Veröffentlichen. Dann öffnet sie einen zweiten Tab, ruft die Website auf – und findet ihren Artikel. In einem Layout, das sie nicht gemacht hat. Mit Abständen, die jemand anders bestimmt hat.
Aber der Text ist gut. Die Struktur trägt. Der Inhalt erreicht Menschen auf Kanälen, die sie selbst nie bedient hat.
Sie hat keine Seite mehr. Aber sie hat etwas, das weiter reicht als jede Seite es je konnte.
Die Frage ist, ob ihr das jemand gesagt hat.
Content als Betriebssystem heißt, dass wir die Infrastruktur genauso ernst nehmen wie den Inhalt — und die Menschen, die damit arbeiten, erst recht. Dieser Text hat auf den Bildschirm der Redakteur:innen geschaut: Kontrollverlust, Formular statt Layout, Speichern ins Nichts.
Die Architektur ist bereit. Die Organisation meistens nicht. Im nächsten Teil drehen wir die Perspektive: Was Redakteur:innen als verschwundene Kontrolle erleben, erleben Leser:innen als verschwundenen Zusammenhang — abgeschnittene KI-Zitate, dekontextualisierte Snippets in Feeds, Inhalte ohne Autor:in, ohne Datum, ohne Herkunft. Was für Systeme Freiheit bedeutet, bedeutet für Menschen Orientierungsverlust.
Du hast bis hier gescrollt, durch einen Text über den Graben zwischen Eingabe und Ergebnis — und das Einzige, was du gesehen hast, war ein Formular aus Absätzen. Ob du dem Ergebnis vertraust, entscheidest du selbst. Genau darum ging es.
