Co mówi kod odpowiedzi, a czego nie mówi
Kod HTTP opisuje wynik konkretnego żądania skierowanego do serwera. Odpowiedzi 4xx wskazują, że żądanie nie mogło zostać obsłużone w oczekiwany sposób, na przykład dlatego, że zasób nie istnieje albo dostęp do niego jest ograniczony. Kody 5xx oznaczają problem po stronie serwera lub infrastruktury obsługującej żądanie. Sam kod nie wyjaśnia jednak przyczyny ani nie rozstrzyga, czy dana sytuacja wymaga naprawy.
W audycie warto patrzeć przede wszystkim na rolę adresu. Odpowiedź 404 dla dawno usuniętej podstrony, do której witryna już nie odsyła, może być poprawna. Ten sam kod dla strony produktu dostępnej w menu oznacza niedziałającą ścieżkę użytkownika. Z kolei 503 na stronie głównej podczas krótkiej przerwy technicznej wymaga innej oceny niż 503 powracający regularnie. Znaczenie mają więc adres, źródło linku, częstotliwość błędu i to, czy strona powinna być publicznie dostępna.
Jak zebrać adresy do sprawdzenia
Zacznij od przejścia po witrynie narzędziem do crawlowania i wyeksportuj adresy zwracające 4xx lub 5xx wraz ze stronami, które do nich prowadzą. Sprawdź też mapę XML, nawigację, linki w treści i ważne odnośniki z innych serwisów, jeśli masz o nich informacje. Dane z narzędzi dla właścicieli witryn oraz logi serwera mogą uzupełnić obraz o adresy odwiedzane przez roboty, których nie znalazł prosty crawl. Żadne pojedyncze źródło nie musi pokazywać całej sytuacji.
Przy weryfikacji zapisuj nie tylko URL i kod, lecz także datę testu, wersję adresu oraz sposób wykonania żądania. Wynik może się różnić dla adresu z ukośnikiem i bez niego, wersji HTTP i HTTPS albo różnych urządzeń i lokalizacji. Jeśli narzędzie zgłasza błąd, otwórz adres także w przeglądarce i ponów żądanie. Jednorazowa odpowiedź 5xx nie dowodzi trwałej awarii; z drugiej strony działająca teraz strona nie wyklucza wcześniejszych problemów widocznych w logach.
Jak oceniać odpowiedzi 4xx
Najczęściej spotkasz 404, czyli brak zasobu. Kod 410 również wskazuje, że zasób jest niedostępny, ale wyraźniej komunikuje jego usunięcie. Jeśli podstrona została trwale wycofana i nie ma odpowiednika, pozostawienie odpowiedzi 404 lub 410 może być właściwe. Usuń wtedy prowadzące do niej linki wewnętrzne i nie umieszczaj jej w mapie XML. Gdy treść zmieniła adres, sprawdź, czy przekierowanie prowadzi do rzeczywiście odpowiadającej jej strony. Przekierowywanie wszystkich brakujących adresów na stronę główną zwykle utrudnia użytkownikom znalezienie tego, czego szukali.
Kody 401 i 403 dotyczą ograniczenia dostępu. Mogą być zamierzone dla panelu klienta, ale nie dla publicznej kategorii sklepu. Kod 429 sygnalizuje zbyt wiele żądań i warto sprawdzić, czy limit nie obejmuje także potrzebnych wizyt robotów. Nie ograniczaj kontroli do samych kodów: strona z komunikatem „nie znaleziono”, która zwraca 200, również wymaga uwagi. Serwer informuje wówczas o powodzeniu, choć zawartość sugeruje brak strony.
Jak diagnozować odpowiedzi 5xx
Kod 500 oznacza ogólny błąd serwera, 502 często wskazuje problem w komunikacji między serwerami, 503 informuje o czasowej niedostępności usługi, a 504 o przekroczeniu czasu oczekiwania na odpowiedź. Te nazwy pomagają rozpocząć diagnostykę, ale nie zastępują logów aplikacji i serwera. Przyczyną może być między innymi błąd aplikacji, przeciążenie, niedostępna zależność albo nieudane wdrożenie. Nie da się jej wiarygodnie ustalić wyłącznie na podstawie numeru kodu.
Sprawdź, czy błędy występują dla wszystkich adresów, czy tylko dla określonego szablonu, na przykład kart produktów. Porównaj czas wystąpienia błędów z zapisami w logach i zmianami w witrynie, a po poprawce powtórz test. Podczas planowanej, krótkiej niedostępności odpowiedź 503 może lepiej opisywać sytuację niż strona błędu zwracająca 200; serwer może wtedy przekazać również informację o przewidywanym czasie ponownej próby. Ważne, by stan tymczasowy nie pozostał na stałe.
Ustal priorytety i wykonaj kontrolę po poprawkach
Najpierw zajmij się błędami na adresach potrzebnych użytkownikom: stronie głównej, ważnych kategoriach, aktualnych produktach i podstronach, do których prowadzi nawigacja. Wyżej ustaw także powtarzające się 5xx oraz błędy obejmujące wiele stron. Pojedynczy 404 dla nieistniejącego adresu ma zwykle niższy priorytet, o ile nie prowadzą do niego istotne linki. Celem audytu nie jest uzyskanie zera odpowiedzi 4xx, lecz usunięcie usterek i zachowanie poprawnych odpowiedzi dla zasobów, których rzeczywiście nie ma.
Na koniec przejdź krótką checklistę: czy ważne adresy zwracają oczekiwany kod, czy linki wewnętrzne prowadzą do działających stron, czy mapa XML nie zawiera usuniętych URL-i i czy przekierowania mają sens dla odbiorcy? Sprawdź ponownie problematyczne adresy po wdrożeniu zmian, a przy sporadycznych 5xx obserwuj logi przez pewien czas. Taka kontrola pozwala odróżnić skuteczną poprawkę od chwilowo udanego testu, choć sama w sobie nie gwarantuje określonej widoczności w wyszukiwarce.
