302 vs. 307: Weiterleitung

TL;DR – Eine 302 und eine 307 sind beide „vorübergehende“ Weiterleitungen – sie schicken Besucher vorübergehend an einen anderen Ort und behalten dabei die ursprüngliche URL als maßgebliche URL. Google verarbeitet sie gleich, also gibt es keinen bedeutsamen SEO-Unterschied. Der eine echte technische Unterschied: Ein 307 muss deine Request-Art beibehalten (eine Formularübermittlung bleibt eine Formularübermittlung, statt zu einem einfachen Seitenabruf zu werden), während ein 302 historisch eine Umwandlung zuließ. Verwende 302 für normale Weiterleitungen und 307 für Formulare oder APIs, die Daten senden – und nimm nicht an, dass „standardmäßig überall 307“ ohne Nachteile wäre.

Was eine 302 und eine 307 tatsächlich bedeuten

302 und 307 sind Weiterleitungen: Du rufst eine URL auf und landest auf einer anderen. Die Zahl ist der HTTP-Statuscode, den der Server zurückgibt, und sie enthält eine Anweisung für Browser und Suchmaschinen.

• 302 – „Gefunden“ (vorübergehend). Die ursprüngliche vorübergehende Weiterleitung. Sie bedeutet: „Geh vorerst hierhin, aber die alte Adresse ist weiterhin die echte – ich komme zurück.“
• 307 – „Vorübergehende Weiterleitung“. Dieselbe Aussage – vorübergehend, die alte URL bleibt maßgeblich –, aber mit einem zusätzlichen Versprechen: Der Browser muss deinen exakten Request wiederholen, einschließlich der Methode GET (nur eine Seite abrufen) oder POST (Daten wie ein Formular senden).

Sie sind also Geschwister. Eine nützliche Kurzform: Ein 307 ist ein 302, das zusätzlich garantiert, dass der Browser deine Formularübermittlung nicht stillschweigend in einen einfachen Seitenabruf umwandelt.

Ist das für SEO wichtig?

Nicht so, wie die meisten Websitebetreiber befürchten. Googles eigene Dokumentation führt 307 für die Verarbeitung und Weiterleitung durch Crawler als “Equivalent to 302” (Übersetzung) „gleichwertig mit 302“ auf. Beide sind „vorübergehende“ Signale, daher behandelt Google das Ziel standardmäßig nicht allein wegen der Weiterleitung als kanonische Seite. Googles Dokumentation sagt nicht, ob 302 und 307 identische oder unterschiedliche Mengen an Linkwert übertragen – klar ist nur, dass keiner der beiden Codes dem Ziel die Signale der Quelle so übergibt wie eine dauerhafte Weiterleitung. Wenn jemand behauptet, 307 „übertrage weniger Wert“ als 302, frage nach der Quelle: Google hat keine solche Formel veröffentlicht.

Wann verwende ich welchen Code?

• Eine normale 302 für alltägliche vorübergehende Weiterleitungen – saisonale Verkaufsseite, A/B-Test, Wartungsseite oder länderspezifische Startseite.
• Eine 307, wenn die Weiterleitung Daten sendet – Formularübermittlung, API-Aufruf oder Login-/Checkout-POST. Das Versprechen der 307 (Methode und Daten exakt beibehalten) ist dann wichtig, weil ein älterer Browser ein POST bei 302 in GET umwandeln und die Daten verwerfen könnte.

Ein typischer Stolperstein

Manchmal öffnest du die Entwicklertools des Browsers und siehst ein 307, das du nie eingerichtet hast. Das ist meist keine echte Serverweiterleitung, sondern der Browser stuft einen Link mit http:// selbst zu https:// hoch (eine Sicherheitsfunktion namens HSTS) und zeigt dir das als 307. Dein Server hat es nie gesendet. Mehr dazu findest du im Fortgeschritten-Tab.

Möchtest du die vollständige Geschichte – Spezifikationsgeschichte, genauere Aussagen von Google und Mueller, die HSTS-„Phantom-307“ und überraschende Framework-Standards? Wechsle zur Registerkarte Fortgeschritten.

TL;DR – 302 und 307 sind beide vorübergehende Weiterleitungen, und Google verarbeitet sie gleich – laut Dokumentation ist 307 “Equivalent to 302” (Übersetzung) „gleichwertig mit 302“, und Mueller sagte, es mache “for SEO, it doesn’t really matter” (Übersetzung) „für SEO nicht wirklich einen Unterschied“, ob man das vorübergehende oder dauerhafte Paar verwendet. Keiner der Codes signalisiert, dass das Ziel kanonisch werden soll, und Google hat keinen PageRank-/Linkwertunterschied veröffentlicht. Der echte Unterschied ist die Methodenerhaltung: Ein automatisch folgendes 307 muss dieselbe Request-Methode beibehalten (ein POST bleibt ein POST), während ein 302 einem Client die Umwandlung von POST in GET erlauben kann – exakte Body-Bytes, Zugangsdaten und Cross-Origin-Verhalten hängen weiterhin vom Client ab. Verwende 307, wenn der Methodenverlust Probleme verursacht – APIs, Formulare, POST-/Webhook-/Checkout-/Auth-Abläufe –, aber achte auf Wiederholungen nicht idempotenter Requests (ein Zahlungs- oder Bestellaufruf kann erneut gesendet werden). Ein gewöhnlicher 302 reicht für GET-Weiterleitungen, einschließlich Googles ausdrücklicher Empfehlung für A/B-Tests. Beachte die HSTS-„Phantom-307“ (ein Chrome-UI-Label, keine Protokollgarantie), Frameworkdetails (Next.js dokumentiert 303 für Server Actions und 307 an anderer Stelle) sowie Bings fehlende eigene 302-vs.-307-Leitlinie. Meine bevorzugte Reihenfolge ist 307 / 302 / 303 vor Meta-/HTTP-Refresh – prüfe aber Cache-Header, Legacy-Clients und Idempotenz, bevor du standardmäßig überall 307 einsetzt.

Beide sind vorübergehend – das ist der Ausgangspunkt

Zunächst: 302 und 307 gehören in dieselbe Kategorie. Google fasst 302 (Found), 303 (See Other) und 307 (Temporary Redirect) als “temporary redirects” (Übersetzung) „vorübergehende Weiterleitungen“ zusammen und behandelt sie alle gleich – “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (Übersetzung) „Googlebot folgt der Weiterleitung, aber die Indexierungspipeline verwendet sie nicht als Signal, dass das Weiterleitungsziel kanonisch sein soll.“ In einfachen Worten: Eine vorübergehende Weiterleitung behält standardmäßig die Quell-URL als kanonische URL; sie übergibt dem Ziel nicht die Signale der Quelle wie eine dauerhafte Weiterleitung (301/308).

Das ist genau der Vergleich innerhalb der dauerhaften Ebene eine Stufe darunter: 301/308 sind das dauerhafte Paar, 302/307 das vorübergehende Paar, und die Logik „die höhere Nummer erhält die Methode“ ist in beiden Paaren gleich.

Der eine echte Unterschied: Erhaltung von Methode und Body

Hier ist der entscheidende Unterschied in einem Satz: Wenn ein Client einer 307 automatisch folgt, verlangt die aktuelle HTTP-Spezifikation (RFC 9110), dass er dieselbe Request-Methode beibehält; bei 302 darf der Client ein POST in GET umwandeln. Das ist eine Garantie für die Methode – keine pauschale Garantie für jedes Byte des Bodys, Zugangsdaten oder Cross-Origin-Verhalten. Das hängt weiterhin vom konkreten Client ab. Prüfe es mit einem echten Request, statt anzunehmen, dass ein 307 immer alles identisch wiederholt.

Warum diese Unklarheit entstand, ist eine Spezifikationsgeschichte, die viele Texte auslassen. In der HTTP/1.0-Zeit sagte der Text für 302 technisch, Clients sollten die Methode bei der Weiterleitung nicht ändern – frühe Browser (Netscape, später praktisch alle) ignorierten das jedoch und wandelten Nicht-GET-Methoden, besonders POST, stillschweigend in GET um. Dieses uneinheitliche, aber universelle Verhalten wurde zum De-facto-Standard. HTTP/1.1 (RFC 2616, 1999, später in RFC 7231 und dem heutigen RFC 9110 aufgegangen) formalisierte die Trennung in zwei ausdrückliche Codes:

• 303 (See Other) – ruft das Weiterleitungsziel mit GET oder HEAD ab (nicht einfach „immer GET“ – RFC 9110 erlaubt beide sicheren Methoden); gedacht für „POST, dann Weiterleitung auf eine Ergebnis-Seite, die gefahrlos neu geladen werden kann“.
• 307 (Temporary Redirect) – die Methode wird bei einer automatischen Weiterleitung streng beibehalten; RFC 9110 zwingt aber keinen Client, der Weiterleitung überhaupt zu folgen.

MDN fasst die praktische Konsequenz klar zusammen: “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (Übersetzung) „Der Unterschied zwischen 307 und 302 ist, dass 307 garantiert, dass der Client Methode und Body des weitergeleiteten Requests nicht ändert. Bei 302 änderten ältere Clients die Methode fälschlich in GET.“ 307 fügte also keine neue Fähigkeit hinzu, sondern beseitigte eine Mehrdeutigkeit: Es ist die spezifikationsgarantierte Variante dessen, was ein korrekt arbeitender 302 schon immer tun sollte. Moderne Browser sind viel konsistenter als zu Netscape-Zeiten, aber 307 beseitigt die Unklarheit per Spezifikation statt per Konvention.

Im Vergleich:

Zwei Präzisierungen: Die Erlaubnis der RFC, bei 302 umzuwandeln, nennt POST, nicht jede Methode – verallgemeinere das nicht zu “302 always breaks PUT/DELETE” (Übersetzung) „302 macht PUT/DELETE immer kaputt“. Und keiner der Codes ist allein wegen seines Status standardmäßig cachebar: RFC 9111 führt 302 und 307 nicht unter den Statuscodes auf, die allein aufgrund ihres Status heuristisch cachebar sind – Caching hängt von ausdrücklichen Cache-Control-/Expires-Headern ab.

Meine eigene Ahrefs-Definition passt zur Methodenerhaltung: “A 307 redirect is the same as a 302 redirect, except it retains the HTTP method (POST, GET) of the original request when performing the redirect.” (Übersetzung) „Eine 307-Weiterleitung ist dasselbe wie eine 302-Weiterleitung, außer dass sie bei der Weiterleitung die HTTP-Methode (POST, GET) des ursprünglichen Requests beibehält.“

Behandelt Google 302 und 307 für SEO unterschiedlich?

Nein – und Google ist hier ungewöhnlich deutlich. Das Thema ist so wenig kontrovers wie 301-vs.-308.

In Googles Dokumentation zu HTTP-Statuscodes heißt es für die 302-Zeile, dass Crawler der Weiterleitung folgen und sie als schwaches Signal für die Verarbeitung des Ziels verwenden; in der 307-Zeile steht wörtlich “Equivalent to 302” (Übersetzung) „gleichwertig mit 302“. Google ergänzt den Hinweis, der für 302/307 und 301/308 gilt: “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (Übersetzung) „Obwohl Google diese Statuscodes gleich behandelt, bleiben sie semantisch verschieden. Wählen Sie den für die Weiterleitung geeigneten Statuscode, damit auch andere Clients – etwa E-Reader und weitere Suchmaschinen – davon profitieren.“

Das ist die Antwort zur Verarbeitung durch Crawler: Google behandelt beide gleich, wenn Googlebot die Weiterleitung abruft und verfolgt, und verlangt nur, dass du den semantisch passenden Code für andere Clients auswählst. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the two status codes are semantically different. Scope: Google Search redirect handling; HTTP clients still need the appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Eine wichtige Nuance: Die Gleichwertigkeit bei der Verarbeitung durch Crawler ist eine andere Aussage als das Ergebnis der Indexierung. Googles Dokumentation zu Weiterleitungen und Google Search gruppiert 302, 303 und 307 als “temporary redirects” (Übersetzung) „vorübergehende Weiterleitungen“ und erklärt, dass “the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (Übersetzung) „die Indexierungspipeline die Weiterleitung nicht als Signal verwendet, dass das Ziel kanonisch sein soll“. Das ist eine nützliche Garantie, aber kein Versprechen, dass die Quell-URL weiter rankt oder das Ziel nicht über andere Signale indexiert werden kann. Behandle “302 and 307 are processed the same way” (Übersetzung) „302 und 307 werden gleich verarbeitet“ und “neither is a canonical signal to the target” (Übersetzung) „keiner ist ein Kanonisierungssignal für das Ziel“ als zwei getrennte, beide zutreffende Aussagen – nicht als Behauptung, Google habe identische PageRank- oder Linkwertübertragung veröffentlicht.

John Mueller sagt dasselbe mit eigenen Worten. In der Folge Search Off the Record, Folge 51 – „Let’s talk redirects“ fragte Martin Splitt direkt, warum 307 und 308 neben 301 und 302 existieren. Mueller: “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (Übersetzung) „Das musste ich erst kürzlich nachsehen. Üblicherweise werden mit 301 und 302 GET-Anfragen weitergeleitet.“ … “And with 307, 308, it also forwards POST requests.” (Übersetzung) „Bei 307 und 308 werden auch POST-Requests weitergeleitet.“ Dann das Zitat, das die SEO-Frage einordnet: “I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (Übersetzung) „Für SEO ist es meiner Meinung nach nicht wirklich wichtig. Es geht eher darum: Funktioniert es für APIs oder nicht? APIs müssen normalerweise nicht direkt in der Suche indexiert werden.“

Der entscheidende Rahmen: Der ganze Grund, 307 statt 302 zu wählen, ist eine Funktionsfrage („funktioniert es für APIs?“), keine Rankingfrage. Es gibt keine glaubwürdige Primärquelle, die einen SEO-Vorteil für einen der beiden Codes behauptet.

Behandelt Bing 302 und 307 unterschiedlich?

Ehrlich gesagt: Bing hat es nicht gesagt. Die öffentliche Bing-Leitlinie zu Weiterleitungen (der Beitrag von 2011 „Weiterleitungen verwalten – 301er, 302er und Canonicals“ und der Beitrag „Website-Migration mit Bing“ von 2020) behandelt nur die Trennung dauerhaft/vorübergehend bei 301 und 302 und nennt 307 oder 308 nie beim Namen. Anders als beim Thema 301-vs.-308, zu dem Fabrice Canel eine direkte Aussage gemacht hat, konnte ich keine Bing-Aussage finden, die 302 und 307 ausdrücklich unterscheidet.

Ich sage es daher klar, statt Gleichheit anzunehmen: Es gibt keine spezielle Bing-Aussage zu 302 und 307. Ein dokumentiertes Bing-Verhalten ist für vorübergehende Weiterleitungen trotzdem wichtig: Wenn Bingbot denselben 302 oft hintereinander sieht, beginnt Bing, ihn wie einen 301 zu behandeln und die Weiterleitung zu konsolidieren. Bing hat aber nicht öffentlich bestätigt, dass das auch für wiederholte 307 gilt. Betrachte das als echte Dokumentationslücke, nicht als Tatsache über 307.

Wann 307 technisch die richtige Wahl ist

Bei jeder Weiterleitung, bei der ein Verlust von Methode oder Body die Funktion beeinträchtigen würde:

• APIs und Webhook-Endpunkte – ein POST/PUT/DELETE, das mit Methode und Payload intakt an der neuen URL ankommen muss.
• Formularübermittlungen (POST-Abläufe) – wie Mueller es ausdrückte: “if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (Übersetzung) „Wenn du beispielsweise ein – ich würde fast sagen – fehlerhaftes Setup hast, bei dem ein Formular auf einer Domain liegt und die Ergebnisse an eine andere weitergeleitet werden, würdest du 307 oder 308 verwenden.“
• Checkout-, Zahlungs- und Login/Auth-POST-Übergaben – überall dort, wo ein verlorener Body die Transaktion stillschweigend scheitern lässt.

Ein Sicherheitshinweis: Die Methodenerhaltung von 307 wirkt in beide Richtungen. Wenn der ursprüngliche Request nicht idempotent war – Zahlung, Bestellung oder irgendein Seiteneffekt –, wiederholt ein automatisch folgendes 307 denselben Request an der neuen URL. Das ist meist gewollt, bedeutet aber auch, dass ein Retry des Clients oder eine Weiterleitungskette einen nicht idempotenten Aufruf mehrfach senden kann. Baue am Ziel Idempotenzkontrollen (Idempotenzschlüssel, Prüfung auf doppelte Übermittlung) ein, statt anzunehmen, dass die Weiterleitung allein die Wiederholung sicher macht.

Ein häufiger Grund, warum Entwickler 307 antreffen, ohne es ausgewählt zu haben: Manche Frameworks und Edge-Plattformen verwenden für Nicht-GET-Requests standardmäßig einen methodenerhaltenden Code. Next.js ist das klarste dokumentierte Beispiel – seine Funktion redirect() gibt bei einem Server Action ein 303 und in anderen unterstützten Kontexten ein 307 zurück. Prüfe daher die Dokumentation deiner Next.js-Version. Andere Frameworks, CDNs und Load-Balancer unterscheiden sich je nach Produkt und Version – verifiziere den tatsächlichen Statuscode deiner Plattform. Ein unerwartetes 307 oder 303 ist oft eine absichtliche Methodenbehandlung der Plattform, keine Fehlkonfiguration; bestätige es aber für dein Setup.

Wann 302 die pragmatische Standardwahl ist

Normale vorübergehende Weiterleitungen für reine GET-Requests – es gibt keine Methode zu erhalten, also bringt dir die 307-Garantie nichts:

• Geo-/Sprachweiterleitungen (mit dem üblichen Hinweis, Inhalte nicht vollständig nach Region zu blockieren).
• A/B- und Split-Tests – Googles eigene Leitlinie zu Website-Tests sagt ausdrücklich, für weitergeleitete Testvarianten 302 statt 301 zu verwenden, gerade weil die Weiterleitung vorübergehend ist.
• Wartungsmodus-/„Bin bald wieder da“-Weiterleitungen – aber nur, wenn es tatsächlich eine Ressource gibt, an die Besucher gesendet werden können. Wenn die gesamte Website nicht verfügbar ist, empfiehlt Google einen 503 (Service Unavailable) statt irgendeiner Weiterleitung. Wenn der weitergeleitete Request ein Nicht-GET ist – etwa ein Checkout- oder API-Aufruf auf die Wartungsseite –, wiederholt 307 den Request am Ziel; bei Seiteneffekten ist das nicht automatisch sicher. Verwende 307 dort nicht aus Gewohnheit.
• Mobile↔Desktop (m-dot)-Weiterleitungen – Muellers eigenes Beispiel für den Fall, in dem 302 ausdrücklich der richtige Code ist: “a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (Übersetzung) „Eine 302-Weiterleitung wäre die richtige, weil du beim nächsten Besuch nicht wirklich weißt, ob jemand die mobile oder die Desktop-Version sehen möchte.“ Das richtige Ziel hängt vom Besucher ab, also handelt es sich nicht um einen dauerhaften Umzug.

Die HSTS-„Phantom-307“ – ein 307, das dein Server nie gesendet hat

Dieser Abschnitt ist wichtig, weil es um ein völlig anderes Thema als die Wahl des Weiterleitungscodes geht. Wer beides vermischt, bekommt beim Debuggen von Weiterleitungsketten echte Probleme.

Wenn eine Website den HSTS-Header (Strict-Transport-Security) über HTTPS sendet, merkt sich der Browser das. Bei einem späteren Aufruf der Version unter http:// stuft er den Request selbst zu https:// hoch – die URI wird geändert, bevor der Request überhaupt das Netzwerk erreicht. Aktuelle Chrome-Versionen zeigen dieses interne Upgrade in DevTools als 307 an. Der Server hat es aber nicht ausgegeben, und die genaue Bezeichnung, Byteanzahl oder Headerdarstellung ist Chrome-versionsabhängiges UI-Verhalten, keine HTTP- oder HSTS-Spezifikationsanforderung. John Mueller erklärte auf seiner persönlichen Website: “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (Übersetzung) „Nachdem Chrome die HTTPS-URL mit dem HSTS-Header gesehen hat (etwa durch eine Weiterleitung von der HTTP-Version), verhält es sich beim nächsten Aufruf der HTTP-Seite so, als sehe es eine 307-Weiterleitung.“ Die entscheidende Klarstellung lautet: “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (Übersetzung) „Dein Server gibt kein 307 zurück; Chrome zeigt es nur so an, um zu erklären, dass der Browser die Weiterleitung für dich ausführt.“

Ich habe dasselbe in meinen eigenen Texten zu Statuscodes markiert: Es gibt sogar die eigene Bedeutung „307 HSTS Policy“ („erzwingt HTTPS für den Client“) neben „307 Temporary Redirect“. Die SEO-Nuance: “When web servers require clients to only use HTTPS connections (HSTS policy), Google won’t see the 307 because it’s cached in the browser.” (Übersetzung) „Wenn Webserver von Clients ausschließlich HTTPS-Verbindungen verlangen (HSTS-Richtlinie), sieht Google die 307 nicht, weil sie im Browser gecacht ist.“ Wenn du also ein 307 im Network-Tab entdeckst, das du nie eingerichtet hast, prüfe vor der Suche nach einer falsch konfigurierten Weiterleitungsregel, ob HSTS lediglich ein HTTP→HTTPS-Upgrade für dich ausführt.

Häufige Irrtümer

• „307 überträgt nicht denselben SEO-Wert wie 302.“ Nicht belegt – Googles eigene Dokumentation nennt 307 für die Verarbeitung „Equivalent to 302“ (Übersetzung) „gleichwertig mit 302“, und keiner der Codes ist ein Signal, dass das Ziel kanonisch werden soll. Google hat allerdings keine exakte PageRank-/Linkwertformel veröffentlicht. Behaupte daher keine präzise gleiche oder ungleiche Übertragung; korrekt ist: Google verarbeitet beide gleich, nicht: Google hat den übertragenen Wert quantifiziert.
• „302 ist immer sicherer, weil es älter ist.“ Übertrieben. Googles Behandlung von 307 ist ebenso dokumentiert. Wenn überhaupt, bietet 307 eine Funktionsgarantie für Methode und Body, die 302 nicht bietet.
• „Ein 307 im Network-Tab bedeutet, dass mein Server falsch konfiguriert ist.“ Oft falsch – bei aktivem HSTS ist es möglicherweise das interne HTTP→HTTPS-Upgrade von Chrome und keine Serverantwort.
• „302 wandelt immer POST in GET um, also darf man 302 nie für Formulare verwenden.“ Für moderne Browser übertrieben. Die Umwandlung war ein echtes, gut dokumentiertes Problem älterer Clients – der Grund, warum 307 als garantierte Option existiert, nicht der Beweis, dass jeder 302 heute POST-Daten verwirft. 302 ist mehrdeutig, nicht universell kaputt.
• „Ersetze alle vorübergehenden Weiterleitungen durch 307, um besser zu ranken.“ Falsch und unnötige Unruhe – es gibt keinen Rankingvorteil. Wähle 307 nur, wenn Methode/Body wirklich erhalten werden müssen oder ein Framework diesen sichereren Standard sinnvoll verwendet.
• „303 und 307 sind praktisch gleich.“ Nein – 303 erzwingt für die Weiterleitung GET (für POST-dann-Weiterleitung-zu-Ergebnis-Muster), während 307 Methode und Body erhält.

Meine Empfehlung

Für vorübergehende Weiterleitungen ist meine bevorzugte Reihenfolge 307 / 302 / 303, vor Meta-Refresh (0) und HTTP-Refresh (0). Ich setze 307 tatsächlich vor 302 – nicht, weil es SEO hilft (das tut es nicht), sondern weil man beim methodenerhaltenden Code später seltener daran denken muss, umzuschalten: Eine normale GET-Weiterleitung funktioniert als 307, und am Tag einer Formular- oder API-Weiterleitung bist du bereits abgesichert. Das ist ein Vollständigkeitsargument, kein Freibrief: Eine 307-Standardstrategie braucht dieselbe Cache-Control-Disziplin wie jede andere Weiterleitung, muss mit den unterstützten Legacy-Clients funktionieren und braucht Idempotenzschutz an jedem Ziel, das nicht nur einen normalen GET-Abruf entgegennimmt. Mueller formulierte denselben Vollständigkeitspunkt: “if you always use them, then you’re always safe.” (Übersetzung) „Wenn du sie immer verwendest, bist du immer auf der sicheren Seite.“ Ein normaler 302 ist trotzdem völlig in Ordnung; für den speziellen m-dot-Fall ist 302 technisch sogar die korrektere Wahl.

Wo das Thema einzuordnen ist

302 und 307 sind zwei der vorübergehenden 3xx-Weiterleitungscodes. In diesem Cluster gibt es für beide eigene Vertiefungen, daneben das dauerhafte Paar (301, 308), das immer GET verwendende Geschwister 303 und die Vergleiche 301-vs.-308 (dieselbe Methodenerhaltungslogik eine Ebene höher) sowie 301-vs.-302 (dauerhaft gegen vorübergehend) – außerdem operative Risiken, Weiterleitungsketten und Schleifen. Für die gesamte Familie der Serverantworten siehe den Hub für HTTP-Statuscodes; Weiterleitungstypen sind auch Kanonisierungssignale, die unter Kanonisierung behandelt werden.

AI-Zusammenfassung

Eine komprimierte Fassung der Fortgeschritten-Version:

• Beide sind vorübergehende Weiterleitungen. 302 und 307 behalten standardmäßig die Quell-URL als kanonische URL – keiner übergibt dem Ziel die Signale der Quelle wie ein dauerhafter 301/308.
• Google verarbeitet sie gleich. Die Dokumentation nennt 307 “Equivalent to 302” (Übersetzung) „gleichwertig mit 302“, und Mueller sagt: “for SEO, it doesn’t really matter.” (Übersetzung) „Für SEO ist es nicht wirklich wichtig.“ Das ist eine Aussage zur Crawler-Verarbeitung, keine veröffentlichte PageRank-/Linkwertformel. Behaupte keinen exakt gleichen oder ungleichen Werttransfer und nimm nicht an, dass gleiche Verarbeitung garantiert, dass die Quelle weiter rankt oder das Ziel niemals über andere Signale indexiert wird.
• Der eine echte Unterschied ist die Methodenerhaltung. Ein automatisch folgendes 307 muss dieselbe Methode behalten (ein POST bleibt ein POST); ein 302 kann POST in GET umwandeln. 307 wurde in HTTP/1.1 (RFC 2616 → 7231 → 9110) eingeführt, um diese Mehrdeutigkeit zu schließen – exakte Body-Bytes, Zugangsdaten und Cross-Origin-Verhalten hängen aber vom Client ab, und die Umwandlungserlaubnis der RFC nennt ausdrücklich POST, nicht jede Nicht-GET-Methode.
• Verwende 307 für APIs, Formulare sowie POST-/Webhook-/Checkout-/Auth-Abläufe – aber achte auf nicht idempotente Wiederholungen und ergänze Schutzmaßnahmen. Verwende 302 für reine GET-Weiterleitungen – Geo/Sprache, Googles Empfehlung für A/B-Tests und (Muellers Beispiel) Mobile↔Desktop. Bei Wartungsweiterleitungen hängt die Wahl davon ab, ob es eine echte Zielressource gibt; bei einem vollständigen Ausfall ist 503 oft besser.
• Frameworkstandards hängen von Version und Kontext ab. Next.js dokumentiert 303 für Server Actions und 307 in anderen Kontexten – prüfe deine Version, statt andere Frameworks oder CDNs gleich zu behandeln.
• HSTS-„Phantom-307“: Ein 307 im Network-Tab ist oft Chrome, das HTTP→HTTPS selbst hochstuft (HSTS), nicht eine Serverantwort. Das genaue „307“-Label ist versionsabhängiges Chrome-UI-Verhalten und keine HTTP-/HSTS-Protokollanforderung. Mueller: “Your server’s not returning a 307, Chrome is just showing it to you as such.” (Übersetzung) „Dein Server gibt kein 307 zurück; Chrome zeigt es nur so an.“
• Bing: Es gibt keine eigene 302-vs.-307-Leitlinie. Nimm keine Gleichheit an und übertrage Bings Verhalten „wiederholtes 302 → wie 301 behandelt“ nicht automatisch auf 307.
• Keiner der Codes ist allein aufgrund seines Status standardmäßig cachebar (RFC 9111) – Caching hängt weiterhin von ausdrücklichen Cache-Control-/Expires-Headern ab.
• Patricks bevorzugte Reihenfolge für vorübergehende Weiterleitungen: 307 / 302 / 303 vor Meta-/HTTP-Refresh – aber standardmäßig überall 307 einzusetzen ist nicht automatisch kostenlos; prüfe Cache-Header, Legacy-Clients und Idempotenz.

