„Błąd serwera (5xx)” w raporcie indeksowania. Jak ustalić przyczynę?

W Google Search Console, w raporcie „Indeksowanie stron”, pojawia się wiersz „Błąd serwera (5xx)”, a przy nim liczba adresów, których Google nie zindeksował. Komunikat brzmi groźnie, a jednocześnie strona otwierana w przeglądarce działa bez zarzutu. To typowa sytuacja: robot Google odwiedził witrynę w chwili, gdy serwer nie był w stanie mu odpowiedzieć, i zapisał to w raporcie.

Ta instrukcja jest przeznaczona dla właścicieli firm i osób, które same opiekują się stroną, najczęściej zbudowaną na WordPressie. Nie wymaga wiedzy programisty, choć w kilku miejscach potrzebny będzie dostęp do panelu hostingu.

Po lekturze będzie wiadomo, jak odróżnić chwilową awarię od trwałej usterki, gdzie odczytać dokładny dzień i godzinę błędu, jak ustalić, czy zawinił serwer, wtyczka, zapora czy sam ruch robotów, jak naprawić każdą z tych przyczyn i jak poprosić Google o ponowne sprawdzenie adresów.

Co oznacza „Błąd serwera (5xx)” i dlaczego Google nie indeksuje wtedy strony?

Każda odpowiedź serwera zaczyna się od trzycyfrowego kodu. Kod zaczynający się od cyfry 5 oznacza, że serwer otrzymał prośbę o stronę, ale nie potrafił jej obsłużyć. W pomocy Search Console opis jest krótki: po zgłoszeniu żądania strony serwer zwrócił błąd na poziomie 500.

Google wyjaśnia też szerzej, co kryje się pod pojęciem błędu serwera: Googlebot nie mógł uzyskać dostępu do adresu, upłynął czas oczekiwania na realizację żądania albo witryna je odrzuciła. Robot musiał więc zrezygnować z pobrania strony.

Skutki opisuje dokumentacja Google dla twórców stron. Treść otrzymana z adresu, który zwraca kod 5xx, jest ignorowana. Adresy zindeksowane wcześniej pozostają w indeksie, ale po pewnym czasie są z niego usuwane, jeśli błąd się utrzymuje. Dodatkowo robot zwalnia: błędy 5xx oraz kod 429 są dla niego sygnałem, że serwer jest przeciążony i przez jakiś czas należy odwiedzać witrynę rzadziej.

Dobra wiadomość jest taka, że ten mechanizm działa w obie strony. Gdy serwer znów zacznie odpowiadać prawidłowo, Google stopniowo zwiększa częstotliwość odwiedzin. Pojedyncza, krótka awaria zwykle nie zostawia trwałych śladów. Groźne są błędy powtarzające się albo trwające wiele dni.

Najczęściej spotykane kody z grupy 5xx

Search Console nie pokazuje w tym wierszu, który dokładnie kod wystąpił, ale można go odczytać w dziennikach serwera lub w raporcie „Statystyki indeksowania”. Znajomość kodu bardzo zawęża poszukiwania.

• 500 – wewnętrzny błąd serwera. Najczęściej usterka w kodzie strony: wtyczka, motyw, błędny wpis w pliku .htaccess, wyczerpana pamięć PHP.
• 502 – błędna brama. Serwer pośredniczący (na przykład sieć CDN lub serwer proxy) nie dostał poprawnej odpowiedzi od właściwego serwera strony.
• 503 – usługa niedostępna. Serwer jest przeciążony, trwa przerwa techniczna albo włączono tryb konserwacji.
• 504 – przekroczony czas oczekiwania bramy. Strona generowała się zbyt długo i serwer pośredniczący przestał czekać.
• 429 – zbyt wiele żądań. Formalnie to kod z grupy 4xx, ale Google traktuje go jak błąd serwera i sygnał przeciążenia.

Po czym rozpoznać, czy problem jest jednorazowy, czy trwały?

Od odpowiedzi na to pytanie zależy cała dalsza praca. Jednorazowy błąd sprzed dwóch tygodni wymaga tylko potwierdzenia, że strona działa. Błąd wracający co kilka dni wymaga szukania przyczyny.

1. W Search Console, w menu po lewej stronie, należy otworzyć raport „Strony” w części „Indeksowanie”. To właśnie raport, który pomoc Google nazywa „Indeksowanie stron”.
2. Pod wykresem znajduje się tabela „Dlaczego strony nie są indeksowane”. Trzeba w niej kliknąć wiersz „Błąd serwera (5xx)”.
3. Otworzy się strona ze szczegółami. Wykres na górze pokazuje, ile adresów miało ten problem w kolejnych dniach. Linia płaska lub opadająca oznacza zdarzenie z przeszłości, linia rosnąca oznacza usterkę, która trwa.
4. Niżej widać tabelę z przykładowymi adresami i datą ostatniego skanowania każdego z nich. Lista jest przykładowa i ograniczona do 1000 wierszy, więc nie musi zawierać wszystkich adresów z błędem.
5. Warto zanotować kilka adresów i daty. Będą potrzebne przy przeglądaniu dzienników serwera i w rozmowie z firmą hostingową.

Trzeba też zwrócić uwagę na datę ostatniego skanowania. Raport pokazuje stan z chwili ostatniej wizyty robota. Jeśli usterka została usunięta później, adres nadal będzie widniał na liście, dopóki Google nie odwiedzi go ponownie.

Jak sprawdzić, czy błąd nadal występuje?

Najprostszy test to narzędzie do sprawdzania adresów URL wbudowane w Search Console. Pobiera ono stronę tak, jak robi to Googlebot, i pokazuje wynik od razu.

1. W tabeli z przykładami należy najechać kursorem na wybrany adres i kliknąć ikonę lupy. Adres otworzy się w narzędziu do sprawdzania adresów URL. Można też wkleić adres w pole wyszukiwania na samej górze Search Console.
2. Pierwszy ekran pokazuje dane z indeksu Google, czyli stan z ostatniej wizyty robota. W części dotyczącej skanowania widać datę tej wizyty i informację, czy pobranie strony się powiodło.
3. Następnie trzeba kliknąć „Sprawdź URL wersji opublikowanej”. Test trwa zwykle od kilkunastu sekund do kilku minut.
4. Jeśli wynik jest pozytywny, strona w tej chwili odpowiada robotowi poprawnie. Jeśli narzędzie zgłasza, że adres jest niedostępny, błąd trwa i trzeba przejść do szukania przyczyny.
5. Test należy powtórzyć dla trzech lub czterech adresów z listy, najlepiej różnego rodzaju: strona główna, wpis, kategoria, produkt.

Jedno zastrzeżenie, które Google podaje wprost: błędy serwera bywają przejściowe, więc test wersji opublikowanej może się udać, mimo że wcześniejsza wizyta Googlebota zakończyła się błędem. Udany test dowodzi, że strona działa teraz. Nie dowodzi, że działa zawsze. Dlatego kolejnym krokiem jest raport pokazujący dłuższą historię.

Gdzie odczytać historię awarii z ostatnich tygodni?

Służy do tego raport „Statystyki indeksowania”. Otwiera się go przez „Ustawienia” w menu po lewej stronie, a następnie pozycję „Statystyki indeksowania”. Raport jest dostępny tylko dla usług najwyższego poziomu, czyli dla usługi domeny albo usługi z prefiksem URL obejmującej całą witrynę, a nie pojedynczy katalog.

Stan hosta

Część „Stan hosta” informuje, czy w ciągu ostatnich 90 dni robot miał kłopot z dostępnością witryny. Możliwe są trzy stany: brak poważnych problemów, problem, który wystąpił ponad tydzień temu, oraz problem z ostatniego tygodnia, oznaczony na czerwono.

Po kliknięciu otwierają się trzy kategorie, każda z własnym wykresem i przerywaną czerwoną linią. Przekroczenie tej linii oznacza, że danego dnia w tej kategorii wystąpił problem.

