Sprawdzanie przekierowań 301: cały łańcuch krok po kroku

Sprawdzanie przekierowań pokazuje, co naprawdę dzieje się między kliknięciem linku a wylądowaniem na stronie. Każdy wpisany adres jest żądany z serwera Marqly z wyłączonym automatycznym podążaniem za przekierowaniami, więc każda odpowiedź jest zapisywana osobno: kod statusu, nagłówek Location, na który wskazuje, czas odpowiedzi oraz nagłówki ważne dla SEO. Narzędzie podąża następnie za tym adresem i powtarza, do 10 przekierowań, czyli tyle, ile domyślnie śledzą roboty Google. Dostajesz pełny łańcuch przekierowań, końcowy adres i status oraz zrozumiałe ostrzeżenia o pętlach, przekierowaniach tymczasowych, wolnych przeskokach, zgubionych parametrach śledzących i łańcuchach, które warto skrócić.

Jak sprawdzić przekierowanie

1. Wklej adres URL do pola. Przy sprawdzaniu zbiorczym wklej do 10 adresów, po jednym w wierszu.
2. Wybierz agenta użytkownika, jeśli go potrzebujesz. Domyślny przedstawia się jako sprawdzanie Marqly; możesz też wysłać agenta Chrome, Safari na iPhonie, Googlebot smartphone lub Googlebot desktop, żeby wychwycić reguły traktujące przeglądarki, telefony i roboty inaczej.
3. Zaznacz Sprawdź też wersje http/https oraz www/bez www, żeby przetestować wszystkie cztery formy tego samego adresu naraz. To najszybszy sposób, żeby potwierdzić, że witryna ma jedną kanoniczną nazwę hosta i że każdy wariant dociera do niej jednym przeskokiem.
4. Naciśnij Sprawdź przekierowania. Każdy adres dostaje własną kartę z werdyktem, wskazówkami i łańcuchem krok po kroku.
5. Użyj Kopiuj wyniki, żeby dostać raport tekstowy, Pobierz CSV, żeby dostać arkusz z jednym wierszem na przeskok, albo Kopiuj link do udostępnienia, żeby wysłać link, który ponownie uruchamia to samo sprawdzenie.

Jak czytać wyniki

Każda karta zaczyna się od końcowego kodu statusu, wpisanego adresu, liczby przekierowań, łącznego czasu i końcowego adresu. Pod nią wskazówki zwracają uwagę na to, co zasługuje na uwagę: od błędów (pętle, łańcuchy przekraczające limit, łańcuch kończący się na 404), przez ostrzeżenia (przekierowania tymczasowe, meta refresh, zejście z https na http, zgubione parametry zapytania, X-Robots-Tag: noindex na stronie końcowej), po uwagi neutralne (zmiany ukośnika końcowego lub www, przeniesienie na inną domenę, wolne przeskoki).

Tabela łańcucha wymienia każde żądanie po kolei. Status to kod statusu HTTP zwrócony przez serwer.URL to to, co zostało zażądane, a pod spodem — dokąd ten przeskok kieruje klienta dalej, już rozwiązane do adresu bezwzględnego, gdy serwer wysłał względny Location.Czas to czas, w jakim serwer zwrócił nagłówki dla tego przeskoku. OtwórzNagłówki w dowolnym wierszu, żeby zobaczyć Location, Cache-Control,Content-Type, X-Robots-Tag, Link (gdzie można zadeklarować adres kanoniczny),Strict-Transport-Security, X-Redirect-By (WordPress i niektóre wtyczki się tu przedstawiają) oraz Server. Wartości plików cookie nie są nigdy pokazywane, tylko liczba ustawionych.

301, 302, 307 i 308: co znaczy każdy kod przekierowania

HTTP definiuje kody statusu przekierowań w RFC 9110, sekcja 15.4 (po angielsku). Dwa pytania je rozróżniają: czy przeniesienie jest trwałe oraz czy klient może zmienić metodę żądania (na przykład zamienić POST z formularza na GET) po podążeniu za przekierowaniem.Dokumentacja Google o kodach statusu HTTP (po angielsku) wyjaśnia, jak jego roboty i indeksowanie traktują każdy z nich.

Dla zwykłych stron używaj 301, gdy treść przeniosła się na stałe: zmieniona nazwa w adresie, połączony artykuł, migracja domeny, przejście na HTTPS. Używaj 302 lub 307, gdy oryginalny adres wróci, na przykład strona prac serwisowych, krótka kampania albo test. Sięgnij po308, gdy liczy się metoda, na przykład dla punktu końcowego API lub formularza przyjmującego żądania POST, bo RFC 9110 pozwala klientom zamienić przekierowany POST na GET przy 301 i 302, ale zabrania tego przy 307 i 308.

