Redaktion, Mehrsprachigkeit und Anwendungslogik vergleichen
Ein Länderauftritt mit vielen Redaktionen stellt andere Anforderungen als ein Produktportal mit Login. Bei einem Magazin steht die Veröffentlichung im Mittelpunkt. Bei einer Fachanwendung sind Inhalte ein Teil eines größeren Datenmodells. Diese Unterschiede sollten die Auswahl bestimmen.
Wir vergleichen die sieben CMS, die wir auf unseren Leistungsseiten näher vorstellen. Headless ist dabei kein weiteres Produkt: Es beschreibt die Trennung von Inhaltsverwaltung und Ausspielung. Mehrere der Systeme können sowohl klassische Websites als auch getrennte Frontends unterstützen.
Der Funktionsvergleich
Die Tabelle zeigt, wie eine Funktion umgesetzt wird – nicht nur, ob sie theoretisch möglich ist. „Erweiterung“ bedeutet zusätzlichen Integrations- und Wartungsaufwand. „Konfiguration“ setzt ebenfalls Projektarbeit voraus. Bei kommerziellen Editionen und Cloud-Tarifen muss der genaue Umfang im Angebot geprüft werden.
Die erste Zeile beschreibt die besondere Stärke jedes Systems: unsere Einordnung der dokumentierten Funktionen und ihres Zusammenspiels, kein exklusives Feature-Versprechen. Grundlage sind TYPO3 14, Drupal Core 11 und Drupal CMS 2, Neos 9, Craft 5 sowie die aktuelle Dokumentation von Storyblok, Payload und WordPress.
Bei Drupal ist die Unterscheidung wichtig: Drupal CMS ist ein vorkonfiguriertes Paket auf Basis von Drupal Core. In Version 2 gehört Canvas für visuelles Seitenbauen dazu. Canvas selbst ist kein Core-Modul.
| Kriterium | TYPO3 | Drupal | Neos | Craft | Storyblok | Payload | WordPress |
|---|---|---|---|---|---|---|---|
| Besondere Stärke | Viele Websites gemeinsam steuern: zentraler Seitenbaum, mehrere Sprachen, getrennte Redaktionsrechte und mehrstufige Workspaces in einer Installation. | Verknüpfte Inhalte auswerten: Mit Feldern, Taxonomien und Views entstehen filterbare Verzeichnisse und Listen, deren Abfragen sich im Backend konfigurieren lassen. | Im Seitenlayout redigieren und zugleich Varianten verwalten: Content Dimensions verbinden etwa Sprachen und Länder mit definierten Rückfallregeln. | Die Redaktion passend zum Inhalt aufbauen: eigene Felder und verschachtelte Matrix-Einträge, kombiniert mit frei gestalteten Templates und Live Preview. | Headless mit visueller Redaktion als Cloud-Dienst: Blöcke im angebundenen Frontend auswählen und bearbeiten; das CMS betreibt Storyblok. | CMS und Anwendung in einem Next.js-Projekt: TypeScript-Konfiguration erzeugt Datenmodell, Admin-Oberfläche und APIs; eigene Geschäftslogik nutzt die Local API. | Vom Blog bis zur Unternehmenswebsite: Block-Editor und ein breites Theme- und Plugin-Angebot verbinden redaktionelles Publizieren mit vielen vorgefertigten Bausteinen. |
| Redaktion | Seitenbaum, Inhaltselemente und Website-Vorschau | Core: Formulare und Layout Builder; Drupal CMS 2 ergänzt Canvas | Inhalte direkt in der Seitenansicht bearbeiten | Individuelle Eingabeformulare mit Live Preview | Visual Editor mit Vorschau und Blockauswahl im angebundenen Frontend | Generiertes Admin-Panel; integrierte Live Preview wird mit dem Frontend verbunden | Block-Editor für Beiträge und Seiten; mit Block-Theme auch Templates und globale Gestaltung |
| Inhaltsmodell | Seiten, Inhaltselemente und eigene Datensatztypen | Inhaltstypen, Felder, Taxonomien und Referenzen; Views für die Ausgabe | Node Types: Dokumente und Inhalte in einer Baumstruktur | Sections und Entry Types; Matrix für verschachtelte Einträge | Stories und definierte Blöcke; Inhalte über Referenzen wiederverwenden | Collections, Globals und Felder im TypeScript-Code | Beiträge, Seiten, Taxonomien und eigene Inhaltstypen; zusätzliche Felder per Code oder Plugin |
| Sprachen & Varianten | Mehrsprachigkeit und mehrere Sites im Core | Inhalts- und Konfigurationsübersetzung über Core-Module | Content Dimensions für Sprachen, Länder und weitere Varianten | Verbundene Sites; Übersetzung und Verteilung je Feld und Section konfigurierbar | Lokalisierung über Felder, Ordner oder getrennte Spaces | Lokalisierung auf Feldebene; Sprachen und Fallbacks im Code konfigurieren | Mehrsprachige Inhalte über Plugins; Multisite im Core ersetzt kein Übersetzungsmodell |
| Freigaben | Mitgelieferte Workspaces-Extension; eigene Freigabestufen konfigurierbar | Core-Module Workflows und Content Moderation; Stufen und Übergänge konfigurieren | Persönliche Workspaces, optional Review-Workspace vor Live; separate Veröffentlichungsrechte | Entwürfe, Revisionen und Veröffentlichungsrechte; zusätzliche Freigabestufen erweitern | Standardworkflow; eigene Abläufe und Stufen tarifabhängig | Entwürfe und Versionen konfigurierbar; mehrstufige Freigaben individuell oder über das Enterprise-Angebot | Entwürfe, Revisionen und Beiträge zur Prüfung; mehrstufige Freigaben über Plugins oder eigene Entwicklung |
| Zugriffsrechte | Backend-Rechte für Seiten, Tabellen, berechtigungsgesteuerte Felder und Sprachen | Rollen und Modul-Berechtigungen; Sonderregeln über zusätzliche Module | Flow-Policies und Workspace-Rollen; Regeln für Inhalte konfigurierbar | Benutzergruppen und Berechtigungen; Umfang editionsabhängig | Rollen und Inhaltszugriff; eigene Rollen tarifabhängig | Regeln bis auf Dokument- und Feldebene; Local API prüft Rechte nur bei expliziter Aktivierung | Rollen und Capabilities im Core; zusätzliche Rechte über Plugins oder eigenen Code |
| Headless & APIs | JSON-Ausgabe über Extensions; eigene APIs zusätzlich entwickelbar | JSON:API für Inhaltsdaten im Core; weitere Schnittstellen über Module | JSON-Ausgabe über Fusion; eigene APIs und zusätzliche Pakete | GraphQL im CMS; alternativ klassische Website-Ausgabe mit Twig | Content Delivery API und Management API; Frontend läuft separat | REST und GraphQL automatisch; Local API für direkte Aufrufe im Server-Code | REST API im Core; separates Frontend möglich, Vorschau und Anmeldung zusätzlich integrieren |
| Eigene Funktionen | PHP-Extensions; Extbase für Anwendungslogik, Fluid für Templates | Module und Services in PHP auf Symfony-Basis | PHP-Pakete auf Neos Flow; Fusion für die Ausgabe | PHP-Plugins und -Module auf Yii-Basis; Twig für Templates | Apps, Feld-Plugins, Webhooks und externe Backend-Dienste | TypeScript, Hooks, eigene Endpoints und React-Komponenten | PHP-Plugins und Hooks, eigene Blöcke und Themes |
| Betrieb & Lizenzmodell | Open Source; Hosting und Wartung separat planen | Open Source; Hosting und Wartung separat planen | Open Source; Hosting und Wartung separat planen | Solo kostenlos, Team/Pro kostenpflichtig; eigenes Hosting oder Craft Cloud | SaaS mit kostenlosen und kostenpflichtigen Tarifen; Frontend-Betrieb separat | Open-Source-Kern; Hosting separat, zusätzliche Enterprise-Angebote | Open-Source-Software von WordPress.org; Hosting und Wartung separat, manche Plugins und Themes kostenpflichtig |
TYPO3
Drupal
Neos
Craft
Storyblok
Payload
Welche Kandidaten wir näher prüfen würden
Die folgenden Zuordnungen sind unsere fachliche Einordnung, keine Rangliste. Sie helfen, eine erste Auswahl einzugrenzen; die tatsächlichen Anforderungen können zu einer anderen Entscheidung führen.
- Ein Blog, Magazin oder eine Website mit etablierten Funktionen
- WordPress ist dafür ein naheliegender Kandidat: Der Block-Editor und das Angebot an Themes und Plugins liefern viele vorhandene Bausteine. Wir würden prüfen, welche Erweiterungen wirklich nötig sind und wie sie zusammenspielen. Mehrsprachigkeit und mehrstufige Freigaben brauchen zusätzliche Lösungen; sie sind keine automatisch mitgelieferten Funktionen.
- Viele Marken, Länder und Redaktionen
- TYPO3, Drupal und Neos sind naheliegende Kandidaten. Wir würden mit unterschiedlichen Zuständigkeiten, Sprachvarianten und einem echten Freigabeablauf beginnen und prüfen, wie gut das jeweilige Modell zur Organisation passt.
- Eine individuell gestaltete Unternehmenswebsite oder ein Magazin
- Craft stellt individuell aufgebaute Eingabemasken mit Live Preview in den Vordergrund, Neos das Bearbeiten direkt im Seitenlayout. Crafts Multisite-Modell ist für zusammengehörende Auftritte mit redaktionellen Überschneidungen gedacht, nicht als Verwaltung beliebiger unabhängiger Projekte. TYPO3 und Drupal kommen ebenfalls infrage – etwa bei einer vorhandenen Plattform oder entsprechenden Kompetenzen im Unternehmen.
- Mehrere Frontends, ein gemeinsamer Inhaltsbestand
- Storyblok bietet einen betriebenen Inhaltsdienst mit visueller Redaktion. Payload ist interessant, wenn die Anwendung in TypeScript und Next.js entwickelt wird und Datenmodell und Zugriffsregeln im eigenen Code liegen sollen. Auch die anderen CMS lassen sich für API-basierte Ausspielung einsetzen.
- Ein Portal mit individuellen Geschäftsregeln
- Hier vergleichen wir nicht nur die Redaktion. Nutzerkonten, Datenzugriff, Suchfunktionen, Prozesse und Schnittstellen gehören in den Prototyp. Payload, Drupal oder eine auf Neos Flow basierende Anwendung können dafür unterschiedliche Ausgangspunkte sein.
Entwicklung, Migration und laufende Kosten vergleichen
Für jedes CMS kalkulieren wir Konzeption, Inhaltsmigration, Frontend und Erweiterungen. Laufend fallen je nach System Lizenzen oder Abonnements, Hosting und Wartung an. Bei einem SaaS-CMS umfasst das Abonnement den angebotenen CMS-Dienst; individuelle Frontends und Schnittstellen müssen separat betreut werden.
Wir halten vor der Auswahl fest, welche Daten exportiert werden können, wo individueller Code liegt und wie ein anderes Team die Lösung übernehmen könnte. Das ist bei einer selbst betriebenen Installation ebenso relevant wie bei einem SaaS-Angebot.
Mit einem echten Ablauf entscheiden
Für eine belastbare Auswahl nehmen wir einen Ausschnitt Ihrer Arbeit: etwa eine Produktseite mit mehreren Sprachversionen, eine Freigabe durch zwei Rollen und einen Datenimport. Zwei geeignete Systeme werden daran geprüft. Die Redaktion arbeitet selbst mit dem Prototyp; die IT beurteilt Schnittstellen und Betrieb.
Dabei wird schnell sichtbar, ob ein scheinbar passendes Feature im Alltag zu viele Sonderwege braucht. Die Entscheidung lässt sich anschließend mit konkreten Beobachtungen begründen – statt mit der persönlichen Lieblingssoftware des Entwicklungsteams.
Eine Produktseite in mehreren Sprachen, eine Freigabe durch zwei Rollen und ein Datenimport: Mit einem solchen Prototyp lassen sich Unterschiede zwischen den CMS an der eigenen Arbeit prüfen.