Kody HTTP a SEO: 401, 403, 404, 5xx i soft 404

Kod odpowiedzi HTTP to pierwsza informacja, jaką Googlebot dostaje od serwera, i to od niego zależy, czy Google w ogóle zajmie się treścią strony. Według dokumentacji Google treści z URL-i zwracających kody 4xx, w tym 401, 403, 404 i 410, nie są używane, a zaindeksowane URL-e z takim kodem wypadają z indeksu. Kody 5xx i 429 spowalniają skanowanie serwisu, a uporczywe błędy serwera też kończą się usunięciem z indeksu. Soft 404 to strona z kodem 200, która wygląda na błąd: Google wyklucza ją z wyników, choć serwer twierdzi, że wszystko jest w porządku.

Jak Google traktuje kody 4xx i 5xx

Każda odpowiedź serwera zaczyna się od trzycyfrowego kodu stanu. Przeglądarka zwykle go nie pokazuje, dopóki coś nie pójdzie źle, ale robot wyszukiwarki czyta go przy każdym pobraniu strony i na jego podstawie decyduje, co zrobić dalej. Kod to pierwsze, co robot ocenia podczas skanowania strony, zanim ktokolwiek zajrzy do treści.

Google opisuje to w dokumentacji o wpływie kodów HTTP na roboty Google. Wynika z niej podział na trzy grupy, który warto mieć w głowie przy każdej rozmowie o błędach:

• 2xx (sukces). Google przekazuje pobraną treść dalej, w wyszukiwarce do systemów indeksujących. Dokumentacja zastrzega jednak, że kod 2xx nie gwarantuje indeksowania: o tym decyduje dopiero ocena samej treści.
• 4xx (błędy klienta). Google nie używa treści z takich URL-i. Nowe URL-e z kodem 4xx nie trafiają do indeksu, a te, które w nim już są, zostają z niego usunięte. Wszystkie kody 4xx poza 429 Google traktuje jednakowo, jako informację, że treść nie istnieje.
• 5xx (błędy serwera) i 429. To dla Google sygnał, że serwer ma kłopot. Robot tymczasowo zwalnia, zaindeksowane URL-e na razie zostają w indeksie, ale przy uporczywych błędach z niego wypadają.

Search Console generuje komunikaty o błędach dla kodów z zakresu 4xx–5xx i dla nieudanych przekierowań. Dlatego te same kody, które dla użytkownika są tylko nieprzyjemnym ekranem, w raportach wyszukiwarki zamieniają się w listę URL-i, które z indeksu wypadły albo do niego nie weszły.

Błąd 401 i 403: strona za logowaniem albo zablokowana

Kod 401 (Unauthorized) oznacza, że żądanie nie zostało wykonane, bo zabrakło ważnych danych uwierzytelniających. Serwer, który go zwraca, musi w nagłówku WWW-Authenticate wskazać, jak się uwierzytelnić. Tak stanowi specyfikacja HTTP, RFC 9110. W praktyce „401 error” widzi ten, kto próbuje wejść na stronę albo do API bez zalogowania, z wygasłą sesją lub z nieważnym kluczem.

Kod 403 (Forbidden) mówi coś innego: serwer zrozumiał żądanie, ale odmawia jego wykonania. Dane logowania niewiele tu zmienią, bo odmowa może wynikać z zupełnie innych powodów, na przykład z reguł dostępu albo blokady po stronie zapory. Specyfikacja dopuszcza też, żeby serwer, który nie chce zdradzać istnienia zasobu, odpowiedział zamiast tego kodem 404.

Dla Google różnica między tymi kodami nie ma znaczenia. Oba należą do grupy 4xx, więc strona za logowaniem jest dla robota stroną, której nie ma. Google w podstawach JavaScript SEO podaje zresztą 401 jako właściwy kod dla stron za logowaniem. Jeśli treść ma być w wyszukiwarce, nie może się chować ani za 401, ani za 403.

Dokumentacja zawiera przy tych kodach wyraźne ostrzeżenie: nie należy używać 401 i 403 do ograniczania tempa skanowania. Kody 4xx poza 429 nie mają na nie żadnego wpływu, więc zamiast odciążyć serwer, po prostu wyrzucają strony z indeksu.

Osobnym przypadkiem jest sam plik robots.txt. Jeśli zwraca 401 albo 403, Google według specyfikacji robots.txt zachowuje się tak, jakby pliku nie było, i zakłada brak jakichkolwiek ograniczeń. Więcej o tym pliku piszemy w przewodniku po robots.txt.

W audytach regularnie trafiamy na sytuację, której właściciel strony nie jest świadomy: w przeglądarce wszystko działa, a robot dostaje 403, bo zapora aplikacji albo usługa ochrony przed botami uznała go za intruza. Sam właściciel zawsze widzi kod 200, więc problem wychodzi dopiero w raportach. Dlatego kod sprawdzamy narzędziem URL Inspection w Search Console, które według dokumentacji Google pokazuje kod zwrócony robotowi i wyrenderowaną stronę, a nie tylko w przeglądarce.

Błąd 404 i 410: strony nie ma

Co oznacza błąd 404? Serwer nie znalazł pod danym URL-em aktualnej wersji strony albo nie chce zdradzić, że ona istnieje. Według RFC 9110 kod 404 nie mówi, czy brak jest chwilowy, czy trwały. Jeśli serwer wie, że strona zniknęła na dobre, specyfikacja zaleca kod 410 (Gone). Typowe przyczyny to literówka w linku, usunięta strona albo strona przeniesiona pod nowy URL bez przekierowania.

W dokumentacji Google kody 404 i 410 są traktowane tak samo jak wszystkie kody 4xx poza 429. Dokumentacja dodaje, że nowo napotkane strony 404 nie są przetwarzane, a częstotliwość ich skanowania stopniowo spada. W dokumentacji o budżecie skanowania Google zaleca zwracać 404 lub 410 dla stron usuniętych na stałe i wyjaśnia, że nie zapomina URL-i, które zna, ale kod 404 jest silnym sygnałem, by danego URL-a więcej nie pobierać. URL zablokowany w robots.txt zostaje natomiast w kolejce znacznie dłużej. Dla serwisów, w których budżet skanowania ma znaczenie, to istotna różnica.

Jak więc naprawić błąd 404? Zacząć od pytania, czy to w ogóle błąd. Dokumentacja Google rozpisuje trzy sytuacje:

• Strona przeniosła się albo ma wyraźny odpowiednik. Wtedy właściwe jest przekierowanie 301, które prowadzi i człowieka, i robota pod nowy URL.
• Strony nie ma i nie ma odpowiednika. Kod 404 albo 410 jest wtedy poprawną odpowiedzią i niczego nie trzeba naprawiać.
• Strona istnieje, a zwraca 404. To jest prawdziwy błąd, zwykle w konfiguracji serwera albo systemu zarządzania treścią.

Własna strona 404 powinna pomagać ludziom: jasno mówić, że strony nie znaleziono, mieć ten sam wygląd i nawigację co reszta serwisu, odsyłać do popularnych treści i do strony głównej. Google przypomina, że taka strona jest wyłącznie dla ludzi, więc serwer musi przy niej zwracać kod 404, a nie 200. Martwe URL-e powstają masowo zwykle przy przebudowie i przenosinach serwisu, dlatego mapę przekierowań opisujemy osobno w checkliście migracji strony.

Soft 404: strona, która udaje, że działa

Soft 404 to przypadek odwrotny do poprzednich: serwer zwraca kod 200, czyli sukces, a strona mówi użytkownikowi, że niczego tu nie ma. Według dokumentacji Google o rozwiązywaniu problemów ze skanowaniem może to być też strona bez głównej treści albo zupełnie pusta. Google wymienia typowe źródła: brak pliku dołączanego po stronie serwera, zerwane połączenie z bazą danych, pusta strona wyników wewnętrznej wyszukiwarki, niewczytany plik JavaScript.

Takie strony są wykluczane z wyników. Gdy algorytmy Google rozpoznają po treści, że strona jest w rzeczywistości stroną błędu, Search Console pokazuje soft 404 w raporcie indeksowania stron (Page Indexing). Dokumentacja o budżecie skanowania dodaje drugi koszt: strony soft 404 są dalej skanowane i zużywają budżet, który mógłby pójść na ważne podstrony.

Naprawa zależy od tego, co naprawdę dzieje się ze stroną. Jeśli treści już nie ma, Google zaleca kod 404 albo 410. Jeśli treść przeniosła się w inne miejsce, przekierowanie 301. Jeśli strona jest dobra, a mimo to dostała etykietę soft 404, najpewniej nie wczytała się Googlebotowi poprawnie: zabrakło jej kluczowych zasobów albo podczas renderowania pokazała wyraźny komunikat o błędzie. Przyczyną bywają zasoby zablokowane w robots.txt, zbyt wiele zasobów na stronie, błędy serwera albo zasoby wolne i bardzo duże.

Aplikacje renderowane w przeglądarce mają tu własny kłopot, bo nawigacja odbywa się bez nowego zapytania do serwera i trudno zwrócić właściwy kod. Google podaje dwa wyjścia: przekierowanie skryptem na URL, pod którym serwer odpowiada kodem 404, albo dodanie do strony błędu znacznika meta robots z wartością noindex.

W audytach Search Console najczęściej oznacza jako soft 404 cztery rodzaje stron: puste kategorie i listy ofert, wyniki wewnętrznej wyszukiwarki bez trafień, strony wycofanych produktów lub usług, które dalej zwracają 200 z dopiskiem o niedostępności, oraz aplikacje renderowane w przeglądarce, które pokazują komunikat o błędzie, nie zmieniając kodu odpowiedzi.

Błędy 5xx, przestoje i kod 503

Kody 5xx mówią, że zawiódł serwer, a nie żądanie. Google reaguje na nie inaczej niż na 4xx: zamiast uznać, że treści nie ma, tymczasowo zwalnia skanowanie. Zaindeksowane URL-e zostają w indeksie, ale nie w nieskończoność. Przy kodzie 500 spowolnienie jest proporcjonalne do liczby URL-i, które zwracają błąd, a URL-e uporczywie zwracające błąd serwera system indeksujący z czasem usuwa. Gdy serwer znów odpowiada kodem 2xx, Google stopniowo przywraca tempo skanowania.

Ważne jest to, że skutek nie ogranicza się do stron z błędem. Według dokumentacji o ograniczaniu tempa skanowania, gdy robot napotka znaczną liczbę odpowiedzi 500, 503 albo 429, zwalnia na całej nazwie hosta, także na URL-ach, które zwracają treść poprawnie. Awaria jednej sekcji serwisu potrafi więc spowolnić skanowanie wszystkiego.

Planowany przestój to sytuacja, w której kod 503 (Service Unavailable) jest najlepszym wyborem. W dokumentacji o czasowym wyłączeniu witryny Google zaleca, by przy wyłączeniu na dzień lub dwa zwracać zamiast treści stronę informacyjną z kodem 503. Przy dłuższym wyłączeniu lepiej zostawić indeksowalną stronę główną z kodem 200 jako zastępstwo. Dokumentacja wylicza dobre praktyki: nagłówek Retry-After z przewidywanym terminem, statyczny HTML, jasna informacja dla ludzi, kiedy strona wróci. Ostrzega też, że w czasie 503 Google nie odświeży tytułów, opisów ani danych strukturalnych.

To nie jest nowa rada. Już we wpisie na blogu Google z 25 stycznia 2011 roku, o planowanych przestojach, zespół jakości wyszukiwania pisał, że 503 jest lepsze niż 404 albo strona błędu z kodem 200, i że długo utrzymywane 503 może zostać uznane za znak trwałej niedostępności serwera i skończyć się usunięciem URL-i z indeksu. Google oznacza dziś ten wpis jako starszy i odsyła do aktualnych zaleceń, ale obie zasady przetrwały w obecnej dokumentacji.

Jest jeden plik, któremu nie wolno zwracać 503: robots.txt. Dokumentacja mówi wprost, że 503 na robots.txt blokuje całe skanowanie. Specyfikacja opisuje dokładny przebieg: przez pierwsze 12 godzin Google wstrzymuje skanowanie serwisu i ponawia próby pobrania pliku; przez kolejne 30 dni korzysta z ostatniej poprawnej wersji; a jeśli błędy trwają dłużej, zachowuje się tak, jakby pliku nie było, o ile serwis poza tym działa, albo przestaje go skanować, jeśli problemy z dostępnością dotyczą całego serwisu. To jeden z niewielu przypadków, w których pojedynczy plik decyduje o dostępności całej witryny dla robota.

Kod 400 i kod 429

Kod 400 (Bad Request) oznacza według RFC 9110, że serwer nie może albo nie chce przetworzyć żądania z powodu czegoś, co uznał za błąd po stronie klienta: zniekształconej składni, nieprawidłowej budowy żądania albo podejrzanego kierowania ruchu. Gdy „400 error” widzi użytkownik, przyczyna leży zwykle w samym żądaniu, na przykład w źle zbudowanym linku, a nie w treści strony. Dla Google to zwykły kod z grupy 4xx: treść jest traktowana jak nieistniejąca, a zaindeksowany URL wypada z indeksu.

Kod 429 (Too Many Requests) zdefiniowano w RFC 6585 jako sygnał, że klient wysłał zbyt wiele żądań w danym czasie, czyli ograniczanie liczby zapytań. Odpowiedź może zawierać nagłówek Retry-After z informacją, ile odczekać. To jedyny kod 4xx, który Google traktuje inaczej: jako znak przeciążenia serwera, czyli tak jak błąd serwera. Googlebot zwalnia skanowanie, tak jak przy 5xx.

