Ist deine TYPO3-Webseite fit für das nächste Jahr?

Die Frage "ist unsere Website noch aktuell?" wird in vielen Projekten auf eine einzige Kennzahl reduziert: Läuft die neueste TYPO3-Version, sind alle Extensions gepflegt? Wichtig – keine Frage. Wer auf einer End-of-Life-Version sitzt oder Extensions seit drei Jahren nicht angefasst hat, hat ein Sicherheits- und Wartungsproblem, das zuerst gelöst gehört. Aber Version und Patch-Level sagen nichts darüber aus, ob eine Website tatsächlich noch zeitgemäß arbeitet. Genau darum soll es hier gehen: um die Dinge, die man beim jährlichen Website-Check gern übersieht, obwohl sie über Performance, Auffindbarkeit und Zukunftsfähigkeit entscheiden.

1. Performance ist kein "Nice to have" mehr

Core Web Vitals sind längst kein SEO-Detail mehr, sondern ein handfester Wettbewerbsfaktor – sowohl für Google-Rankings als auch für die Absprungrate. Ein paar Stellen, an denen TYPO3-Websites typischerweise Performance liegen lassen:

• Bilder: Werden AVIF/WebP ausgeliefert, oder liegen noch unkomprimierte JPEGs im FAL? Skaliert TYPO3 die Bilder wirklich responsive aus, oder wird ein 4000px-Original in einen 400px-Container gequetscht?
• Caching: Sind Seiten-Cache, Zwischenlayer-Caches (Varnish, Nginx FastCGI Cache, Redis) und HTTP-Caching-Header sauber konfiguriert – oder wird bei jedem Request unnötig neu gerendert?
• Frontend-Assets: Wie viele CSS/JS-Dateien werden geladen, die aus alten Extensions oder Templates stammen, aber längst nicht mehr gebraucht werden? Bundling, als o bündelnvon Dateien, Tree-Shaking, , kritisches CSS – das sind Standardaufgaben, keine Kür.
• Hosting/Server: PHP-Version, OPcache-Konfiguration, Datenbank-Indizes – auch hier lohnt sich ein Blick unter die Haube, nicht nur auf das CMS selbst.

Eine gute Übung: Lighthouse- oder PageSpeed-Insights-Report ziehen und nicht nur auf die Gesamtnote schauen, sondern auf die einzelnen Metriken (LCP, INP, CLS) – die zeigen sehr konkret, wo es hakt.

2. Strukturierter Content statt Freitext-Wüste

Viele TYPO3-Installationen haben über Jahre Content angesammelt, der technisch im "Text mit Bild"-Element liegt, inhaltlich aber eigentlich strukturierte Daten wären: Ansprechpartner, Produktmerkmale, FAQ-Einträge, Event-Daten. Das rächt sich doppelt – Redakteure pflegen uneinheitlich, und Suchmaschinen wie KI-Systeme können den Inhalt schlechter interpretieren.

TYPO3 v13 hat hier mit Site Sets und vor allem Content Blocks einen echten Sprung gemacht: eine standardisierte API, um eigene Content-Elemente, Page Types oder Record Types ohne TCA-Frickelei zu bauen. Das Feature soll perspektivisch sogar zum Core-Feature in TYPO3 v15 LTS werden – wer heute schon strukturierte Content-Typen statt Freitext pflegt, ist also nicht nur aktuell gut aufgestellt, sondern auch für kommende Versionen vorbereitet.

Praktischer Nutzen: klar definierte Felder statt Freitext lassen sich sauber in Schema.org-Markup übersetzen, konsistent in Templates ausgeben und – siehe nächster Punkt – von KI-Systemen zuverlässiger auslesen.

3. Verändertes Nutzerverhalten durch KI-Zusammenfassungen

