English
Deutsch
PolskiDie richtige Website-Weiterleitung wählen: 301, 302, 307 und 308 erklärt
Management Summary
Eine Weiterleitung teilt einem Browser oder Programm mit, dass ein angefragter Inhalt unter einer anderen Adresse liegt. Das ist bei Website-Umzügen üblich, hat aber besonders für Formulare Folgen. Manche Weiterleitungen können eine Datenübermittlung in einen gewöhnlichen Seitenabruf verwandeln und den ursprünglichen Inhalt verlieren. Der Beitrag erklärt, warum 307 und 308 die Anfrageart bei vorübergehenden und dauerhaften Umzügen erhalten, während 301 und 302 anders reagieren können. Die passende Wahl schützt vollständige Übermittlungen.
Inhalt
Eine Weiterleitung fordert einen Client auf, eine andere URL zu verwenden. Zwei Entscheidungen zählen: Ist der Umzug dauerhaft, und soll die nächste Anfrage Methode und Inhalt wiederholen? GET ruft häufig eine Seite ab; POST übermittelt häufig Daten wie ein ausgefülltes Formular. Bei Formularen und APIs ist diese Unterscheidung besonders wichtig.
Eine empfangene Weiterleitung beweist weder deren Befolgung noch die Annahme der Daten am Ziel. Browser, Bibliothekseinstellungen und die gesamte Kette brauchen getrennte Prüfungen.
Zwei Fragen, vier häufige Statuscodes
| Code | Bedeutung | Behandlung von POST |
|---|---|---|
| 301 | Dauerhafter Umzug | HTTP erlaubt den Wechsel zu GET; Browser führen diesen gewöhnlich aus. |
| 302 | Vorübergehendes Ziel | HTTP erlaubt den Wechsel zu GET; Browser führen diesen gewöhnlich aus. |
| 307 | Vorübergehendes Ziel | Bei automatischer Befolgung muss die Methode erhalten bleiben. |
| 308 | Dauerhafter Umzug | Bei automatischer Befolgung muss die Methode erhalten bleiben. |
Beim Wechsel von POST zu GET wird der ursprüngliche Anfragekörper nicht erneut gesendet. Bei 307 und 308 wird der Inhalt beim Folgen normalerweise erneut übertragen. Ein Client kann die Weiterleitung aber ablehnen oder an einem nicht erneut lesbaren Anfragekörper scheitern. Eine erhaltene Methode garantiert keine identischen Cookies, Authentifizierungsheader oder Anwendungsergebnisse.
303 See Other erfüllt einen anderen Zweck: Nach der Verarbeitung eines POST kann der Server auf eine Ergebnisseite verweisen, die per GET abgerufen wird. Das passt zum Ablauf Post/Redirect/Get. Für das erneute Senden derselben Formulardaten an einen anderen Endpunkt ist 303 nicht vorgesehen.
Was bei jedem Sprung passiert
Location kann einen relativen URI-Verweis enthalten, der anhand der Anfrage-URL aufgelöst wird. Bei aktivierter Befolgung entsteht eine weitere Anfrage. Auch die Weiterleitungsantwort kann einen Inhalt besitzen, der sich ohne automatische Befolgung ansehen oder anzeigen lässt. Nicht jede 3xx-Antwort ist eine Navigationsweiterleitung: 304 betrifft beispielsweise die Wiederverwendung einer gespeicherten Antwort.
Eine zusätzliche Netzwerkanfrage erzeugt Aufwand, benötigt aber nicht zwingend eine neue DNS-Auflösung oder Verbindung. DNS-Cache, wiederverwendete Verbindungen und HTTP-Caches beeinflussen die Kosten. HSTS kann außerdem lokal von HTTP auf HTTPS wechseln, ohne dass der Server 301 sendet. Eine feste Millisekundenzahl je Sprung ist daher keine allgemeine Regel.
Speicherung und Dauerhaftigkeit sind verschiedene Dinge
301 und 308 kommen nach den HTTP-Cacheregeln für heuristische Speicherung infrage. Auch vorübergehende Antworten wie 302 können bei geeigneten ausdrücklichen Frischeangaben gespeichert werden. Vorübergehend bedeutet nicht „niemals gespeichert“. Anfragemethode, Cachevorgaben und weitere Einschränkungen bleiben relevant.
Cache-Control: max-age=3600 legt eine Frischefrist fest, keine garantierte Löschung nach einer Stunde. Eine veraltete Antwort kann gespeichert bleiben und erneut validiert werden; weitere Regeln beeinflussen ihre Wiederverwendung. Eine geänderte Serverregel ruft bereits gespeicherte Weiterleitungen nicht sofort von allen Clients zurück.
Eine falsche dauerhafte Weiterleitung braucht eine abgestimmte Korrektur. Leitet das Ziel auf die alte URL zurück, können Clients mit der gespeicherten ersten Weiterleitung in eine Schleife geraten. Prüfungen sollten frische und vorhandene Cachezustände berücksichtigen; Links und Clients werden auf die beabsichtigte Endadresse angepasst.
Suchsignale garantieren keine Platzierung
Die kanonische URL ist die bevorzugte Hauptadresse für den Suchindex. Google wertet dauerhafte Weiterleitungen als starkes Signal, dafür die Zieladresse zu wählen. Vorübergehende Weiterleitungen sind ein schwächeres Signal. Daraus folgt weder, dass 302 die alte URL für immer im Index hält, noch dass 301 sofort eine bestimmte Platzierung überträgt. Erneutes Crawlen und weitere Signale bleiben relevant.
Laut Googles Umzugsdokumentation verursachen dauerhafte Weiterleitungen für sich keinen PageRank-Verlust. Kurze Ketten sind trotzdem für Laufzeit, Zuverlässigkeit und Crawlergrenzen sinnvoll. Die Behauptung, bei jedem Sprung gehe zwangsläufig Bewertungsgewicht verloren, führt in die Irre. Direkte Verweise zum richtigen Endziel sind vorzuziehen, soweit das erforderliche Verhalten das erlaubt.
Cookies, Herkunftsangaben und Anmeldung
Der Ursprung (Origin) besteht aus Protokoll, Hostname und Port, ohne den Seitenpfad. Ein Hostwechsel entfernt den Referer-Header nicht automatisch. Bei der verbreiteten Regel strict-origin-when-cross-origin bleibt bei einem sicheren ursprungsübergreifenden Abruf gewöhnlich der Ursprung erhalten, während der Pfad entfällt. Beim Wechsel zu HTTP wird die Angabe weggelassen. Entscheidend sind die tatsächliche Richtlinie und der Anfragekontext.
Ein hostgebundenes Cookie gilt nicht automatisch für Unterdomains. Ein gültiges Domain-Attribut kann Unterdomains einschließen; zusätzlich wirken Path, Secure, SameSite und Browserregeln. Für Zugangsdaten und Authorization-Header gelten weitere Weiterleitungsgrenzen. Der Titel der Endseite allein beweist keine erhaltene Anmeldung oder API-Berechtigung.
Ein kleiner reproduzierbarer Methodentest
Ein isolierter Loopback-Test mit curl 8.14.1 sendete den harmlosen Inhalt test=1 an fünf künstliche Weiterleitungen. Mit gewöhnlichem --location --data test=1 kamen 301, 302 und 303 als GET ohne Anfragekörper an; 307 und 308 als POST mit unverändertem Inhalt. Mit der ausdrücklichen curl-Option --post301 blieb POST auch nach 301 erhalten. Das zeigt den Einfluss der Clienteinstellung.
Geprüft ist nur diese curl-Konfiguration. Browsercaches, echte Formulare, externe Webseiten und die Weitergabe von Zugangsdaten waren nicht Teil des Tests. Historische Ergebnisse zu zwölf Seiten werden hier nicht als bestätigte Messung dargestellt.
Die gesamte Kette prüfen
Ein brauchbares Protokoll enthält Start-URL und Methode, jeden Status mit Location, Endadresse, endgültige Methode, Behandlung des Anfragekörpers und finalen Antwortstatus. Ein 403 am Ziel ist eine Zugriffsverweigerung, kein Beweis für eine bestimmte Weiterleitungsursache. Eine Schleife oder die Sprunggrenze des Clients kann die Kette vor einer Endseite abbrechen.
Ein Indexierungsprüfer mit GET hilft bei der URL-Führung, belegt aber kein POST-Verhalten. Formular- und API-Umzüge brauchen den tatsächlich unterstützten Client und harmlose Testdaten. Bei dauerhaft verlegten Endpunkten ist 308 ein passendes methodenerhaltendes Signal. Direkt angepasste Clientadressen vermeiden die dauerhafte Abhängigkeit von der Weiterleitungsunterstützung.
Fragen und Antworten
Warum verhindert 303 nach einem Formular, dass die Daten beim Neuladen erneut gesendet werden?
Nach einer 303-Antwort ruft der Browser die Ergebnisseite per GET ab, und diese GET-Anfrage ist dann das, was ein Neuladen wiederholt. Die Formulardaten gehen deshalb kein zweites Mal an den Server. Gegen einen doppelten Klick auf die Absenden-Schaltfläche schützt das allerdings nicht; dafür braucht die Anwendung eine eigene Prüfung.
Ein API-Endpunkt zieht dauerhaft um. Genügt eine 308-Weiterleitung?
Als Übergang ja, als Dauerlösung selten. 308 sagt aus, dass der Umzug dauerhaft ist und die Methode erhalten bleiben muss, wenn der Client der Weiterleitung automatisch folgt. Ob er das tut, hängt vom Client ab: Manche Bibliotheken folgen gar nicht oder erst nach einer Einstellung, und ein Anfragekörper, der sich nicht erneut lesen lässt, etwa ein Datenstrom, kann beim zweiten Senden scheitern.
Dazu kommen Anmeldung und Cache. Für Zugangsdaten und Authorization-Header gelten bei Weiterleitungen eigene Grenzen; wechselt der Host, senden viele Clients sie nicht weiter, und der neue Endpunkt lehnt die Anfrage dann ab, obwohl die Methode stimmt. Außerdem kommt 308 für eine heuristische Speicherung infrage. Eine falsch gesetzte dauerhafte Weiterleitung kann so bei manchen Clients wirksam bleiben, auch nachdem die Serverregel geändert wurde.
Belastbar ist deshalb ein Test mit den Clients, die die API tatsächlich nutzen, und mit harmlosen Testdaten, protokolliert bis zur endgültigen Methode und zum Antwortstatus. Danach sollten die Clients die neue Adresse direkt verwenden; die Weiterleitung fängt dann nur noch Nachzügler ab.
Quellen
Passend dazu
