Field Note: Warum ich die Technologie erst nach dem Redaktionsmodell auswähle

Ich beginne nicht mit der Systemauswahl

Wenn ich ein digitales Projekt plane, entscheide ich nicht zuerst, ob es WordPress, Astro, Payload, Ghost oder eine statische Website wird. Ich frage zuerst, wie die Inhalte entstehen und gepflegt werden sollen. Die Technologie kommt danach.

Das klingt selbstverständlich, wird in der Praxis aber leicht umgedreht. Ein System ist bekannt, ein Werkzeug wirkt passend oder eine Architektur verspricht Vorteile. Dann sucht man nach Gründen, das Projekt darin unterzubringen. Ich versuche, diesem ersten Impuls nicht zu folgen. Denn eine Technologie kann viele Dinge gut können und trotzdem schlecht zu der Redaktion passen, die später mit ihr arbeiten muss.

Mich interessiert deshalb zunächst nicht die Feature-Liste. Mich interessiert der tatsächliche Arbeitsalltag: Wer pflegt Inhalte? Wie oft passiert das? Welche Inhalte gibt es? Sind sie überwiegend frei formuliert oder bestehen sie aus wiederkehrenden, klar unterscheidbaren Angaben? Braucht es Vorschau, Rollen, Freigaben oder einen bestimmten Umgang mit Medien?

Was ich zuerst prüfe: Nicht, welches System am meisten kann, sondern welche redaktionellen Aufgaben regelmäßig anfallen und wer sie erledigt.

Das Redaktionsmodell ist mehr als ein Eingabeformular

Mit Redaktionsmodell meine ich nicht nur die Frage, ob ein Textfeld groß oder klein ist. Ich meine die Verbindung aus Inhaltstypen, Zuständigkeiten und Arbeitsabläufen. Was wird veröffentlicht? Welche Angaben gehören zusammen? Was darf verändert werden? Und woran erkennt die Redaktion, dass ein Inhalt bereit für die Veröffentlichung ist?

Bei einem frei geschriebenen Beitrag kann eine Redaktion vor allem einen guten Schreib- und Veröffentlichungsprozess brauchen. Bei Inhalten mit wiederkehrenden Eigenschaften muss ich zusätzlich überlegen, welche Angaben einzeln erfasst und später wiederverwendet werden sollen. Wenn mehrere Personen unterschiedliche Aufgaben haben, kommen Rollen und Freigaben hinzu. Wenn Inhalte erst geprüft werden sollen, bevor sie öffentlich erscheinen, muss das im Ablauf vorkommen und darf nicht als nachträglicher Sonderfall behandelt werden.

Diese Fragen verändern, was ich unter einer passenden Lösung verstehe. Ein System ist nicht schon deshalb gut, weil Inhalte darin gespeichert werden können. Es muss die tatsächliche Arbeit verständlich abbilden. Wenn ein Redaktionsmodell unklar ist, wird die Unklarheit häufig in Eingabemasken, Sonderregeln oder manuelle Absprachen verlagert. Das Werkzeug sieht dann vielleicht fertig aus, aber die Arbeit bleibt umständlich.

Ich versuche, das Modell so konkret zu machen, dass sich Entscheidungen prüfen lassen: Welche Arten von Inhalten gibt es? Welche Angaben sind Pflicht? Welche Beziehungen zwischen Inhalten sind wichtig? Wer darf etwas anlegen, ändern oder freigeben? Und was muss eine Person sehen, bevor sie eine Änderung veröffentlicht?

Das sind keine Fragen, die ich unabhängig von der Technik für immer beantworten muss. Aber ich brauche eine belastbare erste Antwort, bevor ich die Technik auswähle. Sonst entscheide ich über eine Oberfläche, ohne zu wissen, welche Arbeit sie unterstützen soll.

Drei Projekte, drei unterschiedliche redaktionelle Formen

Wie stark sich das Redaktionsmodell auf die Architektur auswirkt, sehe ich in unterschiedlichen Projekten. Garten 1x1 wurde von WordPress zu Astro migriert. Die Inhalte sind dort nicht nur eine Sammlung frei formulierter Seiten: Content Collections bilden unter anderem Pflanzen, Probleme, Aufgaben, Bereiche, Regionen und Ziele ab. Dazu kommen mehrere hundert Pflanzenprofile. Für mich zeigt das, wie wichtig es ist, wiederkehrende Inhalte als solche zu erkennen, bevor ich über die passende Auslieferung nachdenke.

pfwi.de steht für eine andere Form. Dort liegen alle redaktionellen Typen in einer einzigen Content Collection, und Prüfstatus, Aktualisierungstyp und Prüftermin stehen im Frontmatter jedes Beitrags. Das Beispiel erinnert mich daran, dass nicht jede redaktionelle Website ein umfangreiches, individuell modelliertes Backend braucht. Manchmal liegt die wichtige Arbeit eher darin, die redaktionellen Regeln so festzulegen, dass das Publishing-System sie tragen kann, statt zusätzliche Komplexität einzuführen.