Das ist der Punkt, der 2027 wirklich den Unterschied macht. Google AI Overviews erreichen inzwischen mehrere Milliarden Nutzer im Monat, dazu kommen ChatGPT, Perplexity, Gemini und Co. als eigenständige Recherchekanäle. Klassische Suchergebnislisten werden zunehmend durch direkte, synthetisierte Antworten ersetzt – mit spürbaren Folgen für organischen Traffic: Gartner rechnet mit einem Rückgang des klassischen Suchvolumens um rund ein Viertel bis 2026 (Gartner-Pressemitteilung, Feb. 2024); in mehrfach zitierten älteren Gartner-Marketingprognosen ist zusätzlich von einem Rückgang des organischen Website-Traffics um bis zu 50 % bis 2028 die Rede – diese Zahl kursiert breit, eine einzelne offizielle Gartner-Quelle mit eigener URL ließ sich dafür allerdings nicht zweifelsfrei belegen, sie sollte entsprechend vorsichtig zitiert werden.

Was heißt das für eine TYPO3-Seite konkret?

• Die ersten Sätze zählen doppelt. KI-Systeme, die live nachschlagen (Perplexity, AI Overviews), bewerten vor allem den Seitenanfang – die ersten Sätze sollten die Kernfrage direkt beantworten, statt erst darauf hinzuarbeiten. Eine Content-Struktur, die erst nach drei Absätzen zum Punkt kommt, wird seltener zitiert – unabhängig davon, wie gut der Rest des Textes ist.
• Aktualität wird stärker gewichtet als früher. Inhalte mit klar erkennbarem "zuletzt aktualisiert"-Datum und regelmäßiger Pflege schneiden bei KI-Zitationen deutlich besser ab als statische Altbestände; nach aktuellen Auswertungen stammt der Großteil der KI-Overview-Zitate aus Inhalten, die in den letzten zwei Jahren veröffentlicht oder überarbeitet wurden. Ein Redaktionsplan, der alte Kernseiten regelmäßig auffrischt, ist damit kein "Nice to have" mehr.
• Strukturierte Daten und klare Semantik gewinnen an Gewicht, weil sie es Sprachmodellen leichter machen, Inhalte korrekt einzuordnen und zu zitieren, statt sie zu übergehen. Genau hier zahlt sich Punkt 2 (strukturierter Content) direkt aus.
• Google selbst bestätigt, dass die Optimierung für generative KI-Suchfeatures im Kern weiterhin klassische SEO-Grundlagen ist (Google Search Central: "AI Features and Your Website") – nur eben mit stärkerer Gewichtung von Extrahierbarkeit und Aktualität. Bemerkenswert: Google rät in seinem eigenen Leitfaden sogar explizit dazu, reine "AEO/GEO-Hacks" wie unnötige llms.txt-Dateien oder künstliches "Content-Chunking" zu ignorieren (Google: "Optimizing your website for generative AI features"). Sauberes Markup, klare Überschriftenstruktur und FAQ-Bereiche mit echten, gut formulierten Antworten sind also keine "GEO-Spielerei", sondern solide technische Hygiene.

4. KI-Crawler bewusst steuern

Ein Thema, das 2026 spürbar an Relevanz gewonnen hat: Bot-Traffic von KI-Crawlern verursacht auf vielen Seiten mittlerweile eine eigene Traffic-Kategorie, die separat betrachtet werden muss – technisch wie strategisch. Die gute Nachricht: Die großen Anbieter (OpenAI, Anthropic, Google) trennen inzwischen sauber zwischen Trainings- und Retrieval-/Such-Crawlern, sodass sich Training gezielt blockieren lässt, während die Suche weiter funktioniert. Das lohnt sich für die robots.txt zu nutzen: Trainings-Bots gezielt aussperren, sofern gewünscht, während Such- und Retrieval-Crawler (die für Sichtbarkeit in KI-Antworten sorgen) weiter Zugriff behalten.

Eine ergänzende llms.txt kann sinnvoll sein, ist aber kein Wundermittel – vor allem für dokumentationslastige Seiten, API-Referenzen oder strukturierte Produktdatenbanken eine günstige, aufwandsarme Ergänzung, aber kein Sichtbarkeits-Hebel für die generative Suche. Wer sich hier Wunder verspricht, sollte die Erwartungen etwas herunterschrauben; wer sie als kleinen, sauberen Baustein neben robots.txt, Sitemap und strukturierten Daten einordnet, macht nichts falsch.

