Jak sprawdzić przekierowania i odczytać łańcuch przekierowań

Link, który klikasz, często nie prowadzi wprost do strony, którą ostatecznie widzisz. Po drodze może się pojawić przejście na HTTPS, zmiana hosta, usługa śledząca, skracacz linków i reguła w CMS, która dopisuje ukośnik na końcu adresu – a każdy z tych kroków to osobne żądanie, które przeglądarka wysyła, nic Ci o tym nie mówiąc.

Z tego poradnika dowiesz się, jak zobaczyć te kroki za pomocą TrueURL, curl i narzędzi deweloperskich przeglądarki (DevTools), co oznacza każdy element łańcucha przekierowań i jak naprawić najczęstsze problemy.

Czym jest łańcuch przekierowań

Przekierowanie następuje wtedy, gdy serwer odpowiada kodem 3xx i nagłówkiem Location, który wskazuje inny adres URL. Klient – przeglądarka lub robot indeksujący – wysyła następnie żądanie pod ten adres i powtarza ten proces, aż otrzyma odpowiedź, która nie jest przekierowaniem.

Każde żądanie wraz z odpowiedzią to jeden przeskok. Cała sekwencja od pierwszego adresu URL do odpowiedzi końcowej to łańcuch przekierowań:

#  URL                              Status  Location
1  http://example.com/Shoes         301     https://example.com/Shoes
2  https://example.com/Shoes        301     https://www.example.com/Shoes
3  https://www.example.com/Shoes    302     /shoes/
4  https://www.example.com/shoes/   200

To trzy przekierowania i cztery żądania, żeby dotrzeć do jednej strony. Wartość Location w przeskoku 3 jest względna: klient rozwiązuje ją względem adresu URL, o który właśnie poprosił, tak jak określa to RFC 9110, więc oznacza ona https://www.example.com/shoes/. W idealnym przypadku każdy z tych adresów prowadziłby do docelowego adresu URL w jednym przeskoku.

Strona może też przekierować dalej już po odpowiedzi 200 OK – za pomocą tagu <meta http-equiv="refresh"> lub JavaScriptu. Takie przekierowania po stronie klienta również należą do łańcucha, ale narzędzia, które czytają tylko nagłówki HTTP, takie jak curl, zatrzymują się na tej stronie.

Dlaczego warto sprawdzać przekierowania

SEO: sygnały kanoniczności i budżet indeksowania

Wyszukiwarki traktują przekierowanie jako informację o tym, który adres URL należy zindeksować. Google uznaje przekierowania stałe (301 i 308) za silny sygnał, że kanoniczny powinien być adres docelowy, a przekierowania tymczasowe (302, 303 i 307) – za słaby sygnał. Strona przeniesiona na stałe, ale za pomocą kodu 302, może więc zachować w wynikach wyszukiwania swój stary adres URL.

Liczy się też długość łańcucha. Googlebot podąża za maksymalnie 10 przeskokami przekierowań; jeśli do tego czasu nie dotrze do treści, Search Console zgłasza błąd przekierowania. W przewodniku po budżecie indeksowania (crawl budget) Google radzi też unikać długich łańcuchów przekierowań, które według niego negatywnie wpływają na skanowanie witryny.

Szybkość ładowania strony

Strona docelowa nie zacznie się ładować, dopóki nie nadejdzie odpowiedź na ostatnie przekierowanie. Każdy przeskok to dodatkowa podróż przez sieć tam i z powrotem (round trip), a przeskok na nowy host wymaga jeszcze zapytania DNS, nowego połączenia i – w przypadku HTTPS – uzgadniania TLS (TLS handshake). W sieciach komórkowych trzy lub cztery przekierowania mogą dodać kilkaset milisekund, zanim dotrze pierwszy bajt właściwej strony. Pomiar opóźnień przekierowań pokazuje, ile czasu kosztuje każdy przeskok.

Bezpieczeństwo skróconych i nieznanych linków

Skrócone linki i wiele linków śledzących w e-mailach ukrywają, dokąd naprawdę prowadzą. Kampanie phishingowe wykorzystują też otwarte przekierowania (open redirect) w znanych domenach, więc link, który zaczyna się w zaufanej witrynie, może skończyć się zupełnie gdzie indziej. Rozwijanie skróconych linków jeszcze przed kliknięciem pokaże Ci każdą domenę na trasie i to, czy któryś przeskok schodzi z HTTPS na niezaszyfrowane HTTP.

Linki afiliacyjne i śledzące

