TYPO3: RealURL und Routing

Vor TYPO3 9 übernahmen Erweiterungen wie RealURL, simulate_static oder cooluri die lesbaren Pfade. Mit TYPO3 9 kam das Routing in den Kern: Jede Seite hat seither einen Slug, und für Listen und Detailseiten von Erweiterungen gibt es Route Enhancer. Wer heute eine ältere Installation übernimmt oder aktualisiert, trifft oft noch auf Spuren beider Welten. Diese Seite erklärt, wie TYPO3 Routing und URLs heute zusammenhängen und was beim Wechsel von RealURL zu beachten ist.

RealURL und die Zeit vor dem Kern-Routing

RealURL war eine Erweiterung, die Adressen umschreibt. Der Changelog von TYPO3 9.4 nennt sie zusammen mit simulate_static und cooluri als Beispiele für solche Erweiterungen und beschreibt, wo RealURL die Pfade speicherte: in der Tabelle tx_realurl_pathcache bei Version 1 und in tx_realurl_pathdata ab Version 2 ^[1]. Mit TYPO3 9.5 kamen Route Enhancer und Aspekte in den Kern, die Adressen für Seiten mit einer Site-Konfiguration bilden ^[2]. Die Dokumentation von TYPO3 9.5 beschreibt das seitenbasierte Routing als Funktion, die TYPO3 ohne Zusatz mitbringt, und setzt dafür eine Site-Konfiguration voraus ^[3].

Mit Kern-Routing braucht eine Website kein RealURL. Die Frage stellt sich bei Installationen, die von einer Version vor 9 kommen, oder bei Websites, die damals umgestellt wurden und deren Adressen seitdem nie geprüft worden sind.

Der Umstieg von RealURL auf Slugs

TYPO3 9.4 brachte einen Upgrade-Assistenten mit, der für Seiten ohne eigenen Pfad den Adressteil erzeugt. Findet er die Tabellen von RealURL, übernimmt er deren Werte und bringt sie in die Form eines Slugs mit führendem Schrägstrich. Seiten mit einem Wert im Feld alias haben Vorrang vor allen anderen und bekommen einen Slug wie /my-alias-value ^[1]. Der Changelog rät, vor dem Assistenten eine Site-Konfiguration anzulegen ^[1].

Zwei Hinweise aus der Dokumentation sind für die Suche wichtig. Der Assistent migriert ein vorher eingerichtetes RealURL-Projekt nicht vollständig, er erleichtert nur den Umstieg ^[1]. Und wer RealURL, simulate_static oder cooluri genutzt hat, muss laut Changelog damit rechnen, dass Seiten danach unter anderen Adressen erreichbar sind ^[1]. Die Dokumentation zu 9.5 empfiehlt deshalb, die erzeugten Slugs zu prüfen, wenn die Adressen nach dem Update gleich bleiben sollen ^[3].

Slugs im heutigen TYPO3

Ein Slug ist laut TYPO3 Explained ein eindeutiger Name einer Ressource, aus dem Adressen gebildet werden. Er wird klein geschrieben, berücksichtigt Unicode und enthält nur Zeichen, die in Adressen erlaubt sind. Schrägstriche innerhalb des Slugs eines Datensatzes rät die Dokumentation zu vermeiden, weil sie zu Konflikten führen können ^[4]. Den Slug einer Seite sehen und ändern Redakteure im Feld slug der Seiteneigenschaften, sofern sie Zugriff auf dieses Feld haben. Wie Slugs erzeugt werden, steht in der TCA der Tabelle pages und lässt sich in TCA/Overrides/pages.php anpassen ^[3].

Für die Suche bedeutet das: Die Adresse einer Seite ist ein eigenes Feld und hängt nicht automatisch am Seitentitel. Ändert jemand den Slug, entsteht eine neue Adresse, und die Slugs der Unterseiten passt TYPO3 in der Voreinstellung mit an ^[5]. Legen Sie deshalb bewusst fest, welche Redakteure das Feld slug bearbeiten dürfen, und erklären Sie ihnen, dass jede Änderung eine Weiterleitung nach sich zieht.

Route Enhancer und Aspekte

Seiten bekommen ihre Adresse über den Slug. Für alles, was hinter dem Slug steht, sind Route Enhancer und Dekoratoren zuständig, etwa für die Detailseite einer News oder eine Endung wie .html, die TYPO3 als Dekorator behandelt ^[4]. Der Changelog 9.5 nennt die Enhancer Simple, Plugin und Extbase. Für variable Teile der Adresse gibt es Aspekte: StaticValueMapper, LocaleModifier, StaticRangeMapper, PersistedAliasMapper und PersistedPatternMapper ^[2]. Ein PersistedAliasMapper kann zum Beispiel ein Feld eines Datensatzes als sprechenden Pfad nutzen, statt die Nummer des Datensatzes in die Adresse zu schreiben ^[2].

