Kody odpowiedzi HTTP a SEO: jak Googlebot traktuje grupy 2xx, 3xx, 4xx i 5xx

Czym jest kod odpowiedzi HTTP i dlaczego wyszukiwarka zwraca na niego uwagę

Kod odpowiedzi, nazywany też kodem stanu, to krótka informacja serwera o tym, jak zakończyło się żądanie pobrania adresu. Człowiek zwykle jej nie widzi, bo przeglądarka pokazuje od razu stronę albo komunikat o błędzie. Robot wyszukiwarki czyta ją natomiast jako pierwszą i od niej uzależnia wszystko, co robi dalej z danym adresem.

Pierwsza cyfra kodu wskazuje grupę. Dokumentacja Google o wpływie kodów stanu HTTP na roboty Google omawia cztery grupy istotne dla wyszukiwarki: 2xx, czyli powodzenie, 3xx, czyli przekierowania, 4xx, czyli błędy po stronie klienta, oraz 5xx, czyli błędy po stronie serwera. Strona ta opisuje dwadzieścia kodów, które roboty Google napotykają najczęściej, i pomija kody rzadkie.

Z punktu widzenia właściciela strony ważne są trzy pytania. Czy po danym kodzie treść może trafić do indeksu? Czy adres, który już w indeksie jest, zostanie w nim, czy zniknie? Czy kod wpływa na tempo, w jakim Googlebot odwiedza pozostałe podstrony? Odpowiedzi różnią się między grupami i to one tworzą mapę przedstawioną w tabeli.

Warto zauważyć, że kod odpowiedzi dotyczy każdego zasobu osobno. Swoją odpowiedź ma strona główna, każda podstrona, każdy obraz, arkusz stylów, a także plik robots.txt i mapa witryny. Na jednej wizycie użytkownika serwer potrafi więc wysłać kilkadziesiąt różnych kodów i część z nich może być błędna, choć strona na ekranie wygląda poprawnie.

Przeglądanie kodów odpowiedzi jest stałym elementem prac, które prowadzimy w ramach SEO technicznego. Błędny kod bywa jedyną przyczyną tego, że dobra treść nie pojawia się w wynikach, a jednocześnie nie widać go bez zajrzenia do narzędzi.

Grupa 2xx: kiedy powodzenie oznacza szansę na indeks, a kiedy pozorny błąd

Kod z grupy 2xx mówi Google, że treść jest gotowa do przetworzenia, ale niczego nie przesądza. Dokumentacja wprost zastrzega, że kod 2xx nie gwarantuje zindeksowania. Adres z odpowiedzią 200 przechodzi do kolejnego etapu, w którym systemy Google oceniają treść, powielenie, dyrektywy dla robotów i wiele innych sygnałów.

Kody 200, 201, 202 i 204

Kod 200 to zwykła, poprawna odpowiedź i to on powinien stanowić zdecydowaną większość odpowiedzi w zdrowym serwisie. Przy kodach 201 i 202 roboty Google czekają na treść przez ograniczony czas, zależny od rodzaju robota, a następnie przekazują dalej to, co otrzymały. Kod 204 oznacza odpowiedź bez treści, więc Google nie ma czego przetwarzać. Jeżeli podstrona ofertowa odpowiada kodem 204 zamiast 200, dla wyszukiwarki jest pusta.

Pozorny błąd 404

Najczęstszy kłopot w tej grupie to pozorny błąd 404, w Search Console opisany także angielską nazwą soft 404. Powstaje wtedy, gdy serwer odpowiada kodem 200, a treść wygląda na błąd: strona jest pusta albo wyświetla komunikat, że niczego nie znaleziono. Google rozpoznaje taką sytuację po treści i zgłasza ją w Search Console jako pozorny błąd 404.

