Przekierowanie 301 czy 302? Kody 3xx, Google i cache

Przekierowanie 301 to odpowiedź serwera „ten adres przeniesiono na stałe”: zamiast strony serwer odsyła nowy adres, a przeglądarka sama pod niego przechodzi. Na tym podobieństwo do innych przekierowań się kończy. Przeglądarka może odpowiedź 301 zapamiętać i przy kolejnym wejściu w ogóle nie zapytać serwera, a Google traktuje ją jako sygnał, że nowy adres ma zastąpić stary w wynikach wyszukiwania. Dlatego 301 dajesz tylko temu, czego nie zamierzasz cofać. Poniżej porównujemy kody 301, 302, 303, 307 i 308 na podstawie specyfikacji HTTP i dokumentacji Google, pokazujemy własny pomiar tego, kiedy Chromium i Firefox zapamiętują przekierowanie, prawdziwy łańcuch przekierowań na naszej domenie i gotowe reguły dla Apache, nginx i Next.js.

Przekierowanie 301 — co to jest i jak działa

Przekierowanie to odpowiedź z kodem z grupy 3xx i nagłówkiem Location, w którym serwer podaje nowy adres. Przeglądarka nie pokazuje takiej odpowiedzi — od razu wysyła drugie zapytanie pod adres z nagłówka. Dla użytkownika wygląda to tak, jakby od początku wpisał nowy adres, najwyżej z ułamkiem sekundy opóźnienia.

Specyfikacja HTTP opisuje 301 Moved Permanently tak: zasobowi przypisano „a new permanent URI”, a wszystkie przyszłe odwołania „ought to use one of the enclosed URIs” (RFC 9110, §15.4.2). Słowo „permanent” niesie dwie konsekwencje, które opisujemy niżej: odpowiedź 301 jest według tej samej specyfikacji „heuristically cacheable”, czyli przeglądarka może ją przechowywać, nawet gdy serwer nie podał żadnych instrukcji, a wyszukiwarka może przenieść stary adres w wynikach na nowy.

Jeśli trafiłeś tu z Google Search Console, gdzie raport Indeksowanie stron pokazuje pozycję „Strona zawiera przekierowanie”, to nie jest błąd. Search Console wyjaśnia, że to adres niekanoniczny, który przekierowuje na inną stronę, więc sam nie trafi do indeksu, a adres docelowy jest oceniany osobno (Search Console, raport Indeksowanie stron). Po migracji serwisu ta lista powinna rosnąć — to stare adresy, które poprawnie odsyłają na nowe. Błędem jest dopiero „błąd przekierowania”: za długi łańcuch albo pętla, o czym niżej.

301, 302, 303, 307, 308 — czym się różnią

Pięć kodów przekierowań różni się na dwóch osiach: czy przeniesienie jest trwałe i czy przeglądarka może przy okazji zmienić metodę zapytania. Druga oś ma znaczenie przy formularzach i API, gdzie zapytanie POST niesie dane.

Historia jest pogmatwana. Kody 301 i 302 miały zachowywać metodę, ale przeglądarki w praktyce zamieniały POST na GET. Specyfikacja to przyznaje: przeważająca praktyka „eventually converged on changing the method to GET”, więc później dodano 307 i 308, żeby jednoznacznie oznaczyć przekierowania zachowujące metodę, a 301 i 302 dostosowano tak, żeby zmiana POST na GET była dozwolona (RFC 9110, §15.4). Stąd zapis przy 301: „For historical reasons, a user agent MAY change the request method from POST to GET”, a jeśli to niepożądane, można użyć 308 (RFC 9110, §15.4.2).

W skrócie:

• 301 Moved Permanently — trwałe; metoda może się zmienić na GET; przeglądarka może zapamiętać odpowiedź.
• 302 Found — tymczasowe; zasób „resides temporarily under a different URI” i klient powinien dalej używać pierwotnego adresu (RFC 9110, §15.4.3).
• 303 See Other — po wysłaniu formularza: służy do tego, żeby wynik akcji POST pokazać pod innym adresem (RFC 9110, §15.4.4). MDN dodaje praktyczny powód: odświeżenie strony wyniku nie wyśle formularza drugi raz (MDN, Redirections).
• 307 Temporary Redirect — tymczasowe jak 302, ale przeglądarka „MUST NOT change the request method” (RFC 9110, §15.4.8).
• 308 Permanent Redirect — trwałe jak 301, bez zmiany metody; też „heuristically cacheable” (RFC 9110, §15.4.9).

Przy zwykłym kliknięciu w link metoda zawsze jest GET, więc 307 zachowuje się wtedy jak 302, a 308 jak 301. Różnica wychodzi przy formularzach i API: przekierowanie 301 albo 302 po POST może dotrzeć do celu jako GET, bez danych. Jeśli przenosisz adres, pod który aplikacje wysyłają dane — np. punkt końcowy API albo adres, na który wysyła się formularz — użyj 308 albo 307, żeby zapytanie dotarło w niezmienionej postaci. Pozostałe kody, które API zwraca na co dzień — 2xx i 4xx — opisuje tekst o REST API.

303 ma z kolei zastosowanie odwrotne: zmiana na GET jest tu zamierzona. Klasyczny przykład to formularz zamówienia. Serwer przyjmuje POST, zapisuje zamówienie i odpowiada 303 z adresem strony „dziękujemy”. Przeglądarka otwiera tę stronę metodą GET, więc odświeżenie pokazuje potwierdzenie, a nie wysyła zamówienia drugi raz.

Przekierowanie 301 a Google

Dla Google przekierowanie trwałe to sygnał, który adres jest kanoniczny. Dokumentacja Google Search Central opisuje to wprost: przy przekierowaniu stałym w wynikach wyszukiwania pojawia się nowy adres docelowy, a przy tymczasowym — strona źródłowa. Przy 301 i 308 Googlebot podąża za przekierowaniem, a system indeksowania traktuje je jako sygnał, że cel powinien być kanoniczny; przy 302, 303 i 307 też podąża, ale takiego sygnału z niego nie bierze (Google Search Central, przekierowania). W innym miejscu Google nazywa 301 silnym, a 302 słabym sygnałem i podaje, że 307 traktuje jak 302, a 308 jak 301 (Google Search Central, kody HTTP).

W polskich poradnikach krąży twierdzenie, że przekierowanie 301 „przekazuje 90–99% mocy linku”, a 302 nie przekazuje nic. W dokumentacji Google nie ma ani tych procentów, ani takiego podziału — jest sygnał kanoniczny, silny albo słaby. Nie opieraj decyzji na liczbach, których nikt nie podał.

Z dokumentacji wynikają cztery praktyczne zasady:

1. Trwałe tylko wtedy, gdy nie cofniesz. Google radzi używać przekierowań stałych, „when you're sure that the redirect won't be reverted” (Google Search Central).
2. Trzymaj przekierowania długo. Przy przenoszeniu serwisu Google zaleca utrzymywać je „for as long as possible, generally at least 1 year” (Google Search Central, przenoszenie witryny).
3. Nie przekierowuj wszystkiego na stronę główną. Ten sam poradnik ostrzega, że przekierowanie wielu starych adresów na jedną niepasującą stronę, np. główną, może zostać uznane za soft 404. Strona usunięta bez następcy powinna zwrócić 404 albo 410 — szczegóły w tekście o błędzie 404.
4. Przekierowanie po stronie serwera. Przekierowania w JavaScripcie Google radzi stosować tylko wtedy, gdy nie da się zrobić przekierowania po stronie serwera ani przez meta refresh (Google Search Central).

Dlaczego 301 trudno cofnąć — cache przeglądarki

Przekierowanie 301 jest „heuristically cacheable” (RFC 9110, §15.4.2). To znaczy, że przeglądarka może przechować odpowiedź i przy następnym wejściu pójść prosto pod nowy adres, choć serwer nie powiedział, jak długo. Specyfikacja cache pozwala w takiej sytuacji samodzielnie przyjąć czas ważności, a jako typową wartość podaje 10% czasu, jaki minął od daty ostatniej zmiany w nagłówku Last-Modified; jeśli serwer podał jawny czas ważności, heurystyki używać nie wolno (RFC 9111, §4.2.2). Specyfikacja na to pozwala, ale nie nakazuje — jak robią to konkretne przeglądarki, sprawdziliśmy sami.

Lokalny serwer odpowiadał przekierowaniem w ośmiu wariantach, a Chromium 145 i Firefox 146 (sterowane przez Playwright, każdy wariant w świeżym profilu) otwierały ten sam adres trzy razy: drugi raz zaraz po pierwszym, trzeci po 70 sekundach. Serwer liczył, ile zapytań do niego dotarło. Pomiar powtórzyliśmy trzy razy z tym samym wynikiem.

Co z tego wynika:

• Chromium zapamiętał 301 i 308 bez żadnych nagłówków i do trzeciego wejścia po 70 sekundach nie zapytał serwera ani razu. Dłuższego okresu nie mierzyliśmy.
• Firefox bez nagłówków pytał serwer za każdym razem, ale gdy odpowiedź 301 miała Last-Modified sprzed 30 dni, zapamiętał ją jak Chromium — zgodnie z heurystyką, którą dopuszcza RFC 9111. Zastrzeżenie: Playwright uruchamia własną, zmodyfikowaną kompilację Firefoksa; zwykłego Firefoksa nie sprawdzaliśmy, więc nie zakładaj, że nie zapamięta 301.
• Jawne Cache-Control wygrało w obu przeglądarkach. max-age=60 dało jedną minutę pamięci, no-store — zero. Dotyczy to też 302: z max-age=60 obie przeglądarki zapamiętały przekierowanie tymczasowe.
• 302 i 307 bez nagłówków nie zostały zapamiętane nigdzie.

Praktyczny wniosek: jeśli nie masz pewności, że przeprowadzka jest ostateczna, zacznij od 302 albo daj na 301 krótki Cache-Control: max-age, a pełne 301 bez ograniczeń ustaw dopiero, gdy wszystko działa. Odwrotnie przy adresach, które mają się zmieniać: przekierowanie tymczasowe nie powinno mieć nagłówków cache, bo inaczej przeglądarka zapamięta i jego.

Co się dzieje, gdy cofniesz 301

Kusi, żeby pomyłkę z 301 naprawić przekierowaniem w drugą stronę. Sprawdziliśmy, co wtedy widzi ktoś, kto był już na stronie. Najpierw adres /a odpowiadał 301 na /b, z nagłówkiem Last-Modified, przy którym zapamiętują to obie przeglądarki. Potem „cofnęliśmy” zmianę: /a znowu pokazuje stronę, a /b odsyła kodem 302 z powrotem na /a.

Nowi odwiedzający nie zauważyli niczego. Powracający w Chromium utknął w pętli: przeglądarka brała z pamięci skok z /a na /b, serwer odsyłał z /b na /a i tak dziesięć razy, aż Chromium przerwał błędem „za dużo przekierowań”. Do adresu /a nie wysłał przy tym ani jednego zapytania. Firefox w tej samej sytuacji zapytał serwer o /a ponownie i otworzył stronę. Wniosek: zapamiętanego 301 nie cofniesz przekierowaniem zwrotnym. Bezpieczniej zostawić pod nowym adresem działającą stronę albo przenieść treść jeszcze raz, pod trzeci adres.

Przekierowanie 301 w .htaccess i nginx

Najczęstszy błąd przy przekierowaniu 301 w Apache to brak kodu. Dyrektywa Redirect bez argumentu statusu daje przekierowanie tymczasowe: „If no status argument is given, the redirect will be "temporary" (HTTP status 302)” (Apache, mod_alias). To samo z RewriteRule z flagą [R]: bez podanego kodu Apache wysyła 302 (Apache, flagi RewriteRule). Kod trzeba więc napisać jawnie:

Redirect dopasowuje początek ścieżki i dopisuje do nowego adresu resztę, która była za dopasowanym fragmentem (Apache, mod_alias) — reguła dla /blog przeniesie więc też /blog/artykul. W nginx przekierowanie ustawia dyrektywa return, która przyjmuje adres dla kodów 301, 302, 303, 307 i 308 (nginx, moduł rewrite):

Zmienna $request_uri to pełny pierwotny adres zapytania razem z parametrami (nginx, moduł core). Bez niej każda podstrona trafi na stronę główną nowej domeny, a parametry w rodzaju UTM czy gclid przepadną po drodze — co to oznacza dla raportów Google Ads, opisujemy w tekście o gclid. Przeglądarka sama przeniesie przy przekierowaniu tylko fragment po #, parametrów nie; pomiar w przeglądarkach i na publicznych serwisach jest w tekście o query stringu. Z czego składa się adres i która część za co odpowiada, wyjaśniamy w tekście o adresie URL.

W Next.js przekierowania ustawia się w next.config funkcją redirects(). Uwaga na nazewnictwo: permanent: true daje 308, a false — 307, a nie 301 i 302 (Next.js, redirects). Dla Google to bez różnicy, bo 308 traktuje jak 301:

Tak przekierowujemy zmienione adresy artykułów na tym blogu: stary adres odpowiada 308 i jednym skokiem prowadzi na nowy, co po wdrożeniu każdej takiej zmiany sprawdzamy poleceniem curl.

Przekierowanie domeny, https i www

Każda strona powinna mieć jeden adres, a pozostałe warianty — z http://, z www albo na starej domenie — powinny odsyłać na niego przekierowaniem stałym. MDN podaje to jako typowy przypadek: serwis działa pod www.example.com, ale wejście na example.com też ma zadziałać (MDN, Redirections). To przeprowadzki, których nie cofniesz, więc 301 albo 308 są tu właściwe.

Przy przeprowadzce całego serwisu Google zaleca kolejność: najpierw mapa adresów — lista, który stary adres odpowiada któremu nowemu — potem przekierowania na serwerze, a na końcu obserwacja ruchu na starych i nowych adresach. Wewnętrzne linki na nowej stronie warto od razu zmienić na nowe adresy, a przekierowywać „to the final destination directly”, bez pośrednich skoków (Google Search Central, przenoszenie witryny). Ten sam poradnik przypomina o linkach, których nie kontrolujesz w całości: profilach w mediach społecznościowych i kampaniach reklamowych — je też trzeba przestawić na nowe strony docelowe. Przekierowanie ratuje ruch, ale każdy link, który od razu wskazuje nowy adres, oszczędza odwiedzającemu jeden skok.

Przekierowanie domeny ustaw tam, gdzie zapytanie na pewno dociera. Częsty błąd: reguła „www → adres bez www” siedzi w kodzie aplikacji, ale zapytania na adres z www do aplikacji w ogóle nie trafiają — serwer albo serwis hostingowy przed nią nie zna tej nazwy i odpowiada błędem (np. 503), więc reguła nie ma szansy zadziałać. Przekierowanie domeny należy do warstwy, która przyjmuje ruch jako pierwsza: serwera WWW albo CDN.

Sprawdziliśmy, jak robią to duże serwisy. Na wejście przez http:// siedem z dziesięciu sprawdzonych odpowiada najpierw 301, pozostałe 302 albo 307, a do strony końcowej prowadzą od jednego do trzech skoków.

Łańcuchy i pętle przekierowań

Każdy skok w łańcuchu to osobne zapytanie i osobne oczekiwanie. Google zaleca trzymać łańcuch krótko, „ideally no more than 3 and fewer than 5”, bo przekierowania dokładają opóźnienia, a nie każda przeglądarka obsługuje długie łańcuchy (Google Search Central, przenoszenie witryny). Robot Google podąża domyślnie za najwyżej dziesięcioma skokami (Google Search Central). Pętla — przekierowanie, które po kilku skokach wraca do punktu wyjścia — kończy się błędem: specyfikacja wymaga, żeby klient takie pętle wykrywał (RFC 9110, §15.4), a Search Console zgłasza ją jako błąd przekierowania.

Łańcuchy rosną same, bo każda warstwa dokłada swoje: CDN przekierowuje http na https, potem www na adres bez www, potem aplikacja dodaje wersję językową. Tak wyglądało to u nas. 19.10.2026 adres http://www.dvn.dev/ z nieistniejącym kodem krótkiego linku wymagał czterech skoków, bo aplikacja kierowała na /pl, a moduł wersji językowych dokładał jeszcze 307 na /. Ten skok usunęliśmy. Dziś łańcuch wygląda tak:

Najdłużej trwa tu sama strona docelowa; każdy skok przekierowania kosztował w naszym pomiarze od 24 do 55 milisekund — mało, ale to czas, w którym odwiedzający patrzy na pusty ekran. Dwa pierwsze skoki to osobne reguły na CDN; jedna reguła, która z http://www odsyła od razu na https:// bez www, skróciłaby łańcuch o jeden skok.

Łańcuch sprawdzisz poleceniem curl, które pokazuje kod i nagłówek Location każdego skoku:

Bez terminala: w przeglądarce otwórz narzędzia deweloperskie, kartę Network, zaznacz „Preserve log” i wejdź na adres. Każdy skok będzie osobnym wierszem z kodem w kolumnie Status.

Kiedy 302, a nie 301

Przekierowanie tymczasowe jest właściwe wszędzie tam, gdzie cel ma się zmieniać albo stary adres ma pozostać tym, który ludzie i wyszukiwarka zapamiętują.

• Krótki link i kod QR. Krótki link ma liczyć każde kliknięcie i dawać się przestawić na inny cel po wydruku, więc skracacz powinien odpowiadać 302. Dlaczego i co się dzieje, gdy odpowiada 301, opisujemy w poradniku jak skrócić link. DVN Links przekierowuje krótkie linki kodem 302 bez nagłówków cache, a cel zmienisz w panelu — więcej na stronie funkcji.
• Test A/B. Google zaleca, żeby test, który przekierowuje użytkowników z oryginalnego adresu na wariant, używał 302, nie 301 (Google Search Central, testy witryn). Jak działa to w praktyce, pokazujemy w tekście o smart linku.
• Kampania na czas określony — adres akcji, który po jej końcu wróci na swoje miejsce albo poprowadzi gdzie indziej.
• Formularz — po wysłaniu POST wynik pokazuj pod innym adresem przez 303.

Najczęstsze pytania

Potrzebujesz adresu, który da się przestawić po wydruku? Krótki link DVN Links odpowiada kodem 302, więc cel zmienisz w panelu, a ulotka i kod QR zostaną te same. Konto założysz tutaj.