307 Temporäre Weiterleitung

TL;DR — Eine 307 ist eine vorübergehende Weiterleitung, genau wie eine 302. Sie schickt Besucher und Suchmaschinen vorerst zu einer neuen URL, ohne Google mitzuteilen, dass das Ranking der alten URL auf die neue übertragen werden soll. Der entscheidende Unterschied zu 302: Eine 307 verspricht, die Art der Anfrage nicht zu ändern. Wenn jemand ein Formular absendet (POST), bleibt es ein POST. Bei einfachen Seiten-zu-Seiten-Links ist das unsichtbar; wichtig ist es nur für Formulare und Anwendungen. Und die „307“, die Sie bei einem HTTPS-Upgrade manchmal im Browser sehen, ist überhaupt keine echte Weiterleitung.

Was eine 307-Weiterleitung ist

Wenn eine URL vorerst an einen anderen Ort umgezogen ist — nicht dauerhaft — kann der Server mit einer 307 Temporary Redirect antworten und den Browser auf den neuen Ort verweisen. Das ist dieselbe Grundidee wie bei einer 302: Sie ist vorübergehend, daher behandelt Google sie nicht als Signal dafür, das Ranking der ursprünglichen URL auf das Ziel zu übertragen, wie es das bei einer dauerhaften Weiterleitung tut. Das ist ein schwaches, nicht kanonisierendes Signal und keine Garantie dafür, dass die ursprüngliche URL ihre Rankings behält oder für immer indexiert bleibt. Verwenden Sie eine vorübergehende Weiterleitung für eine Seite, die wegen Wartung nicht verfügbar ist, für eine saisonale Kampagne oder für etwas, das später wieder zurückgeschaltet werden soll.

Was eine 307 von einer 302 unterscheidet

Es gibt eigentlich nur einen Unterschied, mit dem die meisten Menschen nie in Berührung kommen. Eine Webanfrage hat eine Methode — meistens GET (eine Seite abrufen), manchmal aber POST (Daten senden, etwa beim Absenden eines Formulars). Eine 307 garantiert, dass der Browser beim Folgen der Weiterleitung dieselbe Methode beibehält. Ältere Browser wandelten bei einer 302 manchmal POST in GET um, wodurch eine Formularübermittlung scheitern konnte. Eine 307 beseitigt dieses Risiko durch die Spezifikation.

Bei der großen Mehrheit der Weiterleitungen — jemand klickt auf einen Link zu einer Seite — macht das überhaupt keinen Unterschied, weil es in beiden Fällen GET-Anfragen sind.

Schadet eine 307 der SEO?

Nein. Googles eigene Dokumentation sagt, dass eine 307 „gleichwertig zu“ einer 302 ist. Beide sind vorübergehend, daher überträgt keine von beiden das Ranking der alten Seite auf die neue, wie es eine dauerhafte Weiterleitung (301) tut. Es gibt weder eine geheime Strafe noch einen geheimen Bonus — eine 307 wird genau wie eine 302 behandelt.

Die „307“, die keine Weiterleitung ist

Hier liegt die häufigste Verwirrung. Wenn Ihre Website HTTPS erzwingt (eine Sicherheitsfunktion namens HSTS), zeigt Ihr Browser beim Besuch der HTTP-Version einer Seite in den Developer-Tools manchmal „307“. Ihr Server hat das nie gesendet — der Browser erzeugt die Anzeige selbst, um zu erklären, dass er direkt zur sicheren Version gesprungen ist. Er zeigt sogar eine Antwort mit 0 Byte, was der entscheidende Hinweis ist.

Wenn ein Audit-Tool oder Ihr Browser also eine unerwartete 307 meldet, geraten Sie nicht in Panik und nehmen Sie nicht sofort eine Fehlkonfiguration des Servers an. Ein frisches Inkognito-Fenster löscht normalerweise den vom Browser gelernten HSTS-Speicher und zeigt den echten Statuscode — aber nicht immer: Manche Domains stehen auf der eingebauten HSTS-Preload-Liste der Browser, die Inkognito nicht löscht. Ein Redirect Checker oder eine curl-Anfrage ist der zuverlässigere Weg, die tatsächliche Antwort Ihres Servers zu sehen.

Möchten Sie die Sprache der Spezifikation, John Muellers Aussagen, die HSTS-Mechanik im Detail und die konkrete Ausgabe einer 307? Wechseln Sie zum Tab Fortgeschritten.

TL;DR — Eine 307 ist gemäß RFC 9110 eine vorübergehende Weiterleitung, die “MUST NOT change the request method” (Übersetzung) „die Request-Methode nicht ändern darf“ — die eine feste Garantie, die eine 302 nicht gibt. Für SEO ist sie ein Nicht-Ereignis: Googles Dokumentation führt sie als “Equivalent to 302” (Übersetzung) „gleichwertig zu 302“ (ein schwaches, vorübergehendes Signal), und Mueller sagte, die Wahl zwischen 307 und 302 “doesn’t really matter” (Übersetzung) „spielt für die Suche keine wirkliche Rolle“ — entscheidend ist, ob die Weiterleitung für POST-/API-Traffic funktionieren muss. Die 307, die tatsächlich Verwirrung stiftet, ist das HSTS-Artefakt: eine browserinterne „Weiterleitung“ mit 0 Byte, die der Server nie gesendet hat und die entsteht, wenn der Browser HTTP eigenständig zu HTTPS hochstuft. Es gibt zwei funktional unabhängige Fälle, und sie auseinanderzuhalten ist die gesamte Aufgabe.

