Was ist eine 302-Weiterleitung?

Der Code 302 teilt mit, dass die angeforderte Ressource sich vorübergehend an einer anderen Adresse befindet und die ursprüngliche weiterhin die gültige Referenz bleibt. Die Spezifikation sagt es ohne Umschweife: Der Client soll für künftige Anfragen weiterhin die Ausgangs-URL verwenden, weil die Umleitung jederzeit verschwinden kann. Darin liegt der ganze Abstand zum 301, der den Umzug für endgültig erklärt.

Es gibt einen zweiten vorübergehenden Code, den kaum jemand einsetzt und der in manchen Fällen der richtige ist: den 307. Der Unterschied hat nichts mit der Suchmaschine zu tun, sondern mit der Methode der Anfrage. Aus historischen Gründen darf ein Browser eine POST-Anfrage, die einen 302 erhält, in ein GET umwandeln, sie kann also am Ziel ankommen, nachdem sie ihre Daten verloren hat. Der 307 verbietet diesen Methodenwechsel ausdrücklich. Bei einer normalen Seite, die per GET abgerufen wird, verhalten sich beide Codes gleich, und Google behandelt sie gleich. Bei einem Formular, bei einem Zahlungsdienst oder an einem Endpunkt einer API entscheidet genau dieser Unterschied, ob die Anfrage vollständig oder leer ankommt.

Googlebot folgt der Weiterleitung und erreicht das Ziel, aber das Indexierungssystem nutzt sie nicht als Signal dafür, dass dieses Ziel zur kanonischen Fassung werden soll. Das sichtbare Ergebnis ist das, was fast alle erwarten: In den Suchergebnissen erscheint weiterhin die Ausgangs-URL, solange die Umleitung aktiv ist.

Missverstanden wird meist die Reichweite dieser Regel. Dass die 302 nicht als Signal für die Kanonisierung zählt, macht sie noch nicht zu einem Schutz. Die Dokumentation fügt einen Satz an, der das Bild verändert: Die Zielseite kann trotzdem indexiert werden, wenn andere Signale für die Kanonisierung vorliegen. Diese Signale sind die üblichen, und keines hängt vom Statuscode ab: interne Links auf das Ziel, sein Vorkommen in der Sitemap, ein Canonical-Tag oder schlicht der Umstand, dass beide Seiten fast denselben Inhalt tragen.

Daraus ergibt sich die Antwort auf den häufigsten Fall, die 302, die seit Monaten steht. Google macht sie nicht durch Alter zu einer dauerhaften Weiterleitung, und es gibt auch keine veröffentlichte Frist, ab der sich die Bewertung ändert. Was geschieht, ist einfacher und weniger beruhigend: Je mehr Zeit vergeht, desto mehr Signale sammelt das Ziel, und irgendwann können diese Signale schwerer wiegen als das Fehlen jenes Signals, das die 302 nie geliefert hat. Wer eine vorübergehende Umleitung unbefristet stehen lässt, friert nichts ein, sondern verzichtet nur darauf zu entscheiden, welche der beiden Adressen gewinnen soll.

curl -I https://beispiel.de/seite
HTTP/1.1 302 Found
Location: https://beispiel.de/ziel

Drei Situationen bündeln fast alle Probleme.

Die Wartung ist die erste. Eine Seite in Arbeit ist nicht umgezogen, sie bleibt an ihrem Platz und kommt in ein paar Stunden zurück, also lässt eine Weiterleitung den Crawler ohne Inhalt an dieser Adresse zurück, genau wenn er vorbeikommt. Für die vorübergehende Nichtverfügbarkeit hält die Spezifikation einen eigenen Code bereit, den 503, definiert für kurzzeitige Überlastung und geplante Wartung, mit einem Retry-After-Header, der angibt, wann sich ein neuer Abruf lohnt.

Die zweite ist die Erkennung von Land oder Sprache. Die meisten Crawls von Google laufen über US-amerikanische IP-Adressen, und der Crawler sendet keine Sprachpräferenz im Accept-Language-Header. Eine Website, die automatisch nach IP weiterleitet, zeigt ihm am Ende immer dieselbe Fassung, und die übrigen bleiben ungecrawlt. Google rät von dieser automatischen Weiterleitung ab und schlägt das Gegenteil vor: hreflang-Auszeichnungen, alle Fassungen über ihre eigene URL erreichbar und eine sichtbare Auswahl.

Die dritte ist der A/B-Test, und hier passt die 302 ohne Diskussion. Google empfiehlt diesen Code für die Varianten gerade deshalb, weil er die ursprüngliche URL im Index hält, solange das Experiment läuft. Bedingung ist, ihn danach abzubauen: alternative URLs, Test-Skripte und Auszeichnung, alles raus.

• Setze 302 nur ein, wenn die Ausgangs-URL wieder Inhalte ausliefern wird, und halte fest, wann. Eine vorübergehende Umleitung ohne vorgesehenes Datum ist eine vertagte Entscheidung, keine Entscheidung.
• Wähle 307, wenn die Anfrage die Methode nicht wechseln darf: Formulare, Zahlungsdienste und die Endpunkte einer API.
• Decke die Wartung mit 503 und einem Retry-After-Header ab statt mit einer Weiterleitung, denn die Seite ist nicht umgezogen, sie ist nur kurz geschlossen.
• Ergänze die 302 bei A/B-Tests um ein Canonical-Tag auf die ursprüngliche URL in der Variante und entferne beides beim Abschluss des Experiments.
• Biete für Land und Sprache eine sichtbare Auswahl und hreflang-Auszeichnungen an, statt nach IP weiterzuleiten.
• Prüfe nach jeder Migration oder nach jeder Änderung des Templates den Bestand an Weiterleitungen mit einem eigenen Crawl und kontrolliere den ausgelieferten Code, ohne dich auf die Anzeige im CMS zu verlassen.

• Voraussetzen, dass eine 302 die Position der Ausgangs-URL schützt. Garantiert ist allein, dass die Umleitung nicht als Signal zugunsten des Ziels zählt.
• Eine Wartung mit einer Weiterleitung zudecken, statt mit 503 zu antworten, und die Adresse damit ausgerechnet beim entscheidenden Besuch ohne Inhalt für den Crawler lassen.
• Automatisch nach der IP des Besuchers weiterleiten, mit dem Ergebnis, dass Google immer dieselbe Sprachfassung sieht und die übrigen nie gecrawlt werden.
• Eine 302 dort einsetzen, wo die Anfrage Daten transportiert, ohne damit zu rechnen, dass sie in ein GET umgewandelt am Ziel ankommen kann.
• Einen A/B-Test beenden und die URLs des Tests, die Weiterleitung und die Auszeichnung des Experiments stehen lassen.