Meinung: 7 Gründe, warum niemand im Jahr 2026 noch TYPO3 nutzen sollte

Ich weiß, dass dieser Artikel Widerspruch erzeugen wird. TYPO3 hat eine leidenschaftliche Community, langjährige Verfechter in Agenturen und Unternehmen, und eine Tradition, die im deutschsprachigen Raum tief verwurzelt ist. Ich respektiere das.

Und trotzdem: Wer heute ein neues Webprojekt startet und TYPO3 wählt, trifft eine Entscheidung, die ich nicht empfehlen kann. Nicht weil TYPO3 schlechte Software wäre. Sondern weil die Kosten dieser Entscheidung – in Entwicklungsaufwand, Betriebskomplexität, Recruiting und strategischer Flexibilität – in keinem vernünftigen Verhältnis zu dem stehen, was andere Systeme heute leisten.

Das ist meine Meinung. Hier sind meine Gründe.

Es gibt eine einfache Frage, die man vor der Wahl eines CMS stellen sollte: Wie leicht finde ich in zwei Jahren jemanden, der dieses System wirklich kennt?

Bei WordPress lautet die Antwort: sehr leicht, weltweit, zu vernünftigen Kosten. Bei Sanity, Payload oder Strapi: wächst schnell, weil die Systeme auf Technologien aufbauen, die Entwickler ohnehin lernen. Bei TYPO3: schwierig, teuer, und die Kurve zeigt in die falsche Richtung.

Das TYPO3-Ökosystem schrumpft. Nicht dramatisch, nicht über Nacht – aber die Zahlen sind eindeutig. Weniger neue Entwickler lernen TYPO3, weil der Einstieg aufwändig ist und die erworbenen Kenntnisse kaum auf andere Systeme übertragbar sind. Wer TYPO3 kann, kann TYPO3. Wer Next.js, TypeScript und ein modernes Headless CMS kann, kann fast alles.

Für Unternehmen bedeutet das: TYPO3-Expertise wird nicht günstiger. Sie wird teurer und seltener. Wer heute in TYPO3 investiert, baut eine strategische Abhängigkeit auf, die in fünf Jahren ein echtes Problem sein kann.

Für Startups bedeutet das: Ihr werdet für TYPO3-Entwickler entweder zu viel bezahlen oder zu lange suchen – beides ist Gift für ein Unternehmen, das schnell iterieren muss. Jede Stunde, die in die Suche nach spezialisierter Expertise fließt, fehlt beim Produkt.

Für KMU bedeutet das: Die Agentur, die eure TYPO3-Site gebaut hat, ist euer einziger Hebel. Wenn sie das Projekt nicht weiterführt, wird der Wechsel aufwändig und teuer – nicht weil die Site schlecht ist, sondern weil kaum jemand anderes sie wirklich kennt.

Für Konzerne bedeutet das: Recruiting und interne Weiterbildung auf TYPO3 wird zunehmend schwieriger zu rechtfertigen, wenn dieselben Entwicklungsbudgets in Technologien investiert werden könnten, die breitere Talentpools ansprechen und einfacher zu besetzen sind.

TYPO3 ist komplex. Das ist keine Kritik an schlechter Software-Entwicklung – es ist das Ergebnis von über zwanzig Jahren gewachsener Architektur, die immer weiterentwickelt, aber nie wirklich von Grund auf neu gedacht wurde.

TypoScript ist ein Konfigurationsformat, das keine andere Plattform kennt und das selbst erfahrene TYPO3-Entwickler gelegentlich an den Rand der Verzweiflung treibt. Die Konzepte von Pages, Content Elements, Fluid Templates und Extbase sind mächtig – und sie sind so anders als alles andere in der modernen Webentwicklung, dass ein Entwickler, der TYPO3 lernt, vor allem TYPO3 lernt.

Diese Komplexität wäre zu rechtfertigen, wenn sie einen proportionalen Mehrwert liefern würde. Für bestimmte Enterprise-Szenarien tat sie das früher. Heute liefern Drupal, Sanity oder eine maßgeschneiderte Headless-Architektur dieselbe Mächtigkeit – auf Basis von Technologien und Konzepten, die Entwickler bereits kennen, weil sie zum Standard der modernen Webentwicklung gehören.