Wynikają z tego dwie praktyczne rzeczy. Po pierwsze, 503 i 429 to zalecany przez Google sposób na doraźne odciążenie serwera: dokumentacja o rozwiązywaniu problemów zaleca zwracać je tymczasowo, gdy Googlebot przeciąża stronę, bo robot ponawia takie URL-e przez około dwa dni. Po drugie, ten sam mechanizm działa przeciwko stronie, jeśli trwa za długo. Zwracanie 503 lub 429 dłużej niż dwa dni prowadzi do usunięcia tych URL-i z indeksu, dlatego reguły ograniczania liczby zapytań w zaporze, które obejmują Googlebota, warto przejrzeć, zanim problem pokażą raporty.

Gdzie to widać w Search Console

Search Console generuje komunikaty o błędach dla kodów 4xx i 5xx oraz dla nieudanych przekierowań, a soft 404 oznacza osobno w raporcie indeksowania stron. To pierwsze miejsce, do którego zaglądamy: lista URL-i, które nie są w indeksie, z powodem wykluczenia. Jak czytać ten raport i jego statusy, opisujemy w poradniku po Google Search Console.

Drugim źródłem jest raport statystyk skanowania (Crawl Stats). Według dokumentacji Google pokazuje on historię skanowania serwisu przez Googlebota i momenty, w których robot napotkał problemy z dostępnością hosta. Na wykresach dostępności widać, kiedy liczba żądań przekroczyła czerwoną linię limitu, a po kliknięciu w wykres można zobaczyć, które URL-e zawodziły. Dokumentacja radzi zestawić je z tym, co działo się wtedy na serwerze.

Trzecim narzędziem jest URL Inspection, które dla pojedynczego URL-a pokazuje zwrócony kod i wyrenderowaną stronę. Search Console nie daje natomiast historii skanowania filtrowanej po URL-u czy ścieżce. Kto chce wiedzieć, czy Googlebot odwiedził konkretne podstrony i co od serwera dostał, musi zajrzeć do logów serwera.

Czego szukamy w audycie

Sama liczba błędów w raporcie mówi niewiele. W audycie i pozycjonowaniu interesuje nas, które z nich są prawdziwym problemem, a które stanem prawidłowym, i to rozróżnienie zajmuje większość pracy.

Kody na kluczowych stronach. Najpierw sprawdzamy, co robot dostaje na stronach, na których zależy firmie: głównej, usługowych, ofertowych. Porównujemy wynik z URL Inspection z tym, co widać w przeglądarce, bo właśnie tu wychodzą blokady zapory i ochrony przed botami.

404 z linkami i 404 bez linków. Dzielimy błędy 404 na dwie grupy. URL-e, do których wciąż prowadzą linki wewnętrzne albo mapa witryny, to błędy do naprawy. Stare URL-e, o których Google pamięta, choć nikt już do nich nie linkuje, to zwykle stan prawidłowy. Nie przekierowujemy hurtowo wszystkich usuniętych stron na stronę główną, bo człowiek trafia wtedy w miejsce, którego nie szukał.

Soft 404. Każdy taki URL sprawdzamy osobno: czy strona naprawdę jest pusta, czy przeniosła się, czy jest dobra, tylko nie wczytała się robotowi. Przy okazji patrzymy na drugą stronę tego samego problemu, czyli na mało wartościowe strony, które zwracają 200, nie zostały rozpoznane jako błąd i rozdymają indeks. To zjawisko opisujemy w haśle index bloat.

5xx i dostępność hosta. Błędy serwera czytamy razem z raportem statystyk skanowania i logami. Szukamy powtarzalnych okien, na przykład godzin kopii zapasowych albo wdrożeń, i reguł zapory, które odpowiadają robotowi kodem 429 lub 503 dłużej, niż powinny.

Ślady po migracji. Po przebudowie serwisu sprawdzamy, czy stare URL-e prowadzą przekierowaniem 301 do odpowiedników, zamiast zwracać 404 albo stronę główną z kodem 200.

Podsumowanie

Kod HTTP decyduje, czy Google w ogóle sięgnie po treść strony. Kody 4xx, w tym 401, 403, 404 i 410, oznaczają dla Google brak treści i usunięcie URL-a z indeksu. Kody 5xx i 429 spowalniają skanowanie, przy ich większej liczbie na całym hoście, a utrzymane zbyt długo też kończą się wypadnięciem z indeksu. Soft 404 to strona, która zwraca 200, a wygląda na błąd, i Google wyklucza ją z wyników mimo poprawnego kodu.

Nie każdy błąd w raporcie trzeba naprawiać. 404 na stronie usuniętej bez odpowiednika jest poprawne, 503 przy krótkim zaplanowanym przestoju to dobra praktyka. Naprawy wymagają błędy na stronach, które powinny działać, linki prowadzące donikąd i blokady, o których właściciel strony nie wie.

Jeśli chcesz sprawdzić, które kody na Twojej stronie są stanem prawidłowym, a które kosztują ją miejsce w indeksie, zamów bezpłatną wycenę audytu.