Website ohne CMS: Wann Dateien und Git die bessere Wahl sind

Ein CMS ist nicht automatisch die einfachste Lösung für eine Website. Wenn Inhalte selten geändert werden, nur wenige Personen daran arbeiten und die Seiten einer klaren Struktur folgen, kann ein Dateisystem mit einem kontrollierten Veröffentlichungsprozess ausreichen. Ein CMS wird wichtiger, sobald Fachbereiche regelmäßig Inhalte pflegen, mehrere Rollen beteiligt sind oder Freigaben im System stattfinden müssen.

Die Entscheidung betrifft deshalb nicht nur die Technik. Geschäftsführung, Projektverantwortliche und technische Leitung sollten zuerst klären, wie Inhalte entstehen, wer sie ändert und wie Änderungen geprüft werden. Dieser Beitrag ordnet die wichtigsten Kriterien ein und vergleicht drei Ansätze: Inhalte im Repository, ein Git-basiertes CMS und ein klassisches CMS. Die zentrale Aussage: Wählen Sie das kleinste System, das Ihren tatsächlichen Redaktionsprozess zuverlässig unterstützt – nicht das System mit den meisten Funktionen.

Kurz gesagt

Eine Website ohne CMS ist sinnvoll, wenn Inhalte selten wechseln, ihre Struktur überschaubar ist und technische Mitarbeitende Änderungen sicher veröffentlichen können. Dateien im Repository bieten dann einen direkten, nachvollziehbaren Workflow. Ein Git-basiertes CMS ergänzt diesen Ansatz um eine redaktionelle Oberfläche, ohne die Inhalte aus dem Repository herauszulösen. Sobald viele nicht technische Beteiligte Inhalte laufend pflegen oder Freigaben und Rollen zuverlässig abgebildet werden müssen, ist ein klassisches CMS meist die passendere Wahl.

Ausgangslage

Ein Content-Management-System löst konkrete Aufgaben: Inhalte erfassen, strukturieren, bearbeiten, prüfen und veröffentlichen. Es verursacht aber auch laufende Arbeit. Das System muss betrieben, aktualisiert und abgesichert werden. Redaktionsoberfläche, Datenmodell und Veröffentlichungsprozess müssen zur Website passen.

Bei kleinen Websites wird ein CMS oft gewählt, weil es als Standard gilt. Das kann sinnvoll sein, selbst wenn nur wenige Seiten existieren: Entscheidend ist, ob die zuständigen Personen Inhalte eigenständig ändern sollen. Umgekehrt kann ein CMS unnötig komplex sein, wenn jede Änderung ohnehin durch ein Entwicklungsteam läuft und nur selten stattfindet.

Die Alternative „ohne CMS“ bedeutet nicht automatisch „ohne Struktur“. Inhalte können als Markdown- oder Textdateien organisiert, anhand eines Schemas geprüft und über einen Build-Prozess veröffentlicht werden. Dafür müssen Zuständigkeiten, Vorschau und Veröffentlichung ebenfalls geregelt sein. Die Architektur spart nur dann Aufwand, wenn sie zum tatsächlichen Arbeitsablauf passt.

Entscheidungskriterien

1. Wie häufig ändern sich Inhalte?

Betrachten Sie nicht nur, wie oft die Website insgesamt aktualisiert wird. Fragen Sie, wie oft einzelne Inhalte geändert werden und ob Änderungen zeitkritisch sind.

• Seltene Änderungen: Wenn neue Inhalte nur bei einem Relaunch, einer fachlichen Überarbeitung oder einer gelegentlichen Ergänzung entstehen, können Dateien im Repository ausreichen.
• Regelmäßige redaktionelle Arbeit: Wenn laufend Meldungen, Artikel, Produktinformationen oder Landingpages erscheinen, ist eine Redaktionsoberfläche oft hilfreicher.
• Häufige, dringende Änderungen: Wenn Inhalte kurzfristig angepasst werden müssen, sollte der Veröffentlichungsweg ohne unnötige technische Abhängigkeiten funktionieren.

Frequenz allein entscheidet nicht. Eine kleine Zahl von Änderungen kann hohe Anforderungen an Freigaben oder Aktualität haben. Umgekehrt kann ein umfangreicher, aber stabiler Informationsbestand gut dateibasiert funktionieren.

2. Wer bearbeitet und veröffentlicht Inhalte?

Klären Sie, ob Änderungen ausschließlich durch Entwicklerinnen und Entwickler erfolgen oder ob Fachredaktion, Kommunikation, Produktteam oder externe Beteiligte Inhalte selbst pflegen sollen.

Dateien im Repository setzen meist voraus, dass Beteiligte mit dem vorgesehenen Versionskontroll- und Veröffentlichungsprozess umgehen können – oder dass eine technische Person Änderungen übernimmt. Ein Git-basiertes CMS kann die Bearbeitung für Redaktionen zugänglicher machen, während die Inhalte weiterhin in einem Git-Repository verwaltet werden.

Ein klassisches CMS ist dann naheliegend, wenn mehrere nicht technische Personen regelmäßig arbeiten und die Website nicht für jede Inhaltsänderung von Entwicklungskapazität abhängig sein soll. Prüfen Sie dabei auch, ob die Benutzeroberfläche die tatsächlich benötigten Aufgaben einfach abbildet.

3. Wie stabil und wiederholbar ist die Inhaltsstruktur?

Dateien eignen sich gut, wenn Inhalte klar typisiert sind und sich in einem verständlichen Format beschreiben lassen. Ein Artikel kann etwa Titel, Datum, Zusammenfassung und Text enthalten. Wenn Datensätze viele Beziehungen, Varianten oder abhängige Felder haben, reicht eine Sammlung einfacher Dateien möglicherweise nicht mehr.

Entscheidend ist, ob Inhalte als Seiten oder als strukturierte Datensätze verstanden werden müssen. Eine Website mit mehreren Content-Typen, Filtern, Beziehungen und dynamischen Ansichten braucht ein bewusstes Datenmodell – unabhängig davon, ob die Eingabe über ein CMS oder Dateien erfolgt. Dazu passt der Beitrag Content-Modell entwickeln.

4. Welche Freigaben und Prüfungen sind nötig?

Ein Versionsverlauf ist nicht dasselbe wie ein Redaktionsprozess. Git kann Änderungen nachvollziehbar machen und eine Prüfung vor der Veröffentlichung ermöglichen. Es ersetzt aber nicht automatisch eine verständliche Vorschau, eine redaktionelle Freigabe oder eine klare Rollenverteilung.

Fragen Sie deshalb konkret:

• Muss eine zweite Person Inhalte vor der Veröffentlichung prüfen?
• Braucht die Redaktion eine Vorschau, die der späteren Seite entspricht?
• Gibt es Entwürfe, geplante Veröffentlichungen oder mehrere Freigabestufen?
• Müssen unterschiedliche Rollen verschiedene Inhalte bearbeiten dürfen?

Je komplexer diese Abläufe sind, desto wichtiger wird eine Oberfläche, die den Prozess explizit unterstützt. Freigaben nur informell per Nachricht oder E-Mail zu organisieren, kann funktionieren, sollte aber als bewusste Prozessentscheidung behandelt werden.

5. Wer trägt den laufenden Betrieb?

Ein dateibasierter Ansatz vermeidet nicht jede technische Verantwortung. Build-Prozess, Abhängigkeiten, Vorschau und Veröffentlichung müssen weiterhin funktionieren. Das Team braucht außerdem eine klare Zuständigkeit für Änderungen am Schema und an der Website.

Ein CMS verlagert einen Teil der Arbeit in Betrieb, Updates, Rechteverwaltung und Administration. Ein Git-basiertes CMS bringt sowohl Anforderungen an die Redaktionsoberfläche als auch an Repository und Build-Prozess mit sich. Vergleichen Sie daher nicht nur Lizenz- oder Einrichtungsaufwand, sondern den gesamten Arbeitsweg von der Änderung bis zur geprüften Veröffentlichung.