Linki marketingowe często przechodzą przez kilka usług, zanim trafią na stronę docelową (landing page), a każda z nich musi przekazać dalej ciąg zapytania (query string) – inaczej parametry UTM, identyfikatory kliknięć i tagi afiliacyjne po cichu przepadają. Docelowy adres URL pokazuje, czy przetrwały i czy link nadal prowadzi na właściwą stronę.

Migracje, HTTPS i kanoniczny host

Po przebudowie witryny, przeniesieniu domeny lub przejściu na HTTPS każdy stary adres URL powinien prowadzić do swojego nowego odpowiednika jednym przekierowaniem stałym. Cztery podstawowe warianty witryny (http:// i https://, z www i bez) powinny trafiać na jeden kanoniczny adres. Te reguły psują się po cichu: nowa reguła CDN, aktualizacja wtyczki czy przeprowadzka na inny serwer mogą niepostrzeżenie dodać przeskok albo pętlę.

Jak sprawdzić przekierowanie w TrueURL

TrueURL wykonuje każde sprawdzenie w sieci brzegowej Cloudflare, więc możesz przeanalizować linki, którym nie ufasz, bez otwierania ich w przeglądarce. Sprawdzanie przekierowań URL na stronie głównej – podstawowy redirect checker – obsługuje pojedynczy adres URL, a Sprawdzanie łańcucha przekierowań i pozostałe wyspecjalizowane narzędzia korzystają z tego samego silnika.

Krok 1: wpisz adres URL

Wklej adres URL i uruchom sprawdzanie. Jeśli nie podasz protokołu, przyjmowany jest https://; aby przetestować zwykłe HTTP, wpisz http://.

Krok 2: w razie potrzeby zmień ustawienia zaawansowane

Domyślnie narzędzie wysyła żądanie GET z User-Agentem aktualnej wersji Chrome na komputery (desktop), bez plików cookie i z limitem 20 przekierowań. W sekcji Ustawienia zaawansowane możesz to zmienić:

• Metoda HTTP: GET, HEAD lub POST. Metoda HEAD jest lżejsza, ale niektóre serwery odpowiadają na nią inaczej, a bez treści odpowiedzi nie da się wykryć przekierowań po stronie klienta. POST wysyła wpisaną przez Ciebie treść żądania – przydaje się przy testowaniu obsługi formularzy i API. Kolejne przeskoki działają według reguł przeglądarek: po żądaniu POST przekierowanie 301 lub 302 jest kontynuowane metodą GET, 303 zawsze przechodzi na GET, a 307 i 308 zachowują metodę i treść żądania.
• Maks. liczba przeskoków: liczba przekierowań, za którymi narzędzie podąża, od 1 do 50. Domyślna wartość 20 to limit określony w specyfikacji Fetch Standard i stosowany w Chrome i Firefoksie. Ustaw 10, aby sprawdzić, czy łańcuch mieści się w limicie Googlebota.
• Własny User-Agent: puste pole oznacza Chrome w wersji desktop. Do wyboru są gotowe ustawienia: Safari na iPhonie, Chrome na Androidzie, Googlebot (smartfon i desktop), Bingbot, boty Facebooka i X, które generują podglądy linków, oraz curl.
• Własne nagłówki żądania: dodatkowe nagłówki wysyłane w każdym przeskoku, np. Accept-Language: fr-FR, aby wywołać przekierowanie zależne od języka.
• Pliki cookie: wpisz name=value; other=value, aby odtworzyć stan po zalogowaniu, udzieloną zgodę albo wybrany region. Pliki cookie ustawione po drodze są zachowywane na kolejne przeskoki, tak jak w przeglądarce.
• Przekierowania po stronie klienta: narzędzie może podążać za tagami meta refresh i prostymi przekierowaniami JavaScript albo tylko je zgłaszać.
• Ignoruj błędy SSL: sieć brzegowa Cloudflare zawsze weryfikuje certyfikaty, więc ta opcja nie pozwoli pominąć wadliwego certyfikatu. Błąd TLS jest zgłaszany w tym przeskoku, w którym wystąpił.

Krok 3: odczytaj wynik

Na początku wyniku widać docelowy adres URL i jego kod odpowiedzi. Poniżej znajduje się łańcuch, w którym każdy przeskok ma osobny wiersz, a w nim:

• żądany adres URL i użyta metoda HTTP;
• kod odpowiedzi z opisem słownym (każdy z nich wyjaśnia kompendium kodów odpowiedzi HTTP);
• czas odpowiedzi – od wysłania żądania do otrzymania nagłówków, łącznie z ewentualnym zapytaniem DNS i nawiązaniem połączenia;
• adres, na który wskazuje nagłówek Location;
• nagłówki odpowiedzi i nazwy plików cookie ustawionych w tym przeskoku.

Każde przekierowanie jest oznaczone według tego, jak nastąpiło: kod odpowiedzi HTTP, meta refresh (z opóźnieniem w sekundach) lub JavaScript. Zgłaszane są również przekierowania po stronie klienta, które zostały wykryte, ale za którymi narzędzie nie podążyło. Równie ważne jest to, jak zakończyło się sprawdzanie:

Ostrzeżenia sygnalizują przekierowanie tymczasowe w łańcuchu, przejście z HTTPS na HTTP, więcej niż trzy przekierowania, docelowy adres URL w innej domenie, przekierowania po stronie klienta oraz żądania HEAD, przy których nie dało się odczytać treści strony.

Jedno ostrzeżenie wymaga szczególnej uwagi. Niektóre witryny pokazują ruchowi automatycznemu lub pochodzącemu z centrów danych weryfikację antybotową, np. stronę Cloudflare „Just a moment...”. TrueURL oznacza odpowiedzi, które ją przypominają, bo w takim przypadku sprawdzanie dotarło do warstwy ochronnej witryny, a nie do celu. Prawdziwy użytkownik może trafić zupełnie gdzie indziej.

Jak sprawdzić przekierowania w wierszu poleceń

Narzędzie curl jest preinstalowane w systemach macOS, Windows 10 i 11 oraz w większości dystrybucji Linuksa i pokazuje dokładnie to, co wysyła serwer, bez udziału pamięci podręcznej przeglądarki. Przykłady zakładają powłokę uniksową; w Windows PowerShell 5.1 wpisuj curl.exe, bo curl jest tam aliasem Invoke-WebRequest, a zamiast /dev/null pisz NUL.

Sprawdź pojedynczy przeskok

curl -I https://example.com/old-page

-I wysyła żądanie HEAD i wyświetla nagłówki odpowiedzi, w tym wiersz statusu i ewentualny nagłówek Location. Bez dodatkowej opcji curl nie podąża za przekierowaniami. Ponieważ niektóre serwery traktują HEAD inaczej, powtórz sprawdzenie metodą GET, gdy wynik wygląda podejrzanie; -o /dev/null odrzuca treść odpowiedzi, a -D - wyświetla nagłówki:

curl -sS -o /dev/null -D - https://example.com/old-page

Prześledź cały łańcuch

-L włącza podążanie za przekierowaniami, a w połączeniu z -I lub -D - curl wyświetla nagłówki każdego przeskoku. Filtr grep zostawia zwięzły podgląd:

curl -sIL http://example.com/Shoes | grep -iE '^(HTTP/|location:)'

HTTP/1.1 301 Moved Permanently
Location: https://example.com/Shoes
HTTP/2 301
location: https://www.example.com/Shoes
HTTP/2 302
location: /shoes/
HTTP/2 200

Domyślnie curl podąża za maksymalnie 50 przekierowaniami; --max-redirs 10 ustawia limit Googlebota.

Wyświetl tylko docelowy adres URL

Opcja -w (write-out) wyświetla szczegóły po zakończeniu transferu, dzięki czemu curl staje się poręcznym narzędziem do rozwijania skróconych linków (URL expander):

curl -sSL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' https://example.com/go

%{url_effective} to ostatni pobrany adres URL, %{num_redirects} – liczba wykonanych przekierowań, a %{http_code} – końcowy kod odpowiedzi. %{time_redirect} podaje w sekundach czas, jaki zajęły przekierowania przed ostatnim żądaniem. Bez -L zmienna %{redirect_url} pokazuje, dokąd prowadziłoby pierwsze przekierowanie.

Przetestuj żądania POST

-d wysyła treść żądania i zmienia je w żądanie POST. Podczas podążania za przekierowaniami curl zachowuje się wtedy jak przeglądarka: po 301, 302 lub 303 przechodzi na GET, a po 307 lub 308 ponownie wysyła POST wraz z treścią.

curl -sSL -o /dev/null -D - -d 'email=test%40example.com' https://example.com/subscribe

Unikaj łączenia -X POST z -L. -X wymusza metodę w każdym żądaniu, więc curl nadal wysyła POST po 301, 302 lub 303, choć przeglądarka przeszłaby na GET – a Ty testujesz łańcuch, którego żaden prawdziwy klient nie wygeneruje.

Zmień User-Agenta, nagłówki i pliki cookie

# Smartphone User-Agent
curl -sIL -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1' https://example.com/

# Extra request header
curl -sIL -H 'Accept-Language: de-DE,de;q=0.9' https://example.com/

# Send a cookie and keep the cookies set along the chain
curl -sSL -o /dev/null -D - -b 'consent=yes' -c cookies.txt https://example.com/

-A ustawia User-Agenta, -H dodaje nagłówek, a -b wysyła pliki cookie. -c zapisuje otrzymane pliki cookie we wskazanym pliku i włącza w curl obsługę plików cookie (cookie engine), dzięki czemu plik cookie ustawiony w jednym przeskoku zostanie wysłany w następnym.

Narzędzie curl nie uruchamia JavaScriptu ani nie reaguje na tagi meta refresh. Jeśli jego ostatnią odpowiedzią jest strona HTML z kodem 200 OK, a Twoja przeglądarka ląduje gdzie indziej, przekierowanie odbywa się po stronie klienta.

Jak sprawdzić przekierowania w DevTools przeglądarki

DevTools pokazuje łańcuch tak, jak widzi go Twoja przeglądarka – z Twoimi plikami cookie, rozszerzeniami i lokalizacją:

1. Otwórz DevTools (F12 lub Cmd+Option+I na Macu) i wybierz kartę Network.
2. Włącz Preserve log w Chrome i Edge albo Persist Logs w menu ustawień sieci w Firefoksie. W przeciwnym razie lista jest czyszczona przy każdym wczytaniu strony, a przekierowania po stronie klienta znikają z widoku.
3. Włącz Disable cache, aby przekierowanie zapisane w pamięci podręcznej nie zasłoniło tego, co serwer wysyła dzisiaj.
4. Wpisz adres URL na pasku adresu.

Każdy przeskok pojawia się w osobnym wierszu ze swoim kodem 3xx; zaznacz go i otwórz kartę Headers, aby zobaczyć nagłówek odpowiedzi location. W Chrome wpis „(disk cache)” lub „(memory cache)” w kolumnie Size oznacza, że przekierowanie pochodzi z pamięci podręcznej, a nie z serwera.

Chrome czasem pokazuje 307 Internal Redirect z http:// na https://. Serwer nigdy go nie wysłał: przeglądarka sama zmieniła żądanie na HTTPS, zwykle dlatego, że ma zapisaną politykę HSTS dla tej witryny. Aby zobaczyć, co serwer robi ze zwykłym żądaniem HTTP, użyj curl lub TrueURL.

Najczęstsze problemy z przekierowaniami i jak je naprawić

Łańcuchy dłuższe niż jeden przeskok

Łańcuchy narastają warstwami: reguła z dawnej migracji wskazuje adres URL, który późniejsza migracja ponownie przekierowała. Kieruj każdą regułę prosto do ostatecznego celu i zaktualizuj linki wewnętrzne, tagi canonical, adnotacje hreflang i mapy witryny, tak aby Twoja własna witryna nigdy nie wywoływała przekierowań. Masowe sprawdzanie przekierowań pokaże, które stare adresy URL nadal potrzebują więcej niż jednego przeskoku.

Pętle przekierowań

Chrome zgłasza pętlę komunikatem „Strona … przekierowała Cię zbyt wiele razy” (ERR_TOO_MANY_REDIRECTS), a Firefox – „Nieprawidłowe przekierowanie”. Typowe przyczyny:

• HTTPS za serwerem proxy lub CDN. Serwer źródłowy przekierowuje HTTP na HTTPS, ale proxy łączy się z nim przez zwykłe HTTP, więc serwer źródłowy nigdy nie widzi HTTPS i przekierowuje w nieskończoność. W Cloudflare to klasyczny skutek trybu SSL/TLS Flexible; użyj trybu Full (strict) albo niech serwer źródłowy sprawdza nagłówek X-Forwarded-Proto.
• Dwie warstwy, które sobie przeczą, np. reguła CDN usuwająca www, podczas gdy serwer je dodaje, albo framework dopisujący ukośnik na końcu adresu, który CDN obcina.
• Przekierowania zależne od plików cookie. Strona logowania lub zgody odsyła użytkownika z powrotem pod pierwotny adres URL, a ten ponownie przekierowuje go na stronę logowania, bo plik cookie nie został zapisany.

Wykrywanie pętli przekierowań pokaże, który przeskok zamyka pętlę. Potem zadbaj o to, by za każdą regułę odpowiadała tylko jedna warstwa.

301 i 302 wymieszane w jednym łańcuchu

Łańcuch 301, potem 302, potem 200 to przeniesienie na stałe z tymczasowym krokiem pośrodku. Często wynika on z ustawień domyślnych: zarówno res.redirect() w Express, jak i header('Location: ...') w PHP wysyłają 302, jeśli nie wskażesz innego kodu. Używaj kodu stałego w każdym przeskoku i potwierdź to narzędziem Sprawdzanie przekierowań 301. Kiedy pasuje który kod, wyjaśniamy w przewodniku po kodach przekierowań HTTP.

Podwójne przeskoki HTTP → HTTPS → www

Bardzo częsty łańcuch to http://example.com → https://example.com → https://www.example.com: dwa przeskoki tam, gdzie wystarczyłby jeden. Przekieruj każdy niekanoniczny wariant bezpośrednio na docelowy adres URL z HTTPS, a potem przetestuj wszystkie cztery narzędziem Sprawdzanie przekierowania na HTTPS.

Jest jeden celowy wyjątek. Jeśli Twój kanoniczny host to www, a domenę dodajesz do listy HSTS preload, hstspreload.org wymaga, aby http://example.com najpierw przekierowywał na https://example.com – dzięki temu przeglądarki zapiszą politykę HSTS dla samej domeny, bez www.

Niespójny ukośnik na końcu adresu (trailing slash)

/pricing i /pricing/ to różne adresy URL. Jeśli oba zwracają 200 OK, masz zduplikowaną treść (duplicate content); jeśli dwie warstwy przekierowują je wzajemnie na siebie, masz pętlę. Wybierz jedną formę, drugą przekieruj na nią jednym przekierowaniem 301 i konsekwentnie linkuj do wybranej. Sprawdzanie ukośnika na końcu adresu URL testuje obie formy jednocześnie.

Przekierowania tylko na urządzeniach mobilnych

Osobne wersje mobilne witryn, zachęty do instalacji aplikacji i wykrywanie urządzeń czasem kierują telefony gdzie indziej – często na mobilną stronę główną zamiast na odpowiednik danej strony. W ramach indeksowania mobile-first Google skanuje witryny głównie robotem dla smartfonów, więc dla indeksowania najważniejszy jest łańcuch mobilny. Porównaj oba łańcuchy narzędziem Przekierowania mobile vs desktop.

Przekierowania w mapach witryn

Mapa witryny powinna zawierać kanoniczne adresy URL, które mają się pojawiać w wynikach wyszukiwania – a te zwracają 200 OK. Wpisy z przekierowaniem marnują żądania robotów i wysyłają sprzeczne sygnały kanoniczności. Po każdej migracji uruchom Sprawdzanie przekierowań w mapie witryny i zastąp każdy przekierowujący wpis jego docelowym adresem URL.

Przekierowania JavaScript i meta refresh

Google traktuje natychmiastowy meta refresh jak przekierowanie stałe, a opóźniony – jak tymczasowe. Przekierowania JavaScript widzi dopiero po wyrenderowaniu strony, czyli na etapie, który następuje po skanowaniu i może się nie powieść. Wiele innych robotów, botów generujących podglądy linków i narzędzi wiersza poleceń w ogóle nie uruchamia JavaScriptu, a niektóre ignorują też meta refresh. Wszędzie tam, gdzie masz kontrolę nad serwerem, stosuj przekierowania po stronie serwera, a te po stronie klienta znajdziesz narzędziem Sprawdzanie meta refresh.

Lista kontrolna przekierowań

Przejdź przez tę listę po migracji, po zmianie CDN lub przed startem kampanii:

1. Każdy stary adres URL prowadzi do ostatecznego celu w jednym przeskoku.
2. Przy przeniesieniach na stałe każdy przeskok to 301 lub 308.
3. Wszystkie cztery warianty protokołu i hosta kończą się na kanonicznym adresie URL z HTTPS.
4. Żaden przeskok nie przechodzi z HTTPS na HTTP.
5. Ciągi zapytania, w tym parametry UTM i identyfikatory afiliacyjne, nie giną w łańcuchu.
6. Każdy adres URL występuje tylko w jednej formie (z ukośnikiem na końcu albo bez), a druga forma przekierowuje na nią.
7. Żądania z komputera, ze smartfona i od Googlebota kończą się na odpowiadających sobie stronach.
8. Wszędzie, gdzie to możliwe, przekierowania po stronie serwera zastępują meta refresh i JavaScript.
9. Linki wewnętrzne, tagi canonical, adnotacje hreflang i mapy witryny wskazują docelowe adresy URL.
10. Usunięte strony bez zamiennika zwracają 404 lub 410, zamiast przekierowywać na stronę główną.
11. Przekierowania wprowadzone przy przenoszeniu witryny pozostają aktywne – Google zaleca utrzymywać je co najmniej rok.