5. Ein aufgeräumtes Backend

Das klassische, aber unterschätzte Thema. Über Jahre gewachsene TYPO3-Installationen sammeln:

• Seitenbäume mit toten Ästen, alten Kampagnen-Seiten, doppelten Test-Bereichen
• Backend-Nutzer und Gruppen mit Rechten, die niemand mehr braucht (ehemalige Mitarbeiter, Agenturen, Praktikanten)
• TypoScript-Setups mit Altlasten aus drei CMS-Generationen, die konkurrieren statt zusammenzuspielen
• Ungenutzte Extensions, die zwar installiert, aber seit Jahren nicht mehr aktiv sind – toter Code, der trotzdem Angriffsfläche bietet

Ein sauberer Seitenbaum und klare Rechtestrukturen sind kein Selbstzweck: Sie verringern die Fehlerquote im Redaktionsalltag und schließen ganz nebenbei Sicherheitslücken, die durch "vergessene" Zugänge entstehen.

6. Datenbank-Hygiene

Auch die Datenbank altert mit. Typische Kandidaten für den jährlichen Frühjahrsputz:

• Als gelöscht markierte, aber nie endgültig entfernte Datensätze (deleted=1)
• Wuchernde sys_log- und History-Tabellen, die kaum noch jemand ausliest, aber Backups aufblähen
• Verwaiste Relationen zwischen Content-Elementen, Kategorien und Dateien, die beim Löschen von Seiten nicht sauber mitgezogen wurden
• Cache-Tabellen, die nie geleert werden, obwohl sie mitunter der größte Batzen der gesamten DB-Größe sind

Kleinere DB, schnellere Backups, schnellere Migrationen bei Versions-Updates – und ein System, in dem sich Integritätsprobleme leichter finden lassen, weil nicht jeder Fehler im Datenmüll untergeht.

7. FAL: die unterschätzte Baustelle

Der File Abstraction Layer ist in der Praxis oft die unaufgeräumteste Ecke einer TYPO3-Installation:

• Dateileichen, die keiner Seite mehr zugeordnet sind, aber weiter Speicherplatz und Backup-Volumen fressen
• Duplikate desselben Bildes in drei verschiedenen Auflösungen und Dateinamen, weil beim Reimport nie aufgeräumt wurde
• Fehlende oder nichtssagende Metadaten (Alt-Texte, Titel, Beschreibungen) – schlecht für Barrierefreiheit, schlecht für Bilder-SEO, schlecht für die Auffindbarkeit über Bildersuche
• Uralte, viel zu große Originaldateien, die bei jeder Cropping-Operation unnötig Rechenzeit kosten

Ein FAL-Audit lohnt sich fast immer mehr, als man vorher denkt – gerade weil dieser Bereich selten Teil eines "normalen" Relaunch- oder Update-Projekts ist und sich Jahr für Jahr weiter aufbläht.

8. Die Redaktion: die eigentliche Fehlerquelle hinter dem FAL-Chaos

Vieles, was im FAL-Abschnitt oben technisch beschrieben ist, hat eine sehr menschliche Ursache: Redakteure, die nie systematisch eingewiesen wurden, wie Bilder, Ordnerstrukturen und Rechte im Backend eigentlich funktionieren. Das ist kein Vorwurf an die Redaktion – die meisten haben schlicht nie gelernt, worauf es ankommt, weil es ihnen nie gezeigt wurde. Ein paar Muster, die in fast jeder gewachsenen Installation auftauchen:

• Zu große Bilder werden hochgeladen, wie sie aus der Kamera oder von der Bildagentur kommen. Ein 8-MB-Foto mit 6000px Kantenlänge landet im FAL, wird im Frontend auf 400px runterskaliert – und produziert bei jedem Seitenaufruf unnötige Rechenlast und ein aufgeblähtes Backup. Ohne klare Vorgabe ("lade nichts über X MB / Y Pixel hoch") oder eine technische Leitplanke (z. B. eine Obergrenze im Upload) bleibt das Zufall.
• Der Seitenbaum im FAL wird zur Ablage nach Gefühl. Ohne feste Ordnerlogik legt jeder Redakteur Dateien dort ab, wo es ihm gerade sinnvoll erscheint – mal nach Kampagne, mal nach Jahr, mal gar nicht sortiert. Nach ein paar Jahren findet niemand mehr etwas wieder, und die Konsequenz ist fast immer: lieber neu hochladen als suchen. Genau so entstehen die Duplikate aus Punkt 7.
• Multidomain verschärft das Problem massiv. Bei mehreren Websites in einer TYPO3-Instanz (Storages pro Mandant oder ein gemeinsamer Storage für alle) fehlt Redakteuren oft das Bewusstsein, dass ein Bild, das für Domain A lizenziert oder freigegeben wurde, nicht automatisch auch auf Domain B verwendet werden darf. Bildrechte, Lizenzmodelle und Nutzungsvereinbarungen sind selten pro Domain oder Mandant sauber getrennt – und noch seltener in den FAL-Metadaten hinterlegt. Das Ergebnis: Bilder wandern querbeet zwischen Domains, ganz unabhängig davon, ob die Lizenz das eigentlich hergibt. Das ist nicht nur ein Aufräum-, sondern ein handfestes rechtliches Risiko.
• Backend-Rechte werden nicht an die Multidomain-Realität angepasst. Wenn jeder Redakteur auf jeden Storage und jede Domain zugreifen kann, ist es fast unvermeidlich, dass irgendwann etwas dort landet, wo es nicht hingehört – ein internes Dokument auf der öffentlichen Domain, ein für Domain A lizenziertes Bild auf Domain B, ein Preis- oder Rabattfeld, das eigentlich nur für einen Mandanten gilt.

Was hilft in der Praxis, ohne die Redaktion mit Technik zu überfordern:

• Klare, mandantengetrennte FAL-Storages oder zumindest Ordnerstrukturen – pro Domain oder Bereich ein eigener, klar benannter Ordner, kein gemeinsamer Wildwuchs-Ordner "Bilder".
• Backend-Nutzergruppen so einschränken, dass jeder Redakteur nur den Storage/die Ordner seiner eigenen Domain sieht – das verhindert versehentliche domänenübergreifende Verwendung strukturell, statt auf Disziplin zu hoffen.
• Pflichtfeld für Bildrechte/Lizenzquelle in den FAL-Metadaten, das beim Upload ausgefüllt werden muss – auch wenn es nur ein Freitextfeld ist. Besser eine unvollständige Angabe als gar keine.
• Ein kurzer, konkreter Redaktionsleitfaden (eine Seite reicht): maximale Upload-Größe, wo welche Bilder hingehören, wer welche Rechte für welche Domain hat. Das ersetzt keine technischen Leitplanken, senkt aber die Fehlerquote spürbar.
• Automatische serverseitige Begrenzung bei Bildgröße/Dateigröße im Upload, statt sich auf "die Redaktion wird schon dran denken" zu verlassen – Technik schlägt gute Vorsätze zuverlässig.
• Regelmäßige, kurze Auffrischungs-Schulungen, gerade nach Relaunches oder wenn neue Redakteure dazukommen – das Wissen geht sonst mit Personalwechseln verloren und die alten Probleme fangen von vorn an.

Beispiel: Redaktionsleitfaden zum Kopieren

Muss keine Hochglanz-Doku sein – ein internes Wiki-Snippet oder eine PDF-Seite reicht. Zum direkten Übernehmen und Anpassen:

Bilder hochladen – kurz & knapp

