TYPO3 ist ein Headless-CMS—und das seit 20 Jahren

Die meiste Verwirrung beginnt schon bei der Definition.

Ein Headless-CMS verwaltet Inhalte und liefert sie über eine API aus, ohne eingebautes Frontend. Eine Website, eine App, ein Kiosk-Terminal, ein Sprachassistent oder ein KI-Agent holt sich die Inhalte und entscheidet selbst, wie sie aussehen.

Diese Definition beschreibt die Auslieferung: JSON über REST, GraphQL oder was auch immer nächstes Jahr kommt. Sie sagt nichts darüber, wie Inhalte modelliert, versioniert, übersetzt, freigegeben oder mit Rechten versehen werden. Das einzige Versprechen: Niemand zwingt dir HTML auf.

Deshalb ist der Begriff so schwammig. Ist ein CMS „headless“, wenn es JSON ausliefert? Oder Markdown? Oder wenn es HTML rendern kann, aber nicht muss? Streng genommen würde kein System durchgehen, das auch HTML rendert — und das sagt mehr über Marketing-Kategorien aus als über Software-Architektur.

Die Architektur, auf die es ankommt, ist strukturierter Content: Daten mit typisierten Feldern und expliziten Beziehungen, gespeichert, unabhängig von jeder Ausgabe. Headless ist nur eine der Möglichkeiten, die darauf aufbauen.

Wenn deine Inhalte so strukturiert sind, ist der Schritt zu Headless reine Konfiguration. Stecken sie in HTML-Blobs, hilft dir auch eine API obendrauf nicht viel.

In WP Engines State of Headless 2024 gaben 73 % von 1.015 befragten Unternehmen an, einen Headless-Ansatz zu nutzen — 2019 war es noch rund ein Drittel. Von denen, die es noch nicht tun, wollen 98 % das Thema innerhalb des nächsten Jahres prüfen. Storyblok meldet in seinem State of CMS 2024, dass über 99 % der Teams nach dem Umstieg Verbesserungen festgestellt haben.

Dabei solltest du im Hinterkopf behalten: Beide Umfragen stammen von Unternehmen, die selbst Headless-Lösungen verkaufen, eins davon ein WordPress-Hoster. Auch die Marktschätzungen gehen weit auseinander: Für 2025 reichen die Zahlen von 1,56 bis 3,94 Milliarden US-Dollar, je nachdem, was das jeweilige Analysehaus als headless zählt. Wenn die Größe einer Kategorie so stark von ihrer Definition abhängt, lohnt sich ein genauerer Blick auf diese Definition.

Trotzdem: Die Gründe für den Wechsel zu Headless sind echt.

• Mehr Kanäle: Websites, Apps, Kiosk-Terminals, Newsletter und inzwischen auch KI-Agenten wollen dieselben Inhalte.
• Freiheit im Frontend: Teams wollen mit React, Vue oder Astro arbeiten, nicht mit der Template-Sprache des CMS.
• Klare Zuständigkeiten: Content-Teams und Frontend-Teams können in ihrem eigenen Tempo arbeiten.

Alle drei Punkte sprechen für strukturierten Content und flexible Ausgabe. Keiner davon verlangt, dass du auf die Verwaltungsebene verzichtest — und genau dort geraten viele Headless-Projekte ins Straucheln.

Am deutlichsten wird der Unterschied, wenn du dir anschaust, wo und wie Inhalte gespeichert werden.

In WordPress steckt der Inhalt einer Seite in einem einzigen Datenbankfeld: post_content. Seit es den Block-Editor gibt, enthält dieses Feld HTML, in das Block-Markierungen als HTML-Kommentare eingebettet sind. WordPress hat seit Jahren eine REST-API, du kannst diese Inhalte also als JSON abrufen. Zurück bekommst du aber im Wesentlichen einen gerenderten HTML-String in einem JSON-Feld. Die vorhandene Struktur steckt im Blob, wo andere Systeme nichts damit anfangen können.