Eine 307 hat zwei völlig unterschiedliche Fälle

Das ist die ordnende Idee für alles Folgende und stammt direkt aus meinem Statuscodes-Leitfaden, in dem 307 zwei getrennte Einträge erhält: “307 Temporary Redirect – Has the same functionality as a 302 redirect, except you can’t switch between POST and GET” (Übersetzung) „307 Temporary Redirect – hat dieselbe Funktion wie eine 302-Weiterleitung, außer dass nicht zwischen POST und GET gewechselt werden kann“ und “307 HSTS Policy – Forces the client to use HTTPS when making requests instead of HTTP.” (Übersetzung) „307 HSTS Policy – zwingt den Client, Anfragen über HTTPS statt über HTTP zu stellen.“ Sie teilen sich eine Nummer und fast nichts anderes:

1. 307 als echte, vom Server ausgegebene vorübergehende Weiterleitung — absichtlich ausgewählt (oder von einem Framework als Standard verwendet), um Methode und Body einer Nicht-GET-Anfrage zu erhalten.
2. 307 als HSTS-Browserartefakt — überhaupt keine Serverantwort. Der Browser stuft HTTP intern zu HTTPS hoch und beschriftet dieses Upgrade als 307.

Diese beiden Fälle zu vermischen ist die häufigste Quelle der 307-Verwirrung. Ich behandle sie nacheinander.

Fall 1: die echte 307 — was die Spezifikation tatsächlich verlangt

RFC 9110, die aktuelle Spezifikation für HTTP-Semantik, ist in §15.4.8 eindeutig:

“The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (Übersetzung) „Der Statuscode 307 (Temporary Redirect) zeigt an, dass die Zielressource vorübergehend unter einer anderen URI liegt und der User-Agent die Request-Methode NICHT ändern DARF, wenn er automatisch zu dieser URI weiterleitet.“

Dieses „DARF NICHT“ ist eine harte Anforderung, keine Empfehlung. Vergleichen Sie das mit dem Abschnitt zu 302 (§15.4.3), der das historische Durcheinander, zu dessen Behebung 307 geschaffen wurde, offen dokumentiert: “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.” (Übersetzung) „Aus historischen Gründen DARF ein User-Agent die Request-Methode für die folgende Anfrage von POST zu GET ändern. Wenn dieses Verhalten unerwünscht ist, kann stattdessen der Statuscode 307 (Temporary Redirect) verwendet werden.“ 307 existiert ausdrücklich, um die POST→GET-Mehrdeutigkeit zu beseitigen, die ältere Clients bei 302s hatten.

MDN beschreibt dieselbe Unterscheidung in der Praxis:

“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. 307 and 302 responses are identical when the request method is GET.” (Übersetzung) „Der Unterschied zwischen 307 und 302 besteht darin, dass 307 garantiert, dass der Client die Request-Methode und den Body bei der weitergeleiteten Anfrage nicht ändert. Bei 302 änderten ältere Clients die Methode fälschlicherweise zu GET. 307- und 302-Antworten sind identisch, wenn die Request-Methode GET ist.“

Der letzte Satz ist für SEO am wichtigsten. Fast jede Weiterleitung, die für SEO relevant ist — eine alte Seite zu einer neuen — ist eine GET-Anfrage, und bei GET-Anfragen sind 307 und 302 buchstäblich identisch. Die Garantie der Methodenerhaltung greift nur, wenn die Methode nicht GET ist: bei erneuten Formularübermittlungen, API-Endpunkten, Webhook-Zielen sowie Checkout- oder Auth-POST-Übergaben. Die Spezifikation garantiert Methode und Body, legt aber nicht automatisch den exakten Umgang jedes Clients mit Headern, Anmeldedaten oder Cross-Origin-Anfragen bei der Wiederholung fest. Prüfen Sie das daher mit Ihrem tatsächlichen Client. Der direkte Vergleich der beiden Codes bei einem normalen Seitenumzug wird im eigenen Beitrag zu 302 vs. 307 ausführlich behandelt.

302 vs. 303 vs. 307 in einer Tabelle

Alle drei liegen in der „vorübergehenden“ Gruppe der RFC, verhalten sich aber auf den zwei entscheidenden Achsen — Methodenerhaltung und Caching — nicht gleich:

Keiner der drei Statuscodes ist standardmäßig heuristisch cachebar — eine 307 (wie 302 und 303) benötigt ein ausdrückliches Frische-Signal (Cache-Control, Expires usw.), bevor ein Cache sie ohne erneute Anfrage speichert.

Fall 1, Fortsetzung: Wie Google eine echte 307 für SEO behandelt

Die Kurzfassung: genau wie eine 302. Googles Dokumentation zu HTTP-Statuscodes führt die 307-Zeile als “Equivalent to 302,” (Übersetzung) „gleichwertig zu 302“ auf, und die geerbte 302-Zeile erklärt, was das bedeutet:

“By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (Übersetzung) „Standardmäßig folgen Googles Crawler der Weiterleitung, und Google-Systeme verwenden die Weiterleitung als schwaches Signal dafür, dass das Weiterleitungsziel verarbeitet werden soll.“

