307 Tymczasowe przekierowanie

TL;DR — 307 to tymczasowe przekierowanie, podobnie jak 302 — na razie wysyła ludzi i wyszukiwarki pod nowy adres URL, nie mówiąc Google, aby przeniosło ranking starego adresu URL na nowy. Jedna rzecz odróżnia je od 302: 307 obiecuje, że nie zmieni metody żądania. Jeśli ktoś wysłał formularz metodą POST, pozostaje on POST-em. Przy zwykłych linkach strona–strona jest to niewidoczne; liczy się tylko w formularzach i aplikacjach. A „307”, który czasem widzisz w przeglądarce przy przejściu na HTTPS, wcale nie jest prawdziwym przekierowaniem.

Czym jest przekierowanie 307

Gdy adres URL został na razie przeniesiony gdzie indziej — nie na stałe — serwer może odpowiedzieć 307 Temporary Redirect i wskazać przeglądarce nowe miejsce. To ten sam podstawowy pomysł co 302: przeniesienie jest tymczasowe, więc Google nie traktuje go jako sygnału przekazania rankingu oryginalnego adresu URL na nowy, tak jak przy stałym przekierowaniu. To słaby sygnał bez kanonizacji celu, a nie gwarancja, że oryginalny adres URL zachowa rankingi lub na zawsze pozostanie w indeksie. Tymczasowego przekierowania użyjesz przy stronie wyłączonej na czas konserwacji, kampanii sezonowej albo wszystkim, co planujesz później cofnąć.

Co odróżnia 307 od 302

W praktyce istnieje tylko jedna różnica, na którą większość ludzi nigdy nie trafia. Żądanie internetowe ma metodę — zwykle GET (tylko pobranie strony), ale czasem POST (wysłanie danych, na przykład formularza). 307 gwarantuje, że przeglądarka zachowa tę samą metodę, podążając za przekierowaniem. Starsze przeglądarki czasem zmieniały POST na GET przy 302, co mogło zepsuć wysłanie formularza. 307 usuwa to ryzyko na poziomie reguły protokołu.

W zdecydowanej większości przekierowań — gdy ktoś klika link do strony — nie robi to żadnej różnicy, bo w obu przypadkach jest to żądanie GET.

Czy 307 szkodzi SEO?

Nie. Własna dokumentacja Google mówi, że 307 jest „równoważny” 302. Oba są tymczasowe, więc żaden nie przekazuje rankingu starej strony na nową tak, jak robi to stałe przekierowanie (301). Nie ma tu ukrytej kary ani premii — 307 jest traktowany dokładnie jak 302.

„307”, który nie jest przekierowaniem

To część, która najbardziej wprowadza w błąd. Jeśli witryna wymusza HTTPS (funkcja bezpieczeństwa o nazwie HSTS), Twoja przeglądarka może pokazać „307” w narzędziach deweloperskich, gdy odwiedzasz wersję HTTP strony. Serwer nigdy tego nie wysłał — przeglądarka sama tworzy ten wpis, aby wyjaśnić, że od razu przeskoczyła na bezpieczną wersję. Pokazuje nawet odpowiedź o rozmiarze 0 bajtów, co jest wskazówką.

Jeśli więc narzędzie audytowe albo przeglądarka sygnalizuje niespodziewany 307, nie zakładaj od razu, że serwer jest źle skonfigurowany. Nowe okno incognito zwykle czyści zapamiętaną przez przeglądarkę pamięć HSTS i pokazuje prawdziwy kod stanu — ale nie zawsze: niektóre domeny są na wbudowanej liście preload HSTS przeglądarek, której incognito nie czyści. Checker przekierowań lub żądanie curl to bardziej niezawodny sposób sprawdzenia, co naprawdę zwraca serwer.

Chcesz poznać język specyfikacji, wypowiedzi Johna Muellera, pełną mechanikę HSTS i sposób faktycznego zwracania 307? Przejdź do karty Advanced.

TL;DR — 307 to tymczasowe przekierowanie, które zgodnie z RFC 9110 “MUST NOT change the request method” (tłumaczenie) „NIE MOŻE zmieniać metody żądania” — jedyna twarda gwarancja, której 302 nie zapewnia. Dla SEO nie ma znaczenia: dokumentacja Google wymienia je jako “Equivalent to 302” (tłumaczenie) „równoważne z 302” (słaby, tymczasowy sygnał), a Mueller powiedział, że wybór 307 kontra 302 “doesn’t really matter” (tłumaczenie) „właściwie nie ma znaczenia” dla wyszukiwania — chodzi o to, czy przekierowanie musi działać dla ruchu POST/API. 307, który naprawdę myli ludzi, to artefakt HSTS: przeglądarkowy „redirect” o rozmiarze 0 bajtów, którego serwer nigdy nie wysłał, powstały, gdy przeglądarka sama ulepsza HTTP do HTTPS. Istnieją dwa funkcjonalnie niepowiązane przypadki, a oddzielenie ich jest całym zadaniem.

307 ma dwa całkowicie różne przypadki

