Przekierowanie 302

TL;DR — Przekierowanie 302 tymczasowo wysyła odwiedzających z jednego adresu URL na inny. Mówi wyszukiwarkom: „to przeniesienie nie jest stałe — zachowajcie oryginalny adres URL w wynikach”. Używaj go, gdy naprawdę chodzi o zmianę tymczasową (test A/B, strona wyprzedaży, komunikat o konserwacji). Użyj 301, gdy przenosisz stronę na dobre.

Czym jest przekierowanie 302

Przekierowanie to instrukcja, która wysyła każdego, kto żąda jednego adresu URL, pod inny. Gdy serwer odpowiada na żądanie, dołącza kod stanu HTTP — trzycyfrową liczbę mówiącą, co się stało. 302 jest jednym z kodów przekierowania. Jego oficjalna nazwa to „302 Found”, a jego cała charakterystyka mieści się w jednym słowie: tymczasowe. Evidence for this claim RFC 9110 defines 302 Found as a temporary move to another URI and notes that user agents may change POST to GET when following it. Scope: HTTP semantics for 302 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.3 — 302 Found

Właśnie ta tymczasowość jest najważniejsza. 302 mówi: ta strona została na razie przeniesiona, ale oryginalny adres URL wróci. Dlatego wyszukiwarki powinny zachować oryginalny adres URL w wynikach i traktować cel jako zastępstwo, a nie zamiennik.

Porównaj to z jego stałym krewniakiem, przekierowaniem 301, które mówi: „to przeniesienie jest na zawsze — zamiast niego zindeksuj nowy adres URL”. To samo doświadczenie odwiedzającego (oba kody wysyłają go na nową stronę), ale przeciwny komunikat dla wyszukiwarek.

Kiedy naprawdę go użyć

302 jest właściwym narzędziem, gdy przeniesienie jest rzeczywiście krótkotrwałe:

• Prowadzisz test A/B i wysyłasz część odwiedzających do wariantu strony.
• Masz tymczasową stronę wyprzedaży lub promocji i później wrócisz do poprzedniego adresu.
• Strona jest przez krótki czas niedostępna z powodu konserwacji i chcesz wyświetlić komunikat „wkrótce wracamy”, nie rezygnując z miejsca prawdziwego adresu URL w wynikach.
• Kierujesz odwiedzających według lokalizacji lub urządzenia (na przykład do wersji właściwej dla kraju lub języka), a „właściwy” cel zmienia się zależnie od odwiedzającego.

We wszystkich tych przypadkach chcesz, aby oryginalny adres URL pozostał w wynikach Google — i dokładnie o to prosi 302.

Rzecz, którą większość ludzi rozumie błędnie

Przez lata specjaliści SEO traktowali 302 jak coś radioaktywnego — „nie przekazuje żadnej wartości linków, nigdy go nie używaj”. To mit. 302 przekazuje sygnały linków; różni się od 301 tylko tym, który adres URL wyszukiwarki preferują do wyświetlenia. John Mueller z Google powiedział, że 302s “have a bad reputation among SEOs, which I think is incorrect.” (tłumaczenie) „mają złą reputację wśród specjalistów SEO, co uważam za błędne.”

Prawdziwym błędem nie jest użycie 302 — tylko użycie 302 przy stałym przeniesieniu. Jeśli na zawsze wycofujesz stronę, ale przekierowujesz ją kodem 302, mówisz Google „zachowaj stary adres URL w indeksie”, więc nowa strona, którą naprawdę chcesz pozycjonować, może nie przejąć miejsca przez długi, nieprzewidywalny czas. Przy przeniesieniu na zawsze użyj 301.

Chcesz poznać dokładną mechanikę — język Google o „słabym sygnale kontra silnym sygnale”, dlaczego długo utrzymywany 302 może się przełączyć i zacząć działać jak 301 oraz jak traktuje go Bing? Przejdź do karty Advanced.

TL;DR — 302 („Found”) to tymczasowe przekierowanie. Precyzyjne ujęcie Google obejmuje dwa etapy, nie jeden: infrastruktura crawlowania nazywa je słabym sygnałem, że cel przekierowania powinien zostać przetworzony, w przeciwieństwie do silnego sygnału 301 — a osobno potok indeksowania Search mówi, że nie traktuje tymczasowego przekierowania jako sygnału, że cel powinien być kanoniczny (cel nadal może zostać zindeksowany przez inne sygnały). Dwa mechanizmy są stale mylone: przekazywanie sygnałów linków/PageRank (Mueller i Illyes powiedzieli, że nie jest zerowe w przypadku 302, choć to ich publiczne stwierdzenie, a nie formalnie opublikowana uniwersalna reguła) oraz preferencja kanonizacji/indeksowania (to ona faktycznie się różni — 302 mówi Google, aby zachować źródłowy adres URL w indeksie). Pozostawiony dostatecznie długo 302 może się przełączyć — to wzorzec zaobserwowany przez praktyków, a nie udokumentowany mechanizm, bez opublikowanego harmonogramu. Google zaleca 302 zamiast 301 przy testach A/B. Jedynym prawdziwym błędem jest użycie 302 przy stałym przeniesieniu; nie buduj też celu przekierowania z niesprawdzonych danych wejściowych użytkownika.

„Moved Temporarily” → „Found” — krótka historia

302 narodził się jako kod niejednoznaczny. W HTTP/1.0 nazywał się „Moved Temporarily”, a specyfikacja mówiła, że klienci powinni ponownie używać pierwotnej metody żądania podczas podążania za nim. W praktyce przeglądarki tego nie robiły — wiele z nich po cichu zmieniało POST na GET przy przekierowaniu, wbrew specyfikacji. HTTP/1.1 uznało rzeczywistość, zmieniając nazwę 302 na „Found” i dodając dwie jednoznaczne alternatywy: 303 (See Other), który zawsze zmienia metodę na GET, oraz 307 (Temporary Redirect), który nigdy nie zmienia metody. Aktualna specyfikacja, RFC 9110 (2022), nadal zaznacza, że klienci mogą zmienić POST na GET przy 302 — właśnie dlatego istnieje 307 dla przypadków, w których nie wolno tego zrobić. Przy zwykłych przekierowaniach stron opartych na GET (zastosowanie SEO) 302 i 307 zachowują się tak samo wobec wyszukiwarek; różnica zachowania metody ma znaczenie tylko przy wysyłaniu formularzy i wywołaniach API. Evidence for this claim RFC 9110 defines 302 Found as a temporary move to another URI and notes that user agents may change POST to GET when following it. Scope: HTTP semantics for 302 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.3 — 302 Found

Z punktu widzenia wyszukiwania Google grupuje 302 (found), 303 (see other) i 307 (temporary redirect) jako „Temporary”, w przeciwieństwie do 301 i 308 jako „Permanent”.

Skrócona decyzja, jeśli wybierasz między nimi:

• 302 — klient podążający za przekierowaniem może zmienić POST na GET (RFC 9110). To dobre rozwiązanie dla zwykłego przekierowania strony opartego na GET; unikaj go, jeśli nie możesz tolerować zmiany metody.
• 307 — nigdy nie zmienia metody ani nie wysyła innego żądania. Użyj go, gdy wysłanie formularza lub wywołanie API musi zostać dokładnie powtórzone.
• 303 — celowo wskazuje inny, niebędący odpowiednikiem zasób, zwykle pobierany przez GET/HEAD — klasyczny wzorzec „przekieruj po POST do strony potwierdzenia”, a nie zamiennik tego samego żądania.
• Cache — 302 nie jest heurystycznie możliwy do zapisania w cache tylko ze względu na kod stanu (RFC 9111); zostanie zapisany i ponownie użyty wyłącznie po ustawieniu jawnych dyrektyw świeżości lub cache. Nie zakładaj, że CDN albo przeglądarka domyślnie potraktuje go jako możliwy do cache’owania.

Słaby kontra silny sygnał — precyzyjne słowa Google

Pomiń folklor i przeczytaj rzeczywisty język Google. W dokumentacji infrastruktury crawlowania Google mówi, że 302 jest słabym sygnałem:

“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 przekierowania powinien zostać przetworzony.”

Wiersz dotyczący 301 w tej samej tabeli jest identyczny z wyjątkiem jednego słowa — strong:

“Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (tłumaczenie) „Google podąża za przekierowaniem, a systemy Google używają przekierowania jako silnego sygnału, że cel przekierowania powinien zostać przetworzony.”

„Słaby” nie znaczy „zerowy” — ale warto też precyzyjnie wskazać, co jest słabe. Mówią tu dwa różne systemy Google o dwóch różnych etapach, a nie jeden ciągły zakres:

• Infrastruktura crawlowania (powyższy cytat o „słabym sygnale”) dotyczy tego, czy cel przekierowania zostanie przetworzony — w praktyce, czy crawler Google pobierze i obejrzy stronę docelową.
• Potok indeksowania Search to osobny, późniejszy etap, który podaje własną regułę wprost: “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical. The target page might still be indexed if other canonicalization signals are present.” (tłumaczenie) „Googlebot podąża za przekierowaniem, ale potok indeksowania nie używa go jako sygnału, że cel powinien być kanoniczny. Strona docelowa nadal może zostać zindeksowana, jeśli obecne są inne sygnały kanonizacji.” Evidence for this claim Google follows a 302 temporary redirect but does not use it as a signal that the destination should become canonical; Google recommends 302 rather than 301 for temporary site tests. Scope: Google Search handling of temporary redirects and A/B tests. Confidence: high · Verified: 2026-07-14 Google: Redirects and Google Search Google: Website testing

Czytaj te informacje razem: 302 daje Google delikatny impuls, aby zajrzał do celu (crawlowanie), ale potok indeksowania Search nie traktuje tego samego przekierowania jako głosu za uczynieniem celu kanonicznym (indeksowanie). Cel nadal może zostać zindeksowany i stać się kanoniczny — ale dzięki innym sygnałom, a nie dzięki samemu 302. Nie sprowadzaj tego do „302 jest słabym głosem za kanonicznością celu” — żaden z tych dokumentów tego nie mówi; opisują różne zakresy.

Dwa mechanizmy, nie jeden

W tym miejscu większość treści konkurencji miesza pojęcia, więc zachowaj je osobno:

1. Przekazywanie sygnałów linków/PageRank nie jest zerowe przy 302. Gary Illyes powiedział w 2016 roku, że Google nie stosuje już rozcieńczania PageRank przy przekierowaniach 301, 302 ani innych 30x (odchodząc od starego folkloru o „utracie około 15% na przeskoku”), a Mueller powiedział to samo konkretnie o 302: “do work the same as normal redirects… It’s not that they don’t pass any PageRank or anything like that.” (tłumaczenie) „działają tak samo jak zwykłe przekierowania… Nie chodzi o to, że nie przekazują żadnego PageRank ani niczego podobnego.” Traktuj to jako publiczne stwierdzenie Google w tej kwestii, a nie formalnie opublikowaną, uniwersalną gwarancję transferu — aktualna dokumentacja pierwotna nie opisuje dokładnej reguły transferu sygnałów linków dla każdego typu przekierowania w każdej sytuacji.
2. Preferencja kanonizacji/indeksowania to mechanizm, który faktycznie się różni. 301 jest silnym sygnałem, aby zindeksować cel; 302 jest słaby, więc domyślnie Google zachowuje indeksowanie źródła.

„Czy 302 przekazuje PageRank?” oraz „czy 302 zmienia adres URL, który się pozycjonuje?” to dwa różne pytania. Odpowiedź na pierwsze brzmi „tak”, a na drugie „nie, nie domyślnie”. Ich pomieszanie dało początek mitowi „302 = zero wartości”.

W związku z tym: po przekierowaniu adresu URL Google śledzi oba końce. “Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent. The other URL becomes an alternate name of the canonical URL.” (tłumaczenie) „Google śledzi zarówno źródło przekierowania (stary adres URL), jak i jego cel (nowy adres URL). Jeden z adresów URL będzie kanoniczny; który, zależy od sygnałów, takich jak tymczasowy lub stały charakter przekierowania. Drugi adres URL staje się alternatywną nazwą kanonicznego.” W przypadku 302 źródło pozostaje kanoniczne — na razie.

Co się dzieje, gdy 302 pozostaje zbyt długo — „przełączenie”

Oto część, która zaskakuje ludzi: tymczasowe przekierowanie, którego nigdy nie usunięto, może przestać być traktowane jako tymczasowe. Mueller: “if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.” (tłumaczenie) „jeśli utrzymujesz przekierowania 302 przez długi czas, i tak traktujemy je dokładnie tak samo jak przekierowania 301.”

Dlaczego tak się dzieje? To moje własne robocze wyjaśnienie z poradnika kanonizacji Ahrefs — model mentalny praktyka zbudowany na podstawie obserwowanego zachowania, a nie mechanizm formalnie opublikowany przez Google — potraktuj to jak przechylającą się wagę. Stałe przekierowania wysyłają sygnały do przodu, na nowy adres URL; tymczasowe przekierowania wysyłają sygnały wstecz, na oryginalny adres URL. Ale:

“If a temporary redirect is left in place long enough or the URL it’s redirected to already exists, it may be treated as a permanent redirect and send signals forward instead. It requires enough signals to flip the scale we saw earlier for canonicalization signals. As links build up, internal links are changed, sitemap URLs are updated, etc., more signals point to the new URL than the old URL, and the flip occurs.” (tłumaczenie) „Jeśli tymczasowe przekierowanie pozostanie aktywne wystarczająco długo lub adres URL, do którego prowadzi, już istnieje, może zostać potraktowane jako stałe i zamiast tego wysyłać sygnały do przodu. Do przechylenia wagi potrzebna jest wystarczająca liczba sygnałów kanonizacji. Gdy przybywa linków, zmieniają się linki wewnętrzne, aktualizowane są adresy URL w sitemapach itd., więcej sygnałów wskazuje nowy adres URL niż stary i następuje przełączenie.”

Pułapka polega na tym, że nikt nie wie, ile to trwa. Jak napisałem w poradniku o przekierowaniach, “Nobody knows how long a 302 redirect has to exist before Google starts treating it as a 301 redirect. Usually, it’s a few weeks to a few months, but it can be days, weeks, or months.” (tłumaczenie) „Nikt nie wie, jak długo przekierowanie 302 musi istnieć, zanim Google zacznie traktować je jak 301. Zwykle jest to od kilku tygodni do kilku miesięcy, ale mogą to być dni, tygodnie lub miesiące.” Google może zadziałać wcześniej, jeśli uzna, że popełniłeś błąd: “Only if Google thinks you used a 302 redirect by mistake for a permanent move does this not happen. In that case, it treats the redirect as a 301… In some circumstances, Google even appears to treat 302s as 301s from the get-go.” (tłumaczenie) „Tylko gdy Google uzna, że przez pomyłkę użyto 302 przy stałym przeniesieniu, to się nie dzieje. W takim przypadku traktuje przekierowanie jak 301… W pewnych okolicznościach Google zdaje się nawet traktować 302 jak 301 od samego początku.” Nie podawaj konkretnej liczby dni — nie ma opublikowanej wartości, a żadna liczba, którą zobaczysz (w tym „2 dni” krążące w folklorze Binga), nie została potwierdzona przez Google.

Jak Bing traktuje 302 — obserwuje zachowanie, nie tylko nagłówek

Bing dochodzi do podobnego wniosku nieco inną drogą i mówi o tym wprost. W swoim wieloletnim objaśnieniu przekierowań Bing opisuje obserwowanie wzorca przekierowania podczas kolejnych crawlów, zamiast ufania samemu kodowi stanu: przekierowania, które stale zmieniają cel, są traktowane bardziej jak 302, nawet jeśli mają etykietę 301, a przekierowania zawsze wskazujące to samo miejsce są traktowane bardziej jak 301, nawet jeśli mają etykietę 302 — system Binga zaczyna „myśleć o nich bardziej jak o 301, gdy crawlujemy je ponownie raz za razem”. To ta sama konwergencja, którą opisuje Google, osiągnięta niezależnie: przy wystarczająco spójnym zachowaniu obie wyszukiwarki bardziej ufają temu, co przekierowanie robi, niż temu, co twierdzi jego nagłówek.

Starsze wytyczne Binga również mocniej niż dzisiejsze Google skłaniały się ku „oszczędnemu używaniu 302”, ostrzegając, że niewłaściwie użyty 302 może pozostawić wartość na starych adresach URL. Wniosek praktyczny jest taki sam jak u Google: dopasuj typ przekierowania do rzeczywistej intencji.

Kiedy 302 jest właściwym wyborem

Google nie tylko toleruje 302s — przy jednym zastosowaniu zaleca ten kod. Z wytycznych dotyczących testów A/B:

“If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect. This tells search engines that this redirect is temporary—it will only be in place as long as you’re running the experiment—and that they should keep the original URL in their index rather than replacing it with the target of the redirect (the test page). JavaScript-based redirects are also fine.” (tłumaczenie) „Jeśli prowadzisz test przekierowujący użytkowników z oryginalnego adresu URL na wariant, użyj przekierowania 302 (tymczasowego), a nie 301 (stałego). Informuje to wyszukiwarki, że przekierowanie jest tymczasowe — będzie aktywne tylko tak długo, jak długo prowadzisz eksperyment — i że powinny zachować oryginalny adres URL w indeksie, zamiast zastępować go celem przekierowania (stroną testową). Przekierowania oparte na JavaScripcie również są dopuszczalne.”

Uzasadnione przypadki użycia (wszystkie rzeczywiście tymczasowe):

• Testy A/B — wyraźna rekomendacja Google powyżej. Nie przeciągaj jednak testu: Google ostrzega, że “if we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” (tłumaczenie) „jeśli odkryjemy witrynę prowadzącą eksperyment przez niepotrzebnie długi czas, możemy zinterpretować to jako próbę oszukania wyszukiwarek i odpowiednio zareagować.” Prowadź test tak długo, jak potrzeba do uzyskania istotności, a następnie go usuń.
• Routing geograficzny, urządzenia i języka — gdy „właściwy” cel zależy od odwiedzającego i żaden pojedynczy adres URL nie powinien na stałe zastąpić źródła. Tu potrzeba czegoś więcej niż wyboru kodu stanu: sprawdź, do czego trafia sam Googlebot (zwykle nie wysyła prawdziwych sygnałów lokalizacji ani urządzenia odwiedzającego), czy routing korzysta z ciasteczek lub nagłówków, których crawler nie wysyła, czy klucze cache i nagłówek Vary poprawnie rozdzielają warianty (aby cache nie podał strony jednego kraju innemu), czy użytkownik czytnika ekranu lub bez JavaScriptu może dotrzeć do treści oraz czy odwiedzający może nadpisać automatyczny routing, zamiast utknąć w pętli przekierowań. Połącz to z prawidłowym hreflang na wersjach lokalnych — przekierowanie i hreflang powinny się zgadzać, a nie wzajemnie zwalczać.
• Tymczasowe strony konserwacji / niedostępności usługi — własny przykład Google: “if a service your site offers is temporarily unavailable, you can set up a temporary redirect to send users to a page that explains what’s happening, without compromising the original URL in search results.” (tłumaczenie) „jeśli usługa oferowana przez witrynę jest tymczasowo niedostępna, możesz ustawić tymczasowe przekierowanie wysyłające użytkowników na stronę wyjaśniającą sytuację, bez naruszania pozycji oryginalnego adresu URL w wynikach wyszukiwania.” Zastanów się, który z dwóch przypadków naprawdę masz. Jeśli sam adres URL po prostu nie może być teraz obsłużony (backend jest wyłączony, trwa wdrożenie), 503 Service Unavailable z nagłówkiem Retry-After na tym samym adresie URL jest często dokładniejszą odpowiedzią — mówi „tymczasowo nie mogę spełnić tego żądania, spróbuj ponownie później”, bez przekierowywania gdziekolwiek. Sięgnij po 302, gdy celowo kierujesz odwiedzających do innego, rzeczywiście użytecznego adresu URL z wyjaśnieniem (strony statusu lub strony „wrócimy” z większą ilością szczegółów), a nie tylko oznaczasz oryginał jako niedostępny.
• Promocje ograniczone czasowo — wysyłaj odwiedzających na stronę kampanii podczas jej trwania, a potem wróć do poprzedniego adresu.
• Równoważenie obciążenia / przełączanie awaryjne — kieruj ruch gdzie indziej, gdy źródło lub centrum danych jest tymczasowo niedostępne.

Zobacz kartę Examples, aby obejrzeć te przypadki z adnotacjami obok siebie, oraz kartę Checklists, aby wykonać kontrolę przed uruchomieniem.

Jeden prawdziwy błąd

Użycie 302, gdy chodzi o stałe przeniesienie. Mówisz Google, aby zachował stary adres URL w indeksie, więc nowa strona, którą chcesz pozycjonować, może nie przejąć miejsca przez nieokreślony, nieprzewidywalny czas — to realny koszt utraconej widoczności, a nie teoretyczne ryzyko. Jeśli strona zniknęła na dobre, użyj 301 (lub 308). Powiązane błędy to niespójne mieszanie 301 i 302 w łańcuchu przekierowań oraz — tryb awarii każdego przekierowania — przypadkowe skierowanie dwóch adresów URL do siebie nawzajem i utworzenie pętli.

Wdrażanie 302

Liczy się nagłówek — wiersz statusu 302 Found i Location. Własny przykład PHP Google:

header('HTTP/1.1 302 Found');
header('Location: https://www.example.com/newurl');
exit();

Apache (.htaccess) — flaga R=302 sprawia, że przekierowanie jest tymczasowe (R=301 lub samo R domyślnie oznaczałoby stałe):

Redirect 302 /old-path https://www.example.com/newurl
# or with mod_rewrite:
RewriteRule ^old-path/?$ https://www.example.com/newurl [R=302,L]

nginx — redirect wydaje 302 (permanent wydałoby 301):

location = /old-path {
    return 302 https://www.example.com/newurl;
}

Niezależnie od stosu (wtyczki przekierowań WordPressa, reguła CDN/brzegu sieci, handler na poziomie aplikacji), zasada jest taka sama: preferowane są przekierowania po stronie serwera, a kod tymczasowy trzeba wybrać świadomie — większość narzędzi domyślnie ustawia 301, więc 302 zwykle wymaga jawnego ustawienia.

Jedna uwaga dotycząca bezpieczeństwa, która dotyczy każdego przekierowania, nie tylko 302s: jeśli cel w nagłówku Location jest kiedykolwiek budowany na podstawie danych wejściowych kontrolowanych przez użytkownika (na przykład parametru zapytania ?next= lub ?returnUrl=), masz składniki otwartego przekierowania — atakujący tworzy link w Twojej domenie, który w rzeczywistości odbija odwiedzających gdzieś złośliwie. Nie wysyłaj odwiedzających pod dowolny adres URL pojawiający się w parametrze żądania; umieść na liście dozwolonych cele, do których rzeczywiście będziesz przekierowywać (stały zestaw znanych, bezpiecznych ścieżek lub źródeł), i przed wdrożeniem sprawdź, jak logika przekierowania obsługuje zakodowane oraz względne względem schematu dane wejściowe (//evil.example, %2F%2Fevil.example i podobne sztuczki). Przed wdrożeniem porównaj dokładną składnię każdego fragmentu dla danej platformy z aktualną wersją — powyższe przykłady są ilustracyjne i nie zastępują testów na własnym serwerze/CDN.

Stały odpowiednik oraz pełne porównanie opisują sąsiednie artykuły o przekierowaniu 301, 301 kontra 302 i 302 kontra 307 w tym klastrze.

Podsumowanie AI

Skrót wersji Advanced:

• 302 (“Found” (tłumaczenie) „Znaleziono”) jest tymczasowym przekierowaniem (kod stanu HTTP 302). Przekazuje użytkowników na nowy adres URL, sygnalizując, że oryginalny adres URL powinien pozostać w wynikach wyszukiwania.
• Dokładne ujęcie Google ma dwa etapy, a nie jedno kontinuum. Infrastruktura crawlowania określa 302 jako słaby sygnał, że cel należy “processed” (tłumaczenie) „przetworzyć przez Google” (zindeksować lub obejrzeć) — w przeciwieństwie do silnego sygnału 301. Osobno potok indeksowania Search nie używa tymczasowego przekierowania jako sygnału, że cel powinien być “canonical” (tłumaczenie) „kanoniczny dla celu” — choć inne sygnały nadal mogą doprowadzić do jego indeksowania. Słaby sygnał ≠ zero, a “processed” (tłumaczenie) „przetworzony przez Google” ≠ “made canonical.” (tłumaczenie) „uznany za kanoniczny”.
• 302 a 303 a 307, w skrócie: klient może zmienić metodę 302 z POST na GET; 307 nigdy nie zmienia metody; 303 celowo wskazuje inny, nieekwiwalentny zasób. Żaden z nich nie jest domyślnie heurystycznie zapisywany w cache — cache’owanie wymaga jawnych dyrektyw.
• Przekazywanie sygnałów linków nie jest przy 302 zerowe — Mueller i Illyes tak twierdzili — ale to ich publiczne stanowisko, a nie formalnie opublikowana uniwersalna reguła transferu dla każdego scenariusza przekierowania. Różni się mechanizm preferencji kanonizacji i indeksowania: 301 kieruje indeksowanie ku celowi, a 302 domyślnie pozostawia je przy źródle.
• Długotrwałe 302s mogą się “flip.” (tłumaczenie) „przełączyć”. To wzorzec zaobserwowany przez praktyków (Mueller, własne doświadczenie Patricka), a nie udokumentowany mechanizm z opublikowanym harmonogramem — “days, weeks, or months,” (tłumaczenie) „dni, tygodnie lub miesiące”, bez stałej liczby.
• Bing obserwuje zachowanie, nie tylko nagłówek: przekierowania zachowujące się spójnie podczas kolejnych crawlów są przeklasyfikowywane niezależnie od kodu stanu — podobnie jak opisuje to Google.
• Google zaleca 302, a nie 301, przy testach A/B. Inne uzasadnione zastosowania to routing geograficzny/urządzeń/języka (sprawdź faktyczne traktowanie Googlebota, cookies, zachowanie Vary/cache, dostępność i połącz go z hreflang), tymczasowe strony konserwacji (porównaj z 503 i Retry-After, gdy ten sam adres URL nie może być teraz obsłużony), promocje ograniczone w czasie oraz równoważenie obciążenia/przełączenie awaryjne. Nie prowadź testu A/B przez “an unnecessarily long time” (tłumaczenie) „niepotrzebnie długi czas” — Google może uznać to za wprowadzające w błąd.
• Bezpieczeństwo: nigdy nie buduj celu Location bezpośrednio z danych wejściowych użytkownika — umieszczaj cele na liście dozwolonych, aby uniknąć nadużycia otwartych przekierowań.
• Jeden rzeczywisty błąd: użycie 302 przy stałej zmianie — może pozostawić starą stronę w rankingu zamiast nowej na czas nieokreślony. Przy przenosinach na zawsze użyj 301.

Oficjalna dokumentacja

Najważniejsze źródła pierwotne to dokumentacja Google dotycząca przekierowań i kodów HTTP, wytyczne Google dotyczące testów A/B, dokumentacja Bing dotycząca przekierowań oraz specyfikacja HTTP.

Google

• Przekierowania i wyszukiwarka Google — tabela typów przekierowań (stałe i tymczasowe), rekomendacja „zachowaj stary adres URL w wynikach Search”, śledzenie alternatywnych adresów URL oraz przykład implementacji w PHP.
• Jak kody stanu HTTP wpływają na crawlery Google — tabela 3xx z dokładnym językiem o „słabym sygnale” (302) i „silnym sygnale” (301).
• Najlepsze praktyki testów A/B dla Search — wyraźna rekomendacja Google „użyj 302, nie 301” przy testach oraz ostrzeżenie przed prowadzeniem ich przez „niepotrzebnie długi czas”.

Bing / Microsoft

• Zarządzanie przekierowaniami — 301, 302 i kanoniczne adresy URL (Bing Webmaster Blog) — wyjaśnienie Binga dotyczące różnicy między 301 i 302 oraz stanowisko „obserwujemy zachowanie, nie tylko nagłówek”. (Bieżący wpis jest renderowany w JavaScripcie; dosłowny tekst zachowano w archiwum Wayback Machine.)

Specyfikacja HTTP / materiały referencyjne

• MDN — 302 Found oraz 307 Temporary Redirect — niuans zachowania metod i powód istnienia kodów 303/307.
• RFC 9110, §15.4.3 (302 Found) — bieżąca specyfikacja HTTP Semantics; odnotowuje, że klienci nadal mogą zmieniać POST→GET przy 302.

Cytaty ze źródła

Wypowiedzi Google i Binga zapisane wprost. Każdy odnośnik do dokumentacji jest głębokim linkiem, który przenosi do cytowanego fragmentu strony źródłowej.

Google — rozróżnienie słabego i silnego sygnału (oś dokładności)

• “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 przekierowania powinien zostać przetworzony.” — o 302. Przejdź do cytatu
• “Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (tłumaczenie) „Google podąża za przekierowaniem, a systemy Google używają przekierowania jako silnego sygnału, że cel przekierowania powinien zostać przetworzony.” — kontrastujący wiersz 301 z tej samej tabeli. 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. The target page might still be indexed if other canonicalization signals are present.” (tłumaczenie) „Googlebot podąża za przekierowaniem, ale potok indeksowania nie używa go jako sygnału, że cel przekierowania powinien być kanoniczny. Strona docelowa nadal może zostać zaindeksowana, jeśli występują inne sygnały kanonizacji.” Przejdź do cytatu

Google — kiedy używać tymczasowego przekierowania

• “If you just want to send users to a different page temporarily, use a temporary redirect. This will also ensure that Google isn’t influenced by the redirect which may help keep the old URL in its Search results.” (tłumaczenie) „Jeśli chcesz tylko tymczasowo wysłać użytkowników na inną stronę, użyj tymczasowego przekierowania. Dzięki temu przekierowanie nie wpłynie na Google, co może pomóc zachować stary adres URL w wynikach wyszukiwania.” Przejdź do cytatu
• “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent.” (tłumaczenie) „Gdy przekierowujesz adres URL, Google śledzi zarówno źródło przekierowania (stary adres URL), jak i cel przekierowania (nowy adres URL). Jeden z tych adresów URL będzie kanoniczny; który — zależy od sygnałów, takich jak tymczasowy lub stały charakter przekierowania.” Przejdź do cytatu

Google — testy A/B (zalecany 302, ale nie przeciągaj testu)

• “If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect.” (tłumaczenie) „Jeśli prowadzisz test przekierowujący użytkowników z oryginalnego adresu URL na wariant, użyj przekierowania 302 (tymczasowego), a nie 301 (stałego).” Przejdź do cytatu
• “If we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” (tłumaczenie) „Jeśli odkryjemy witrynę prowadzącą eksperyment przez niepotrzebnie długi czas, możemy zinterpretować to jako próbę oszukania wyszukiwarek i odpowiednio zareagować.” Przejdź do cytatu

John Mueller, Google — obalanie mitu „302 jest zły”

• “302 redirects have a bad reputation among SEOs, which I think is incorrect. Because they do work the same as normal redirects as well. It’s not that they don’t pass any PageRank or anything like that. And if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.” (tłumaczenie) „Przekierowania 302 mają złą reputację wśród SEO, co moim zdaniem jest nieprawidłowe. Działają przecież również tak samo jak zwykłe przekierowania. Nie jest tak, że nie przekazują żadnego PageRanku ani niczego podobnego. A jeśli utrzymujesz przekierowania 302 przez długi czas, i tak traktujemy je dokładnie tak samo jak przekierowania 301.” Przeczytaj transkrypcję

Bing / Microsoft — obserwowanie zachowania, nie tylko nagłówka

• Bing mówił, że przeklasyfikowuje przekierowania na podstawie obserwowanego wzorca podczas kolejnych crawlów: 301, których cel ciągle się zmienia, są traktowane bardziej jak 302, a 302, które zawsze wskazują to samo miejsce, są traktowane bardziej jak 301 “as we continue to crawl them again and again.” (tłumaczenie) „gdy nadal crawlujemy je raz za razem.” “We sometimes see 301s changing destination each time we crawl them” (tłumaczenie) „Czasem widzimy, że 301 zmieniają cel przy każdym crawlowaniu.” Źródło archiwalne

301 czy 302? — lista kontrolna przed wdrożeniem

Wykonaj tę kontrolę przed wdrożeniem dowolnego przekierowania, aby upewnić się, że kod odpowiada Twojej intencji:

• Czy przeniesienie jest stałe? Jeśli stary adres URL nigdy nie wróci → 301 (lub 308), a nie 302.
• Czy jest rzeczywiście tymczasowe? (Test A/B, promocja, konserwacja, routing geograficzny lub urządzeń, przełączenie awaryjne) → właściwy jest 302.
• Czy kod został ustawiony jawnie? Większość narzędzi domyślnie używa 301 — potwierdź, że 302 jest zamierzony, a nie wynika z wypadku, i odwrotnie.
• Test A/B? Użyj 302 (rekomendacja Google) i zaplanuj jego usunięcie, gdy test osiągnie istotność — nie zostawiaj go „przez niepotrzebnie długi czas”.
• Tymczasowa awaria pod tym samym adresem URL? Rozważ 503; 302 stosuj, gdy kierujesz ruch na inną stronę wyjaśniającą.
• Brak łańcuchów przekierowań niespójnie mieszających 301 i 302 — kieruj od razu do ostatecznego celu.
• Brak pętli — sprawdź ponownie, czy dwa adresy URL nie przekierowują do siebie nawzajem.
• Jeśli „tymczasowy” 302 po cichu stał się stały, zmień go na 301, aby sygnał odpowiadał rzeczywistości (i nie polegaj na nieokreślonym w czasie „przełączeniu” Google).
• Zweryfikuj faktyczny kod stanu zwracany przez serwer (curl -I, narzędzia deweloperskie przeglądarki albo checker przekierowań) — etykieta wtyczki przekierowań nie dowodzi, jaki nagłówek jest wysyłany.

Uzasadnione zastosowania 302 z adnotacjami

Pięć sytuacji, w których 302 jest właściwym wyborem — i dlaczego sygnał „tymczasowości” ma znaczenie w każdej z nich.

1. Test A/B

GET /pricing/           → 302 → /pricing/variant-b/

Wysyłasz część ruchu do wariantu, aby go zmierzyć. Chcesz, aby /pricing/ — oryginał — pozostał zaindeksowany i zachował pozycję; wariant jest przeznaczony do usunięcia. To przypadek, w którym Google wyraźnie zaleca 302. Usuń go, gdy test się zakończy; test uruchomiony bezterminowo może wyglądać jak oszustwo.

2. Tymczasowa wyprzedaż lub promocja

GET /shoes/             → 302 → /promo/summer-sale-shoes/

Przez czas trwania kampanii odwiedzający trafiają na stronę wyprzedaży, ale /shoes/ jest stałym adresem URL i powinien odzyskać swoje miejsce natychmiast po zakończeniu promocji. 301 byłby tu błędem: przekazałby pozycję adresu /shoes/ stronie, którą zaraz usuniesz.

3. Konserwacja lub tymczasowa niedostępność

GET /booking/           → 302 → /status/booking-back-soon/

Usługa jest krótko niedostępna, więc kierujesz użytkowników do strony wyjaśniającej. To własny przykład zastosowania Google. Oryginalny adres URL zachowuje pozycję w wynikach, gdy naprawiasz problem. (Jeśli ten sam adres URL jest po prostu offline, zamiast kierować gdzie indziej często czytelniejszym sygnałem będzie 503 Service Unavailable.)

4. Routing geograficzny, urządzeń lub języka

GET /               → 302 → /us/     (visitor in the US)
GET /               → 302 → /de/     (visitor in Germany)

Cel zależy od tego, kto pyta, więc żaden pojedynczy cel nie powinien na stałe zastępować źródłowego adresu URL. Tymczasowe przekierowanie pasuje, ponieważ „właściwa” odpowiedź zmienia się dla każdego żądania. (Połącz je z prawidłowym hreflang dla wersji lokalnych.)

5. Równoważenie obciążenia lub przełączenie awaryjne

GET /app/               → 302 → /app-eu-west/     (primary origin down)

Gdy źródłowy serwer lub centrum danych jest tymczasowo niedostępne, ruch przełącza się gdzie indziej — ale to przekierowanie powinno zakończyć się po przywróceniu głównego źródła. Z definicji jest tymczasowe.

Antywzorzec, dla kontrastu:

GET /old-product/       → 302 → /new-product/     ❌ (permanent move!)

To stałe wycofanie produktu przebrane za tymczasowe. W rezultacie Google może przez nieprzewidywalnie długi czas zachować /old-product/ w indeksie i rankingu zamiast skonsolidować sygnały na /new-product/. Tu powinien być 301.

Dwa mechanizmy, nie jeden

Użyj tego modelu, aby nie mieszać mitów o przekierowaniach z odrębnymi pytaniami.

Zastosuj to w trzech krokach:

1. Określ intencję. 302 mówi, że przeniesienie jest tymczasowe, a oryginalny adres URL powinien pozostać stabilnym adresem.
2. Sprawdź sygnały kanonizacji. Linki wewnętrzne, wpisy w sitemapach, znaczniki canonical, linki zewnętrzne i czas działania przekierowania mogą wzmacniać źródło albo sprawić, że wygra cel.
3. Prawidłowo zinterpretuj długotrwały 302. Jeśli Google zacznie traktować go jak stałe przeniesienie, przekierowanie nie zaczęło nagle „przekazywać wartości”. Zmieniła się równowaga sygnałów kanonizacji decydująca o tym, który adres URL przejmuje pulę.

Pytanie diagnostyczne nie brzmi „czy 302 przekazuje PageRank?”, lecz „który adres URL powinien być kanoniczny i czy przekierowanie wraz z naszymi pozostałymi sygnałami mówią to samo?”

Narzędzia do sprawdzania tymczasowych przekierowań

Bezpłatne narzędzia Patricka

• Redirect Checker — sprawdź, czy pierwszy krok rzeczywiście zwraca 302, obejrzyj Location i wykryj łańcuch mieszający tymczasowe oraz stałe kody.
• Bulk HTTP Status Code Checker — sprawdź do 500 adresów URL testów, promocji, routingu lub konserwacji i wyeksportuj każdą odpowiedź, która nie pasuje do zaplanowanego zachowania tymczasowego.

Sprawdzanie zachowania kanonicznego i czasu działania

• Google Search Console URL Inspection — porównaj źródłowy i wariantowy adres URL oraz sprawdź, który Google wybrał jako kanoniczny.
• Logi serwera lub CDN — potwierdź, że przekierowanie dotyczy zamierzonej grupy odbiorców i okresu oraz że Googlebot przypadkowo nie otrzymuje innej ścieżki.
• Logi lub konfiguracja platformy eksperymentu — zapisz początek i koniec testu, przydział ruchu oraz regułę przekierowania, aby tymczasowa odpowiedź nie stała się zapomnianą częścią infrastruktury.

Udowodnij, że tymczasowe przekierowanie pozostało tymczasowe

Test 1 — Eksperyment emituje prawdziwy kod 302

• Test do wykonania — Sprawdź oryginalny adres URL za pomocą Redirect Checker, będąc przypisanym do wariantu z przekierowaniem; jeśli przydział opiera się na ciasteczku, powtórz test w czystej sesji. Wykonaj prawdziwe GET, a nie tylko żądanie HEAD — obsługa na serwerze, CDN-ie lub w aplikacji może się między nimi różnić, więc samo sprawdzenie HEAD nie dowodzi, co otrzymuje prawdziwy odwiedzający (ani Googlebot). Zapisz surową linię statusu, dokładną wartość Location i wszystkie nagłówki kontroli cache z odpowiedzi, nie tylko informację „przekierowało”.
• Oczekiwany wynik — Źródło zwraca 302 z zamierzonym wariantem w Location, a wariant rozwiązuje się bez pętli, dodatkowego niepowiązanego kroku ani łańcucha.
• Interpretacja niepowodzenia — 301/308 wysyła stały sygnał; 200 po którym następuje nawigacja, oznacza przekierowanie po stronie klienta zamiast planowanej odpowiedzi serwera; różne kody dla HEAD i GET tego samego adresu URL oznaczają niespójną obsługę metod przez serwer lub CDN i wymagają dokładniejszego sprawdzenia.
• Okno monitorowania — Bezpośrednio po włączeniu testu, a następnie po każdym wdrożeniu lub zmianie routingu.
• Warunek wycofania — Oryginał zwraca stały kod, cel jest nieprawidłowy albo dowolna kohorta trafia do pętli.

Test 2 — Oryginał pozostaje kanonicznym adresem URL

• Test do wykonania — Sprawdź oryginalny i wariantowy adres URL w Google Search Console oraz zweryfikuj, że linki wewnętrzne, wpisy w sitemapach i znaczniki canonical nadal preferują oryginał.
• Oczekiwany wynik — Oryginał pozostaje zamierzonym adresem kanonicznym; wariant nie zastępuje go jako osobno zaindeksowana strona testowa.
• Interpretacja niepowodzenia — Sprzeczne sygnały kanonizacji albo przekierowanie działające niepotrzebnie długo kierują Google ku wariantowi.
• Okno monitorowania — Sprawdź po ponownym crawlowaniu adresów URL przez Google i ponownie podczas długiego testu; nie ma ustalonego dnia, w którym 302 się przełącza.
• Warunek wycofania — Wariant staje się kanonicznym adresem wybranym przez Google albo zaczyna niezależnie pojawiać się dla zapytań dotyczących oryginalnej strony.

Test 3 — Tymczasowa reguła zostaje usunięta po zakończeniu testu

• Test do wykonania — Po wyłączeniu testu zażądaj oryginalnego adresu URL w czystej sesji i przepuść go przez Redirect Checker.
• Oczekiwany wynik — Oryginał ponownie zwraca zwykłą treść 200 i żaden przydział testowy nie przekierowuje do wariantu.
• Interpretacja niepowodzenia — Pozostała nieaktualna reguła CDN-u, brzegu sieci, aplikacji lub eksperymentu.
• Okno monitorowania — Natychmiast po wyłączeniu oraz raz po wygaśnięciu cache.
• Warunek wycofania — Dowolna kohorta produkcyjna nadal trafia do wycofanego wariantu; wyłącz nieaktualną regułę i wyczyść odpowiedni cache.

Test 4 — Pełny łańcuch, zachowanie metod i przypadki brzegowe są objęte kontrolą

• Test do wykonania — Prześledź cały łańcuch przekierowań od początku do końca (nie tylko pierwszy krok) i potwierdź, że ostateczny cel zwraca prawidłową odpowiedź; powtórz test z dołączonym parametrem zapytania i potwierdź, że jest zachowany (albo celowo usunięty), zamiast po cichu znikać; wyślij żądania z treścią POST, jeśli trasa może je otrzymywać, aby sprawdzić, czy metoda zostaje zachowana lub zmieniona; a jeśli cel przekierowania kiedykolwiek pochodzi od użytkownika, potwierdź sprawdzanie go względem listy dozwolonych zamiast akceptowania dowolnego celu.
• Oczekiwany wynik — Łańcuch rozwiązuje się w małej, przewidywalnej liczbie kroków do działającej strony; parametry i metoda zachowują się zgodnie z intencją aplikacji; cele spoza listy dozwolonych są odrzucane, a nie przekierowywane.
• Interpretacja niepowodzenia — Długi lub zapętlony łańcuch, zgubiony parametr psujący stronę docelową, metoda po cichu zmieniona wbrew wymaganiom albo przekierowanie podążające za dowolnym parametrem w rodzaju ?next= (ryzyko otwartego przekierowania) to ustalenia blokujące wdrożenie, a nie kosmetyka.
• Okno monitorowania — Przed uruchomieniem oraz po każdej zmianie reguły, CDN-u lub wersji frameworka obsługującej przekierowanie.
• Warunek wycofania — Dowolna z powyższych awarii w ruchu produkcyjnym.
• Zastrzeżenie dotyczące narzędzi — Narzędzie URL Inspection w Search Console ma własne ograniczenia w takim sprawdzeniu (odzwierciedla własny crawl Google i nie musi pokazywać bieżących surowych nagłówków) — traktuj je jako sygnał tego, co zobaczyło Google, a nie jako zamiennik samodzielnego sprawdzenia rzeczywistej odpowiedzi HTTP.

Sprawdź się: przekierowania 302

Pięć krótkich pytań o to, czym jest 302 i kiedy go używać. Wybierz odpowiedź na każde pytanie, a następnie sprawdź wynik.

Dziennik zmian