„Schwach“ ist das entscheidende Wort — eine vorübergehende Weiterleitung konsolidiert die Kanonisierung nicht auf dem Ziel, wie eine dauerhafte Weiterleitung es tut. Googles Dokumentation Redirects and Google Search gruppiert 302, 303 und 307 unter „vorübergehend“ und sagt: “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 die Weiterleitung nicht als Signal dafür, dass das Weiterleitungsziel kanonisch sein soll.“ Auf derselben Seite heißt es außerdem: “If you just want to send users to a different page temporarily, use a temporary redirect.” (Übersetzung) „Wenn Sie Nutzer nur vorübergehend an eine andere Seite senden möchten, verwenden Sie eine vorübergehende Weiterleitung.“

Direkt nach den Zeilen zu 307 und 308 fügt Google den Hinweis hinzu, den man sich an die Wand tätowieren sollte:

“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) „Auch wenn Google diese Statuscodes gleich behandelt, bedenken Sie, dass sie semantisch verschieden sind. Wählen Sie den für die Weiterleitung passenden Statuscode, damit andere Clients – etwa E-Reader und andere Suchmaschinen – davon profitieren können.“

Google fasst 307 und 302 für Rankings also in einer Gruppe zusammen, sagt Ihnen aber weiterhin, den semantisch richtigen Code auszuwählen. Das ist die gesamte SEO-Antwort. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the HTTP semantics differ. Scope: Google Search redirect handling; clients still need the semantically appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search John Mueller formulierte es im Podcast Search Off the Record, Folge 51 (“Let’s talk redirects”), noch direkter. Er erklärte, dass “with 307, 308, it also forwards POST requests” (Übersetzung) „bei 307 und 308 werden auch POST-Anfragen weitergeleitet“ — anders als bei 301/302, die GET-Anfragen weiterleiten — und brachte den Punkt anschließend auf den Nenner:

“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) „Meiner Ansicht nach ist das für SEO nicht wirklich entscheidend. Die eigentliche Frage lautet eher: Funktioniert es für APIs? Normalerweise müssen APIs nicht direkt in der Suche indexiert werden.“

Es gibt keinen Rankingvorteil, wenn Sie Ihre vorübergehenden Weiterleitungen auf 307 umstellen. Der einzige stichhaltige Grund ist die Erhaltung von Methode und Body — oder, als allgemeine Präferenz für Zukunftssicherheit, die ich am Ende bespreche.

Fall 1, Fortsetzung: Framework- und CDN-Standards

Immer mehr Fragen nach dem Muster „Warum ist das eine 307?“ sind keine bewusste Entscheidung, sondern Framework-Standards. Die Funktion redirect() von Next.js verwendet standardmäßig 307; der Begriff redirect bezeichnet dabei die Weiterleitung. Die Dokumentation erklärt: „Die Methode redirect() verwendet standardmäßig 307 statt einer vorübergehenden 302, was bedeutet, dass Ihre Anfragen immer als POST-Anfragen erhalten bleiben.“ Next.js verwendet innerhalb von Server Actions gezielt 303 und stellt für 308 die Funktion permanentRedirect() bereit. Wenn Sie 307s sehen, die Sie nicht selbst geschrieben haben, prüfen Sie, ob Ihr Framework oder Ihre Edge-Plattform sie bei Nicht-GET-Weiterleitungen als Standard verwendet — das ist normalerweise die Erklärung und normalerweise korrekt.

Fall 2: das HSTS-„Phantom-307“, das Ihr Server nie gesendet hat

Wenn eine Website einen Strict-Transport-Security-(HSTS-)Header sendet, sagt sie dem Browser: Lade mich ab jetzt ausschließlich über HTTPS. Bei der nächsten Anfrage an die HTTP-Version stuft der Browser selbst auf HTTPS hoch, ohne mit dem Server zu sprechen — und zeigt dieses interne Upgrade in Developer-Tools und Crawlern als „307“ an.

John Mueller erklärte die Mechanik 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. 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) „Nachdem Chrome die HTTPS-URL mit dem HSTS-Header gesehen hat (zum Beispiel nach einer Weiterleitung von der HTTP-Version), verhält es sich beim nächsten Versuch, die HTTP-Seite aufzurufen, so, als würde es eine 307-Weiterleitung sehen. Ihr Server gibt keine 307 zurück, Chrome zeigt sie Ihnen nur so an, um zu erklären, dass es die Weiterleitung für Sie übernimmt.“

Der Body mit 0 Byte ist der Hinweis — wie Mueller ergänzt: “the 307 isn’t actually a redirect at all, it’s just a placeholder.” (Übersetzung) „Die 307 ist eigentlich überhaupt keine Weiterleitung, sondern nur ein Platzhalter.“ Mein Weiterleitungsleitfaden fasst die praktische Folge für Audits zusammen: “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. The initial hit (without cache) will have a server response code that’s likely a 301 or a 302. But your browser will show you a 307 for subsequent requests which makes it more difficult to troubleshoot. You will need to use a fresh Incognito session to see the returned status code.” (Übersetzung) „Wenn Webserver von Clients ausschließlich HTTPS-Verbindungen verlangen (HSTS-Richtlinie), sieht Google die 307 nicht, weil sie im Browser gecacht ist. Der erste Abruf ohne Cache liefert wahrscheinlich den Serverstatus 301 oder 302. Der Browser zeigt bei späteren Anfragen jedoch eine 307 an, was die Fehlersuche erschwert. Sie müssen eine frische Inkognito-Sitzung verwenden, um den zurückgegebenen Statuscode zu sehen.“