Konfiguriert wird das Routing in der Datei config/sites/<site>/config.yaml oder, seit TYPO3 14.1, auch in einer Datei eines Site Sets wie route-enhancers.yaml. Angaben in der Site-Konfiguration haben dabei Vorrang vor denen aus einem Site Set ^[4]. Nach Änderungen an den Enhancern müssen alle Caches geleert werden ^[2].

Parameter und cHash

Bleiben Parameter in einer Adresse dynamisch, hängt TYPO3 laut Changelog 9.5 einen cHash an, der sich nicht entfernen lässt ^[2]. Adressen mit cHash und weiteren Parametern sind für Besucher schwer lesbar und können viele Varianten derselben Liste ergeben. Für die Suche lohnt es sich daher, für jede Liste und jede Detailansicht zu klären, welche Werte über einen Aspekt einen festen Pfad bekommen und welche Parameter gar nicht in den Index gehören. Hinweise zum Umgang mit unendlich vielen Adressvarianten stehen im Ratgeber Endlose URL-Räume vermeiden.

Wenn Slugs sich ändern

Ändert sich ein Slug, legt die Erweiterung redirects in der Voreinstellung selbst eine Weiterleitung von der alten auf die neue Adresse an und passt die Slugs der Unterseiten an. Diese Weiterleitungen haben kein Ablaufdatum, ihr Statuscode ist aber 307, sowohl in TYPO3 12.4 als auch im Zweig main der Dokumentation ^[5][6]. In 12.4 stehen die Einstellungen unter settings > redirects in der config.yaml der Site, im Zweig main zusätzlich in der settings.yaml eines Site Sets ^[5][6].

Google wertet nur dauerhafte Weiterleitungen mit 301 oder 308 als Signal, dass das Ziel die kanonische Adresse ist. Bei 302, 303 und 307 bleibt in der Regel die alte Adresse in den Suchergebnissen ^[7]. Stellen Sie redirects.httpStatusCode deshalb auf 301, wenn Umbenennungen dauerhaft gemeint sind. Die Einstellung gilt nur für automatisch erzeugte Weiterleitungen, den Standard für manuell angelegte legt die TCA fest ^[6].

Zur Pflege gibt es zwei Konsolenbefehle. redirects:checkintegrity sucht nach Konflikten wie Weiterleitungsschleifen, für alle Sites oder eine bestimmte, mit dem Hinweis, dass zusätzliche Enhancer zu falschen Treffern führen können. redirects:cleanup löscht Weiterleitungen nach Alter, Aufrufzahl, Domain, Pfad oder Statuscode, seit 15.0 auch als Probelauf mit --dry-run ^[6]. Nach unserer Erfahrung lohnt ein Probelauf vor jedem Aufräumen, weil sich unter alten Weiterleitungen oft solche befinden, auf die noch externe Links zeigen.

Was die Weiterleitungen für Standortseiten bedeuten, beschreibt die Seite SEO für TYPO3 auf unserem Local-SEO-Portal. Den Wechsel der Hauptversion behandelt TYPO3 Update und Migration, den Überblick gibt TYPO3 SEO Agentur. Den Unterschied der Statuscodes erklärt das Glossar unter 301-Weiterleitung.

Sie haben eine ältere TYPO3-Website mit RealURL übernommen und fragen sich, ob die Adressen nach dem Update stimmen? Stellen Sie die Frage in der gratis Sprechstunde.

1. Organisation Feature: #85928 Upgrade wizard to migrate pages to speaking URLs (Changelog 9.4). TYPO3 Documentation Team. Stand 9.4. abgerufen am 31.10.2026
2. Organisation Feature: #86365 Routing Enhancers and Aspects (Changelog 9.5). TYPO3 Documentation Team. Stand 9.5. abgerufen am 31.10.2026
3. Organisation Page based Routing (TYPO3 Explained). TYPO3 Documentation Team. Stand 9.5. abgerufen am 31.10.2026
4. Organisation Routing (TYPO3 Explained). TYPO3 Documentation Team. Stand main. abgerufen am 31.10.2026
5. Organisation Redirects: Setup. TYPO3 Documentation Team. Stand 12.4. abgerufen am 31.10.2026
6. Organisation Redirects: Setup. TYPO3 Documentation Team. Stand main. abgerufen am 31.10.2026
7. Organisation Weiterleitungen und die Google Suche. Google Search Central. Stand 20.04.2026. abgerufen am 31.10.2026

Zuletzt geprüft am 03.11.2026, nächste Prüfung spätestens im November 2027. Haben Sie einen Fehler entdeckt? Schreiben Sie uns.