Sprawdzanie przekierowań pozwala prześledzić przekierowania HTTP jednego publicznego adresu URL i odczytać odpowiedź otrzymaną na końcu. Raport pokazuje zaobserwowane adresy, kody statusu i cele przekierowań. Porównaj te dane z miejscem, do którego powinien prowadzić link: ukończony łańcuch nadal może kończyć się na niewłaściwej stronie, a nieukończone sprawdzenie nie potwierdza końcowego adresu.
Wprowadź adres URL, który wymaga sprawdzenia
Zacznij od adresu rzeczywiście używanego przez użytkowników, wraz ze ścieżką i istotnymi parametrami zapytania. Sprawdzenie samej strony głównej nie wyjaśni, co dzieje się ze starym linkiem do produktu. Przykładowo http://example.com/products/old-mug/ ilustruje adres źródłowy; zastąp go publicznym adresem, który chcesz zbadać.
Przed wysłaniem ustal oczekiwany cel i zdecyduj, czy przeniesienie powinno być trwałe, czy tymczasowe. Po zmianie adresu produktu może to być ten sam produkt pod nowym adresem. Podczas chwilowej przerwy w działaniu usługi pierwotny adres może nadal pełnić rolę stałego punktu wejścia.
Wprowadź jeden pełny adres HTTP lub HTTPS i uruchom sprawdzenie. Screpy wysyła żądanie GET i podąża za obsługiwanymi przekierowaniami HTTP. Narzędzie nie odkrywa wszystkich wariantów domeny, nie korzysta z zalogowanej sesji przeglądarki i nie wykonuje skryptów. Aby porównać różne ścieżki, protokoły lub nazwy hostów, sprawdź te adresy źródłowe osobno.
Odczytaj łańcuch przekierowań i końcową odpowiedź
Czytaj wiersze odpowiedzi po kolei. Każdy podaje żądany adres URL, status HTTP i cel Location, jeśli obsługiwane przekierowanie go wskazuje. Wartości Location są przedstawiane jako rozstrzygnięte, pełne adresy. Jeśli odpowiedź wskazuje /products/new-mug/, raport wyznacza adres względem URL, który wysłał tę odpowiedź. Wyświetlony adres nie musi więc być dosłownym tekstem oryginalnego nagłówka.
Ten przykładowy łańcuch ma trzy odpowiedzi i dwa przekierowania. To ilustracja, nie wynik skanowania rzeczywistej witryny:
http://example.com/products/old-mug/ 301 → https://example.com/products/old-mug/
https://example.com/products/old-mug/ 301 → https://example.com/products/new-mug/
https://example.com/products/new-mug/ 200
Pierwszy status to 301, końcowy status to 200, a końcowy URL jest nowym adresem produktu. Ostatni wiersz 200 oznacza odpowiedź, a nie dodatkowe przekierowanie. Przy ukończonym sprawdzeniu liczba przekierowań opisuje przejścia między zaobserwowanymi odpowiedziami. Jeśli sprawdzenie zatrzyma się wcześniej, odczytuj tę liczbę razem z zachowanymi wierszami, zamiast traktować ją jako pełną długość łańcucha.
Interpretuj kolor wyniku razem z tymi szczegółami:
- Zielony: bezpośrednia poprawna odpowiedź bez przekierowań, za którymi podążono. To przydatny wynik, gdy adres powinien już być docelowy.
- Żółty: przekierowanie, nawet jeśli kończy się poprawną odpowiedzią, lub inna odpowiedź wymagająca oceny. Żółte przekierowanie nie oznacza automatycznie niedziałającego linku.
- Czerwony: końcowa odpowiedź z błędem HTTP, na przykład 404 lub 500. Sprawdź cel i kod, zanim zdecydujesz, co naprawić.
- Szary: nie udało się ustalić końcowej odpowiedzi. Zachowane wiersze są częściowymi dowodami.
Kolory opisują kategorie odpowiedzi. Nie oceniają treści strony, nie dowodzą indeksowania i nie rozstrzygają, czy przekierowanie odpowiada Twojemu zamiarowi.
Zrozum kody 301, 302, 303, 307 i 308
Najpierw wybierz zamierzone zachowanie, potem status. Narzędzie podąża za tymi pięcioma kodami przekierowań:
| Kod | Znaczenie HTTP | Co sprawdzić |
|---|---|---|
| 301 | Trwałe przeniesienie | Czy przyszłe linki powinny używać nowego adresu? |
| 302 | Tymczasowe przeniesienie | Czy pierwotny adres ma pozostać w użyciu? |
| 303 | Odpowiedź można odczytać w innym zasobie | Czy to zamierzony kolejny zasób, a nie trwałe zastąpienie? |
| 307 | Tymczasowe przekierowanie zachowujące metodę żądania | Czy zamierzono tymczasowe przekierowanie bez zmiany metody? |
| 308 | Trwałe przekierowanie zachowujące metodę żądania | Czy zamierzono trwałe przeniesienie bez zmiany metody? |
Różnice wynikają z semantyki przekierowań HTTP w RFC 9110. Sprawdzenie używające wyłącznie GET nie potwierdzi, co stanie się z wysłanym żądaniem POST ani jego treścią. Obecność 307 lub 308 w raporcie nie jest testem wysyłania formularza.
Wytyczne Google dotyczące przekierowań zalecają trwałe przekierowania po stronie serwera dla trwałych zmian URL. Google wykorzystuje je jako sygnał przemawiający za wyborem celu jako adresu kanonicznego; przekierowania tymczasowe służą innemu celowi. Nie oznacza to, że każde 302 jest błędem SEO ani że 301 natychmiast zmieni wyniki wyszukiwania.
Jeśli trwałe przeniesienie niespodziewanie zwraca kod tymczasowy, sprawdź regułę, która go wygenerowała. Przy zamierzonym tymczasowym obejściu nie zmieniaj statusu wyłącznie po to, aby wynik wyglądał korzystniej.
Sprawdź, czy cel jest właściwą stroną
Ukończony łańcuch pokazuje, gdzie zakończyło się to żądanie. Nie dowodzi, że strona jest odpowiednim zastępstwem. Narzędzie odczytuje statusy odpowiedzi i cele przekierowań, bez badania treści końcowej strony.
Porównaj końcowy URL z celem ustalonym przed sprawdzeniem. Oceń nazwę hosta, ścieżkę i istotne parametry zapytania. Stary link do produktu kończący się na stronie głównej z kodem 200 nadal może nie spełniać potrzeb odwiedzającego. Otwórz cel i ustal, czy zawiera właściwy produkt, artykuł lub inne odpowiednie zastępstwo. Jeśli odpowiedniego zastępstwa nie ma, nie wymyślaj go tylko po to, by usunąć błąd z raportu.
Sprawdź też ostrzeżenie o przejściu z HTTPS na HTTP. Ustal, czy reguła wskazuje zamierzony bezpieczny adres, i popraw niezamierzone przejście na HTTP. Ostrzeżenie opisuje tę zmianę; nie stanowi audytu bezpieczeństwa celu.
Dla strony, która ma pojawiać się w wyszukiwaniu, użyj osobno Sprawdzania tagów canonical, aby odczytać zadeklarowany preferowany URL. Udane przekierowanie nie potwierdza deklaracji canonical, braku noindex ani decyzji Google o indeksowaniu. Poprawny łańcuch HTTP i poprawna deklaracja na stronie to różne obserwacje.
Zdiagnozuj nieukończony łańcuch
Gdy końcowy URL lub status nie jest dostępny, zacznij od ostatniej faktycznie zapisanej odpowiedzi. Location wskazuje miejsce, do którego ta odpowiedź chciała skierować żądanie. Nie dowodzi, że kolejny adres został osiągnięty lub zwrócił poprawną odpowiedź. Wynik niedostępny różni się też od zaobserwowanego błędu HTTP: przekroczenie czasu nie daje potwierdzonego końcowego kodu, natomiast otrzymana odpowiedź może wyraźnie zwrócić 404 lub 403.
Użyj zachowanych wierszy, aby zawęzić diagnozę:
- Powtarzające się adresy: przykładowa sekwencja
A → B → Ajest pętlą. Sprawdź reguły kierujące żądanie z powrotem do odwiedzonego już URL, na przykład sprzeczne reguły nazw hostów lub ścieżek. - Długa sekwencja bez powtórzeń: narzędzie podąża za najwyżej pięcioma przekierowaniami. Osiągnięcie limitu nie dowodzi pętli ani nie ujawnia reszty łańcucha. Sprawdź ostatni zapisany cel osobno.
- Status przekierowania bez użytecznego celu: sprawdź, czy odpowiedź podaje prawidłowe Location. Brakującego lub nieprawidłowego celu nie można traktować jako ukończonego przeniesienia.
- Brak następnej odpowiedzi: problemy z dostępem publicznym, rozwiązywaniem nazw, połączeniem lub bezpiecznym połączeniem mogą uniemożliwić sprawdzenie. Cały łańcuch URL ma osiem sekund, nie osiem na każdy krok. Limity nagłówków odpowiedzi oraz prywatne lub nieobsługiwane cele także mogą zatrzymać sprawdzenie.
Jeśli cel zwraca ograniczenie dostępu lub liczby żądań, zbadaj ten stan, zanim uznasz, że treść została usunięta. Żądanie narzędzia może otrzymać inną odpowiedź niż Twoja zalogowana przeglądarka. Przekierowania JavaScript, meta refresh i zachowanie przeglądarki są poza zakresem sprawdzenia, więc wynik HTTP nie wyjaśnia każdej nawigacji widocznej na ekranie.
Napraw przyczynę i ponownie sprawdź ten sam URL
Pobierz raport JSON przed zmianą reguły. Zachowaj z nim wysłany URL i zamierzony cel, aby osoba wykonująca poprawkę mogła odróżnić zachowanie zaobserwowane od oczekiwanego. Narzędzie eksportuje raport jako JSON; nie udostępnia filtrowanego CSV i nie zmienia przekierowań za Ciebie.
- Znajdź odpowiedź, w której adres lub status po raz pierwszy odbiega od Twojego zamiaru. Zlokalizuj ustawienie generujące tę odpowiedź, zamiast zmieniać niezwiązane z nią metadane strony.
- Popraw niezamierzony cel, status, pętlę lub przejście na HTTP. Usuń zbędne etapy pośrednie tam, gdzie kontrolujesz reguły, zachowując routing lub śledzenie mające świadomy cel. Kieruj linki wewnętrzne bezpośrednio do zamierzonego adresu, jeśli służy to zadaniu odwiedzającego.
- Sprawdź dokładnie ten sam źródłowy URL, gdy poprawiona publiczna odpowiedź jest dostępna. Porównaj sekwencję, pierwszy i ostatni kod, końcowy adres oraz nadal niedostępne dane z zapisanym raportem.
- Osobno sprawdź istotne warianty źródła, na przykład starą ścieżkę lub inną nazwę hosta. Naprawa jednego adresu nie potwierdza poprawności wszystkich mapowań w migracji.
Użyj Zbiorczego sprawdzania statusu HTTP, gdy masz listę do oceny. Przyjmuje do 50 URL i obsługuje eksport filtrowanego CSV. Narzędzie do sprawdzania jednego adresu służy do dokładnego odczytania jednego łańcucha. Udane ponowne sprawdzenie potwierdza odpowiedź zaobserwowaną teraz; nie dowodzi, że przyszły odwiedzający, przeglądarka lub robot wyszukiwarki otrzyma identyczne zachowanie.