Headless TYPO3 mit Next.js: Architektur, Aufwand und wann es sich lohnt

Ich werde in Projekten fast immer dasselbe gefragt: „Können wir TYPO3 behalten und trotzdem ein schnelles, modernes Frontend bekommen?“ Die ehrliche Antwort ist Ja, aber nicht kostenlos. In diesem Beitrag zeige ich dir, wie die Architektur aussieht, was im Oktober 2026 technisch stabil ist, wo die typischen Fallstricke liegen und wann sich der Umbau für ein mittelständisches Unternehmen wirklich rechnet.

Was Headless TYPO3 eigentlich bedeutet

Headless heißt: TYPO3 kümmert sich nur noch um Inhalte, Rechte, Workflows und Mehrsprachigkeit. Das HTML für die Besucher erzeugt eine separate Anwendung, in unserem Fall Next.js. Im klassischen Setup rendert TYPO3 die Seite selbst über Fluid-Templates und TypoScript.

Für deine Redaktion ändert sich dabei wenig. Sie arbeitet weiter im gewohnten Backend mit Seitenbaum, Inhaltselementen und Freigaben. Was sich ändert, ist alles dahinter: Hosting, Deployment, Caching und die Verantwortung für das Frontend liegen jetzt in zwei Systemen statt in einem.

Der Unterschied zu einem reinen Headless CMS wie Strapi oder Contentful: TYPO3 bringt eine Seitenstruktur mit. Du bekommst nicht nur Datensätze, sondern komplette Seiten mit Navigation, Breadcrumbs, Sprachvarianten und SEO-Feldern. Das ist der eigentliche Grund, TYPO3 headless zu betreiben, statt gleich das CMS zu wechseln.

Die Architektur auf einen Blick

Das Setup besteht aus drei Teilen: TYPO3 als Content-Quelle, Next.js als Rendering-Schicht und dem Browser. Die Brücke zwischen TYPO3 und Next.js ist EXT:headless, die jede TYPO3-Seite als JSON statt als HTML ausgibt.

Next.js ruft das Seiten-JSON ab, cacht es und liefert fertiges HTML aus. Speichert die Redaktion, meldet TYPO3 das per Webhook, und Next.js verwirft genau die betroffenen Cache-Einträge. Für die Vorschau holt Next.js Inhalte ungecacht direkt aus TYPO3.

Stand Oktober 2026: Was ist stabil, was nicht?

Die wichtigste Nachricht zuerst: TYPO3 v14 LTS ist da, aber EXT:headless für v14 ist noch ein Release Candidate. Wer heute produktiv startet, muss diese Lücke bewusst einplanen.

Quellen: die TYPO3-Pressemitteilung zu v14 LTS und die Release Notes von EXT:headless 5.0.0-rc1.

Zwei Details aus dem Release Candidate solltest du kennen. Der alte PreviewController-XClass ist entfallen, weil TYPO3 v14 eine eigene Vorschau mitbringt. Und die finale Preview-Integration ist im RC noch deaktiviert. Für Redaktionen, die stark mit Vorschau und Workspaces arbeiten, ist das kein Detail, sondern ein Projektrisiko.

Auf der Next.js-Seite gilt: Halte die Version aktuell. Im Mai 2026 hat Vercel mit 16.2.6 dreizehn Sicherheitslücken auf einmal geschlossen. Ein Headless-Frontend ist ein eigenes Produkt mit eigenem Patch-Zyklus.

So setzt du es um: die sechs Bausteine

In jedem Headless-TYPO3-Projekt mit Next.js musst du dieselben sechs Fragen beantworten. Wer eine davon vergisst, merkt es spätestens beim ersten Redaktionstag.

1. Routing: eine Route für alle Seiten

Den Seitenbaum pflegt die Redaktion in TYPO3. Next.js soll ihn nicht nachbauen, sondern jede URL an TYPO3 durchreichen. Dafür reicht eine optionale Catch-all-Route:

// app/[[...slug]]/page.tsx
import { notFound } from 'next/navigation';
import { getPage } from '@/lib/typo3';
import { ContentArea } from '@/components/ContentArea';

export default async function Page({ params }: { params: Promise<{ slug?: string[] }> }) {
  const { slug = [] } = await params;
  const page = await getPage('/' + slug.join('/'));
  if (!page) notFound();
  return <ContentArea elements={page.content?.colPos0 ?? []} />;
}

Mehrsprachigkeit löst du über das Sprachpräfix im Pfad, so wie es in der TYPO3-Site-Konfiguration steht. Navigation und Sprachmenü liefert EXT:headless über Data Processors mit.

2. Komponenten-Mapping: ein React-Baustein pro Inhaltselement

