Field Note: Warum ich Content und Technik nicht getrennt betrachte

Mein Blick kommt aus zwei Richtungen

Ich betrachte Content und Technik nicht getrennt, weil ich in meiner Arbeit immer wieder sehe, wie stark die eine Seite die andere bestimmt. Ich komme aus Kommunikationsdesign und Marketing und bin technisch tiefer geworden. Für mich ist das keine Abkehr vom Inhalt. Es ist eher eine längere Sicht auf denselben Inhalt: Was soll er leisten, wie muss er dafür strukturiert sein und wie wird er im System auffindbar und nutzbar?

Am Anfang steht oft ein konkreter Wunsch: Inhalte sollen verständlicher werden, eine Website soll besser auffindbar sein oder eine Suche soll zuverlässiger funktionieren. Mein erster Impuls war früher manchmal, direkt an der sichtbaren Stelle anzusetzen: einen Text überarbeiten, eine Seite ergänzen oder eine Funktion nachrüsten. Das kann richtig sein. Aber bevor ich loslege, frage ich inzwischen, ob das Problem wirklich dort sitzt.

Denn ein Text kann nur so gut wirken, wie ihn die umgebende Struktur trägt. Wenn zusammengehörige Inhalte nicht als solche erkennbar sind, wenn wichtige Merkmale nur irgendwo im Fließtext stehen oder wenn das Template sie nicht sinnvoll ausgibt, ist die Ursache nicht allein redaktionell. Dann ist ein Contentproblem oft auch ein Architekturproblem.

Der Inhalt läuft durch ein System

Ich denke Content nicht nur als fertige Seite, sondern als Ablauf. Eine vereinfachte Skizze sieht so aus:

Content → Struktur → Datenmodell → Template → Suche → interne Verlinkung → SEO

Jeder Schritt verändert, was mit dem Inhalt möglich ist. Die Struktur beschreibt, welche Arten von Inhalten es gibt und wie sie zusammenhängen. Das Datenmodell legt fest, welche Informationen getrennt und verlässlich erfasst werden. Das Template entscheidet, wie daraus eine Seite oder ein anderes Ausgabeformat wird. Suche und interne Verlinkung machen Beziehungen auffindbar. SEO hängt nicht erst am Ende als zusätzliche Schicht daran: Es wird von vielen dieser Entscheidungen mitgeprägt.

Das heißt nicht, dass jeder Inhalt ein kompliziertes Modell braucht. Im Gegenteil: Ich möchte keine Struktur einführen, nur weil sie technisch elegant aussieht. Entscheidend ist, ob sie eine echte redaktionelle oder funktionale Aufgabe löst. Manchmal reicht ein gut gepflegter Text. Manchmal braucht es klar getrennte Felder, definierte Inhaltstypen oder Beziehungen zwischen Einträgen. Die passende Lösung hängt davon ab, wie Inhalte erstellt, geprüft, kombiniert und gefunden werden sollen.

Was ich zuerst prüfe: Welche Information muss jemand erstellen oder verstehen – und an welcher Stelle im System wird sie dafür heute gespeichert, dargestellt und gefunden?

Wenn ein Contentproblem tiefer sitzt

Bei Vergessene Zivilisationen sind Quellen im Datenmodell verankert. Das ist für mich mehr als ein technisches Detail. Wenn eine Quelle zu einem Inhalt gehört, kann sie Teil davon sein, wie der Inhalt redaktionell eingeordnet und auf der Website dargestellt wird. Das Projekt führt außerdem Belegstufen für Inhalte. Damit wird eine wichtige inhaltliche Unterscheidung nicht nur im Text behauptet, sondern als strukturierte Information behandelt.

Daran interessiert mich die Verbindung: Eine redaktionelle Frage – worauf stützt sich diese Aussage und wie sicher ist sie? – bekommt eine technische Entsprechung. Das Datenmodell ersetzt keine redaktionelle Prüfung. Es kann aber dabei helfen, dass relevante Informationen nicht in beliebigen Textfeldern verschwinden und in der Darstellung berücksichtigt werden können.