Offizielle Dokumentation

Dokumentation und Spezifikationen aus Primärquellen.

Google

• HTTP-Statuscodes, Netzwerk- und DNS-Fehler sowie Google Search – die 302-Zeile mit dem „schwachen Signal“, die 307-Zeile „Equivalent to 302“ und der Hinweis „semantisch unterschiedlich – passenden Code verwenden“.
• Weiterleitungen und Google Search – gruppiert 302, 303 und 307 als “temporary redirects” (Übersetzung) „vorübergehende Weiterleitungen“ und erklärt die Wirkung auf die Kanonisierung.
• Search Off the Record, Folge 51 – „Let’s talk redirects“ (John Mueller + Martin Splitt) – das Gespräch darüber, warum 307/308 existieren und wann sie wichtig sind.
• John Mueller – Leitfaden zu 301, 302, 307 und anderen Weiterleitungen – Indexierungsverhalten von 302 (die Quell-URL „R“ wird tendenziell indexiert; die Weiterleitung wird nicht gecacht).
• John Mueller – 307s – Erklärung der HSTS-„Phantom-307“.

Bing / Microsoft

• Weiterleitungen verwalten – 301, 302 und Canonicals (Oktober 2011) – Bings Einordnung 301=dauerhaft, 302=vorübergehend (keine Erwähnung von 307).
• Website-Migration mit Bing (Dezember 2020) – allgemeine Hinweise zum Website-Umzug (wieder keine 307-spezifische Aussage).

Spezifikationen

• MDN – 307 Temporary Redirect – Definition der Methoden-/Body-Erhaltung und historische Anmerkung zu älteren Clients, die ihre Methode in GET umwandelten.
• RFC 9110 – HTTP Semantics – §15.4.8 „307 Temporary Redirect“ und §15.4.3 „302 Found“, die aktuelle Spezifikation für beide Codes.

Zitate aus den Quellen

Aufgezeichnete Aussagen von Google sowie aus der Spezifikation. Wo die Quellseite es unterstützt, springt jeder Link direkt zur zitierten Passage.

Google-Dokumentation – 307 ist gleichwertig mit 302

• “Equivalent to 302.” (Übersetzung) „Gleichwertig mit 302.“ (Zeile für 307) – Google Search Central. Zitat öffnen
• “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (Übersetzung) „Obwohl Google diese Codes gleich behandelt, sind sie semantisch nicht identisch. Verwenden Sie den sachlich passenden Statuscode, damit auch E-Reader und andere Suchmaschinen den Unterschied nutzen können.“ Zitat öffnen
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (Übersetzung) „Googlebot folgt der Weiterleitung, aber die Indexierungspipeline verwendet sie nicht als Signal, dass das Weiterleitungsziel kanonisch sein soll.“ (vorübergehende Weiterleitungen, einschließlich 302/303/307) Zitat öffnen