Jedes TYPO3-Inhaltselement kommt als JSON mit seinem Typ an. Du brauchst eine Zuordnung von Typ zu React-Komponente:

const registry = {
  text: TextBlock,
  textmedia: TextMedia,
  image: ImageGallery,
  form_formframework: Typo3Form,
};

export function ContentArea({ elements }) {
  return elements.map((el) => {
    const Component = registry[el.type] ?? Fallback;
    return <Component key={el.id} {...el.content} />;
  });
}

Hier steckt der Hauptaufwand des Projekts. Jedes eigene Inhaltselement und jede Extension mit Frontend-Ausgabe braucht ein Gegenstück in React. Für EXT:news, EXT:solr, Powermail und EXT:container gibt es Zusatz-Extensions, die das JSON liefern. Das React-Rendering baust du trotzdem selbst.

3. Caching: TYPO3 sagt Bescheid, Next.js räumt auf

Ohne Caching fragt Next.js bei jedem Aufruf TYPO3 an, und dein Performance-Vorteil ist weg. Mit Next.js 16 cachst du den Abruf explizit und hängst ein Tag daran:

import { cacheTag, cacheLife } from 'next/cache';

export async function getPage(path: string) {
  'use cache';
  cacheTag('typo3', `page:${path}`);
  cacheLife('days');
  const res = await fetch(`${process.env.TYPO3_URL}${path}`);
  return res.ok ? res.json() : null;
}

Speichert die Redaktion eine Seite, schickt TYPO3 einen Webhook an Next.js. Die Webhooks-Extension gehört seit TYPO3 v12 zum Core. Ein Route Handler in Next.js prüft das Secret und ruft revalidateTag('typo3', 'max') oder gezielt das Seiten-Tag auf.

Der heikle Teil: Ändert sich ein Datensatz, der auf vielen Seiten erscheint, etwa die Navigation oder ein Footer-Element, musst du breiter invalidieren. Plane das von Anfang an mit ein.

4. Vorschau: Draft Mode und Workspaces

Redaktionen wollen sehen, was sie vor der Freigabe ändern. In Next.js aktivierst du dafür den Draft Mode über eine abgesicherte Route und holst Inhalte dann ungecacht direkt aus TYPO3. Die Vorschau-Links im TYPO3-Backend müssen auf die Next.js-Domain zeigen. Wie oben beschrieben ist genau dieser Teil im v14-RC von EXT:headless noch offen. Prüfe ihn im Proof of Concept als Erstes.

5. Formulare und Login

EXT:headless gibt Formulare aus dem TYPO3 Form Framework als JSON-Schema aus, inklusive Validierungsregeln. Du renderst das Formular in React und schickst es an TYPO3 zurück. Finisher wie der E-Mail-Versand laufen weiter serverseitig in TYPO3. Für Frontend-Login über EXT:felogin gilt dasselbe Prinzip, nur musst du Session-Cookies über zwei Domains oder einen Proxy sauber durchreichen.

6. SEO: Nichts davon passiert automatisch

Meta-Titel, Description, Canonical, hreflang und Open-Graph-Daten liefert TYPO3 im JSON mit. Du setzt sie in Next.js über generateMetadata. Redirects aus EXT:redirects kannst du über EXT:headless auflösen lassen oder in proxy.ts abbilden, dem Nachfolger von middleware.ts in Next.js 16. Das Rendering muss serverseitig passieren, sonst sehen KI-Crawler nur eine leere Seite. Mehr dazu im Glossar zu Server-Side-Rendering.

Die XML-Sitemap kann weiter TYPO3 erzeugen, sie muss aber auf die Frontend-URLs zeigen. Prüfe nach dem Go-live mit einem Crawler, ob Statuscodes, Canonicals und hreflang identisch zum alten Stand sind. Wie du dabei vorgehst, steht im Beitrag zur Migration ohne SEO-Verlust.

Aufwand und typische Fallstricke

Der Aufwand hängt fast nur an einer Zahl: wie viele Inhaltselemente und Extensions dein Frontend abbilden muss. Die TYPO3-Seite ist mit EXT:headless schnell konfiguriert. Die Arbeit steckt im React-Frontend und in der Infrastruktur dazwischen.

Diese Fallstricke sehe ich in fast jedem Projekt:

• Alte Inhaltselemente mitschleppen. Viele TYPO3-Instanzen haben über Jahre Dutzende CTypes angesammelt, von denen die Hälfte niemand mehr nutzt. Räum vor dem Umbau auf, sonst baust du Altlasten in React nach.
• RTE-Inhalte unterschätzen. Fließtext aus dem Rich-Text-Editor kommt als HTML mit internen TYPO3-Links. Die musst du in Next.js-Links umwandeln, sonst lädt jeder Klick die Seite komplett neu.
• Vorschau zu spät testen. Wenn die Redaktion erst beim Go-live merkt, dass Workspaces nicht sauber funktionieren, wird es teuer.
• Zwei Teams, keine Verantwortung. Wenn TYPO3-Entwicklung und Frontend getrennt arbeiten, braucht ihr einen klaren JSON-Vertrag zwischen beiden. Sonst bricht bei jeder Backend-Änderung das Frontend.

Wann es sich lohnt und wann nicht

Headless lohnt sich, wenn das Frontend mehr können muss als eine Website. Für eine reine Unternehmensseite mit Blog ist klassisches TYPO3 meistens die günstigere und ehrlichere Lösung.

Ein Mittelweg, der oft übersehen wird: EXT:headless kennt einen Mixed Mode. Damit liefert dieselbe TYPO3-Site sowohl klassisches HTML als auch JSON aus. Du kannst einzelne Bereiche, etwa einen Produktfinder oder ein Kundenportal, mit Next.js bauen und den Rest erst einmal lassen, wie er ist. Das ist für viele Mittelständler der risikoärmere Einstieg als der Komplettumbau.

Und noch ein Punkt zur Ehrlichkeit: Wenn dein Team Vue statt React bevorzugt, ist Nuxt die naheliegendere Wahl. Für Nuxt gibt es mit nuxt-typo3 ein offizielles Frontend-Paket aus dem Headless-Umfeld. Bei Next.js baust du diese Schicht selbst. Welches Framework zu deinem Team passt, vergleichen wir im Beitrag Angular vs. Next.js. Die Abwägung zwischen gekoppeltem und entkoppeltem Frontend kennst du vielleicht schon aus dem Shop-Umfeld: Sie ist dieselbe wie bei Composable Commerce mit Shopware.

Fazit: erst der Use Case, dann die Architektur

Headless TYPO3 mit Next.js ist 2026 eine solide Option, aber kein Selbstzweck. TYPO3 v14 LTS gibt dir Planungssicherheit bis 2029, Next.js 16 ein ausgereiftes Caching-Modell. Die Schwachstelle liegt dazwischen: EXT:headless für v14 ist noch RC, und die Vorschau ist der Teil, den du am frühesten prüfen musst.

Mein Rat aus der Praxis: Starte mit einem Proof of Concept von zwei bis drei Wochen. Nimm die fünf wichtigsten Inhaltselemente, eine Formularseite und den Vorschau-Workflow deiner Redaktion. Danach weißt du, ob sich der Umbau lohnt, und hast eine belastbare Schätzung statt eines Bauchgefühls. Wie du das Projekt drumherum planst, zeigt unser Leitfaden zum Website-Relaunch.

Du überlegst, deine TYPO3-Website headless umzubauen, oder willst wissen, ob ein Hybrid reicht? Sprich mit uns als Agentur für Website-Relaunches. Wir schauen uns dein Setup an und sagen dir ehrlich, welcher Weg zu deinem Team und Budget passt.

Häufige Fragen zu Headless TYPO3 mit Next.js

Brauche ich für Headless TYPO3 eine Extension?

Praktisch ja. Der Standard ist EXT:headless, als Composer-Paket friendsoftypo3/headless, entwickelt mit Unterstützung von Macopedia. Sie gibt Seiten, Inhaltselemente, Navigation, Formulare und SEO-Daten als JSON aus.

Funktioniert EXT:headless mit TYPO3 v14?

Ja, mit Version 5, die seit Mai 2026 als Release Candidate vorliegt und nur TYPO3 v14 unterstützt. Für TYPO3 v12 und v13 gibt es die stabile 4.x-Linie.

Gibt es ein fertiges Next.js-Paket für TYPO3?

Ein offizielles Gegenstück zu nuxt-typo3 gibt es für Next.js nicht. Routing, Komponenten-Mapping, Caching und Vorschau baust du selbst, wie oben beschrieben.

Kann die Redaktion weiter mit Vorschau arbeiten?

Ja, über den Draft Mode von Next.js und angepasste Vorschau-Links im TYPO3-Backend. Diesen Teil solltest du aber zuerst testen, weil die v14-Integration in EXT:headless noch nicht final ist.

Ist Headless TYPO3 schneller als klassisches TYPO3?

Nicht automatisch. Schneller wird es durch sauberes Caching in Next.js. Ein gut gecachtes klassisches TYPO3 ist oft genauso schnell wie ein schlecht gecachtes Headless-Setup.

Kann ich nur einen Teil der Website headless betreiben?

Ja. Mit dem Mixed Mode von EXT:headless liefert dieselbe Site HTML und JSON aus. So setzt du einzelne Bereiche mit Next.js um und migrierst den Rest schrittweise.