Błąd 503 w WordPressie. Dlaczego usługa bywa niedostępna i jak to sprawdzić?

Komunikat „503 Service Unavailable” albo „Usługa niedostępna” potrafi pojawić się na stronie firmy bez żadnej zapowiedzi i po kilku minutach zniknąć. Bywa też, że zostaje na dłużej i blokuje zarówno stronę publiczną, jak i panel WordPressa. W obu przypadkach klienci nie widzą oferty, a formularz i koszyk nie działają.

Ta instrukcja jest przeznaczona dla właścicieli firm i osób, które samodzielnie opiekują się stroną na WordPressie. Opisuję w niej, co naprawdę oznacza kod 503, jakie ma najczęstsze przyczyny, jak ustalić, która z nich zachodzi, i jak naprawić każdą z nich po kolei.

Po lekturze czytelnik będzie umiał wyprowadzić witrynę z trybu konserwacji, odczytać w panelu hostingu, czy zabrakło zasobów, znaleźć wadliwą wtyczkę bez dostępu do kokpitu, napisać konkretne zgłoszenie do firmy hostingowej i ocenić w Google Search Console, czy przerwa zaszkodziła widoczności strony.

Co oznacza błąd 503 i czym różni się od innych błędów serwera?

Kod 503 należy do grupy błędów serwera, oznaczanych jako 5xx. Dokumentacja standardu HTTP opisuje go krótko: serwer nie jest w tej chwili gotowy do obsłużenia zapytania. Ten kod jest przewidziany dla stanów przejściowych, takich jak prace serwisowe albo przeciążenie.

To ważna różnica wobec pozostałych błędów. Serwer nie twierdzi, że coś zepsuło się w kodzie strony. Informuje, że działa, ale chwilowo nie przyjmuje zapytań, bo jest zajęty, wyłączony na czas prac albo celowo odmawia obsługi, żeby się nie zawiesić.

Do odpowiedzi z kodem 503 serwer może dołączyć nagłówek Retry-After, czyli informację, po jakim czasie warto spróbować ponownie. Czytają go przeglądarki i roboty wyszukiwarek. WordPress sam wysyła taki nagłówek w czasie aktualizacji, o czym mowa w dalszej części tekstu.

Dla porównania: błąd 500 oznacza usterkę przy wykonywaniu kodu, a błąd 504 brak odpowiedzi w wyznaczonym czasie. Osobno opisałem, co przy błędzie 502 leży po stronie hostingu, a co po stronie witryny, bo tam serwer pośredniczący dostaje nieprawidłową odpowiedź z głębi. Przy 503 pytanie brzmi inaczej: dlaczego usługa odmówiła pracy i czy zrobiła to celowo.

Jak wygląda ten komunikat na ekranie?

Postać komunikatu zależy od tego, kto go wysłał. Serwer WWW pokazuje zwykle białą stronę z napisem „503 Service Unavailable” albo „Service Temporarily Unavailable”. Przeglądarka może wyświetlić „HTTP ERROR 503”. Część firm hostingowych podmienia ten ekran na własną planszę z informacją o przekroczeniu limitów konta.

WordPress w trakcie aktualizacji pokazuje krótką notę o chwilowej niedostępności z powodu zaplanowanej konserwacji. W wersji angielskiej brzmi ona „Briefly unavailable for scheduled maintenance. Check back in a minute.”. Ta nota również jest wysyłana z kodem 503, choć samej liczby na ekranie nie widać.

Jeśli witryna korzysta z sieci CDN albo usługi ochronnej, komunikat może pochodzić od niej. Wtedy na ekranie widać nazwę tej usługi, a nie serwera hostingowego. To pierwsza wskazówka, gdzie szukać przyczyny.

Jak wykluczyć problem po własnej stronie?

Przed szukaniem przyczyny na serwerze trzeba upewnić się, że błąd widzą wszyscy, a nie tylko jedno urządzenie. Stronę otwiera się w oknie prywatnym przeglądarki oraz na telefonie korzystającym z sieci komórkowej zamiast z firmowego Wi-Fi.

Jeśli w innej sieci strona działa, serwer mógł czasowo ograniczyć dostęp z jednego adresu, na przykład po wielu szybkich odświeżeniach albo nieudanych logowaniach. Taka blokada zwykle mija sama. Jeśli błąd widać wszędzie, przyczyna leży po stronie serwera lub witryny.

Jak w kilka minut zawęzić listę przyczyn?

Kod 503 ma w WordPressie kilka typowych źródeł. Zanim zacznie się cokolwiek zmieniać, trzeba zebrać kilka obserwacji. Zajmuje to parę minut i pozwala uniknąć przypadkowych zmian.

1. Należy otworzyć stronę główną, dowolną podstronę oraz adres logowania, czyli adres witryny z końcówką /wp-admin. Trzeba zanotować, które z tych miejsc pokazują błąd i jak dokładnie brzmi komunikat.
2. Stronę odświeża się kilka razy w odstępach około minuty. Błąd, który pojawia się i znika, wskazuje na brak zasobów. Błąd stały wskazuje na tryb konserwacji, zatrzymaną usługę albo trwałą usterkę.
3. Trzeba ustalić, co działo się tuż przed awarią: aktualizacja WordPressa, wtyczki lub motywu, instalacja nowego dodatku, import produktów, wysyłka newslettera, start kampanii reklamowej.
4. W panelu klienta firmy hostingowej i na jej stronie ze statusem usług należy poszukać informacji o awarii albo pracach serwisowych. Jeśli hosting je potwierdza, pozostaje poczekać.
5. W tym samym panelu warto otworzyć wykresy zużycia zasobów konta i porównać godzinę awarii z godziną szczytu na wykresie.
6. Jeśli na tym samym koncie działa inna strona, trzeba ją otworzyć. Gdy ona również zwraca 503, przyczyna dotyczy całego konta lub serwera, a nie jednej witryny.

Zebrane obserwacje układają się zwykle w jeden z pięciu obrazów. Każdy z nich prowadzi do innej części tej instrukcji.

Pierwszy obraz to nota o konserwacji, która nie znika po kilkunastu minutach od aktualizacji. Drugi to błąd pojawiający się falami, w godzinach większego ruchu albo o stałych porach, co wskazuje na limity konta hostingowego. Trzeci to błąd, który zaczął się zaraz po instalacji lub aktualizacji dodatku.

Czwarty obraz to 503 widoczny głównie w panelu, zwłaszcza gdy kokpit jest otwarty w kilku kartach albo u kilku osób jednocześnie. Tu podejrzenie pada na zadania działające w tle. Piąty to nagły napływ zapytań od automatów, widoczny w dzienniku serwera. Zdarza się też, że nakłada się kilka przyczyn naraz, na przykład ciężka wtyczka i zbyt mały pakiet hostingowy.

Co zrobić, gdy witryna utknęła w trybie konserwacji po aktualizacji?

Podczas aktualizacji WordPress tworzy w głównym katalogu witryny plik o nazwie .maintenance. Dopóki plik istnieje, każdy odwiedzający dostaje notę o konserwacji z kodem 503 i nagłówkiem Retry-After ustawionym na 600 sekund. Po zakończeniu aktualizacji WordPress sam usuwa ten plik.

Problem pojawia się wtedy, gdy aktualizacja zostanie przerwana: karta przeglądarki została zamknięta, połączenie się zerwało albo serwer zakończył działanie skryptu przed czasem. Plik zostaje na serwerze, a witryna dalej pokazuje notę. WordPress przestaje brać go pod uwagę po około dziesięciu minutach od utworzenia, więc krótka przerwa zwykle kończy się sama.

Jeśli po kwadransie nota nadal jest widoczna albo zależy komuś na czasie, plik usuwa się ręcznie. Oficjalna dokumentacja WordPressa wskazuje dokładnie to rozwiązanie.

1. Należy zalogować się do panelu firmy hostingowej i otworzyć menedżera plików albo połączyć się z serwerem programem FTP, korzystając z danych dostępowych od hostingu.
2. Trzeba przejść do głównego katalogu witryny. To ten, w którym znajdują się plik wp-config.php oraz foldery wp-admin, wp-content i wp-includes.
3. W ustawieniach menedżera plików lub programu FTP włącza się wyświetlanie plików ukrytych. Nazwa pliku zaczyna się od kropki, dlatego bez tej opcji zwykle go nie widać.
4. Plik .maintenance należy skasować. Żadnego innego pliku w tym katalogu nie wolno przy tej okazji zmieniać.
5. Stronę otwiera się w oknie prywatnym przeglądarki. Jeśli nota zniknęła, trzeba zalogować się do kokpitu.
6. W kokpicie należy otworzyć „Kokpit” i „Aktualizacje”, a następnie ponownie uruchomić aktualizację, która została przerwana. Niedokończona aktualizacja wtyczki lub motywu może pozostawić niekompletne pliki.

Po czym poznać, że naprawa zadziałała? Strona publiczna i panel otwierają się normalnie, a na ekranie „Aktualizacje” nie ma dodatku, który figuruje jako zaktualizowany tylko częściowo. Jeśli po skasowaniu pliku pojawia się inny komunikat, na przykład o błędzie krytycznym, oznacza to, że przerwana aktualizacja uszkodziła dodatek. Wtedy należy przejść do części o wyszukiwaniu wadliwej wtyczki.

Na przyszłość radzę aktualizować dodatki pojedynczo lub w małych grupach i nie zamykać karty do końca operacji. Przed większą aktualizacją dobrze jest mieć świeżą kopię, a sposób jej wykonania opisałem w tekście o tym, jak zrobić i sprawdzić kopię zapasową WordPressa.

A jeśli tryb konserwacji włącza wtyczka?

Część właścicieli korzysta z wtyczek, które pokazują planszę „Strona w budowie” albo „Przerwa techniczna”. Takie dodatki często wysyłają kod 503 celowo i robią to tak długo, jak długo są włączone. Jeśli nikt nie pamięta, że plansza została kiedyś aktywowana, witryna może zwracać 503 przez wiele dni.

Sprawdzenie jest proste: po zalogowaniu się do kokpitu trzeba otworzyć „Wtyczki” i „Zainstalowane wtyczki”, znaleźć dodatek odpowiedzialny za planszę i wyłączyć w jego ustawieniach tryb przerwy technicznej albo wyłączyć całą wtyczkę. Osoby zalogowane często widzą normalną stronę, dlatego efekt należy ocenić w oknie prywatnym.

Jak sprawdzić, czy witrynie zabrakło zasobów na hostingu?

Najczęstszą przyczyną nawracającego błędu 503 jest wyczerpanie zasobów przydzielonych kontu hostingowemu. Każde zapytanie o stronę, która nie pochodzi z pamięci podręcznej, zajmuje na chwilę jeden proces PHP. Liczba procesów działających jednocześnie jest ograniczona pakietem. Gdy wszystkie są zajęte, kolejne zapytania czekają, a po przekroczeniu progu serwer odpowiada kodem 503.

Na hostingu współdzielonym limity obejmują zwykle czas procesora, pamięć operacyjną, liczbę procesów i liczbę jednoczesnych połączeń. Nazwy i wartości różnią się u poszczególnych firm, dlatego dokładnych liczb należy szukać w opisie własnego pakietu, a nie w ogólnych tekstach.

W panelu hostingu trzeba odnaleźć sekcję ze statystykami zużycia zasobów. W zależności od firmy nosi ona nazwę zbliżoną do „Wykorzystanie zasobów”, „Statystyki” albo „Obciążenie”. Istotne są trzy rzeczy: czy w godzinie awarii któryś z wykresów dotknął górnej granicy, czy panel odnotował przekroczenia limitu i czy zdarza się to regularnie.

Jeśli wykresy dochodzą do limitu, wniosek jest jasny: witryna potrzebuje więcej, niż daje pakiet, albo coś zużywa zasoby bez potrzeby. Zwiększenie pakietu usuwa objaw, ale nie zawsze przyczynę. Dlatego przed dopłatą warto ustalić, co dokładnie obciąża serwer.

Co mówi dziennik serwera?

Drugim źródłem wiedzy są dzienniki, dostępne w panelu hostingu zwykle pod nazwą „Logi” lub „Dzienniki”. Dziennik dostępu pokazuje każde zapytanie: adres, z którego przyszło, godzinę, żądany plik i kod odpowiedzi. Dziennik błędów pokazuje komunikaty serwera i PHP.

W dzienniku dostępu należy odszukać wiersze z kodem 503 i przyjrzeć się temu, co działo się tuż przed nimi. Długa seria zapytań do pliku admin-ajax.php wskazuje na zadania panelu działające w tle. Seria zapytań do wp-cron.php wskazuje na harmonogram zadań. Setki zapytań z jednego adresu do wp-login.php albo xmlrpc.php to ślad automatów próbujących się zalogować.

Jeśli panel hostingu nie daje dostępu do dzienników albo ich odczytanie sprawia trudność, o wyciąg z godziny awarii można poprosić dział pomocy. Gotową treść takiego zgłoszenia podaję w dalszej części tekstu.

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ę: ustalę na podstawie dzienników i panelu hostingu, co wywołuje błąd 503, usunę przyczynę i sprawdzę, czy przerwa nie zaszkodziła stronie w Google.

Jak znaleźć wtyczkę lub motyw, które wywołują błąd?

Jeśli błąd pojawił się po instalacji albo aktualizacji dodatku, pierwszym podejrzanym jest właśnie on. Wtyczka może zużywać zbyt dużo pamięci, wykonywać ciężkie zapytania do bazy przy każdej odsłonie albo łączyć się z zewnętrzną usługą, która przestała odpowiadać. W każdym z tych przypadków procesy PHP pracują dłużej, niż powinny, i szybko brakuje wolnych.

Gdy kokpit jest dostępny, sprawa jest prosta: w menu „Wtyczki” i „Zainstalowane wtyczki” wyłącza się ostatnio dodany lub zaktualizowany dodatek i obserwuje, czy błąd wraca. Gdy kokpit również zwraca 503, wtyczki wyłącza się z poziomu plików. To bezpieczna metoda, bo niczego nie kasuje.

1. Należy otworzyć menedżera plików w panelu hostingu albo połączyć się z serwerem przez FTP i przejść do folderu wp-content.
2. Nazwę folderu plugins zmienia się na plugins-wylaczone. WordPress nie znajdzie wtedy żadnej wtyczki i uzna wszystkie za nieaktywne.
3. Stronę i adres /wp-admin otwiera się w oknie prywatnym. Jeśli błąd 503 zniknął, przyczyną jest jedna z wtyczek.
4. Folderowi trzeba przywrócić pierwotną nazwę plugins. Wtyczki pozostaną nieaktywne, ale będą widoczne w kokpicie.
5. W kokpicie, w menu „Wtyczki”, włącza się dodatki pojedynczo, zaczynając od najważniejszych. Po każdym włączeniu należy odświeżyć stronę publiczną i odczekać chwilę.
6. Wtyczka, po której włączeniu błąd wraca, jest przyczyną błędu. Jeśli kokpit znów przestanie działać, wystarczy zmienić nazwę folderu tej jednej wtyczki wewnątrz plugins.

Po wskazaniu wadliwego dodatku są trzy drogi: aktualizacja do nowszej wersji, przywrócenie poprzedniej wersji z kopii albo zastąpienie go innym rozwiązaniem. Radzę też zgłosić problem autorowi wtyczki, podając wersję WordPressa i PHP. Te dane znajdują się w kokpicie, w menu „Narzędzia” i „Stan witryny”, na karcie „Informacje”.

Jeśli wyłączenie wszystkich wtyczek nie pomogło, w ten sam sposób sprawdza się motyw. W folderze wp-content/themes zmienia się nazwę folderu aktywnego motywu. WordPress przełączy się wtedy na jeden z motywów domyślnych, pod warunkiem że któryś jest zainstalowany. Przed tą próbą trzeba więc upewnić się, że w folderze znajduje się motyw domyślny, którego nazwa zaczyna się od słowa „twenty”.

Jak włączyć zapis błędów do pliku?

Gdy metoda wyłączania nie daje jednoznacznej odpowiedzi, pomaga dziennik błędów samego WordPressa. Włącza się go w pliku wp-config.php, w głównym katalogu witryny. Przed zmianą należy pobrać kopię tego pliku na dysk, bo literówka w nim zatrzymuje całą stronę.

Poniższe wiersze wkleja się przed wierszem z komentarzem zawierającym słowa „stop editing”. Jeśli wiersz ze stałą WP_DEBUG już w pliku istnieje, należy zmienić jego wartość, a nie wklejać drugi.

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

Pierwszy wiersz włącza tryb diagnostyczny, drugi każe zapisywać komunikaty do pliku debug.log w folderze wp-content, a trzeci ukrywa je przed odwiedzającymi. Po odtworzeniu błędu plik otwiera się w menedżerze plików i czyta ostatnie wpisy. W ścieżce widocznej w komunikacie zwykle pojawia się nazwa folderu wtyczki lub motywu.

Po zakończeniu diagnozy wartość WP_DEBUG trzeba ustawić z powrotem na false, a plik debug.log skasować. Dziennik pozostawiony na serwerze rośnie i może zawierać informacje, których nie powinny czytać osoby postronne.

Jak ograniczyć zadania działające w tle: Heartbeat i WP-Cron?

WordPress wykonuje część pracy bez wiedzy użytkownika. Dwa mechanizmy potrafią przy słabszym pakiecie hostingowym zająć wszystkie wolne procesy: Heartbeat oraz WP-Cron.

Heartbeat to wbudowany mechanizm, dzięki któremu przeglądarka z otwartym kokpitem co pewien czas odpytuje serwer. Według dokumentacji WordPressa odstęp wynosi od 15 do 120 sekund. Służy to między innymi do automatycznego zapisu wpisów i blokowania edycji tej samej treści przez dwie osoby. Każde takie odpytanie zajmuje proces PHP.

Jedna otwarta karta nie stanowi problemu. Kilka osób z kokpitem otwartym w wielu kartach przez cały dzień to już stały strumień zapytań do admin-ajax.php. Najprostsze rozwiązanie nie wymaga żadnych narzędzi: należy zamykać karty kokpitu, w których nikt nie pracuje. Częstotliwość odpytywania można też zmniejszyć w ustawieniach wielu wtyczek do optymalizacji. Całkowitego wyłączania nie polecam, bo przestaje wtedy działać automatyczny zapis w edytorze.

Kiedy harmonogram zadań obciąża serwer?

WP-Cron odpowiada za zadania zaplanowane: publikację wpisów o ustalonej godzinie, sprawdzanie aktualizacji, wysyłkę wiadomości, kopie zapasowe. Nie działa w sposób ciągły. WordPress sprawdza przy każdym wczytaniu strony, czy jest coś do wykonania. Przy dużym ruchu oznacza to dodatkową pracę przy bardzo wielu odsłonach.

Dokumentacja WordPressa opisuje rozwiązanie: wyłączenie uruchamiania przy odsłonach i zlecenie tego zadania harmonogramowi serwera. W pliku wp-config.php dopisuje się wiersz:

define( 'DISABLE_WP_CRON', true );

Następnie w panelu hostingu, w sekcji o nazwie zbliżonej do „Zadania Cron” lub „Harmonogram zadań”, tworzy się zadanie, które w stałych odstępach wywołuje adres witryny z końcówką /wp-cron.php. Sposób wpisania polecenia zależy od panelu, dlatego dokładnej składni należy szukać w pomocy własnej firmy hostingowej. Odstęp dobiera się do potrzeb witryny: sklep z wieloma zamówieniami potrzebuje częstszego wywołania niż strona wizytówka.

Uwaga: dopisanie samego wiersza bez utworzenia zadania na serwerze zatrzymuje wszystkie zaplanowane czynności. Zaplanowane wpisy przestaną się publikować, a kopie zapasowe wykonywać. Obie zmiany trzeba wprowadzić razem, a następnie sprawdzić, czy wpis zaplanowany na próbę ukazał się o czasie.

Co zrobić, gdy serwer przeciążają automaty albo nagły ruch?

Nie każde przeciążenie wynika z budowy witryny. Zdarza się, że serwer zalewają zapytania automatów: programów próbujących odgadnąć hasło, narzędzi kopiujących treść albo robotów indeksujących, które pracują zbyt szybko. W dzienniku dostępu widać to jako długie serie zapytań z tych samych adresów w bardzo krótkich odstępach.

Bezpieczne środki są trzy. Pierwszy to ochrona logowania: mocne hasła, ograniczenie liczby prób i wyłączenie obsługi pliku xmlrpc.php, jeśli żadna używana usługa z niego nie korzysta. Drugi to zapora aplikacyjna albo sieć CDN, która zatrzymuje część szkodliwego ruchu, zanim dotrze on do serwera. Trzeci to pamięć podręczna stron, dzięki której większość odsłon nie wymaga pracy PHP.

Odradzam blokowanie adresów na oślep, zwłaszcza całych krajów lub zakresów. Łatwo w ten sposób odciąć prawdziwych klientów albo roboty Google. Jeśli ruch wygląda na atak, należy zgłosić to firmie hostingowej, która widzi go z poziomu całego serwera i ma do tego właściwe narzędzia.

Osobną sytuacją jest prawdziwy wzrost zainteresowania, na przykład po kampanii reklamowej lub publikacji w mediach. Wtedy pomaga pamięć podręczna, a na dłuższą metę wyższy pakiet hostingowy. O szukaniu elementów, które niepotrzebnie obciążają witrynę, piszę szerzej w tekście o tym, co spowalnia WordPressa.

Jak napisać zgłoszenie do firmy hostingowej, na które da się konkretnie odpowiedzieć?

Dział pomocy widzi rzeczy niedostępne dla klienta: stan całego serwera, pełne dzienniki i licznik przekroczeń limitów. Odpowiedź będzie tym lepsza, im dokładniejsze pytanie. Wiadomość o treści „strona nie działa” kończy się zwykle prośbą o szczegóły i stratą kilku godzin.

Poniższy wzór można przepisać, uzupełniając dane w nawiasach kwadratowych:

Dzień dobry,
witryna [adres] zwraca błąd 503. Pierwszy raz zauważono go [dzień i godzina], ostatni raz [dzień i godzina].
Błąd występuje [stale / falami], na [stronie publicznej / w panelu / w obu miejscach].
Przed awarią wykonano: [np. aktualizację wtyczki o nazwie ...].
Proszę o informacje:
1. Czy w tym czasie konto przekroczyło limity i które dokładnie?
2. Co zapisano w dzienniku błędów dla tej domeny w godzinie awarii?
3. Czy na serwerze trwały prace lub wystąpiła awaria?
4. Które adresy lub pliki generowały w tym czasie najwięcej zapytań?

Do zgłoszenia warto dołączyć zrzut ekranu z komunikatem. Jeśli odpowiedź wskazuje na przekroczenie limitu, kolejne pytanie powinno dotyczyć tego, który skrypt zużywał najwięcej zasobów. Taka informacja prowadzi wprost do wtyczki lub zadania, którym trzeba się zająć.

Czy błąd 503 szkodzi widoczności w Google i jak to sprawdzić?

Krótka przerwa nie wyrządza szkody. Kod 503 jest dla robotów czytelnym sygnałem, że kłopot jest chwilowy. Dokumentacja Google podaje, że błędy serwera z grupy 5xx informują roboty, iż na pewien czas należy zwolnić indeksowanie. Adresy już zindeksowane pozostają w indeksie, ale te, które stale zwracają błąd serwera, są z niego po jakimś czasie usuwane.

Z tej samej dokumentacji wynikają dwie praktyczne granice. Google zaleca, by kodu 503 nie zwracać dłużej niż przez około dwa dni, bo później adresy mogą zacząć wypadać z indeksu. Druga dotyczy pliku robots.txt: jeśli on sam zwraca błąd 5xx, Google przez pierwsze 12 godzin wstrzymuje indeksowanie witryny, a przez kolejne 30 dni korzysta z ostatniej poprawnie pobranej wersji pliku.

Po przywróceniu działania serwera Google stopniowo zwiększa szybkość indeksowania. Nie trzeba niczego zgłaszać, ale warto sprawdzić, jak przerwę odnotowano w Google Search Console.

1. Należy zalogować się do Google Search Console i wskazać właściwą usługę.
2. W menu bocznym trzeba kliknąć „Ustawienia”, a następnie otworzyć raport „Statystyki indeksowania”. Raport jest dostępny dla usług najwyższego poziomu, czyli dla całej domeny lub prefiksu adresu na najwyższym poziomie.
3. W części „Stan hosta” odczytuje się ocenę dostępności z ostatnich 90 dni. Opis „Niedawny problem” oznacza istotny kłopot w ostatnim tygodniu, a „Problem sprzed ponad tygodnia” kłopot starszy.
4. W tabeli „Odpowiedzi na żądania robota indeksującego” należy otworzyć wiersz „Błąd serwera (5XX)”. Widać w nim przykładowe adresy i godziny, w których robot otrzymał błąd.
5. W menu bocznym otwiera się raport „Indeksowanie stron” i szuka na liście przyczyn pozycji „Błąd serwera (5xx)”.
6. Jeśli taka pozycja istnieje, a przyczyna została już usunięta, po jej otwarciu należy użyć przycisku „Sprawdź poprawkę”. Według pomocy Google weryfikacja trwa zazwyczaj do dwóch tygodni, a o wyniku informuje wiadomość e-mail.

Godziny z raportu dobrze jest zestawić z wykresami zużycia zasobów na hostingu. Jeśli błędy pojawiają się o stałych porach, najczęściej pokrywają się z kopią zapasową, importem danych albo wysyłką wiadomości. Gdy po dłuższej awarii część podstron wypadła z wyników, pomocny będzie tekst o tym, co sprawdzić, gdy strona zniknęła z Google.

Jak zapobiec powrotowi błędu i jakich pomyłek unikać?

Błąd 503, który wraca co kilka dni, rzadko jest przypadkiem. Zwykle oznacza, że witryna pracuje na granicy możliwości pakietu i wystarczy niewielki dodatkowy ruch, aby tę granicę przekroczyć. Trwałe rozwiązanie składa się z kilku prostych nawyków.

• Pamięć podręczna stron powinna być włączona i sprawdzona w oknie prywatnym, bo zalogowany administrator zwykle jej nie widzi.
• Ciężkie zadania, takie jak kopie zapasowe, importy i masowe wysyłki, planuje się na godziny najmniejszego ruchu.
• Nieużywane wtyczki należy odinstalować, a nie tylko wyłączyć, i raz na kwartał przejrzeć listę dodatków.
• Aktualizacje wykonuje się regularnie, pojedynczo lub w małych grupach, po zrobieniu kopii.
• Dostępność witryny powinna śledzić zewnętrzna usługa monitorująca, która wysyła powiadomienie, gdy strona przestaje odpowiadać.

Najczęstsza pomyłka to działanie w pośpiechu na plikach bez kopii. Kasowanie folderów wtyczek zamiast zmiany ich nazwy, edycja wp-config.php bez pobrania oryginału czy przywracanie całej witryny z kopii sprzed tygodnia mogą kosztować utratę zamówień i treści. Zmiana nazwy jest zawsze odwracalna, a kasowanie nie.

Druga pomyłka to natychmiastowa dopłata do wyższego pakietu bez diagnozy. Jeśli zasoby zużywa jedna wadliwa wtyczka albo automaty, większy pakiet tylko odsunie problem. Trzecia to pozostawienie planszy przerwy technicznej na wiele dni. Gdy prace mają potrwać dłużej, lepiej prowadzić je na kopii roboczej witryny, a stronę publiczną zostawić dostępną.

Najczęstsze pytania

Czy błąd 503 oznacza, że strona została zhakowana?

Zazwyczaj nie. Kod 503 informuje o chwilowej niedostępności usługi, najczęściej z powodu przeciążenia albo prac serwisowych. Zainfekowana witryna może jednak zużywać dużo zasobów, na przykład rozsyłając niechciane wiadomości, i w ten sposób pośrednio doprowadzać do tego błędu. Jeśli w dzienniku widać nieznane pliki lub nietypowe zadania, trzeba to zbadać osobno.

Ile czasu wolno czekać, zanim zacznie się działać?

Po aktualizacji rozsądnie jest odczekać kilkanaście minut, bo tryb konserwacji zwykle kończy się sam. Jeśli błąd nie ma związku z aktualizacją i trwa dłużej niż kilka minut, należy od razu sprawdzić stronę statusu hostingu i wykresy zasobów. Z punktu widzenia Google istotna jest granica około dwóch dni ciągłego zwracania kodu 503.

Dlaczego błąd pojawia się tylko w panelu, a strona publiczna działa?

Odwiedzający otrzymują zwykle strony z pamięci podręcznej, które nie wymagają pracy PHP. Kokpit zawsze jej wymaga, więc brak wolnych procesów widać w nim najpierw. Taki obraz wskazuje na zadania w tle, zbyt wiele otwartych kart panelu albo ciężką wtyczkę działającą po stronie administracyjnej.

Czy zwiększenie limitu pamięci PHP usuwa błąd 503?

Rzadko. Brak pamięci dla pojedynczego skryptu kończy się raczej błędem krytycznym lub kodem 500. Błąd 503 wynika zwykle z liczby jednoczesnych procesów albo z łącznego zużycia zasobów konta, a wyższy limit pamięci na skrypt może to zużycie nawet zwiększyć.

Czy planowaną przerwę techniczną lepiej oznaczyć kodem 503, czy zwykłą stroną z informacją?

Przy krótkiej przerwie właściwy jest kod 503 z nagłówkiem Retry-After, bo roboty rozumieją go jako stan chwilowy i nie zapisują planszy jako treści strony. Google zaznacza przy tym, że taki stan powinien trwać najwyżej dzień lub dwa i że plik robots.txt nie powinien w tym czasie zwracać kodu 503.

Czy sieć CDN może sama wywołać błąd 503?

Tak. Usługa pośrednicząca może zwrócić 503, gdy sama ma awarię, gdy uzna ruch za podejrzany albo gdy nie może połączyć się z serwerem docelowym. Jeśli na planszy widnieje nazwa tej usługi, należy sprawdzić jej stronę statusu i na próbę wstrzymać pośredniczenie w jej panelu, o ile taka opcja jest dostępna.

Co zrobić, gdy żadna z opisanych metod nie pomogła?

Należy zebrać wszystkie ustalenia w jednym miejscu: godziny awarii, wynik próby z wyłączonymi wtyczkami i motywem domyślnym, wpisy z dziennika oraz odpowiedź hostingu. Taki zestaw pozwala specjaliście szybko wskazać przyczynę. Jeśli hosting potwierdza, że limity nie są przekraczane, a witryna bez wtyczek nadal zwraca błąd, problem leży w konfiguracji serwera i wymaga działania po stronie firmy hostingowej.

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

Błąd 503 potrafi zabrać cały dzień, zwłaszcza gdy pojawia się falami i nie widać, co go wywołuje. Chętnie zajmę się tym od początku do końca: sprawdzę dzienniki i zużycie zasobów, wyprowadzę witrynę z trybu konserwacji, znajdę wtyczkę lub zadanie, które obciąża serwer, uporządkuję działanie harmonogramu i pamięci podręcznej, a w razie potrzeby przeprowadzę rozmowę z firmą hostingową. Na koniec sprawdzę w Google Search Console, czy przerwa nie zostawiła śladów, i opiszę prostym językiem, co zostało zrobione.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz godzinę, o której błąd się pojawił. Resztą zajmę się sam.