Przekierowania 301 a 302: kiedy używać każdego z nich

TL;DR: Genuinely trwałe przekierowanie dostaje 301, a faktycznie tymczasowe dostaje 302. Źle dobierz — a Google zindeksuje niewłaściwy URL. Użyj poniższej tabeli decyzyjnej, a potem przeczytaj sekcję o canonicalizacji, jeśli chcesz zrozumieć mechanizm.

Odpowiedź w 30 sekund (tabela decyzyjna)

Zanim cokolwiek: oto mapa „scenariusz → kod”. Jeśli się spieszysz, to ten artykuł.

Jeśli zastanawiasz się, czy coś jest „wystarczająco trwałe” na 301, to najpewniej jest. Liczy się to, czy zamierzasz utrzymywać URL docelowy długoterminowo — jeśli masz pewność, że tak będzie, użyj 301.

Co tak naprawdę oznacza przekierowanie

Kiedy przeglądarka lub crawler żąda URL-a, serwer może odpowiedzieć kodem statusu z rodziny 3xx zamiast treści strony. Ten kod mówi wprost: „Zasób, którego szukasz, jest gdzie indziej”. Nagłówek Location w odpowiedzi wskazuje klientowi, dokąd przejść dalej.

Rodzina 3xx obejmuje kilka wariantów: 301 (Moved Permanently), 302 (Found / Moved Temporarily), 303 (See Other), 307 (Temporary Redirect), 308 (Permanent Redirect) i jeszcze kilka innych. Z perspektywy SEO liczą się 301, 302, 307 i 308. Reszta to bardziej przypadki brzegowe.

301: co „trwałe” mówi Google

301 to sygnał zarówno dla przeglądarki, jak i dla pipeline’u indeksowania, że stary URL znika bezpowrotnie. Dokumentacja Google mówi to wprost: „Jeśli musisz zmienić URL strony tak, jak jest wyświetlana w wynikach wyszukiwania, zalecamy korzystanie z trwałego przekierowania po stronie serwera, kiedy tylko to możliwe”.

Pipeline indeksowania traktuje 301 jako sygnał kanoniczny. Google podąża za przekierowaniem, a potem oznacza URL docelowy jako ten, który ma zostać w indeksie. Z czasem stary URL przestaje pojawiać się w wynikach wyszukiwania, a na jego miejsce wchodzi nowy. Ranking, zapisane w cache strony i skonsolidowane sygnały przestawiają się na adres docelowy.

Jedna rzecz, którą podkreślę z doświadczenia: trwałe znaczy trwałe. Google zaleca używanie trwałych przekierowań „gdy masz pewność, że nie zostaną cofnięte”. Jeśli ustawisz 301, a potem zdejmiesz go po sześciu miesiącach, nie cofnie się to „czysto” w sensie sygnałów. Googlebot musi ponownie odwiedzić stary URL i przetworzyć wszystko od nowa. Widziałem, jak klienci robili taki revert i potem przez tygodnie zastanawiali się, czemu ranking się rozjechał. Trzymaj 301 co najmniej rok, a najlepiej dłużej.

302: tymczasowa zmiana i pułapka konsolidacji

302 mówi Google: zachowaj oryginalny URL w indeksie — ta zmiana jest tymczasowa. Zalecenia Google są jednoznaczne: „Jeśli chcesz tylko czasowo odesłać użytkowników na inną stronę, użyj tymczasowego przekierowania”.

Googlebot podąża za 302 dokładnie tak samo jak za 301. Różnica pojawia się później w pipeline’ie indeksowania. Przy przekierowaniu tymczasowym Google nie traktuje URL-a docelowego jako kanonicznego. Oryginalny URL zostaje w indeksie jako ten zindeksowany.

Na stronie serwisowej w trybie utrzymania albo w teście A/B to dokładnie taki efekt, jakiego chcesz.

Pułapka polega na użyciu 302 dla ruchu „na stałe”, bo ktoś nie był pewny albo uznał, że „łatwiej będzie to zmienić później”. Google czasem potrafi zreinterpretować długowieczne 302 jako 301, ale nie należy na tym polegać. Widziałem serwisy, które trzymały 302 przez miesiące po migracji domeny i dopiero potem okazywało się, że Google nigdy w pełni nie zindeksowało nowych URL-i. Nie licz na heurystyki Google — bądź precyzyjny.

Mit o „link equity” (i co naprawdę się różni)

Problem polega na tym, że prawie każdy artykuł na ten temat pomija kluczową rzecz: przekierowania 302 nie rozszczelniają link equity.

W 2016 Gary Illyes, Google Webmaster Trends Analyst, napisał to wprost: „30x redirects don't lose PageRank anymore.” Obejmuje to 301, 302 i każdy inny 3xx. Wszystkie przekazują PageRank.

John Mueller opisał mechanizm podczas Webmaster Hangout: „Możemy przekazać PageRank przez przekierowania 301 i 302. W praktyce polega to na tym, że używamy tych przekierowań, aby wybrać kanoniczny adres. Gdy wybierzemy kanoniczny, skupiamy wszystkie sygnały, które trafiały do tych URL-i, na URL kanoniczny.”

Przeczytaj to uważnie. To nie jest „rura”, która przenosi juice z jednego URL-a na drugi. To jest konsolidacja kanoniczna: sygnały kumulują się na tym URL-u, który Google uzna za kanoniczny. Typ przekierowania decyduje, który URL staje się kanoniczny.

Realne pytanie brzmi więc: który URL chcesz, aby Google traktowało jako kanoniczny? 301 sprawia, że docelowy jest kanoniczny. 302 zostawia kanoniczny po stronie źródła. To jest właściwa decyzja.

(Uwaga: uznanie equity nie jest natychmiastowe nawet przy 301. Google musi najpierw ponownie odwiedzić stary URL, a konsolidacja zachodzi w wielu cyklach crawlowania. Liczy się też kontekst — 301 z bloga o gotowaniu do landing page z oprogramowaniem nie „skonsoliduje się” tak gładko.)

301 vs 302 — szybkie porównanie

307 i 308: kody, o których prawie nikt nie mówi

307 i 308 istnieją, ponieważ 301 i 302 mają problem ze zmianą metody. Gdy przeglądarka podąża za 301 lub 302 w odpowiedzi na żądanie POST, specyfikacja Fetch pozwala przełączyć metodę na GET dla przekierowanego żądania. To może cicho zepsuć flow logowania, wysyłki w checkout i endpointy API.

307 rozwiązuje to dla przekierowań tymczasowych. MDN ujmuje to prosto: „307 gwarantuje, że klient nie zmieni metody ani treści żądania, gdy zostanie wykonane przekierowane żądanie. Przy 302 starsze klienty błędnie zmieniały metodę na GET”. Jeśli tymczasowo kierujesz formularz oparty o POST i potrzebujesz, żeby POST przetrwał — 307 jest właściwym kodem.

308 robi to samo dla przekierowań trwałych. Całkowicie zabrania zmiany metody, w przeciwieństwie do 301, gdzie klienci historycznie wymuszali przejście na GET. Jeśli na stałe przekierowujesz endpoint API, który otrzymuje dane w POST, 308 jest bardziej restrykcyjne i bezpieczniejsze.

Dla stron opartych wyłącznie o GET (czyli większości treści w sieci) 307 i 302 zachowują się identycznie, a 308 i 301 — identycznie. Różnica w metodzie ma znaczenie tylko wtedy, gdy w grę wchodzą treści POST lub PUT.

Jeszcze jedna rzecz warta wspomnienia: istnieją też przekierowania meta-refresh oraz oparte o JavaScript (window.location). Google traktuje meta-refresh z opóźnieniem 0 sekund jako trwałe (odpowiednik 301), a każde z innym opóźnieniem jako tymczasowe. Przekierowania oparte o JavaScript to inna historia: Google może je podążać, gdy wyrenderuje stronę, ale są wolniejsze w przetwarzaniu, mogą zostać pominięte podczas crawlów bez pełnego renderowania i nie niosą jawnego sygnału „trwałe/tymczasowe”. Zawsze lepszy wybór to przekierowania po stronie serwera.

Pułapka łańcuchów przekierowań

Łańcuchy tworzą się wtedy, gdy przekierujesz A na B, a później przekierujesz B na C — bez aktualizowania A. Użytkownik i Googlebot podążają z A do B do C zamiast iść bezpośrednio do C.

Każdy „skok” dodaje opóźnienie. Realna latencja użytkownika, mierzona w milisekundach, wpływa na Core Web Vitals na urządzeniach mobilnych. Każdy skok to też kolejny punkt awarii: jeśli którykolwiek URL w łańcuchu zwróci 404, wszystko za nim się psuje.

Dokumentacja Google o migracji serwisu mówi, że Googlebot może przejść nawet do 10 skoków w łańcuchu, ale jednocześnie zaleca przekierowanie bezpośrednio do finalnego adresu. John Mueller doprecyzował to mocniej: „Jedyna rzecz, na którą bym uważał, to to, żeby było mniej niż 5 skoków dla URL-i, które są często crawl’owane.” Googlebot toleruje do 10, zanim oznaczy to jako błąd; praktyczny limit Muellera to 5; prawdziwy cel to 1.

Łańcuchy potrafią narastać po cichu przez lata migracji. Serwis, który przeszedł z .com na .io, znów na .com, zmienił strukturę URL-ów dwa razy i robił testy A/B na stronach kategorii, może zgromadzić łańcuchy bez tego, żeby ktokolwiek to zauważył. (W audytach z SEOJuice najczęstsze znalezisko to nudny łańcuch z czterema skokami na URL-u o wysokim ruchu, który został po migracji, bo nikt nie zaktualizował przekierowań. Łańcuchy z kampanii i testów A/B są drugi najczęstszy winowajca — zwykle dlatego, że tymczasowe 302 nigdy nie zostały potem „posprzątane”.) Potem ktoś odpala crawl i odkrywa, że homepage jest trzy skoki w głąb.

Naprawa zawsze wygląda tak samo: zidentyfikuj docelowy finalny adres i zaktualizuj pierwszy redirect, żeby prowadził tam bezpośrednio. Zredukuj łańcuch. Nie czekaj, aż Google przejdzie przez pośrednie strony.

Pętle to przypadek patologiczny. A przekierowuje na B, B przekierowuje na A, a przeglądarka wyrzuca ERR_TOO_MANY_REDIRECTS. Zwykle to źle skonfigurowana reguła HTTPS albo przekierowanie w CMS-ie, które tworzy cykl. Narzędzia audytowe wyłapują to od razu.

Jak audytować przekierowania na Twojej stronie

Na co patrzeć:

• Zły kod do scenariusza: migracja trwała obsłużona jako 302 albo test tymczasowy, który stał się trwały bez aktualizacji na 301
• Łańcuchy: każda sekwencja A → B → C, w której można przejść z A prosto do C
• Pętle: dowolny cykl generujący ERR_TOO_MANY_REDIRECTS
• Przekierowania na 404: URL docelowy już nie istnieje — wysyłasz użytkowników i roboty w ślepy zaułek
• Nieaktualne 302: treści przeniesione miesiące lub lata temu, które nigdy nie zostały podniesione do trwałych przekierowań

Do szybkiej weryfikacji ręcznej curl -I https://yourdomain.com/old-url pokazuje kod statusu i nagłówek Location bez ładowania całej strony. Narzędzia deweloperskie przeglądarki (zakładka Network, „Preserve log” włączone) pokażą pełną sekwencję przekierowań dla dowolnego URL-a. To jest dobre do spot-checków. Do systematycznego pokrycia potrzebujesz crawlera.

Audyt SEOJuice crawl’uje Twoją stronę i flaguje łańcuchy przekierowań, pętle, przekierowania z błędnym kodem oraz skoki do destynacji 4xx. To najszybszy sposób, żeby dostać pełny obraz bez ręcznego „curlowania” setek URL-i. Warto też sprawdzić: wszystkie URL-e z wysokim ruchem z Twojego audytu SEO hygiene. To zazwyczaj tam „zakopany” łańcuch realnie kosztuje.

Single-page applications wymagają tu dodatkowej uwagi. Routing po stronie JS może tworzyć zachowania podobne do przekierowań, których crawlery po stronie serwera nie zauważą w ogóle. Jeśli uruchamiasz stronę w React lub Next.js, zobacz notatki o obsłudze przekierowań w SPA. Przypadki brzegowe z window.location i routingiem po stronie klienta mieszają się z egzekucją JavaScript przez Google w sposób, którego nie widać na pierwszy rzut oka.

Najczęściej zadawane pytania

Czy przekierowanie 302 przekazuje link equity (wartość SEO)?

Tak. Google potwierdziło, że PageRank przepływa przez 301, 302 i wszystkie przekierowania 3xx. Gary Illyes stwierdził w 2016, że „30x redirects don't lose PageRank anymore”, a John Mueller wyjaśnił, że zarówno 301, jak i 302 przekazują sygnały poprzez konsolidację kanoniczną. Typ przekierowania decyduje o tym, który URL Google trzyma w indeksie — nie o tym, czy equity płynie.

Co jest lepsze dla SEO: 301 czy 302?

Żadne z nich nie jest „z definicji” lepsze. Właściwy kod zależy od tego, czy ruch jest trwały. Użyj 301, gdy URL docelowy jest tym, który ma być indeksowany w przyszłości. Użyj 302, gdy oryginalny URL powinien pozostać w indeksie i faktycznie zamierzasz go przywrócić. Źle dobrany kod nie „zabiera” link equity — tylko wprowadza do indeksu Google niewłaściwy URL.

Jak długo trzeba czekać, aż Google zacznie honorować 301?

Nie ma stałego terminu. Google musi ponownie zcrawlować stary URL, zanim przetworzy sygnał, co może zająć od kilku dni do kilku tygodni — zależnie od częstotliwości crawlowania. Trzymaj 301 aktywne co najmniej rok. Usunięcie go zbyt wcześnie cofa sygnał kanoniczny i będziesz musiał ponownie zlecić Googlebotowi crawl oraz przetworzenie wszystkiego od zera.

Czy zbyt wiele przekierowań może zaszkodzić rankingom?

Tak, ale pośrednio. Łańcuchy przekierowań dodają opóźnienia, marnują budżet crawl i wprowadzają punkty awarii. Google zaleca przekierowanie bezpośrednio do finalnego destination; praktyczna wskazówka Muellera to mniej niż 5 skoków dla URL-i często crawl’owanych. Efekt to suma: wolniejsze ładowanie strony, mniejsza efektywność crawlowania oraz ryzyko, że uszkodzony skok po drodze wywali całą sekwencję — a nie bezpośrednia kara rankingowa.

Powiązana lektura:

• Checklist do audytu SEO hygiene, żeby nie stracić ruchu
• Core Web Vitals 2026: zmiany w audycie, które realnie mają znaczenie
• SEO best practices dla aplikacji single-page

Zrób darmowy audyt SEO, aby znaleźć łańcuchy przekierowań, pętle, przekierowania z błędnym kodem oraz skoki do martwych stron na Twojej witrynie.