Jak testować przekierowania? curl, DevTools, łańcuchy i pętle

Poprawne przekierowanie trzeba ocenić na podstawie kodu HTTP, nagłówka Location, całego łańcucha oraz odpowiedzi strony docelowej. Sam fakt, że pasek adresu w przeglądarce się zmienił, nie wystarcza — przeglądarka może korzystać z cache, JavaScriptu albo zapamiętanego 301.

Krótka odpowiedź: uruchom curl -I dla starego URL-a, sprawdź kod i Location, a potem curl -IL, aby zobaczyć cały łańcuch. Dobre trwałe przeniesienie zwykle ma jeden krok 301 → 200 i prowadzi od razu do kanonicznego adresu HTTPS.

Co dokładnie trzeba potwierdzić?

Dla każdego przekierowania odpowiedz na sześć pytań:

1. Czy źródłowy URL odpowiada?
2. Czy zwraca planowany kod — np. 301, a nie 302?
3. Czy Location wskazuje właściwy, pełny cel?
4. Czy po drodze nie ma zbędnych kroków?
5. Czy strona docelowa zwraca 200 i pokazuje właściwą treść?
6. Czy podobne adresy, których reguła nie powinna obejmować, pozostały bez zmian?

Google traktuje trwałe przekierowania serwerowe, takie jak 301 i 308, jako sygnał, że docelowy URL powinien zostać kanoniczny. Tymczasowe 302 i 307 komunikują inną intencję. Dlatego „przekierowuje” to za mało — kod musi odpowiadać rzeczywistej sytuacji.

Test 1: nagłówki jednego URL-a przez curl -I

curl -I https://example.pl/stary-adres/

-I prosi o same nagłówki odpowiedzi. Przykładowy wynik:

HTTP/2 301
location: https://example.pl/nowy-adres/
content-type: text/html; charset=UTF-8

Sprawdź:

• pierwszą linię z kodem;
• dokładną wartość location;
• protokół HTTPS;
• wybrany wariant domeny;
• końcowy ukośnik;
• zachowanie znaków i kodowania w adresie.

Jeżeli serwer nie obsługuje żądania HEAD tak samo jak GET, test -I może różnić się od zachowania użytkownika. Wtedy pobierz odpowiedź GET bez zapisywania treści, np.:

curl -sS -o /dev/null -D - https://example.pl/stary-adres/

-D - wypisuje nagłówki na standardowe wyjście, a -o /dev/null pomija ciało odpowiedzi.

Test 2: cały łańcuch przez curl -IL

curl -IL https://example.pl/stary-adres/

-L każe podążać za nagłówkiem Location. Prawidłowy prosty łańcuch:

HTTP/2 301
location: https://example.pl/nowy-adres/

HTTP/2 200

Łańcuch wymagający poprawy:

http://www.example.pl/stary
→ https://www.example.pl/stary
→ https://example.pl/stary
→ https://example.pl/stary/
→ https://example.pl/nowy/

Nie każdy dodatkowy krok powoduje awarię, ale zwiększa opóźnienie, utrudnia crawl i komplikuje przyszłe migracje. Reguła źródłowa powinna — gdy to możliwe — kierować od razu do ostatecznej wersji.

Test 3: pokaż adres końcowy, kod i liczbę przekierowań

Do szybkiego raportu użyj formatu wyjścia curl:

curl -sS -L -o /dev/null \
  -w 'kod=%{http_code}\ncel=%{url_effective}\nprzekierowania=%{num_redirects}\n' \
  https://example.pl/stary-adres/

Przykładowy wynik:

kod=200
cel=https://example.pl/nowy-adres/
przekierowania=1

To wygodne przy ręcznej kontroli kilku URL-i. Przy dużej migracji potrzebny jest arkusz źródło → oczekiwany cel oraz automatyczny test całej listy.

Test 4: ogranicz liczbę kroków, żeby wykryć pętlę

curl -IL --max-redirs 10 https://example.pl/

Jeśli narzędzie osiągnie limit, zapisz powtarzające się wartości Location. Najczęstsze pary to:

• HTTP i HTTPS;
• www i brak www;
• slash i brak slasha;
• domena publiczna i tymczasowa;
• URL logowania i panel;
• dwie wersje językowe.

Następnie przejdź do drzewa diagnostycznego błędu ERR_TOO_MANY_REDIRECTS.

Test 5: przekierowanie w Chrome lub Firefox DevTools

1. Otwórz narzędzia deweloperskie.
2. Przejdź do zakładki Network/Sieć.
3. Włącz „Preserve log”, aby zachować wcześniejsze żądania.
4. Jeśli narzędzie na to pozwala, zaznacz „Disable cache” przy otwartych DevTools.
5. Wpisz stary adres i odśwież stronę.
6. Kliknij pierwsze żądanie dokumentu.
7. Sprawdź Status Code oraz nagłówek Response Headers → Location.

