2008, als dieser Artikel zuerst erschien, war der CMS-Markt Wilder Westen. WordPress galt vor allem als Blog-Plattform. Die Original-Liste empfahl Systeme wie Frog CMS, SilverStripe, Liferay, miaCMS, MoinMoin, ImpressCMS, MODx, Textpattern, Radiant und CMS Made Simple. Die meisten dieser Namen sagen 2026 niemandem mehr etwas.
Die Kategorie hat sich in drei geteilt: traditionelle CMS, Headless API-first CMS und SaaS-Content-Plattformen. So steht der Markt 2026 da - mit deutscher Praxis im Blick, nicht nur globalen Prozenten.
1. WordPress - weiterhin die Standardwahl (über 40 % aller Websites)
Typ: Traditionelles CMS mit Headless-Optionen Lizenz: GPL (kostenlos, Open Source) Sprache: PHP Ideal für: Blog, Unternehmensseiten, WooCommerce-Shops, Portale
WordPress betreibt über 40 % aller Websites. Kein anderes CMS kommt nah. Die Software ist kostenlos; Sie zahlen für Hosting, Plugins und Arbeitszeit. Trotz jährlicher Niedergangsprognosen wuchs WordPress durch Diversifikation:
- Gutenberg ist zu Full Site Editing (FSE) gereift, sodass weniger neue Projekte Elementor nur für Layout brauchen
- REST API und WPGraphQL erlauben Headless mit React, Astro oder Next.js davor
- WooCommerce bleibt die dominante offene Shop-Plattform; in DE entscheiden oft Klarna, PayPal und SEPA-Lastschrift darüber, ob der Checkout wirklich konvertiert
- Die WordPress-7.x-Roadmap zielt auf mehr KI-Hilfe beim Redigieren, bessere Medienverwaltung und tiefere Block-Themes
Stärken: Plugin-Ökosystem (60.000+), großes Talentpool, bewährte Skalierung, WooCommerce.
Schwächen: PHP-Monolith, Sicherheit hängt an Plugin-Qualität, Admin-UX hinter modernen Tools, technische Schuld aus 20 Jahren Rückwärtskompatibilität.
Urteil 2026: WordPress verschwindet nicht. Es ist die Standardwahl, wenn nichttechnische Redakteure den Inhalt besitzen sollen und Shop plus deutsche Zahlarten im selben Stack sitzen.
2. Drupal - das Arbeitspferd im öffentlichen Sektor (0,7 % aller Websites)
Typ: Traditionelles CMS mit starker Headless-Unterstützung Lizenz: GPL Sprache: PHP (Symfony) Ideal für: Behörden, Gesundheit, Bildung, komplexe Enterprise-Seiten
Drupal sitzt in einer klaren Nische: Organisationen mit komplexer Inhaltsmodellierung, strengen Barrierefreiheitsanforderungen (BITV 2.0 / WCAG 2.2) und eigenen Entwicklungsteams. In Ausschreibungen deutscher Behörden landet Drupal oft genau deshalb, weil Rechte und Accessibility First-Party sind - nicht Plugin-Abhängigkeit.
- Drupal 11 (2025) brachte Symfony 7, bessere Admin-UX und mehr First-Party-Headless
- Die Initiative Drupal CMS versucht, die Lücke zu WordPress für Redakteure zu verkleinern
- Starke Adoption in der EU-Verwaltung (europa.eu und vergleichbare Portale)
Stärken: Inhaltsmodellierung, feingranulare Rechte, WCAG/BITV, Enterprise-Sicherheit.
Schwächen: Steile Lernkurve, kleineres Plugin-Ökosystem, teuer in Entwicklung und Betrieb, Major-Upgrades tun weh.
Urteil 2026: Drupal lebt gut in Behörden und großen Enterprise-Umgebungen, verliert aber Mid-Market an Headless und WordPress.
3. Joomla - der Überlebende (1,2 % Marktanteil)
Typ: Traditionelles CMS Lizenz: GPL Sprache: PHP Ideal für: Community-Portale, mehrsprachige Seiten, Vereine
Joomla war einst WordPress’ Hauptkonkurrent. 2026 ist es eine kleine, loyale Nische:
- Joomla 5 modernisierte die Codebasis mit PHP 8.1+ und Bootstrap-5-Admin
- Eingebaute Mehrsprachigkeit ohne Plugins bleibt ein echter Vorteil
- Stärkere Community in Teilen Europas und Südamerikas als in der DACH-Mid-Market
Stärken: Native Mehrsprachigkeit, flexibles ACL, reifes Erweiterungsverzeichnis.
Schwächen: Schrumpfende Entwickler-Community, weniger Extensions als WordPress, alte Image-Bremse.
Urteil 2026: Joomla überlebt, wächst aber nicht. Bestehende Seiten werden gepflegt; neue Projekte wählen selten Joomla vor WordPress oder Headless.
4. Ghost - Newsletter zuerst (0,1 % Marktanteil)
Typ: Spezialisierte Publishing-Plattform mit Headless-API Lizenz: MIT Sprache: Node.js Ideal für: Unabhängige Publisher, Newsletter, Mitgliedsseiten
Ghost ließ den Kampf ums «allgemeine CMS» und setzte auf die Creator-Economy:
- Eingebauter Newsletter mit E-Mail-Zustellung
- Mitgliedschaften und Abos über Stripe
- Content API und Admin API für eigene Frontends
- Ghost(Pro) als Managed Hosting für Autoren ohne DevOps
Stärken: Gute Schreib-UX, integrierte Monetarisierung, schnelles Node.js, saubere API.
Schwächen: Kleines Plugin-Ökosystem, ungeeignet für komplexe Seiten, kein E-Commerce jenseits von Mitgliedschaften.
Urteil 2026: Ghost trifft seine Nische. Gut für Solo-Publisher, die Text, Newsletter und Mitgliedschaft in einem Stack brauchen.
5. Strapi - der Open-Source-Headless-Pionier
Typ: Headless CMS (API-first) Lizenz: MIT / Enterprise Sprache: Node.js Ideal für: Custom-Apps, Mehrkanal, entwicklergetriebene Projekte
Strapi öffnete die Kategorie Open-Source-Headless und bleibt unter den meistgenutzten:
- Strapi 5 (2025) schrieb den Kern in TypeScript um, bessere Performance und Versionierung
- Automatisches REST und GraphQL aus Inhaltstypen
- Plugin-Marketplace mit SEO, Mediathek und Übersetzungen
- Strapi Cloud als Alternative zum Self-Hosting
Deutsche Agenturen, die Node bereits auf eigenen Servern oder bei EU-Hostern betreiben, schätzen, dass Daten im eigenen Umfeld bleiben können - besonders bei Kunden mit Speicherort-Vorgaben.
Stärken: Reifes Ökosystem, große Community, Self-Hosting für Datensouveränität.
Schwächen: Schwer für einfache Seiten, braucht JS/TS-Kompetenz, kein eingebautes Frontend.
Urteil 2026: Sichere Wahl für Teams, die Open-Source-Headless wollen und mit Node.js vertraut sind.
6. Payload CMS - der TypeScript-Herausforderer
Typ: Headless CMS (API-first, TypeScript-nativ) Lizenz: MIT Sprache: TypeScript (Next.js) Ideal für: Moderne Web-Apps, TypeScript-Teams, Next.js-Projekte
Payload ist das am schnellsten wachsende Open-Source-Headless-CMS 2025-2026:
- Config-as-code: Inhaltstypen in TypeScript ergeben API, Admin und Typen
- Kann im Next.js-Prozess laufen
- Payload 3.0 nutzt React Server Components im Admin
- Eingebautes ACL, Lokalisierung, Versionen, Entwürfe und Media
Stärken: Typsicherheit Ende-zu-Ende, gute DX, Next.js-Integration.
Schwächen: Jüngeres Ökosystem als Strapi, weniger Community-Plugins, Next.js-zentriert.
Urteil 2026: Erste Wahl, wenn das Team bereits in TypeScript und Next.js steckt.
7. Directus - Datenbank zuerst
Typ: Headless CMS (Wrapper um SQL) Lizenz: BSL / GPL nach 3 Jahren Sprache: TypeScript Ideal für: Bestehende Datenbanken, interne Tools, datenintensive Apps
Directus zeigt auf eine vorhandene SQL-Datenbank und generiert Admin und API:
- PostgreSQL, MySQL, MariaDB, SQLite, MS SQL, Oracle, CockroachDB
- Automatisches REST und GraphQL aus dem Schema
- Feldrechte und rollenbasierter Zugriff
Stärken: Funktioniert mit Daten, die Sie schon besitzen, keine proprietäre Speicherung, mehrere DB-Engines.
Schwächen: Weniger opinionated (mehr Entscheidungen), Admin kann für reine Redakteure schwer wirken.
Urteil 2026: Ideal, wenn die Datenbank existiert. Nicht der beste Startpunkt für Greenfield.
8. Sanity und Contentful - der SaaS-Kontrast
Sanity (proprietäres SaaS) differenziert mit Echtzeit-Kollaboration und einem React-basierten Studio, das Sie anpassen können. GROQ liefert für viele Teams mächtigere Abfragen als reines REST. Die Kosten skalieren mit API-Nutzung und Dataset-Größe.
Contentful ist der Enterprise-Standard für Multi-Brand und globale Content-Ops: Content Orchestration, Studio für visuelle Zusammenstellung, App Framework und dokumentierte Governance (SOC 2, ISO 27001, GDPR). Teuer in der Skala; oft überdimensioniert für kleine DACH-Projekte.
Urteil 2026: Sanity, wenn die Redaktion Echtzeit und flexibles Studio braucht. Contentful, wenn Compliance und Managed-Infrastruktur schwerer wiegen als Lizenzkosten. Für budgetsensible Projekte sind self-hosted Strapi/Payload oder WordPress realistischer.
9. Astro Content Collections - developer-first
Typ: Web-Framework mit dateibasierten CMS-Fähigkeiten Lizenz: MIT Sprache: TypeScript/JavaScript Ideal für: Entwicklergesteuerte Blogs, Dokumentation, Marketing-Seiten
Astro ist kein klassisches CMS, aber Content Collections liefern CMS-ähnliche Funktion für Inhalt in Git:
- Typsichere, schema-validierte Markdown/MDX-Dateien
- Content Layer API (Astro 5): Inhalt aus Dateien, APIs oder Datenbanken
- Null JS als Standard; Islands hydrieren nur dort, wo nötig
- Starke Core Web Vitals, wenn das JavaScript-Budget eng bleibt
Diese Website (wppoland.com) läuft auf Astro mit Content Collections für Blog und Service-Seiten. Statische Generatoren wie Hugo und Jekyll leben in derselben Familie, aber Astro sehen wir am häufigsten in neuen JS-Teams.
Stärken: Performance, typsicherer Inhalt, optionale UI-Stacks (React, Vue, Svelte).
Schwächen: Kein visuelles Admin für Nicht-Entwickler; Inhaltsänderungen laufen über Commit.
Urteil 2026: Gut, wenn Entwickler den Inhalt besitzen und Performance Priorität hat. Kein Ersatz für WordPress, wenn Redakteure ohne Git täglich publizieren.
Vergleichsmatrix: 10 CMS 2026
| CMS | Typ | Lizenz | Anteil aller Websites | Headless | Visueller Editor | Self-hosted | Ideal für |
|---|---|---|---|---|---|---|---|
| WordPress | Traditionell + headless | GPL | 40,8 % | Via REST/GraphQL | Ja (Gutenberg) | Ja | Allgemeine Seiten, E-Commerce |
| Drupal | Traditionell + headless | GPL | 0,7 % | Ja (native) | Ja | Ja | Enterprise, Behörden |
| Joomla | Traditionell | GPL | 1,2 % | Begrenzt | Ja | Ja | Mehrsprachige Communities |
| Ghost | Publishing | MIT | 0,1 % | Ja (API) | Ja | Ja | Newsletter, Mitgliedschaften |
| Strapi | Headless | MIT/Enterprise | N/A | Ja | Admin | Ja | Custom-Web-Apps |
| Payload | Headless | MIT | N/A | Ja | Admin | Ja | TypeScript/Next.js |
| Directus | Headless | BSL | N/A | Ja | Admin | Ja | Bestehende Datenbanken |
| Sanity | Headless (SaaS) | Proprietär | N/A | Ja | Anpassbar | Nur Cloud | Große Redaktionen |
| Contentful | Headless (SaaS) | Proprietär | N/A | Ja | Ja (Studio) | Nur Cloud | Enterprise Multi-Brand |
| Astro | Framework + CMS | MIT | N/A | N/A (statisch) | Nein | Ja | Entwicklergesteuerter Inhalt |
Die Prozente sind Anteil aller Websites. Quelle: W3Techs, 13. August 2026. Unter Seiten mit erkanntem CMS liegt WordPress bei 59,0 %.
Was wurde aus der Liste von 2008?
- Frog CMS: Aufgegeben. Letztes Release 2009.
- SilverStripe: Lebt als Silverstripe CMS, vor allem im öffentlichen Sektor Ozeaniens.
- miaCMS: Tot. Mambo-Fork, um 2010 aufgegeben.
- MoinMoin: Lebt als Python-Wiki, irrelevant als CMS.
- ImpressCMS: Technisch gepflegt, vernachlässigbare Adoption.
- MODx / MODX: Lebt als MODX Revolution mit kleiner, treuer Entwickler-Community.
- Textpattern: Lebt mit minimaler Community.
- Radiant: Aufgegeben. Ruby, letzte sinnvolle Updates um 2014.
- CMS Made Simple: Gepflegt (2.x), kleine Community.
- Liferay: Pivot zu Enterprise-Java-Portal/DXP für Banken und Konzerne.
Die Lehre von 2008 ist einfach: Ökosysteme gewinnen, nicht Feature-Listen. WordPress siegte, weil Plugins, Themes, Hosting und Talent zusammenwuchsen. Die Systeme, die überlebten (Drupal, Joomla), hatten eigene Ökosysteme. Die, die starben, setzten auf technische Eleganz ohne nachhaltige Community. WordCamp Berlin und WordCamp Hamburg bleiben sichtbare Zeichen, dass die WordPress-Community in DACH lebt - Meetups und Talks, nicht nur GitHub-Sterne.
Wie wählen
Wählen Sie WordPress, wenn Redakteure nicht coden, Sie WooCommerce mit Klarna/PayPal/SEPA brauchen oder das breiteste Hosting- und Plugin-Angebot wollen.
Wählen Sie Headless (Strapi/Payload), wenn das Frontend React/Next.js/Astro ist, Inhalt auf mehrere Kanäle muss oder das Team TypeScript und API-first bevorzugt.
Wählen Sie SaaS (Contentful/Sanity), wenn Sie Managed-Infrastruktur, Echtzeit-Kollaboration oder Enterprise-Governance brauchen - und das Budget das trägt.
Wählen Sie Astro Content Collections, wenn Entwickler Inhalt über Git besitzen, Performance Top-Priorität ist und die Seite überwiegend statisch ist (Blog, Docs, Marketing).
Wählen Sie Drupal, wenn BITV, WCAG und feingranulare Rechte First-Party-Anforderungen sind, nicht etwas, das Sie später ankleben.
Der CMS-Markt 2026 ist kein Winner-takes-all. Verschiedene Tools decken verschiedene Bedarfe. Wenn Sie klassisches WordPress gegen Headless für ein konkretes Projekt abwägen, gehen wir das in der WordPress-Entwicklung bei WPPoland durch.
