CMS
Die CMS-Landschaft 2026
Ein sachlicher Überblick über Systeme, Stärken und Schwächen
Content Management Systeme sind für viele Projekte unverzichtbar — sie ermöglichen es, Inhalte zu verwalten, ohne tief in Code einsteigen zu müssen. Doch die Landschaft ist fragmentiert und vielfältig. Welches CMS passt zu welchem Projekt? Ein Überblick über die wichtigsten Systeme, ihre Architektur und ihre echten Anwendungsfälle.
Die zwei Architekturen: Datenbank vs. Flat-File
Bevor wir einzelne Systeme betrachten, ist es wichtig, die grundsätzliche Unterscheidung zu verstehen. CMS-Systeme folgen zwei verschiedenen Paradigmen:
Datenbankbasierte Systeme speichern Inhalte in relationalen oder dokumentenorientierten Datenbanken. Sie sind bewährt, skalierbar und ermöglichen komplexe Abfragen. Allerdings erfordern sie mehr Infrastruktur und sind wartungsintensiver.
Flat-File-Systeme speichern Inhalte in Dateien (meist Markdown, YAML oder JSON) im Dateisystem. Sie sind einfacher zu hosten, versionierbar mit Git, und perfekt für kleinere bis mittlere Projekte. Der Nachteil: Sie skalieren bei sehr großen Inhaltsmengen nicht ideal und ermöglichen keine komplexen Datenbankabfragen.
Datenbankbasierte Systeme
WordPress
Architektur: PHP + MySQL/MariaDB
Stärken:
- Gigantisches Ökosystem mit Tausenden von Plugins und Themes
- Extrem große Community, einfach Lösungen online zu finden
- Flexibel genug für Blogs, Magazine, kleine E-Commerce-Seiten
- Hohe Hosting-Verfügbarkeit auch bei günstigen Anbietern
- Gutter REST API und REST-basierte Headless-Funktionalität möglich
Schwächen:
- Sicherheitslücken in Core und Plugins sind omnipräsent; regelmäßiges Patching zwingend erforderlich
- Performance-Probleme ohne sorgfältige Optimierung und Caching
- Code-Qualität im Kern und in vielen Plugins fragwürdig; technische Schulden
- Veraltet für größere, komplexere Projekte
- Theme- und Plugin-Abhängigkeiten führen zu Vendor Lock-in
Anwendungsfälle:
- Kleine bis mittlere Blogs und Magazine
- Unternehmenswebseiten mit Standard-Features
- Schnelle Prototypen für Content-Projekte
- Einsatz für Teams ohne tiefe Programmier-Expertise
Warnung: Nicht geeignet für sicherheitskritische Anwendungen, Hochlast-Szenarien oder Projekte, die auf moderne, wartbare Architektur angewiesen sind. WordPress-Projekte werden oft zur technischen Schuldenfalle.
Drupal
Architektur: PHP + MySQL/PostgreSQL
Stärken:
- Äußerst leistungsstarkes, erweiterbares Framework für größere Projekte
- Modulares Designprinzip ermöglicht präzise Anpassungen
- Starke Taxonomie- und Metadaten-Unterstützung
- Ausgezeichnet für Multisite-Setup und mehrsprachige Projekte
- Bessere Code-Qualität und Architektur als WordPress
- Robuste Admin-Interfaces für komplexe Workflows
Schwächen:
- Steile Lernkurve; Drupal ist nicht anfängerfreundlich
- Performance erfordert erhebliches Tuning
- Größere Overhead für einfache Projekte
- Kleinere Community als WordPress, weniger Tutorials online
- Theming und Custom Development erfordern Drupal-Expertise
Anwendungsfälle:
- Große Nachrichtenportale und Medienseiten
- Komplexe Unternehmensseiten mit besonderen Anforderungen
- Multisite-Installationen mit gemeinsamen Code-Basis
- Projekte, die erweiterte Taxonomien und Custom Content Types benötigen
- Digitale Archive und Sammlungen
Warnung: Nicht geeignet für kleine Websites, schnelle Prototypen oder Teams ohne Drupal-Erfahrung. Die Komplexität rentiert sich nur bei entsprechend großen und komplexen Projekten.
Typo3
Architektur: PHP + MySQL/PostgreSQL
Stärken:
- Professionelle Enterprise-Lösung mit starkem Fokus auf große Installationen
- Flexible Template-Engine und granulare Zugriffskontrolle
- Ausgezeichnet für Multisite- und Multi-Language-Setups
- Starke Rechtesystem mit differenzierten Rollen
- Gutes Ökosystem für Agenturen
Schwächen:
- Sehr hohe Komplexität; steile Lernkurve
- Kleinere Community als WordPress oder Drupal
- Eher im deutschsprachigen und Benelux-Raum verbreitet
- Licensing-Modelle können verwirrend sein
- Hosting und Infrastruktur erfordern spezielle Expertise
Anwendungsfälle:
- Große föderale Websites (z.B. Behördenportale)
- Multisite-Installationen für Agenturen
- Projekte mit sehr granularen Zugriffskontroll-Anforderungen
- Mittel- bis großformatige Unternehmensseiten im deutschsprachigen Raum
Warnung: Deutlich zu komplex für kleine und mittlere Projekte. Nur wenn die Anforderungen wirklich groß sind, zahlt sich der Overhead aus.
Joomla
Architektur: PHP + MySQL
Stärken:
- Gutes Ökosystem mit großer Community
- Gutes Kompromiss zwischen Flexibilität und Bedienbarkeit
- Komponenten-, Modul- und Plugin-System funktioniert vernünftig
- K2 und ähnliche Extensions ermöglichen erweiterte Content-Verwaltung
Schwächen:
- Deutlich kleiner als WordPress, marginalisiert von dessen Dominanz
- Performance-Probleme ohne Optimierung
- Die Admin-UI ist nicht besonders modern oder intuitiv
- Weniger Dokumentation und Online-Ressourcen als Konkurrenten
- Sicherheit abhängig von Fleiß bei Updates
Anwendungsfälle:
- Mittlere Websites, wenn WordPress zu einfach ist
- Community-Portale und soziale Aspekte
- Mehrsprachige Websites mit besserer Unterstützung als WordPress
Warnung: Joomla hat die strategische Schlacht gegen WordPress verloren. Neue Projekte sollten sich besser für WordPress (einfacher) oder Drupal (komplexer) entscheiden. Joomla ist ein Mittelding, das schwer zu rechtfertigen ist.
Statamic
Architektur: PHP (Laravel) + MySQL/PostgreSQL (optional Flat-File-Hybrid)
Stärken:
- Modern aufgebaut auf dem Laravel-Framework
- Moderne, benutzerfreundliche Admin-Oberfläche
- Flexibler als WordPress, weniger Overhead als Drupal
- Gute Dokumentation und moderne Developer Experience
- Headless-CMS möglich; gute REST API
- Kann auch Flat-File-basiert arbeiten (Hybrid-Ansatz)
Schwächen:
- Kleine Gemeinschaft; nicht so viel Online-Material wie WordPress
- Weniger Plug-and-Play Extensions als etablierte Systeme
- Basiert auf Laravel, was Hosting-Anforderungen komplexer macht
Anwendungsfälle:
- Moderne Websites für Teams mit PHP/Laravel-Expertise
- Headless-CMS für JAMstack-Architektur
- Projekte, die WordPress zu einfach und Drupal zu schwer finden
- Hybrid-Projekte zwischen traditionellem CMS und Flat-File
Datenbankbasiert, aber leichtgewichtig
Craft CMS
Architektur: PHP (Yii Framework) + MySQL/PostgreSQL/SQLite
Stärken:
- Extrem flexible Content-Modellierung mit beliebigen Field Types
- Professionelle Admin-UI mit exzellenter Developer Experience
- Matrix Fields und Relationship Fields ermöglichen komplexe Strukturen
- Content ist als REST API nutzbar; ideal für Headless
- Gutes Ökosystem von Official Plugins
- Bessere Performance als WordPress bei vergleichbarer Komplexität
Schwächen:
- Kommerzielles Licensing für Production; kostenlos nur für Development
- Kleinere Community als WordPress, mehr Spezialist:in-Know-how erforderlich
- Nicht so viele Third-Party-Plugins wie WordPress
- Hosting-Anforderungen etwas höher als WordPress
Anwendungsfälle:
- Headless-CMS für komplexe Content-Modellierungen
- Modern Agency Workflows
- Websites mit individuellen Content-Strukturen
- Projekte, die eine REST API als primäres Interface benötigen
Hinweis: Craft ist nicht “open source” im klassischen Sinne, sondern “source available” mit Commercial License. Für kleinere Budgets kann das problematisch sein.
Strapi
Architektur: Node.js (Express) + PostgreSQL/MySQL/SQLite/MongoDB
Stärken:
- Echtes Open-Source Headless CMS mit großem Momentum
- Fantastische für Content APIs ausgelegt
- Modernes JavaScript-Ökosystem
- Flexible Content Type Generierung
- Wachsendes Ökosystem von Plugins und Integrationen
- Gute Dokumentation
Schwächen:
- Overhead für einfache, traditionelle Websites
- Database-Migration und Upgrades können knifflig sein
- Community-Edition hat Limitations gegenüber Pro-Version
- Relativer zu neu für sehr großformatige Deployments
Anwendungsfälle:
- Headless CMS für Decoupled Architectures
- API für Mobile Apps, React/Vue Frontends
- Projekte mit JavaScript/Node.js Stack
- Content APIs mit Webhooks und Event-Driven Workflows
Flat-File Systeme
Kirby
Architektur: PHP + Dateisystem (Markdown/YAML)
Stärken:
- Wunderbar einfach zu installieren und zu hosten (nur PHP nötig)
- Inhalte sind lesbar in der Dateisystem-Hierarchie; Git-freundlich
- Überraschend leistungsstarke Templating-Engine
- Panel (Admin-Oberfläche) ist modern und angenehm zu nutzen
- Kleine, durchdachte API; sehr gute Dokumentation
- Perfekt für Designer:innen und Frontend-Developer:innen
- Feldtypen sind flexibel konfigurierbar
- Kostenlos für kleine Projekte, transparente Pro-Lizenzierung
Schwächen:
- Keine native Multi-User Collaborative Editing (Panel ist Single-User-fokussiert)
- Komplexe Abfragen über Content-Hierarchien sind begrenzt
- Skaliert nicht auf mehrere Millionen von Inhalten
- Limited Query-Möglichkeiten im Vergleich zu Datenbanken
- Community deutlich kleiner als WordPress
Anwendungsfälle:
- Portfolios, Agentur-Webseiten
- Blogs und Editorial Sites mit moderatem Content-Volumen
- Dokumentations-Websites
- Kleine bis mittlere Unternehmensseiten
- Projects, die Git-basiertes Versioning von Content wünschen
- Hybrid mit Headless-Ansatz für statische Seiten + externe APIs
Ideal für: Designer:innen und Entwickler:innen, die einfache, wartbare Lösungen ohne Datenbank-Overhead schätzen.
Grav
Architektur: PHP + Dateisystem (Markdown/YAML)
Stärken:
- Sehr schnell und leichtgewichtig
- Keine Admin-Oberfläche erforderlich (traditionell datei-basiert)
- Git-freundlich; Inhalte sind einfache Dateien
- Admin Plugin (optional) mit moderner UI verfügbar
- Skeleton-Pakete für schnelle Starts
- Gutes Dokumentation und aktive Community
- Excellent für technische Dokumentation
Schwächen:
- Weniger professionelle Admin-UI als Kirby Panel
- Dokumentation teilweise weniger tiefgreifend als Kirby
- Community kleiner als WordPress, größer als Kirby
- Multi-User Editing in Admin-Plugin begrenzt
Anwendungsfälle:
- Technische Dokumentation und Wikis
- Statische Seiten mit Blog-Komponenten
- Entwickler:innen-fokussierte Sites
- Knowledge Bases
- Schnelle Prototypen für Statische Seiten
Ideal für: Entwickler:innen mit Markdown-Vorliebe und Affinität zum Terminal.
Hugo
Architektur: Go-Binary + Markdown (kein PHP erforderlich)
Stärken:
- Extrem schnell (kompiliert zu statischen Seiten)
- Einfache Installation; nur ein Binary
- Großes Ökosystem von Themes
- Perfekt für JAMstack und statische Seite-Generierung
- Git-freundlich
- Leicht versionierbar, einfaches Deployment zu CDN/Static Hosting
- Exzellent für Technical Blogging
Schwächen:
- Keine Admin-Oberfläche; reine Datei + Kommandozeile
- Kein dynamischer Content ohne externe APIs
- Learning Curve für Go-Templates
- Für Content-Editor:innen ohne Terminal-Affinität unpraktisch
- Community ist skriptorientiert, weniger “business-fokussiert”
Anwendungsfälle:
- Statische Websites mit Performance-Anforderungen
- Dokumentation, Blogs, Portfolios
- JAMstack Architecture mit externen APIs
- OpenSource-Projekte mit GitHub Pages Hosting
- High-Traffic Websites ohne Datenbankbelastung
Warnung: Nicht für Projekte, bei denen Content-Editor:innen ohne Terminal-Kenntnisse das CMS bedienen sollen.
Statik / Eleventy (11ty)
Architektur: JavaScript/Node.js + Markdown (Static Site Generator)
Stärken:
- Flexible Template-Engine (Nunjucks, EJS, Pug, Liquid, uvm.)
- Großes Ökosystem von Plugins
- Einfach zu erweitern mit JavaScript
- Zero-Config möglich
- JAMstack-native Architektur
- Schnelle Build-Times
Schwächen:
- Auch kein Admin-Panel; CLI/Dateien
- Erfordert Node.js Installation und npm Vertrautheit
- Nicht gedacht für Content-Editor:innen ohne Code-Erfahrung
Anwendungsfälle:
- Statische Websites mit flexiblen Template-Requirements
- Dokumentations-Sites und Knowledge Bases
- Blogs und Editorial Inhalte
- Projekte im JAMstack/Headless-Ökosystem
Statamic (auch hier erwähnenswert im Flat-File-Kontext)
Statamic funktioniert im Hybrid-Modus auch mit Flat-Files statt Datenbank. Das macht es zu einer interessanten Option, die traditionelle CMS-UX mit File-basiertem Versionierung kombiniert.
Spezialzweck: Headless CMS
Contentful
Architektur: SaaS Cloud-basiert (nicht selbst gehostet)
Stärken:
- Content APIs als primäres Interface
- Unkompliziert für Multi-Channel Publishing
- Webhooks und Events sind gut integriert
- Verwaltete Infrastruktur; keine Server-Wartung
- Gutes Ökosystem von Integrations
Schwächen:
- Monatliche Gebühren; nicht kostenlos für Production
- Vendor Lock-in; Daten sind in ihrem System
- Weniger Flexibilität bei Custom Workflows
- Overkill für kleine Projekte
Anwendungsfälle:
- Unternehmensseiten mit Multi-Channel Publishing
- Mobile Apps mit gemeinsamer Content-Base
- Startups, die schnell skalieren wollen
Hinweis: Kostenpflichtig. Open Source Alternative: Strapi.
Matrixvergleich: Wann welches System?
| Anforderung | Best Choice | Alternative |
|---|---|---|
| Einfache Website, minimaler Code | Kirby | Grav |
| Performance-kritische statische Seite | Hugo | Eleventy |
| WordPress-ähnliche Einfachheit, bessere Code | Statamic | Craft CMS |
| Großes Portal / Nachrichtenseite | Drupal | Typo3 |
| Headless API-First | Strapi | Craft CMS |
| Enterprise Multi-Site | Typo3 / Drupal | Drupal / Typo3 |
| Kleine Community Website | Joomla | (lieber WordPress) |
| Designer/Frontend fokussiert | Kirby | Craft CMS |
Häufige Fehler bei der CMS-Wahl
Fehler 1: WordPress als Universallösung
WordPress wird oft als “einfachste Lösung” eingesetzt, auch wenn das Projekt komplexer ist. Das führt zu Plugin-Chaos, Sicherheitsproblemen und unmartbarer Architektur. Wenn die Anforderungen 10% über “einfacher Blog” liegen, ist Drupal, Statamic oder ein Headless-Ansatz oft besser.
Fehler 2: Datenbank-CMS für kleine Projekte
Ein Medium-Unternehmen mit statischer Website braucht keine MySQL und keine Sicherheits-Updates für den CMS-Core. Kirby oder Hugo wären viel wartungsfreundlicher.
Fehler 3: Flat-File-System für große Redaktionen
Wenn 50 Journalisten gleichzeitig Content editieren und eine komplexe Workflow-Engine benötigen, sind Flat-Files nicht geeignet. Drupal oder Craft CMS sind deutlich besser.
Fehler 4: Zu viel Fokus auf Plugins statt echtem Design
WordPress-Projekte, die nur Plugins zusammenklicken, führen zu unmartbaren Sites. Bei größerer Komplexität sollte bewusst eine Lösung mit besseren Foundations gewählt werden.
Fazit: Es gibt kein universales CMS
Jedes System hat seinen Platz. Die richtige Wahl hängt von Anforderungen, Team-Expertise, Budget und Zukunftsperspektiven ab. Ein paar Faustregeln:
- Small & Simple: Kirby oder Grav
- Small & Static: Hugo oder Eleventy
- Small-Medium & Datenbank: WordPress oder Statamic
- Medium-Large & Complex: Drupal oder Craft CMS
- Enterprise: Typo3 oder Drupal
- Headless Modern: Strapi oder Craft CMS
- Technische Dokumentation: Grav, Hugo oder Eleventy
Die beste Wahl ist oft nicht das System mit den meisten Features, sondern das, das die benötigten Features mit minimaler Komplexität bereitstellt.