Przykład z praktyki: sklep z Poznania po wyprzedaży kolekcji zostawił adresy produktów, które pokazywały jedynie napis o braku towaru i pusty szablon. Serwer zwracał przy tym kod 200. Według dokumentacji o budżecie indeksowania strony z pozornym błędem 404 są nadal skanowane, czyli zużywają zasoby, które robot mógłby przeznaczyć na działające podstrony. Rozwiązania są dwa: zwrócić prawdziwy kod 404 lub 410 dla stron usuniętych na stałe albo uzupełnić stronę o rzeczywistą treść, jeśli ma pozostać. Wybór między nimi przy kartach produktów omawiamy we wpisie o produkcie wycofanym ze sprzedaży.

Grupa 3xx: jak Googlebot podąża za przekierowaniami

Kod z grupy 3xx informuje, że treści należy szukać pod innym adresem, a Googlebot za takim wskazaniem podąża. Treść wysłana przez adres przekierowujący jest pomijana, a przetwarzana jest wyłącznie treść adresu końcowego. Domyślnie robot pokonuje najwyżej 10 kolejnych przekierowań. Dokumentacja zaznacza, że inne roboty mogą mieć inne limity, a narzędzia testowe Google nie podążają za przekierowaniami.

Przekierowania trwałe i tymczasowe

Różnica między kodami w tej grupie sprowadza się do siły sygnału. Kod 301 systemy Google odczytują jako mocny sygnał, że to adres docelowy powinien być przetwarzany. Kod 302 jest sygnałem słabym. Kod 308 działa jak 301, a kod 307 jak 302. Google traktuje te pary jednakowo, jednak dokumentacja radzi dobierać kod zgodnie z jego znaczeniem, ponieważ inne programy, na przykład inne wyszukiwarki, mogą je rozróżniać.

Strona Przekierowania a wyszukiwarka Google dodaje do tego skutek praktyczny. Przy przekierowaniu trwałym strona docelowa jest traktowana jako kanoniczna, czyli jako ta wersja, która ma się pokazywać w wynikach. Przy przekierowaniu tymczasowym takiego sygnału nie ma i w wynikach nadal może się pojawiać adres źródłowy. Dlatego przekierowanie trwałe stosuje się wtedy, gdy zmiana nie zostanie cofnięta, a tymczasowe wtedy, gdy stary adres ma wrócić. Szerzej opisujemy to we wpisie przekierowanie 301 a 302.

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/oferta/naprawa-pieca/
Content-Type: text/html; charset=UTF-8

Kod 304: treść bez zmian

Kod 304 nie jest przekierowaniem w potocznym rozumieniu. Serwer informuje nim, że strona nie zmieniła się od poprzedniej wizyty robota. Googlebot przekazuje wtedy dalej sygnał, że treść jest identyczna. Sam kod nie wpływa na indeksowanie, choć sygnały dotyczące adresu mogą zostać przeliczone.

Łańcuchy i pętle

Kłopoty w grupie 3xx wynikają zwykle nie z samego kodu, lecz z liczby przeskoków. Hydraulik z Łodzi zmienił kiedyś adresy usług, potem włączył certyfikat, a na końcu dodał przedrostek www. Każda zmiana dołożyła jedno przekierowanie, więc stary adres z wizytówek prowadził do celu przez trzy kolejne odpowiedzi 301. Dokumentacja Google zaleca unikać długich łańcuchów, ponieważ źle wpływają na skanowanie. Pomoc Search Console wymienia też sytuacje, w których przekierowanie w ogóle się nie udaje: zbyt długi łańcuch, pętlę, zbyt długi adres docelowy albo pusty lub błędny adres w łańcuchu. Taki przypadek trafia do raportu jako błąd przekierowania. Po każdej większej zmianie adresów, także po migracji domeny i hostingu, warto skrócić łańcuchy tak, aby stary adres wskazywał od razu adres ostateczny.

Grupa 4xx: co znika z indeksu i dlaczego to nie zawsze problem

Kod z grupy 4xx oznacza dla Google, że pod danym adresem nie ma treści, z której można skorzystać. Treść wysłana razem z takim kodem jest pomijana. Adres napotkany po raz pierwszy nie jest przetwarzany, a adres, który wcześniej był w indeksie, jest z niego usuwany. Robot wraca pod taki adres coraz rzadziej.

Istotne jest to, że Google nie rozróżnia kodów w tej grupie. Dokumentacja wymienia razem kody 400, 401, 403, 404, 410 i 411 i stwierdza, że wszystkie błędy 4xx poza 429 są traktowane tak samo. Zarówno 404, czyli nie znaleziono, jak i 410, czyli zasób usunięty, prowadzą do tego samego skutku. Dokumentacja o budżecie indeksowania zaleca jeden z tych dwóch kodów dla stron usuniętych na stałe i dodaje, że kod 404 jest dla Google wyraźnym sygnałem, by nie skanować adresu ponownie.

Kiedy 404 jest poprawną odpowiedzią

Pomoc Search Console podkreśla, że kod 404 dla strony usuniętej bez zamiennika nie jest problemem. Naprawy wymagają przede wszystkim te przypadki, w których do nieistniejącego adresu prowadzi mapa witryny albo odnośniki. Jeżeli strona została przeniesiona, właściwe jest przekierowanie 301 do nowego miejsca. Więcej o tym rozróżnieniu zawiera wpis błąd 404 a widoczność w Google.

Kody 401 i 403: dostęp zamknięty

Kod 401 oznacza, że serwer wymaga uwierzytelnienia, a 403, że odmawia dostępu. Googlebot nie podaje danych logowania, więc strony za hasłem są dla niego niedostępne. To prawidłowe zachowanie dla panelu klienta, ale błąd, gdy dotyczy oferty. Kancelaria z Krakowa po włączeniu ochrony przed robotami na serwerze zaczęła odsyłać Googlebotowi kod 403 na wszystkich podstronach, choć zwykli użytkownicy widzieli stronę bez przeszkód. Pomoc Search Console radzi w takiej sytuacji umożliwić dostęp osobom niezalogowanym albo wprost Googlebotowi.

Jeżeli celem jest świadome wycofanie adresu z wyników, kod 404 lub 410 jest jedną z kilku dostępnych metod. Pozostałe, w tym rozwiązania tymczasowe, zestawiamy we wpisie o usuwaniu strony z wyników Google.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Grupa 5xx i kod 429: co spowalnia skanowanie całej witryny

Błędy serwera z grupy 5xx oraz kod 429 są dla Google sygnałem, że serwer nie radzi sobie z ruchem, dlatego robot na pewien czas zwalnia skanowanie. To jedyna grupa kodów, która wpływa nie tylko na pojedynczy adres, lecz także na tempo odwiedzin całego serwisu.

Treść odesłana z kodem 5xx jest pomijana. Adresy, które były już w indeksie, pozostają w nim przez pewien czas, a jeśli błąd się utrzymuje, są usuwane. Przy kodzie 500 dokumentacja podaje, że Googlebot zmniejsza szybkość skanowania proporcjonalnie do liczby adresów zwracających błąd. Kody 502 i 503 są objęte tym samym ogólnym opisem. Gdy serwer znowu zaczyna odpowiadać kodami 2xx, Google stopniowo przywraca wcześniejsze tempo.

Kod 429 liczony jak błąd serwera

Kod 429 formalnie należy do grupy 4xx, ale roboty Google odczytują go jako informację o przeciążeniu i traktują jak błąd serwera. Ma to dwa skutki. Zabezpieczenie, które zbyt gorliwie ogranicza liczbę żądań i odsyła Googlebotowi kod 429, spowalnia skanowanie tak samo jak awaria. Z drugiej strony jest to kod, którym można celowo i na krótko poprosić robota o mniejszą liczbę odwiedzin, czego nie da się osiągnąć pozostałymi kodami 4xx.

Krótka przerwa a długa awaria

Przerwa techniczna trwająca godzinę nie powinna zaszkodzić widoczności, ponieważ zindeksowane adresy zostają w indeksie przez pewien czas mimo błędu. Inaczej jest przy awarii ciągnącej się dniami. Pomoc Search Console poświęcona raportowi Statystyki indeksowania zaznacza, że kodów 503 i 429 nie należy zwracać dłużej niż przez 2-3 dni. Po takim czasie rośnie ryzyko, że adresy zaczną wypadać z indeksu.