Komplexität ist kein Qualitätsmerkmal. Sie ist ein Kostenfaktor. Und TYPO3 ist teurer in der Einarbeitung als jedes andere CMS, das ich kenne.

Für Startups bedeutet das: Jede Stunde Einarbeitungszeit ist eine Stunde, die nicht in das eigentliche Produkt oder den Marktauftritt fließt. TYPO3 zu lernen ist eine Investition, die ausschließlich in TYPO3 verwertbar ist – eine schlechte Ressourcenentscheidung in einer Phase, in der jede Entscheidung zählt.

Für KMU bedeutet das: Interne Mitarbeiter, die die Website pflegen sollen, brauchen entweder externe Unterstützung für jede nicht-triviale Änderung – oder sie müssen eine Lernkurve bewältigen, die für ein modernes CMS schlicht nicht mehr zeitgemäß ist.

Für Konzerne bedeutet das: Onboarding neuer Entwickler auf TYPO3-Projekte ist signifikant teurer und langwieriger als auf Projekte mit modernen, standardisierten Technologien. Das erhöht die Projektkosten strukturell – und ist schwerer intern zu begründen, je mehr andere Abteilungen auf agilere Stacks setzen.

Die Webentwicklung hat sich auf API-first und Headless-Architekturen zubewegt – nicht als Trend, sondern weil die Vorteile in Performance, Flexibilität und Integrationsfähigkeit real sind. Content einmal erfassen, überall ausspielen: Website, App, Newsletter, Digital Signage. Das ist die Realität moderner Content-Strategien.

TYPO3 kann Headless. Es gibt Erweiterungen, es gibt Projekte, es gibt Agenturen, die das umsetzen. Aber es ist kein System, das von Grund auf für diesen Ansatz gebaut wurde. Sanity wurde dafür gebaut. Payload wurde dafür gebaut. Strapi wurde dafür gebaut.

Der Unterschied ist spürbar: In Systemen, die API-first als Fundament haben, ist Headless die einfachste Art, sie zu nutzen. In TYPO3 ist Headless eine Erweiterung des traditionellen Rendering-Ansatzes – mit allem, was das an Komplexität und Einschränkungen mit sich bringt.

Wer eine Headless-Architektur plant, sollte mit einem System anfangen, das dafür gebaut wurde.

Für Startups bedeutet das: Wenn ihr heute auf TYPO3 Headless setzt, kämpft ihr gegen die Architektur, nicht mit ihr. Der Mehraufwand gegenüber einem System, das API-first als Fundament hat, ist von Beginn an spürbar – und wächst mit jedem Feature.

Für KMU bedeutet das: Omnichannel ist keine Zukunftsvision mehr. Wer Inhalte auf der Website, in der App, im Newsletter und auf weiteren Kanälen konsistent ausspielen will, braucht ein System, das dafür gebaut wurde – kein System, das das mit Erweiterungen nachbildet.

Für Konzerne bedeutet das: Enterprise-Content-Strategien mit internationalen Märkten, mehreren Marken und verschiedenen digitalen Touchpoints verlangen eine API-first-Architektur als Fundament. TYPO3 Headless ist an dieser Stelle eine technische Schuld, die von Anfang an eingebaut wird.

Ein TYPO3-System zu betreiben bedeutet: regelmäßige Major-Updates, die Entwicklerzeit erfordern, weil die Abwärtskompatibilität zwischen Versionen nicht immer gegeben ist. Extensions, die nicht mithalten und bei Updates Probleme verursachen. Ein Hosting-Setup, das PHP-Expertise voraussetzt und nicht von jedem Hoster vernünftig unterstützt wird.

Ich spreche nicht von Systemen, die schlecht gebaut wurden. Ich spreche vom Normalzustand gut gebauter TYPO3-Installationen. TYPO3-Updates sind Projekte. Nicht Klicks, nicht automatisierte Prozesse – Projekte, die geplant, entwickelt und getestet werden müssen.

WordPress kann dasselbe Problem haben – schlecht gebaute Installationen mit unkontrollierten Plugin-Sets sind auch dort ein Betriebsrisiko. Aber bei WordPress gibt es ein breites Ökosystem an Managed-Hosting-Anbietern, die dieses Risiko strukturell adressieren. Bei TYPO3 ist das Ökosystem enger, die Expertise teurer, und die Automatisierungsmöglichkeiten geringer.