Bei erlebe-nrw kommen Ausflugsziele aus mehreren Datenquellen zusammen. Bei jeder Angabe werden Quelle und Stand ausgewiesen. Auch hier ist die Herkunft der Information Teil der Inhaltsarbeit und nicht bloß ein technischer Importvermerk. Die Daten müssen in eine Form gebracht werden, in der sie sich auf der Website nutzen lassen. Gleichzeitig werden dünne Seiten per noindex ausgeschlossen. Das zeigt für mich, warum Umfang allein kein Qualitätsmerkmal ist: Eine große Menge an Datensätzen löst noch nicht die Frage, welche Seiten für Menschen tatsächlich hilfreich sind.

Aus diesen Beispielen leite ich keine allgemeine Pflicht zu einem bestimmten CMS oder Datenmodell ab. Sie zeigen vielmehr, dass konkrete redaktionelle Anforderungen manchmal technische Konsequenzen haben. Wenn Herkunft, Beziehungen, Filter oder Belegstatus wichtig sind, sollte das System diese Bedeutung nicht dem Zufall überlassen.

Technik ist Teil der redaktionellen Entscheidung

Ich spreche deshalb ungern von „Content hier“ und „Technik dort“, als wären das zwei unabhängige Arbeitsbereiche, die erst kurz vor dem Launch zusammenkommen. Natürlich braucht es unterschiedliche Kompetenzen. Aber die Entscheidungen greifen ineinander: Wer Inhalte modelliert, beeinflusst, was Redakteurinnen und Redakteure pflegen können. Wer Templates entwickelt, beeinflusst, welche Zusammenhänge sichtbar werden. Wer eine Suche plant, entscheidet mit, welche Eigenschaften überhaupt als Such- oder Filterkriterien taugen.

Dabei geht es nicht darum, jeden Inhalt zu automatisieren oder alles in Daten umzuwandeln. Struktur soll das Denken nicht ersetzen. Sie soll wiederkehrende Anforderungen verlässlich abbilden und unnötige Handarbeit vermeiden. Ein gutes Modell macht auch die Grenzen sichtbar: Welche Angaben sind bekannt? Was fehlt? Was ist eine eigenständige Information und was gehört nur in die Beschreibung?

Dasselbe gilt für SEO. Ich verstehe es nicht als nachträgliche Dekoration mit Suchbegriffen, sondern als eine der Folgen davon, wie Inhalte organisiert und miteinander verbunden sind. Eine klare Contentstruktur kann helfen, Themen und Beziehungen nachvollziehbar zu machen. Sie garantiert keine Sichtbarkeit. Aber wenn Inhalte im System schlecht unterscheidbar oder schwer auffindbar sind, lässt sich das nicht allein durch eine sprachliche Überarbeitung beheben.

Was sich an meinem Vorgehen verändert hat

Inzwischen gehe ich bei Contentproblemen einen Schritt zurück. Ich schaue mir nicht nur die betroffene Seite an, sondern frage, an welcher Stelle im Ablauf der Bruch entsteht. Liegt es am Inhalt? An seiner Struktur? Fehlt ein relevantes Feld oder eine Beziehung? Wird die Information im Template nicht ausgegeben? Findet die Suche sie nicht? Gibt es keinen sinnvollen Weg über interne Links?

Die Antwort kann weiterhin eine Textänderung sein. Oder eine Anpassung am Modell, an der Darstellung oder an der Suche. Wichtig ist, nicht vorschnell eine technische Lösung auf ein redaktionelles Problem zu setzen – und genauso wenig, ein Architekturproblem mit immer neuen Texten zu überdecken.

Ich versuche, die kleinste passende Änderung zu finden. Erst wenn klar ist, was sich ändern soll, lässt sich sinnvoll prüfen, ob die neue Struktur oder Darstellung ihren Zweck erfüllt. Für mich gehören diese Schritte zusammen: verstehen, verändern, überprüfen. Nicht als starres Verfahren, sondern als Haltung gegenüber einem System, das Inhalte nicht nur speichert, sondern auch ordnet und zugänglich macht.

Weiterführend: Content-Architektur, Sichtbarkeit beginnt in der Contentstruktur und das Projekt erlebe-nrw.

Meine Faustregel: Wenn ein Contentproblem wiederkehrt, prüfe ich nicht nur den Text. Ich verfolge den Inhalt von seiner Struktur und seinem Datenmodell bis zu Darstellung, Suche und interner Verlinkung.