Was Googlebot bei HSTS tatsächlich sieht (und wie sich die Aussage entwickelt hat)

Zwei Google-Aussagen im Abstand von fünf Jahren sollte man zusammen lesen. Im Dezember 2015 sagte Zineb Ait Bahajji laut Search Engine Roundtable: “With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’.” (Übersetzung) „Bei aktiviertem HSTS sieht Googlebot eine 301-Weiterleitung (probieren Sie es mit Fetch as Google). Die 307 ist lediglich eine ,interne Weiterleitung‘.“ Im Oktober 2020 war Muellers Einordnung in einem Ask-Google-Webmasters-Video (über Search Engine Journal) anders: “In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects.” (Übersetzung) „Kurz gesagt: [Googlebot] arbeitet damit nicht; diese 307-Weiterleitungen sind im Allgemeinen keine echten Weiterleitungen.“ In beiden Fällen sieht der Crawler nicht dieselbe 307 wie ein Mensch in Developer-Tools. Behandeln Sie die Aussage von 2020 als aktuelle Anleitung; die Aussage von 2015 ist nützliche Geschichte.

Die wichtige operative Schlussfolgerung: HSTS ist eine Komfortfunktion des Browsers, kein Mechanismus zur Erkennung durch Crawler. Website-Betreiber benötigen weiterhin eine echte serverseitige Weiterleitung (eine echte 301) für HTTP→HTTPS, wenn dieser Pfad für Crawler funktionieren soll.

Wie Bing eine 307 behandelt

Ehrlich gesagt gibt es hier eine Dokumentationslücke. Ich habe keine öffentliche Aussage von Bing gefunden, die 307 ausdrücklich oder speziell die HSTS-bedingte 307 behandelt. Bings Weiterleitungsleitfäden behandeln nur die dauerhafte-vs.-vorübergehende Trennung von 301 und 302 — 307, 308 und HSTS werden nicht erwähnt. Nehmen Sie daher keine Gleichheit mit Google an: Bing hat öffentlich nichts Spezifisches zu 307 gesagt. Das Phänomen ist unabhängig von der Suchmaschine real und für Crawler relevant — Screaming Frogs SEO Spider bietet deshalb einen Schalter „Respect HSTS Policy“ — aber das ist Tool-Dokumentation und keine Aussage von Bing.

Wann Sie bewusst eine 307 wählen

Wählen Sie eine 307 (statt einer 302), wenn der Verlust der ursprünglichen Methode oder des Bodys etwas beschädigen würde:

• API-Endpunkte und Webhook-Ziele, die POST/PUT/PATCH empfangen.
• Formularübermittlungen (POST), die nach der Verarbeitung weiterleiten.
• Checkout-/Login-POST-Übergaben zwischen Hosts.
• Alles, was einen Body trägt, den Sie nicht verlieren können.

Bei einem einfachen Seiten-zu-Seiten-Umzug sind 302 und 307 für Google nicht zu unterscheiden, daher sind beide aus SEO-Sicht in Ordnung. Bei der dauerhaften Variante derselben Methodenerhaltungslogik ist das die Beziehung 301 zu 308 — 308 verhält sich zu 301 wie 307 zu 302.

Meine eigene Präferenz aus dem Weiterleitungsleitfaden ist eindeutiger als das übliche „spielt keine Rolle“: “my preferred order would be: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0.” (Übersetzung) „Meine bevorzugte Reihenfolge wäre: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0.“ Ich setze 307 unter den vorübergehenden Optionen an die erste Stelle, weil sie bei der Methodenerhaltung zukunftssicher ist. Egal, was Sie wählen: Achten Sie darauf, dass eine echte 307 oder das HSTS-Artefakt nicht zu einem Hop in einer längeren Weiterleitungskette wird — jeder zusätzliche Hop bedeutet Latenz und verlorene Effizienz.

KI-Zusammenfassung

Eine komprimierte Zusammenfassung der Advanced-Version:

• Eine 307 hat zwei unabhängige Fälle. (1) Eine echte, vom Server ausgegebene vorübergehende Weiterleitung, die HTTP-Methode und Body erhält; (2) ein HSTS-Browserartefakt — eine 307 mit 0 Byte, die der Server nie gesendet hat und die entsteht, wenn der Browser selbst HTTP zu HTTPS hochstuft.
• Fall 1 — die Garantie der Spezifikation: RFC 9110 sagt, eine 307 “MUST NOT change the request method.” (Übersetzung) „die Request-Methode nicht ändern darf.“ MDN ergänzt, dass “307 and 302 responses are identical when the request method is GET” (Übersetzung) „307- und 302-Antworten bei GET identisch sind“ — relevant ist die Unterscheidung also nur bei POST/PUT/PATCH. Die Garantie umfasst Methode und Body; der Umgang mit Headern, Anmeldedaten und Cross-Origin-Anfragen hängt weiterhin vom Client ab.
• 302 vs. 303 vs. 307: 302 kann historisch POST zu GET ändern, 303 ruft das Ziel bewusst mit GET/HEAD ab, 307 darf die Methode nicht ändern — und keiner der drei Codes ist standardmäßig heuristisch cachebar.
• SEO-Antwort: Googles Dokumentation führt 307 als “Equivalent to 302” (Übersetzung) „gleichwertig zu 302“ — ein schwaches, vorübergehendes Signal, das Rankings nicht wie eine dauerhafte Weiterleitung auf dem Ziel konsolidiert. Mueller sagte für SEO, “it doesn’t really matter” (Übersetzung) „es spielt keine wirkliche Rolle“; die eigentliche Frage ist: “does it work for APIs.” (Übersetzung) „funktioniert es für APIs.“
• Framework-Standards: Next.js redirect() verwendet standardmäßig 307, 303 in Server Actions und permanentRedirect() für 308, um POST zu erhalten.
• Fall 2 — HSTS: Der Browser zeigt eine 307 mit 0-Byte-Body; der echte Servercode ist normalerweise 301/302. Googlebot sieht diese 307 nicht. Für HTTP→HTTPS benötigen Sie weiterhin eine echte serverseitige 301. Prüfen Sie mit Redirect Checker oder einfachem curl; Inkognito funktioniert nicht für Domains auf der eingebauten HSTS-Preload-Liste.
• Bing: Keine öffentliche, spezifische Aussage zu 307 — eine Dokumentationslücke, kein Beleg für Gleichbehandlung.
• Präferenz: Es gibt keinen Rankinggrund, auf 307 umzuschalten; 307 steht unter den vorübergehenden Optionen zur Zukunftssicherheit an erster Stelle.