WordPress wurde gebaut, um Websites zu veröffentlichen, und das macht es sehr gut. Taxonomien und Plugins wie ACF oder WPGraphQL setzen echte Struktur obendrauf. Das Kernmodell bleibt trotzdem: ein Dokument mit einem Body für eine Webseite.

Damit ist WordPress nicht allein. Microsoft SharePoint speichert den kompletten Inhalt einer modernen Seite in einem einzigen Feld — als HTML, in dem die Einstellungen jedes Webparts als codiertes JSON in Attributen stecken. Die Seite ist ein Listeneintrag mit Metadatenspalten rund um diesen Blob. Joomla speichert den Text eines Beitrags als HTML in seinen Intro- und Volltextfeldern. Page Builder wie Wix und Squarespace gehen noch weiter: Inhalt und Layout sind eins, werden direkt auf der Seite bearbeitet und lassen sich kaum in eine andere Form bringen. Sie alle sind in erster Linie Seiten-Publisher. (Fairerweise: Drupal ist hier die Ausnahme. Sein Entity- und Feldmodell ist ganz ähnlich strukturiert wie das von TYPO3.)

In TYPO3 hat eine Seite kein Body-Feld. Eine Seite ist ein Knoten im Seitenbaum und ein Container für Datensätze. Jedes Inhaltselement ist eine eigene Zeile mit typisierten Feldern: Überschrift, Fließtext, Layout, Sprache, Start- und Enddatum, Zugriffsgruppe. Alles andere ist eine Beziehung. Bilder sind Referenzen auf Dateien, Kategorien sind Referenzen auf Kategorie-Datensätze, eine Übersetzung verweist auf ihr Original, und ein Inhaltselement kann auf mehreren Seiten referenziert werden. Eigene Inhaltstypen können eigene Felder und Tabellen bekommen, und ihre Beziehungen werden als Relationen in der Datenbank gespeichert statt als Links, die irgendwo im Markup vergraben sind.

Sobald Inhalte als strukturierte Daten mit expliziten Beziehungen gespeichert sind, ist die Ausgabe als JSON im Grunde nur ein weiteres Template.

TYPO3 wurde nie mit der Annahme gebaut, dass Ausgabe gleich Webseite bedeutet. Das macht heute Folgendes möglich:

• Jedes Format, dieselben Inhalte. TYPO3 kann dieselbe Seite als HTML, XML, RSS, JSON oder reinen Text ausliefern. Jedes Format ist nur eine weitere Rendering-Definition auf denselben strukturierten Datensätzen — keine doppelten Inhalte, kein zweites System.
• Templates sind nicht an HTML gebunden. Fluid, die Template-Engine von TYPO3, rendert Text. Ob dieser Text HTML, JSON oder Markdown ist, entscheidest du.
• Eine vollständige JSON-API, wenn du eine willst. Die Extension EXT:headless, gepflegt von der Community und gesponsert von Macopedia, macht aus TYPO3 eine JSON-Content-API: Seiten, Inhaltselemente, Navigation, Formulare, SEO-Metadaten, Redirects. Sie passt zu nuxt-TYPO3 für ein Vue-Frontend, funktioniert aber mit jedem Frontend.
• Beides gleichzeitig. EXT:headless hat einen Mixed Mode: Dieselbe Site antwortet Browsern mit HTML und Clients, die Accept: application/json senden, mit JSON. Du musst dich also nicht am ersten Tag entscheiden.
• Markdown für Maschinen. Unsere eigene Extension b13/ai-bots-love-markdown stellt jede Seite per Standard-Content-Negotiation als Markdown bereit. Innerhalb eines Tages nach dem Aktivieren auf b13.com ist der Bot-Traffic auf die Markdown-Version umgeschwenkt. (Mehr dazu hier.)