Meta refresh i przekierowania w JavaScripcie

Poradnik Google o przekierowaniach (po angielsku) zaleca, gdy to możliwe, stałe przekierowanie po stronie serwera. Natychmiastowy meta refresh traktuje jak przekierowanie stałe, a opóźniony jak tymczasowe, i radzi stosować przekierowania w JavaScripcie tylko wtedy, gdy nie da się użyć ani przekierowania serwerowego, ani meta refresh, bo renderowanie może zawieść. To narzędzie podąża za znacznikami meta refresh i nagłówkiem Refresh i je oznacza, ale nie uruchamia JavaScriptu.

Czym jest łańcuch przekierowań i dlaczego szkodzi?

Łańcuch przekierowań to każda ścieżka z więcej niż jednym przeskokiem: http://example.com/page →https://example.com/page → https://www.example.com/page →https://www.example.com/page/. Łańcuchy rzadko powstają celowo. Narastają, gdy witryna przechodzi na HTTPS, wybiera preferencję www, zmienia CMS, przemianowuje działy i przekierowuje stare przekierowania zamiast je przepisać. Każda warstwa działa osobno; razem się sumują.

• Szybkość. Każdy przeskok to kolejne pełne żądanie, zanim strona zacznie się ładować, a przeskok na nową nazwę hosta dokłada wyszukanie DNS i uzgodnienie TLS. Kolumna czasu pokazuje, ile kosztuje każdy przeskok.
• Indeksowanie. Google mówi, że jego roboty domyślnie podążają za maksymalnie 10 przeskokami przekierowań, a jego raport indeksowania stron wymienia zbyt długi łańcuch przekierowań, pętlę przekierowań oraz zły lub pusty adres URL w łańcuchu jako błędy przekierowania (po angielsku).Poradnik Google o przeniesieniu witryny (po angielsku) radzi przekierowywać bezpośrednio na adres docelowy, zaznaczając, że łączenie w łańcuch dodaje opóźnienie i że nie wszyscy agenci użytkownika i przeglądarki obsługują długie łańcuchy.
• Inni klienci. RFC 9110 zauważa, że wcześniejsza specyfikacja HTTP zalecała maksymalnie pięć przekierowań i że niektórzy klienci mogą nadal egzekwować taki stały limit, więc łańcuch, który toleruje Googlebot, może nadal zepsuć się dla innego oprogramowania.
• Kruchość i utrata danych. Każdy przeskok to kolejna reguła, którą można edytować, usunąć lub zasłonić. Przeskok, który przebudowuje adres, może po cichu zgubić ciągi zapytania, i właśnie tak znikają znaczniki UTM, zanim analityka je zobaczy; narzędzie ostrzega, gdy parametru z Twojego oryginalnego adresu brakuje w końcowym.

Jak naprawić łańcuch przekierowań

1. Znajdź końcowy adres. Przepuść stary adres przez narzędzie i skopiuj ostatni adres w łańcuchu.
2. Skieruj pierwsze przekierowanie na końcowy adres. Jeśli A przekierowuje do B, a B do C, zmień regułę A tak, żeby szła prosto do C, i zachowaj B → C dla każdego, kto nadal ma B. W mapie przekierowań lub wtyczce poszukaj reguł, których cel sam jest źródłem innej reguły.
3. Połącz reguły protokołu i nazwy hosta. Najczęstszy łańcuch to http → https, a potem bez www → www. Napisz jedną regułę, która wysyła każdy wariant do formy kanonicznej jednym krokiem, jak w tym przykładzie dla nginx:

# Jeden przeskok z każdego wariantu do https://www.example.com
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    # wiersze ssl_certificate pominięto
    return 301 https://www.example.com$request_uri;
}

4. Zaktualizuj linki u źródła. Zmień linki wewnętrzne, znaczniki canonical, adnotacje hreflang i mapy witryny XML na adresy końcowe; poradnik Google o przeniesieniu witryny prosi o aktualizację linków wewnętrznych do nowych adresów. Przekierowania mają łapać stare linki z zewnątrz, a nie nosić Twoją własną nawigację.
5. Zachowaj przekierowania. Google sugeruje utrzymywać przekierowania jak najdłużej, zazwyczaj co najmniej rok. Skracanie łańcucha oznacza zmianę celu, a nie usuwanie starych reguł.
6. Przetestuj ponownie. Uruchom te same adresy jeszcze raz, najlepiej z zaznaczoną opcją wariantów, i potwierdź, że każdy dociera do strony 200 jednym przeskokiem.

Naprawianie pętli przekierowań