Offizielle Dokumentation

Primärquellen und Spezifikationen.

Google

• HTTP-Statuscodes, Netzwerk- und DNS-Fehler sowie die Google-Suche — die Zeile „307 (temporary redirect) — Equivalent to 302“, die Formulierung zum schwachen Signal bei 302 und der Hinweis, dass die Codes semantisch unterschiedlich sind.
• Redirects and Google Search — gruppiert 302/303/307 unter „vorübergehend“; die Indexierungspipeline verwendet die Weiterleitung nicht als Signal, dass das Ziel kanonisch sein soll.

Bing / Microsoft

• Weiterleitungen verwalten – 301er, 302er und kanonische URLs — Bings Anleitung behandelt nur 301/302 und erwähnt 307/HSTS nicht.
• Website-Migration mit Bing — Migrationsanleitung, ebenfalls nur 301/302.

HTTP-Spezifikation

• RFC 9110 §15.4.8 — 307 Temporary Redirect — die Methode darf nicht geändert werden.
• RFC 9110 §15.4.3 — 302 Found — der historische Hinweis zu POST→GET, der auf 307 verweist.

Technische Referenz

• MDN — 307 Temporary Redirect — Erhaltung von Methode und Body; identisch, wenn die Request-Methode GET ist.

Framework

• Next.js — Referenz zur Funktion redirect() — die FAQ „Warum verwendet redirect 307 und 308?“; standardmäßig 307, 303 in Server Actions.

Crawler-Tools

• Screaming Frog — An SEO’s Guide To Crawling HSTS & 307 Redirects — Konfiguration für die HSTS-Richtlinie und HSTS-Mechanik.

Zitate aus den Quellen

Nachprüfbare Aussagen. Jeder Link führt zur zitierten Passage oder dokumentiert sie.

Google-Dokumentation — die SEO-Behandlung

• “307 (temporary redirect) — Equivalent to 302.” (Übersetzung) „307 (vorübergehende Weiterleitung) — gleichwertig zu 302.“ Zum Zitat springen
• “By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (Übersetzung) „Standardmäßig folgen Googles Crawler der Weiterleitung, und Google-Systeme verwenden die Weiterleitung als schwaches Signal dafür, dass das Weiterleitungsziel verarbeitet werden soll.“ (die 307-Zeile übernimmt diese Formulierung aus der 302-Zeile) Zum Zitat springen
• “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) „Auch wenn Google diese Statuscodes gleich behandelt, sollten Sie bedenken, dass sie semantisch unterschiedlich sind. Verwenden Sie den Statuscode, der für die Weiterleitung angemessen ist, damit andere Clients davon profitieren können.“ Zum Zitat springen
• “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 die Weiterleitung nicht als Signal dafür, dass das Weiterleitungsziel kanonisch sein soll.“ Zum Zitat springen

HTTP-Spezifikation / MDN — die technische Garantie

• “The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (Übersetzung) „Der Statuscode 307 (Temporary Redirect) zeigt an, dass die Zielressource vorübergehend unter einer anderen URI liegt und der User-Agent die Request-Methode NICHT ändern DARF, wenn er automatisch zu dieser URI weiterleitet.“ — RFC 9110, §15.4.8. Abschnitt lesen
• “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.” (Übersetzung) „Aus historischen Gründen DARF ein User-Agent die Request-Methode für die folgende Anfrage von POST zu GET ändern. Wenn dieses Verhalten unerwünscht ist, kann stattdessen der Statuscode 307 (Temporary Redirect) verwendet werden.“ — RFC 9110, §15.4.3. Abschnitt lesen
• “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… 307 and 302 responses are identical when the request method is GET.” (Übersetzung) „Der Unterschied zwischen 307 und 302 besteht darin, dass 307 garantiert, dass der Client die Request-Methode und den Body bei der weitergeleiteten Anfrage nicht ändert … 307- und 302-Antworten sind identisch, wenn die Request-Methode GET ist.“ — MDN, 307 Temporary Redirect. Zum Zitat springen

John Mueller, Google — SEO und Methodenerhaltung