To porządkująca idea dla całego artykułu i wynika wprost z mojego poradnika o kodach stanu, w którym 307 ma dwa osobne wpisy: “307 Temporary Redirect – Has the same functionality as a 302 redirect, except you can’t switch between POST and GET” (tłumaczenie) „ma tę samą funkcję co 302, ale nie można przełączać POST i GET” oraz “307 HSTS Policy – Forces the client to use HTTPS when making requests instead of HTTP” (tłumaczenie) „wymusza używanie HTTPS zamiast HTTP podczas żądań”. Łączy je numer, a prawie nic poza nim:

1. 307 jako prawdziwe, wydane przez serwer przekierowanie tymczasowe — wybrane celowo (albo ustawione domyślnie przez framework), aby zachować metodę HTTP i ciało przy żądaniu innym niż GET.
2. 307 jako artefakt HSTS w przeglądarce — w ogóle nie jest odpowiedzią serwera. Przeglądarka wewnętrznie podnosi HTTP do HTTPS i oznacza to podniesienie jako 307.

Mieszanie tych dwóch przypadków jest najczęstszym źródłem nieporozumień dotyczących 307. Omówię je po kolei.

Przypadek 1: prawdziwy 307 — czego wymaga specyfikacja

RFC 9110 (bieżąca specyfikacja semantyki HTTP) jest jednoznaczne w §15.4.8:

“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.” (tłumaczenie) „Kod stanu 307 (Temporary Redirect) oznacza, że zasób docelowy znajduje się tymczasowo pod innym URI, a klient użytkownika NIE MOŻE zmienić metody żądania, jeśli automatycznie przekierowuje do tego URI.”

To „MUST NOT” jest twardym wymogiem, a nie sugestią. Porównaj je z sekcją 302 (§15.4.3), która otwarcie dokumentuje historyczny bałagan, do którego naprawy powstał 307: “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.” (tłumaczenie) „Z powodów historycznych klient użytkownika MOŻE zmienić metodę POST na GET przy kolejnym żądaniu. Jeśli takie zachowanie jest niepożądane, można użyć kodu 307.” Innymi słowy, 307 istnieje konkretnie po to, by usunąć niejednoznaczność POST→GET, która występowała w starszych klientach przy 302.

MDN podaje praktyczną wersję tego samego rozróżnienia:

“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.” (tłumaczenie) „Różnica między 307 i 302 polega na tym, że 307 gwarantuje zachowanie metody i ciała żądania przy przekierowaniu. Starsze klienty przy 302 nieprawidłowo zmieniały metodę na GET. Odpowiedzi 307 i 302 są identyczne, gdy metoda żądania to GET.”

To ostatnie zdanie ma największe znaczenie dla SEO. Prawie każde przekierowanie interesujące specjalistę SEO — stara strona do nowej — jest żądaniem GET, a przy GET 307 i 302 są dosłownie identyczne. Gwarancja zachowania metody ma znaczenie tylko wtedy, gdy metoda nie jest GET: przy ponownym wysyłaniu formularzy, endpointach API, celach webhooków i przekazywaniu POST-u w checkoutach lub uwierzytelnianiu. Specyfikacja gwarantuje metodę i ciało — sama w sobie nie ustala dokładnej obsługi nagłówków, danych uwierzytelniających ani żądań cross-origin przy ponownym odtworzeniu, więc sprawdź to z rzeczywistym klientem zamiast zakładać zachowanie bajt w bajt. Jeśli porównujesz oba kody przy zwykłym przeniesieniu strony, temat szczegółowo omawia osobny artykuł o 302 kontra 307 — ten zakłada znajomość podstaw tymczasowego przekierowania z pogłębienia o 302 i skupia się na tym, co w 307 wyjątkowe.

302 a 303 a 307 w jednej tabeli

Wszystkie trzy należą w RFC do kategorii „tymczasowe”, ale nie zachowują się tak samo na dwóch osiach, które naprawdę mają znaczenie — zachowaniu metody i cache:

Żaden z tych trzech kodów nie jest domyślnie heurystycznie zapisywany w cache — 307 (podobnie jak 302 i 303) potrzebuje jawnego sygnału świeżości (Cache-Control, Expires itd.), zanim cache zapisze go bez ponownego pytania.

Przypadek 1, ciąg dalszy: jak Google traktuje prawdziwy 307 w SEO

Krótka odpowiedź: dokładnie jak 302. Dokumentacja Google Kody stanu HTTP wymienia wiersz 307 jako “Equivalent to 302” (tłumaczenie) „jest równoważny z kodem 302”, a odziedziczony wiersz 302 wyjaśnia, co to oznacza:

““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.”” (tłumaczenie) „Domyślnie crawlery Google podążają za przekierowaniem, a systemy Google używają przekierowania jako słabego sygnału, że cel powinien zostać przetworzony.”

„Słaby” to słowo kluczowe — tymczasowe przekierowanie nie konsoliduje kanonizacji na celu tak jak stałe. Dokument Google Przekierowania i wyszukiwarka Google grupuje 302, 303 i 307 jako “temporary” (tłumaczenie) „tymczasowe” i opisuje zachowanie wprost: “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (tłumaczenie) „Googlebot podąża za przekierowaniem, ale potok indeksowania nie używa go jako sygnału, że cel powinien być kanoniczny.” Na tej samej stronie, w tym samym ujęciu intencji: “If you just want to send users to a different page temporarily, use a temporary redirect.” (tłumaczenie) „Jeśli chcesz tylko tymczasowo wysłać użytkowników na inną stronę, użyj tymczasowego przekierowania.”