• „Pobieranie pliku robots.txt” – jaki odsetek prób pobrania pliku robots.txt się nie powiódł.
• „Rozpoznawanie nazw DNS” – kiedy serwer DNS nie rozpoznał nazwy domeny lub nie odpowiadał.
• „Połączenie z serwerem” – kiedy serwer nie odpowiadał albo nie udzielił pełnej odpowiedzi.

Odpowiedzi na żądania robota

Niżej znajduje się tabela z odpowiedziami pogrupowanymi według typu. Wiersz „Błąd serwera (5XX)” ma miniaturowy wykres pokazujący, kiedy mniej więcej błędy wystąpiły. Po kliknięciu widać przykładowe adresy z dokładną godziną żądania i kodem odpowiedzi.

To najcenniejsza informacja w całym badaniu. Godzina pozwala zestawić błąd z tym, co działo się wtedy na serwerze: z kopią zapasową wykonywaną w nocy, z aktualizacją wtyczek, z wysyłką kampanii reklamowej albo z awarią zgłoszoną przez firmę hostingową.

W tej samej tabeli warto przejrzeć sąsiednie wiersze: „Czas oczekiwania na odpowiedź strony”, „DNS nie odpowiada” i „Plik robots.txt jest niedostępny”. Jeśli pojawiają się w tych samych dniach, wskazują na ogólną niedostępność serwera, a nie na błąd pojedynczej podstrony. Przydatny jest także wykres średniego czasu odpowiedzi: jego wyraźny wzrost tuż przed błędami sugeruje przeciążenie.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl, a ja przejmę sprawę: odczytam z raportów i dzienników serwera, kiedy i dlaczego pojawiły się błędy 5xx, doprowadzę do ich usunięcia i zgłoszę adresy do ponownego sprawdzenia.

Jakie są możliwe przyczyny i jak ustalić, która zachodzi?

Z mojej praktyki wynika, że niemal wszystkie przypadki mieszczą się w pięciu grupach. Każda zostawia inne ślady, więc da się je rozróżnić bez zgadywania.

Awaria lub przerwa techniczna po stronie hostingu

Ślady: błędy skupione w jednym dniu lub w kilku godzinach, dotyczą przypadkowych adresów z całej witryny, w „Stanie hosta” widać przekroczenie w kategorii „Połączenie z serwerem”. Potwierdzenie daje strona ze statusem usług firmy hostingowej albo wiadomość o pracach serwisowych wysłana do klientów.

Przeciążenie serwera

Ślady: błędy 503 lub 504 wracają o podobnych porach, średni czas odpowiedzi rośnie, a w panelu hostingu widać wykorzystanie zasobów bliskie limitu. Przeciążenie bywa wywołane przez ruch klientów, przez zadania uruchamiane cyklicznie, przez obce roboty albo przez sam sposób zbudowania strony.

Usterka w kodzie strony

Ślady: kod 500, błąd dotyczy stale tych samych adresów albo jednego rodzaju podstron, a jego początek pokrywa się z aktualizacją wtyczki, motywu lub wersji PHP. W dzienniku błędów serwera pojawiają się wpisy o błędzie krytycznym albo o wyczerpanej pamięci.

Zapora lub ochrona, która blokuje Googlebota

Ślady: strona działa bez zarzutu w przeglądarce, a robot dostaje błąd. Google opisuje ten przypadek w pomocy: systemy ochrony często automatycznie blokują adresy, z których przychodzi nadzwyczaj dużo żądań, a Googlebot wysyła ich więcej niż zwykły użytkownik. Blokować może zapora na serwerze, usługa CDN, wtyczka bezpieczeństwa albo ochrona przed atakami DoS.

Adresy z parametrami i strony generowane w locie

Ślady: na liście dominują adresy z filtrami, sortowaniem, wyszukiwarką wewnętrzną albo kalendarzem. Każdy taki adres zmusza serwer do zbudowania strony od zera. Google zwraca uwagę, że odpowiedź strony dynamicznej może trwać zbyt długo i kończyć się przekroczeniem czasu oczekiwania.

Jak czytać dzienniki serwera, żeby znaleźć źródło błędu?

Dzienniki, nazywane też logami, to pliki, w których serwer zapisuje każde żądanie i każdy błąd. Większość firm hostingowych udostępnia je w panelu klienta, zwykle w dziale poświęconym statystykom lub plikom. Nazwy działów różnią się między dostawcami, dlatego w razie wątpliwości najszybciej zapytać pomoc techniczną, gdzie znajdują się dziennik dostępu i dziennik błędów dla danej domeny.

Dziennik dostępu zawiera po jednym wierszu na każde żądanie: datę i godzinę, adres IP, żądany adres strony, kod odpowiedzi oraz nazwę programu, który o stronę poprosił. Należy odszukać wiersze z godziny podanej w raporcie „Statystyki indeksowania”, z kodem zaczynającym się od 5 i ze słowem Googlebot w nazwie programu.

Dziennik błędów mówi, dlaczego serwer nie dał rady. Wpis z tej samej minuty zwykle wskazuje konkretny plik i wiersz kodu, nazwę wtyczki w ścieżce pliku albo informację o przekroczeniu limitu pamięci lub czasu wykonywania.

W WordPressie można dodatkowo włączyć własny dziennik błędów. W pliku wp-config.php, powyżej wiersza z komentarzem o zakończeniu edycji, umieszcza się trzy wiersze:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Błędy będą wtedy zapisywane w pliku debug.log w katalogu wp-content, a odwiedzający nie zobaczą ich na ekranie. Po zakończeniu badania wartość WP_DEBUG należy przywrócić na false, a plik debug.log usunąć z serwera, ponieważ może zawierać informacje o budowie strony. Przed jakąkolwiek zmianą w plikach powinna powstać kopia zapasowa, którą da się odtworzyć.

Jeśli w dziennikach nie ma żadnego śladu żądania z godziny błędu, to także jest wskazówka. Oznacza, że żądanie robota nie dotarło do serwera strony, więc zatrzymało je coś po drodze: sieć CDN, zapora albo awaria łącza w serwerowni.

Jak naprawić błąd, gdy zawinił serwer albo hosting?

Przy jednorazowej awarii hostingu po stronie właściciela strony nie ma nic do naprawienia. Wystarczy potwierdzić testem wersji opublikowanej, że adresy odpowiadają, i poprosić Google o ponowne sprawdzenie, co opisuję niżej.

Przy awariach powtarzających się trzeba napisać do pomocy technicznej. Zgłoszenie ogólne w rodzaju „strona czasem nie działa” niewiele da. Skuteczne zgłoszenie zawiera konkretne dane, na przykład w takim brzmieniu:

„Zgłaszam powtarzające się błędy 5xx w domenie [nazwa domeny]. Robot Google otrzymał kod [kod] w dniach [daty] około godziny [godziny] pod adresami: [trzy przykładowe adresy]. Proszę o sprawdzenie dzienników serwera z tych godzin i informację, czy przyczyną było przekroczenie limitów konta, przerwa techniczna czy blokada na zaporze. Proszę też o potwierdzenie, że adresy IP Googlebota nie są blokowane ani ograniczane.”

Jeśli odpowiedź wskaże na przekraczanie limitów konta, są dwie drogi. Pierwsza to odciążenie strony: włączenie pamięci podręcznej stron, ograniczenie liczby wtyczek, przeniesienie ciężkich zadań na godziny nocne. Szerzej opisałem to we wpisie o tym, co spowalnia WordPressa. Druga droga to mocniejszy pakiet hostingu. Google w swojej pomocy również radzi, by przy utrzymujących się problemach z połączeniem lub czasem odpowiedzi rozważyć zwiększenie możliwości obsługi żądań przez witrynę.

Jak naprawić błąd, gdy zawiniła wtyczka, motyw lub konfiguracja?

Jeżeli dziennik błędów wskazuje konkretną wtyczkę, postępowanie jest proste: aktualizacja do najnowszej wersji, a gdy to nie pomoże, wyłączenie jej i poszukanie zamiennika. Gdy dziennik nie daje jasnej odpowiedzi, pozostaje metoda eliminacji.

