Aby sprawdzić przekierowanie, trzeba zobaczyć nie tylko stronę końcową, lecz każdy kod odpowiedzi po drodze. Przeglądarka zwykle ukrywa te kroki. Dopiero nagłówki HTTP pokazują, czy stary adres zwraca 301 lub 308, czy występuje łańcuch, pętla, przejście na HTTP albo błędny cel.
- Zapisz dokładny stary URL wraz z protokołem, hostem, ścieżką i parametrami.
- Wyłącz automatyczne podążanie za przekierowaniami albo użyj narzędzia pokazującego każdy krok.
- Odczytaj kod, nagłówek
Locationi adres końcowy. - Potwierdź, że ostatnia strona zwraca 200 i odpowiada treścią staremu URL-owi.
- Powtórz test dla wersji HTTP, HTTPS, www, bez www i reprezentatywnych podstron.
Jak wygląda prawidłowe przekierowanie jednego adresu
Dla trwałej zmiany najprostszy poprawny przebieg to: stary URL zwraca kod 301 albo 308, w nagłówku Location wskazuje bezpośrednio nowy adres, a strona docelowa odpowiada kodem 200. Treść nowej strony powinna realizować tę samą albo bardzo zbliżoną intencję. Sam kod nie wystarcza. Przekierowanie dawnej usługi na niepowiązaną stronę główną może działać technicznie, ale nadal jest błędną decyzją dla użytkownika i wyszukiwarki.
https://example.pl/stara-usluga/
301 Location: https://example.pl/nowa-usluga/
https://example.pl/nowa-usluga/
200 OKSprawdzaj pełny URL, nie tylko domenę. Wynik dla strony głównej nie mówi nic o setkach podstron po zmianie struktury. Ukośnik na końcu, wielkość liter, parametr, inny protokół lub host mogą uruchamiać osobne reguły. Jeśli migracja obejmuje katalog /blog/, przetestuj kilka wpisów, paginację i adres, który nie istnieje. Jedna udana próbka nie potwierdza poprawności całego wzorca.
Warto też odróżnić przekierowanie serwerowe od zmiany widocznej dopiero po uruchomieniu JavaScriptu. Dla migracji i kanonizacji adresów mechanizm HTTP jest czytelniejszy, szybszy i możliwy do zbadania bez renderowania strony. Meta refresh lub skrypt mogą mieć zastosowania interfejsowe, ale nie powinny zastępować poprawnej odpowiedzi serwera przy trwałym przeniesieniu dokumentu.
Jak sprawdzić przekierowanie w przeglądarce, terminalu i zbiorczo
W przeglądarce otwórz narzędzia deweloperskie, przejdź do zakładki Network, włącz zachowanie logu i dopiero wtedy wpisz stary adres. Filtr „Doc” albo „Document” pomaga oddzielić główną nawigację od obrazów, fontów i skryptów. Kliknij pierwszy rekord i odczytaj Status, Location oraz kolejne dokumenty. Jeśli przeglądarka pamięta stałe przekierowanie, użyj okna prywatnego albo wyczyść dane dla domeny.
W terminalu przydaje się żądanie nagłówkowe. Polecenie bez podążania za przekierowaniami pokazuje pierwszy krok:
curl -I https://example.pl/stary-adres/Aby zobaczyć całą ścieżkę, można dodać opcję podążania za przekierowaniami i zapis nagłówków. Nie oceniaj wyniku wyłącznie po ostatnim kodzie 200, bo taki odczyt ukrywa liczbę pośrednich kroków. Zapisz każdy adres oraz kod. Na Windowsie użyj curl.exe, aby uniknąć konfliktu z aliasem polecenia PowerShell.
Dla kilku adresów wystarczy tabela ręczna. Dla setek URL-i potrzebny jest test zbiorczy z listą „stary → oczekiwany nowy”. Crawler albo skrypt powinien porównać rzeczywisty cel z mapą, a nie tylko oznaczyć „jest 301”. Przekierowanie do innego, ale działającego URL-a nadal jest błędem. Kontrola zbiorcza powinna wykrywać również 302, 307, więcej niż jeden skok, przejście z HTTPS do HTTP i brak reguły.
| Metoda | Najlepsze zastosowanie | Ograniczenie |
|---|---|---|
| Pasek adresu | Szybkie potwierdzenie, dokąd trafia użytkownik | Ukrywa kody i zwykle nie pokazuje łańcucha |
| Network w DevTools | Jedna trasa wraz z zachowaniem przeglądarki | Cache i sesja mogą zmieniać wynik |
curl -I |
Pierwszy kod i nagłówek Location | Nie pokaże redirectu JavaScript ani treści po renderowaniu |
| Crawler | Setki lub tysiące adresów po migracji | Wymaga poprawnej listy oczekiwanych celów |
| Inspekcja URL w GSC | Stan znany Google i test adresu końcowego | Nie zastępuje pełnej mapy przekierowań |
Jeśli przekierowanie dotyczy WordPressa, sprawdź zarówno regułę w CMS-ie, jak i odpowiedź publiczną. Wtyczka może przegrywać z konfiguracją serwera, CDN-em albo cache. Przy większej zmianie audyt techniczny WordPressa powinien obejmować mapę URL-i, kody odpowiedzi, canonicale, linki wewnętrzne i sitemapę. Sam podgląd ustawienia w panelu nie dowodzi, że użytkownik otrzymuje właściwy wynik.
Co oznaczają 301, 302, 307 i 308 podczas kontroli
Kody 301 i 308 komunikują trwałe przeniesienie. Różnią się zachowaniem metody żądania: 308 zachowuje ją jednoznacznie, podczas gdy historyczna obsługa 301 bywała mniej ścisła. Dla zwykłego przejścia metodą GET oba prowadzą do podobnego rezultatu. Kody 302 i 307 oznaczają zmianę tymczasową; 307 również zachowuje metodę. Nie wybieraj numeru na podstawie popularności. Najpierw odpowiedz, czy stary URL ma wrócić jako samodzielny dokument.
| Kod | Znaczenie operacyjne | Typowy przypadek |
|---|---|---|
| 301 | Trwałe przeniesienie | Zmiana sluga, domeny lub stała konsolidacja adresów |
| 308 | Trwałe przeniesienie z zachowaniem metody | Stała zmiana endpointu, gdy metoda ma znaczenie |
| 302 | Tymczasowe przeniesienie | Krótkotrwały wariant, gdy pierwotny URL ma wrócić |
| 307 | Tymczasowe przeniesienie z zachowaniem metody | Czasowa zmiana przy wymaganej metodzie żądania |
| 200 | Dokument dostępny pod bieżącym adresem | Końcowy URL trasy |
| 404/410 | Brak zasobu | Brak sensownego następcy albo cel usunięty omyłkowo |
Nie każdy stary adres wymaga przekierowania. Jeśli treść została usunięta i nie ma porównywalnego następcy, 404 albo 410 może być uczciwszą odpowiedzią niż wysłanie na stronę główną. Jeżeli powstała nowa strona o tej samej funkcji, stały redirect jest właściwy. Matrycę decyzji opisuje szerzej poradnik kiedy ustawiać 301, a przypadki bez następcy — poradnik o błędzie 404.
Sprawdzaj również nagłówek Location. Powinien zawierać poprawny adres, najlepiej absolutny, ze zgodnym protokołem i hostem. Błąd w nazwie domeny, niezakodowany znak lub podwójny ukośnik może zadziałać w jednej przeglądarce, a w innym kliencie dać nieprzewidywalny wynik. W testach API i formularzy zwracaj uwagę na metodę, ponieważ automatyczne przejście z POST do GET może zmienić sens żądania.
Jak znaleźć łańcuch, pętlę i przekierowanie do złego celu
Łańcuch powstaje, gdy adres A prowadzi do B, B do C, a dopiero C zwraca 200. Typowy przykład to równoczesna zmiana HTTP na HTTPS, hosta i sluga wdrażana w oddzielnych regułach. Rozwiązaniem nie jest usunięcie ostatniego kroku, lecz wskazanie z każdego starego wariantu bezpośrednio kanonicznego celu. Dzięki temu użytkownik i robot wykonują mniej żądań, a utrzymanie jest prostsze.
Pętla wygląda jak A → B → A albo dłuższy cykl. Przeglądarka po kilku lub kilkunastu przejściach wyświetla błąd. Przyczyną bywa konflikt reguł serwera, wymuszania HTTPS, wtyczki, proxy i CDN-u. Nie dodawaj kolejnego wyjątku bez rozrysowania całej trasy. Najpierw wyłącz cache dla testu, zapisz nagłówki z każdego poziomu i ustal, która warstwa podejmuje pierwszą sprzeczną decyzję.
Najtrudniejszy do wykrycia jest poprawny kod prowadzący do złej strony. Automatyczny test może uznać go za PASS, bo widzi 301 oraz końcowe 200. Człowiek musi ocenić zgodność znaczenia. Stary poradnik o kopii WordPressa nie powinien kończyć na ogólnej stronie oferty hostingu, a usunięty produkt nie zawsze ma odpowiednik w najpopularniejszej kategorii. Dla każdego ważnego URL-a ustal oczekiwany cel przed migracją.
Prawidłowe przejście domeny A na domenę B nie potwierdza migracji podstron. Największe straty powstają wtedy, gdy wszystkie stare ścieżki lądują na stronie głównej albo zwracają 404 mimo działającej reguły dla hosta.
Sprawdź także adresy z parametrami. Filtry, UTM, wersje językowe i identyfikatory mogą zostać utracone albo doprowadzić do innego celu niż czysty URL. Nie trzeba zachowywać każdego parametru analitycznego w nieskończoność, ale przekierowanie nie powinno kasować informacji potrzebnej do działania strony lub pomiaru bieżącej kampanii. W razie duplikacji sprawdź relację z adresem kanonicznym; canonical nie zastępuje redirectu, gdy stary URL został trwale wycofany.
Jak kontrolować przekierowania po migracji strony
Najlepszy audyt zaczyna się przed wdrożeniem. Zbierz adresy z sitemap, crawla, Search Console, analityki i profilu linków. Do każdego przypisz decyzję: pozostaje bez zmiany, dostaje konkretny następca albo uczciwie znika. Mapa powinna zawierać pełne URL-e, nie tylko same slugi, ponieważ zmiana hosta i protokołu jest częścią trasy.
- Przed publikacją: uruchom mapę w środowisku testowym lub sprawdź reguły na kontrolowanej próbce.
- Tuż po starcie: sprawdź wszystkie URL-e o ruchu, linkach i znaczeniu biznesowym.
- Następnego dnia: wykonaj pełny test zbiorczy po odświeżeniu cache i DNS.
- Po kolejnych crawlach: przejrzyj 404, soft 404 i strony z przekierowaniem w raportach.
- Po aktualizacji linków: potwierdź, że nawigacja i treść prowadzą już bezpośrednio do nowych URL-i.
- Po zmianach redakcyjnych: zachowaj reguły dla starych adresów, które nadal mają ruch lub linki.
Nie zostawiaj linków wewnętrznych prowadzących przez 301. Przekierowanie chroni stare wejścia, ale aktualny serwis powinien wskazywać bezpośrednie cele. Dotyczy to menu, treści, danych strukturalnych, sitemap, canonicali, hreflangów i odnośników w plikach do pobrania. Kontrolę całej sieci wspiera poradnik o audytowaniu linkowania wewnętrznego.
Po zmianie domeny sprawdź osobno warianty hosta. Jeżeli aktywny jest adres bez www, wejścia na www powinny trafić bezpośrednio do odpowiadających im ścieżek, a nie najpierw zmieniać protokół, potem host i dopiero slug. Certyfikat musi obejmować stary host tak długo, jak obsługuje on przekierowania; inaczej użytkownik zobaczy ostrzeżenie przed wykonaniem reguły.
Jak zapisać wynik, żeby można było go powtórzyć
Raport nie powinien ograniczać się do kolumny „działa”. Dla każdego adresu zapisz URL wejściowy, oczekiwany cel, rzeczywisty ciąg odpowiedzi, adres końcowy, kod końcowy, datę testu oraz ocenę zgodności treści. Dodaj źródło adresu: sitemap, GSC, link zewnętrzny, analityka albo crawl. Pozwala to ustawić priorytet, gdy liczba błędów jest większa niż możliwości jednorazowej naprawy.
| Pole | Przykład | Po co je zapisywać |
|---|---|---|
| Stary URL | /stara-oferta/ |
Identyfikuje testowane wejście |
| Oczekiwany cel | /nowa-oferta/ |
Oddziela poprawność techniczną od zgodności decyzji |
| Rzeczywista trasa | 301 → 200 | Ujawnia łańcuch i kod tymczasowy |
| Adres końcowy | Pełny kanoniczny URL | Wykrywa inny host, HTTP albo parametr |
| Ocena znaczenia | Zgodny / do poprawy | Zapobiega przekierowaniu wszystkiego na stronę główną |
| Data i środowisko | 2026-10-22, produkcja | Umożliwia powtórzenie kontroli po zmianie |
Po naprawie uruchom dokładnie tę samą próbkę. To ważne, bo nowe reguły mogą poprawić jeden URL i zepsuć inny. Nie zamykaj zadania na podstawie konfiguracji ani komunikatu w panelu. Dowodem jest publiczna odpowiedź serwera oraz zgodność finalnej strony. Jeśli wynik zmienia się zależnie od urządzenia, kraju lub cookies, zapisz warunki i sprawdź, czy to zamierzone zachowanie.