Redirects beim Relaunch – meistens stiefmütterlich behandelt
500 Seiten Relaunch. Klingt nach Routine. Wird aber selten entspannter Alltag. Eigentlich geht alles glatt, bis das Redirect-Thema aufploppt. Im Projekt lagen plötzlich tausende Alt-URLs auf dem Tisch. Subpages, Parameter, uralte Verzeichnisse – querbeet. Überraschung: Die meisten davon wollte niemand freiwillig wieder anfassen. Wer sich hier nicht früh kümmert, hat später ein Problem am Hals.
Die typische Reihenfolge: Neue Seitenstruktur fertig, aber überall kursieren die alten Adressen. Backlinks, Google, Bookmarks. Überall. Fehlt die Redirect-Liste, gibt’s Ärger: Rankings futsch, Nutzer genervt, Support läuft heiß. Eigentlich simpel – jede alte URL sauber erfassen, priorisieren, in eine Mapping-Tabelle schieben. Die war im Projekt das einzige, was am Ende noch den Überblick rettete. Ohne diese Tabelle: 404-Party.
Vor dem ersten Redirect: Inventur statt Blindflug
Der erste Schritt war kein Redirect, sondern ein Komplett-Crawl. Screaming Frog, Sitebulb – alles, was URLs ausspuckt. Indexierte Seiten, PDFs, Parameter-Reste. Die Google Search Console brachte noch ein paar Leichen aus der Vergangenheit ans Licht, die nirgends mehr verlinkt waren – aber immer noch von Bots besucht wurden.
Dynamische URLs, Session-Parameter, Specials aus alten Modulen – viel Ballast, wenig Nutzen. Einiges konnte direkt raus, anderes musste gezielt de-indexiert werden. Jede vergessene Alt-URL bedeutete: Potenziell verlorene Backlinks oder Traffic. Und spätestens, wenn ein alter Blogpost wieder in Reddit oder Xing geteilt wird, rächt sich jeder Fehler.
Typischer Stolperdraht: Die Redirect-Liste kommt zu spät und ist dann noch lückenhaft. Im Projekt wurde sie von Anfang an mitgeführt – parallel zur Entwicklung. Spart Nerven. Und Ärger mit dem Chef.
Technischer Teil: 301-Redirects, aber bitte mit System
Redirect-Methode? 301. Keine Debatte. Bei mehreren tausend URLs wird’s dann aber schnell unübersichtlich. Im Projekt: Mix aus .htaccess, Nginx-Config und PHP. Alles in eine Datei kippen? Schlechte Idee. Besser: Nach Mustern sortieren. Gruppenweise abarbeiten. Performance bleibt stabil, Anpassungen sind kein Albtraum.
Nach dem Go-live: Monitoring. Logfiles laufen lassen, Redirect-Checker drüberjagen, nach doppelten Weiterleitungen fahnden. Wer da schlampig ist, bekommt Redirect-Loops oder verschachtelte Ketten – Google freut sich, Nutzer weniger.
Stolpersteine in der Praxis
Automatische Redirects nach dem Motto „Wird schon passen“? Funktioniert nie. Im Projekt sind dabei prompt Schleifen und falsche Ziele entstanden. Erst die händische Prüfung hat’s gerettet.
Kommunikation – Klassiker. Content, SEO, Entwickler: Wer nicht miteinander redet, verliert URLs. Im Projekt war wenigstens ein Projektmanager am Start, der den Überblick hielt und alle nervte, bis alles passte.
Nicht vergessen: PDFs, Bilder, eingebettete Assets. Bleiben die draußen, gibt’s hässliche Fehlermeldungen oder zerschossene Seiten. Im Projekt alles fein säuberlich in die Redirect-Tabelle – keine Ausnahmen.
Was tatsächlich geholfen hat
- Früh alles crawlen und in eine Liste werfen, auch Parameter-Kram
- Mapping-Tabelle sauber pflegen, ohne wilde Ausreißer
- Redirects nach Themen/Typen splitten, nicht alles in einen Topf
- Vor und nach dem Go-live: Testen, Schleifen suchen, Fehler rausfischen
- Monitoring: Logs, Tools, alles, was Fehler schnell anzeigt
Ergebnis: Google-Rankings blieben stabil, Traffic hat keinen Bauchklatscher gemacht. Aufwand? Klar. Aber verglichen mit dem möglichen Absturz: geschenkt.
Fazit
Redirects nur Technikthema? Schön wär’s. Meistens scheitert’s an Zeit, Überblick und Kommunikation. Wer die Redirect-Liste erst nach dem Livegang baut, kann sich auf Wochen voller Fehlermeldungen und verlorener Rankings einstellen.
Empfehlung: Redirect-Planung gehört von Anfang an in jedes Relaunch-Dokument. Technik muss schlank und wartbar bleiben. Qualitätssicherung: keine Option, sondern Pflicht. Nur so bleibt die Seite auch nach dem Relaunch sichtbar. Für Nutzer. Und für Google.
Ideal: Niemand merkt, wie viel Arbeit in der Redirect-Liste steckt. Worst Case: Alle merken’s – weil plötzlich die Hälfte der Seiten weg ist.
bye
mo
Anhänge
Zuletzt bearbeitet: