Eine Website neu zu gestalten bedeutet oft, ihre URL-Struktur zu ändern. Ohne Weiterleitungsplan nimmt jede verschwindende Adresse das aufgebaute Ranking mit und schickt Besucher auf eine Fehlerseite. Das ist keine kosmetische Frage: Eine schlecht gesetzte Weiterleitung schlägt sich schon bei den ersten Durchläufen des Crawlers in verlorenem Traffic nieder. Dieser Leitfaden behandelt die Wahl der HTTP-Statuscodes, den Aufbau des Plans, die Kanonisierung, die serverseitige Umsetzung und die Kontrolle nach dem Livegang.
Was eine Weiterleitung überträgt und was ein Fehler zerstört
Eine dauerhafte Weiterleitung teilt dem Browser und der Suchmaschine mit, dass der Inhalt endgültig die Adresse gewechselt hat. Die Maschine überträgt dann den Großteil des Ranking-Signals der alten URL auf die neue und aktualisiert ihren Index. Umgekehrt gibt eine ohne Weiterleitung gelöschte URL einen 404 zurück: Die externen Links, die auf sie zeigten, werden zu Sackgassen, und das Signal, das sie brachten, verschwindet. Ein gelungener Relaunch bewahrt die Zuordnung zwischen jeder nützlichen alten Adresse und ihrem Ziel.
Die Übertragung erfolgt nicht sofort. Die Maschine muss die alte URL erneut besuchen, die Weiterleitung feststellen und dann das Ziel neu bewerten. Diese Verzögerung, von einigen Tagen bis zu einigen Wochen je nach Crawl-Frequenz, erklärt, warum ein vorübergehender Traffic-Rückgang nach einer Umstellung nichts Ungewöhnliches ist – vorausgesetzt, die Weiterleitungen sind korrekt.
301, 302, 307, 308: den richtigen Code wählen
Der HTTP-Code ist kein Detail. Er sagt der Maschine, ob die Änderung dauerhaft ist und ob sie das Signal übertragen soll. Den falschen Code zu wählen bedeutet, entweder die alte URL im Index zu behalten oder die Übertragung zu verlieren.
| Code | Art | Methode erhalten | Empfohlener Einsatz |
|---|---|---|---|
| 301 | Dauerhaft | Nicht garantiert (GET möglich erzwungen) | Relaunch, dauerhafter URL-Wechsel |
| 302 | Temporär | Nicht garantiert | Wartung, kurzer A/B-Test |
| 307 | Temporär | Ja | Temporäre Weiterleitung eines POST |
| 308 | Dauerhaft | Ja | Dauerhafter Wechsel unter Erhalt der Methode |
Für einen Relaunch ist die Regel einfach: 301 für Seiten, 308 wenn die HTTP-Methode erhalten bleiben muss. Der 302 bleibt wirklich temporären Situationen vorbehalten, da er die Maschine nicht dazu einlädt, ihren Index zu aktualisieren.
Den Weiterleitungsplan vor der Umstellung aufbauen
Der Plan wird während des Relaunchs erstellt, nie danach. Er besteht aus einer Zuordnungstabelle zwischen jeder alten URL und ihrem Ziel, erstellt aus drei abgeglichenen Quellen: dem Export der indexierten URLs aus der Search Console, der Liste der meistbesuchten Seiten und den bekannten eingehenden Links. Jede wertvolle alte URL erhält ein Ziel auf einer gleichwertigen Seite – nicht systematisch die Startseite, die das Signal verwässert.
Alle alten Seiten auf die Startseite umzuleiten ist kein Weiterleitungsplan: Es ist Signalverlust, als Lösung verkleidet.
Manche Fälle verdienen besondere Aufmerksamkeit. URLs mit Parametern (Filter, Sortierung, Kampagnen-Tracking) werden nicht einzeln umgeleitet: Besser ist eine Regel auf dem Pfad, die die Parameter je nach Rolle behält oder verwirft. Auch Paginierungsseiten, Archive und Bild-URLs ändern sich bei einem Relaunch und gehören in den Plan. Schließlich zählt die redaktionelle Kontinuität ebenso wie die technische: Eine Seite, die strukturierte Daten trug, muss auf ihrem Ziel eine gleichwertige Auszeichnung wiederfinden, sonst verschwinden die Rich Results, bis die Maschine die neue Seite neu bewertet.
Kanonisierung: eine einzige Version jeder URL erzwingen
Ein Relaunch ist der richtige Moment, doppelte Einstiegspunkte zu konsolidieren. Solange http:// und https://, die Version mit und ohne www oder die Varianten mit und ohne abschließenden Schrägstrich alle mit einem 200 antworten, sieht die Maschine mehrere URLs für denselben Inhalt und muss selbst entscheiden, welche sie indexiert. Die Wahl erzwingt man mit einer dauerhaften Weiterleitung auf eine einzige, kanonische Form. Unter nginx läuft die idiomatische Praxis über eigene Weiterleitungsblöcke statt über bedingte Tests:
# HTTP zu HTTPS: der gesamte Klartext-Traffic geht zur sicheren Version
server {
listen 80;
server_name beispiel.de www.beispiel.de;
return 301 https://www.beispiel.de$request_uri;
}
# Version ohne www zur kanonischen Version mit www
server {
listen 443 ssl;
server_name beispiel.de;
return 301 https://www.beispiel.de$request_uri;
}Dasselbe Prinzip gilt für den abschließenden Schrägstrich: eine Konvention wählen, überall dieselbe, und die andere Form mit einem 301 umleiten. Wichtig ist die Konsistenz, nicht die Wahl selbst.
Serverseitig umsetzen
Die Weiterleitung gehört auf die Ebene des Webservers, vor die Anwendung, damit sie schnell und codeunabhängig bleibt. Unter nginx wird eine exakte Zuordnung mit return 301 deklariert, ein vollständiges Muster mit rewrite:
server {
listen 443 ssl;
server_name www.beispiel.de;
# Exakte Weiterleitung, alte Seite auf neue
location = /alte-rubrik/artikel {
return 301 /neue-rubrik/artikel/;
}
# Weiterleitung eines vollständigen Musters auf einen neuen Baum
location /blog/ {
rewrite ^/blog/(.*)$ /artikel/$1 permanent;
}
}Das Ergebnis prüft man an der HTTP-Antwort: Der Code muss 301 sein und der Location-Header muss in einem einzigen Schritt auf die endgültige URL zeigen.
GET /alte-rubrik/artikel HTTP/1.1
Host: www.beispiel.de
HTTP/1.1 301 Moved Permanently
Location: https://www.beispiel.de/neue-rubrik/artikel/Eine Prüfung auf der Kommandozeile genügt, um das Verhalten ohne Browser zu bestätigen:
curl -sI https://www.beispiel.de/alte-rubrik/artikel \
| grep -i -E '^(HTTP|location)'Diese Logik gilt unabhängig vom Hosting, auch auf einem selbst gehosteten Stack, bei dem der Webserver direkt zugänglich ist.
Ketten und Schleifen vermeiden
Zwei wiederkehrende Mängel verschlechtern einen Relaunch. Die Weiterleitungskette – A leitet auf B weiter, das auf C weiterleitet – fügt Umwege hinzu, verlangsamt das Rendering und verwässert das übertragene Signal: Jede alte URL muss direkt auf ihr endgültiges Ziel zeigen. Die Schleife – A auf B, B auf A – macht die Seite unerreichbar und löst einen Browserfehler aus. Ein Weiterleitungs-Audit vor dem Livegang erkennt beide.
Nach dem Livegang kontrollieren
Die Umstellung ist nicht das Ende der Arbeit. In den folgenden Tagen sind drei Prüfungen fällig: die neue Sitemap an die Search Console übermitteln und die Indexierungsabdeckung überwachen, den Traffic verfolgen, um eine abrutschende Seite zu erkennen, und die Serverprotokolle nach noch ausgelieferten 404 durchsehen. Das Steuerungs-Dashboard, das Analytics und Search Console verbindet, macht diese Signale auf einen Blick lesbar. Eine Häufung von 404 in den Protokollen weist fast immer auf eine im Plan vergessene alte URL hin; sie wird behoben, indem man die fehlende Weiterleitung ergänzt, ohne zu warten, bis die Maschine den Fehler bemerkt.
Was bleibt
Ein Relaunch bewahrt sein Ranking, wenn der Weiterleitungsplan vor der Umstellung erstellt wird, gestützt auf echte Indexierungs- und Traffic-Daten, serverseitig als direkte 301 gesetzt und nach dem Livegang kontrolliert. Der HTTP-Code wird nach der Art der Änderung gewählt, doppelte Einstiegspunkte werden auf eine kanonische URL konsolidiert, die Ziele bleiben Seite für Seite relevant, und Ketten wie Schleifen werden im Vorfeld beseitigt. Nichts Spektakuläres: Methode, zur richtigen Zeit angewandt.
Bei den Relaunchs, die ich begleitet habe, ist die Weiterleitung nie der Schritt, der scheitert: Es ist der Plan, der fehlt. Ich halte mich an eine einfache Regel – keine URL wird gelöscht, bevor ihr Ziel schwarz auf weiß in der Zuordnungstabelle steht – und lasse in der ersten Woche jeden Tag eine 404-Kontrolle laufen. Das ist mühsam, aber genau das unterscheidet einen Relaunch, der seinen Traffic behält, von einem, der ihn versickern lässt. — Simon Janvier
Zum Weiterlesen: die Dokumentation von Google Search Central zu Weiterleitungen und ihrer Wirkung auf Crawling und Indexierung.