Optionen

Inhalte als Dateien im Repository

Inhalte liegen als Markdown, JSON oder einem anderen geeigneten Dateiformat direkt im Projekt. Änderungen werden versioniert und über den Build-Prozess veröffentlicht. Das passt zu stabilen Websites mit klaren Inhaltsfeldern und einem Team, das den technischen Workflow zuverlässig bedienen kann.

Der Vorteil ist die enge Verbindung von Inhalt und Auslieferung: Änderungen lassen sich gemeinsam prüfen, versionieren und reproduzieren. Die Grenze liegt meist nicht in der Dateiform, sondern bei der Redaktion. Wenn viele Personen keine Repository-Werkzeuge nutzen können oder sollen, wird jede Änderung zu einer technischen Übergabe.

Git-basiertes CMS

Ein Git-basiertes CMS stellt eine redaktionelle Oberfläche bereit, während Inhalte weiterhin als Dateien in einem Repository gespeichert werden. Redaktionelle Änderungen können dadurch in einen Versions- und Freigabeprozess eingebunden werden.

Diese Option eignet sich, wenn die Datei- und Build-Architektur passt, aber die Bearbeitung im Repository für die Redaktion eine Hürde ist. Prüfen Sie vorab, ob Vorschau, Rollen, Veröffentlichungsprozess und verwendete Inhaltsformate zu Ihrem Alltag passen. Eine Oberfläche macht einen ungeeigneten Workflow nicht automatisch passend.

Klassisches oder API-basiertes CMS

Ein CMS ist meist die bessere Wahl, wenn Inhalte häufig und eigenständig durch mehrere Beteiligte gepflegt werden. Es kann Rollen, strukturierte Eingabe, Entwürfe und Veröffentlichungen an einem Ort zusammenführen. Bei komplexeren Inhalten kommt es besonders auf ein passendes Datenmodell an, nicht auf eine lange Funktionsliste.

Ein CMS muss nicht zwingend die Website selbst ausliefern. Bei einer getrennten Architektur kann das Frontend Inhalte über eine Schnittstelle beziehen. Ob sich diese Trennung lohnt, hängt davon ab, welche Systeme dieselben Inhalte benötigen und wie Vorschau, Betrieb und Schnittstellen abgesichert werden. Einen Überblick über diese Abwägung bietet CMS, Static Site oder Web-App.

Praxisbeispiel

Beim Projekt Garten 1x1 wurde eine Website von WordPress zu Astro migriert. Ein einmaliges TypeScript-Skript überführte einen WXR-Export in Markdown. Die Inhalte werden in Astro Content Collections anhand eines Zod-Schemas für verschiedene Typen wie Pflanzen, Probleme, Aufgaben und Regionen strukturiert.

Das Beispiel zeigt, dass eine Migration weg von einem klassischen CMS nicht bedeuten muss, Inhalte unstrukturiert abzulegen. Die Eignung eines solchen Modells hängt weiterhin davon ab, wer Inhalte bearbeitet und wie häufig sie geändert werden. Aus den verfügbaren Projektdaten lässt sich keine allgemeine Aussage über den Redaktionsprozess ableiten.

Typische Fehler

• CMS als Standard voraussetzen: Ein verbreitetes Werkzeug ist nicht automatisch die passende Lösung für einen selten veränderten Webauftritt.
• „Ohne CMS“ mit „ohne Prozess“ verwechseln: Auch dateibasierte Inhalte brauchen Zuständigkeiten, Prüfung und einen verlässlichen Veröffentlichungsweg.
• Nur die Zahl der Seiten betrachten: Umfang sagt wenig darüber aus, wie häufig Inhalte wechseln oder wie komplex Beziehungen und Freigaben sind.
• Repository-Zugang als Redaktionslösung behandeln: Versionskontrolle schafft Nachvollziehbarkeit, aber nicht automatisch eine für alle Beteiligten verständliche Oberfläche.
• Freigaben nachträglich ergänzen: Wenn Entwürfe, Vorschau oder Rollen wichtig sind, sollten sie vor der Architekturentscheidung berücksichtigt werden.
• Die spätere Pflege ausblenden: Ein kleiner Build-Prozess kann wartbar sein, braucht aber dokumentierte Zuständigkeiten und nachvollziehbare Änderungen.