1. Maximalgröße: Lade keine Bilder über 2 MB / 2500 px Kantenlänge hoch. TYPO3 skaliert selbst herunter – große Originale bringen keinen Mehrwert, nur langsamere Seiten.
2. Ablage: Lade Bilder ausschließlich in den Ordner deiner eigenen Domain/deines Bereichs hoch (z. B. fileadmin/domain-a/bilder/). Nicht in fremde oder gemeinsame Ordner.
3. Rechte prüfen: Trage bei jedem Upload im Feld "Bildquelle/Lizenz" ein, woher das Bild stammt und ob es nur für diese Domain freigegeben ist. Kein Eintrag = nicht verwenden.
4. Vor Wiederverwendung: Bevor du ein Bild von einer anderen Domain/Kampagne übernimmst, frag kurz nach, ob die Lizenz das erlaubt. Im Zweifel: neu lizenzieren statt riskieren.
5. Alt-Text nicht vergessen: Jedes Bild braucht einen kurzen, beschreibenden Alt-Text – Pflichtfeld, keine Kür (Barrierefreiheit + Auffindbarkeit).

Wichtig ist weniger die exakte Formulierung als dass es ein Dokument gibt, auf das man verweisen kann – bei Onboarding neuer Redakteure, aber auch als Erinnerung im Alltag, wenn mal wieder ein 8-MB-Bild im Postfach landet.

9. Barrierefreiheit nicht vergessen

Mit dem Barrierefreiheitsstärkungsgesetz (BFSG) sind viele geschäftsmäßig betriebene Websites in Deutschland inzwischen zur Barrierefreiheit verpflichtet. Wer das beim letzten Relaunch nur halbherzig mitgedacht hat, sollte spätestens jetzt Kontrastwerte, Tastaturbedienbarkeit, Alt-Texte (siehe FAL-Punkt oben) und semantisches HTML prüfen. Das ist nicht nur Compliance-Thema, sondern verbessert nebenbei auch, wie gut Inhalte von Screenreadern und von KI-Systemen interpretiert werden können – sauberes semantisches Markup nützt beiden.

Checkliste für den Jahres-Check

• Core-Version und Extensions aktuell, Security-Patches eingespielt
• Core Web Vitals gemessen (nicht geschätzt) und Flaschenhälse identifiziert
• Wichtigste Content-Typen strukturiert statt als Freitext gepflegt (Content Blocks / Site Sets prüfen)
• Kernseiten liefern die Antwort in den ersten Sätzen, tragen ein Aktualisierungsdatum und werden regelmäßig gepflegt
• Strukturierte Daten (Schema.org) für zentrale Inhaltstypen vorhanden und korrekt
• robots.txt differenziert zwischen Trainings- und Such-/Retrieval-Crawlern; llms.txt als bewusste, realistisch eingeschätzte Ergänzung
• Seitenbaum, Backend-Nutzer und Rechte bereinigt
• Datenbank von Alt- und Cache-Datenmüll befreit
• FAL entrümpelt: keine Dateileichen, vollständige Metadaten und Alt-Texte
•  FAL-Storages/Ordner und Backend-Rechte sauber nach Domain/Mandant getrennt, Bildrechte in Metadaten dokumentiert
• Redaktionsleitfaden vorhanden und Redakteure zu Bildgrößen, Ablagestruktur und Domain-Rechten geschult
• Barrierefreiheit (Kontraste, Tastaturbedienung, Alt-Texte, Semantik) geprüft

Fazit

"Fit für das nächste Jahr" heißt 2027 nicht mehr nur "Update eingespielt". Es heißt: Performance, die auch unter realer Last hält; Content, der strukturiert genug ist, um sowohl von Redakteuren gepflegt als auch von Suchmaschinen und KI-Systemen verstanden zu werden; ein bewusster Umgang mit KI-Crawlern statt Zufallskonfiguration; und ein System, das im Hintergrund – Backend, Datenbank, FAL – nicht über Jahre unbeobachtet vor sich hin wächst. Die gute Nachricht: Vieles davon ist kein Neubau, sondern Aufräumarbeit. Und die zahlt sich in der Regel schneller aus, als man denkt.