Bei Wendewerk ist die redaktionelle und fachliche Struktur deutlich ausgeprägter: Die WordPress-Plattform verarbeitet Krankenkassen- und Leistungsdaten, nutzt ein Datenmodell in ACF-Feldern und kennt Rollen für Krankenkassen, Experten, Präventionsanbieter und Versicherte. KI-gestützt extrahierte Satzungstexte werden vor dem Zusammenführen in einem Staging geprüft. Das ist nicht einfach „Content einpflegen“. Es gibt unterschiedliche Beteiligte, strukturierte Informationen und einen Prüfweg, der Teil des Systems sein muss.

Ich leite daraus keine Rangliste der Technologien ab. Die Projekte beantworten nicht dieselbe Frage und brauchen deshalb auch nicht dieselbe Form. Sie helfen mir vielmehr, die eigene Frage schärfer zu stellen: Welche redaktionelle Arbeit soll das System tragen – und welche Regeln müssen darin sichtbar werden?

Erst dann vergleiche ich die Technologien

Wenn das Redaktionsmodell klarer ist, kann ich die Optionen sinnvoller betrachten. WordPress, Astro, Payload, Ghost oder eine statische Lösung sind für mich keine Ausgangspunkte, die ich auf jedes Projekt anwende. Sie sind mögliche Antworten auf Anforderungen, die ich vorher verstehen muss.

Dabei achte ich darauf, nicht nur den Zustand am Veröffentlichungstag zu betrachten. Ein System wird regelmäßig gepflegt, erweitert und manchmal von anderen Personen übernommen. Deshalb frage ich auch, ob die Inhalte im Alltag gut bearbeitet werden können, ob Zuständigkeiten verständlich bleiben und ob die nötigen Prüfungen in den Ablauf passen. Ein technisch elegantes Ergebnis hilft wenig, wenn die Redaktion für einfache Änderungen Umwege gehen muss.

Umgekehrt sollte ich auch keine Oberfläche oder Funktion einplanen, nur weil sie in einem System verfügbar ist. Wenn Inhalte nicht regelmäßig geändert werden und kein redaktioneller Ablauf dafür nötig ist, kann ein umfangreiches CMS mehr Arbeit erzeugen als lösen. Wenn Inhalte stark strukturiert sind oder mehrere Rollen zusammenarbeiten, reicht eine einfache Publikationslogik möglicherweise nicht aus. Entscheidend ist nicht, ob ein System abstrakt leistungsfähig ist, sondern ob seine Arbeitsweise zum Modell passt.

Inzwischen versuche ich, diese Entscheidung als Folge von Fragen zu behandeln, nicht als Geschmacksfrage. Ich kläre zuerst Inhalt und Pflege. Danach prüfe ich, welche Abläufe das System unterstützen muss. Erst dann vergleiche ich die technischen Möglichkeiten und ihre Konsequenzen für Entwicklung, Betrieb und spätere Änderungen.

Das lässt auch Raum für Unsicherheit. Nicht jede Antwort muss zu Beginn endgültig sein. Aber ich möchte wissen, welche Annahmen meiner Entscheidung zugrunde liegen. Dann kann ich sie später überprüfen, statt eine frühe Technologieentscheidung mit immer neuen Ausnahmen zu verteidigen.

Was sich dadurch verändert

Der wichtigste Unterschied liegt für mich nicht darin, dass ich immer die „richtige“ Technologie finde. Es ist, dass ich anders über Passung spreche. Statt ein System mit allgemeinen Stärken zu begründen, kann ich benennen, welche konkrete redaktionelle Aufgabe es unterstützt und welche Anforderungen es nicht abdeckt.

Das macht Gespräche präziser. Wenn sich herausstellt, dass mehrere Personen Inhalte nach unterschiedlichen Regeln pflegen, wird das nicht erst beim Bau der Oberfläche sichtbar. Wenn ein Inhalt aus vielen wiederkehrenden Angaben besteht, muss ich nicht so tun, als wäre er nur ein langer Text. Und wenn eine einfache Veröffentlichungsform reicht, muss ich keine größere Architektur rechtfertigen.

Auch meine eigenen Vorlieben treten dadurch etwas zurück. Ich arbeite gerne an Datenmodellen und technischen Systemen, aber nicht jede Website braucht ein spezialisiertes Backend oder eine individuelle Lösung. Umgekehrt ist ein vertrautes CMS nicht automatisch die passende Antwort, nur weil sich damit schnell ein erster Entwurf bauen lässt.

Ein gutes Redaktionsmodell nimmt der Technologieentscheidung nicht jede Schwierigkeit. Es macht aber sichtbar, worüber ich überhaupt entscheide. Und wenn sich das Modell ändert, kann ich besser erkennen, welche Teile der Architektur davon betroffen sind.

Weiterführend

• Content-Modell entwickeln: Von Seiten zu strukturierten Inhalten
• CMS auswählen: 12 Kriterien, die wichtiger sind als Feature-Listen
• Astro für Content-Sites: Wann statische Auslieferung die bessere Architektur ist