• “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) „Ich denke, für SEO spielt es keine wirkliche Rolle. Es geht eher um die Frage: Funktioniert es für APIs oder nicht? Und normalerweise müssen APIs nicht direkt in der Suche indexiert werden.“ — Search Off the Record, Folge 51. Transkript-PDF
• “And with 307, 308, it also forwards POST requests” (Übersetzung) „Und bei 307 und 308 werden auch POST-Anfragen weitergeleitet“ (im Gegensatz zu 301/302, die GET-Anfragen weiterleiten). — dieselbe Folge.

John Mueller, Google — das HSTS-„Phantom-307“

• “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… the 307 isn’t actually a redirect at all, it’s just a placeholder.” (Übersetzung) „Ihr Server gibt keine 307 zurück, Chrome zeigt sie Ihnen nur so an, um zu erklären, dass es die Weiterleitung für Sie übernimmt … die 307 ist eigentlich überhaupt keine Weiterleitung, sondern nur ein Platzhalter.“ — John Mueller, HTTPS & HSTS: 301, 302, or 307? Zum Zitat springen
• “In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects.” (Übersetzung) „Kurz gesagt, Googlebot interagiert nicht mit ihnen. 307-Weiterleitungen sind im Allgemeinen keine echten Weiterleitungen.“ — John Mueller, Ask Google Webmasters. Zum Zitat springen

Zineb Ait Bahajji, Google — HSTS, 2015 (überliefert)

• “With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’.” (Übersetzung) „Mit aktiviertem HSTS sieht Googlebot eine 301-Weiterleitung. Die 307 ist nur eine interne Weiterleitung.“ — Zineb Ait Bahajji (Google), über Twitter, berichtet von Search Engine Roundtable. Zum Zitat springen

Welche 307 sehe ich tatsächlich?

Fast jede Frage zu 307 lässt sich auf eine von zwei völlig unterschiedlichen Situationen zurückführen. Gehen Sie diese Fälle Schritt für Schritt durch.

Mythen und Fehler, die Sie vermeiden sollten

„Eine 307 überträgt nicht dieselbe Linkkraft wie eine 302.“ Falsch ist die Einordnung „307 ist schlechter als 302“. Googles Dokumentation verarbeitet 307 und 302 gleich: Beide sind nicht kanonisierende, vorübergehende Weiterleitungen mit schwachem Signal, und die Dokumentation nennt 307 ausdrücklich „gleichwertig zu 302“. Es gibt keine dokumentierte Grundlage dafür, 307 eine geringere Übertragung als 302 zuzuschreiben. Vorübergehende Weiterleitungen sind allgemein nicht dazu gedacht, Rankingsignale auf das Ziel zu konsolidieren — lassen Sie sich daher von einer Behauptung, 307 halte speziell Linkkraft zurück, nicht zu unnötigen Änderungen drängen.

„Eine 307 in meinem Network-Tab bedeutet, dass mein Server eine Weiterleitung falsch konfiguriert hat.“ Oft falsch. Wenn HSTS aktiviert ist und der Browser zuvor den Strict-Transport-Security-Header gesehen hat, zeigt er ein HTTP→HTTPS-Upgrade nur als eigene Erklärung als 307 an — der Server hat sie nie zurückgegeben. Eine frische Inkognito-Sitzung zeigt normalerweise den echten Code, aber nicht bei Domains auf der eingebauten HSTS-Preload-Liste. Testen Sie dort mit Redirect Checker oder curl ohne HSTS-Konfiguration.

„Googlebot sieht bei einer HSTS-Website dieselbe 307 wie mein Browser.“ Nicht ganz. Google-Vertreter sagten, Googlebot sehe entweder eine 301 (Zineb, 2015) oder interagiere überhaupt nicht mit dem 307-/HSTS-Mechanismus (Mueller, 2020). In beiden Fällen handelt es sich nicht um die für Menschen sichtbare 307. Sie benötigen für HTTP→HTTPS weiterhin eine echte serverseitige 301.

„303 und 307 sind im Grunde austauschbar.“ Auf der entscheidenden Achse sind sie Gegensätze. Eine 303 wechselt immer zu GET (Post/Redirect/Get); eine 307 garantiert, dass die Methode nicht geändert wird. Verwechselbar sind sie nur, weil beide neben 302 in der vorübergehenden Gruppe stehen.

„Stellen Sie alle vorübergehenden Weiterleitungen für bessere Rankings auf 307 um.“ Es gibt keinen Bonus. Der einzige gültige Grund, 307 gegenüber 302 zu bevorzugen, ist die tatsächliche Erhaltung von Methode und Body oder allgemeine Zukunftssicherheit. Alle 302s auf 307 umzustellen bringt nichts und kann Fehler einführen.

„302s wandeln POST immer in GET um, daher ist 302 für Formulare grundsätzlich kaputt.“ Das ist übertrieben. Die POST→GET-Umwandlung war bei älteren, uneinheitlichen Clients ein echtes Problem — genau deshalb gibt es 307 als garantierte Option — moderne Browser verhalten sich aber deutlich konsistenter. 307 beseitigt die Mehrdeutigkeit durch die Spezifikation; das bedeutet nicht, dass 302 kaputt ist.

Den echten Statuscode sehen (nicht das HSTS-Artefakt)

Sobald HSTS gecacht ist, verbirgt der Browser eine echte 301/302 hinter einer Phantom-307. curl verwendet standardmäßig kein HSTS, daher spricht ein einfacher Aufruf direkt mit dem Server und zeigt die Wahrheit — führen Sie ihn nur nicht mit einer konfigurierten --hsts-Cache-Datei aus.

Die vollständige Weiterleitungskette nur anhand der Header verfolgen

# -s silent, -I headers-only, -L follow redirects, cap the hops
curl -sIL --max-redirs 10 http://example.com/old-page 2>&1 \
  | grep -Ei '^(HTTP/|location:)'
# Each "HTTP/…" line is one hop's real status code; each "location:" is where it points.
# An HSTS "307" never appears here — it's browser-only.

Den Statuscode einer URL prüfen, ohne der Weiterleitung zu folgen

curl -s -o /dev/null -w "%{http_code}\n" http://example.com/old-page

Chrome-DevTools-Konsole — eine Phantom-307 erkennen

Fügen Sie dies in den Tab „Console“ ein. Eine echte Serverweiterleitung liefert ein redirected-Flag und eine aufgelöste URL; das HSTS-Upgrade passiert, bevor die Anfrage den Browser überhaupt verlässt.

// Fetch and report what the network actually did.
fetch("http://example.com/old-page", { redirect: "manual" })
  .then(r => console.log("type:", r.type, "status:", r.status, "url:", r.url))
  .catch(e => console.log("blocked before request (often HSTS upgrade):", e.message));

Sie können den HSTS-Eintrag von Chrome auch direkt unter chrome://net-internals/#hsts lesen — fragen Sie eine Domain ab, um zu sehen, ob static_upgrade_mode/dynamic_upgrade_mode HTTPS erzwingen.

Bookmarklet — schneller Header-Blick für den aktuellen Tab

Ziehen Sie ein Lesezeichen mit diesem Inhalt in die Lesezeichenleiste und klicken Sie es auf einer beliebigen Seite an, um Status und Weiterleitungsstatus der aktuellen URL in der Konsole zu protokollieren:

javascript:(function(){fetch(location.href,{redirect:"manual"}).then(function(r){console.log("[status]",r.status,"[type]",r.type,"[redirected]",r.redirected,"[url]",r.url);}).catch(function(e){console.log("[error]",e.message);});})();

Hinweis: Browser-fetch() kann keine bodylosen Redirects über Cross-Origin-Grenzen lesen. Für eine maßgebliche Verfolgung mehrerer Hops ist das obige curl -sIL die Quelle der Wahrheit.

Eine echte 307 zurückgeben

Der Zweck, eine 307 zurückzugeben (statt sie nur dem Framework-Standard zu überlassen), ist die Garantie, dass Methode und Body erhalten bleiben. Einige übliche Möglichkeiten, das ausdrücklich zu tun.

Apache (.htaccess)

# mod_rewrite with an explicit 307 (R=307). Preserves POST body.
RewriteEngine On
RewriteRule ^old-endpoint$ https://example.com/new-endpoint [R=307,L]

nginx

# 307 keeps the method; 302 would risk POST→GET on older clients.
location = /old-endpoint {
    return 307 https://example.com/new-endpoint;
}

Node / Express

app.post("/old-endpoint", (req, res) => {
  // res.redirect defaults to 302; pass 307 to preserve the POST + body.
  res.redirect(307, "https://example.com/new-endpoint");
});

Next.js (App Router) — 307 ist der Standard, daher schreiben Sie den Code oft gar nicht:

import { redirect } from "next/navigation";
// redirect() returns a 307 by default (303 inside a Server Action),
// preserving the request as a POST. Use permanentRedirect() for a 308.
export default function Page() {
  redirect("/new-endpoint");
}

Wie eine rohe 307-Antwort aussieht

HTTP/1.1 307 Temporary Redirect
Location: https://example.com/new-endpoint
Content-Length: 0

Wie das HSTS-„Phantom-307“ aussieht (nur im Browser)

Dieselbe Statuszeile in den Developer-Tools, aber achten Sie auf die Hinweise — sie stammt aus dem Browser, nicht vom Server, und trägt einen Body mit 0 Byte:

HTTP/1.1 307 Internal Redirect
Location: https://example.com/old-page
Non-Authoritative-Reason: HSTS

Wenn Sie Non-Authoritative-Reason: HSTS (Chrome) oder eine 307 mit 0 Byte sehen, die bei einem Client ohne HSTS-Unterstützung verschwindet, handelt es sich um das Artefakt — nicht um eine Weiterleitung, die Ihr Server gesendet hat. Der genaue Headername und die Beschriftung in DevTools sind browserspezifische Implementierungsdetails, keine Garantie der HTTP- oder HSTS-Spezifikation.

Methode, Dauer und Herkunft der Weiterleitung

Ich bewerte eine 307 auf drei Achsen, bevor ich sie ändere:

1. Methode: Muss das Ziel die ursprüngliche Methode und den Request-Body erhalten? Wenn ja, ist 307 die vorübergehende Weiterleitung, die beides erhält. Ein einfacher Seiten-zu-Seiten-GET benötigt diese Eigenschaft normalerweise nicht.
2. Dauer: Ist der Umzug wirklich vorübergehend? Behalten Sie 307 nur so lange, wie die Rückkehr der ursprünglichen URL erwartet wird. Ein dauerhafter Umzug erfordert eine dauerhafte Weiterleitungsentscheidung.
3. Herkunft: Hat der Server die 307 gesendet, hat ein Framework sie ausgewählt oder hat der Browser ein internes HSTS-Upgrade erzeugt? Ein Internal Redirect in DevTools ist keine Origin-Regel, die Sie umschreiben sollten.

Tools zum Trennen echter und Phantom-307s

• Redirect Checker: Sehen Sie Status, Ziel und jeden Hop, ohne vom HSTS-Zustand eines einzelnen Browsers abhängig zu sein.
• Redirect Chain Mapper: Verwenden Sie die Ansicht pro Hop, wenn eine 307 Teil eines längeren Weiterleitungspfads ist.
• HTTP Header Checker: Prüfen Sie Location und Strict-Transport-Security und vergleichen Sie Edge- und Origin-Hinweise.
• curl: Führen Sie curl -I http://example.com/path außerhalb der internen HSTS-Anzeige des Browsers aus. Testen Sie POST-Erhaltung nur gegen einen sicheren Endpunkt, den Sie kontrollieren.
• Browser-DevTools: Prüfen Sie, ob der Eintrag „Internal Redirect“ sagt und eine Übertragung von null Byte hat.

Eine 307 nach dem Deployment validieren

Status- und Zieltest

Auszuführender Test: Prüfen Sie die Quelle mit dem Redirect Checker oder curl -I. Erwartetes Ergebnis: genau eine 307 mit dem vorgesehenen Location-Ziel. Interpretation eines Fehlschlags: Eine andere Schicht hat Regel oder Ziel geändert. Beobachtungsfenster: sofort. Rollback-Auslöser: Eine Schleife, ein defektes Ziel oder ein unerwarteter Hostname erscheint.

Test der Methodenerhaltung

Auszuführender Test: Senden Sie ein harmloses POST an eine kontrollierte Test-Route und prüfen Sie, was das Ziel erhält. Erwartetes Ergebnis: Das Ziel erhält POST mit dem ursprünglichen Body. Interpretation eines Fehlschlags: Ein Vermittler hat die Methode geändert oder einen anderen Code ausgeliefert. Beobachtungsfenster: sofort. Rollback-Auslöser: Eine Formular-, Webhook- oder Checkout-Anfrage verliert Methode oder Body.

HSTS-Trennungstest

Auszuführender Test: Vergleichen Sie DevTools oder eine frische Inkognito-Sitzung mit einer curl -I-Anfrage ohne konfigurierten HSTS-Cache. Erwartetes Ergebnis: Ein Internal Redirect des Browsers ist von der echten Serverantwort unterscheidbar, und HTTP hat weiterhin eine serverseitige Weiterleitung. Interpretation eines Fehlschlags: HSTS verbirgt eine fehlende Origin-Regel; Inkognito allein reicht für Domains auf der eingebauten HSTS-Preload-Liste nicht aus. Beobachtungsfenster: sofort. Rollback-Auslöser: Die Origin-Änderung entfernt die funktionierende HTTP-zu-HTTPS-Weiterleitung.

Testen Sie Ihr Wissen: 307 Temporary Redirect

Fünf kurze Fragen dazu, was eine 307 ist, wie Google sie behandelt und was das HSTS-Artefakt bedeutet. Wählen Sie für jede eine Antwort und prüfen Sie die Antwort anschließend.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Texte

• 11 Arten von Weiterleitungen und ihre SEO-Auswirkungen — dort stammen die 307-Definition, der HSTS-Hinweis und meine bevorzugte Reihenfolge (307 / 302 / 303 zuerst) her.
• HTTP-Statuscodes und ihre SEO-Auswirkungen — mein Beitrag mit den zwei unterschiedlichen 307-Einträgen: der Fall der vorübergehenden Weiterleitung und der Fall der HSTS-Richtlinie.
• The Beginner’s Guide to Technical SEO — dort wird erklärt, wie Weiterleitungen in den größeren Zusammenhang passen.

Meine Vorträge

• How Search Works (SlideShare) — mein Überblick über Crawling, Rendering, Indexierung und Ranking, einschließlich des Umgangs mit Weiterleitungen. Mein ständiger Hinweis gilt: „Das ist mein Verständnis der Systeme … nicht zu 100 % vollständig oder korrekt.“

Aus der Branche

• John Mueller — HTTPS & HSTS: 301, 302, or 307? — die klarste Erklärung aus erster Hand zum HSTS-„Phantom-307“.
• Search Off the Record, Folge 51 — Let’s talk redirects (Transkript-PDF) — Mueller und Splitt dazu, warum 307/308 existieren und warum es für SEO keine wirkliche Rolle spielt.
• Google on 307/HSTS Redirects (Search Engine Journal) — Zusammenfassung von Muellers Aussage, dass 307-Weiterleitungen im Allgemeinen keine echten Weiterleitungen sind.
• GoogleBot Treats 307 Redirects As 301s? (Search Engine Roundtable) — Zinebs Aussage von 2015 dazu, was Googlebot bei HSTS sieht.
• MDN — 307 Temporary Redirect — die technische Referenz für die Garantie von Methode und Body.
• An SEO’s Guide To Crawling HSTS & 307 Redirects (Screaming Frog) — die beste Behandlung der Crawler-Konfiguration für HSTS-bedingte 307s.
• Next.js — redirect()-Referenz — warum ein großes Framework Nicht-GET-Weiterleitungen standardmäßig zu 307 macht.

Änderungsprotokoll