Weiterleitungen und Redirect-Ketten: 301, 302, 307, 308

Was ist eine Weiterleitung und wie funktioniert sie technisch?

Bei einer Weiterleitung antwortet der Server nicht mit dem gewünschten Inhalt, sondern mit einem Statuscode aus der Gruppe 3xx und einem Location-Header, der die neue Adresse nennt. Der Client (Browser, Suchmaschinen-Crawler, Monitor, Skript) ruft die neue Adresse dann selbst ab. Der Standard dazu ist in RFC 9110 beschrieben, Abschnitt zu den Weiterleitungs-Statuscodes; eine verständliche Übersicht liefert MDN (beides in den Quellen).

HTTP/1.1 301 Moved Permanently
Location: https://www.example.de/neue-seite/

Weiterleitungen sind alltäglich und nützlich: Sie führen http:// auf https://, die Variante ohne www auf die mit www (oder umgekehrt), alte URLs nach einem Relaunch auf neue und verkürzte Adressen auf lange. Problematisch werden sie erst, wenn sie sich häufen, widersprechen oder ins Leere führen. Das ist ein klassischer Fall, in dem eine Seite für Besucher „irgendwie funktioniert“, aber langsamer und für Suchmaschinen weniger eindeutig ist (siehe auch HTTP-Statuscodes erklärt).

Welcher Statuscode ist der richtige: 301, 302, 303, 307 oder 308?

Die einfache Entscheidungsregel: Dauerhaft (alte URL wird nie wieder benutzt) → 301 oder 308. Vorübergehend (die alte URL kommt zurück) → 302 oder 307. Nach Formularversand → 303. Den Unterschied zwischen 301/302 und 307/308 brauchen Sie nur, wenn die Anfrage keine einfache GET-Anfrage ist, etwa bei Formularen oder API-Aufrufen mit POST. Für normale Seitenaufrufe genügen 301 und 302.

Zwei Praxisregeln: Erstens speichern Browser dauerhafte Weiterleitungen sehr hartnäckig, und eine fälschlich gesetzte 301 bleibt unter Umständen lange im Browser einzelner Besucher bestehen, auch wenn Sie die Regel längst korrigiert haben. Testen Sie neue Weiterleitungen deshalb zuerst mit 302 und stellen Sie erst nach erfolgreicher Prüfung auf 301 um. Zweitens kennen Suchmaschinen den Unterschied: Eine dauerhafte Weiterleitung signalisiert, dass das Ziel die URL ersetzt; wie Google damit umgeht, beschreibt die Dokumentation in Google Search Central (Quellen).

Was ist eine Redirect-Kette und warum schadet sie?

Eine Redirect-Kette liegt vor, wenn eine URL nicht direkt zum Ziel führt, sondern über mindestens eine Zwischenstation. Ein Klassiker:

http://example.de/seite
  → 301 → https://example.de/seite
  → 301 → https://www.example.de/seite
  → 301 → https://www.example.de/seite/

Drei Weiterleitungen, bevor der Inhalt kommt. Das entsteht meist, weil mehrere Regeln unabhängig voneinander gewachsen sind: eine für HTTPS, eine für www, eine für den Schrägstrich am Ende, eventuell zusätzlich eine im CMS oder CDN. Die Folgen:

• Zeit: Jeder Sprung braucht eine vollständige Anfrage samt Antwort. Auf einer neuen Verbindung (anderer Host oder Protokollwechsel) kommen Verbindungsaufbau und TLS-Handshake hinzu.
• Verlust von Signalen: Je länger die Kette, desto größer das Risiko, dass ein Crawler sie nicht vollständig verfolgt. Google gibt in der Dokumentation eine Obergrenze an, nach der das Verfolgen abbricht; die genaue Zahl prüfen Sie in Google Search Central, da sie sich ändern kann.
• Fehleranfälligkeit: Jede Station kann ausfallen oder falsch konfiguriert sein, und Fehler werden an der ersten Anfrage nicht sichtbar.
• Browsergrenze: Browser brechen nach einer festen Zahl von Weiterleitungen ab (typischerweise im Bereich von etwa 20) und zeigen ERR_TOO_MANY_REDIRECTS bzw. „Die Seite leitet zu oft weiter“.

Wie entstehen Schleifen und warum sind sie gefährlich?

Eine Weiterleitungsschleife entsteht, wenn zwei Regeln einander aufheben: A leitet auf B, B leitet auf A. Der Browser meldet „ERR_TOO_MANY_REDIRECTS“, ein Monitor meldet einen Fehler, ein Crawler gibt auf. Aus Besuchersicht ist die Seite ausgefallen, obwohl der Server antwortet (siehe Ausfallursachen von Websites). Typische Auslöser:

• HTTPS-Erzwingung hinter einem Proxy oder CDN: Der Proxy spricht mit dem Ursprungsserver per HTTP, der Server leitet „auf HTTPS“ um, der Proxy fragt erneut per HTTP an und so weiter. Gegenmittel: Dem Server über einen Header wie X-Forwarded-Proto mitteilen, dass die Verbindung außen schon HTTPS war, oder die Verbindung zwischen Proxy und Ursprung ebenfalls verschlüsseln. Beim Einsatz von CDNs führt eine Betriebsart, die nur die Besucherseite verschlüsselt, häufig zu genau diesem Fehler.
• www-Regeln in zwei Schichten: Der Server leitet auf www, das CMS auf die Variante ohne www.
• Falsche Basis-URL in WordPress oder im Shop: siteurl/home passen nicht zur tatsächlichen Adresse.
• Regeln für den Schrägstrich: Eine Regel entfernt ihn, eine andere ergänzt ihn.
• Anmelde- und Sprachweichen: Eine Weiterleitung auf die Anmeldeseite, die selbst geschützt ist.

Wie finden Sie Ketten und Schleifen mit curl?

Mit curl sehen Sie jede Station einzeln:

# Kette anzeigen: -s still, -I nur Header, -L Weiterleitungen folgen
curl -sIL http://example.de/seite | grep -iE '^(HTTP|location)'

# Typische Ausgabe:
# HTTP/1.1 301 Moved Permanently
# Location: https://example.de/seite
# HTTP/2 301
# location: https://www.example.de/seite
# HTTP/2 200

Für eine kompakte Auswertung eignen sich die Schreibvariablen von curl:

curl -sL -o /dev/null -w 'Endziel: %{url_effective}\nSprünge: %{num_redirects}\nStatus: %{http_code}\nZeit: %{time_total}s\n' http://example.de/seite

Die Zahl der Sprünge (num_redirects) sollte bei normalen URLs höchstens 1 betragen. Schleifen erkennen Sie daran, dass curl mit Maximum (50) redirects followed abbricht; mit --max-redirs 5 brechen Sie früher ab. Prüfen Sie nicht nur die Startseite, sondern auch eine tiefe URL, die Variante mit und ohne Schrägstrich, Groß-/Kleinschreibung und eine URL mit Parametern. Wichtig: Testen Sie mehrere Einstiegsvarianten: http:// und https://, mit und ohne www. Jede sollte in einem einzigen Sprung auf dieselbe Zielvariante führen.

Zu beachten bleibt, dass curl keine Weiterleitungen ausführt, die per HTML (<meta http-equiv="refresh">) oder JavaScript (window.location) erfolgen. Solche Varianten sind für Suchmaschinen und Monitore schlechter erkennbar, gelten als weniger zuverlässig und sollten, wo möglich, durch serverseitige 3xx-Weiterleitungen ersetzt werden.

Wie konfigurieren Sie saubere Weiterleitungen in nginx und Apache?