Z naszej praktyki wynika, że błędy 5xx rzadko dotyczą całej witryny naraz. Częściej pojawiają się w godzinach szczytu, na podstronach generowanych dynamicznie, na przykład na wynikach filtrowania w sklepie, albo wyłącznie dla robotów, gdy zapora uzna ich ruch za podejrzany. Właściciel, który sprawdza stronę ręcznie w ciągu dnia, może ich nigdy nie zobaczyć. O tym, na co zwracać uwagę przy wyborze serwera, piszemy we wpisie hosting a SEO.

Błędy sieci i DNS: gdy serwer nie zdąży podać żadnego kodu

Błąd sieci lub DNS oznacza, że Googlebot w ogóle nie nawiązał połączenia z serwerem, więc nie otrzymał ani kodu odpowiedzi, ani treści. Dokumentacja o debugowaniu błędów sieci i DNS wyjaśnia, że przekroczenia limitu czasu, zerwane połączenia i błędy DNS są traktowane podobnie jak błędy 5xx. Skanowanie zwalnia od razu, a adresy, które były w indeksie i stały się nieosiągalne, są z niego usuwane w ciągu kilku dni.

Skąd biorą się błędy sieci

Błąd sieci może powstać w dowolnym elemencie, przez który przechodzi ruch, jeszcze zanim serwer zacznie odpowiadać. Dokumentacja jako pierwszą rzecz do sprawdzenia podaje ustawienia zapory i jej dzienniki, ponieważ zbyt ogólne reguły blokowania mogą objąć adresy IP robotów Google. Kolejny krok to analiza ruchu sieciowego wykonana przez administratora, a jeżeli przyczyna pozostaje nieznana, kontakt z firmą hostingową lub dostawcą sieci dostarczania treści.

Skąd biorą się błędy DNS

Najczęstszą przyczyną błędów DNS jest według dokumentacji błędna konfiguracja, a drugą zapora blokująca zapytania DNS Googlebota. Sprawdzenie obejmuje rekordy A, które mają wskazywać właściwy adres IP, rekordy CNAME, które mają wskazywać właściwą nazwę hosta, oraz serwery nazw, z których każdy powinien podawać ten sam, poprawny adres witryny. Po zmianie ustawień DNS dokumentacja zaleca odczekać do 72 godzin, aż zmiana rozejdzie się po świecie.

dig +nocmd example.com a +noall +answer
dig +nocmd www.example.com cname +noall +answer

Typowy przypadek to przenosiny serwisu do nowej firmy hostingowej, po których jeden z serwerów nazw nadal wskazuje stary adres IP. Część zapytań trafia wtedy poprawnie, a część donikąd, dlatego strona raz działa, a raz nie. Takie błędy są trudne do zauważenia bez raportu, który pokazuje je w ujęciu dziennym.

Jak odczytać kod odpowiedzi w przeglądarce

Kod odpowiedzi dowolnego adresu można zobaczyć w narzędziach deweloperskich przeglądarki Chrome, w panelu Sieć. Nie wymaga to instalowania dodatków. Narzędzia otwiera się z menu przeglądarki, w pozycji z dodatkowymi narzędziami, a panel Sieć zapisuje wszystkie żądania wysyłane podczas wczytywania strony.

Opis funkcji panelu Sieć wskazuje dwa miejsca, w których widać kod. Pierwsze to tabela żądań z kolumną Stan, w której przy każdym zasobie stoi liczba, na przykład 200 lub 404. Drugie to szczegóły żądania: po kliknięciu pozycji w kolumnie Nazwa otwiera się karta Nagłówki, a w jej sekcji Ogólne widnieje kod razem z krótkim opisem słownym.

1. Otwarcie panelu Sieć

   Po uruchomieniu narzędzi deweloperskich należy przejść do panelu Sieć jeszcze przed wczytaniem badanej strony, aby zapis objął pierwsze żądanie.

