10 CMS-Systeme 2026: Marktanteil, Headless und was von 2008 übrig blieb

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, das meistgenutzte CMS (rund 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 rund 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 für Behörden und den öffentlichen Sektor

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 10 und Drupal 11 brachten Symfony 7, modernisierte Admin-Oberflächen und native Entkopplung. Die Decoupled-Architektur stützt sich auf JSON:API im Kern, GraphQL Compose und Next-Drupal, wodurch React- und Astro-Frontends standardisierte Entitäten konsumieren.
• Die Initiative Drupal CMS versucht, die Lücke zu WordPress für Redakteure durch vorkonfigurierte Starter-Kits (Recipes) zu verkleinern.
• Starke Adoption in der EU-Verwaltung (europa.eu und vergleichbare Portale) sowie in Bundes- und Landesbehörden, wo Sicherheitsüberprüfungen und rollenbasierte Freigabeworkflows vorgeschrieben sind.

Stärken: Inhaltsmodellierung mit Entity API, feingranulare Taxonomien, native Barrierefreiheit nach BITV/WCAG, Enterprise-Sicherheitsarchitektur ohne Drittanbieter-Zwang.

Schwächen: Steile Lernkurve, kleineres Plugin-Ökosystem im Vergleich zu WordPress, teuer in Entwicklung und Betrieb, Major-Upgrades erfordern geplante Migrationsetappen.

Urteil 2026: Drupal lebt gut in Behörden und großen Enterprise-Umgebungen, verliert aber Mid-Market an Headless und WordPress.

#3. Joomla 2026, mehrsprachiges CMS ohne Plugins

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 als CMS für Newsletter und Mitgliedschaften

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, direkt angebunden an Mailgun oder SMTP-Relays.
• Mitgliedschaften und gestaffelte Abos über native Stripe-Billing-Integration.
• Die Ghost Content API liefert schreibgeschützte JSON-Endpunkte für performante Frontends in Astro, Next.js oder Remix, während die Ghost Admin API automatisierte Redaktionspipelines und Webhooks speist.
• Ghost(Pro) als Managed Hosting für Autoren ohne DevOps, parallel zu Docker-Self-Hosting für Entwickler.

Stärken: Hervorragende Schreib-UX mit Markdown und Karten, integrierte Monetarisierung, schnelles Node.js-Backend, saubere REST-API.

Schwächen: Kleines Plugin-Ökosystem, ungeeignet für komplexe relationale Datenmodelle, kein E-Commerce jenseits digitaler Mitgliedschaften.

Urteil 2026: Ghost trifft seine Nische. Gut für Solo-Publisher, die Text, Newsletter und Mitgliedschaft in einem Stack brauchen.

#5. Strapi, Open-Source-Headless-CMS auf Node.js

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 schrieb den Kern vollständig in TypeScript um, führte den Document Service zur Inhaltsversionierung ein und optimierte die Datenbankabfragen für PostgreSQL und SQLite.
• Automatisches REST und GraphQL aus deklarierten Content-Typen mit feingranularen API-Tokens.
• Ein wachsender Plugin-Marketplace für SEO-Metadaten, Cloud-Mediatheken (S3, Cloudflare R2), Volltextsuche und Mehrsprachigkeit.
• Strapi Cloud als Alternative zum Self-Hosting auf eigener Infrastruktur.

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 strengen DSGVO- und Speicherort-Vorgaben.

Stärken: Reifes Ökosystem, große Community, vollständige Datensouveränität durch Self-Hosting, flexible Dokumentenmodelle.

Schwächen: Ressourcenintensiv für einfache Websites, verlangt kontinuierliche Node.js- und Datenbankwartung, kein mitgeliefertes Frontend.

Urteil 2026: Sichere Wahl für Teams, die Open-Source-Headless wollen und mit Node.js vertraut sind.

#6. Payload CMS für TypeScript und Next.js

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 als Headless CMS für bestehende SQL-Datenbanken

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 oder Contentful als SaaS-Headless-CMS

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 als dateibasiertes CMS

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.

#CMS-Marktanteile 2026 im Vergleich

Die Prozente sind Anteil aller Websites. Quelle: W3Techs, 13. August 2026. Unter Seiten mit erkanntem CMS liegt WordPress bei 59,0 %.

#Welches ist das beste kostenlose CMS 2026?

Für die meisten Websites bleibt WordPress 2026 das beste kostenlose CMS. Welche kostenlose Wahl passt, hängt aber davon ab, wer die Inhalte pflegt und wie sie ausgeliefert werden. Von den zehn Systemen in der Tabelle oben sind nur Sanity und Contentful proprietäre SaaS-Dienste mit begrenztem Gratis-Tarif; die übrigen acht lassen sich ohne Lizenzgebühr selbst hosten. Sieben davon sind Open Source unter GPL oder MIT, und der Quellcode von Directus ist unter der BSL frei einsehbar (jede Version wechselt drei Jahre später zur GPL). Die Lizenzkosten unterscheiden diese acht also nicht. Entscheidend sind das Redaktionsmodell und der Technologie-Stack.

Redakteure ohne technischen Hintergrund, allgemeine Websites, E-Commerce: WordPress (GPL). Es bringt das größte Plugin-Ökosystem und WooCommerce mit, und unter den kostenlosen Optionen ist es dasjenige, das jemand ohne Entwicklerkenntnisse am ehesten komplett selbst betreibt, ohne Code anzufassen. Ghost, Joomla und Drupal haben ebenfalls redaktionsfreundliche Backends, aber keines verbindet das mit einem vergleichbaren Ökosystem aus Plugins und E-Commerce.

Newsletter, Mitgliedschaften, Einzelpublizisten: Ghost (MIT). Eingebauter E-Mail-Versand und Mitgliedschaften auf Stripe-Basis ersparen Ihnen ein externes Newsletter-Tool.

Behörden, komplexe Inhaltsmodelle, strenge Barrierefreiheit: Drupal (GPL). Feingranulare Rechte und WCAG-2.2-Konformität funktionieren nativ, ohne Plugins.

Von Haus aus mehrsprachige Community-Websites: Joomla (GPL), das mehrere Sprachen ohne Erweiterungen verwaltet.

Sind Ihre Inhalte API-first oder werden sie von Entwicklern gepflegt, verschiebt sich die kostenlose Wahl zu einer Headless-Option oder zu Astro (siehe unten).

#Was wurde aus Frog CMS, SilverStripe und MODX?

• 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.

#TYPO3, Grav und Concrete CMS seit 2008

Der Weg von den Pionierjahren um 2008 bis zum heutigen Markt zeigt, wie sich Architekturanforderungen verschoben haben:

• TYPO3: Im DACH-Raum war TYPO3 über zwei Jahrzehnte die Standardreferenz für Universitäten, Konzerne und den öffentlichen Sektor. Während TYPO3 v12 und v13 moderne PHP-Standards und Headless-Konnektoren mitbringen, bleibt der Pflegeaufwand beträchtlich. TypoScript, komplexe TCA-Konfigurationen und steigende Stundensätze für spezialisierte TYPO3-Entwickler führen dazu, dass viele Organisationen den Umstieg auf WordPress oder modulare Stacks evaluieren.
• Grav: Als Flat-File-CMS verzichtet Grav vollständig auf eine SQL-Datenbank. Inhalte liegen als Markdown-Dateien mit YAML-Frontmatter vor, gerendert über Twig. Für kleinere Dokumentationsseiten oder agenturgetriebene Portfolios bietet Grav minimale Wartungslasten und einfache Versionskontrolle via Git. Grenzen zeigen sich bei Tausenden Artikeln, dynamischen Volltextsuchen oder mehrstufigen redaktionellen Freigabeworkflows.
• Concrete CMS: Ursprünglich bekannt als concrete5, setzte das System früh auf In-Context-Editing direkt auf der Website. In den 2010er Jahren war diese visuelle Bearbeitung innovativ, verlor jedoch an Zugkraft, als moderne Block-Editoren wie Gutenberg und Headless-Komponenten ähnliche Flexibilität ohne monolithische Bindung boten. Heute bedient Concrete CMS vor allem bestehende Enterprise- und Bildungsportale.
• Silverstripe CMS: Basierend auf einem eigenen PHP-Framework erfreute sich Silverstripe großer Beliebtheit bei Entwicklern, die sauberen objektorientierten Code schätzten. Durch die offizielle Ausrichtung auf den neuseeländischen Regierungsstandard Common Web Platform (CWP) sicherte sich das System eine stabile institutionelle Nische, während die weltweite Neugewinnung im Vergleich zu Headless-Systemen stagniert.
• Dotclear: Das traditionsreiche französische Blog-Publishing-System, gegründet 2002 als Alternative zu WordPress und Movable Type, wird bis heute von einer engagierten Community gepflegt. Mit schlankem PHP-Kern und geringem Ressourcenbedarf bleibt Dotclear eine puristische Option für Weblogs, spielt jedoch im internationalen Enterprise- oder E-Commerce-Umfeld keine Rolle.

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, TYPO3), hatten eigene Ökosysteme oder institutionelle Verankerungen. 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.

