Przekierowania HTTP
Czym naprawdę jest przekierowanie HTTP (kod statusu 3xx oraz nagłówek Location), czym różnią się 301/302/303/307/308, jak je wdrażać oraz kiedy wybrać przekierowanie zamiast tagu kanonicznego — centrum podklastra przekierowań.
1 sygnał dowodowy na tej stronie
- Powiązane działające narzędzie HTTP Status & Redirect Checker
Przekierowanie jest odpowiedzią HTTP z kodem statusu 3xx i nagłówkiem Location, która wysyła przeglądarki i roboty ze starego adresu URL pod nowy. Google dzieli je na dwie grupy: stałe 301/308 przekazują mocny sygnał kanonikalizacji, więc sygnały rankingowe konsolidują się pod celem; tymczasowe 302/303/307 przekazują sygnał słaby. W każdej grupie kody różnią się zachowaniem metody HTTP — 307/308 ją zachowują, a 301/302 mogą zmienić POST na GET. Przekierowania wdrażaj po stronie serwera (.htaccess/nginx), na CDN-ie lub brzegu sieci albo przez wtyczkę CMS; JavaScript i meta refresh są słabsze, bo zależą od renderowania. Przekierowanie nie jest tagiem kanonicznym: przekieruj, gdy w przyszłości powinien istnieć tylko jeden URL; ustaw canonical, gdy kilka wersji musi pozostać aktywnych. To centrum mapuje cały krajobraz i prowadzi do szczegółowych artykułów.
TL;DR — Przekierowanie wysyła każdego, kto żąda starego adresu URL, pod nowy. Najpopularniejszy rodzaj to 301 („przeniesiono na stałe”), który informuje Google, że sygnały rankingowe starej strony powinny przejść na nowy URL. 302 oznacza zmianę „tymczasową”. Wybierz prawidłowo między wariantem stałym a tymczasowym i preferuj prawdziwe przekierowania serwerowe zamiast JavaScript — to pokrywa 90% tego, co najważniejsze.
Czym jest przekierowanie
Przekierowania HTTP wykorzystują odpowiedzi 3xx oraz pole Location, aby skierować klienta pod inny URI. Dowód potwierdzający to twierdzenie Primary standard or official documentation supporting the adjacent article claim. Zakres: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Poziom ufności: wysoki · Zweryfikowano: RFC 9110: Redirection Google traktuje stałe przekierowania jako mocne sygnały kanoniczne, lecz nie gwarantuje zindeksowania celu. Dowód potwierdzający to twierdzenie Primary standard or official documentation supporting the adjacent article claim. Zakres: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Poziom ufności: wysoki · Zweryfikowano: Google: Redirects and Search
Gdy strona się przenosi, nie chcesz, aby odwiedzający ani Google trafiali pod starym adresem w ślepy zaułek. Przekierowanie to instrukcja, która automatycznie przesyła ich pod nowy adres. Ktoś klika stary link, a serwer po cichu przekazuje mu nową stronę.
Od strony technicznej przekierowanie jest szczególnym rodzajem odpowiedzi serwera: kodem
statusu z zakresu 300s (najczęściej 301 lub 302) oraz nagłówkiem Location,
który mówi: „zamiast tego przejdź tutaj”. Nie musisz znać tej instalacji od podszewki, aby
użyć przekierowania — ale właśnie dlatego jest ono niezawodne w sposób, w jaki komunikat
„ta strona została przeniesiona, kliknij tutaj” nie jest.
Dwa najważniejsze rodzaje
- 301 — przeniesiono na stałe. Używaj go, gdy zmiana jest trwała. Informuje wyszukiwarki, że strona ma nowy dom, dzięki czemu pozycje i linki starej strony przechodzą na nowy URL. Po ten kod sięgniesz najczęściej.
- 302 — znaleziono (tymczasowo). Używaj go, gdy zmiana obowiązuje tylko teraz — przy krótkiej kampanii, teście A/B lub stronie, którą przywrócisz. Informuje Google, aby nie przenosiło sygnałów rankingowych, ponieważ zmiana nie jest trwała.
Istnieje jeszcze kilka kodów (303, 307, 308), ale w większości witryn praktyczna decyzja sprowadza się do pytania: czy przenosiny są stałe (301), czy tymczasowe (302)?
Jak skonfigurować przekierowanie
- Na serwerze — w pliku Apache
.htaccesslub regule konfiguracji nginx. To klasyczne rozwiązanie. - Przez wtyczkę CMS — w WordPressie wtyczka przekierowań zwykle po prostu edytuje za Ciebie
plik
.htaccess. - Na CDN-ie lub brzegu sieci — Cloudflare i podobne usługi pozwalają ustawić przekierowania, zanim żądanie dotrze do serwera.
Jeśli to możliwe, unikaj przekierowań JavaScript, w których skrypt wysyła przeglądarkę dalej. Google potrafi je respektować, ale dopiero po pomyślnym wyrenderowaniu strony — to dodatkowy krok, który czasem zawodzi — dlatego są wolniejsze i mniej niezawodne od prawdziwego przekierowania serwerowego.
Najczęstsze nieporozumienie
Przekierowanie to nie to samo co tag kanoniczny. Użyj przekierowania, gdy stary URL powinien przestać istnieć, a wszyscy mają trafiać pod nowy. Użyj tagu kanonicznego, gdy kilka adresów URL musi pozostać dostępnych, ale Google ma traktować jeden z nich jako wersję „główną” — na przykład na stronach produktów z parametrami śledzącymi. Przekierowanie = przeżywa jeden URL; canonical = przeżywa kilka, lecz jeden jest preferowany.
Chcesz poznać szczegóły protokołu, pełne porównanie 301/302/303/307/308, czas utrzymywania przekierowania oraz pułapki łańcuchów i pętli? Przejdź do karty Zaawansowane.
TL;DR — Przekierowanie jest odpowiedzią HTTP z kodem statusu 3xx i nagłówkiem
Location— najpierw protokół, potem SEO. Google sprowadza kody do dwóch grup kanonikalizacji: stałe (301/308) = mocny sygnał (sygnały konsolidują się pod celem), tymczasowe (302/303/307) = słaby sygnał (zwykle pozostają przy źródle, choć długo utrzymywane tymczasowe przekierowanie może zmienić interpretację). W każdej grupie 307 i 308 zachowują metodę HTTP i treść żądania; 301 i 302 mogą ich nie zachować. Wdrażaj po stronie serwera, na CDN-ie/brzegu sieci (to moja preferencja) lub przez wtyczkę CMS; przekierowania JS i opóźnione meta refresh są słabsze, bo zależą od renderowania. Jedno dobre przekierowanie nie traci PageRank — rzeczywiste ryzyka to łańcuchy (unikaj ich) i pętle (wyszukiwarki je ignorują). Utrzymuj przekierowania co najmniej rok. Przekierowanie nie jest tagiem kanonicznym.
Czym naprawdę jest przekierowanie na poziomie protokołu
Kody statusu przekierowań mają ustandaryzowane reguły obsługi metod. Dowód potwierdzający to twierdzenie Primary standard or official documentation supporting the adjacent article claim. Zakres: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Poziom ufności: wysoki · Zweryfikowano: RFC 9110: Redirection Wytyczne wyszukiwarek rozróżniają sygnały stałe i tymczasowe, zalecając przy przenosinach bezpośrednie przekierowania serwerowe. Dowód potwierdzający to twierdzenie Primary standard or official documentation supporting the adjacent article claim. Zakres: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Poziom ufności: wysoki · Zweryfikowano: Google: Redirects and Search
Większość tekstów SEO od razu przechodzi do stwierdzenia „301 oznacza przenosiny stałe”,
nie wyjaśniając, czym jest przekierowanie. Warto zacząć od podstaw, bo mechanizm wyjaśnia
wszystko, co dzieje się później. Według MDN:
“redirection is triggered by a server sending a special redirect response to a
request. Redirect responses have status codes that start with 3, and a Location
header holding the URL to redirect to.” (tłumaczenie) „przekierowanie zostaje wywołane, gdy
serwer wysyła specjalną odpowiedź na żądanie. Odpowiedzi przekierowujące mają kody statusu
zaczynające się od 3 oraz nagłówek Location zawierający docelowy URL”.
Przekierowanie składa się więc z dwóch elementów podróżujących razem: kodu statusu 3xx
(301, 302, 303, 307, 308…) i nagłówka Location wskazującego cel. Przeglądarka lub robot odczytuje
tę odpowiedź i ponownie wysyła żądanie pod URL z Location. Kod statusu niesie semantykę —
stałość lub tymczasowość oraz zachowanie metody — a Location jest adresem. Wszystko, co
interesuje specjalistę SEO, wynika z wyboru wysyłanego kodu 3xx.
Warstwę SEO nakładaną na ten mechanizm ująłem w artykule Ahrefs 11 rodzajów przekierowań i ich wpływ na SEO: “A redirect is a way to send people and bots to a new URL when they request the old URL, but the page has changed locations.” (tłumaczenie) „Przekierowanie to sposób wysłania ludzi i robotów pod nowy URL, gdy żądają starego, ale strona zmieniła adres”.
Dlaczego przekierowania mają znaczenie dla SEO
Dokumentacja Google o przekierowaniach ujmuje cel wprost: “Redirecting URLs is the practice of resolving an existing URL to a different one, effectively telling your visitors and Google Search that a page has a new location.” (tłumaczenie) „Przekierowywanie adresów URL polega na rozwiązywaniu istniejącego URL-a do innego, co w praktyce informuje odwiedzających i wyszukiwarkę Google, że strona ma nową lokalizację”. Skutek dla SEO dzieli się jasno według trwałości:
- Stałe przekierowania pokazują w wynikach wyszukiwania nowy cel.
- Tymczasowe przekierowania zachowują w wynikach stronę źródłową.
Istnieje też wymiar wartości linków. Google śledzi oba końce przekierowania: “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 URL, Google śledzi zarówno źródło przekierowania (stary URL), jak i jego cel (nowy URL). Jeden z nich będzie kanoniczny; wybór zależy od sygnałów, na przykład od tego, czy przekierowanie jest tymczasowe, czy stałe”. Stałe przekierowania konsolidują sygnały do przodu, pod nowym adresem; tymczasowe zwykle pozostawiają je przy starym.
Krajobraz przekierowań: 301, 302, 303, 307 i 308
Poniżej znajdziesz całą rodzinę w skrócie. Każdy kod ma w tym klastrze własne szczegółowe omówienie — zobacz sekcję „Co dalej”.
- 301 (Moved Permanently) — podstawowe stałe przekierowanie. Jest mocnym sygnałem kanonikalizacji, więc sygnały rankingowe konsolidują się pod celem. Dokumentacja Google dla robotów mówi: “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ą go jako mocnego sygnału, że cel powinien zostać przetworzony”.
- 302 (Found) — standardowe przekierowanie tymczasowe. Google podąża za nim, a “and Google systems use the redirect as a weak signal.” (tłumaczenie) „systemy Google używają przekierowania jako słabego sygnału”. Słabego, nie zerowego — wystarczająco długo utrzymywane 302 może zostać potraktowane jak 301.
- 303 (See Other) — wyjątek. Należy do grupy tymczasowej i stoi za wzorcem Post/Redirect/Get
(wysłanie formularza, a potem przejście do strony wynikowej przez
GET). W SEO pojawia się rzadko, a jego traktowanie jest naprawdę niejasne — jak zauważyłem, 303 ma nieokreślone traktowanie przez Google i zależnie od działania może zachowywać się jak 301 lub 302. - 307 (Temporary Redirect) — ma dla SEO takie samo znaczenie jak 302, ale zachowuje metodę HTTP i treść żądania. Dokumentacja Google mówi wprost, że 307 jest “equivalent to 302.” (tłumaczenie) „równoważne 302”. Kod 307 pojawia się też automatycznie w witrynach HTTPS używających HSTS.
- 308 (Permanent Redirect) — ma dla SEO takie samo znaczenie jak 301, ale zachowuje metodę i treść żądania. Według Google 308 jest “equivalent to 301.” (tłumaczenie) „kod 308 jest równoważny kodowi 301”.
Szczegół dotyczący zachowania metody — 307/308 zachowują pierwotną metodę i treść,
zaś 301/302 pozwalają klientowi zmienić po drodze POST na GET — nie zmienia sposobu,
w jaki Google ustala pozycje, ale ma duże znaczenie przy przekierowywaniu formularzy i wywołań API.
Google zaleca uważny wybór: “While Google treats these status codes the same way, keep in mind that
they’re semantically different. Use the status code that’s appropriate for the
redirect so other clients (for example, e-readers, other search engines) may benefit
from it.” (tłumaczenie) „Choć Google traktuje te kody statusu tak samo, pamiętaj, że semantycznie
się różnią. Użyj kodu odpowiedniego dla przekierowania, aby skorzystali na tym inni klienci, na
przykład czytniki elektroniczne i inne wyszukiwarki”. Pełne porównanie znajduje się w karcie Ściągi.
Wpływ przekierowań na skanowanie, indeksowanie i wartość linków
Dwie grupy, jedno rozróżnienie. Dokumentacja Google opisuje stałe przekierowania (301, 308,
natychmiastowe meta refresh i location w JS) jako przypadki, w których “the indexing
pipeline uses the redirect as a signal that the redirect target should be canonical,” (tłumaczenie)
„potok indeksowania używa przekierowania jako sygnału, że jego cel powinien być kanoniczny”,
a tymczasowe (302, 303, 307 i opóźnione meta refresh) jako przypadki, w których “the indexing pipeline
doesn’t use the redirect as a signal that the redirect target should be canonical.” (tłumaczenie)
„potok indeksowania nie używa przekierowania jako sygnału, że jego cel powinien być kanoniczny”.
Mit o PageRank umarł. Dawne twierdzenie, że przekierowania „tracą 10–15% wartości linków”, od lat jest nieaktualne. Gary Illyes z Google powiedział w 2016 roku, że “30x redirects don’t lose PageRank anymore,” (tłumaczenie) „przekierowania 30x nie tracą już PageRank”, a John Mueller zaznaczył, że nawet wtedy nie była to nowa informacja. Jedno poprawnie wdrożone przekierowanie przenosi zasadniczo całą wartość sygnałów strony. Koszty wynikają z łańcuchów i pętli, nie z samego istnienia przekierowania.
Jak długo utrzymywać przekierowanie. Wytyczne Google o migracji witryny zalecają: “keep the redirects for as long as possible, generally at least 1 year” (tłumaczenie) „utrzymuj przekierowania tak długo, jak to możliwe, na ogół co najmniej rok”, aby wszystkie sygnały mogły przejść na nowe URL-e. Gary Illyes zasugerował, że “after 1 y all signals had time to pass on from A to B.” (tłumaczenie) „po roku wszystkie sygnały miały czas przejść z A do B”. Sam to przetestowałem: usunąłem przekierowania 301 z czterech artykułów Ahrefs, do których przekierowywano starsze treści, i obserwowałem wynik. Nastąpił “a clear drop in referring domains after I did this,” (tłumaczenie) „wyraźny spadek liczby domen odsyłających”, ale “not much drop in traffic to these posts.” (tłumaczenie) „niewielki spadek ruchu do tych artykułów”. Mój uczciwy wniosek: “I’m not willing to conclusively say that permanent redirects pass value even after one year, but what Gary said seems to mostly hold true.” (tłumaczenie) „Nie chcę kategorycznie twierdzić, że stałe przekierowania przekazują wartość nawet po roku, ale słowa Gary’ego wydają się w większości trafne”. Bezpieczna reguła nadal brzmi: nie usuwaj starych przekierowań bez namysłu.
Łańcuchy i pętle przekierowań
- Łańcuch przekierowań ma więcej niż jeden skok między żądanym adresem a ostatecznym celem (strona 1 → strona 2 → strona 3). Google podąża za maksymalnie 10 skokami: “By default, Google’s crawlers follow up to 10 redirect hops” (tłumaczenie) „Domyślnie roboty Google podążają za maksymalnie 10 skokami przekierowań”. Aktualne wytyczne dotyczące migracji zalecają jednak unikać łańcuchów, a gdy są nieuniknione — ograniczyć je do najwyżej 3 i mniej niż 5 skoków. Dziesięć to pułap robota; 3–5 to wskazówka praktyczna, nie sprzeczny limit. Łańcuchy zwiększają opóźnienie, marnują budżet indeksowania i zaciemniają analitykę.
- Pętla przekierowań to łańcuch, który zjada własny ogon — URL przekierowuje do siebie albo do wcześniejszego adresu w łańcuchu — więc nigdy się nie kończy. Przeglądarki zgłaszają błąd „zbyt wiele przekierowań”, a wyszukiwarki po prostu rezygnują. John Mueller ujął to tak: “a redirect loop is a URL that doesn’t work, so it’s essentially a broken link. We ignore these for search.” (tłumaczenie) „pętla przekierowań to niedziałający URL, czyli w istocie uszkodzony link. Ignorujemy je w wyszukiwarce”. Pętle więżą też roboty i marnują zasoby serwera.
Za dobrze znaną liczbą pięciu skoków stoją również historyczne wypowiedzi przedstawiciela Google. W spotkaniu dla webmasterów z 2014 roku, od 46:03 John Mueller opisał Googlebota podążającego za maksymalnie pięcioma przekierowaniami w jednym skanowaniu i kontynuującego pozostałe podczas następnego. W 2020 roku osobno opisał Google jako podążające za maksymalnie pięcioma skokami na jedną próbę skanowania. Te historyczne wypowiedzi wyjaśniają pochodzenie liczby, lecz nie nadpisują obecnej dokumentacji ani nie gwarantują, że każdy długi łańcuch zostanie wznowiony według określonego harmonogramu.
Moja niezależna obserwacja praktyczna jest taka, że Google często wraca do dłuższych łańcuchów, a około pięciu skoków traktuję jako próg priorytetu naprawy. To ocena operacyjna oparta na moich obserwacjach, nie limit platformy Google. Gdy kontrolujesz przekierowania, celem nadal powinien być jeden bezpośredni skok.
Oba problemy mają poniżej własne szczegółowe artykuły.
Jak wdrażać przekierowania
Nie ma jednego „właściwego” miejsca na przekierowanie — wybierz to, które potrafisz utrzymać:
- Konfiguracja po stronie serwera. Plik Apache
.htaccess, reguły nginx lub skrypty serwerowe. To domyślne i najbardziej niezawodne rozwiązanie dla większości witryn. W WordPressie “most WordPress installs will be running Apache and the plugins used for redirecting will actually be editing a website’s.htaccessfile” (tłumaczenie) „większość instalacji WordPressa działa na Apache, a wtyczki do przekierowań w praktyce edytują plik .htaccess witryny” — wtyczka jest jedynie wygodniejszym interfejsem. - CDN / brzeg sieci. Reguły Cloudflare, edge workers i podobne mechanizmy działają, zanim żądanie dotrze do serwera źródłowego. Sam preferuję takie rozwiązanie: “I typically prefer to have redirects on the edge (CDN-level) over having them on the server.” (tłumaczenie) „Zwykle wolę umieszczać przekierowania na brzegu sieci, na poziomie CDN, niż na serwerze”. Większości osób “always recommend going with what is easiest for you to implement. For many people that is server-level redirects.” (tłumaczenie) „zawsze zalecam jednak wybór rozwiązania najłatwiejszego do wdrożenia. Dla wielu osób są nim przekierowania serwerowe”.
- Po stronie klienta: meta refresh. Tag
<meta http-equiv="refresh">. Natychmiastowe meta refresh (0 sekund) Google odczytuje jako stałe, a opóźnione jako tymczasowe. Jest wolniejsze i mniej eleganckie od przekierowania serwerowego, lecz czasem stanowi jedyną dostępną dźwignię. - Po stronie klienta: JavaScript. Skrypt ustawia
window.location. Google potrafi go respektować, ale tylko po udanym renderowaniu — to osobny etap potoku, który czasem zawodzi. Google radzi: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (tłumaczenie) „Używaj przekierowań JavaScript tylko wtedy, gdy nie możesz zastosować przekierowań serwerowych ani meta refresh”. Zalecana przeze mnie kolejność stałych przekierowań odzwierciedla tę drabinę niezawodności: 308 / 301 → meta refresh 0 → JavaScript → crypto.
Przekierowanie a tag kanoniczny
Te mechanizmy rozwiązują różne problemy, choć są nieustannie mylone.
- Przekierowanie — stosuj, gdy stary URL powinien całkowicie przestać zwracać własną treść. W przyszłości powinien istnieć tylko jeden URL. Stary adres przekazuje dalej i nie obsługuje już własnej strony.
- Tag kanoniczny — stosuj, gdy kilka adresów URL musi pozostać aktywnych i niezależnie dostępnych,
ale Google ma uznać jeden za wersję preferowaną. Pomyśl o wariantach nawigacji fasetowej, adresach
z parametrami śledzącymi lub wersjach do druku — wszystkie są dostępne i wszystkie wskazują główny
adres przez
rel=canonical.
Bing podobnie jasno opisuje ten podział we wpisie o zduplikowanej treści z grudnia 2025 roku: “Use 301 redirects to consolidate variants into a single preferred URL. Apply canonical tags when multiple versions must remain accessible.” (tłumaczenie) „Używaj przekierowań 301, aby skonsolidować warianty pod jednym preferowanym adresem URL. Stosuj tagi kanoniczne, gdy wiele wersji musi pozostać dostępnych”. Jeśli Google ignoruje wskazówkę kanoniczną, a naprawdę chcesz konsolidacji, możesz przejść do przekierowania — ale tylko wtedy, gdy zduplikowany URL nie musi nadal obsługiwać własnej treści.
Uwaga o Bing
Kierunkowo Bing zgadza się z Google: stałe przenosiny wymagają 301, a tymczasowe — 302. Fabrice Canel z Bing powiedział, że “preferable to use a 302 redirect if your destination URL may change within 2 days, else 301 is recommended” (tłumaczenie) „lepiej użyć przekierowania 302, jeśli docelowy URL może zmienić się w ciągu 2 dni; w przeciwnym razie zalecane jest 301”. Jego kolega Frédéric Dubut wyjaśnił, że “2 days” (tłumaczenie) „2 dni” nie stanowi twardego progu: “anytime a redirect is temporary… you should use 302s.” (tłumaczenie) „za każdym razem, gdy przekierowanie jest tymczasowe, należy użyć 302”. To ten sam model myślowy, tylko opisany przez przewidywany czas zmiany celu.
Co dalej: podklaster przekierowań
Ten artykuł jest mapą. Każdy z poniższych tematów ma własne szczegółowe omówienie zagnieżdżone pod tym centrum i widoczne na pasku bocznym:
Poszczególne kody przekierowań
- Przekierowanie 301 — podstawowy kod stały: jak konsoliduje sygnały pod celem i kiedy go użyć.
- Przekierowanie 302 — standardowy kod tymczasowy, dlaczego stanowi sygnał słaby (nie zerowy) i jak może z czasem zacząć zachowywać się jak 301.
- Przekierowanie 303 (See Other) — kod Post/Redirect/Get, przyczyna jego rzadkości w SEO oraz powód, dla którego traktowanie przez Google pozostaje naprawdę nieokreślone.
- Przekierowanie tymczasowe 307 — to samo znaczenie dla SEO co 302, ale ścisłe zachowanie metody HTTP; miejsca występowania, takie jak HSTS oraz przekierowania formularzy i API.
- Przekierowanie stałe 308 — to samo znaczenie dla SEO co 301, ale ścisłe zachowanie metody HTTP i treści żądania.
Bezpośrednie porównania
- Przekierowanie 301 a 302 — stałe kontra tymczasowe, konsolidacja sygnałów do przodu lub wstecz oraz wybór odpowiedniego kodu.
- Przekierowanie 301 a 308 — to samo znaczenie dla SEO, lecz 308 zachowuje metodę HTTP i treść żądania.
- Przekierowanie 302 a 307 — taki sam podział po stronie tymczasowej: jednakowe dla SEO, lecz 307 zachowuje metodę i treść formularzy oraz wywołań API.
Wdrożenia po stronie klienta
- Przekierowania JavaScript — dlaczego są najsłabszą opcją, jak potok renderowania Google traktuje je inaczej niż serwerowe 301 i kiedy stanowią dopuszczalną ostateczność.
- Przekierowanie meta refresh — natychmiastowe i opóźnione odświeżenia, pozycja między przekierowaniem serwerowym a JavaScript w kolejności preferencji Google oraz powody, dla których jest odradzane.
Pułapki
- Łańcuchy przekierowań — dlaczego należy kierować prosto do docelowego URL-a, na czym polega limit 10 skoków i jak łańcuchy marnują budżet indeksowania.
- Pętle przekierowań — przekierowanie, które nigdy się nie kończy, powody jego ignorowania przez wyszukiwarki i sposób przerwania cyklu.
W Google Search Console
- Strona z przekierowaniem — co oznacza ten stan indeksowania, dlaczego jest normalny i nie stanowi błędu oraz które rzadkie przypadki wymagają działania.
- Błąd przekierowania — cztery przyczyny według Google: zbyt długi łańcuch, pętla, maksymalna długość URL-a oraz zły lub pusty URL; różnica wobec normalnego stanu „Strona z przekierowaniem”.
Pełny obraz kodów statusu HTTP, w którym mieści się ten podklaster — rodziny 2xx/3xx/4xx/5xx i kody inne niż przekierowania — znajdziesz w indeksie /technical-seo/http-status-codes/.
Podsumowanie AI
Skrócona wersja karty Zaawansowane:
- Przekierowanie = kod statusu 3xx + nagłówek
Location. Kod niesie semantykę (stałe/tymczasowe, zachowanie metody lub jego brak), aLocationwskazuje cel. Najpierw protokół, potem SEO. - Dwie grupy kanonikalizacji: stałe 301/308 = mocny sygnał (sygnały konsolidują się pod nowym URL-em); tymczasowe 302/303/307 = słaby sygnał (sygnały zwykle zostają przy starym, choć długo utrzymywany kod tymczasowy może zmienić interpretację).
- W obrębie każdej grupy: 307/308 zachowują metodę HTTP i treść żądania; 301/302 mogą ich nie zachować. Dla pozycji nie ma różnicy, lecz ma ona znaczenie dla formularzy i API.
- 303 jest wyjątkiem — to rzadki w SEO kod Post/Redirect/Get o naprawdę nieokreślonym traktowaniu przez Google.
- Mit o PageRank umarł: jedno poprawne przekierowanie nie traci wartości (Illyes, 2016). Koszt tworzą łańcuchy (Google podąża za maksymalnie 10 skokami, ale zaleca ich unikanie) i pętle (wyszukiwarki ignorują je jako uszkodzone linki).
- Utrzymuj przekierowania ≥ 1 rok. Własny test Patricka po usunięciu rocznych 301 wykazał spadek liczby domen odsyłających przy niewielkiej utracie ruchu — zasada „w większości się sprawdza”, więc nie usuwaj ich pochopnie.
- Wdrażaj po stronie serwera (.htaccess/nginx), na CDN-ie lub brzegu sieci (preferencja Patricka)
albo przez wtyczkę CMS, która zwykle tylko edytuje
.htaccess. JS i opóźnione meta refresh są słabsze, bo zależą od renderowania. - Przekierowanie ≠ canonical: przekieruj, gdy w przyszłości ma istnieć tylko jeden URL; ustaw canonical, gdy kilka pozostaje aktywnych, lecz jeden ma być preferowany.
Oficjalna dokumentacja
Dokumentacja źródłowa dotycząca przekierowań.
- Przekierowania a wyszukiwarka Google — dokument kanoniczny: podział na stałe i tymczasowe, tabele rodzajów przekierowań (301/308/302/303/307, meta refresh, JS, crypto) oraz koncepcja alternatywnego URL-a i wartości linków.
- Wpływ kodów statusu HTTP na roboty Google — zachowanie przy 3xx, limit 10 skoków i traktowanie 301/302/307/308 przez robota.
- Przenoszenie witryny ze zmianą adresów URL — unikanie łańcuchów oraz zalecenie utrzymywania przekierowań na ogół co najmniej rok.
- Konsolidowanie zduplikowanych adresów URL — dlaczego preferencja kanoniczna jest „wskazówką, nie regułą” i jak współdziała z przekierowaniami.
- Search Off the Record — odcinek zespołu Search Relations Google o rodzajach przekierowań (301 a 302, zastosowania 307/308 i łączenie domen).
Bing / Microsoft
- Czy zduplikowana treść szkodzi widoczności w SEO i wyszukiwaniu AI? — Fabrice Canel i Krishna Madhavan o użyciu 301 do konsolidacji wariantów oraz tagów kanonicznych, gdy wersje muszą pozostać aktywne.
Dokumentacja techniczna
- Przekierowania w HTTP — definicja MDN na poziomie protokołu (status 3xx + nagłówek
Location) oraz obsługa metody i treści żądania przez poszczególne kody.
Cytaty ze źródeł
Publiczne wypowiedzi Google, Bing i MDN. Każdy odsyłacz prowadzi bezpośrednio do cytowanego fragmentu strony źródłowej.
Google — cel przekierowań oraz podział na stałe i tymczasowe
- “Redirecting URLs is the practice of resolving an existing URL to a different one, effectively telling your visitors and Google Search that a page has a new location.” (tłumaczenie) „Przekierowywanie adresów URL polega na rozwiązywaniu istniejącego URL-a do innego, co w praktyce informuje odwiedzających i wyszukiwarkę Google, że strona ma nową lokalizację”. — dokumentacja Google Search Central. Przejdź do cytatu
- “we recommend that you use a permanent server-side redirect whenever possible.” (tłumaczenie) „zalecamy używanie stałego przekierowania po stronie serwera, gdy tylko jest to możliwe”. 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).” (tłumaczenie) „Gdy przekierowujesz URL, Google śledzi zarówno źródło przekierowania (stary URL), jak i jego cel (nowy URL)”. Przejdź do cytatu
- “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (tłumaczenie) „Używaj przekierowań JavaScript tylko wtedy, gdy nie możesz zastosować przekierowań serwerowych ani meta refresh”. Przejdź do cytatu
Google — traktowanie kodów przez roboty
- “Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (tłumaczenie) „Google wykonuje przekierowanie, a jego systemy uznają je za mocny sygnał, że należy przetworzyć docelowy adres”. (301) Przejdź do cytatu
- “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) „Roboty Google podążają za przekierowaniem, a systemy Google używają go jako słabego sygnału, że cel powinien zostać przetworzony”. (302) Przejdź do cytatu
- “While Google treats these status codes the same way, keep in mind that they’re semantically different.” (tłumaczenie) „Choć Google traktuje te kody statusu tak samo, pamiętaj, że semantycznie się różnią”. (307 ≈ 302, 308 ≈ 301) Przejdź do cytatu
- “By default, Google’s crawlers follow up to 10 redirect hops.” (tłumaczenie) „Domyślnie roboty Google podążają za maksymalnie 10 skokami przekierowań”. Przejdź do cytatu
Google — łańcuchy i czas utrzymywania przekierowań
- “Avoid chaining redirects.” (tłumaczenie) „Unikaj łączenia przekierowań w łańcuchy”. Przejdź do cytatu
- “ideally no more than 3 and fewer than 5.” (tłumaczenie) „najlepiej nie więcej niż 3 i mniej niż 5”. Przejdź do cytatu
- “Keep the redirects for as long as possible, generally at least 1 year.” (tłumaczenie) „Utrzymuj przekierowania tak długo, jak to możliwe, na ogół co najmniej rok”. Przejdź do cytatu
John Mueller, Google — historyczne wypowiedzi o pięciu skokach
- Podczas spotkania dla webmasterów w 2014 roku Mueller opisał Googlebota podążającego za maksymalnie pięcioma przekierowaniami w jednym skanowaniu i kontynuującego pozostałą część przy następnym skanowaniu. Oglądaj od 46:03
- “up to 5 hops in the chain per crawl attempt” (tłumaczenie) „maksymalnie 5 skoków w łańcuchu na jedną próbę skanowania”. (Komentarz na Reddicie z 2020 roku, przytoczony przez Search Engine Journal.) Przeczytaj relację
John Mueller, Google — pętle przekierowań
- “In general, a redirect loop is a URL that doesn’t work, so it’s essentially a broken link. We ignore these for search.” (tłumaczenie) „Ogólnie pętla przekierowań jest niedziałającym adresem URL, czyli zasadniczo uszkodzonym linkiem. Ignorujemy takie adresy w wyszukiwarce”. Przejdź do cytatu
Fabrice Canel, Microsoft Bing — czas wyboru między 301 a 302
- “When the future is uncertain… preferable to use a 302 redirect if your destination URL may change within 2 days, else 301 is recommended.” (tłumaczenie) „Gdy przyszłość jest niepewna, lepiej użyć przekierowania 302, jeśli docelowy URL może zmienić się w ciągu 2 dni; w przeciwnym razie zalecane jest 301”. Przejdź do cytatu
MDN — definicja na poziomie protokołu
- “redirection is triggered by a server sending a special redirect response to a request. Redirect responses have status codes that start with
3, and aLocationheader holding the URL to redirect to.” (tłumaczenie) „Serwer uruchamia przekierowanie, wysyłając specjalną odpowiedź na żądanie. Taka odpowiedź ma kod statusu zaczynający się od 3 i nagłówek Location z docelowym adresem URL”. Przeczytaj dokument
Lista kontrolna wdrożenia przekierowań
Przed uruchomieniem przekierowania i po nim:
- Kod pasuje do sytuacji — stałe przenosiny →
301/308; tymczasowe →302/307; zachowanie formularzaPOST→307/308. - Przekierowanie prowadzi do najlepiej dopasowanego URL-a, a nie masowo ze wszystkiego na stronę główną, co Google odczytuje jako soft 404.
- Prowadzi prosto do ostatecznego celu — bez łańcucha. Aktualizuj regułę źródłową, gdy sam cel zostanie później przeniesiony.
- Nie ma pętli — potwierdź, że cel nie przekierowuje z powrotem do łańcucha; uruchom
curl -ILdla starego URL-a i odczytaj całą sekwencję skoków. - Działa na poziomie serwera lub brzegu sieci, a nie przez JavaScript, jeśli jest to możliwe.
- Standaryzuje oczywiste warianty — www i bez www, HTTP i HTTPS, ukośnik końcowy oraz wielkość liter — do jednej postaci kanonicznej.
- Linki wewnętrzne prowadzą bezpośrednio do nowego URL-a, więc własna nawigacja nie polega na przekierowaniu.
- Pozostaje aktywne ≥ 1 rok zgodnie z wytycznymi Google — dłużej dla stron o wysokiej wartości; nie usuwaj starych przekierowań pochopnie.
- Istnieje ścieżka wycofania — przed uruchomieniem zapisz poprzedni cel lub treść starej strony, jeśli ją wycofujesz, aby szybko cofnąć błędny cel albo nieoczekiwany spadek.
- Wdrożenie zostało zweryfikowane — sprawdź kod i cel końcowy przez
curl -IL, kartę Network w przeglądarce lub crawler; zbiorczo szukaj łańcuchów i pętli.-Iwysyła żądanieHEAD— jeśli serwer może obsługiwaćHEADiGETinaczej, sprawdź ponownie zwykłymcurl -L(używaGET) albo trybem GET crawlera.
Rodzaje przekierowań — porównanie
Pięć kodów przekierowań 3xx w skrócie
| Kod | Nazwa | Stałe czy tymczasowe? | Czy zachowuje metodę HTTP? | Sygnał Google | Kiedy używać |
|---|---|---|---|---|---|
301 | Przeniesiono na stałe | Stałe | Może zmienić POST→GET | Mocny (konsoliduje do przodu) | Strona przeniosła się na stałe — domyślny kod stały |
302 | Znaleziono | Tymczasowe | Może zmienić POST→GET | Słaby (zwykle pozostaje przy starym URL-u) | Krótkotrwałe przenosiny — kampania, test A/B, tymczasowa zamiana |
303 | Zobacz inne | Tymczasowe | Nie (zawsze wymusza GET) | Słaby / nieokreślony | Post/Redirect/Get po wysłaniu formularza; rzadki w SEO |
307 | Przekierowanie tymczasowe | Tymczasowe | Tak | Słaby (= 302) | Tymczasowe przenosiny, gdy metoda i treść muszą zostać zachowane (formularze, API); występuje też przy HSTS |
308 | Przekierowanie stałe | Stałe | Tak | Mocny (= 301) | Stałe przenosiny, gdy metoda i treść muszą zostać zachowane |
Dwie kwestie, które naprawdę rozstrzygają wybór
- Stałe czy tymczasowe → określa sygnał kanonikalizacji (mocny lub słaby) oraz to, czy wyszukiwarka pokaże nowy, czy stary URL.
- Zachowanie metody → 307/308 zachowują pierwotną metodę i treść żądania; 301/302
pozwalają klientowi zamienić po drodze
POSTnaGET— to zgodność wsteczna dla starszych klientów opisana w Fetch Standard; 303 zawsze wymuszaGET. Nie ma znaczenia dla pozycji, lecz jest krytyczne dla formularzy i API — użyj307/308, gdy metoda i treść muszą przetrwać skok.
Metody wdrożenia przekierowania stałego — od najmocniejszej do najsłabszej
| Metoda | Gdzie działa | Niezawodność |
|---|---|---|
308 / 301 (serwer lub brzeg sieci) | Serwer / CDN | Najlepsza — bez zależności od renderowania |
Meta refresh 0 | Przeglądarka | Odczytywane jako stałe, lecz nieporęczne i wolne |
JavaScript (window.location) | Przeglądarka (po renderowaniu) | Słabsza — zależy od udanego renderowania |
| Crypto / wariant oparty tylko na linku | — | Wyłącznie ostateczność |
Najważniejsze fakty
- Jedno poprawne przekierowanie nie traci PageRank (Illyes, 2016).
- Google dokumentuje pułap 10 skoków, ale gdy łańcucha nie da się uniknąć, zaleca nie więcej niż 3 i mniej niż 5.
- Wypowiedzi Muellera z 2014 i 2020 roku opisują około pięciu skoków na jedno skanowanie; w 2014 roku wspomniał też o późniejszym kontynuowaniu reszty. Traktuj je jako historyczne, reprezentatywne wypowiedzi, nie obecną gwarancję harmonogramu.
- Utrzymuj przekierowania przez ≥ 1 rok.
- Dla Google 307 ≈ 302, a 308 ≈ 301 — różnica dotyczy zachowania metody.
- Przekierowanie = przeżywa tylko jeden URL; tag kanoniczny = przeżywa kilka, lecz jeden jest preferowany.
Zasoby warte czasu
Moje artykuły
- 11 rodzajów przekierowań i ich wpływ na SEO — pełne omówienie wszystkich rodzajów (301, 302, 303, 307, 308, meta refresh, JS, crypto, łańcuchy i pętle), które ten artykuł streszcza.
- Kody statusu HTTP i ich wpływ na SEO — miejsce przekierowań w pełnym obrazie kodów 1xx–5xx.
- Czy można usunąć przekierowania 301 po roku? Przetestowaliśmy to — mój kontrolowany test usunięcia rocznych przekierowań: spadła liczba domen odsyłających, ale ruch w dużej mierze się utrzymał.
- Przekierowania 301 a 302 w SEO: którego użyć? — bezpośrednie porównanie oraz mój eksperyment, w którym 302 skłoniło Google do zastąpienia starej domeny nową.
- Udana migracja witryny wymaga czegoś więcej niż listy kontrolnej — przekierowania w kontekście pełnej migracji witryny.
Z branży
- Przekierowania a wyszukiwarka Google (Google) — dokument kanoniczny stojący za większością tez tego centrum.
- Wpływ kodów statusu HTTP na roboty Google (Google) — traktowanie 3xx przez roboty i limit 10 skoków.
- Czy zduplikowana treść szkodzi widoczności w SEO i wyszukiwaniu AI? (Bing) — aktualne, publiczne stanowisko Microsoftu o przekierowaniach i tagach kanonicznych.
- Przekierowania w HTTP (MDN) — dokumentacja protokołu dotycząca kodów 3xx i obsługi metody oraz treści żądania.
- Google: przekierowania 301, 302 i inne 30x nie osłabiają już PageRank (Search Engine Land) — źródło korekty mitu o PageRank.
- Wyszukiwarka Google ignoruje pętle przekierowań (Search Engine Roundtable) — wypowiedź Muellera o pętlach jako „zasadniczo uszkodzonych linkach”.
- Bing: użyj 302, jeśli URL może zmienić się w dwa dni; w przeciwnym razie 301 (Search Engine Roundtable) — wskazówka Fabrice’a Canela o czasie wyboru 301 i 302.
- Poradnik przekierowań w SEO (Conductor Academy) — solidne konkurencyjne omówienie krajobrazu przekierowań.
Przekierowanie czy canonical? Zastosuj test przetrwania
Oba sygnały mogą wskazywać ten sam preferowany URL, lecz rozwiązują inne problemy.
Przekieruj, gdy źródłowy URL powinien przestać obsługiwać własną treść
Wybierz przekierowanie serwerowe, gdy użytkownicy i roboty żądające starego URL-a powinny
trafić gdzie indziej. Użyj kodu stałego (301 lub 308) przy trwałych przenosinach, a tymczasowego
(302, 303 lub 307), gdy źródło ma powrócić.
Typowe przypadki: zmieniony URL, scalona strona, migracja HTTP→HTTPS lub zmiana domeny. Cel musi być prawdziwym odpowiednikiem; masowe przekierowanie niepowiązanych starych adresów na stronę główną może zostać potraktowane jako soft 404.
Ustaw canonical, gdy wiele adresów URL musi pozostać dostępnych
Wybierz rel="canonical", gdy zduplikowane lub prawie zduplikowane warianty nadal muszą
zwracać własne odpowiedzi 200, ale jeden URL powinien być preferowany do indeksowania. Canonical
jest wskazówką, nie nawigacją: użytkownik pozostaje pod żądanym adresem. Dla Google również jest
wskazówką, nie regułą. Google mówi:
“indicating a canonical preference is a hint, not a rule,” (tłumaczenie) „wskazanie preferencji
kanonicznej jest wskazówką, nie regułą”, i na podstawie innych sygnałów może wybrać inną stronę.
Typowe przypadki: przydatne warianty sortowania i filtrowania, wersje syndykowane lub parametryczne albo duplikaty, których jeszcze nie można usunąć.
Brak odpowiedniego zamiennika
Nie wymuszaj przekierowania na niepowiązaną stronę tylko po to, aby mieć dokąd wysłać stary URL — przekierowanie zbiorcze lub na stronę główną dla treści bez prawdziwego następcy Google odczytuje jako soft 404. Brak rzeczywistego odpowiednika to sygnał, aby zamiast wymyślać cel podjąć świadomą decyzję o 404 lub 410.
Nie wysyłaj sprzecznych instrukcji
Jeśli URL A przekierowuje do B, adres B nie powinien wskazywać A jako kanonicznego. Uzgodnij linki wewnętrzne i mapy witryn z docelowym adresem, który ma przetrwać. Model jest prosty: przeżywa jeden URL → przekierowanie; kilka musi pozostać aktywnych → canonical.
Prompt: audyt mapy przekierowań pod kątem słabych celów
Wklej mapę przekierowań w formacie CSV z kolumnami: stary URL, proponowany cel, powód, stary tytuł lub temat, tytuł lub temat celu, zamierzona trwałość oraz — jeśli są dostępne — sygnały ruchu i linków.
Review this proposed redirect map for relevance and implementation risk.
For each row:
1. Classify the destination as strong equivalent, plausible but needs review,
irrelevant/catch-all, self-redirect, chain risk, loop risk, missing destination,
or insufficient evidence.
2. Explain the classification using only the supplied old/destination topics and
URL evidence.
3. Flag many-to-one mappings to a homepage or broad category for manual review.
4. Check whether the intended permanence matches the proposed 3xx code when a code
column is present.
5. Do not invent a replacement URL. If no equivalent is supplied, recommend manual
mapping or an intentional 404/410 decision.
Return a table with old URL, destination, verdict, evidence, recommended action, and
priority. End with a summary of repeated rule patterns that could create chains or
loops.
DATA:
[PASTE REDIRECT MAP HERE]Przed wdrożeniem mapy człowiek musi sprawdzić każdą ocenę równoważności treści.
Narzędzia do planowania i weryfikowania przekierowań
- Tester przekierowań — szybko sprawdza status końcowy, każdy skok i cel pojedynczego URL-a lub małej partii po wdrożeniu.
- Maper łańcuchów przekierowań — diagnozuje ścieżki wieloskokowe, pokazuje zmiany na każdym skoku i eksportuje spłaszczone reguły napraw dla popularnych platform serwerowych.
- Zbiorczy tester kodów statusu HTTP — weryfikuje większy zbiór przekierowań, filtruje wyniki tymczasowe i wieloskokowe oraz eksportuje dowody.
- Kreator mapy przekierowań — planuje mapowania starych adresów na nowe, jawnie zachowuje niedopasowane URL-e i listę do usunięcia kodem 410 oraz eksportuje reguły dopasowane do platform. Jego sugestie nadal wymagają sprawdzenia równoważności treści.
- DevTools przeglądarki → Network — pozwala zweryfikować kod 3xx odpowiedzi dokumentu i nagłówek
Locationpodczas odtwarzania zachowania charakterystycznego dla przeglądarki.
Sprawdź się: przekierowania HTTP
Pięć krótkich pytań o działanie przekierowań i sposób, w jaki traktują je wyszukiwarki. Wybierz odpowiedź na każde pytanie, a następnie sprawdź wynik.
Dziennik zmian
Zaktualizowano 21 wrz 2026.
Podsumowanie redakcyjne i zapisane szczegóły zmian.Podsumowanie
Zlokalizowano pozostałą angielską treść w historii źródłowej, zachowując dokładne cytaty z bezpośrednimi polskimi objaśnieniami.
Szczegóły zmian
-
Przetłumaczono siedem opisów zmian z dwóch rewizji źródłowych; dokładne frazy o limitach przekierowań, zachowaniu metod i zastrzeżeniu dotyczącym canonical zachowano wraz z natychmiastowymi polskimi tłumaczeniami, bez zmiany treści artykułu ani granic dowodowych.
Pełne porównanie jest niedostępne — dla tej wersji nie zarchiwizowano wcześniejszej migawki.
Zaktualizowano 8 wrz 2026.
Podsumowanie redakcyjne i zapisane szczegóły zmian.Podsumowanie
Utworzono zablokowany względem źródła kandydat zlokalizowanego artykułu; lokalna numeracja rewizji zaczyna się od 1.
Szczegóły zmian
-
Zmaterializowano przetłumaczone bloki z zachowaniem historii źródła jako pochodzenia treści.
Pełne porównanie jest niedostępne — dla tej wersji nie zarchiwizowano wcześniejszej migawki.
Zaktualizowano 8 wrz 2026.
Podsumowanie redakcyjne i zapisane szczegóły zmian.Podsumowanie
Zastosowano ograniczoną korektę AI z zachowaniem blokady źródła i struktury MDX.
Szczegóły zmian
-
Poprawiono 7 bloków objętych blokadą źródła; wersja po korekcie maszynowej pozostaje robocza i wymaga oceny native speakera.
Pełne porównanie jest niedostępne — dla tej wersji nie zarchiwizowano wcześniejszej migawki.
Zaktualizowano 19 lip 2026.
Podsumowanie redakcyjne i zapisane szczegóły zmian.Podsumowanie
Przywrócono opatrzone źródłami i datami wypowiedzi o liczbie skoków przekierowań, które poprzednia rewizja błędnie uznała za wymyślone, zachowując ich rozdzielenie od aktualnej dokumentacji Google i obserwacji Patricka.
Szczegóły zmian
-
Uzgodniono obecny limit Google wynoszący 10 skoków oraz praktyczne zalecenie, aby nie przekraczać 3 i utrzymywać mniej niż 5 skoków, z datowanymi wypowiedziami Johna Muellera z 2014 i 2020 roku o około pięciu skokach na próbę skanowania.
-
Przywrócono wypowiedź z 2014 roku, według której późniejsze skanowanie może kontynuować pozostałe przekierowania, oznaczono ją jako historyczną, reprezentatywną wskazówkę, a nie bieżącą gwarancję, i zachowano osobne przypisanie obserwacji praktycznych Patricka.
Pełne porównanie jest niedostępne — dla tej wersji nie zarchiwizowano wcześniejszej migawki.
Zaktualizowano 18 lip 2026.
Podsumowanie redakcyjne i zapisane szczegóły zmian.Podsumowanie
Usunięto niepoparty źródłem szczegół o czasie obsługi skoków, doprecyzowano zachowanie metod przy 301/302/303/307/308 zgodnie z MDN i Fetch Standard opartymi na RFC 9110, dodano zastrzeżenie Google, że canonical jest „wskazówką, nie regułą”, oraz uzgodniono indeks podklastra i listę kontrolną z istniejącymi artykułami powiązanymi.
Szczegóły zmian
-
Z zakładki zaawansowanej usunięto niepoparty źródłami szczegół 'typically five per session and resuming the rest later' _(tłumaczenie)_ „zwykle pięć na sesję, a reszta jest wznawiana później” dotyczący skoków przekierowań; dokumentacja Google o skanowaniu podaje jedynie 'up to 10 redirect hops' _(tłumaczenie)_ „do 10 skoków przekierowania”, bez liczby przypisanej do sesji.
-
Doprecyzowano opis zachowania metody przy 301/302 w tabeli ściągawki i dwóch objaśnieniach zakładki zaawansowanej: niejasne 'Not guaranteed' _(tłumaczenie)_ „Brak gwarancji” oraz 'may swap' _(tłumaczenie)_ „może zmienić” zastąpiono zweryfikowanym wyjaśnieniem, że klient może zmienić POST na GET przy 301/302 zgodnie z Fetch Standard, 303 zawsze wymusza GET, a 307/308 ściśle zachowują metodę i treść żądania.
-
Dodano udokumentowane przez Google zastrzeżenie dotyczące tagu kanonicznego — 'a hint, not a rule' _(tłumaczenie)_ „wskazówka, a nie reguła”; Google może wybrać inny adres kanoniczny — oraz trzecią gałąź w zakładce Frameworks dla sytuacji, gdy nie istnieje odpowiedni cel zastępczy przekierowania; należy wtedy użyć 404/410 zamiast wymuszonego przekierowania.
-
Zsynchronizowano indeks podklastra 'Where to go next' _(tłumaczenie)_ „Co dalej” oraz zakładkę z oficjalną dokumentacją z istniejącymi już materiałami: artykułem 307-redirect, artykułem 308-redirect, przewodnikiem javascript-redirect, omówieniem meta-refresh, analizą page-with-redirect, diagnostyką redirect-error i dokumentem o kanonizacji. Usunięto też nieaktualną uwagę, że 308 zastępuje jeszcze nienapisany artykuł o 307.
-
Do listy kontrolnej wdrożenia dodano punkt dotyczący ścieżki wycofania zmian oraz zastrzeżenie o weryfikacji HEAD względem GET.
Pełne porównanie jest niedostępne — dla tej wersji nie zarchiwizowano wcześniejszej migawki.
Czy to było pomocne?
Podoba Ci się ten materiał? Dodaj tę witrynę do preferowanych źródeł w Google.
Dodaj tę witrynę w GoogleKontynuujmy rozmowę
Zadaj pytanie tutaj lub zapytaj innych specjalistów ds. SEO technicznego
Moje notatki
- Redirect Chains · Dostępne po angielsku
- Redirect Loops · Dostępne po angielsku
- Przekierowania HTTP