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: Wenn du heute ein neues Webprojekt startest und TYPO3 wählst, triffst du eine Entscheidung, die ich nicht empfehlen kann. Nicht weil TYPO3 schlechte Software wäre. Sondern weil die Kosten dieser Entscheidung in keinem vernünftigen Verhältnis zu dem stehen, was andere Systeme heute leisten: Entwicklungsaufwand, Betriebskomplexität, Recruiting und strategische Flexibilität.

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

Es gibt eine einfache Frage, die du dir vor der Wahl eines CMS stellen solltest: Wie leicht findest du 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 der Pool 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 dein Unternehmen heißt 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: Du wirst 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: Die Agentur, die deine TYPO3-Site gebaut hat, ist dein 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: Recruiting und interne Weiterbildung auf TYPO3 werden zunehmend schwerer zu rechtfertigen. Dieselben Entwicklungsbudgets könnten in Technologien fließen, die breitere Talentpools ansprechen und einfacher zu besetzen sind.

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

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: Jede Stunde Einarbeitungszeit ist eine Stunde, die nicht in dein Produkt oder deinen 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: Deine 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: Das Onboarding neuer Entwickler auf TYPO3-Projekte ist deutlich teurer und langwieriger als auf Projekte mit modernen, standardisierten Technologien. Das erhöht deine Projektkosten strukturell – und ist intern schwerer 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.

Wenn du eine Headless-Architektur planst, fang mit einem System an, das dafür gebaut wurde.

Für Startups: Wenn du heute auf TYPO3 Headless setzt, kämpfst du 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: Omnichannel ist keine Zukunftsvision mehr. Wenn du Inhalte auf der Website, in der App, im Newsletter und auf weiteren Kanälen konsistent ausspielen willst, brauchst du ein System, das dafür gebaut wurde – kein System, das das mit Erweiterungen nachbildet.

Für Konzerne: 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: keine Klicks, keine automatisierten Prozesse, sondern Vorhaben, 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: Betriebskosten, die du nicht einkalkuliert hast, 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: 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 dir an anderer Stelle.

Für Konzerne: Mehrere TYPO3-Installationen in verschiedenen Ländern oder für verschiedene Marken zu betreiben, multipliziert Betriebskosten und 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 lag 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. Für erfahrene TYPO3-Redakteure ist das kein Problem, weil sie die Logik kennen. Für alle anderen ist es ein großes Problem.

Die Onboarding-Zeiten für neue Redakteure sind bei TYPO3 deutlich 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: Wenn du als Gründer oder kleines Team die eigene Website selbst pflegen willst, wirst du 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: 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: Große Redaktionsteams, die mit TYPO3 arbeiten müssen, brauchen längere Schulungen, produzieren mehr Support-Anfragen an die IT und arbeiten weniger eigenständig. Das widerspricht dem Ziel jeder modernen Content-Organisation, die Marketing-Agilität als Wettbewerbsvorteil versteht.

Wenn du heute in TYPO3 investierst, investierst du 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 deine Website in fünf Jahren aus? Welche Integrationen brauchst du dann? Welche Kanäle bespielst du dann? Welche Technologien kennen deine Entwickler dann?

TYPO3 gibt auf diese Fragen keine guten Antworten. Nicht weil die Zukunft des Systems ungesichert wäre – 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 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: Du weißt 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: Wenn du in drei Jahren eine App bauen, einen neuen Markt erschließen oder eine KI-gestützte Suche integrieren willst, wird TYPO3 als Fundament zum Hindernis. Nicht weil es das explizit verbietet, sondern weil die Architektur nicht dafür gedacht ist.

Für Konzerne: 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: Es gibt kein Szenario, in dem TYPO3 deine 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: Die klassischen TYPO3-Stärken wie Mehrsprachigkeit, strukturierte Inhalte und Benutzerrechte decken Sanity, Strapi oder WordPress Headless heute besser und wirtschaftlicher ab. Der Grund, TYPO3 zu wählen, ist meistens Gewohnheit. Gewohnheit ist kein Architekturentscheid.

Für Konzerne: Hast du echte Enterprise-Anforderungen wie komplexe Compliance, große internationale Redaktionsteams und hohe Sicherheitsanforderungen, bist du mit Drupal besser bedient. Willst du moderne Composable-Architekturen aufbauen, bist du 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 du bestehende TYPO3-Installationen sofort ablösen solltest. 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. Ablösen solltest du sie dann, wenn es einen konkreten Anlass gibt: einen Relaunch, eine strategische Neuausrichtung, eine Anforderung, die das System strukturell nicht erfüllen kann.

Was ich sage: Wenn du heute ein neues Projekt startest und TYPO3 wählst, brauchst du sehr gute Gründe. Gewohnheit ist kein guter Grund. Vorhandene Agenturexpertise ist kein guter Grund. «Das haben wir immer so gemacht» ist kein guter Grund.

Die Beweislast liegt 2026 bei denen, die TYPO3 empfehlen – nicht bei denen, die es hinterfragen.

Du stehst vor einer CMS-Entscheidung oder planst einen Relaunch? Dann lass uns über deine Anforderungen sprechen: ehrlich, konkret und ohne Verkaufsdruck. Buch dir ein unverbindliches Erstgespräch – wir schauen gemeinsam, welches System zu deinem Projekt passt.