Betriebskosten sind die Kosten, die niemand im Projektbudget einplant – und die trotzdem über zehn Jahre hinweg den größten Teil des Gesamtbudgets ausmachen.

Für Startups bedeutet das: Betriebskosten, die nicht einkalkuliert wurden, kommen trotzdem. Ein TYPO3-Major-Update, das ein paar Entwicklertage kostet, ist für ein kleines Unternehmen kein Schönheitsfehler – es ist eine ungeplante Ausgabe, die wehtut.

Für KMU bedeutet das: Der laufende Wartungsaufwand für eine TYPO3-Installation ist in der Drei-Jahres-Betrachtung fast immer höher als bei vergleichbaren WordPress- oder Headless-Setups – bei gleichem Funktionsumfang. Das Geld fehlt an anderer Stelle.

Für Konzerne bedeutet das: Mehrere TYPO3-Installationen in verschiedenen Ländern oder für verschiedene Marken zu betreiben, multipliziert die Betriebskosten und den Koordinationsaufwand erheblich. Was bei einer Installation noch handhabbar ist, wird bei fünf zum strukturellen Problem.

Ich sage das vorsichtig, weil TYPO3 die Redaktionsoberfläche in den letzten Jahren verbessert hat. Aber der Ausgangspunkt war so weit zurück, dass auch erhebliche Verbesserungen das System nicht an das herangeführt haben, was Redakteure heute zu Recht erwarten.

Der Seitenbaum, das Backend-Konzept, die Art wie Inhalte strukturiert und bearbeitet werden – alles davon trägt die DNA eines Systems, das für eine andere Ära des Webs gebaut wurde. Das ist für erfahrene TYPO3-Redakteure kein Problem, weil sie die Logik kennen. Es ist ein großes Problem für alle anderen.

Onboarding-Zeiten für neue Redakteure sind bei TYPO3 signifikant höher als bei WordPress, Sanity oder modernen Alternativen. In Unternehmen mit wechselnden Teams, Freelancern oder abteilungsübergreifender Website-Pflege ist das ein echter Kostenfaktor.

Für Startups bedeutet das: Wer als Gründer oder kleines Team die eigene Website selbst pflegen will, wird mit TYPO3 früh frustriert sein. Die Redaktionsoberfläche ist nicht für Menschen ohne Systemkenntnis gebaut – das kostet Zeit, die woanders fehlt.

Für KMU bedeutet das: Jedes Mal, wenn ein neuer Mitarbeiter die Website pflegen soll, beginnt eine Einarbeitungsphase, die bei modernen Systemen schlicht nicht so lang ist. Das summiert sich über Jahre zu echten Kosten – und zu echter Frustration im Team.

Für Konzerne bedeutet das: Große Redaktionsteams, die mit TYPO3 arbeiten müssen, brauchen längere Schulungen, produzieren mehr Support-Anfragen an die IT und sind weniger in der Lage, eigenständig zu arbeiten. Das widerspricht dem Ziel jeder modernen Content-Organisation, die Marketing-Agilität als Wettbewerbsvorteil versteht.

Wer heute in TYPO3 investiert, investiert in ein System mit einem bestimmten Technologie-Stack, einer bestimmten Community und einer bestimmten Entwicklungsgeschwindigkeit.

Die Frage, die ich jedem Kunden stelle, der mit TYPO3 liebäugelt: Wie sieht Ihre Website in fünf Jahren aus? Welche Integrationen werden dann gebraucht? Welche Kanäle werden dann bespielt? Welche Technologien werden Ihre Entwickler dann kennen?

TYPO3 gibt auf diese Fragen keine guten Antworten. Nicht weil die Zukunft des Systems ungesichert ist – das ist sie nicht –, sondern weil die Richtung, in die sich moderne Webentwicklung bewegt, eine andere ist als die, für die TYPO3 optimiert wurde.

Composable Architekturen, KI-Integration, Omnichannel-Delivery, API-first – das sind keine Buzzwords. Das sind die Anforderungen, die in Projekten heute schon real sind und in drei Jahren Standard sein werden. Wer ein System wählt, das diese Anforderungen als Erweiterung statt als Fundament behandelt, baut eine strategische Bremse ein.

