Sprawdzanie przekierowań
Do 10 adresów, pełny łańcuch przekierowań z kodami 301, 302, 307 i 308
- Darmowe
- Bez zakładania konta
Przykład: prawdziwe łańcuchy zapisane 23.09.2026. Wpisz swoje adresy.
| # | Kod | Adres → cel | Czas |
|---|---|---|---|
| 1 | 301 | http://cometweb.io/tools/obfuscator → https://cometweb.io/tools/obfuscator | 141 ms |
| 2 | 301 | https://cometweb.io/tools/obfuscator → /tools/code-obfuscator | 175 ms |
| 3 | 200 | https://cometweb.io/tools/code-obfuscator | 209 ms |
- Łańcuch przekierowań. Każdy krok to dodatkowe żądanie i opóźnienie, więc przekieruj od razu na adres końcowy. Przekierowań w łańcuchu:
2 - Adres http przekierowuje na https, tak powinno być.
| # | Kod | Adres → cel | Czas |
|---|---|---|---|
| 1 | 301 | https://google.com/ → https://www.google.com/ | 169 ms |
| 2 | 200 | https://www.google.com/ | 186 ms |
- Jedno stałe przekierowanie prosto do celu, tak powinno być.
Sprawdzanie przekierowań śledzi każdy podany adres krok po kroku i pokazuje cały łańcuch: kod odpowiedzi na każdym etapie, adres docelowy z nagłówka Location, czas i stronę końcową. Wskazuje łańcuchy dłuższe niż jedno przekierowanie, pętle, przekierowania tymczasowe tam, gdzie zwykle potrzebne jest stałe, przejście z https na http, stronę końcową z błędem i przekierowanie przez meta refresh. Nie wykona JavaScriptu, więc przekierowań robionych skryptem nie zobaczy.
Kiedy przekierowanie szkodzi?
Stałe i tymczasowe to dwa różne sygnały. Według Google przekierowanie 301 lub 308 mówi, że cel powinien stać się adresem kanonicznym. Za 302, 303 i 307 Googlebot podąża, ale nie traktuje ich jako takiego sygnału. Przy przenosinach strony, zmianie domeny albo przejściu na https używaj przekierowań stałych.
Łańcuch to zwykle ślad po kilku migracjach. Stary adres przekierowuje na nowszy, a ten na najnowszy. Każdy krok to kolejne żądanie; crawlery Google domyślnie przechodzą do 10 kroków, ale użytkownik czeka na każdy z nich. Popraw regułę tak, żeby pierwszy adres wskazywał od razu cel.
Meta refresh i JavaScript to rozwiązania awaryjne. Google odczytuje natychmiastowy meta refresh jak przekierowanie stałe, a opóźniony jak tymczasowe. Przekierowania w JavaScripcie może nie zobaczyć wcale, jeśli renderowanie się nie uda. To narzędzie wykrywa meta refresh na stronie końcowej, ale nie uruchamia skryptów.
Reguły przekierowań dla serwera Apache albo nginx przygotujesz w generatorze przekierowań, a sprawdzisz je tutaj po wdrożeniu.
Sprawdź wszystkie warianty adresu
Po migracji wklej po jednym adresie z każdego wariantu: http i https, z www i bez, z ukośnikiem na końcu i bez, stary adres z sitemapy i z linków zewnętrznych. Każdy powinien dojść do celu jednym przekierowaniem stałym.
Google Search Central, Redirects and Google SearchJak sprawdzić łańcuch przekierowań 301 i 302
Łańcuch przekierowań sprawdzasz od adresu, który ludzie i crawlery naprawdę odwiedzają, do strony, która odpowiada kodem 200. Cztery kroki wystarczą przy migracji i przy zwykłej kontroli.
-
Zbierz adresy wejściowe
Weź stare adresy z mapy migracji, linki z kampanii i wersje domeny:
http://,https://, zwwwi bez. Każdy wariant może przejść inną ścieżką. -
Wklej je i przeczytaj każdy krok
Narzędzie pokazuje kod, adres z nagłówka Location i czas każdego kroku. Szukaj więcej niż jednego przekierowania, kodów 302 tam, gdzie zmiana jest stała, i strony końcowej z błędem.
-
Popraw regułę u źródła
Zmień pierwszą regułę tak, żeby prowadziła od razu do adresu końcowego. Jeśli kroki robią dwie warstwy, na przykład CDN i aplikacja, jedna z nich musi znać adres docelowy.
-
Sprawdź ponownie i zaktualizuj linki
Po wdrożeniu wklej te same adresy jeszcze raz. Potem zmień linki wewnętrzne, sitemapę i canonical na adresy końcowe, żeby przekierowanie obsługiwało tylko ruch z zewnątrz.
Przykłady łańcuchów przekierowań i ich poprawek
Adresy na example.com są przykładowe. Kod przy każdym kroku to odpowiedź serwera.
http://example.com/oferta
301 → https://example.com/oferta
301 → https://example.com/uslugi
200http://example.com/oferta
301 → https://example.com/uslugi
200Reguła dla starej ścieżki obsługuje też wersję http, więc odwiedzający i crawler wykonują jedno żądanie mniej.
https://example.com/cennik-2025
302 → https://example.com/cennikhttps://example.com/cennik-2025
301 → https://example.com/cennikGoogle traktuje 301 i 308 jako mocny sygnał, że nowy adres ma zastąpić stary, a 302 i 307 jako słaby.
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}Jedna reguła kieruje każdy wariant http od razu na docelowy host https, bez pośredniego kroku przez https://www.
Najczęstsze błędy przy przekierowaniach
-
Łańcuchy po kolejnych migracjach
Każda migracja dokłada regułę na końcu łańcucha zamiast poprawić stare. Google zaleca unikać łańcuchów, bo dodają opóźnienie i nie każda przeglądarka obsługuje długie łańcuchy.
-
Wszystkie stare adresy na stronę główną
Odwiedzający szukał konkretnej treści i ląduje na stronie głównej bez wyjaśnienia. Kieruj każdy stary adres na najbliższy odpowiednik, a adresy bez odpowiednika zostaw z kodem 404 albo 410.
-
Sprzeczne reguły ukośnika albo www
Jedna reguła dodaje ukośnik na końcu, druga go usuwa, i powstaje pętla. To samo dzieje się, gdy CDN wymusza www, a aplikacja je zdejmuje.
-
Przekierowanie zostawione na 302
Domyślna funkcja w wielu frameworkach zwraca 302. Przy stałej zmianie adresu ustaw jawnie 301 albo 308, żeby wyszukiwarka zastąpiła stary adres nowym.
-
Usunięcie przekierowań po kilku tygodniach
Linki z innych stron i zakładki odwiedzających działają latami. Google zaleca trzymać przekierowania po przenosinach witryny co najmniej rok.
Przekierowania HTTP w dokumentacji Google i w RFC 9110
| Wartość | Co oznacza | Źródło |
|---|---|---|
| 10 | Tyle kroków przekierowania domyślnie wykonują crawlery Google. | Google Search Central, kody HTTP |
| 301, 308 | Kody, które Google traktuje jako mocny sygnał, że adres docelowy ma stać się kanoniczny. 302 i 307 to sygnał słaby. | Google Search Central, kody HTTP |
| 0 s | Meta refresh bez opóźnienia Google traktuje jak przekierowanie stałe, a z opóźnieniem jak tymczasowe. | Google Search Central, przekierowania |
| 1 rok | Tyle co najmniej Google zaleca utrzymywać przekierowania po przenosinach witryny. | Google Search Central, przenosiny witryny |
| 307, 308 | Te kody zachowują metodę żądania. Przy 301 i 302 przeglądarka może z powodów historycznych zamienić POST na GET. | IETF, RFC 9110, 15.4 |
Źródła sprawdzone:
Kody przekierowań
- 301Moved Permanently
- Stałe. Silny sygnał, że cel ma zastąpić stary adres.
- 308Permanent Redirect
- Stałe, jak 301, ale bez zmiany metody żądania.
- 302Found
- Tymczasowe. Google podąża, ale nie przenosi kanoniczności.
- 307Temporary Redirect
- Tymczasowe, jak 302, bez zmiany metody żądania.
Wpisz adres i kliknij „Sprawdź”. Narzędzie wyśle żądanie, odczyta kod odpowiedzi i nagłówek Location, a potem powtórzy to dla każdego kolejnego adresu, aż dojdzie do strony, która nie przekierowuje. Dostajesz cały łańcuch z kodem i czasem każdego kroku. Możesz sprawdzić do 10 adresów naraz.
301 oznacza przeniesienie na stałe, a 302 tymczasowe. Google traktuje 301 (i 308) jako sygnał, że adres docelowy powinien być kanoniczny, a za 302 (i 303, 307) podąża, ale takiego sygnału z niego nie bierze. Przy trwałej zmianie adresu używaj 301 albo 308.
To sytuacja, w której adres A przekierowuje na B, a B na C. Każdy krok wydłuża ładowanie, a zbyt długi łańcuch może nie zostać przejęty do końca, bo crawlery Google domyślnie podążają za najwyżej 10 przekierowaniami. Rozwiązanie: każda stara ścieżka powinna wskazywać bezpośrednio adres końcowy.
Łańcuch, który wraca do adresu, który już odwiedził, np. A → B → A. Przeglądarka po kilku próbach wyświetla błąd, a strona nigdy się nie wczyta. Najczęstsza przyczyna to sprzeczne reguły, na przykład jedna wymusza ukośnik na końcu, a druga go usuwa.
Nie. Śledzimy przekierowania z nagłówków HTTP i wykrywamy meta refresh na stronie końcowej, ale nie wykonujemy skryptów. Google ostrzega, że przekierowania w JavaScripcie może nie zobaczyć, jeśli renderowanie się nie uda, i zaleca je tylko wtedy, gdy nie da się zrobić przekierowania po stronie serwera.
Często pierwszy krok wykonuje CDN albo serwer, który zamienia http na https, a drugi robi to aplikacja, która przenosi stary adres na nowy. To łańcuch dwóch przekierowań. Jeśli to możliwe, dodaj regułę, która z adresu http kieruje od razu na końcowy adres https.
Adresy pobiera nasz serwer, więc trafiają do naszych logów. Wyników nie przechowujemy. Na każdym kroku łańcucha odrzucamy adresy prywatne i lokalne.
Kody 307 i 308 wybierz, gdy przekierowujesz formularz albo żądanie API i metoda nie może się zmienić. RFC 9110 pozwala przeglądarce zamienić POST na GET przy 301 i 302, a przy 307 i 308 metoda zostaje. Dla zwykłych stron 301 i 308 działają w Google tak samo.
Przekierowania po migracji trzymaj tak długo, jak się da, a Google zaleca co najmniej rok. W tym czasie zmień linki wewnętrzne i najważniejsze linki zewnętrzne na nowe adresy, żeby przekierowanie obsługiwało coraz mniej ruchu.
RFC 9110 nie podaje sztywnego limitu przekierowań, zaleca tylko, żeby klient wykrywał pętle. Wcześniejsza wersja specyfikacji zalecała najwyżej pięć, a RFC ostrzega, że część klientów może mieć taki stały limit. Najbezpieczniej mieć jeden krok.
Co jeszcze może Ci się przydać
Ten test sprawdza jedną rzecz na jednej stronie
Indeksowalność, metadane i struktura z priorytetami i raportem dla klienta.