Redirect-Strategie beim TYPO3 Relaunch — so vermeidet ihr SEO-Verluste

Ohne saubere Redirect-Strategie verliert ihr beim TYPO3 Relaunch Sichtbarkeit, Rankings und Traffic. Das Vorgehen: alle bestehenden URLs crawlen, ein vollständiges Mapping erstellen, Redirect-Typ festlegen (301 für permanent), in TYPO3 umsetzen und vor dem Go-live systematisch testen. Mit dem richtigen Prozess lassen sich SEO-Verluste fast vollständig vermeiden. Dieser Artikel richtet sich an IT-Verantwortliche und SEO-Teams, die einen TYPO3 Relaunch planen oder gerade mitten drin stecken.

Ein Relaunch verändert fast immer die URL-Struktur. Neue Seitenhierarchien, andere Slugs, zusammengelegte Inhalte — das ist normal. Problematisch wird es, wenn die alten URLs ins Leere laufen.

Was dann passiert:

• 404-Fehler für Besucher, die über bestehende Links oder Bookmarks kommen
• Ranking-Verluste, weil Google die Verbindung zwischen alter und neuer URL verliert
• Verlorene Backlinks, weil externe Seiten auf URLs verweisen, die nicht mehr existieren
• Einbruch im organischen Traffic, oft innerhalb weniger Tage nach Go-live

Bei TYPO3-Projekten kommt zusätzliche Komplexität dazu: Multi-Site-Setups mit mehreren Domains, mehrsprachige Seiten mit Sprach-Prefixes und Site-Konfigurationen, die das Routing beeinflussen. Je komplexer das Setup, desto wichtiger ist ein systematisches Vorgehen.

Ein 301-Redirect ist eine permanente Weiterleitung. Er signalisiert Suchmaschinen, dass die alte URL dauerhaft durch die neue ersetzt wird. Ranking-Signale wie Backlinks werden auf die neue URL übertragen.

Ein 302-Redirect ist eine temporäre Weiterleitung. Suchmaschinen behalten die alte URL im Index und übertragen keine Ranking-Signale. Die alte URL bleibt die „kanonische" Variante.

Wann welchen Typ verwenden?

• Wenn eine Seite dauerhaft umzieht (Relaunch, neue URL-Struktur) → 301
• Wenn eine Seite vorübergehend nicht erreichbar ist (Wartung, saisonale Inhalte) → 302
• Wenn ihr A/B-Tests auf verschiedene URLs laufen lasst → 302
• Wenn ihr unsicher seid → 301 (im Relaunch-Kontext ist das fast immer richtig)

Wichtig: Ein falsch gesetzter 302 bei einem Relaunch ist einer der häufigsten Fehler. Google indexiert dann weiterhin die alte URL, die neue Seite rankt nicht — und ihr verliert Zeit und Sichtbarkeit.

Bevor ihr irgendetwas weiterleitet, braucht ihr eine vollständige Liste aller URLs, die aktuell existieren und indexiert sind.

Quellen kombinieren:

• Crawl-Tool (Screaming Frog, Sitebulb): Alle erreichbaren URLs der bestehenden Seite
• Google Search Console: Alle indexierten URLs, inkl. solcher, die der Crawler nicht findet
• XML-Sitemap: Falls vorhanden, als zusätzliche Quelle
• Server-Logs: Für URLs, die Traffic bekommen, aber weder im Crawl noch in der Sitemap auftauchen (z.B. alte PDF-Links)

Tipp: Vergesst nicht die Assets — PDFs, Bilder und Dateien, auf die extern verlinkt wird. Die tauchen im Crawl auf, werden beim Mapping aber oft übersehen.

Das Mapping ist die zentrale Datei eurer Redirect-Strategie. Es ordnet jeder alten URL eine neue URL zu.

Format (CSV):

Strategien für das Mapping:

• 1:1-Mapping: Jede alte URL bekommt eine spezifische neue URL. Am sichersten, aber aufwändig.
• Pattern-basiert: Regeln für URL-Gruppen (z.B. /produkte/* → /leistungen/*). Effizient bei großen Seiten, aber fehleranfällig.
• Kombination: Pattern-Regeln für 80% der URLs, manuelles Mapping für die wichtigen 20%.

Bei einem typischen Relaunch mit 300–500 Seiten lässt sich der Großteil über 10–15 Pattern-Regeln abdecken. Die Top-Landingpages (die mit dem meisten Traffic und den meisten Backlinks) solltet ihr aber immer manuell prüfen.

Im Relaunch-Kontext ist der 301-Redirect der Standard. Setzt 302 nur ein, wenn ihr einen konkreten Grund dafür habt (und dokumentiert ihn).

Entscheidungshilfe:

• Seite existiert in neuer Form weiter → 301
• Seite wird mit einer anderen zusammengelegt → 301 (auf die zusammengeführte Seite)
• Seite wird ersatzlos entfernt → 301 auf die nächstbeste thematische Seite oder die Kategorie-Übersicht
• Seite ist nur temporär offline → 302

TYPO3 bietet seit v9 ein integriertes Redirect-Modul (EXT:redirects). Für die meisten Relaunch-Szenarien reicht das aus.

Option A: TYPO3 Core Redirect Modul

Das Modul findet ihr im Backend unter *Site Management → Redirects*. Redirects legt ihr dort manuell an. Für einen CSV-Import benötigt ihr eine Extension wie georgringer/redirect-generator — das Core-Modul selbst bietet diese Funktion nicht.

Vorteile: Kein zusätzlicher Installationsaufwand, direkte Integration in die TYPO3-Oberfläche, Unterstützung von t3://-Links (bleiben auch bei URL-Änderungen stabil).

Option B: htaccess-Regeln

Für Pattern-basierte Redirects oder wenn Redirects vor TYPO3 greifen sollen (Performance):

Vorteil: Greift auf Webserver-Ebene, bevor TYPO3 überhaupt geladen wird — schneller bei sehr vielen Redirects.

Option C: Extension

Bei komplexen Anforderungen (Regex-Patterns, Import/Export, Statistiken) kann eine spezialisierte Extension sinnvoll sein. Prüft aber, ob sie aktiv gepflegt wird und eure TYPO3-Version unterstützt.

Empfehlung: Startet mit dem Core Redirect Modul. Nutzt htaccess für die großen Pattern-Regeln. Greift nur dann zu Extensions, wenn ihr einen konkreten Bedarf habt, den die Bordmittel nicht abdecken.

Redirects auf Staging testen — nicht erst nach dem Go-live.

Test-Methoden:

• Stichproben-Check: Die 20 wichtigsten URLs manuell testen (curl, Browser, Redirect-Checker)
• Crawl auf Staging: Screaming Frog gegen die Staging-Umgebung laufen lassen, alte URLs als Liste importieren
• Alte Sitemap als Testliste: Die sitemap.xml der Live-Seite gegen Staging crawlen — jede URL muss entweder 200 oder 301 zurückgeben, keine 404

Prüfpunkte:

• [ ] Jeder Redirect führt auf eine existierende Seite (HTTP 200 oder 301, kein 404)
• [ ] Alle Redirects leiten direkt zum Ziel (max. 1 Hop, keine Ketten)
• [ ] Keine Redirect-Loops vorhanden (testen mit curl oder Browser)
• [ ] Bei mehrsprachigen Seiten: Redirects für jede Sprachvariante konfiguriert
• [ ] Redirects für PDFs und andere Assets (Bilder, Downloads) eingerichtet

Die ersten 2 Wochen nach dem Go-live sind kritisch. Richtet diese Monitoring-Punkte ein:

• Google Search Console: Crawl-Errors täglich prüfen, neue 404-Fehler sofort beheben
• Server-Logs oder 404-Monitoring: Welche URLs werden aufgerufen und enden auf 404?
• Ranking-Tracking: Organische Sichtbarkeit im Auge behalten (Search Console → Leistung)
• Backlink-Check: Externe Links auf alte URLs prüfen — werden sie korrekt weitergeleitet?

Tipp: Legt euch ein einfaches Dashboard an (Search Console + Crawl-Tool), das ihr in den ersten Wochen täglich prüft. Nach 4 Wochen reicht ein wöchentlicher Check.

Mehrsprachige Setups machen Redirects komplexer. Jede Sprache hat eigene URL-Pfade, und die Site-Konfiguration in TYPO3 steuert das Routing.

Typische Fehlerquellen:

• Sprach-Prefix vergessen: /en/old-page/ wird weitergeleitet, /de/alte-seite/ nicht
• hreflang-Konflikte: Redirect zeigt auf eine Seite, deren hreflang auf die alte URL verweist
• Site-Konfiguration überschreibt Redirect: TYPO3 Route Enhancers können das Routing beeinflussen und unerwartete Interaktionen mit Redirects verursachen — testet Redirects nach Änderungen an der Site-Konfiguration

Empfehlung: Erstellt das Redirect-Mapping pro Sprache. Prüft nach dem Go-live, ob die hreflang-Tags auf die neuen URLs zeigen, nicht auf die alten. Testet jede Sprachvariante separat.

Redirect-Ketten

Das häufigste Problem. Seite A leitet auf B, B leitet auf C. Google folgt maximal 5 Hops, aber jeder Hop kostet Crawl-Budget und verdünnt die Link-Signale.

Wie erkennen: Crawl-Tool zeigt Redirect-Ketten als Warning. Oder per curl: Wenn ihr mehr als eine 301-Antwort seht, bevor die 200 kommt, habt ihr eine Kette.

Wie vermeiden: Jeder Redirect zeigt immer auf die finale URL, nie auf eine andere Weiterleitung. Beim Update von Redirects: alte Einträge aktualisieren, nicht neue drauflegen.

Redirect-Loops

Seite A leitet auf B, B leitet zurück auf A. Der Browser zeigt „ERR_TOO_MANY_REDIRECTS". Entsteht oft bei Pattern-Regeln, die sich gegenseitig triggern.

Wie erkennen: Browser-Test oder curl. Passiert oft erst nach dem Go-live, wenn mehrere Redirect-Quellen aktiv sind (TYPO3 + htaccess + CDN).

Wie vermeiden: Redirect-Regeln an nur einer Stelle pflegen. Wenn ihr htaccess UND TYPO3-Redirects nutzt, klar dokumentieren, welche Regel wo greift.

Performance bei großen Redirect-Tabellen

Bei sehr großen Redirect-Tabellen (mehrere tausend Einträge) solltet ihr die Performance monitoren. Das TYPO3 Core Redirect Modul ist mit dem Standard-Cache-Backend für bis zu ca. 65.000 Redirects ausgelegt — darüber hinaus empfiehlt TYPO3 den Wechsel zu einem Redis-Cache-Backend.

Empfehlung: Große Pattern-Regeln in die htaccess auslagern (greifen auf Webserver-Ebene, bevor TYPO3 geladen wird). Das Core-Modul nur für individuelle Redirects nutzen. Nach 6–12 Monaten: Redirects aufräumen, die keinen Traffic mehr bekommen.

Unvollständiges Mapping

URLs mit Query-Parametern (?id=42&L=1), Trailing Slashes, Groß-/Kleinschreibung — alles Varianten, die im Mapping fehlen können.

Wie vermeiden: Crawl und Search Console kombinieren. Search Console zeigt URLs, die Google kennt — der Crawl zeigt nur, was verlinkt ist. Die Differenz sind eure blinden Flecken.

Ein mittelständisches Unternehmen hat seine TYPO3-Instanz von v11 über v12 auf v13 aktualisiert und gleichzeitig die gesamte Seitenstruktur überarbeitet — rund 400 Seiten in 3 Sprachen.

Vorgehen: Crawl + Search-Console-Export ergaben 1.200 aktive URLs. Davon ließen sich 95% über 12 Pattern-Regeln in der htaccess abdecken. Die 60 wichtigsten Landingpages (höchster Traffic und meiste Backlinks) wurden manuell gemappt. Alle Redirects liefen 2 Wochen auf Staging, bevor der Go-live stattfand.

Ergebnis: Null messbare Sichtbarkeitsverluste in den ersten 4 Wochen (Google Search Console). Zwei vergessene PDF-URLs tauchten am zweiten Tag im 404-Monitoring auf und wurden innerhalb einer Stunde nachgepflegt.