Jak kody stanu HTTP, błędy sieci i błędy DNS wpływają na działanie wyszukiwarki Google

Z tego artykułu dowiesz się, jak różne kody stanu HTTP, błędy sieci i DNS wpływają na działanie wyszukiwarki Google. Opisujemy tutaj 20 kodów stanu, które Googlebot napotyka w internecie, oraz najczęściej występujące błędy sieci i błędy DNS. Nie znajdziesz tutaj informacji o rzadkich kodach błędów, takich jak 418 (I'm a teapot). Wszystkie błędy wymienione w tym artykule powodują wygenerowanie odpowiedniej informacji o błędzie lub ostrzeżenia w raporcie Indeksowanie stron w Search Console.

Kody stanów HTTP

Kody stanu HTTP generuje serwer hostujący witrynę, gdy odpowiada na żądania wysyłane przez klienta, np. przeglądarkę lub robota. Każdy kod stanu HTTP ma inne znaczenie, ale odpowiedź na żądanie często jest taka sama. Na przykład istnieje wiele kodów stanu sygnalizujących przekierowanie, ale ich wynik jest jednakowy.

Search Console generuje komunikaty o błędach dla kodów stanu z zakresu 4xx–5xx oraz dla nieudanych przekierowań (3xx). Jeśli serwer odpowiada kodem stanu 2xx, treść otrzymana w odpowiedzi jest uznawana za możliwą do zindeksowania.

Poniższa tabela zawiera najczęściej napotykane przez Googlebota kody stanu HTTP oraz wyjaśnienie, jak Google obsługuje każdy kod stanu.

Kody stanów HTTP

2xx (success)

Google uznaje, że treści należy zindeksować. Jeśli treści sugerują występowanie błędu – np. pusta strona lub komunikat o błędzie – Search Console wyświetla błąd soft 404.

200 (success)

Google przekazuje treści do procesu indeksowania. Systemy indeksowania mogą indeksować treści, ale nie jest to gwarantowane.

201 (created)
202 (accepted)

Googlebot czeka na treści przez określony czas, a potem przekazuje to, co otrzymał w odpowiedzi, do procesu indeksowania. Ten limit czasu zależy od rodzaju klienta użytkownika, np. Googlebot indeksujący strony na smartfony może mieć inny czas oczekiwania niż Googlebot indeksujący obrazy.

204 (no content)

Googlebot wysyła do procesu indeksowania sygnał, że otrzymał treści. Search Console może wyświetlać błąd soft 404 w raporcie Indeksowanie stron.

3xx (redirection)

Googlebot śledzi do 10 przekierowań. Jeśli w tej liczbie przekierowań robot nie otrzyma treści, Search Console wyświetli w raporcie Indeksowanie stron błąd przekierowania. Liczba śledzonych przekierowań zależy od rodzaju klienta użytkownika, np. Googlebot indeksujący strony na smartfony może mieć inną wartość niż Googlebot indeksujący obrazy.

W przypadku pliku robots.txt Google śledzi co najmniej 5 przekierowań, zgodnie z definicją podaną w specyfikacji RFC 1945, a następnie przerywa działanie i przyjmuje kod błędu 404.

Wszystkie treści otrzymane przez Googlebota z adresu URL przekierowania są ignorowane, a treści pod końcowym docelowym adresem URL są indeksowane.

301 (moved permanently)

Googlebot śledzi przekierowanie, a proces indeksowania interpretuje je jako mocny sygnał, że docelowa strona przekierowania powinna być kanoniczna.

302 (found)

Googlebot śledzi przekierowanie, a proces indeksowania interpretuje je jako słaby sygnał, że docelowa strona przekierowania powinna być kanoniczna.

303 (see other)
304 (not modified)

Googlebot wysyła do procesu indeksowania sygnał, że treści są identyczne jak przy ostatnim indeksowaniu. Proces indeksowania może ponownie obliczyć sygnały dla adresu URL, ale kod stanu nie ma wpływu na indeksowanie.

307 (temporary redirect) Odpowiednik: 302.
308 (moved permanently) Odpowiednik: 301.

4xx (client errors)

Proces indeksowania Googlebota nie uwzględnia adresów URL, które zwracają kod stanu indeksowania 4xx. Adresy URL, które zostały już zindeksowane i zwracają kod stanu 4xx, są usuwane z indeksu.

Wszelkie treści otrzymane przez Googlebota z adresów URL, które zwracają kod stanu 4xx, są ignorowane.

400 (bad request)

Wszystkie błędy 4xx (poza błędem 429) są traktowane tak samo: Googlebot wysyła do procesu indeksowania sygnał, że treści nie istnieją.

Proces indeksowania usuwa adres URL z indeksu, jeśli wcześniej został zindeksowany. Nowo napotkane strony z kodem 404 nie są przetwarzane. Częstotliwość indeksowania powoli się zmniejsza.

401 (unauthorized)
403 (forbidden)
404 (not found)
410 (gone)
411 (length required)
429 (too many requests)

Googlebot traktuje kod stanu 429 jako sygnał, że serwer jest przeciążony, i uznaje go za błąd serwera.

5xx (server errors)

Błędy serwera 5xx i 429 informują roboty Google, że na jakiś czas należy zwolnić indeksowanie. Zindeksowane już adresy URL są zachowywane w indeksie, ale po jakimś czasie są z niego usuwane.

Jeśli plik robots.txt zwraca kod stanu błędu serwera dłużej niż przez 30 dni, Google użyje ostatniej kopii tego pliku zapisanej w pamięci podręcznej. Jeśli plik jest niedostępny, zakładamy brak ograniczeń.

Wszelkie treści otrzymane przez Googlebota z adresów URL, które zwracają kod stanu 5xx, są ignorowane.

500 (internal server error)

Googlebot zmniejsza szybkość indeksowania witryny. Spadek szybkości indeksowania jest proporcjonalny do liczby poszczególnych adresów URL, które zwracają błąd serwera. Proces indeksowania Google usuwa z indeksu adresy URL, które stale zwracają błąd serwera.

502 (bad gateway)
503 (service unavailable)

soft 404 błędu

Błąd soft 404 to adres URL, który kieruje użytkownika na stronę z informacją, że dana strona nie istnieje. Na stronie podany jest też kod stanu 200 (success). W niektórych przypadkach może to być strona bez zawartości głównej lub pusta.

Takie strony mogą być generowane przez serwer WWW Twojej witryny, system zarządzania treścią lub przeglądarkę użytkownika z różnych powodów. Na przykład:

  • Brak pliku po stronie serwera.
  • Uszkodzone połączenie z bazą danych.
  • Pusta strona wyników wyszukiwania wewnętrznego.
  • Niewczytany lub brakujący plik JavaScript.

Zwracanie kodu stanu 200 (success) nie jest dobrym rozwiązaniem, ale powoduje wyświetlanie lub sugerowanie komunikatu o błędzie albo jakiegoś błędu na stronie. Użytkownikom może się wydawać, że strona jest dostępna online, ale potem pojawia się komunikat o błędzie. Takie strony są wykluczone z wyszukiwarki.

Jeśli algorytmy Google wykryją na podstawie zawartości strony, że tak naprawdę jest ona stroną błędu, Search Console wyświetli w raporcie Indeksowanie stron błąd soft 404.

Napraw błędy soft 404

W zależności od stanu strony i oczekiwanego wyniku możesz rozwiązać błędy soft 404 na kilka sposobów:

Spróbuj określić, które rozwiązanie będzie najlepsze dla Twoich użytkowników.

Strona i jej zawartość nie są już dostępne

Jeśli strona została usunięta i w Twojej witrynie nie ma jej strony zastępczej z podobną zawartością, ustaw zwracanie kodu stanu 404 (not found) lub 410 (gone). Te kody stanu wskazują wyszukiwarkom, że strona nie istnieje i nie należy indeksować jej zawartości.

Jeśli masz dostęp do plików konfiguracji serwera, możesz dostosować strony z komunikatami o błędach, aby były przydatne dla użytkowników. Dobra niestandardowa strona 404 pomoże odwiedzającym znaleźć poszukiwane informacje, a także dostarczy im przydatną treść i zachęci do dalszego przeglądania Twojej witryny. Oto kilka wskazówek dotyczących projektowania przydatnej, niestandardowej strony 404:

  • Wyraźnie poinformuj użytkowników, że nie można znaleźć strony, której szukają. Zwracaj się do nich w miły i zachęcający sposób.
  • Upewnij się, że Twoja strona 404 wygląda i działa (łącznie z nawigacją) tak samo jak reszta witryny.
  • Pomyśl o dodaniu linków do najpopularniejszych artykułów lub postów, a także do strony głównej witryny.
  • Zastanów się, czy nie warto dać użytkownikom możliwości zgłoszenia uszkodzonego linku.

Niestandardowe strony 404 są tworzone tylko dla użytkowników. Strony te są bezużyteczne z punktu widzenia wyszukiwarki, więc upewnij się, że serwer zwraca kod stanu HTTP 404, aby zapobiec ich indeksowaniu.

Strona lub jej zawartość mają inną lokalizację

Jeśli strona została przeniesiona lub zastąpiona w witrynie inną, ustaw zwracanie kodu 301 (permanent redirect), aby przekierowywać na nią użytkowników. Nie zakłóci to przeglądania Twojej witryny i będzie świetnym sposobem poinformowania wyszukiwarek o nowej lokalizacji strony. Aby upewnić się, że URL zwraca poprawny kod, użyj narzędzia do sprawdzania adresów URL.

Strona i jej zawartość nadal istnieją

Jeśli działająca strona została oznaczona kodem błędu soft 404, może to oznaczać, że nie wczytała się prawidłowo, gdy odwiedzał ją Googlebot, brakowało w niej kluczowych zasobów lub podczas renderowania pojawił się dobrze widoczny komunikat o błędzie. Użyj narzędzia do sprawdzania adresów URL, aby sprawdzić renderowane treści i zwracany kod HTTP. Jeśli wyrenderowana strona jest pusta, prawie pusta lub przy wczytywaniu treści pojawia się komunikat o błędzie, może to oznaczać, że odwołuje się do wielu zasobów, których nie można wczytać (obrazów, skryptów i innych elementów nietekstowych), co może zostać zinterpretowane jako błąd soft 404. Wczytanie zasobów może nie być możliwe, ponieważ zasoby są blokowane (przez plik robots.txt), jest ich zbyt wiele, są za duże, wolno się wczytują lub wystąpiły różnego rodzaju błędy serwera.

Błędy sieci i błędy DNS

Błędy sieci i DNS mają szybki i negatywny wpływ na wyświetlanie adresów URL w wyszukiwarce Google. Googlebot traktuje limity czasu sieci, resetowania połączeń i błędy DNS podobnie do błędów serwera 5xx. W przypadku błędów sieci indeksowanie od razu zwalnia, ponieważ jest to sygnał, że serwer może być przeciążony. Googlebot nie mógł połączyć się z serwerem hostującym witrynę, więc do Google nie zostały przesłane też żadne treści z serwera. Brak treści oznacza, że Google nie może zindeksować zeskanowanych adresów URL. Zindeksowane już adresy URL, które są nieosiągalne, zostaną usunięte z indeksu Google w ciągu kilku dni. Search Console może generować komunikaty o błędach w przypadku każdego błędu.

Debugowanie błędów sieci

Te błędy występują, zanim Google zacznie indeksować adres URL lub w trakcie indeksowania przez Google adresu URL. Takie błędy mogą wystąpić przed odpowiedzią serwera, dlatego nie można ustalić kodu stanu wskazującego na problem – stąd zdiagnozowanie takich błędów bywa trudne. Aby debugować błędy limitu czasu i resetowania połączenia:

  • Sprawdź ustawienia zapory sieciowej i dzienniki. Może istnieć bardzo ogólny zestaw reguł blokowania. Upewnij się, że adresów IP Googlebota nie blokują żadne reguły zapory sieciowej.
  • Sprawdź ruch w sieci. Użyj narzędzi takich jak tcpdump i Wireshark, aby przechwycić i przeanalizować pakiety TCP. Poszukaj w nich anomalii, które wskazują na określony komponent sieci lub moduł serwera.
  • Jeśli nie znajdziesz potencjalnej przyczyny problemów, skontaktuj się z firmą hostingową.

Błąd może występować w dowolnym komponencie serwera, który obsługuje ruch w sieci. Na przykład przeciążone interfejsy sieciowe mogą porzucać pakiety, co prowadzi do przekraczania limitów czasu (braku możliwości nawiązania połączenia) i resetowania połączeń (wysyłania pakietu RST z powodu omyłkowego zamknięcia portu).

Debugowanie błędów DNS

Najczęstszą przyczyną błędów DNS jest nieprawidłowa konfiguracja. Inną przyczyną może być blokowanie zapytań DNS Googlebota przez reguły zapory sieciowej. Aby debugować błędy DNS, wykonaj te czynności:

  • Sprawdź reguły zapory sieciowej. Upewnij się, że żaden z adresów IP Googlebota nie jest blokowany przez reguły zapory sieciowej i dozwolone są żądania UDP oraz TCP.
  • Sprawdź rekordy DNS. Upewnij się, że rekordy A i CNAME wskazują odpowiednio prawidłowe adresy IP i nazwę hosta. Na przykład: 
    dig +nocmd example.com a +noall +answer
     
    dig +nocmd www.example.com cname +noall +answer
  • Sprawdź, czy wszystkie Twoje serwery nazw wskazują prawidłowe adresy IP witryny. Na przykład: 
    dig +nocmd example.com ns +noall +answer
example.com.    86400  IN  NS  a.iana-servers.net.
example.com.    86400  IN  NS  b.iana-servers.net.
dig +nocmd @a.iana-servers.net example.com +noall +answer
example.com.    86400  IN  A  93.184.216.34
dig +nocmd @b.iana-servers.net example.com +noall +answer
...
  • Jeśli w ciągu ostatnich 72 godzin wprowadzono zmiany w konfiguracji DNS, zaczekaj, aż zostaną one obowiązywać w globalnej sieci DNS. Aby przyśpieszyć rozpowszechnianie tych zmian, zresetuj pamięć podręczną publicznego DNS Google.
  • Jeśli korzystasz z własnego serwera DNS, upewnij się, że jest w dobrej kondycji i nie jest przeciążony.