Ein CMS ist eine Abstraktionsschicht. Es nimmt die technische Komplexität hinter einer Website und macht sie über eine visuelle Oberfläche bedienbar. Die Frage, ob man 2026 noch ein CMS braucht, lässt sich deshalb nicht am Tool festmachen. Sie hängt an einer einzigen Gegenfrage: Können die Menschen, die im Alltag Content pflegen, mit Code umgehen?
Ende 2025 hat Lee Robinson beschrieben, wie er das komplette CMS der Webseite des Code-Editor Cursor durch Markdown-Dateien im Code-Repository ersetzt hat. Er tat das Innerhalb von drei Tagen mit (natülrich) Cursor. Kostenpunkt dafür waren gerade mal 260 Dollar in Form von AI-Tokens. Die Gegenreaktion kam prompt: Sanity, der bisherige CMS-Anbieter von Cursor, argumentierte, dass das Team sich damit faktisch ein eigenes, weniger leistungsfähiges CMS gebaut habe.
Beide Positionen haben ihre Berechtigung, argumentieren aber aus derselben Perspektive: der eines Entwicklerteams, das seinen eigenen Content verwaltet. Für die meisten Unternehmen, gerade auch im DACH-Raum, ist das nicht die Realität.
Was ein CMS eigentlich tut
Code, Datenbank, Deployment, Hosting: Ein CMS verpackt diese technischen Schichten in eine visuelle Oberfläche. Wer einen Blog-Post veröffentlichen will, muss keinen Code schreiben, kein Terminal öffnen und keinen Deployment-Prozess anstossen. Es reicht, sich einzuloggen, den Text zu schreiben und auf "Veröffentlichen" zu klicken.
Das klingt banal, ist aber der entscheidende Punkt. Denn ohne diese Abstraktionsschicht muss jede inhaltliche Änderung an der Website über jemanden laufen, der die technische Seite versteht.
Ein Beispiel aus der Praxis von designtakt: Ein Dienstleistungsunternehmen mit rund 30 Mitarbeitenden betreibt über 40 Landing Pages für verschiedene Standorte und Leistungen. Die Marketing-Verantwortliche baut diese Seiten selbst, ohne Entwickler-Support. Die Grundlage dafür sind CMS-Collections: FAQs, Kundenstimmen, Teamprofile und Leistungsbeschreibungen liegen als strukturierte Einträge im System. Eine neue Landing Page für den Standort Winterthur entsteht, indem sie die passenden FAQs auswählt, zwei Kundenstimmen aus der Region zuordnet, das lokale Team verknüpft und auf Veröffentlichen klickt. In 20 Minuten ist eine vollständige Standortseite live. Ohne CMS wäre jede dieser 40 Seiten ein eigenes Template oder ein Ticket an die Entwicklung.
Neben der reinen Zugänglichkeit leistet ein CMS noch etwas anderes: Struktur. Moderne CMS-Systeme arbeiten mit definierten Feldern und Inhaltstypen. Ein Blog-Post hat einen Titel, ein Datum, ein Bild, eine Kategorie. Eine Case Study hat einen Kundennamen, eine Branche, ein Zitat. Diese Struktur sorgt dafür, dass Inhalte konsistent bleiben, auch wenn verschiedene Personen daran arbeiten. Und sie ermöglicht es, Inhalte gezielt abzufragen und an verschiedenen Stellen wiederzuverwenden, ohne sie manuell duplizieren zu müssen.
Wer pflegt den Content wirklich?
Die Antwort auf diese Frage entscheidet, ob ein CMS notwendig ist. Und in den allermeisten Unternehmen lautet die Antwort: nicht die Entwickler.
Bei einem KMU mit 15 Mitarbeitenden kümmert sich jemand aus dem Marketing um die Website-Texte. Oder der Geschäftsführer selbst. Oder eine Person, die neben zehn anderen Aufgaben auch noch "die Website macht". Bei einem Mittelständler mit 200 Mitarbeitenden gibt es in den meisten Fällen ein kleines Marketing-Team, das regelmässig neue Seiten erstellt, Blog-Posts veröffentlicht und Landing Pages für Kampagnen baut.
Was all diese Personen gemeinsam haben: Sie arbeiten nicht in einem Code-Editor. Sie kennen kein Git, Markdown oder Terminal. Und das ist sicherlich kein Defizit, sondern ganz normale Arbeitsteilung. Genau wie der Entwickler nicht die Quartalszahlen erstellt, erstellt die Marketingleiterin keine Pull Requests.
Wenn der Content direkt im Code lebt, ohne CMS dazwischen, entsteht ein Flaschenhals. Jede Änderung, sei es ein Tippfehler, ein neues Teamfoto oder eine aktualisierte Leistungsbeschreibung, muss über einen Entwickler laufen. Das verlangsamt den Content-Prozess und bindet Entwicklerzeit an Aufgaben, die nichts mit Entwicklung zu tun haben.
Wann es auch ohne CMS geht
Es gibt Konstellationen, in denen ein CMS tatsächlich unnötiger Overhead ist. Der häufigste Fall: ein kleines Gründerteam, in dem der Geschäftsführer selbst technisch arbeitet. Wer ohnehin im Code Editor lebt und regelmässig Code deployt, für den ist eine Markdown-Datei kein Hindernis, sondern der kürzeste Weg.
Tools wie Astro machen dieses Setup heute sehr komfortabel. Content-Seiten lassen sich als Markdown- oder MDX-Dateien mit strukturiertem Frontmatter anlegen, versioniert in Git, automatisch deployed bei jedem Commit. Für ein technisches Blog, eine Dokumentation oder ein persönliches Portfolio ist das ein schlankes, schnelles und kostengünstiges Setup.
Auch Lee Robinsons Beispiel fällt in diese Kategorie. Cursor ist ein Unternehmen, dessen gesamtes Team aus Entwicklern besteht. Die Website wird von den gleichen Menschen gepflegt, die auch den Code schreiben. In dieser Konstellation ist ein CMS tatsächlich eine Abstraktionsschicht, die niemand braucht.
Entscheidend ist aber die ehrliche Einordnung: Dieses Setup funktioniert, weil die Personen, die Content verändern, mit Code umgehen können. Sobald jemand ins Team kommt, der das nicht kann (eine Marketing-Verantwortliche, ein Content Writer, eine externe Agentur), stösst das Modell an seine Grenzen. Und in der KMU-Landschaft ist das eher die Regel statt die Ausnahme.
Was ein gutes CMS 2026 können muss
Die Frage hat sich verschoben. Heute geht es vor allem darum, welches CMS zum Unternehmen passt. Und hier hat sich in den letzten Jahren einiges verändert.
Ein zeitgemässes CMS bietet eine Oberfläche, die auch ohne technisches Vorwissen bedienbar ist. Das bedeutet: klare Eingabefelder statt Freitext-Editoren, in denen alles möglich und nichts konsistent ist. Es bedeutet auch, dass Vorschauen funktionieren, ohne dass jemand zuerst ein Deployment anstossen muss. Wer einen Text ändert, will sehen, wie die Änderung auf der fertigen Seite aussieht, bevor sie live geht.
Strukturierte Inhalte sind ein weiterer Punkt, der immer wichtiger wird. Ein CMS, das Inhalte in typisierte Felder aufteilt (Titel, Beschreibung, Bild, Kategorie, Autor), macht diese Inhalte maschinenlesbar. Das ist relevant für SEO, für die Wiederverwendung auf verschiedenen Seiten und zunehmend auch für AI-Tools, die auf strukturierte Daten zugreifen.
Der dritte Aspekt ist Flexibilität in der Architektur. Klassische CMS-Systeme wie WordPress koppeln Inhalt und Darstellung eng aneinander. Headless CMS-Systeme wie Sanity oder Storyblok trennen die beiden Ebenen und liefern Inhalte über eine API aus. Welcher Ansatz der richtige ist, hängt von der Grösse des Projekts, der technischen Kompetenz im Team und den Anforderungen an die Frontend-Umsetzung ab. Das ist aber eine eigene Entscheidung, die einen eigenen Beitrag verdient.
Häufig gestellte Fragen
Macht AI-gestütztes Coding das CMS überflüssig?
AI Coding Agents können Inhalte im Code verändern, das stimmt. Aber sie lösen nicht das Grundproblem: Jemand muss den Agent anweisen, was geändert werden soll. Wenn die Person, die den Content verantwortet, keinen Zugang zum Code-Editor hat, in dem der Agent läuft, bleibt der Flaschenhals bestehen. AI-Tools verändern, wie Websites gebaut werden. Sie verändern nicht, wer den Content im Alltag pflegt.
Ist Markdown im Git-Repo nicht einfacher als ein CMS?
Für Entwickler: ja, oft schon. Markdown ist leichtgewichtig, versioniert, und lässt sich mit jedem Texteditor bearbeiten. Für alle anderen ist ein Git-Repository aber keine intuitive Arbeitsumgebung. Ein CMS übersetzt die gleiche Funktionalität in eine Oberfläche, die ohne technisches Vorwissen bedienbar ist. Die entscheidende Frage ist, für wen das Format einfacher sein muss.
Für welche Unternehmensgrösse lohnt sich ein CMS?
Die Unternehmensgrösse ist nicht der entscheidende Faktor. Entscheidend ist, ob die Personen, die regelmässig Inhalte erstellen oder ändern, technisch arbeiten oder nicht. Ein Zwei-Personen-Startup, in dem beide Gründer coden, kommt ohne CMS aus. Ein Fünf-Personen-Unternehmen, in dem niemand Code schreibt, braucht eins. Die Teamzusammensetzung zählt mehr als die Teamgrösse.
Fazit
Die Debatte um "CMS vs. kein CMS" stellt die falsche Frage. Das richtige Framing ist simpler: Können die Menschen, die im Alltag Content erstellen und pflegen, mit Code umgehen? Wenn ja, kann Content im Code leben. Wenn nein, braucht es eine Abstraktionsschicht, die technische Komplexität verbirgt und inhaltliche Arbeit ermöglicht. Das ist, was ein CMS tut.
Die "Content as Code"-Bewegung hat berechtigte Argumente: weniger Abhängigkeiten, schnellere Builds, tiefere Kosten. Aber sie setzt eine Teamstruktur voraus, die in den meisten KMU und Mittelständlern schlicht nicht existiert.
Wer vor der Entscheidung steht, ob und welches CMS das richtige ist, sollte beim Team anfangen. Wer pflegt den Content? Wie oft? Wie technisch versiert ist diese Person? Die Antwort darauf bestimmt die Infrastruktur, nicht umgekehrt.