2. Włączenie dwóch pól wyboru

   Pole zachowywania dziennika sprawia, że zapis nie znika przy przejściu pod kolejny adres, dzięki czemu widać każdy przeskok przekierowania. Pole wyłączające pamięć podręczną zapobiega pokazaniu odpowiedzi zapamiętanej wcześniej przez przeglądarkę.

3. Wczytanie adresu

   Po wpisaniu adresu w pasku przeglądarki pierwsza pozycja tabeli to badany dokument. W kolumnie Stan stoi jego kod odpowiedzi.

4. Odczytanie łańcucha

   Jeżeli pierwszy wiersz ma kod 301 lub 302, kolejne wiersze pokazują następne adresy, aż do odpowiedzi końcowej. Liczba wierszy z kodem 3xx to długość łańcucha.

Odczyt z przeglądarki ma jedno ograniczenie: pokazuje odpowiedź wysłaną Państwa komputerowi, a nie Googlebotowi. Serwer lub zapora mogą odpowiadać robotom inaczej niż ludziom, jak w opisanym wcześniej przykładzie kancelarii. Dlatego odczyt z przeglądarki warto zawsze potwierdzić w Search Console.

Jak odczytać kody odpowiedzi w Search Console

Search Console pokazuje kody odpowiedzi w trzech miejscach: w raporcie Indeksowanie stron, w raporcie Statystyki indeksowania oraz w narzędziu do sprawdzania adresów URL. Pierwsze mówi, które adresy nie trafiły do indeksu z powodu kodu, drugie, jakie odpowiedzi faktycznie otrzymywał robot, a trzecie, co dzieje się z jednym konkretnym adresem.

Raport Indeksowanie stron

W raporcie Indeksowanie stron przyczyny związane z kodami znajdują się w tabeli adresów niezindeksowanych. Pomoc Search Console wymienia między innymi takie pozycje: Błąd serwera (5xx), Błąd przekierowania, Pozorny błąd 404, Nie znaleziono (404), Strona zablokowana z powodu nieautoryzowanego żądania (401), Strona zablokowana z powodu zabronionego dostępu (błąd 403) oraz URL jest zablokowany z powodu innego błędu 4xx. Kliknięcie przyczyny otwiera listę przykładowych adresów.

Po usunięciu błędu na wszystkich adresach można na stronie szczegółów problemu uruchomić weryfikację poprawki. Według pomocy trwa ona zwykle do dwóch tygodni. Pełny przegląd statusów z tego raportu zawiera wpis dlaczego Google nie indeksuje strony.

Raport Statystyki indeksowania

Raport Statystyki indeksowania znajduje się w menu Ustawienia. Jest dostępny tylko dla usług najwyższego poziomu, czyli usługi domeny albo usługi z prefiksem adresu obejmującej cały host. Pomoc określa go jako raport dla zaawansowanych użytkowników i zaznacza, że witryny mające mniej niż 1000 stron zwykle nie muszą z niego korzystać. Przy podejrzeniu błędów serwera jest jednak najlepszym źródłem wiedzy także w małym serwisie.

Tabela odpowiedzi na żądania robota dzieli wizyty według wyniku. Pomoc uznaje za prawidłowe odpowiedzi OK (200), Przeniesiono na stałe (301/308), Przeniesiono tymczasowo (302/307) i Nie zmodyfikowano (304). Odpowiedź Nie znaleziono (404) jest opisana jako prawdopodobnie prawidłowa. Naprawy wymagają między innymi: Brak autoryzacji (401/407), Błąd serwera (5XX), Inny błąd klienta (4XX), DNS nie odpowiada, Błąd DNS, Nie można otworzyć strony, Czas oczekiwania na odpowiedź strony, Błąd przekierowania oraz Plik robots.txt niedostępny.

Druga ważna część raportu to Stan hosta. Podsumowuje on ostatnie 90 dni w trzech kategoriach: pobieranie pliku robots.txt, rozpoznawanie nazw DNS i połączenie z serwerem. Oznaczenie zielone to brak istotnych problemów, żółte to problem starszy niż tydzień, a czerwone to problem z ostatniego tygodnia. To tutaj widać błędy sieci i DNS, których nie pokaże przeglądarka.