Für Startups bedeutet das: Ihr wisst noch nicht genau, wohin die Reise geht – und das ist richtig so. Ein System zu wählen, das maximale Flexibilität einschränkt, ist in dieser Phase die schlechteste aller Entscheidungen. TYPO3 ist das Gegenteil von Optionalität.

Für KMU bedeutet das: Wenn in drei Jahren eine App gebaut, ein neuer Markt erschlossen oder eine KI-gestützte Suche integriert werden soll, wird TYPO3 als Fundament zum Hindernis – nicht weil es das explizit verbietet, sondern weil die Architektur nicht dafür gedacht ist.

Für Konzerne bedeutet das: Strategische Agilität ist kein Luxus, sondern Wettbewerbsfähigkeit. Wer auf eine Plattform setzt, die Integrations- und Innovationszyklen verlangsamt, zahlt dafür nicht in der IT-Abteilung – sondern im Markt.

Das ist der Kern meiner Kritik – und er ist gleichzeitig das stärkste Argument.

TYPO3 war lange die Antwort auf eine bestimmte Klasse von Anforderungen: große, mehrsprachige Enterprise-Websites mit komplexen Benutzerrechten, langen Redaktionsprozessen und hohen Sicherheitsanforderungen. Das war ein echter Vorteil, weil es damals kaum Alternativen gab, die diese Anforderungen erfüllten.

Heute gibt es sie. Drupal ist für echte Enterprise-Anforderungen mit hohen Compliance-Anforderungen und großen Redaktionsteams die bessere Wahl – es ist in diesem Segment tiefer verankert, hat eine klarere Enterprise-Roadmap und wird von mehr großen Organisationen weltweit eingesetzt. Sanity ist die bessere Wahl für komplexe, mehrsprachige Inhaltsmodelle mit Omnichannel-Anspruch. Eine Headless-Architektur mit Next.js und einem modernen CMS ist die bessere Wahl für alles, was Performance und Flexibilität priorisiert.

TYPO3 ist nicht schlechter geworden. Die Alternativen sind besser geworden. Das ist der Unterschied.

Für Startups bedeutet das: Es gibt kein Szenario, in dem TYPO3 die erste Wahl sein sollte. WordPress für schnelle Markteintritte, Sanity für ambitionierte Content-Strategien, Payload für enge CMS-App-Verzahnung – alle drei sind schneller, günstiger in der Einarbeitung und strategisch offener.

Für KMU bedeutet das: Die klassischen TYPO3-Stärken – Mehrsprachigkeit, strukturierte Inhalte, Benutzerrechte – werden von Sanity, Strapi oder WordPress Headless heute besser und wirtschaftlicher abgedeckt. Der Grund, TYPO3 zu wählen, ist meistens Gewohnheit. Gewohnheit ist kein Architekturentscheid.

Für Konzerne bedeutet das: Wer wirklich Enterprise-Anforderungen hat – komplexe Compliance, große internationale Redaktionsteams, hohe Sicherheitsanforderungen –, ist mit Drupal besser bedient. Wer moderne Composable-Architekturen aufbauen will, ist mit einem dedizierten Headless CMS besser bedient. TYPO3 ist in beiden Szenarien die zweite Wahl.

Ich sage nicht, dass TYPO3 tot ist. Es wird weiterentwickelt, es hat eine treue Community, und Systeme mit dieser Basis sterben nicht über Nacht.

Ich sage auch nicht, dass bestehende TYPO3-Installationen sofort abgelöst werden sollten. Eine gut gebaute TYPO3-Installation, die zuverlässig betrieben wird und deren Team das System kennt, ist kein Notfall. Sie ist eine Infrastruktur, die ihren Zweck erfüllt – und die dann abgelöst werden sollte, wenn es einen konkreten Anlass gibt: einen Relaunch, eine strategische Neuausrichtung, eine Anforderung, die das System strukturell nicht erfüllen kann.

Was ich sage: Wer heute ein neues Projekt startet und TYPO3 wählt, muss sehr gute Gründe haben. Gewohnheit ist kein guter Grund. Vorhandene Agenturexpertise ist kein guter Grund. „Das haben wir immer so gemacht" ist kein guter Grund.

Die Last of Proof liegt 2026 bei denen, die TYPO3 empfehlen – nicht bei denen, die es hinterfragen.