Empfehlung

• Wenn Inhalte selten aktualisiert werden, eine stabile Struktur haben und ein technisches Team Änderungen übernimmt, verwenden Sie Dateien im Repository.
• Wenn die Inhalte dateibasiert bleiben sollen, aber redaktionelle Beteiligte eine Oberfläche benötigen, prüfen Sie ein Git-basiertes CMS.
• Wenn mehrere nicht technische Personen regelmäßig Inhalte pflegen, Freigaben benötigen oder eigenständig veröffentlichen sollen, wählen Sie ein CMS, das diese Abläufe tatsächlich unterstützt.
• Wenn Inhalte stark strukturiert, miteinander verknüpft oder über mehrere Oberflächen genutzt werden, definieren Sie zuerst das Datenmodell und entscheiden Sie danach über CMS, API oder Dateien.
• Wenn Änderungen zeitkritisch sind, aber nur wenige Personen beteiligt sind, bewerten Sie den gesamten Änderungsweg: Wer kann ihn ausführen, prüfen und im Fehlerfall zurücknehmen?

Die passende Lösung ist diejenige, bei der Inhaltspflege und Veröffentlichung mit den vorhandenen Zuständigkeiten zuverlässig funktionieren. Ein CMS ist ein Mittel dafür, keine Pflicht.

Checkliste

• Wie oft werden Inhalte tatsächlich geändert?
• Welche Änderungen müssen kurzfristig veröffentlicht werden?
• Wer erstellt, bearbeitet, prüft und veröffentlicht Inhalte?
• Können alle Beteiligten mit einem Repository-Workflow arbeiten?
• Welche Inhaltstypen und Beziehungen müssen abgebildet werden?
• Sind Vorschau, Entwürfe oder mehrstufige Freigaben erforderlich?
• Wer betreibt und wartet Build-Prozess oder CMS?
• Ist der gesamte Weg von der Änderung bis zur Veröffentlichung dokumentiert?

Häufige Fragen

Kann eine Website ohne CMS trotzdem viele Seiten haben?

Ja. Entscheidend ist nicht allein die Seitenzahl, sondern ob Inhalte strukturiert, effizient gepflegt und zuverlässig veröffentlicht werden können. Ein umfangreicher, stabiler Bestand kann dateibasiert organisiert sein.

Ist Markdown ein Ersatz für ein CMS?

Markdown ist ein Format für Inhalte, kein vollständiger Redaktionsprozess. Es kann Teil einer CMS-losen Architektur sein. Rollen, Vorschau und Freigaben müssen dann anderweitig geregelt werden.

Ist ein Git-basiertes CMS automatisch besser als ein klassisches CMS?

Nein. Es passt, wenn Repository, Build-Prozess und Redaktion zusammenarbeiten sollen. Wenn ein Team eine eigenständige Oberfläche, komplexe Rechte oder umfangreiche Redaktionsabläufe benötigt, kann ein klassisches CMS besser passen.

Weiterführend

• CMS, Static Site oder Web-App: Architektur für digitale Projekte wählen
• Static Site Generation: Wann statische Websites dynamischen Systemen überlegen sind
• Astro für Content-Sites: Wann statische Auslieferung die bessere Architektur ist
• CMS auswählen: 12 Kriterien, die wichtiger sind als Feature-Listen

Weiterführende Quellen

Diese offiziellen Dokumentationen und Standards vertiefen die behandelten Themen.

• Astro: Content Collections
• Astro: Why Astro?