1. Wykonanie pełnej kopii zapasowej plików i bazy danych.
2. Utworzenie kopii testowej strony, jeśli hosting na to pozwala. Wyłączanie wtyczek na działającej stronie firmowej albo w sklepie może przerwać sprzedaż lub popsuć wygląd, dlatego bezpieczniej pracować na kopii.
3. W panelu WordPressa, w menu „Wtyczki”, wyłącza się wszystkie wtyczki, po czym sprawdza się adres, który zwracał błąd.
4. Jeśli błąd zniknął, wtyczki włącza się pojedynczo, sprawdzając adres po każdej z nich. Ta, po której błąd wraca, jest przyczyną.
5. Jeśli wyłączenie wtyczek nie pomogło, w menu „Wygląd” przełącza się stronę na motyw domyślny WordPressa i powtarza test.
6. Na końcu przywraca się poprzednie ustawienia, a wadliwy element aktualizuje, zastępuje innym albo zgłasza jego autorowi.

Gdy błąd 500 obejmuje całą stronę łącznie z panelem administracyjnym, wtyczek nie da się wyłączyć z poziomu WordPressa. Postępowanie w takiej sytuacji, w tym tryb odzyskiwania i wyłączanie wtyczek przez zmianę nazwy katalogu, opisałem we wpisie o tym, jak przywrócić stronę, gdy nic się nie wyświetla.

Wyczerpana pamięć i przekroczony czas wykonywania

Wpis w dzienniku mówiący o wyczerpaniu dozwolonej pamięci oznacza, że skrypt potrzebował jej więcej, niż pozwala limit. WordPress pozwala podnieść własny limit wierszem w pliku wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

Wartość ta nie przekroczy jednak limitu ustawionego na serwerze. Limit pamięci PHP i maksymalny czas wykonywania skryptu zmienia się w panelu hostingu, w ustawieniach PHP, albo prosi o to pomoc techniczną. Radzę traktować podniesienie limitu jako rozwiązanie doraźne: jeśli jedna podstrona potrzebuje nagle kilkakrotnie więcej pamięci niż pozostałe, prawdziwą przyczyną jest wadliwy kod i to jego należy poprawić.

Błędny plik .htaccess

Na serwerach Apache i LiteSpeed jeden nieprawidłowy wiersz w pliku .htaccess wywołuje błąd 500 na całej stronie. Test polega na pobraniu pliku na dysk jako kopii, zmianie jego nazwy na serwerze i sprawdzeniu, czy strona główna zaczęła działać. Jeśli tak, w panelu WordPressa, w „Ustawieniach” i pozycji „Bezpośrednie odnośniki”, wystarczy kliknąć „Zapisz zmiany”, a WordPress utworzy nowy, czysty plik. Własne reguły, na przykład przekierowania, dodaje się potem pojedynczo, sprawdzając stronę po każdej z nich.

Co zrobić, gdy Googlebota blokuje zapora lub ochrona przed atakami?

Ten przypadek łatwo przeoczyć, bo właściciel widzi działającą stronę. Podejrzenie powinno paść na zaporę wtedy, gdy test wersji opublikowanej w Search Console kończy się niepowodzeniem, a przeglądarka w tym samym momencie otwiera stronę poprawnie.

Trzeba po kolei przejrzeć wszystkie warstwy ochrony: ustawienia sieci CDN, zaporę na koncie hostingowym, wtyczkę bezpieczeństwa w WordPressie oraz reguły ograniczające liczbę żądań z jednego adresu IP. W każdym z tych miejsc znajduje się dziennik zablokowanych żądań. Jeśli widnieją w nim adresy należące do Google, przyczyna jest znaleziona.

Rozwiązaniem jest dodanie wyjątku dla prawdziwego Googlebota. Nie należy przy tym ufać samej nazwie programu w żądaniu, bo każdy może się pod nią podszyć. Google opisuje dwie metody weryfikacji: porównanie adresu IP z publikowaną przez Google listą zakresów adresów swoich robotów albo odwrotne sprawdzenie nazwy DNS, które dla prawdziwego robota kończy się nazwą w domenie googlebot.com, google.com lub googleusercontent.com. Większość dostawców CDN i zapór ma gotową regułę dla zweryfikowanych robotów wyszukiwarek i z niej najlepiej skorzystać.

Jeżeli nie ma dostępu do ustawień zapory, Google radzi skontaktować się z dostawcą hostingu. W zgłoszeniu warto użyć sformułowania o „zweryfikowanym Googlebocie”, żeby było jasne, że nie chodzi o wpuszczenie każdego, kto się tak przedstawia.

Zdarza się też sytuacja odwrotna: ktoś celowo ograniczył robotom dostęp zaporą, żeby zmniejszyć obciążenie. Google odradza takie podejście. Do wskazywania, których części witryny robot ma nie odwiedzać, służy plik robots.txt, a jak go bezpiecznie ustawić, wyjaśniam we wpisie o tym, jak jedna linijka w robots.txt potrafi ukryć stronę przed Google.

Jak postąpić, gdy serwer nie wytrzymuje ruchu robotów?

Googlebot ma mechanizmy, które chronią witrynę przed przeciążeniem: gdy odpowiedzi stają się wolniejsze albo rośnie liczba błędów, sam ogranicza liczbę żądań. Mimo to słabszy serwer połączony z dużą liczbą adresów generowanych w locie potrafi sobie nie poradzić.

Najpierw trzeba ustalić, kto naprawdę obciąża serwer. Raport „Statystyki indeksowania” pokazuje łączną liczbę żądań Google dzień po dniu oraz podział według typu robota. Jeśli w dniach błędów liczba żądań Google nie odbiega od zwykłej, źródłem obciążenia jest co innego: inne roboty, ruch klientów albo zadania wewnętrzne. Odpowiedź dadzą dzienniki dostępu.

Jeśli obciążenie rzeczywiście tworzą adresy z parametrami, trwałym rozwiązaniem jest uporządkowanie ich. Google zaleca oszczędne stosowanie parametrów w adresach i ograniczenie ich liczby. W praktyce oznacza to zablokowanie w pliku robots.txt adresów wyników wyszukiwania wewnętrznego i kombinacji filtrów, które nie mają wartości dla szukających, oraz usunięcie linków prowadzących do takich kombinacji.

W sytuacji nagłej, gdy serwer nie daje rady i potrzebne jest natychmiastowe odciążenie, Google dopuszcza czasowe zwracanie kodu 503 lub 429 w chwilach zbliżania się do limitu. Zastrzega jednak wyraźnie, że nie należy robić tego dłużej niż 2 lub 3 dni, bo witryna może być potem trwale odwiedzana rzadziej. To rozwiązanie awaryjne, a nie sposób na codzienne działanie strony.

Szczególny przypadek: plik robots.txt zwraca błąd 5xx

Witryna nie musi mieć pliku robots.txt, ale na prośbę o ten plik musi odpowiedzieć poprawnie: plikiem albo informacją, że pliku nie ma. Odpowiedź z kodem 5xx lub 429 Google uznaje za nieprawidłową i wtedy konsekwencje dotyczą całej witryny, a nie jednego adresu.

Zgodnie z pomocą Search Console przez pierwsze 12 godzin Google wstrzymuje odwiedzanie witryny i ponawia prośbę o plik. Od 12 godziny do 30 dnia korzysta z ostatniej pobranej wersji pliku. Po 30 dniach, jeśli strona główna jest dostępna, zachowuje się tak, jakby pliku nie było, a jeśli jest niedostępna, przestaje odwiedzać witrynę.

Dlatego przy każdym badaniu błędów 5xx warto zajrzeć do kategorii „Pobieranie pliku robots.txt” w „Stanie hosta” i otworzyć w przeglądarce adres pliku robots.txt we własnej domenie. Jeśli plik jest generowany przez wtyczkę, a nie leży na serwerze jako zwykły plik tekstowy, jego dostępność zależy od sprawności całego WordPressa.

Jak poprosić Google o ponowne sprawdzenie i po czym poznać, że naprawa zadziałała?

Google i tak wróci pod adresy z błędem i sam zaktualizuje raport. Prośba o weryfikację nie jest obowiązkowa, ale pozwala śledzić postęp i dostać powiadomienie o wyniku.