#Welches CMS statt WordPress für eine überwiegend statische Website 2026

Im März 2026 stellte ein Thread auf r/webdev die Frage, mit der viele Leser auf diesem Artikel landen. Der Autor betrieb eine alte Firmenwebsite auf WordPress, wollte einen Produktkatalog ergänzen und brauchte mehrere Sprachen im System selbst (r/webdev, Thread vom 6. März 2026).

#Statamic, Grav oder WordPress für eine kleine Firmenwebsite

Eine Antwort nannte ein System, das oben im Abschnitt zu TYPO3, Grav und Concrete CMS schon vorkommt:

Schau dir Grav an. Es ist dateibasiert und hat ein ordentliches Admin-Panel.

(u/madness-81, Antwort auf r/webdev, eigene Übersetzung)

Was dort zu Grav steht (Markdown, YAML, Git, keine SQL-Datenbank), gilt weiter. Laut Projektseite kommen eingebaute Mehrsprachigkeit und die MIT-Lizenz dazu (Grav-Funktionen). Im selben Thread fiel auch Statamic. Es basiert auf Laravel und speichert Inhalte standardmäßig in Dateien, mit einem Datenbankmodus für größere Websites (statamic.com). Mehrere Sprachen laufen über die Multi-Site-Funktion, die die Dokumentation als Pro-Funktion kennzeichnet (Statamic-Dokumentation zu Multi-Site). Prüfen Sie also die Edition, bevor Sie einem Kunden Übersetzungen zusagen. WordPress hält Inhalte in MySQL und ergänzt Sprachen per Plugin.