Das Muster lautet: eine Regel, die jede Variante direkt auf die kanonische Adresse umleitet (zum Beispiel https://www.example.de).

nginx

# 1. Alle HTTP-Anfragen (beide Hostnamen) direkt auf die endgültige HTTPS-Adresse
server {
    listen 80;
    server_name example.de www.example.de;
    return 301 https://www.example.de$request_uri;
}

# 2. HTTPS ohne www auf www
server {
    listen 443 ssl;
    server_name example.de;
    # ssl_certificate ... (Zertifikat muss auch example.de abdecken)
    return 301 https://www.example.de$request_uri;
}

# 3. Hauptseite
server {
    listen 443 ssl;
    server_name www.example.de;
    # ...

    # Einzelne alte URL auf neue
    location = /alte-seite/ {
        return 301 /neue-seite/;
    }
}

Bevorzugen Sie return 301 gegenüber rewrite ... permanent, wenn keine Mustererkennung nötig ist; es ist einfacher und schneller. Bei vielen Einzelweiterleitungen bietet sich eine map an:

map $request_uri $neue_url {
    default                 "";
    /alt/produkt-a/         /produkte/a/;
    /alt/produkt-b/         /produkte/b/;
}
# im server-Block:
if ($neue_url) { return 301 $neue_url; }

Apache (.htaccess)

RewriteEngine On

# HTTP und Nicht-www direkt auf https://www
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.example.de%{REQUEST_URI} [L,R=301]

# Einzelne URL
Redirect 301 /alte-seite/ https://www.example.de/neue-seite/

Hinter einem Proxy oder CDN ist %{HTTPS} off oft immer wahr, weil der Ursprungsserver die Verbindung als unverschlüsselt sieht. Das ist die Hauptursache für HTTPS-Schleifen. Prüfen Sie dann stattdessen %{HTTP:X-Forwarded-Proto}. Und: Regeln, die im Anwendungscode (WordPress, Shop, Framework) zusätzlich zu denen im Server stehen, sind eine der häufigsten Quellen für Ketten, die niemand bewusst angelegt hat. Legen Sie fest, welche Schicht für welche Weiterleitung zuständig ist.

Wie planen Sie Weiterleitungen bei Relaunch und Umzug?

Bei einem Relaunch ändern sich oft URLs. Ohne Weiterleitung laufen alte Links, Lesezeichen und Suchergebnisse auf 404-Fehlerseiten. Ein bewährter Ablauf:

1. Inventar erstellen: Alle alten URLs sammeln (Sitemap, Crawl, Server-Log, Analytics, Suchkonsole), mindestens die mit Besuchern, Verlinkungen oder Rankings.
2. Zuordnen: Jede alte URL einer passenden neuen URL zuordnen (Tabelle alt → neu). Inhaltlich entfernte Seiten auf die nächstpassende Kategorie leiten, nicht pauschal auf die Startseite.
3. Direkt weiterleiten: Immer auf die endgültige URL, nie auf eine URL, die selbst weiterleitet.
4. Vor dem Livegang testen: Mit einer Liste und einem Skript (curl in einer Schleife) prüfen, ob jede alte URL mit 301 und genau einem Sprung auf eine URL mit 200 führt.
5. Nach dem Livegang überwachen: Fehlerseiten (404) im Server-Log beobachten, Lücken in der Tabelle ergänzen.
6. Weiterleitungen lange behalten: Entfernen Sie sie nicht nach wenigen Wochen; Links und Lesezeichen bleiben lange bestehen. Je nach Erfahrung sind es mindestens einige Monate, bis zu mehreren Jahren für stark verlinkte URLs.

Ein Skript für die Stichprobe könnte so aussehen:

while read url; do
  curl -sL -o /dev/null -w "%{http_code} %{num_redirects} %{url_effective}\n" "$url"
done < alte-urls.txt

Erwartetes Ergebnis: Statuscode 200 und höchstens 1 Sprung. Abweichungen (404, 2 oder mehr Sprünge, 5xx) sind die Aufgabenliste. Eine Praxisanleitung für das gesamte Projekt finden Sie in Relaunch und Umzug überwachen.

Welche typischen Fehler passieren?

Checkliste: Weiterleitungen prüfen

1. Führen alle vier Einstiegsvarianten (http/https × mit/ohne www) in genau einem Sprung zur kanonischen Adresse?
2. Endet jede Kette bei Status 200 und nicht bei 404, 5xx oder einer Schleife?
3. Sind dauerhafte Weiterleitungen als 301/308 und nur vorübergehende als 302/307 gesetzt?
4. Haben alte, stark genutzte URLs nach einem Relaunch eine direkte Weiterleitung auf die passende neue URL?
5. Bleiben Parameter und Pfad bei der Weiterleitung erhalten, wo es nötig ist?
6. Werden Fehler- und Wartungsseiten nicht mit 3xx „versteckt“?
7. Stehen Regeln nur in einer Schicht (Server, CMS oder CDN)?
8. Wird die Kette nach jedem Deployment, Relaunch und CDN-Wechsel erneut geprüft?

Grenzen und Einordnung

Eine Prüfung von außen zeigt die Kette für eine Anfrage zu einem Zeitpunkt. Weiterleitungen können vom Standort, vom Gerät, vom Cookie-Zustand, von der Sprache oder vom User-Agent abhängen: Ein Shop leitet vielleicht Besucher aus einem Land auf eine Länderversion, Mobilgeräte auf eine andere Adresse. Ein Monitor sieht dann nur den Weg, den er selbst nimmt. Zudem sagt die Zahl der Sprünge nichts darüber, ob das Ziel inhaltlich passend ist; dafür braucht es Stichproben oder eine inhaltliche Prüfung. Für Suchmaschinen gilt zusätzlich, dass wir nur die Weiterleitung selbst prüfen können, nicht, wie eine Suchmaschine sie bewertet oder wann sie die Änderung verarbeitet.

Auch die Rolle eines Monitors ist begrenzt. Viele Monitore folgen Weiterleitungen bis zum Ziel und bewerten dessen Antwort (prüfen Sie das Verhalten in den Einstellungen Ihres Monitors). Das ist meist sinnvoll, kann aber eine fehlerhafte Zwischenstation verdecken, solange das Endergebnis stimmt. Wer die Weiterleitung selbst absichern will, überwacht deshalb zusätzlich die Zieladresse und prüft den Inhalt (siehe Grenzen automatischer Website-Prüfungen).

Wie setzen Sie das mit UPTIMESHIELD um?

Der Sofort-Report prüft unter anderem die Weiterleitung von HTTP auf HTTPS und das Verhalten der www-Variante sowie, wie sich die Seite bei einer nicht vorhandenen Adresse verhält (404-Prüfung); die Ergebnisse stehen in der Maßnahmenliste. Für die laufende Überwachung legen Sie nach der kostenlosen Registrierung einen HTTP-/HTTPS-Monitor auf die kanonische Adresse an (Monitortypen siehe Monitortypen) und ergänzen bei Bedarf einen Keyword-Monitor, der prüft, dass nach der Weiterleitung der richtige Inhalt erscheint. Die Website-Checks im Dashboard wiederholen die Tiefenprüfung in Abständen und zeigen Veränderungen. Das Vorgehen rund um Statuscodes bei Fehlern erläutert Website-Ausfall erkennen, und wie Sie Zeiten für einen Umzug absichern, steht in Wartungsfenster planen.