Du brauchst nicht immer ein CMS: Ein Entscheidungsrahmen fuer moderne Websites

Als Remote-Webagentur in Nepal bauen wir eine Mischung aus Service-Websites, Marketing-Sites und Produkt-Web-Apps. Eine Frage kommt in fast jedem Projekt-Kickoff: "Brauchen wir ein CMS?" Die ehrliche Antwort: nicht immer. Viele Websites sind strukturell simpel, und ein CMS bringt neue operative Flaechen mit: Auth, Datenbanken, Permissions, Plugin-Risiko, Upgrade-Arbeit und Editorial-Training. Dieser Beitrag ist ein praktischer Entscheidungsrahmen, basierend auf dem, was sich gerade veraendert: Static-first-Stacks, reife Headless-CMS-Optionen und AI-gestuetzte Editing-Workflows.

Starte mit dem Job, den das "CMS" leisten soll

Wenn Menschen "CMS" sagen, meinen sie meistens eine (oder mehrere) dieser Aufgaben:

Einen Ort, an dem Nicht-Engineers Seiten aktualisieren koennen, ohne eine PR zu oeffnen.
Ein strukturiertes Modell fuer Content-Typen (Posts, Case Studies, Services, FAQs).
Editorial-Workflows: Drafts, Approvals, Scheduling, Rollen, Versionshistorie.
Content Ops: Redirects, interne Verlinkung, SEO-Felder, Media-Management.

Du brauchst vielleicht nur eine dieser Funktionen, nicht das komplette "traditionelle CMS-Buendel".

Das "du brauchst kein CMS"-Profil (die meisten Service-Sites)

Du brauchst wahrscheinlich kein vollwertiges CMS, wenn das meiste hiervon stimmt:

Content aendert sich nur gelegentlich (nicht taeglich).
Die Site besteht im Wesentlichen aus: Startseite, Services, About, Contact und einem Blog.
Dein Content-Modell ist flach (wenige Beziehungen).
Dein Team kommt damit klar, dass Content-Aenderungen wie Releases shipped werden.
Du willst vor allem vorhersehbaren HTML-Output statt Admin-Plugins.

In dem Fall passt ein Static-first-Ansatz (MDX/Markdown + typisierte Components + Build-Pipeline) oft sehr gut. Wenn du Next.js nutzt, kombinierst du das idealerweise mit einer starken technischen SEO-Baseline:

"Aber was ist mit Editing?" Die echte Grenze ist Workflow, nicht Technologie

Das staerkste historische Argument fuer ein CMS war Editing: "Unser Team kann kein Markdown bearbeiten und deployen." Das ist fuer viele Teams immer noch eine faire Einschraenkung. Aber die Form dieser Einschraenkung aendert sich:

Viele Teams nutzen ohnehin Git-basierte Workflows fuer Docs und Product Marketing.
Visual Preview Tools existieren fuer static und headless Setups.
AI-gestuetztes Editing reduziert die "du musst die Tools lernen"-Barriere.

Der praktische Takeaway: Wenn du Editing sicher und previewbar machen kannst, kannst du oft auf ein klassisches Admin-Panel verzichten.

Wann du wirklich ein CMS brauchst (und es bewusst waehlen solltest)

Ein CMS rechtfertigt seine Komplexitaet, wenn die Website Teil eines operativen Systems ist: laufender Editorial-Throughput oder komplexe Content-Anforderungen. Du brauchst wahrscheinlich ein CMS, wenn du hast:

Mehrere Editors, die haeufig publishen.
Rollenbasierte Zugriffe und Approvals.
Scheduling, Revisionen und Audit Trails als Muss.
Ein stark strukturiertes / relationales Content-Modell:
- Produkte
- Standorte
- Autoren
- Kategorien
- Knowledge Bases
Personalisierung oder Content, der sich pro User/Session aendert.
Eine Site, die faktisch eine App ist (Membership, LMS, gated content).

In diesen Faellen ist ein Headless CMS oder ein "CMS + App Framework"-Ansatz oft das richtige Werkzeug.

Die Falle: "Wir bauen einfach ein kleines CMS"

Hier verbrennen Teams am haeufigsten. Die erste Version klingt klein:

Login-Screen
Editor
Media-Uploads
Publish/Unpublish

