Ein Content-Management-System verwaltet Inhalte unabhängig von ihrer Darstellung. Redakteure pflegen Texte, Bilder, Taxonomien und Veröffentlichungsstatus; Templates oder Komponenten erzeugen daraus die Webseite. Ob das fertige HTML bei jedem Aufruf, beim Deployment oder aus einem Cache entsteht, ist eine getrennte Architekturentscheidung.
Was beim Aufruf einer Webseite passiert
Der Browser löst den Domainnamen per DNS auf, baut eine verschlüsselte HTTPS-Verbindung zum Server auf und fordert eine Ressource an. Als Antwort erhält er typischerweise HTML sowie Verweise auf Stylesheets, JavaScript, Schriften und Bilder. Aus diesen Bestandteilen rendert er die Seite.
Das gilt unabhängig davon, ob der Inhalt aus WordPress, einer Markdown-Datei, einer API oder einer handgeschriebenen HTML-Datei stammt. Am Ende braucht der Browser Webstandards, kein CMS.
Was ein CMS leistet
Die Kernaufgabe eines CMS ist redaktionelle Organisation:
- strukturierte Inhaltstypen statt frei verteilter Dokumente,
- Medienverwaltung und wiederverwendbare Taxonomien,
- Rollen, Entwürfe, Freigaben und geplante Veröffentlichungen,
- Versionen und nachvollziehbare Änderungen,
- Trennung von Inhalt, Design und Ausgabekanal.
Ein Blogartikel besteht beispielsweise aus Titel, Beschreibung, Autor, Datum, Kategorie, Bild und Inhalt. Eine Komponente entscheidet, wie diese Felder auf der Startseite, im RSS-Feed oder auf der Artikelseite erscheinen. Der Inhalt muss dafür nicht dreimal gepflegt werden.
Monolithisch, Headless oder dateibasiert
Klassisches CMS
Systeme wie WordPress oder Drupal verwalten Inhalt und Darstellung in einer Anwendung. Das ist bequem, weil Redaktion, Plugins, Themes und Auslieferung eng integriert sind. Gleichzeitig wachsen Abhängigkeiten und Angriffsfläche mit jeder Erweiterung.
Headless CMS
Ein Headless CMS stellt Inhalte über eine API bereit. Ein separates Frontend rendert Webseite oder App. Das schafft Flexibilität für mehrere Kanäle, erhöht aber Integrations-, Vorschau- und Betriebsaufwand.
Dateibasiertes CMS
Bei Systemen wie Statamic oder Kirby können Inhalte in Dateien statt in einer klassischen Datenbank liegen. Das erleichtert Versionierung und Portabilität. Eine komfortable Redaktionsoberfläche ist trotzdem möglich.
Content im Repository
Technische Teams können Markdown oder MDX direkt mit dem Anwendungscode versionieren. ITextreme nutzt dieses Modell mit Next.js: Inhalte liegen strukturiert im Repository, Komponenten verantworten die Darstellung. Für viele unabhängige Redakteure oder komplexe Freigaben wäre dieses Modell weniger komfortabel.
Statisch und dynamisch sind kein Entweder-oder
Ein Static Site Generator erzeugt HTML vor der Veröffentlichung. Frameworks können einzelne Seiten statisch vorberechnen, andere bei Bedarf serverseitig rendern und Daten im Hintergrund aktualisieren. Suche, Formulare oder personalisierte Funktionen lassen sich dennoch ergänzen.
Statische Auslieferung bietet geringe Laufzeitkomplexität und gute Performance. Dynamisches Rendering ist sinnvoll, wenn Inhalte pro Anfrage aktuell oder personalisiert sein müssen. Entscheidend ist die Funktion, nicht das Etikett.
Auswahlkriterien
Vor einer Produktentscheidung sollten diese Fragen beantwortet sein:
- Wer erstellt, prüft und veröffentlicht Inhalte?
- Welche Inhaltstypen und Beziehungen gibt es?
- Werden mehrere Sprachen oder Ausgabekanäle benötigt?
- Welche Rechte, Freigaben und Protokolle sind erforderlich?
- Wie funktionieren Vorschau, Suche und Medienbearbeitung?
- Wer übernimmt Updates, Backups, Monitoring und Wiederherstellung?
- Lassen sich Inhalte vollständig und strukturiert exportieren?
Marktanteil und Pluginzahl sagen wenig darüber aus, ob ein System zum eigenen Redaktionsprozess passt.
Sicherheit und Betrieb
Ein CMS ist produktive Software. Kernsystem, Erweiterungen und Themes müssen gepflegt, nicht benötigte Funktionen entfernt und administrative Zugänge abgesichert werden. Backups sind erst dann belastbar, wenn eine Wiederherstellung getestet wurde.
Besondere Aufmerksamkeit verdienen Erweiterungen: Sie laufen häufig mit weitreichenden Berechtigungen und können die gesamte Anwendung gefährden. Wenige gut gepflegte Abhängigkeiten sind meist besser als ein Baukasten aus zwanzig Plugins.
Wann kein CMS nötig ist
Eine kleine, selten geänderte Webseite kann direkt aus Komponenten und Dateien entstehen. Ein CMS nur deshalb einzuführen, damit jemand einmal im Jahr eine Telefonnummer ändern kann, ist oft überzogen. Umgekehrt ist ein handgebautes System ohne redaktionelle Oberfläche unpraktisch, wenn mehrere Personen täglich Inhalte veröffentlichen.
Fazit
Ein CMS ist kein bestimmter Technikstapel, sondern eine Lösung für Inhaltsverwaltung. Die richtige Wahl verbindet den redaktionellen Prozess mit einer passenden Auslieferungsarchitektur. Erst kommen Inhalte, Rollen und Betrieb – danach das Produktlogo.