Dateibasierte Inhalte laufen zusammen mit den Templates durch Git, ein Deployment ist die Kopie eines Ordners, und es gibt keine Datenbank, die gesichert oder migriert werden muss. Eine Datenbank lohnt sich, sobald der Katalog Filter, Lagerbestände oder eine Redakteurin braucht, die jede Woche Produkte anlegt. Ein Katalog, den ein Entwickler ein paar Mal im Jahr aktualisiert, passt in Dateien. Ein Katalog mit Filtern und täglichen Änderungen führt zurück zu WordPress mit WooCommerce oder zu einem datenbankgestützten CMS.

#Payload oder Headless WordPress für ein JavaScript-Team

Ein Thread vom Februar 2026 fragte, ob ein Team zu Payload wechseln oder WordPress als Backend hinter Next.js behalten soll (r/webdev, Thread vom 26. Februar 2026). Die kürzeste Antwort:

Payload, wenn dein Team in JS lebt. Headless WP, wenn dein Content-Team WordPress schon kennt. Die Architektur zählt weniger als die Akzeptanz.

(u/jesusonoro, Antwort auf r/webdev, eigene Übersetzung)

Payload beschreibt sich als Next.js-nativ, das Backend läuft innerhalb der Next.js-App (payloadcms.com). Den Ansatz, Inhaltstypen im Code zu definieren, behandelt der Payload-Abschnitt oben. Headless WordPress behält die Plugins und den Editor, den der Kunde kennt, und verdoppelt dafür die Codebasen. WordPress liefert Inhalte über REST oder GraphQL, ein separates Frontend rendert sie, und jedes neue Feld wird auf beiden Seiten angelegt. Diese Aufteilung beschreibt unser Leitfaden zur Headless-WordPress-Architektur. Für eine überwiegend statische Firmenwebsite ist das mehr Maschinerie, als die Inhalte brauchen. Es lohnt sich, wenn dieselben Inhalte mehrere Frontends versorgen.