John Mueller, Google (Folge 51 von Search Off the Record – die Folge „Let’s talk redirects“; offizielles Transkript-PDF, zitiert nach der Passage – für diese Aussagen gibt es keine HTML-Seite mit passendem Anchor und daher keinen #:~:text=-Deep-Link)

• “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (Übersetzung) „Das habe ich erst vor Kurzem nachgesehen. Bei 301 und 302 werden normalerweise GET-Anfragen weitergeleitet.“ … “And with 307, 308, it also forwards POST requests.” (Übersetzung) „Bei 307 und 308 werden auch POST-Requests weitergeleitet.“
• “If you have some kind of an API that uses POST requests, or if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (Übersetzung) „Wenn du eine API mit POST-Requests oder ein – ich würde fast sagen – fehlerhaftes Setup hast, bei dem ein Formular auf einer Domain liegt und die Ergebnisse an eine andere weitergeleitet werden, würdest du 307 oder 308 verwenden.“
• “I guess from a completeness point of view, if you always use them, then you’re always safe. But that’s the difference there. I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (Übersetzung) „Aus Gründen der Vollständigkeit scheint die konsequente Verwendung zunächst sicherer. Darin liegt der Unterschied. Für SEO ist es meiner Ansicht nach nicht entscheidend; die eigentliche Frage lautet, ob es für APIs funktioniert. APIs müssen normalerweise nicht direkt in der Suche indexiert werden.“
• “And for that kind of redirect [mobile/desktop], from a technical point of view, a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (Übersetzung) „Für diese Art von Weiterleitung [Mobile/Desktop] wäre aus technischer Sicht 302 der richtige Code, weil du beim nächsten Besuch nicht wirklich weißt, ob jemand die mobile oder die Desktop-Version sehen möchte.“ Transkript-PDF

John Mueller, Google (johnmu.com – die HSTS-„Phantom-307“)

• “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (Übersetzung) „Nachdem Chrome die HTTPS-URL mit dem HSTS-Header gesehen hat (etwa durch eine Weiterleitung von der HTTP-Version), verhält es sich beim nächsten Aufruf der HTTP-Seite so, als sehe es eine 307-Weiterleitung.“
• “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (Übersetzung) „Dein Server gibt kein 307 zurück; Chrome zeigt es nur so an, um zu erklären, dass der Browser die Weiterleitung für dich ausführt.“ Beitrag lesen

MDN – der Unterschied bei der Methodenerhaltung

• “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (Übersetzung) „Der Unterschied zwischen 307 und 302 besteht darin, dass 307 garantiert, dass der Client Methode und Body beim Weiterleiten nicht ändert. Bei 302 änderten ältere Clients die Methode fälschlich in GET.“ Zitat öffnen

Welche vorübergehende Weiterleitung: 302 oder 307?

Da beide vorübergehend und SEO-seitig gleichwertig sind, läuft die Entscheidung auf eine Frage hinaus: Muss der Request eine Methode oder einen Body behalten?

Ein Hinweis zum „nicht sicher“-Pfad: Google verarbeitet 307 wie 302, und auch reine GET-Weiterleitungen funktionieren damit. Standardmäßig 307 zu verwenden ist daher nicht falsch – aber auch nicht automatisch kostenlos. Bestätige Cache-Header, prüfe ältere unterstützte Clients und verhindere bei Requests mit Seiteneffekten (Nicht-GET-Aufruf an eine API), dass ein automatisches 307 ohne Idempotenzschutz eine Wiederholung auslöst.

Fehler bei vorübergehenden Weiterleitungen vermeiden

302 wählen, weil 307 angeblich weniger Wert überträgt

Google dokumentiert 307 als gleichwertig mit 302 für die Suche. Entscheide zwischen beiden nach dem Request-Verhalten, nicht nach Rankings.

302 immer als sicherere Wahl betrachten, weil der Code älter ist

Ältere Clients machten die Behandlung der Methode bei 302 mehrdeutig. Wenn ein POST, PUT, DELETE, Webhook oder API-Body erhalten bleiben muss, verwende 307 als ausdrückliche Garantie.

Jedes DevTools-307 als Serverregel behandeln

Chrome kann ein internes HSTS-Upgrade als 307 anzeigen, obwohl der Server keines zurückgegeben hat. Wiederhole den Request mit einem serverseitigen Checker oder curl, bevor du die Weiterleitungskonfiguration änderst.

Behaupten, jede 302 wandle POST in GET um

Das historische Verhalten ist erlaubt und mehrdeutig, aber nicht bei jedem modernen Client garantiert. Verwende 307, wenn du Gewissheit brauchst; beschreibe nicht alle 302-Implementierungen als kaputt.

Jede 302 für einen SEO-Gewinn durch 307 ersetzen

Es gibt keinen Rankingvorteil. Ändere den Code nur dort, wo die Erhaltung von Methode und Body die Korrektheit verbessert oder der sicherere Standard eines Frameworks passt.

303 mit 307 verwechseln

Funktional sind sie bei der Methode Gegensätze: 303 ändert den Folge-Request bewusst in GET; 307 erhält ursprüngliche Methode und Body.

Eine unerwartete 307 oder einen fehlerhaften 302-Ablauf diagnostizieren

DevTools zeigt eine unerklärte Internal Redirect / 307

Symptom: Eine Navigation zu http:// erscheint in Chrome als 307, obwohl keine Weiterleitungsregel existiert.

Wahrscheinliche Ursache: HSTS hat den Request im Browser hochgestuft, bevor er den Server erreichte.

Behebung: Prüfe Initiator und Header des Eintrags. Sende anschließend mit einem serverseitigen Tool direkt an die HTTP-URL, ohne Weiterleitungen automatisch zu verfolgen – nicht mit dem Browser, da auch ein frisches Inkognito-Fenster vorgeladenen HSTS-Zustand anwenden kann. Behandle curl ebenfalls nicht automatisch als neutrale Referenz: Es kann einen eigenen konfigurierten HSTS-Speicher haben. Wenn die rohe Serverantwort von DevTools abweicht, „behebe“ nicht die Phantom-307; prüfe die echte HTTP→HTTPS-Serverweiterleitung separat und teste jeden Nicht-GET-Request kontrolliert. Ein automatisch folgendes HEAD kann Methode-/Body-Verhalten bei POST nicht beweisen.

Ein POST verliert nach einer vorübergehenden Weiterleitung seinen Body

Symptom: Ein Formular, Webhook, Login oder API-Aufruf erreicht das Ziel als GET oder ohne Payload.

Wahrscheinliche Ursache: Die Quelle verwendete 302, wodurch der Client die Methode ändern durfte, oder ein Vermittler schrieb die Antwort um.

Behebung: Verwende für den vorübergehenden Wechsel 307, wiederhole anschließend einen sicheren Test-Request und bestätige in den Ziel-Logs, dass Methode, Content-Type und Body unverändert angekommen sind.

Die Plattform gibt 307 aus, obwohl du eine generische Weiterleitung gewählt hast

Symptom: Ein Framework oder eine Edge-Plattform gibt 307 statt des erwarteten 302 zurück.

Wahrscheinliche Ursache: Die Plattform hat den methodenerhaltenden vorübergehenden Code gewählt, oft für einen Nicht-GET-Request.

Behebung: Prüfe, ob der Wechsel wirklich vorübergehend ist und die Erhaltung des Requests korrekt ist. Wenn ja, behalte den Code – Google behandelt beide gleich. Ändere ihn nur, wenn Anwendungsemantik oder Client-Kompatibilität eine andere Antwort erfordern.

302 vs. 307 auf einen Blick

Faustregel: Gewöhnlicher vorübergehender Seiten-GET → beide funktionieren; vorübergehender Nicht-GET-Request, der intakt ankommen muss → 307.

Werkzeuge, um die tatsächlich empfangene Weiterleitung zu erkennen

Patricks kostenloses Tool

• Bulk HTTP Status Code Checker – sende serverseitige Requests für bis zu 500 URLs und prüfe die echten Codes und Ketten. Besonders nützlich, um Serverantworten von Chromes interner HSTS-307-Anzeige zu unterscheiden.

Request-Verhalten prüfen

• Redirect Checker – verfolge eine einzelne Quelle über jeden Hop und bestätige, ob der Server mit 302 oder 307 beginnt.
• Netzwerk-Panel der Browser-DevTools – prüfe Initiator und ob Chrome einen Eintrag als interne Weiterleitung markiert; allein das beweist keine Serverantwort.
• curl plus Anwendungslogs – sende einen sicheren POST an die Staging-Umgebung und bestätige, dass das Ziel dieselbe Methode und denselben Body erhält. Wenn du curl mit eigenem HSTS-Speicher (--hsts) konfiguriert hast, berücksichtige das bei der Auswertung. Status-Tools allein beweisen nicht, dass ein Payload angekommen ist.

Teste dich selbst: 302 vs. 307

Fünf Fragen zu den beiden vorübergehenden Weiterleitungen und dem tatsächlichen Unterschied zwischen ihnen. Wähle jeweils eine Antwort und prüfe anschließend.

Ressourcen, die sich lohnen

Meine verwandten Texte

• 11 Arten von Weiterleitungen und ihre SEO-Auswirkungen (Ahrefs, mit Joshua Hardwick) – meine vollständige Übersicht über alle Weiterleitungstypen. Hier erkläre ich die bevorzugte Reihenfolge für vorübergehende Weiterleitungen – 307 / 302 / 303 > Meta-Refresh 0 / HTTP-Refresh 0 – und formuliere das SEO-Fazit klar: “For SEO, it’s the same, but if you have data being sent through forms that redirect, then you don’t want to be swapping between GET and POST.” (Übersetzung) „Für SEO ist es dasselbe, aber wenn Daten durch weiterleitende Formulare gesendet werden, solltest du nicht zwischen GET und POST wechseln.“
• HTTP-Statuscodes und ihre SEO-Auswirkungen (Ahrefs) – meine Referenz für jeden Statuscode, einschließlich der zwei unterschiedlichen Bedeutungen von 307 (Temporary Redirect und HSTS Policy 307) und des Hinweises: “Google won’t see the 307 because it’s cached in the browser.” (Übersetzung) „Google sieht die 307 nicht, weil sie im Browser gecacht ist.“
• Der Einsteigerleitfaden für technisches SEO – dort gehören Weiterleitungen in das größere Bild.

Meine Vorträge

• Patrick Stox auf SlideShare und Speaker Deck – meine Vorträge zu technischem SEO, in denen es unter anderem um Weiterleitungen und Kanonisierung geht. (Mein dauerhafter Hinweis: “This is my understanding of systems… not going to be 100% complete or accurate.” (Übersetzung) „Das ist mein Verständnis von Systemen … es wird nicht zu 100 % vollständig oder korrekt sein.“)

Offiziell

• Google – HTTP-Statuscodes, Netzwerk- und DNS-Fehler – die Zeile „Equivalent to 302“ und der Hinweis „semantisch unterschiedlich, passenden Code verwenden“.
• Google – Weiterleitungen und Google Search – gruppiert 302/303/307 als vorübergehende Weiterleitungen.
• Search-Off-the-Record – „Let’s talk redirects“ (Google Search Relations, Folge 51) – das Mueller-/Splitt-Gespräch, aus dem die obigen Zitate stammen.

Aus der Branche

• John Mueller – 307s – die klarste Erklärung der HSTS-„Phantom-307“: das 307, das dein Browser zeigt, aber dein Server nie gesendet hat.
• MDN – 307 Temporary Redirect – die klare Definition der Methoden-/Body-Erhaltung und der historische Hinweis zu älteren Clients.
• Ein SEO-Leitfaden zu Weiterleitungen (Search Engine Land, Helen Pollitt) – eine gute allgemeine Übersicht der Weiterleitungsfamilie.
• URL-Weiterleitungen für SEO: Ein technischer Leitfaden (Search Engine Journal) – eine weitere gute technische Übersicht.
• Ein Mythos zur Korrektur: Conductor-Seite „302 vs. 307“ empfiehlt 302 statt 307, weil “it’s clear how search engines treat the 302 redirect” (Übersetzung) „klar ist, wie Suchmaschinen die 302 behandeln“. Das widerspricht Googles eigener Dokumentation, die 307 ausdrücklich “Equivalent to 302” (Übersetzung) „gleichwertig mit 302“ nennt – die Behandlung von 307 ist genauso dokumentiert. Betrachte die Formulierung “302 is the safer SEO choice” (Übersetzung) „302 ist die sicherere SEO-Wahl“ nicht als maßgeblich; die einzige echte Entscheidung ist, ob Methode und Body erhalten werden müssen.
• r/TechSEO – die Community zum Debuggen von Weiterleitungen und Kanonisierung.

Änderungsprotokoll