Pętla to łańcuch, który wraca do już odwiedzonego adresu, więc nigdy się nie kończy; przeglądarki pokazują błąd zbyt wielu przekierowań. Zwykłe przyczyny to dwie warstwy, które się ze sobą nie zgadzają: CDN rozmawiający z serwerem źródłowym przez HTTP, podczas gdy ten wymusza HTTPS, reguła ukośnika końcowego w serwerze WWW walcząca z przeciwną regułą w aplikacji albo reguły www ustawione zarówno w przekierowaniu na poziomie DNS, jak i w witrynie. Spójrz na przeskok, w którym adres się odwraca; jego nagłówki Server i X-Redirect-By często mówią, która warstwa go wysłała. Niektóre pętle występują tylko bez plików cookie (przekierowania zgody lub logowania) i nie dotykają odwiedzających, którzy już je mają; narzędzie nie wysyła cookies, więc ujawnia także je.

Sprawdzanie przekierowań zbiorczo

Wklej do 10 adresów, po jednym w wierszu, żeby sprawdzić je jednym uruchomieniem; duplikaty są usuwane, a każdy adres dostaje własny wynik. Eksport CSV ma jeden wiersz na przeskok z powtórzonym adresem wejściowym, więc możesz filtrować po statusie, sortować po liczbie przeskoków albo przekazać plik osobie odpowiedzialnej za reguły przekierowań. Dla listy starych zakładek lub linków z dokumentu najpierw wyciągnij adresyprzeglądarką plików zakładek (po angielsku), a potem sprawdź, które są po prostu martwe,sprawdzaniem martwych linków, które przyjmuje 25 adresów na uruchomienie. Dla całej witryny użyj crawlera lub logów serwera, żeby znaleźć przekierowane adresy, a potem wyrywkowo sprawdź tu ważne z agentem Googlebot.

HTTPS, www i ukośniki końcowe

Większość witryn powinna odpowiadać na dokładnie jednej kombinacji protokołu i nazwy hosta, a każda inna forma ma przekierowywać do niej na stałe i jednym przeskokiem. Opcja wariantów sprawdza http://example.com,https://example.com, http://www.example.com i https://www.example.comz tą samą ścieżką i zgłasza, czy wszystkie cztery kończą na tym samym adresie i ile przeskoków zajmuje każdy. Wskazówki zwracają uwagę na podniesienie do HTTPS, które następuje późno w łańcuchu, na łańcuch przełączający się między www i bez www więcej niż raz oraz na przeskoki, które tylko dodają lub usuwają ukośnik końcowy albo zmieniają wielkość liter, a które tanio da się wchłonąć w pierwsze przekierowanie.

Dlaczego wyniki mogą różnić się od przeglądarki

Jeśli Twoja przeglądarka ląduje gdzie indziej, zwykle coś pamięta. RFC 9110 pozwala buforować 301, więc przeglądarka może pominąć stare przekierowanie albo dalej podążać za takim, które już usunąłeś. Gdy przeglądarka zobaczy nagłówek HSTS witryny (albo witryna jest na liście preload HSTS), podnosi http:// do https:// wewnętrznie, zanim jakiekolwiek żądanie opuści Twój komputer. Pliki cookie, język i lokalizacja mogą wywoływać własne przekierowania. Narzędzie za każdym razem startuje od zera i zgłasza to, co wysyła serwer, a ten widok liczy się dla robotów i odwiedzających po raz pierwszy.

Jak działa sprawdzanie

Każdy przeskok to żądanie GET z serwera Marqly w Cloudflare z przekierowaniami ustawionymi na ręczne, więc nic nie jest śledzone, dopóki narzędzie tego nie zapisze. Każda nazwa hosta jest rozwiązywana i musi wskazywać publiczny adres; sieci prywatne, localhost i adresy metadanych chmury są odrzucane, także gdy przekierowanie wskazuje na nie w środku łańcucha. Każdy przeskok ma limit 6 sekund, cały łańcuch zatrzymuje się po 20 sekundach lub 10 przekierowaniach, a treści stron są odrzucane poza pierwszymi 64 KB końcowej strony HTML, które są skanowane pod kątem meta refresh. Nic nie jest przechowywane: wyniki istnieją tylko w karcie Twojej przeglądarki.

Zanim udostępnisz link, który przeszedł przez przekierowanie lub skracacz linków, usuń śmieci śledząceczyszczeniem linków URL. Jeśli budujesz linki kampanii,generator UTM je tworzy, a to narzędzie potwierdza, że parametry przeżywają każdy przeskok. Gdy strona końcowa się załaduje, sprawdź tytuł, opis i podgląd w mediach społecznościowych, które serwuje,sprawdzaniem Open Graph (po angielsku).