DevTools pokazuje również zasoby i przekierowania wykonywane przez JavaScript. To zaleta i zarazem powód, by porównać wynik z curl. Jeżeli przeglądarka zmienia adres, ale serwer przez curl zwraca 200, przekierowanie może pochodzić z JavaScriptu, meta refresh albo logiki aplikacji.

Test 6: macierz wariantów domeny

Dla jednej przykładowej podstrony sprawdź:

Nie testuj tylko strony głównej. Reguły katalogowe i WordPress mogą inaczej obsługiwać podstrony, pliki, panel i API.

Test 7: przypadki negatywne

To najbardziej pomijana część. Sprawdź adresy, które nie powinny się przekierować:

• podobny slug, np. /stara-oferta-premium/;
• zasób w innym katalogu;
• istniejący plik PDF lub obraz;
• endpoint formularza lub webhook;
• /wp-admin/, /wp-login.php i API;
• podstrona docelowa.

Zbyt szeroki regex może wyglądać poprawnie na jednym URL-u, a jednocześnie przechwycić setki innych.

Jak przetestować listę po migracji?

Przy większej zmianie przygotuj arkusz:

Lista starych adresów powinna pochodzić z kilku źródeł:

• poprzedniej mapy XML;
• eksportu systemu CMS;
• Google Search Console;
• narzędzia analitycznego;
• raportu linków zewnętrznych;
• crawl starej strony;
• logów serwera, jeśli są dostępne.

Nie testuj tylko najnowszej sitemapy — nie zawiera ona często historycznych URL-i, które nadal mają wejścia i linki.

Cache i zapamiętany 301

Przeglądarka, CDN i serwer mogą cache’ować przekierowania. Gdy wynik nie odpowiada aktualnej konfiguracji:

1. sprawdź curl bez cookies;
2. sprawdź nagłówki cache;
3. wyczyść cache aplikacji;
4. wyczyść cache hostingu;
5. wyczyść lub purge’uj właściwy URL w CDN-ie;
6. usuń dane tej witryny w przeglądarce albo użyj nowego profilu.

Nie zakładaj od razu, że .htaccess jest ignorowany. Stara odpowiedź mogła zostać zapisana w innej warstwie.

Jak oceniać redirect związany z formularzem lub POST?

Kody 301 i 302 mają historycznie niejednoznaczne zachowanie dla metod innych niż GET w różnych klientach. 307 i 308 jednoznacznie zachowują metodę oraz ciało żądania. Jeżeli testujesz endpoint przyjmujący POST, nie ograniczaj się do curl -I — wyślij kontrolowane żądanie właściwą metodą na środowisku testowym i sprawdź, co otrzymuje cel.

Nie wykonuj testowego POST z prawdziwymi danymi klienta ani na endpointach płatności bez planu. W takich przypadkach użyj środowiska stagingowego i danych testowych.

Najczęstsze błędy podczas testowania

• sprawdzanie tylko zmiany w pasku adresu;
• test tylko strony głównej;
• brak kontroli końcowego statusu 200;
• uznanie dwóch lub trzech kroków za „normalne”, choć można ich uniknąć;
• brak przypadków negatywnych;
• test po zalogowaniu, gdy reguła zależy od cookies;
• pominięcie www, HTTP i trailing slash;
• brak zapisanego oczekiwanego celu — wynik „wydaje się dobry”;
• używanie publicznego testera do poufnych lub nieopublikowanych URL-i.

Checklista akceptacji

• ☐ Kod źródła odpowiada planowi.
• ☐ Location wskazuje bezpośrednio ostateczny URL.
• ☐ Cel ma HTTPS, właściwy host i politykę ukośnika.
• ☐ Docelowy kod to 200.
• ☐ Liczba przekierowań wynosi 1, jeśli nie ma uzasadnionego wyjątku.
• ☐ Nie ma pętli.
• ☐ Parametry zachowują się zgodnie z wymaganiami.
• ☐ Przypadki podobne, ale nieobjęte regułą, nie są przekierowywane.
• ☐ Linki wewnętrzne i sitemapa wskazują cel bez korzystania z 301.
• ☐ Wynik został zapisany w raporcie migracji lub dzienniku zmian.

Podsumowanie

Najbardziej wiarygodny test łączy nagłówki serwera, pełny łańcuch i zachowanie przeglądarki. Zacznij od curl -I, potem użyj curl -IL, sprawdź ostateczny URL, kod 200 i liczbę kroków. Przy większej zmianie testuj arkusz wszystkich starych adresów oraz przypadki, których reguła nie powinna objąć.

Konfigurację samych reguł opisuje pełny przewodnik po przekierowaniach .htaccess. Jeśli masz setki URL-i albo migrację działającego serwisu, audyt w ramach wsparcia technicznego pozwoli wykryć 404, łańcuchy i pętle przed publikacją.

Źródła

• curl manual
• Google Search Central: redirects and Google Search
• MDN: redirections in HTTP