Architektur · Headless & APIs · Frontend-Strategien
„Wir brauchen ein Headless-CMS“ – diesen Satz hört man inzwischen häufig in Pitches und Strategiepapiere. Gleichzeitig laufen sehr viele stabile, erfolgreiche Portale weiterhin mit klassischem TYPO3-Rendering. Dieser Artikel ordnet ein, was Headless eigentlich bedeutet, wo ein Headless-Ansatz (auch mit TYPO3) echten Mehrwert bringt – und wo ein gut aufgesetztes TYPO3-System die pragmatischere Wahl ist.
Klassische CMS haben Backend und Frontend eng gekoppelt: Inhalte werden im Backend gepflegt, im Seitenbaum strukturiert und über Templates direkt als HTML ausgeliefert. Ein Headless-CMS trennt das: Das Backend liefert Inhalte primär über APIs (JSON/REST/GraphQL) aus, die Darstellung übernimmt ein oder mehrere Frontends (z. B. SPA, Native Apps, externe Systeme).
Mit TYPO3 haben Sie mehrere Optionen:
Der entscheidende Punkt: Headless ist kein Selbstzweck, sondern ein Architektur-Pattern, das bestimmte Anforderungen sehr gut, andere eher komplizierter macht.
Die Frage ist nicht „modern oder veraltet“, sondern: Welche Architektur passt zu Ihren Anforderungen, Teams und Budgets?
Klassisches TYPO3
TYPO3 liefert HTML direkt aus (Fluid-Templates), kümmert sich um Caching, Routing, Rechte & Redaktions-UX – alles in einem System.
Headless mit TYPO3 / separatem CMS
Inhalte werden über APIs ausgespielt, Frontends (Web, App, SPA) konsumieren diese und sind technisch unabhängig von TYPO3.
In der Praxis landen viele Organisationen in einem der folgenden drei Muster – bewusst oder „historisch gewachsen“:
Modell 1
TYPO3 rendert HTML, ggf. mit modernem Frontend (Tailwind, Alpine, Stimulus). Perfekt für Verbände, Behördenportale, Unternehmenswebsites.
Modell 2
TYPO3 dient als Content-Hub und liefert Inhalte via JSON/REST an ein SPA-/Frontend-Framework (z. B. React/Vue) oder weitere Kanäle.
Modell 3
Teile werden klassisch durch TYPO3 gerendert, andere Bereiche (z. B. Single Page Applications, Self-Service-Portale) laufen headless über APIs.
Headless kann sehr mächtig sein – aber nur, wenn der Zusatzaufwand durch klare Mehrwerte gerechtfertigt ist. Typische Szenarien, in denen sich Headless lohnt:
In vielen Projekten wird Headless diskutiert, obwohl die Anforderungen durch ein klassisches oder leicht erweitertes TYPO3-Setup sehr gut abgedeckt werden – mit deutlich weniger Komplexität.
Siehe dazu auch Testing in TYPO3-Projekten und Performance messen & optimieren.
Viele Headless-Projekte scheitern nicht an der Technik, sondern an Organisation, Governance und Produktmanagement. Typische Probleme:
Diese Risiken lassen sich minimieren, wenn Architektur-, Governance- und Projektplanung von Anfang an zusammengedacht werden – statt „Headless“ nur als technisches Feature zu verstehen.
Bevor Sie sich auf eine Headless-Architektur festlegen, helfen diese Fragen bei einer nüchternen Bewertung:
Oft führt diese Diskussion zu hybriden Lösungen oder einem bewusst optimierten klassischen TYPO3-Setup – statt zu einem „Alles muss Headless sein“-Dogma.
Einige Fragen tauchen in Strategie- & Architekturworkshops immer wieder auf:
Ob klassisches TYPO3, Headless oder ein Hybrid-Ansatz – die richtige Architektur hängt von Ihren Zielen, Ihrem Team und Ihrer Systemlandschaft ab. In einem kurzen Erstgespräch klären wir, wo Sie stehen, welche Anforderungen Sie haben und wie eine realistische Roadmap aussehen kann – inklusive Governance, Testing und Deployment.