Für nichts davon musste TYPO3 selbst verändert werden — es kamen nur zusätzliche Ausgabedefinitionen auf denselben strukturierten Inhalten dazu. Wenn der Schritt zu Headless eine Konfigurationsänderung ist und keine Migration, dann war das System von Anfang an headless.

Die meisten Headless-Pitches sagen wenig darüber, was passiert, bevor Inhalte veröffentlicht werden.

Eine API ist die leichtere Hälfte eines CMS. Die schwierigere Hälfte regelt, wer was bearbeiten darf, wer es freigibt, wann es live geht, wie es im Kontext aussieht und welche Sprachversion zu welchem Original gehört. Auch das alles hängt an strukturierten Daten und Beziehungen: Rechte hängen an Datensätzen und Feldern, Übersetzungen sind mit ihren Originalen verknüpft.

Viele API-first-Systeme haben auf der Auslieferungsseite angefangen und bauen die Verwaltungsseite immer noch aus. Also ergänzen Teams rund um das CMS eigene Preview-Umgebungen, Freigabeschritte und Rechtelogik. TYPO3 hat auf der Verwaltungsseite angefangen:

• Visuelle Vorschau für Redakteure. Redakteure sehen ihre Inhalte gerendert im Kontext, weil TYPO3 sie rendern kann — und das funktioniert auch dann, wenn das Produktiv-Frontend entkoppelt ist.
• Workspaces. Änderungen über viele Seiten und Datensätze hinweg vorbereiten, gemeinsam in der Vorschau prüfen, durch Review-Stufen schicken und in einem Rutsch veröffentlichen.
• Zeitsteuerung. Jeder Datensatz kann eine Start- und Endzeit haben. Inhalte erscheinen und verschwinden also automatisch — pro Element, nicht nur pro Seite.
• Rechte bis ins Detail. Zugriff pro Seitenbaum, pro Tabelle, pro Feld, pro Sprache. Große Organisationen mit Hunderten von Redakteuren arbeiten genau damit.
• Lokalisierung als Teil des Modells. Übersetzungen sind Datensätze, die mit ihrem Original verknüpft sind. So weißt du immer, was woraus übersetzt wurde und welche Übersetzungen veraltet sind.

Große Organisationen wählen ein CMS genau wegen dieser Funktionen. In TYPO3 sind sie Teil des Core und funktionieren gleich, egal ob die Ausgabe HTML ist, JSON oder ein Format, das es noch gar nicht gibt.

Die erste Generation von Headless-CMS lieferte eine API und einen formularbasierten Editor — die größte Lücke war die Vorschau. Die meisten Frontends waren Static Site Generators, einen Entwurf zu sehen hieß also: auf einen Build warten. Netlify beschreibt, wie Redakteure auf großen Sites eine Änderung speichern und mehrere Minuten warten, bevor sie sie sehen können, und auch Strapis eigenes Tutorial benennt dieses Problem. Formulare, Redirects, Sitemaps, Suche und SEO-Tags blieben ebenfalls am Projektteam hängen.

Die übliche Lösung heute ist ein Preview-Modus, den Entwickler ins Frontend einbauen: eine Draft-Mode-Route, geheime Tokens, im CMS konfigurierte Preview-URLs und meist ein separates Preview-Deployment (Contentfuls Vercel-Guide zeigt das Schritt für Schritt). Visuelles Editing kam später dazu, meist als kostenpflichtiges Add-on oder als Bridge, die du in dein eigenes Frontend integrierst:

Das sind gute Produkte, und Storyblok hatte visuelles Editing von Anfang an. Trotzdem zeigt sich ein Muster: Die Vorschau ist ein separates Deployment, das du selbst baust und hostest. Freigabe-Workflows kosten oft extra. Und deine strukturierten Inhalte liegen in der Cloud eines Anbieters, abgerechnet pro Nutzer oder pro API-Aufruf. Außerdem wechseln Anbieter den Eigentümer: Contentful, gegründet in Berlin, gehört inzwischen zu einem US-amerikanischen CRM-Konzern. Für öffentliche Auftraggeber in Europa wirft das Fragen zur digitalen Souveränität auf.