Narzędzie do sprawdzania adresów URL

Narzędzie do sprawdzania adresów URL pokazuje wynik dla jednego adresu, który wpisuje się w pasku u góry Search Console. W części Indeksowanie stron znajduje się pole Pobranie strony z informacją, czy Google zdołał pobrać adres. Test wersji opublikowanej wysyła żądanie na żywo i podaje to samo pole w części Dostępność. Po teście można wyświetlić przetestowaną stronę, a w karcie Więcej informacji obejrzeć dane odpowiedzi, w tym nagłówki HTTP, co opisuje pomoc narzędzia. Pozostałe pola wyjaśniamy we wpisie o sprawdzaniu adresu URL w Search Console.

Typowe pomyłki i kolejność naprawy

Najwięcej szkód przynoszą nie pojedyncze błędy, lecz kody użyte niezgodnie z przeznaczeniem. Pierwsza pomyłka to kod 200 na stronach, które nie istnieją, czyli opisany wcześniej pozorny błąd 404. Druga to kod 404 lub 403 wysyłany podczas prac technicznych. Skoro kody 4xx prowadzą do usuwania adresów z indeksu, na krótką przerwę właściwy jest kod z grupy 5xx, najczęściej 503, po którym adresy przez pewien czas pozostają w indeksie. Trzecia pomyłka jest odwrotna: przerwa techniczna z kodem 200 i napisem o pracach serwisowych. Google otrzymuje wtedy stronę niemal pustą jako poprawną treść wszystkich adresów.

Czwarta pomyłka to przekierowanie tymczasowe pozostawione na stałe, na przykład po zmianie adresów kategorii. Pomoc Search Console radzi w takiej sytuacji zamienić je na 301. Piąta to przekierowanie wszystkich usuniętych podstron na stronę główną. Z naszych obserwacji wynika, że takie adresy często trafiają w raporcie do pozornych błędów 404, dlatego usuniętą podstronę lepiej przekierować do jej rzeczywistego odpowiednika albo zwrócić kod 404. Szósta to zabezpieczenia, które odsyłają robotom 403 lub 429, choć ludzie widzą stronę bez przeszkód.

Kolejność naprawy wynika z mapy grup. Najpierw błędy, które spowalniają całą witrynę: 5xx, 429, sieć, DNS i niedostępny plik robots.txt. Potem błędy na adresach, które mają być w indeksie: 401, 403 i 404 na działającej ofercie oraz nieudane przekierowania. Na końcu porządki: łańcuchy, pozorne błędy 404 i odnośniki do nieistniejących adresów, które w dużych serwisach wiążą się z budżetem indeksowania.

• Strona główna i najważniejsze podstrony oferty odpowiadają kodem 200, bez pośrednich przekierowań.
• Adresy bez www, z www, z http i z https prowadzą do jednej wersji jednym przekierowaniem 301.
• Nieistniejący adres wpisany ręcznie zwraca kod 404, a nie 200.
• Strony usunięte na stałe zwracają 404 lub 410, a przeniesione mają przekierowanie 301 do nowego miejsca.
• Mapa witryny zawiera wyłącznie adresy z kodem 200.
• W raporcie Statystyki indeksowania nie ma odpowiedzi 5XX ani błędów DNS, a Stan hosta jest oznaczony na zielono.
• Zapora i zabezpieczenia nie odsyłają Googlebotowi kodów 403 ani 429.

Samodzielnie da się sprawdzić kody najważniejszych adresów i przejrzeć raporty. Pomoc specjalisty jest potrzebna zwykle wtedy, gdy błędy pojawiają się nieregularnie, dotyczą tylko robotów, wymagają pracy na dziennikach serwera albo gdy adresów są tysiące. Pełny przegląd kodów odpowiedzi wykonujemy także w ramach usługi audytu SEO.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl