seojuice

Co to jest przekierowanie? Wyjaśnienie przekierowań (301 a 302)

Vadim Kravcenko
Vadim Kravcenko
· Updated · 9 min read

TL;DR: Przekierowanie oznacza, że jeden adres URL automatycznie przekierowuje użytkowników i wyszukiwarki na inny adres URL. Do trwałej zmiany użyj 301, a do tymczasowej 302. Przekierowania nie powodują „automatycznie” utraty PageRank, ale łańcuchy, pętle, błędne (niedziałające) docelowe adresy oraz przekierowania z nieadekwatną stroną główną nadal mogą wywołać realne problemy SEO i w zakresie użyteczności.

Przekierowanie Znaczenie Kiedy użyć Co Google zwykle indeksuje
301 Moved Permanently Strona, protokół, host lub domena zostały trwale zmienione Adres URL docelowy
302 Found Oryginalna strona ma wrócić Oryginalny adres URL
303 See Other Żądanie POST powinno kierować na osobną stronę wynikową poprzez GET Oryginalny adres URL, ponieważ przekierowanie jest tymczasowe
307 Temporary Redirect Zmiana jest tymczasowa i trzeba zachować metodę HTTP Oryginalny adres URL
308 Permanent Redirect Zmiana jest trwała i trzeba zachować metodę HTTP Adres URL docelowy
Redirect types: 301/308 permanent vs 302/307 temporary, and the mistakes to avoid.

Co oznacza przekierowywanie (redirecting)?

Przekierowanie to instrukcja, która mówi: „Ten adres URL został przeniesiony. Przejdź na ten adres URL zamiast niego.”

Technicznie: przeglądarka pobiera adres, a serwer może odpowiedzieć kodem statusu HTTP z zakresu 3xx oraz nagłówkiem Location zawierającym inny adres. Następnie przeglądarka automatycznie żąda docelowego adresu. Roboty wyszukiwarek mogą podążać za tą samą instrukcją.

W praktyce znaczenie przekierowania jest prostsze: stary adres URL nie wyświetla już własnej treści; przekazuje żądanie na nowy adres URL.

Przekierowania są potrzebne, ponieważ adresy URL się zmieniają. Strony są nadawane od nowa (renamowane), produkty są usuwane, serwisy przechodzą z HTTP na HTTPS, zachodzące na siebie artykuły są konsolidowane, a domeny są zastępowane. Bez przekierowania ktoś, kto wejdzie na stary adres, zwykle trafi na 404. Linki zwrotne nadal wskazują opuszczony adres, a Google nie dostaje jawnej instrukcji routingu, która łączy starą stronę z jej zamiennikiem.

Zrobiliśmy to „po bożemu” bezpośrednio wtedy, gdy Lida i ja migrowaliśmy SEOJuice z seojuice.io na seojuice.com w styczniu 2026. Migracja domeny sprawia, że cel przekierowań jest wyjątkowo czytelny: każda stara ścieżka musi mieć przemyślane miejsce docelowe, a nie tylko regułę, która gdzieś „sensownie” przenosi domenę. Przy dwuosobowym zespole nie było komu delegować rozumowania; mapę przekierowań trzeba było potraktować jako część samej migracji (a nie jako zadanie administracyjne po niej).

Ta różnica ma znaczenie. Przekierowanie starego artykułu na jego odpowiednik w nowej domenie zachowuje trasę. Przekierowanie wszystkich starych adresów na nową stronę główną jedynie maskuje brakujące trasy.

301 vs 302: trwałość jest naprawdę tą decyzją

Różnica między 301 a 302 nie polega na tym, że jedna jest „przyjazna SEO”, a druga zła. Każdy kod komunikuje inne oczekiwanie co do tego, co wydarzy się dalej.

Przekierowanie 301 oznacza, że przeniesienie jest trwałe. Przekierowanie 302 oznacza, że przeniesienie jest tymczasowe i oczekuje się, że oryginalny adres URL wróci. Google obsłuży oba sygnały, ale nie interpretuje ich kanonicznego charakteru w identyczny sposób.

„Googlebot podąża za przekierowaniem, a potok indeksowania używa przekierowania jako sygnału, że docelowy adres przekierowania powinien być kanoniczny.”

W przypadku przekierowań tymczasowych: „Googlebot podąża za przekierowaniem, ale potok indeksowania nie używa przekierowania jako sygnału, że docelowy adres przekierowania powinien być kanoniczny.”

To są własne opisy Google Search Central z dokumentacji Redirects and Google Search.

Przetłumaczone na praktyczne SEO: trwałe przekierowanie prosi Google, aby zastąpiło w indeksie stary adres URL adresem docelowym. Tymczasowe przekierowanie kieruje użytkowników do docelowego miejsca, zwykle pozostawiając oryginalny adres URL jako kanoniczny. Jeśli zamieszanie dotyczy kanonizacji, nasz poradnik jak działa indeksowanie w Google wyjaśnia, jak łączą się ze sobą: crawling, wybór kanonicznego adresu i indeksowanie.

Użyj 301 dla trwałych zmian adresów URL

301 to standardowy wybór dla zwykłego adresu URL z treścią, który został przeniesiony na stałe. Typowe przypadki to:

  • Zmiana nazwy strony lub modyfikacja jej slug-a w adresie URL
  • Przejście z HTTP na HTTPS
  • Ujednolicenie wersji na www albo bez www
  • Przeniesienie na inną domenę
  • Konsolidacja zduplikowanych lub częściowo pokrywających się stron
  • Zamiana starej strony na realnie równoważnego następcę

Google zaleca stosowanie trwałego przekierowania po stronie serwera zawsze, gdy jest to możliwe, jeśli adres URL musi się zmienić w wynikach wyszukiwania. Google nazywa to najlepszym sposobem, aby ludzie i Google Search trafili na właściwą stronę.

Oto ten sam pojedynczy trwały redirect w dwóch najczęstszych serwerach WWW:

# Nginx — przekieruj jeden stary URL na nowy
location = /old-page/ {
    return 301 https://example.com/new-page/;
}

# Apache (.htaccess) — analogiczna reguła w jednym wierszu
Redirect 301 /old-page/ https://example.com/new-page/

Słowo „równoważny” robi tu robotę. Usunięty produkt nie staje się automatycznie równoważny Twojej stronie głównej tylko dlatego, że oba adresy URL należą do tej samej firmy.

Użyj 302, gdy oryginalny adres URL wraca

302 pasuje do strony serwisowej w trakcie krótkich prac, testu, tymczasowego przejęcia sezonowej strony albo routingu, który zamierzasz odwrócić. Komunikuje Google, że miejsce docelowe nie ma stać się trwałym zamiennikiem.

Jeśli strona została przeniesiona „na dobre”, ale pozostaje za 302, Google może nadal indeksować stary adres. Przekierowanie może wyglądać w przeglądarce całkiem poprawnie, a jednocześnie komunikować błędną intencję indeksowania (przydatne przypomnienie: „to się ładuje” nie jest pełnym testem przekierowania).

Wybieraj w zależności od tego, czy planujesz odwrócić zmianę. Trwałe oznacza 301; tymczasowe oznacza 302. Nasze osobne porównanie przekierowań 301 vs 302 omawia też mniej oczywiste przypadki migracji i kanonizacji.

A co z przekierowaniami 303, 307 i 308?

Większość serwisów redakcyjnych i marketingowych może używać przez lata przekierowań 301 i 302 bez potrzeby sięgania po pozostałe kody. Różnice stają się istotne w okolicach formularzy, API i innych żądań niezwiązanych z GET.

Jak opisano w przewodniku po przekierowaniach HTTP w MDN Web Docs: 301 i 302 niosą w historii pewną niejednoznaczność dotyczącą metod żądania. Niektóre klienty mogą zmienić POST na GET podczas podążania za przekierowaniem.

Taki scenariusz często jest nieszkodliwy dla zwykłego wyświetlenia strony. Problem pojawia się wtedy, gdy endpoint oczekuje treści żądania.

307 zachowuje żądanie tymczasowo

307 Temporary Redirect wyraża tę samą tymczasową intencję co 302, ale gwarantuje zachowanie metody HTTP i treści (body). POST pozostaje POST-em po przekierowaniu.

308 zachowuje żądanie na stałe

308 Permanent Redirect to odpowiednik zachowujący metodę dla 301. MDN wyjaśnia, że „308 zostało stworzone, aby usunąć niejednoznaczność zachowania przy użyciu metod innych niż GET”.

Dla zwykłej strony z treścią wywoływanej przez GET użytkownicy nie zobaczą dużej praktycznej różnicy między 301 a 308. To samo dotyczy 302 i 307. Zachowanie metody staje się kluczowe dla POST i PUT, formularzy oraz API (w tym momencie wolałbym włączyć osobę odpowiedzialną za backend, zamiast dobierać status na podstawie raportu SEO).

303 celowo zmienia żądanie na GET

Przekierowanie 303 See Other jest tymczasowe i celowo kieruje kolejne żądanie na GET. Typowy przypadek to odesłanie użytkownika z wysłanego formularza na osobną stronę potwierdzenia lub wynikową, aby zapobiec odświeżeniu strony, które ponownie wyśle oryginalny POST.

To najpierw zachowanie HTTP, a dopiero potem kwestia SEO. Nie komplikuj zwykłych przekierowań stron — nie rób z nich czegoś bardziej egzotycznego niż trzeba.

Przekierowania po stronie serwera wygrywają z obejściami w przeglądarce

Przekierowania z użyciem statusów HTTP dzieją się po stronie serwera. Istnieją też dwa alternatywne rozwiązania po stronie klienta: HTML meta refresh oraz przekierowania w JavaScript.

Meta refresh działa po tym, jak dokument HTML zacznie się ładować. MDN zaleca ustawienie opóźnienia na zero ze względów dostępności i ostrzega, że zasady przekierowań w HTTP i w HTML, które nie są zsynchronizowane, mogą prowadzić do nieskończonej pętli albo „innych koszmarów”. Ten sposób sformułowania zapada w pamięć, bo problem jest realny: dwie niezależnie zarządzane warstwy routingu mogą zacząć ze sobą walczyć po pozornie rutynowej zmianie w CMS.

Przekierowanie w JavaScript zależy od tego, czy klient wykona kod JavaScript. Google Search Central podaje: „Używaj przekierowań w JavaScript tylko wtedy, gdy nie możesz zrobić przekierowania po stronie serwera ani meta refresh. Chociaż Google próbuje renderować każdy URL, który Googlebot zaindeksował, renderowanie może nie powieść z różnych powodów”.

Moja kolejność preferencji jest taka:

  1. Przekierowanie HTTP po stronie serwera z poprawnym statusem trwałym lub tymczasowym
  2. Meta refresh z opóźnieniem zerowym, jeśli nie masz dostępu do konfiguracji serwera
  3. Przekierowanie w JavaScript tylko wtedy, gdy żadna z powyższych opcji nie jest możliwa

Część hostingu statycznego i ograniczone platformy CMS nie udostępniają idealnej warstwy po stronie serwera. To ograniczenie jest realne. Mimo to, fakt, że przeglądarka w końcu dojdzie do celu, nie jest tym samym co czyste przekierowanie, które każdy klient potrafi interpretować spójnie.

Czy przekierowania tracą PageRank?

Stara zasada SEO głosiła, że każde przekierowanie traci stały procent „link juice”. Procenty wciąż krążą w obiegu, ale nie powinny napędzać decyzji wdrożeniowych. Nie ma dla nich oparcia w aktualnym stanowisku Google.

„Przekierowania 30x nie tracą już PageRanku.”

Tego stwierdzenia dokonał Gary Illyes z Google w 2016 roku, jak opisuje Search Engine Land. Sensowny wniosek jest wąski, ale ważny: samo pojawienie się 301, 302 lub innego przekierowania z zakresu 30x nie nakłada automatycznej kary za PageRank.

Nie wynika z tego jednak, że 301 i 302 są zamienne.

301 mówi Google, aby traktowało docelowy adres jako trwałą, kanoniczną zamianę. 302 zwykle pozostawia oryginalny adres URL jako kanoniczny, ponieważ przeniesienie jest tymczasowe. Obsługa PageRank i intencja kanonizacji są powiązane, ale to nie to samo pytanie.

Nie chciałbym też obiecywać, że migracja domeny zachowa każdy ranking bez wahań. Przekierowania niosą ważny sygnał, ale Google nadal musi ponownie crawlować adresy URL, przetwarzać kanoniki i aktualizować indeks. Czysty routing usuwa jeden duży obszar niejednoznaczności; nie „zamraża” wyników wyszukiwania w miejscu.

Błędy przekierowań, które realnie szkodzą

Łańcuchy przekierowań

Łańcuch przekierowań wysyła żądanie przez wiele adresów URL:

URL A → URL B → URL C → URL D

Oczywiście czyściej byłoby: URL A bezpośrednio na URL D. Jeśli B i C są nadal linkowane wewnętrznie, zaktualizuj te linki również na D.

Każdy kolejny „skok” dokłada następne żądanie, zużywa zasoby crawlera i tworzy kolejną regułę, która może się nie udać. Długie łańcuchy zwiększają też ryzyko, że docelowy adres nie zostanie osiągnięty w danym cyklu crawlowania. Powtarzane w tysiącach stron, to przestaje być „kosmetyczne ostrzeżenie” z audytu, a staje się realnym problemem z crawl budget.

Nie ma potrzeby przypisywać wymyślonego procentu straty PageRank do każdego skoku. Więcej żądań, wolniejszy routing, zmarnowane crawlowanie i dodatkowe punkty awarii — to wystarczające powody, aby skrócić łańcuch.

Pętle przekierowań

Pętla wysyła żądanie po okręgu, np. A → B → A. W końcu przeglądarki przerywają i pokazują błąd „too many redirects”. Treść staje się niedostępna zarówno dla użytkowników, jak i dla crawlerów.

Pętle powstają najczęściej z konfliktujących reguł: reguła dla HTTPS walczy z regułą dla hosta, reguła trailing-slash cofa inną zmianę, albo meta refresh nie zgadza się z tym, co robi serwer. Końcowy błąd przeglądarki zakrywa ścieżkę, więc sprawdzaj każdą odpowiedź zamiast wielokrotnie odświeżać stronę (albo, częściej niż bym chciał, czyścić cache i mieć nadzieję).

Przekierowywanie wszystkich usuniętych URL na stronę główną

To nie jest strategia „sprzątania”. Zamiast jasnej odpowiedzi „strony nie ma” podmieniasz ją na nieadekwatne miejsce docelowe.

Wytyczne Google dotyczące soft-404 wyjaśniają, że przekierowania na niepowiązane strony mogą być interpretowane jako soft 404. Przekieruj stary adres URL tylko wtedy, gdy istnieje realnie istotny zamiennik. Jeśli zamiennika nie ma, zwróć prawidłowe 404 albo 410.

Wycofany produkt może rozsądnie przekierowywać na bezpośredniego następcę albo — w niektórych przypadkach — na ściśle powiązaną kategorię. Nie powinien automatycznie wysyłać użytkowników na generyczną stronę główną, która nie odpowiada na ich zapytanie.

Warianty protokołu i hosta wymieszane ze sobą

Jeśli HTTP, HTTPS, wersje www i bez www wszystkie serwują tę samą treść, wiele adresów konkuruje o to, który jest „tym właściwym” dla tej strony. Wybierz jeden kanoniczny host i protokół, a potem na stałe przekieruj każdą alternatywę bezpośrednio na niego.

Przetestuj każdą kombinację. Reguła dla HTTP może działać poprawnie sama w sobie, a dopiero w połączeniu z regułą dla hosta dołożyć drugi skok albo utworzyć pętlę.

Przekierowania, które kończą się na błędzie

Przekierowanie nie jest „udane” tylko dlatego, że pierwsza odpowiedź ma 301. Docelowy adres końcowy musi zwracać działającą odpowiedź.

301 prowadzące do 404 nadal jest zepsute dla osoby, która weszła na przekierowanie. Przekierowanie kończące się na odpowiedzi z zakresu 500 też nie pomaga. Dlatego samo sprawdzenie początkowego kodu statusu omija istotną część całej ścieżki.

Jak znaleźć i naprawić problemy z przekierowaniami

Zacznij od crawlowania narzędziem typu Screaming Frog, Ahrefs Site Audit albo audytem w SEOJuice. Zcrawluj źródłowe adresy URL i śledź każdą trasę aż do finalnej odpowiedzi. Szukaj:

  • Łańcuchów przekierowań zawierających wiele skoków
  • Pętli przekierowań
  • Przekierowań kończących się odpowiedzią 4xx lub 5xx
  • Linków wewnętrznych, które nadal wskazują przekierowane adresy URL
  • Trwałych przeniesień wdrożonych przez tymczasowe przekierowania

Z tego, co widzimy na stronach analizowanych w SEOJuice, linki wewnętrzne wskazujące już przekierowane adresy URL wymagają większej uwagi niż zwykle dostają. Może się okazać, że przekierowanie działa, więc problem wygląda niegroźnie. Ale Twoja strona i tak wysyła każdego użytkownika i crawlera przez niepotrzebne dodatkowe żądanie, a przyszłe zmiany przekierowań mogą przerobić ten stary link wewnętrzny w element łańcucha.

To stało się szczególnie istotne podczas naszej migracji z .io na .com. Reguły na poziomie domeny mogą sprawić, że strona wygląda na „przeniesioną”, podczas gdy stare linki absolutne nadal są zakopane w stronach, szablonach lub zagnieżdżonych treściach strukturalnych. Działa globalne przekierowanie — linki są maskowane; dopiero crawl to odsłania.

Google Search Console pokazuje perspektywę Google. W raporcie indeksowania strony możesz zobaczyć statusy typu „Page with redirect” oraz „Redirect error”. Inspekcja URL pokazuje kanoniczny adres zadeklarowany przez użytkownika i wybrany przez Google — to pomaga, gdy Google nie zaakceptowało docelowego adresu, którego oczekiwałeś.

Dla pojedynczego podejrzanego adresu URL użyj panelu Network w narzędziach deweloperskich przeglądarki (DevTools). Sprawdzaj każdą odpowiedź i nagłówek Location aż do załadowania finalnej strony lub do momentu, gdy trasa się nie powiedzie. To jest szybsze niż uruchamianie pełnego crawlowania, gdy debugujesz jedną regułę.

Naprawy priorytetyzuj w tej kolejności:

  1. Usuwaj pętle, bo czynią strony niedostępnymi.
  2. Napraw przekierowania kończące się odpowiedzią 4xx lub 5xx.
  3. Okracaj łańcuchy, aby stare adresy URL wskazywały bezpośrednio na finalne cele.
  4. Zamieniaj przekierowania nieadekwatne na właściwe cele albo prawdziwe 404/410.
  5. Aktualizuj linki wewnętrzne, aby omijały przekierowania.
  6. Potwierdź, że trwałe przeniesienia używają trwałych statusów.

Audyty w SEOJuice, np. SEO audit, wykrywają łańcuchy przekierowań, błędne przekierowania oraz linki wewnętrzne wskazujące przekierowane adresy URL — dostajesz listę rzeczy do zrobienia. To narzędzie nie przepisuje za Ciebie reguł w nginx, .htaccess, CDN ani CMS; te zmiany i tak muszą trafić do infrastruktury, która steruje odpowiedzią.

Lista kontrolna przekierowań podczas migracji serwisu

Sprawdź Oczekiwany efekt
Każdy wartościowy stary adres URL jest zmapowany Każdy adres URL wskazuje realnie istotny zamiennik
Trwałe przeniesienia używają 301 lub 308 Adres docelowy otrzymuje trwały sygnał kanoniczny
Tymczasowe przeniesienia używają 302 lub 307 Oryginał pozostaje oczekiwanym kanonikiem
Przekierowania mają jeden skok Stary adres URL wskazuje bezpośrednio na finalny adres URL
Warianty protokołu i hosta są przetestowane Każdy wariant rozwiązuje się do jednej kanonicznej wersji bez pętli
Sprawdzone są docelowe strony końcowe Żadne przekierowanie nie kończy się na 4xx ani 5xx
Linki wewnętrzne są zaktualizowane Linki wskazują bezpośrednio na finalne adresy URL
Usunięte strony bez dopasowania są obsłużone czytelnie Zwracają 404 lub 410, a nie nieadekwatne przekierowanie

Traktuj przekierowania jak reguły routingu, a nie jak „magiczne” działanie SEO. Wybierz adekwatne miejsce docelowe, określ, czy przeniesienie jest trwałe, i usuń unikaną liczbę skoków. Większość decyzji o przekierowaniach staje się prosta, gdy te trzy kwestie są jednoznaczne.

Najczęściej zadawane pytania

Co oznacza „przekierowywanie” (redirecting)?

Przekierowywanie oznacza, że adres URL przestaje służyć własnej treści i zamiast tego przekierowuje użytkowników oraz wyszukiwarki na inny adres URL. Przekierowanie po stronie serwera zwykle zwraca kod HTTP 3xx wraz z adresem docelowym, o który przeglądarka prosi automatycznie.

Jaka jest różnica między przekierowaniem 301 a 302?

301 oznacza, że przeniesienie jest trwałe, co pozwala Google traktować docelowy adres jako kanoniczny. 302 oznacza, że przeniesienie jest tymczasowe, więc Google zwykle pozostawia oryginalny adres URL w indeksie. Użyj 301, jeśli stara strona nie wróci, i 302, jeśli wróci.

Czy przekierowania szkodzą SEO?

Poprawnie wdrożone przekierowania nie szkodzą SEO „z definicji”. Google rekomenduje trwałe przekierowania po stronie serwera w przypadku trwałych zmian, a Gary Illyes stwierdził, że przekierowania 30x nie tracą PageRanku. Problemy SEO pojawiają się przez łańcuchy, pętle, błędne docelowe adresy, nieadekwatne przekierowania oraz kody statusu, które komunikują złą intencję.

Co to jest łańcuch przekierowań?

Łańcuch przekierowań ma miejsce wtedy, gdy adres URL A przekierowuje na adres URL B, który z kolei przekierowuje na adres URL C. Powoduje to niepotrzebne żądania i pracę po stronie crawlowania. Napraw to tak, że ustawisz adres URL A, aby wskazywał bezpośrednio na adres URL C, oraz zaktualizujesz linki wewnętrzne, aby korzystały z finalnego adresu.

Co powoduje błąd „too many redirects”?

Pętle przekierowań powodują ten błąd. Dwie lub więcej reguł wysyła żądanie w kółko, często dlatego, że reguły dla HTTPS, www, trailing-slash, po stronie serwera albo meta-refresh są ze sobą sprzeczne. W końcu przeglądarka przestaje podążać za tą sekwencją.

Kiedy powinienem użyć przekierowania 307 lub 308?

Użyj 307 dla tymczasowego przeniesienia i 308 dla trwałego, jeśli trzeba zachować oryginalną metodę HTTP oraz treść żądania. Ma to największe znaczenie dla formularzy i zapytań do API używających metod takich jak POST lub PUT. Dla zwykłych stron z treścią wywoływanych przez GET nadal standardowym wyborem są 301 i 302.

SEOJuice
Stay visible everywhere
Get discovered across Google and AI platforms with research-based optimizations.
Works with any CMS
Automated Internal Links
On-Page SEO Optimizations
Get Started Free

no credit card required

More articles

No related articles found.