TYPO3 ist enterprise-tauglich, erprobt im harten Einsatz aber für eine andere Ära des Webs gebaut.

Das Headless-Konzept ist nachträglich angebaut

TYPO3 wurde als klassisches serverseitiges CMS entwickelt. Die native Ausgabe ist HTML, gerendert mit Fluid-Templates. Die EXT:headless-Erweiterung — gepflegt von der TYPO3-Headless-Community, nicht von der TYPO3 GmbH — verwandelt das in eine JSON-API.

Das funktioniert, und für Teams, die in TYPO3 investiert haben und Inhalte als API bereitstellen müssen, ist das ein sinnvoller Weg. Aber es ist eine Community-Erweiterung mit eigenem Release-Zyklus, eigener Kompatibilitätsfläche zu TYPO3-Core-Versionen und eigener Dokumentation. Es gibt kein SLA, keinen versionierten API-Vertrag von der TYPO3 GmbH und kein TypeScript-SDK.

b10cks wurde von Anfang an als Headless-CMS entwickelt. Die API ist das Produkt. Jede Designentscheidung — Block-Architektur, Lokalisierung, Versionierung, Webhooks — dient API-Konsumenten, nicht Template-Renderern.

Die redaktionelle Oberfläche

Das TYPO3-Backend („Backend“) ist leistungsstark und hoch konfigurierbar, aber es hat eine Lernkurve, die die meisten Teams offen zugeben. Das Content-Element-Paradigma (tt_content, TypoScript-Konfiguration, FlexForms für strukturierten Content) ist für nicht-technische Redakteure nicht intuitiv. Onboarding erfordert in der Regel strukturierte Schulungen.

TYPO3 v12 und v13 brachten Verbesserungen im Backend und eine modernisierte UI — der Fortschritt ist real. Aber das grundlegende Denkmodell — Seitenbaum, Inhalts-Spalten, TypoScript — unterscheidet sich weiterhin deutlich davon, wie moderne Content-Teams arbeiten.

Der visuelle Editor von b10cks sitzt direkt in der echten Website des Teams. Redakteure klicken auf die Elemente, die sie ändern wollen, und bearbeiten sie direkt vor Ort. Das Onboarding ist minimal, weil die Oberfläche genau das Produkt ist, das Redakteure jeden Tag nutzen.

Lokalisierung: TYPO3s echte Stärke

Hier liegt TYPO3 tatsächlich vorn. Das Lokalisierungssystem — Übersetzung auf Feldebene, Fallback-Ketten für Locale, seitenbaumbezogene Sprachstrukturen, Statusverfolgung von Übersetzungen — gehört zu den ausgereiftesten in jedem CMS. Organisationen, die 20+ Sprachen auf komplexen Seitenstrukturen verwalten, verlassen sich seit Jahrzehnten darauf.

Die Lokalisierung von b10cks ist für die meisten Praxisanforderungen robust: Übersetzung auf Feldebene, Vererbung von Locale-Einstellungen, sprachspezifische Freigabe-Workflows, Integration mit professionellen Übersetzungstools (Lokalise, Phrase, DeepL). Für Teams, die ganz neu starten, deckt es den vollen Funktionsumfang ohne Legacy-Komplexität ab.

Für Organisationen, die bereits tief komplexe TYPO3-Übersetzungsworkflows betreiben, ist die Reife-Lücke ehrlich abzuwägen.

Workspaces: TYPO3s zweite Stärke

Das Workspace-Modul von TYPO3 gehört zu den leistungsstärksten Content-Staging-Systemen im CMS-Markt. Redakteure können ganze Versionen einer Website in einem isolierten Workspace vorbereiten, mit Live-Inhalten vergleichen, in der Vorschau prüfen und gesammelt veröffentlichen — über mehrere Seiten, Content-Elemente und Sprachen hinweg gleichzeitig.

b10cks bietet Git-ähnliche Versionshistorie, Branching und atomare Releases: Du kannst mehrere Inhaltsänderungen in einer einzigen geplanten Auslieferung bündeln. Für die meisten Produkt-Content-Teams reicht das völlig aus.

Für große Redaktionen, die komplette Website-Releases als atomare Ereignisse verwalten — denk an Behördenportale oder große Nachrichtenseiten zur Wahlzeit — ist das Workspace-System von TYPO3 ein Spezialwerkzeug, das b10cks in der Tiefe nicht erreicht.

Die Developer Experience

Das Einrichten eines modernen headless TYPO3-Stacks erfordert spürbaren Aufwand: TYPO3 Core, EXT:headless-Konfiguration, TypoScript für API-Feldzuordnung, eine Integration des Frontend-Frameworks (Nuxt-TYPO3 ist die Hauptoption) sowie Konfiguration für FAL (File Abstraction Layer), Caching und CDN.

Self-hosting von b10cks:

git clone https://github.com/b10cks/cms
cd cms && docker compose up

Schon läuft ein CMS. Domain hinzufügen. Dein Frontend über das TypeScript-SDK anbinden.

Die API ist mit einer OpenAPI-Spezifikation dokumentiert. Es gibt Framework-Adapter für Next.js, Nuxt, Astro und Vue. Das Content-Modell wird auf dem unendlichen Canvas definiert und sofort in der API abgebildet.

Content-Modellierung: Seitenbäume vs. Blöcke

TYPO3 organisiert Inhalte in einem Seitenbaum: Seiten sind die primäre Entität, und Inhaltselemente leben in den Spaltenbereichen der jeweiligen Seite. Dieses Modell passt gut zu klassischen Websites, erfordert aber zusätzliche architektonische Entscheidungen für Content-as-a-Service-Szenarien (gemeinsam genutzte Inhalte über mehrere Seiten oder Kanäle hinweg).

b10cks organisiert Inhalte als Blöcke: Jeder Inhaltstyp ist ein zusammensetzbarer, wiederverwendbarer Block. Blöcke können ohne Duplizierung über Seiten und Kanäle hinweg referenziert werden. Das Content-Modell wird visuell definiert und spiegelt API-first-Denken wider: Inhalte sind nicht an einen Seitenort gebunden, sondern sind eine Ressource.