#Wer die Inhalte nach der Übergabe pflegt

Ein dritter Thread vom April 2026 kam von einem Entwickler, der langjährige Kundenseiten auf etwas Neueres umstellen will (r/webdev, Thread vom 9. April 2026). Eine Antwort benannte die versteckten Kosten:

Wenn Kunden “leichter zu aktualisierende” Websites wollen, heißt das wahrscheinlich, dass du mehr Arbeit hast, das CMS für jeden einzeln anzupassen.

(u/twenty20vintage, Antwort auf r/webdev, eigene Übersetzung)

Wer nach dem Launch editiert, entscheidet stärker über das CMS als die Frontend-Technik. Kunden, die jede Woche Inhalte ändern, brauchen eine Oberfläche, die sie lernen können: WordPress mit ein paar eigenen Blöcken oder das Control Panel von Statamic. Macht ein Entwickler jede Änderung, nehmen Inhalte in Dateien (Astro Content Collections, auf denen diese Website läuft, oder Grav) die Datenbank aus dem Aufbau. Der Umzug von Redakteuren in eine neue Oberfläche kostet den Kunden Einarbeitungszeit, und eine Weile landen die Änderungswünsche wieder bei Ihnen.

#Wie Sie zwischen WordPress, Headless und Drupal 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.

#Welches Open-Source-CMS ist das beste für Entwickler?

Für Entwickler hängt das beste Open-Source-CMS 2026 vom Stack ab: Payload für TypeScript- und Next.js-Teams, Strapi für Node-Projekte ohne festes Framework und Astro Content Collections für statische Inhalte, die über Git gepflegt werden. Alle drei sind kostenlos und Open Source (MIT), entscheidend ist daher, wie Sie das Frontend bauen.

Payload (MIT, TypeScript) passt am besten, wenn Sie bereits mit Next.js arbeiten. Inhaltstypen werden als Konfiguration im Code definiert, und aus denselben TypeScript-Dateien entstehen API, Admin-Oberfläche und durchgängige Typen. Payload kann außerdem im Serverprozess von Next.js laufen. Der Kompromiss sind ein jüngeres Plugin-Ökosystem und eine auf Next.js zugeschnittene Architektur.

Strapi (MIT, Node.js) ist die sicherere Wahl, wenn das Frontend nicht auf Next.js basiert. Es erzeugt REST und GraphQL automatisch aus den Inhaltstypen, hat die größere Community samt Plugin-Marktplatz und lässt sich für Datensouveränität selbst hosten. Für kleine Websites ist es schwerer als Payload.

Directus (BSL, wechselt nach drei Jahren zur GPL) gewinnt, wenn Sie schon eine SQL-Datenbank haben und darauf eine Verwaltungsoberfläche und eine API setzen wollen, statt ein Inhaltsmodell von null zu entwerfen. Astro Content Collections (MIT) ist die Wahl, wenn Entwickler die Inhalte über Git pflegen und Performance ohne JavaScript im Browser wollen; dafür fehlt eine visuelle Oberfläche für Redakteure ohne technischen Hintergrund. Für eine rein quelloffene Headless-API-Schicht gehören zuerst Strapi und Payload auf die engere Auswahl.