Aber die echten CMS-Anforderungen kommen spaeter:

Rollen und Permissions
Drafts, Previews, Approvals
Versionshistorie und Diffing
Schema-Migrationen
Bild-Transformationen und Optimierung
Link-Integritaet und Redirect-Governance
Abuse Prevention, Rate Limits und Content Security

Wenn du ein CMS baust, meldest du dich fuer ein ganzes Oekosystem an Problemen an, die existieren, weil Content Produktions-Infrastruktur ist. Wenn dein Ziel ist "Seiten schnell und sicher shippen", ist das bessere Pattern:

ein CMS nutzen, das die harten Teile bereits geloest hat, oder
ganz ohne CMS arbeiten und in einen Workflow investieren, der Content-Aenderungen sicher macht

Eine Decision-Matrix, die wir in echten Projekten nutzen

Hier ist ein Set an Fragen, das die richtige Wahl meistens schnell klar macht.

1) Wie oft aendert sich Content?

Monatlich oder seltener: static-first ist meist okay.
Woechentlich mit mehreren Autoren: CMS in Betracht ziehen.
Taegliche Editorial-Cadence: CMS frueh waehlen.

2) Wer muss publishen koennen?

Nur Engineers: MDX/Markdown ist sauber und robust.
Ein kleines Team mit Preview + strukturierten Formularen: leichtgewichtiges Content-Tooling reicht oft.
Viele nicht-technische Editors: CMS.

3) Brauchst du Workflow-Features?

Wenn du Drafts, Approvals, Scheduling und Rollen brauchst, beschreibst du ein CMS.

4) Ist dein Content relational?

Wenn dein Content von Beziehungen und Queries abhaengt (nicht nur Seiten), willst du ein CMS-gestuetztes Modell.

5) Ist "pixel-perfect output" kritisch?

Static- und MDX-first-Ansatz gewinnt hier oft, weil du den HTML-Output end-to-end kontrollierst.

CMS-Alternativen, die fuer Agenturen gut funktionieren

Statt automatisch ein CMS zu nehmen, waehl das kleinste Tool, das die echte Anforderung erfuellt:

MDX/Markdown im Repo:
- stark fuer Service-Sites, technische Blogs und Docs
- gut kombinierbar mit QA-Gates und interner Verlinkungs-Disziplin
Headless CMS:
- stark, wenn du strukturierten Content + Editorial-Workflows brauchst
Agent-native CMS (emerging category):
- macht Automation und AI-getriebene Ops first-class
- Beispiel: EmDash: Cloudflare’s Agent-Native CMS

Unser eigenes Beispiel: Lunover ist von WordPress zu Markdown gewechselt (2024)

2024 sind wir mit der Lunover-Site von WordPress auf ein Markdown/MDX-first-Setup umgestiegen. Heute ist unser "CMS" im Kern:

sauber strukturierte Markdown/MDX-Files im Repo
ein kleines Set wiederverwendbarer Components fuer konsistente Sections (CTAs, Callouts, Layouts)
ein Release-Workflow (Preview, Review, Deploy)

Das funktioniert fuer uns, weil unser Content-Verhalten zum "kein CMS"-Profil passt:

die meisten Seiten aendern sich nicht haeufig
Edits sind meist klein und bewusst (kein dauerndes Editorial-Publishing)
jeder im Team kann Markdown lesen und bearbeiten
Struktur wird durch Templates und Konventionen erzwungen, nicht durch ein Dashboard

Der Punkt ist nicht, dass WordPress "schlecht" ist. Der Punkt ist: Sobald Content stabil ist und das Team Markdown beherrscht, kann ein CMS zusaetzliche Oberflaeche sein, ohne proportionalen Mehrwert zu liefern.

Was das fuer eine Webagentur bedeutet

Fuer die meisten Service-Websites ist die "CMS-Entscheidung" in Wahrheit eine Delivery-Entscheidung:

Sollen Content-Aenderungen wie Releases governed werden?
Oder brauchst du ein Self-Serve-Editorial-System mit Workflow-Kontrollen?

Wir bauen beide Arten von Systemen, aber wir waehlen bewusst, weil die langfristige Maintenance-Oberflaeche unterschiedlich ist. Wenn du einen Neubau oder eine Migration planst und eine Empfehlung willst, die zu Team und Update-Cadence passt: