Join our community of websites already using SEOJuice to automate the boring SEO work.
See what our customers say and learn about sustainable SEO that drives long-term growth.
Explore the blog →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 |

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.
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.
301 to standardowy wybór dla zwykłego adresu URL z treścią, który został przeniesiony na stałe. Typowe przypadki to:
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.
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.
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 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 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).
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 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:
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.
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.
Ł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ę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ę).
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.
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ę.
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.
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:
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:
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ą.
| 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.
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.
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.
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ę.
Ł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.
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ą.
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.
no credit card required
No related articles found.