Ein Redirect-Konzept ist keine Liste von Weiterleitungen, sondern ein Regelwerk mit Ausnahmen. Wer nur eine Liste baut, übersieht die Fälle, die tatsächlich Schaden anrichten: Parameter, Paginierung, Sprachversionen und die Weiterleitungen aus früheren Relaunches.
Schritt 1 · Vollständige URL-Inventur
Eine einzelne Quelle reicht nie. Jede Quelle kennt nur einen Teil des Bestands, und die Lücken der einen sind der Kern der anderen. Vier Quellen zusammenführen:
| Quelle | Was sie liefert | Was sie übersieht |
|---|---|---|
| Crawler | alles, was intern verlinkt ist | verwaiste Seiten, alte Landingpages, PDF-Ablagen |
| XML-Sitemap | was das CMS für relevant hält | alles, was das CMS nicht kennt oder ausschließt |
| Search Console | was tatsächlich Einstiege bringt | Seiten ohne Suchsichtbarkeit |
| Serverlogs | alles, was real aufgerufen wird, inkl. alter Adressen | nichts Wesentliches; deshalb die wichtigste Quelle |
Serverlogs über zwölf Monate sind der beste Fund in diesem Schritt. Sie enthalten die alten Adressen aus früheren Relaunches, die noch verlinkt sind, aus E-Mails aufgerufen werden oder in gedruckten Unterlagen stehen, also genau die Adressen, an die im Projekt niemand denkt.
Schritt 2 · Liste bereinigen
Aus der Rohliste wird die Arbeitsliste. Diese Kategorien werden getrennt, bevor gemappt wird:
- Bereits weitergeleitete Adressen. Wenn A schon auf B zeigt und B künftig auf C, muss A direkt auf C zeigen. Ketten aus mehreren Relaunches sind ein Standardproblem. Nach zwei Generationen sind Ketten mit drei Sprüngen normal.
- Nicht indexierbare Adressen. Was ohnehin auf noindex steht oder gesperrt ist, braucht kein aufwendiges Mapping.
- Technische Adressen. Feeds, Suchergebnisseiten, Filterkombinationen, Session-URLs. Sie kommen in Logs massenhaft vor und brauchen Musterregeln, kein Einzelmapping.
- Dateien. PDFs, Bilder, Downloads. Werden regelmäßig vergessen, obwohl Datenblätter und Prospekte häufig extern verlinkt sind.
Schritt 3 · Mapping-Logik
Für jede verbleibende Adresse gilt eine von fünf Regeln, in dieser Reihenfolge geprüft:
- 1:1. Der Inhalt existiert weiter unter neuer Adresse. Der Normalfall und immer die erste Wahl.
- Zusammenführung. Mehrere alte Seiten werden zu einer neuen. Zulässig, wenn die Zielseite die Inhalte tatsächlich aufnimmt, sonst ist es ein verdeckter Löschvorgang.
- Aufteilung. Eine alte Seite wird zu mehreren neuen. Die Weiterleitung zeigt auf diejenige, die dem ursprünglichen Suchintent am nächsten kommt, nicht auf eine Übersicht.
- Nächstbeste Ebene. Kein passender Nachfolger, aber ein thematisch passender Bereich. Weiterleitung auf die Kategorie- oder Übersichtsseite.
- 410 statt Weiterleitung. Der Inhalt ist bewusst entfallen und hat keinen Nachfolger, etwa eine abgelaufene Aktion. Ein sauberer 410 ist ehrlicher und wird schneller verarbeitet als eine unpassende Weiterleitung.
Eine Weiterleitung auf die Startseite ist nur dann richtig, wenn der Inhalt tatsächlich zur Startseite gewandert ist. In allen anderen Fällen ist sie das, was Suchmaschinen als „soft 404" behandeln: kein Fehler, aber auch keine Signalübertragung. Sammelweiterleitungen auf die Startseite sind die häufigste Ursache für Verluste, die niemand bemerkt, weil nirgends ein Fehler auftaucht.
Die Mapping-Tabelle
Eine brauchbare Vorlage hat mehr als zwei Spalten. Diese Struktur hat sich bewährt und lässt sich direkt als Tabellenblatt anlegen:
| Spalte | Inhalt | Wozu |
|---|---|---|
| Alte URL | vollständig, ohne Domain | Schlüssel |
| Statuscode alt | 200, 301, 404 … | erkennt bestehende Ketten |
| Einstiege 12 Monate | organische Sitzungen | Priorisierung |
| Externe Links | Anzahl verweisender Domains | Priorisierung |
| Regel | 1:1, Zusammenführung, Aufteilung, Ebene, 410 | Nachvollziehbarkeit |
| Neue URL | Ziel | Umsetzung |
| Inhalt übernommen | ja / teilweise / nein | Content-Mapping |
| Geprüft am | Datum, Prüfer | Abnahme |
Sonderfälle
Parameter
Tracking-Parameter wie Kampagnenkennzeichen dürfen die Weiterleitung nicht verhindern und sollten an das Ziel weitergereicht werden, damit die Zuordnung in der Auswertung erhalten bleibt. Filter- und Sortierparameter dagegen brauchen eine Musterregel: entweder auf die parameterfreie Seite weiterleiten oder gezielt vom Index ausschließen.
Paginierung
Seite 2 einer Übersicht auf Seite 1 der neuen Übersicht weiterzuleiten ist vertretbar, solange die neue Übersicht dieselben Inhalte erreichbar macht. Nicht vertretbar ist es, wenn die alte Seite 2 eigenständige Rankings hält. Dann braucht es ein Einzelmapping.
Sprachversionen
Weiterleitungen bleiben innerhalb der Sprache. Eine deutsche Adresse leitet nie auf eine englische Zielseite, auch nicht übergangsweise. Automatische Weiterleitung nach Browsersprache oder Standort ist eine eigene Fehlerquelle: Sie kann dazu führen, dass Suchmaschinen nur eine Sprachversion sehen.
Groß- und Kleinschreibung, Trailing Slash
Beides sind unterschiedliche Adressen. Legen Sie eine Variante fest und leiten Sie die andere dauerhaft weiter, konsequent, für die gesamte Domain, und nicht erst dort, wo es auffällt.
Domainwechsel
Domainwechsel und Strukturänderung möglichst nicht gleichzeitig durchführen. Wenn es sich nicht vermeiden lässt: erst Domain wechseln bei identischer Struktur, dann nach vier bis sechs Wochen die Struktur ändern. Andernfalls sind zwei Ursachen gleichzeitig aktiv und Diagnose wird zum Ratespiel.
Technische Umsetzung
Weiterleitungen gehören so nah wie möglich an den Server. Je weiter oben in der Kette sie liegen, desto schneller und verlässlicher greifen sie:
- Server oder Reverse Proxy (nginx, Apache, CDN-Regeln): schnellste Variante, gut für Musterregeln und große Listen.
- Anwendungsebene (Framework-Konfiguration, CMS-Plugin): flexibler, langsamer, und abhängig davon, dass die Anwendung läuft.
- Nie clientseitig. Weiterleitungen per JavaScript oder Meta-Refresh übertragen Signale schlechter und sind für Nutzer langsamer.
Immer 301 (dauerhaft), nicht 302 (temporär), außer die Änderung ist tatsächlich temporär. Große Listen gehören in eine gepflegte Zuordnungsdatei, nicht in tausende Einzelregeln, sonst leidet die Antwortzeit messbar.
Schritt 4 · Testen
Vor dem Go-Live auf der Staging-Umgebung, danach unmittelbar live:
- Jede alte URL aus der Inventur automatisiert aufrufen und Statuscode plus Endziel protokollieren
- Keine Kette mit mehr als einem Sprung
- Kein Ziel mit Statuscode 404 oder 5xx
- Kein 302, wo 301 gemeint ist
- Stichprobe der Prioritätsseiten inhaltlich prüfen: Ist der erwartete Inhalt dort?
- Test mit und ohne Trailing Slash, mit und ohne www, http und https
Der Test gehört als Freigabekriterium in den Vertrag. Ohne diese Kopplung wird er erfahrungsgemäß zur Fleißaufgabe, die unter Termindruck entfällt.
Die häufigsten Fehler
- Die URL-Inventur stammt nur aus dem Crawler, alte Adressen fehlen komplett.
- Sammelweiterleitung auf die Startseite für alles, was nicht zugeordnet wurde.
- Ketten aus früheren Relaunches werden nicht aufgelöst.
- PDFs und Downloads werden vergessen.
- 302 statt 301, weil das Testsystem so konfiguriert war.
- Weiterleitungen zeigen auf Staging-Adressen, die live nicht existieren.
- Das Mapping ist korrekt, aber der Inhalt fehlt auf der Zielseite.
- Niemand prüft nach dem Go-Live, ob die Regeln tatsächlich greifen.
Wie sich der Erfolg der Migration danach messen lässt, steht in Relaunch ohne Rankingverlust. Den vollständigen Prüfplan finden Sie in Website-Migration testen. Als Leistung buchbar ist das Ganze unter SEO-Migration.