Zaraz po wierszach 307 i 308 Google dodaje zastrzeżenie warte wytatuowania na ścianie:

“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.” (tłumaczenie) „Choć Google traktuje te kody stanu tak samo, pamiętaj, że różnią się semantycznie. Użyj kodu odpowiedniego dla przekierowania, aby inne klienty, np. czytniki e-booków i inne wyszukiwarki, również mogły na tym skorzystać.”

Google grupuje więc 307 i 302 razem dla rankingu, ale nadal mówi, aby wybrać kod poprawny semantycznie. To cała odpowiedź SEO. 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 ujął to jeszcze dosadniej w 51. odcinku podcastu „Porozmawiajmy o przekierowaniach”, wyjaśniając, że “with 307, 308, it also forwards POST requests” (tłumaczenie) „307 i 308 również przekazują żądania POST” — w przeciwieństwie do 301/302, które przekazują żądania GET — po czym przechodzi do sedna:

“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.” (tłumaczenie) „W ujęciu SEO nie ma to właściwie znaczenia. Pytanie brzmi raczej, czy działa dla API; API zwykle nie trzeba bezpośrednio indeksować w Search.”

Nie ma rankingowej korzyści ze zmiany tymczasowych przekierowań na 307. Jedynym prawidłowym powodem wyboru tego kodu jest zachowanie metody i ciała — albo, jako ogólna preferencja przyszłościowa, którą omówię na końcu.

Przypadek 1, ciąg dalszy: domyślne ustawienia frameworków i CDN-ów

Coraz więcej pytań „dlaczego to jest 307?” nie dotyczy w ogóle celowych decyzji — to domyślne ustawienia frameworków. Funkcja redirect() Next.js domyślnie zwraca 307, a dokumentacja wprost wyjaśnia dlaczego, pod nagłówkiem “Why does redirect use 307 and 308?” (tłumaczenie) „Dlaczego funkcja redirect używa 307 i 308?”: “The redirect() method uses a 307 by default, instead of a 302 temporary redirect, meaning your requests will always be preserved as POST requests.” (tłumaczenie) „Metoda redirect() domyślnie używa 307 zamiast tymczasowego 302, więc żądania zawsze zachowują się jako POST.” (Next.js używa 303 konkretnie w Server Actions i ma osobne permanentRedirect() dla przypadku 308.) Jeśli widzisz 307, którego nie napisałeś ręcznie, sprawdź, czy framework lub platforma brzegowa domyślnie nie używa go przy przekierowaniach innych niż GET — zwykle to właśnie odpowiedź i zwykle poprawna.

Przypadek 2: „widmowy 307” HSTS, którego serwer nigdy nie wysłał

To obszar rzeczywiście niedostatecznie omawiany i powód, dla którego osobny artykuł o 307 ma sens. Gdy witryna wysyła nagłówek Strict-Transport-Security (HSTS), mówi przeglądarce: od teraz ładuj mnie wyłącznie przez HTTPS. Przy następnym żądaniu wersji HTTP przeglądarka sama przechodzi na HTTPS, bez rozmowy z serwerem — i pokazuje to wewnętrzne podniesienie jako „307” w narzędziach deweloperskich i crawlerach.

John Mueller wyjaśnił ten mechanizm na swojej prywatnej stronie:

“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.” (tłumaczenie) „Po zobaczeniu adresu HTTPS z nagłówkiem HSTS Chrome zachowa się tak, jakby przy następnym dostępie do strony HTTP widział przekierowanie 307. Serwer nie zwraca 307; Chrome tylko pokazuje to w ten sposób, aby wyjaśnić, że samo wykonuje przekierowanie.”

Ciało o rozmiarze 0 bajtów jest wskazówką — jak dodaje Mueller, “the 307 isn’t actually a redirect at all, it’s just a placeholder” (tłumaczenie) „307 wcale nie jest przekierowaniem, tylko symbolem zastępczym”. Mój poradnik o przekierowaniach ujmuje praktyczną konsekwencję dla audytu tak: “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.” (tłumaczenie) „Gdy serwery wymagają wyłącznie HTTPS, Google nie zobaczy 307, bo jest on zapisany w przeglądarce; pierwsze żądanie bez cache prawdopodobnie otrzyma 301 lub 302, ale kolejne przeglądarka pokaże jako 307, co utrudnia diagnozę. Trzeba użyć nowej sesji incognito, aby zobaczyć zwrócony kod.”

Co Googlebot naprawdę widzi przy HSTS i jak zmieniała się historia

Warto przeczytać razem dwie wypowiedzi Google oddalone o pięć lat. W grudniu 2015 r. Zineb Ait Bahajji (wówczas w Google) powiedziała, według Search Engine Roundtable: “With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’.” (tłumaczenie) „Przy wdrożonym HSTS Googlebot widzi przekierowanie 301 (sprawdź w Fetch as Google). 307 jest tylko „wewnętrznym przekierowaniem”.” W październiku 2020 r. ujęcie Muellera w filmie Ask Google Webmasters (przez Search Engine Journal) było nieco inne: “In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects.” (tłumaczenie) „W skrócie Googlebot nie wchodzi z nimi w interakcję; te przekierowania 307 zasadniczo nie są prawdziwymi przekierowaniami.” Tak czy inaczej crawler nie widzi tego samego „307”, który człowiek widzi w narzędziach deweloperskich — zmieniły się narzędzia i infrastruktura crawlowania (Fetch as Google wycofano na rzecz URL Inspection), ale podstawowy punkt utrzymywał się co najmniej przez dekadę: w przypadku HSTS nie ma prawdziwego 307 wydanego przez serwer. Traktuj wypowiedź z 2020 r. jako bieżące wytyczne, a tę z 2015 r. jako historię.

Najważniejszy wniosek operacyjny: HSTS to wygoda przeglądarki, a nie mechanizm odkrywania adresów przez crawlery. Właściciele witryn nadal potrzebują prawdziwego przekierowania po stronie serwera (autentycznego 301) z HTTP do HTTPS, jeśli ta ścieżka ma działać dla crawlerów.

Jak Bing traktuje 307

Szczerze? Istnieje luka w dokumentacji. Nie znalazłem publicznej wypowiedzi Binga, która odnosiłaby się z nazwy do 307 albo konkretnie do 307 wywołanego przez HSTS. Wytyczne Binga dotyczące przekierowań (wpis z 2011 r. Zarządzanie przekierowaniami — 301, 302 i kanoniczne adresy URL oraz wpis z 2020 r. Migracja witryny z Bingiem) obejmują tylko podział 301/302 na stały i tymczasowy — bez wzmianki o 307, 308 czy HSTS. Zamiast zakładać zgodność z Google, ujmij to wprost: Bing publicznie nie powiedział nic specyficznego o 307. Zjawisko nadal jest prawdziwe i istotne dla crawlerów niezależnie od wyszukiwarki — Screaming Frog ma przełącznik „Respect HSTS Policy” właśnie dlatego, że HSTS wpływa na crawlowanie — ale to dokumentacja narzędzia, a nie wypowiedź Binga.

Kiedy celowo wybrać 307

Wybierz 307 zamiast 302 zawsze, gdy utrata oryginalnej metody lub ciała zepsułaby działanie:

• Endpointy API i cele webhooków, które odbierają POST/PUT/PATCH.
• Przepływy wysyłania formularzy (POST), które przekierowują po przetworzeniu.
• Przekazania POST-u w checkoutach lub logowaniu między hostami.
• Wszystko, gdzie żądanie niesie ciało, którego nie możesz utracić.

Przy zwykłym przeniesieniu strona–strona 302 i 307 są dla Google nie do odróżnienia, więc pod kątem SEO oba są poprawne. Jeśli zajmujesz się stałą wersją tej samej logiki zachowywania metody, chodzi o relację 301 kontra 308 — 308 ma się do 301 tak, jak 307 do 302.

Moja własna preferencja, opisana w poradniku o przekierowaniach, jest bardziej zdecydowana niż zwykłe „to nie ma znaczenia”: “my preferred order would be: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0.” (tłumaczenie) „moja preferowana kolejność to: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0.” Stawiam 307 na pierwszym miejscu wśród opcji tymczasowych — konsekwentne używanie go daje bezpieczeństwo w kwestii zachowania metody, co z grubsza odpowiada argumentowi o „kompletności” Muellera. Niezależnie od wyboru pilnuj, aby prawdziwy 307 (albo artefakt HSTS) nie stał się jednym z przeskoków w dłuższym łańcuchu przekierowań — każdy dodatkowy przeskok to opóźnienie i utracona efektywność.

Podsumowanie AI

Skrót wersji Advanced:

• 307 ma dwa niepowiązane przypadki. (1) Prawdziwe, wydane przez serwer przekierowanie tymczasowe, które zachowuje metodę i ciało HTTP; (2) artefakt HSTS w przeglądarce — „307” o rozmiarze 0 bajtów, którego serwer nigdy nie wysłał, powstały, gdy przeglądarka sama ulepsza HTTP do HTTPS. Oddzielenie ich jest całym zadaniem.
• Przypadek 1 — gwarancja specyfikacji: RFC 9110 mówi, że “MUST NOT change the request method.” (tłumaczenie) „NIE MOŻE zmieniać metody żądania.” MDN dodaje, że “307 and 302 responses are identical when the request method is GET” (tłumaczenie) „odpowiedzi 307 i 302 są identyczne, gdy metoda to GET” — liczy się to tylko przy POST/PUT/PATCH (formularzach i API). Gwarancja obejmuje metodę i ciało; obsługa nagłówków, danych uwierzytelniających i cross-origin przy odtworzeniu nadal zależy od klienta.
• 302 a 303 a 307: 302 może historycznie zmienić POST na GET, 303 celowo pobiera cel przez GET/HEAD, a 307 nie może zmienić metody — i żaden z tych kodów nie jest domyślnie heurystycznie zapisywany w cache.
• Odpowiedź SEO: dokumentacja Google wymienia 307 jako “Equivalent to 302” (tłumaczenie) „jest równoważny z kodem 302” — słaby, tymczasowy sygnał, który nie konsoliduje sygnałów na celu. Mueller: dla SEO “it doesn’t really matter” (tłumaczenie) „właściwie nie ma to znaczenia”; prawdziwe pytanie brzmi: “does it work for APIs” (tłumaczenie) „czy działa dla API?”.
• Domyślne ustawienia frameworków: redirect() Next.js domyślnie zwraca 307 (303 w Server Actions, permanentRedirect() dla 308), aby zachować POST — to częste źródło “accidental” (tłumaczenie) „przypadkowych” 307 i zwykle poprawne zachowanie.
• Przypadek 2 — HSTS: przeglądarka pokazuje 307 z ciałem 0 bajtów; rzeczywisty kod serwera zwykle jest 301/302. Googlebot nie widzi tego 307 (Mueller 2020: “doesn’t interact with them” (tłumaczenie) „nie wchodzi z nimi w interakcję”; Zineb 2015: “sees a 301” (tłumaczenie) „widzi 301”). Nadal potrzebujesz prawdziwego 301 po stronie serwera dla HTTP→HTTPS. Sprawdzaj checkerem przekierowań lub zwykłym curl — świeże incognito zwykle działa, ale nie dla domen na wbudowanej liście preload HSTS przeglądarki.
• Bing: brak publicznej wypowiedzi specyficznej dla 307 — to luka w dokumentacji, a nie dowód zgodności.
• Preferencja: nie ma rankingowego powodu, aby przechodzić na 307; własna kolejność Patricka umieszcza 307 na pierwszym miejscu opcji tymczasowych ze względu na przyszłościowe zachowanie.

Oficjalna dokumentacja

Dokumentacja pierwotna i specyfikacje.

Google

• Kody stanu HTTP, błędy sieci i DNS oraz wyszukiwarka Google — wiersz “307 (temporary redirect) — Equivalent to 302” (tłumaczenie) „307 (tymczasowe przekierowanie) — równoważne z 302”, język o „słabym sygnale” 302 i zastrzeżenie o różnicy semantycznej.
• Przekierowania i wyszukiwarka Google — grupuje 302/303/307 jako “temporary” (tłumaczenie) „tymczasowe”; „potok indeksowania nie używa przekierowania jako sygnału, że cel powinien być kanoniczny”.

Bing / Microsoft

• Zarządzanie przekierowaniami — 301, 302 i kanoniczne adresy URL — wytyczne Binga dotyczące przekierowań (tylko 301/302, bez wzmianki o 307/HSTS).
• Migracja witryny z Bingiem — wytyczne migracji, ponownie tylko 301/302.

Specyfikacja HTTP

• RFC 9110 §15.4.8 — 307 tymczasowe przekierowanie — “MUST NOT change the request method” (tłumaczenie) „NIE MOŻE zmieniać metody żądania”.
• RFC 9110 §15.4.3 — 302 Found — historyczna uwaga o POST→GET, która odsyła do 307.

Materiały techniczne

• MDN — 307 tymczasowe przekierowanie — zachowanie metody i ciała; “identical when the request method is GET” (tłumaczenie) „identyczne, gdy metoda żądania to GET”.

Framework

• Next.js — dokumentacja funkcji redirect() — FAQ “Why does redirect use 307 and 308?” (tłumaczenie) „Dlaczego funkcja redirect używa 307 i 308?”; domyślnie 307 (303 w Server Actions).

Narzędzia crawlerów

• Screaming Frog — przewodnik SEO po crawlowaniu HSTS i przekierowaniach 307 — konfiguracja “Respect HSTS Policy” (tłumaczenie) „respektuj politykę HSTS” i mechanika HSTS.

Cytaty ze źródła

Wypowiedzi zapisane wprost. Każdy link prowadzi do cytowanego fragmentu albo go dokumentuje.

Dokumentacja Google — ujęcie SEO

• “307 (temporary redirect) — Equivalent to 302.” (tłumaczenie) „307 (tymczasowe przekierowanie) — jest równoważny z kodem 302.” — Google Search Central, Kody stanu HTTP, błędy sieci i DNS oraz wyszukiwarka Google. Przejdź do cytatu
• ““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.”” (tłumaczenie) „Domyślnie crawlery Google podążają za przekierowaniem, a systemy Google używają go jako słabego sygnału, że cel powinien zostać przetworzony.” (wiersz 302, który dziedziczy 307) Przejdź do cytatu
• “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.” (tłumaczenie) „Choć Google traktuje te kody tak samo, pamiętaj, że różnią się semantycznie. Użyj właściwego kodu, aby inne klienty, np. czytniki e-booków i inne wyszukiwarki, mogły na tym skorzystać.” Przejdź do cytatu
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (tłumaczenie) „Googlebot podąża za przekierowaniem, ale potok indeksowania nie używa go jako sygnału, że cel powinien być kanoniczny.” — Google Search Central, Przekierowania i wyszukiwarka Google. Przejdź do cytatu

Specyfikacja HTTP / MDN — gwarancja techniczna

• “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.” (tłumaczenie) „Kod 307 oznacza, że zasób docelowy znajduje się tymczasowo pod innym URI, a klient użytkownika nie może zmienić metody przy automatycznym przekierowaniu.” — RFC 9110, §15.4.8. Przeczytaj sekcję
• “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.” (tłumaczenie) „Z powodów historycznych klient może zmienić POST na GET przy kolejnym żądaniu. Jeśli to niepożądane, użyj 307.” — RFC 9110, §15.4.3 (sekcja 302). Przeczytaj sekcję
• “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.” (tłumaczenie) „307 gwarantuje zachowanie metody i ciała, a odpowiedzi 307 i 302 są identyczne, gdy metoda to GET.” — MDN, 307 Temporary Redirect. Przejdź do cytatu

John Mueller, Google — SEO i zachowanie metody

• “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.” (tłumaczenie) „Myślę, że dla SEO nie ma to właściwie znaczenia. Chodzi raczej o to, czy działa dla API, a API zwykle nie trzeba bezpośrednio indeksować w Search.” — podcast „Porozmawiajmy o przekierowaniach”, odc. 51, “Let’s talk redirects” (tłumaczenie) „Porozmawiajmy o przekierowaniach” (17 listopada 2022 r.). PDF transkrypcji
• “And with 307, 308, it also forwards POST requests” (tłumaczenie) „przy 307 i 308 przekazuje również żądania POST” (w przeciwieństwie do 301/302, które przekazują GET). — ten sam odcinek.

John Mueller, Google — „widmowy 307” HSTS

• “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.” (tłumaczenie) „Serwer nie zwraca 307; Chrome tylko tak go pokazuje, aby wyjaśnić, że samo wykonuje przekierowanie… 307 wcale nie jest przekierowaniem, tylko symbolem zastępczym.” — John Mueller, HTTPS & HSTS: 301, 302, or 307? (johnmu.com, pierwotnie Google+, czerwiec 2016 r.). Przejdź do cytatu
• “In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects.” (tłumaczenie) „Według Muellera Googlebot nie wchodzi z nimi w interakcję; te przekierowania zasadniczo nie są prawdziwymi przekierowaniami.” — John Mueller, Ask Google Webmasters (październik 2020 r.), przez Search Engine Journal. Przejdź do cytatu

Zineb Ait Bahajji, Google — HSTS, 2015 (przekazane dalej)

• “With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’.” (tłumaczenie) „Z perspektywy Googlebotu HSTS oznacza widoczny kod 301, a 307 jest jedynie przekierowaniem wewnętrznym.” — Zineb Ait Bahajji (Google), przez Twitter, cytowane przez Search Engine Roundtable (grudzień 2015 r.). Przejdź do cytatu

Na który 307 właściwie patrzę?

Prawie każde pytanie o 307 sprowadza się do jednej z dwóch całkowicie różnych rzeczy. Przejdźmy przez to.

Mity i błędy, których należy unikać

„307 nie przekazuje wartości linków tak jak 302”. Fałszywe w ujęciu „307 jest gorszy niż 302” — a to twierdzenie aktywnie krąży na dużych blogach SEO. Własna dokumentacja Google traktuje 307 i 302 tak samo: oba są tymczasowymi, „słabymi sygnałami” bez kanonizacji celu, a dokument HTTP Status Codes wprost nazywa 307 „Equivalent to 302”. Nie ma udokumentowanej podstawy, aby twierdzić, że 307 przekazuje mniej niż 302. Ujęcie Google jest takie, że tymczasowe przekierowania ogólnie nie mają konsolidować sygnałów rankingowych na celu tak jak stałe — nie pozwól więc, aby twierdzenie o tym, że „konkretnie 307 wstrzymuje wartość”, pchnęło Cię do niepotrzebnych zmian.

„307 w karcie Network oznacza źle skonfigurowane przekierowanie serwera”. Często fałsz. Jeśli HSTS jest włączone, a przeglądarka wcześniej zobaczyła nagłówek Strict-Transport-Security, pokazuje podniesienie HTTP→HTTPS jako 307 wyłącznie dla własnego wyjaśnienia — serwer nigdy go nie zwrócił (wskazówką jest ciało 0 bajtów). Nowa sesja incognito zwykle pokazuje prawdziwy kod, ale nie dla domen z wbudowanej listy preload HSTS przeglądarki — dla nich użyj checkera przekierowań albo curl (bez konfiguracji HSTS), zanim zaczniesz szukać nieistniejącej błędnej konfiguracji.

„Googlebot widzi ten sam 307, który pokazuje mi przeglądarka przy witrynie HSTS”. Niezupełnie. Przedstawiciele Google mówili, że Googlebot albo widzi 301 (Zineb, 2015), albo w ogóle nie wchodzi w mechanizm 307/HSTS (Mueller, 2020). Tak czy inaczej nie jest to „307” widoczne dla człowieka. Nadal potrzebujesz prawdziwego 301 po stronie serwera z HTTP do HTTPS, jeśli odkrywanie tej ścieżki przez crawlery ma znaczenie.

„303 i 307 są praktycznie wymienne”. Są przeciwieństwami na jednej osi, która ma znaczenie. 303 zawsze zmienia metodę na GET (wzorzec Post/Redirect/Get), a 307 gwarantuje, że metoda się nie zmieni. Łatwo je pomylić tylko dlatego, że oba należą do „tymczasowej” kategorii obok 302.

„Zmień wszystkie tymczasowe przekierowania na 307, aby poprawić rankingi”. Nie ma takiej premii. Jedynym poprawnym powodem preferowania 307 nad 302 jest rzeczywiste zachowanie metody i ciała (albo ogólne zabezpieczenie na przyszłość). Przerabianie każdego 302 na 307 nic nie daje i może wprowadzić błędy.

„302 zawsze zmienia POST na GET, więc 302 jest zasadniczo zepsuty dla formularzy”. To przesada. Zmiana POST→GET była realnym problemem starszych, niespójnych klientów — właśnie dlatego 307 istnieje jako opcja gwarantowana — ale współczesne przeglądarki są znacznie bardziej spójne. 307 usuwa niejednoznaczność przez specyfikację zamiast polegać na bieżącym zachowaniu klienta; nie oznacza to, że 302 jest „zepsuty”.

Zobacz prawdziwy kod stanu (nie artefakt HSTS)

Gdy HSTS jest zapisane w cache, przeglądarka ukrywa prawdziwe 301/302 za widmowym 307. curl domyślnie nie stosuje HSTS, więc zwykłe wywołanie rozmawia bezpośrednio z serwerem i pokazuje prawdę — tylko nie uruchamiaj go z skonfigurowanym plikiem cache --hsts, bo przywrócisz tę samą zmianę po stronie klienta, którą próbujesz wykluczyć.

Prześledź cały łańcuch przekierowań, tylko nagłówki

# -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.

Sprawdź kod stanu jednego adresu URL bez podążania dalej

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

Konsola Chrome DevTools — wykryj widmowy 307

Wklej do karty Console. Prawdziwe przekierowanie serwera ujawnia flagę redirected i rozwiązany adres URL; podniesienie HSTS następuje, zanim żądanie w ogóle opuści przeglądarkę.

// 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));

Możesz też odczytać rekord HSTS Chrome bezpośrednio pod chrome://net-internals/#hsts — wyszukaj domenę, aby sprawdzić, czy static_upgrade_mode/dynamic_upgrade_mode wymusza HTTPS (to właśnie tworzy 307 widoczny w karcie Network).

Bookmarklet — szybki podgląd nagłówków bieżącej karty

Przeciągnij zakładkę z tym adresem URL, a następnie kliknij ją na dowolnej stronie, aby zapisać w konsoli bieżący status adresu URL i stan przekierowania:

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);});})();

Uwaga: fetch() w przeglądarce nie może odczytać ciał nieprzezroczystych przekierowań cross-origin, więc przy autorytatywnym śledzeniu wielu przeskoków źródłem prawdy jest powyższe curl -sIL.

Zwracanie prawdziwego 307

Celem zwracania 307 (zamiast pozostawienia tego frameworkowi jako ustawienia domyślnego) jest zagwarantowanie, że metoda i ciało przetrwają. Oto kilka typowych sposobów jawnej konfiguracji.

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 jest domyślne, więc często w ogóle nie piszesz tego kodu:

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");
}

Jak wygląda surowa odpowiedź 307

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

Jak wygląda „widmowy 307” HSTS (tylko w przeglądarce)

Ta sama linia statusu w narzędziach deweloperskich, ale zwróć uwagę na wskazówki — odpowiedź pochodzi z przeglądarki, a nie z serwera, i ma ciało o rozmiarze 0 bajtów:

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

Jeśli widzisz Non-Authoritative-Reason: HSTS (Chrome) albo „307” o rozmiarze 0 bajtów, które znika przy teście klientem niestosującym HSTS, to artefakt — nie przekierowanie wysłane przez serwer. Dokładna nazwa nagłówka i etykieta DevTools są szczegółami implementacji Chrome, a nie gwarancją specyfikacji HTTP lub HSTS, więc traktuj je ilustracyjnie, a nie jako podstawę automatyzacji między przeglądarkami i wersjami.

Metoda, czas trwania i framework źródłowy

Przed zmianą oceniam 307 na trzech osiach:

1. Metoda: czy cel musi otrzymać oryginalną metodę i ciało żądania? Jeśli tak, 307 jest tymczasowym przekierowaniem zachowującym oba. Zwykły GET między stronami zazwyczaj nie potrzebuje tej właściwości.
2. Czas trwania: czy przeniesienie jest rzeczywiście tymczasowe? Zachowuj 307 tylko dopóty, dopóki oryginalny adres URL ma wrócić. Stałe przeniesienie wymaga decyzji o stałym przekierowaniu, a nie bezterminowo tymczasowego statusu.
3. Źródło: czy 307 wysłał serwer, wybrał go framework, czy przeglądarka zsyntetyzowała wewnętrzne podniesienie HSTS? „Internal Redirect” w DevTools nie jest regułą źródłową do przepisania.

Narzędzia do oddzielania prawdziwych i widmowych 307

• Redirect Checker: zobacz status obserwowalny przez serwer, cel i każdy przeskok bez polegania na stanie HSTS jednej przeglądarki.
• Redirect Chain Mapper: użyj widoku każdego przeskoku, gdy 307 jest częścią dłuższej ścieżki przekierowania.
• HTTP Header Checker: sprawdź Location i Strict-Transport-Security oraz porównaj wskazówki z brzegu i źródła.
• curl: uruchom curl -I http://example.com/path poza przeglądarkowym wyświetlaniem HSTS. Zachowanie POST testuj wyłącznie wobec kontrolowanego, bezpiecznego endpointu.
• DevTools przeglądarki: sprawdź, czy wpis mówi „Internal Redirect” i ma transfer o rozmiarze 0 bajtów, co wskazuje na podniesienie HSTS wygenerowane przez przeglądarkę.

Sprawdź 307 po wdrożeniu

Test statusu i celu

Test do wykonania: sprawdź źródło za pomocą Redirect Checker albo curl -I. Oczekiwany wynik: jeden 307 z zamierzonym Location. Interpretacja niepowodzenia: inna warstwa zmieniła regułę lub cel. Okno monitorowania: natychmiast. Warunek wycofania: pętla, zepsuty cel albo niezamierzona nazwa hosta.

Test zachowania metody

Test do wykonania: wyślij nieszkodliwy POST do kontrolowanej trasy testowej i sprawdź, co otrzymuje cel. Oczekiwany wynik: cel otrzymuje POST z oryginalnym ciałem. Interpretacja niepowodzenia: pośrednik zmienił metodę albo podał inny kod. Okno monitorowania: natychmiast. Warunek wycofania: formularz, webhook lub żądanie checkoutu traci metodę albo ciało.

Test oddzielenia HSTS

Test do wykonania: porównaj DevTools (albo nową sesję incognito) z żądaniem curl -I bez skonfigurowanego cache HSTS. Oczekiwany wynik: „Internal Redirect” w przeglądarce można odróżnić od prawdziwej odpowiedzi serwera, a HTTP nadal ma przekierowanie po stronie serwera. Interpretacja niepowodzenia: HSTS maskuje brak reguły źródłowej — pamiętaj, że samo incognito nie wystarcza dla domen na wbudowanej liście preload HSTS przeglądarki, bo ten stan trwa niezależnie od historii przeglądania. Okno monitorowania: natychmiast. Warunek wycofania: zmiana źródła usuwa działające przekierowanie HTTP→HTTPS.

Sprawdź się: 307 Temporary Redirect

Pięć krótkich pytań o to, czym jest 307, jak traktuje go Google i czym jest artefakt HSTS. Wybierz odpowiedź na każde, a następnie sprawdź wynik.

Zasoby warte Twojego czasu

Moje powiązane teksty

• 11 typów przekierowań i ich wpływ na SEO — źródło definicji 307, zastrzeżenia HSTS i mojej kolejności preferencji (307 / 302 / 303 na początku).
• Kody stanu HTTP i ich wpływ na SEO — tekst z dwoma odrębnymi wpisami o 307: przypadkiem przekierowania tymczasowego i przypadkiem polityki HSTS.
• Podstawowy przewodnik po technicznym SEO — miejsce przekierowań w szerszym obrazie.

Moje wystąpienia

• Jak działa wyszukiwanie (SlideShare) — moje omówienie crawlowania, renderowania, indeksowania i rankingu, w tym obsługi przekierowań. (Obowiązuje moje stałe zastrzeżenie: “This is my understanding of systems… not going to be 100% complete or accurate.” (tłumaczenie) „To moje rozumienie systemów… nie będzie w 100% kompletne ani dokładne.”)

Z branży

• John Mueller — HTTPS i HSTS: 301, 302 czy 307? — najjaśniejsze wyjaśnienie HSTS „widmowego 307” z pierwszej ręki (“your server’s not returning a 307” (tłumaczenie) „serwer nie zwraca 307”).
• Podcast o przekierowaniach, odc. 51 — „Porozmawiajmy o przekierowaniach” (PDF transkrypcji) — Mueller i Splitt o tym, dlaczego istnieją 307/308 i dlaczego “for SEO, it doesn’t really matter” (tłumaczenie) „dla SEO właściwie nie ma to znaczenia”.
• Google o przekierowaniach 307/HSTS (Search Engine Journal) — podsumowanie filmu Muellera o tym, że “307 redirects are generally not real redirects” (tłumaczenie) „przekierowania 307 zasadniczo nie są prawdziwymi przekierowaniami”.
• Googlebot traktuje przekierowania 307 jak 301? (Search Engine Roundtable) — wypowiedź Zineb Ait Bahajji z 2015 r. o tym, co Googlebot widzi przy HSTS.
• MDN — 307 tymczasowe przekierowanie — standardowe źródło techniczne gwarancji metody i ciała.
• Przewodnik SEO po crawlowaniu HSTS i przekierowaniach 307 (Screaming Frog) — najlepsze omówienie konfiguracji crawlera przy 307 wywołanym przez HSTS.
• Next.js — dokumentacja redirect() — wyjaśnia, dlaczego popularny framework domyślnie używa 307 dla przekierowań innych niż GET.

Dziennik zmian