TYPO3 bringt all das seit jeher mit. Vorschau, Workspaces, Formulare, Redirects, Sitemaps und SEO-Felder sind Teil des Core. Und weil TYPO3 ein Open-Source-Projekt ist, das von seiner Community getragen wird, kann es niemand kaufen.

Ähnlich ist es mit „Composable“. Gemeint ist, digitale Angebote aus wiederverwendbaren, unabhängigen Bausteinen zusammenzusetzen statt aus monolithischen Seiten.

Genau so funktionieren TYPO3-Inhalte schon immer. Eine Seite setzt sich aus Inhaltselementen zusammen, und jedes Element ist ein eigener strukturierter Datensatz. Du kannst es auf anderen Seiten wiederverwenden, über mehrere Websites hinweg einbinden, übersetzen, ausblenden, zeitlich steuern und unabhängig versionieren. Mit unserer Extension container lassen sich Elemente in Grids und Gruppen verschachteln. Die Verschachtelung wird als Beziehung gespeichert, jedes Element bleibt also eigenständig.

Und neue Bausteine anzulegen, wird immer einfacher: mit schlanken PHP-Dateien, über Content Blocks oder über eine grafische Oberfläche für Website-Betreiber.

Diese semantische Ebene wird leicht übersehen. Ein „Produkt-Teaser“ oder ein „Veranstaltungsdatum“ ist keine gestylte Box, sondern ein typisierter Datensatz mit Bedeutung und Beziehungen — und genau das brauchen Apps, Suchindizes und KI-Agenten.

Die meisten Headless-Produkte sind SaaS. Das ist bequem — bis du wissen musst, wo deine Inhalte liegen, wer sie lesen kann oder was passiert, wenn sich die Preise ändern.

TYPO3 ist Open Source unter der GPL: keine Lizenzgebühren, keine API-Kontingente, kein Anbieter, der über deine Roadmap bestimmt. Du kannst es auf eigener Hardware betreiben, in deiner eigenen Cloud oder bei einem Hosting-Partner. Jede LTS-Version bekommt planbaren Langzeit-Support. Ein Headless-Backend, das du heute aufsetzt, zwingt dich also nicht schon nächstes Jahr zur Migration.

Und TYPO3 funktioniert auch im ganz großen Maßstab. Der Government Site Builder 11, das Standard-CMS für Bundesbehörden, basiert vollständig auf TYPO3. Mehr als 500 Bundesbehörden können ihn nutzen, und sein Quellcode ist öffentlich auf Open CoDE verfügbar. Als ausschlaggebend für die Wahl von TYPO3 wurden genannt: Sicherheit, flexible Benutzerrechte, Workflow-Management sowie barrierefreie, mehrsprachige Websites.

Öffentliche Einrichtungen treffen solche Entscheidungen für Jahrzehnte. Das zeigt, wie viel Zukunft sie TYPO3 zutrauen.

Ja. TYPO3 speichert strukturierte Inhalte mit expliziten Beziehungen, unabhängig von jeder Ausgabe. Es liefert diese Inhalte auf Anfrage als JSON, Markdown oder HTML aus, und es kümmert sich seit Langem um Bearbeitung, Vorschau, Workflows, Rechte und Übersetzungen.

Es hat sich nur nie so vermarktet. Weil es standardmäßig HTML gerendert hat, sind die meisten davon ausgegangen, dass es nichts anderes kann.

Wenn du also das nächste Mal eine Shortlist für Headless-CMS erstellst, setz TYPO3 mit drauf. Es ist eine Content-Plattform, die diese Architektur hatte, lange bevor die Kategorie einen Namen bekam.