1. Przed zgłoszeniem należy testem „Sprawdź URL wersji opublikowanej” potwierdzić na kilku adresach, że błąd rzeczywiście zniknął. Weryfikacja zatrzymuje się, gdy Google znajdzie choć jedno pozostałe wystąpienie problemu.
2. W raporcie „Strony” trzeba otworzyć wiersz „Błąd serwera (5xx)” i kliknąć „Sprawdź poprawkę”.
3. Przycisku nie należy klikać ponownie, dopóki weryfikacja nie zakończy się powodzeniem lub niepowodzeniem.
4. Stan weryfikacji widać na stronie szczegółów problemu. Po kliknięciu „Sprawdź szczegóły” otwiera się lista adresów ze stanem każdego z nich.
5. Dla kilku najważniejszych adresów, na przykład strony głównej i głównych podstron ofertowych, można dodatkowo użyć w narzędziu do sprawdzania adresów URL przycisku „Poproś o zindeksowanie”.

Według pomocy Google weryfikacja trwa zazwyczaj do 2 tygodni, a czasem znacznie dłużej. Stan „Rozpoczęto” oznacza, że na sprawdzonych dotąd adresach nie znaleziono błędu. Stan „Powodzenie” oznacza, że wszystkie znane wystąpienia zniknęły. Stan „Niepowodzenie” oznacza, że błąd nadal występuje na co najmniej jednym adresie.

O skuteczności naprawy świadczą trzy rzeczy naraz: liczba adresów w wierszu „Błąd serwera (5xx)” spada, w raporcie „Statystyki indeksowania” wiersz „Błąd serwera (5XX)” przestaje rosnąć, a „Stan hosta” po tygodniu bez problemów przestaje być czerwony. Liczba żądań robota wraca do zwykłego poziomu stopniowo, nie z dnia na dzień.

Przy dużej liczbie adresów pomaga wskazówka z pomocy Google: nad wykresem znajduje się filtr mapy witryny. Po wybraniu mapy z najważniejszymi podstronami weryfikacja obejmie tylko adresy z tej mapy i może zakończyć się szybciej. Trzeba przy tym pamiętać, że pozostałe adresy nie zostaną wtedy objęte prośbą.

Co zrobić, gdy weryfikacja się nie powiodła albo błąd wraca?

Po nieudanej weryfikacji należy kliknąć „Sprawdź szczegóły” i odszukać adresy ze stanem „Niepowodzenie”. To one zatrzymały proces. Często okazuje się, że naprawiono jeden rodzaj podstron, a błąd dotyczył także innego.

Każdy taki adres trzeba sprawdzić testem wersji opublikowanej i odszukać w dziennikach serwera z dnia, w którym Google podjął próbę. Po usunięciu przyczyny weryfikację uruchamia się ponownie. Obejmie ona adresy oczekujące i te z niepowodzeniem, a adresów już zaliczonych Google nie sprawdza drugi raz.

Jeżeli testy stale wychodzą dobrze, a błąd mimo to wraca w raporcie co kilka dni, usterka jest okresowa. Pomaga wtedy zewnętrzna usługa monitorowania dostępności, która odpytuje stronę co kilka minut i zapisuje każdą przerwę z dokładną godziną. Zestawienie tych godzin z harmonogramem kopii zapasowych, zadań cyklicznych i aktualizacji zwykle szybko wskazuje winnego.

Jakich błędów unikać przy usuwaniu problemu?

• Klikanie „Sprawdź poprawkę” bez wcześniejszej naprawy. Weryfikacja zakończy się niepowodzeniem, a na kolejną trzeba będzie znów czekać.
• Blokowanie adresów z błędem w pliku robots.txt tylko po to, by zniknęły z raportu. Usterka zostaje, a Google traci możliwość sprawdzenia, czy strona wróciła do sprawności.
• Uspokajanie się jednym udanym testem. Błędy przejściowe wymagają spojrzenia na historię w „Statystykach indeksowania”.
• Pozostawianie trybu konserwacji na wiele dni. Kod 503 jest właściwy dla krótkiej przerwy, a utrzymywany długo prowadzi do rzadszych odwiedzin robota i usuwania adresów z indeksu.
• Wyłączanie wtyczek i edytowanie plików na działającej stronie bez kopii zapasowej.
• Dodawanie wyjątku w zaporze dla każdego żądania, które przedstawia się jako Googlebot, bez weryfikacji adresu.
• Zostawianie włączonego dziennika debug.log po zakończeniu badania.

Najczęstsze pytania

Czy błąd serwera (5xx) obniża pozycje strony w Google?

Krótka, jednorazowa awaria zwykle nie ma trwałych skutków, bo zindeksowane adresy pozostają w indeksie. Problem zaczyna się, gdy błąd się utrzymuje: Google podaje, że adresy stale zwracające błąd serwera są usuwane z indeksu, a robot odwiedza witrynę rzadziej. Strona, której nie ma w indeksie, nie wyświetla się w wynikach.

Strona działa w przeglądarce, dlaczego Google widzi błąd?

Są trzy typowe wyjaśnienia. Błąd mógł być chwilowy i wystąpić akurat podczas wizyty robota. Raport może pokazywać stan sprzed naprawy, co widać po dacie ostatniego skanowania. Wreszcie zapora lub ochrona przed atakami może blokować robota, przepuszczając zwykłych odwiedzających.

Ile trwa zniknięcie błędu z raportu po naprawie?

Raport aktualizuje się wtedy, gdy Google ponownie odwiedzi adresy. Weryfikacja uruchomiona przyciskiem „Sprawdź poprawkę” trwa zazwyczaj do 2 tygodni, a w niektórych przypadkach znacznie dłużej. Przyspieszanie przez wielokrotne klikanie przycisku nie działa.

Czy tryb konserwacji podczas aktualizacji strony szkodzi?

Kod 503 jest właściwą odpowiedzią na czas krótkiej przerwy technicznej i informuje robota, że niedostępność jest przejściowa. Szkodzi dopiero przerwa wielodniowa. Google wskazuje granicę 2 lub 3 dni przy celowym zwracaniu kodów 503 i 429, po której witryna może być trwale odwiedzana rzadziej.

Czy da się sprawdzić, jaki dokładnie kod otrzymał Googlebot?

Tak. W raporcie „Statystyki indeksowania” po kliknięciu wiersza „Błąd serwera (5XX)” widać przykładowe żądania z godziną i kodem odpowiedzi. Pełniejszy obraz dają dzienniki dostępu serwera, o ile żądanie w ogóle do niego dotarło.

Czy raport „Statystyki indeksowania” jest dostępny dla każdej strony?

Raport jest dostępny dla usług najwyższego poziomu, czyli dla usługi domeny lub usługi z prefiksem URL obejmującej całą domenę albo subdomenę. Jeśli w Search Console dodano tylko usługę dla katalogu, trzeba dodać i zweryfikować usługę dla całej domeny.

Czy trzeba zmieniać hosting, gdy pojawi się ten błąd?

Nie przy pierwszym wystąpieniu. Najpierw należy ustalić przyczynę, bo bardzo często leży ona w kodzie strony lub w ustawieniach ochrony, a wtedy przenosiny niczego nie zmienią. Zmianę dostawcy warto rozważyć dopiero wtedy, gdy dzienniki i monitoring potwierdzają powtarzające się przerwy po stronie serwera, a pomoc techniczna nie potrafi ich usunąć.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Szukanie przyczyny błędu serwera wymaga zaglądania w kilka miejsc naraz i nie każdy chce to robić między obsługą klientów a fakturami. Mogę przejąć tę sprawę od początku do końca: odczytam w Search Console, kiedy i pod jakimi adresami robot Google napotkał błąd, przejrzę dzienniki serwera, ustalę, czy zawinił hosting, wtyczka, zapora czy nadmiar adresów, doprowadzę do naprawy we współpracy z firmą hostingową, a na koniec zgłoszę adresy do ponownego sprawdzenia i dopilnuję wyniku weryfikacji.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony. Odpowiem, co widać w raportach i co należy zrobić w pierwszej kolejności.