Jak włączyć tryb konserwacji z kodem 503 w WordPressie?

Tryb konserwacji z kodem 503 to ustawienie, przy którym WordPress pokazuje każdemu niezalogowanemu odwiedzającemu stronę z komunikatem o przerwie zamiast zwykłej treści i odpowiada przy tym statusem HTTP 503 Service Unavailable. Włączysz go wtyczką albo kilkunastoma linijkami własnego kodu, zwykle na czas migracji hostingu, dużej aktualizacji lub przebudowy motywu. Kod 503 z nagłówkiem Retry-After mówi Google, że niedostępność jest tymczasowa, więc przy przerwie do 1-2 dni adresy zostają w indeksie.

Czym różni się tryb konserwacji z kodem 503 od strony „w budowie” z kodem 200?

Różnica jest w kodzie odpowiedzi HTTP, nie w wyglądzie strony. Kod 503 mówi robotowi, że strona chwilowo nie działa i wróci, a kod 200 zapewnia go, że komunikat „trwają prace” to normalna treść tej podstrony.

Kod 503 należy do klasy błędów serwera 5xx i według RFC 9110 (sekcja 15.6.4) oznacza, że serwer chwilowo nie może obsłużyć żądania z powodu przeciążenia lub planowanej konserwacji. Google reaguje na niego tak jak na przerwę: ignoruje treść z takiej odpowiedzi, zachowuje zaindeksowane adresy i wraca po nie później.

Strona z napisem „przerwa techniczna” zwracana z kodem 200 wygląda dla użytkownika tak samo, ale dla Google to zwykła podstrona z nową treścią. Robot może zaindeksować komunikat jako treść strony głównej albo uznać podstronę za pustą, a po zakończeniu prac musi ją pobrać i ocenić od nowa.

Wiele wtyczek ma obok siebie dwa tryby: „coming soon” (kod 200, dla nowych stron, których jeszcze nie ma w indeksie) i „maintenance” (kod 503, dla istniejących stron na czas prac). Przy przerwie na działającej stronie wybierasz ten drugi.

Kiedy WordPress sam włącza tryb konserwacji?

WordPress włącza własny tryb konserwacji automatycznie na czas aktualizacji rdzenia, wtyczek i motywów. Tworzy wtedy w katalogu głównym instalacji plik .maintenance, a funkcja wp_maintenance() pokazuje każdemu odwiedzającemu komunikat „Briefly unavailable for scheduled maintenance. Check back in a minute.” z kodem 503 i nagłówkiem Retry-After: 600.

Plik znika po zakończeniu prac, a WordPress ignoruje go, gdy ma więcej niż 10 minut, żeby przerwana aktualizacja nie zablokowała strony na stałe. Ten mechanizm nie daje kontroli nad treścią komunikatu ani nad tym, jak długo potrwa, więc nie nadaje się do planowanej przerwy. Do świadomego włączenia trybu konserwacji służą dwie metody z kolejnych sekcji: wtyczka albo własny kod. Co zrobić, gdy komunikat o aktualizacji nie znika, opisujemy dalej, w części o utknięciu strony w tym trybie.

Jak włączyć tryb konserwacji wtyczką?

Zainstaluj wtyczkę trybu konserwacji, wybierz w niej tryb „maintenance” (kod 503), wpisz komunikat, włącz przełącznik i sprawdź kod odpowiedzi. Przykłady wtyczek z tej grupy to WP Maintenance Mode i Maintenance; działają podobnie, różnią się edytorem strony z komunikatem.

1

Instalacja

W panelu Wtyczki → Dodaj nową wpisz „maintenance mode”, kliknij Zainstaluj, potem Włącz.

2

Tryb

W ustawieniach wtyczki wybierz tryb konserwacji (maintenance), nie „coming soon”. Wtyczka powinna wprost informować, że zwraca kod 503; jeśli tego nie pisze, sprawdzisz to w sekcji o teście kodu odpowiedzi.

3

Komunikat

Napisz, co się dzieje i kiedy strona wróci, a do tego podaj telefon albo adres e-mail, bo formularz kontaktowy w tym czasie nie działa.

4

Wyjątki

Ustaw role, które mają widzieć zwykłą witrynę (domyślnie administrator), i ewentualnie adresy działające normalnie, na przykład stronę kontaktu.

5

Włączenie i test

Przełącz tryb na aktywny, wyczyść cache (w LiteSpeed Cache: Purge All) i otwórz stronę w oknie incognito. Zalogowany administrator widzi witrynę bez zmian, więc test z tego samego okna niczego nie dowodzi.

Jedne wtyczki wysyłają nagłówek Retry-After automatycznie, ze stałą wartością, inne mają pole na tę wartość w ustawieniach, a jeszcze inne pomijają go zupełnie. Tę różnicę widać tylko w nagłówkach odpowiedzi, dlatego test z sekcji o curl -I jest częścią instrukcji, nie dodatkiem. Tryb wyłącza się tym samym przełącznikiem, po którym znów trzeba wyczyścić cache.

Jak włączyć tryb konserwacji własnym kodem, bez wtyczki?

Dodaj funkcję podpiętą pod hook template_redirect, która dla każdego, kto nie jest administratorem, wysyła nagłówki 503 i Retry-After, wypisuje komunikat i kończy działanie. Dokładnie to robi poniższy fragment:

<?php
/**
 * Plugin Name: Tryb konserwacji (503)
 * Description: Zwraca 503 z Retry-After dla niezalogowanych. Usuń plik, żeby wyłączyć.
 */
add_action( 'template_redirect', function () {
    // Administrator widzi stronę normalnie.
    if ( current_user_can( 'manage_options' ) ) {
        return;
    }
    // robots.txt ma dalej odpowiadać kodem 200 (patrz sekcja o robots.txt).
    if ( is_robots() ) {
        return;
    }
    header( 'HTTP/1.1 503 Service Unavailable' );
    header( 'Status: 503 Service Unavailable' );
    header( 'Retry-After: 3600' ); // sekundy: tu godzina
    header( 'Content-Type: text/html; charset=utf-8' );
    echo '<!doctype html><html lang="pl"><head><meta charset="utf-8">'
       . '<title>Przerwa techniczna</title></head><body>'
       . '<h1>Przerwa techniczna</h1>'
       . '<p>Prowadzimy prace na stronie. Wróć za około godzinę.</p>'
       . '</body></html>';
    exit;
} );

Kod wklej w jedno z dwóch miejsc. Pierwsze to wtyczka must-use: zapisz go jako plik wp-content/mu-plugins/tryb-konserwacji.php (folder mu-plugins utwórz, jeśli go nie ma). Taka wtyczka działa od razu bez aktywacji w panelu i nie zależy od motywu, a żeby wyłączyć tryb, wystarczy usunąć plik albo zmienić mu nazwę przez FTP. Drugie miejsce to functions.php motywu potomnego, bez pierwszych linii z komentarzem „Plugin Name”; tam tryb kończy się po skasowaniu tego fragmentu.

Hook template_redirect nie obejmuje wp-admin ani wp-login.php, więc w trybie konserwacji logowanie i praca w panelu przebiegają normalnie. Warunek current_user_can( 'manage_options' ) przepuszcza administratorów; jeśli w pracach bierze udział redaktor, zamień go na is_user_logged_in(). Wartość Retry-After dopasuj do planowanej długości prac; jak ją dobrać, tłumaczy następna sekcja.

MetodaCo robiPlusyMinusyKiedy wybrać
Wtyczka trybu konserwacjiPrzełącznik w panelu, gotowa strona z komunikatem, 503 dla niezalogowanychBez kodu, edytor komunikatu, wyjątki dla ról i adresówKolejna wtyczka; Retry-After i robots.txt trzeba sprawdzić; tryb „coming soon” obok jako pułapkaWiększość stron, prace prowadzone z panelu
Własny kod (mu-plugin lub functions.php)Funkcja na template_redirect z nagłówkami 503 i Retry-AfterPełna kontrola nad nagłówkami i wyjątkami, brak zależności od wtyczkiWymaga dostępu do plików, wyłączenie ręczneMigracje, prace przez FTP lub SSH, strony bez zbędnych wtyczek
Automatyczny tryb rdzenia (.maintenance)WordPress włącza go sam na czas aktualizacjiZero konfiguracjiBrak kontroli nad treścią i czasem, kończy się samNigdy jako metoda na planowaną przerwę; warto go znać, żeby rozpoznać utknięcie po aktualizacji

Jak ustawić nagłówek Retry-After i jaką wartość podać?

Nagłówek Retry-After podaje liczbę sekund albo datę, po której klient ma spróbować ponownie; wpisz realny czas zakończenia prac z zapasem, na przykład 3600, jeśli planujesz je na godzinę. RFC 9110 (sekcja 10.2.3) dopuszcza dwa formaty:

Retry-After: 3600
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT

Pierwszy zapis to liczba sekund, drugi to data w formacie HTTP, zawsze w strefie GMT. Przy własnym kodzie wartość wpisujesz w linii header( 'Retry-After: ...' ), a we wtyczce w polu ustawień, o ile je ma. Sam rdzeń WordPressa na czas aktualizacji wysyła Retry-After: 600, czyli 10 minut.

Dla Google ta liczba jest podpowiedzią, nie rozkazem: Googlebot może przyjść wcześniej albo później, według własnego harmonogramu. Zbyt mała wartość nie szkodzi, bo robot przy każdej wizycie i tak sprawdza, czy strona wróciła do kodu 200. Dokumentacja Search Central zaleca Retry-After zawsze przy planowanej przerwie, bo odróżnia ją od przypadkowej awarii.

Jak sprawdzić, że strona naprawdę zwraca kod 503?

Wpisz w terminalu curl -I https://twojadomena.pl/ i przeczytaj pierwszą linię odpowiedzi oraz nagłówek retry-after. Poprawny wynik wygląda tak:

HTTP/2 503
retry-after: 3600
content-type: text/html; charset=utf-8

Polecenie curl nie jest zalogowane do WordPressa, więc widzi dokładnie to, co Googlebot. Przeglądarka zalogowanego administratora pokazuje zwykłą stronę, dlatego testuj w oknie incognito: kod odpowiedzi odczytasz w Chrome po naciśnięciu F12, w zakładce Network (Sieć), w kolumnie Status. Sprawdź stronę główną i co najmniej jedną podstronę, bo wyjątki we wtyczce mogą obejmować więcej adresów, niż zakładałeś.

Przy teście pamiętaj jeszcze o cache. LiteSpeed Cache, inna wtyczka buforująca albo CDN mogą po włączeniu trybu nadal podawać zapisaną wcześniej wersję strony z kodem 200, a po wyłączeniu jeszcze przez chwilę komunikat o przerwie. Cache czyść po każdej zmianie trybu, przy włączaniu i przy wyłączaniu, i dopiero potem uruchom curl -I.

Nie masz pewności, czy Twoja strona przy przerwie zwraca 503, czy 200?

Napisz do nas, sprawdzimy nagłówki odpowiedzi i podpowiemy, co zmienić.

Napisz do nas

Dlaczego plik robots.txt musi dalej odpowiadać kodem 200?

Gdy robots.txt zwraca 503, Google traktuje całą witrynę jako niedostępną i wstrzymuje crawlowanie wszystkich adresów, zamiast tylko odłożyć na później pojedyncze strony. Google opisał to zachowanie już w poradniku o planowanej przerwie na blogu Search Central i powtarza je w dokumentacji o kodach stanu HTTP: błąd serwera przy robots.txt to dla robota sygnał, że nie może bezpiecznie pobrać niczego.

W WordPressie łatwo o tę pułapkę, bo bez fizycznego pliku robots.txt w katalogu głównym system generuje jego treść w tym samym cyklu żądania, co zwykłe strony: hook template_redirect wykonuje się przed sprawdzeniem is_robots(). Kod trybu konserwacji bez wyjątku dla robotów zwróci więc 503 także dla robots.txt; dlatego fragment z poprzedniej sekcji ma linię if ( is_robots() ) return;. Fizyczny plik obsługuje serwer WWW bez udziału PHP, ale reguła ustawiona w .htaccess albo w panelu hostingu obejmie także ten plik, więc tam również trzeba dopisać wyjątek.

Wtyczki trybu konserwacji zwykle omijają robots.txt, ale nie jest to regułą: zależy od konkretnego rozwiązania i jego wersji. Sprawdź plik tym samym poleceniem, co stronę główną: curl -I https://twojadomena.pl/robots.txt ma zwrócić HTTP/2 200. Jeśli zwraca 503, przerwa dotyczy w oczach Google całej witryny, a nie tylko stron z komunikatem.

Jak długo można trzymać stronę w trybie konserwacji?

Do 1-2 dni. Google Search Central zaleca na taką przerwę kod 503 z nagłówkiem Retry-After dla wszystkich adresów. Ostrzega jednak, że kod utrzymywany dłużej niż około 2 dni prowadzi do usuwania adresów z indeksu, a przy przerwie liczonej w tygodniach nie ma gwarancji, kiedy wrócą. Więcej o tym, jak Google traktuje błędy 5xx, piszemy w osobnym wpisie.

Prace, które potrwają dłużej, prowadź poza stroną live: na kopii testowej (staging) u hostingu albo na subdomenie, a gotową wersję podmień w jednym kroku, który zajmuje minuty, nie dni. Drugie wyjście to tryb konserwacji tylko dla części adresów: wtyczki pozwalają wskazać strony, które mają działać normalnie, więc na czas przebudowy bloga sklep może przyjmować zamówienia.

Przerwę zaplanuj na godziny najmniejszego ruchu, które sprawdzisz w raporcie Google Analytics, i ustaw Retry-After na realny czas zakończenia prac. Tryb konserwacji nie zastępuje noindex ani blokady w robots.txt i nie służy do ukrywania strony na dłużej; oba te narzędzia działają inaczej, co wyjaśniamy w FAQ.

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

Usuń plik .maintenance z katalogu głównego instalacji, tego samego, w którym leży wp-config.php, przez FTP lub menedżer plików w panelu hostingu. Strona wraca natychmiast.

Komunikat „Briefly unavailable for scheduled maintenance” zostaje na stronie, gdy aktualizacja rdzenia, wtyczki lub motywu przerwała się w połowie: przez utratę połączenia, limit czasu PHP albo zamknięcie karty przeglądarki w jej trakcie. WordPress ignoruje plik .maintenance starszy niż 10 minut, więc jeśli napis utrzymuje się dłużej, winna jest raczej wtyczka trybu konserwacji, własny kod z poprzednich sekcji albo cache z zapamiętaną wersją strony.

Po usunięciu pliku wejdź w Kokpit → Aktualizacje i uruchom przerwaną aktualizację ponownie, bo część plików wtyczki mogła zostać podmieniona, a część nie. Jeśli strona zwraca potem błąd 500 zamiast komunikatu, to już inny problem, na czele z nieudaną podmianą plików wtyczki, a nie tryb konserwacji.

Strona utknęła w trybie konserwacji albo planujesz przerwę dłuższą niż 2 dni?

Napisz do nas, sprawdzimy to i podpowiemy, jak przeprowadzić prace bez utraty pozycji.

Napisz do nas

FAQ

Nie, jeśli trwa do 1-2 dni i strona zwraca 503 z nagłówkiem Retry-After. Google zachowuje wtedy zaindeksowane adresy i wraca po nie, gdy prace się skończą. Pozycjom szkodzi komunikat o przerwie z kodem 200, bo zastępuje treść podstron, oraz 503 utrzymywany dłużej niż około 2 dni.

Tak. Wtyczki domyślnie pokazują zwykłą stronę zalogowanym administratorom, a własny kod z tego wpisu robi to przez warunek current_user_can(’manage_options’). Dlatego tryb testuj w oknie incognito albo poleceniem curl -I, nigdy z przeglądarki, w której jesteś zalogowany.

Nie. Adresy wp-login.php i wp-admin działają normalnie, bo hook template_redirect ich nie obejmuje, a wtyczki trybu konserwacji też je pomijają. Blokada pojawia się dopiero wtedy, gdy przerwę ustawiono na poziomie serwera, na przykład regułą w .htaccess bez wyjątku dla panelu.

Nie. Tag noindex mówi Google, żeby usunął stronę z indeksu, a blokada w robots.txt zatrzymuje crawlowanie na tak długo, jak trwa; oba działają na stałe, nie „na chwilę”. Tymczasową niedostępność zgłasza tylko kod 503 z nagłówkiem Retry-After.

Nie jest to konieczne. Dla Google liczą się strony HTML i wyjątek dla robots.txt; pliki statyczne mogą działać normalnie i wtyczki zwykle tak je zostawiają. Mapa witryny z kodem 503 nie szkodzi przy krótkiej przerwie, bo robot wraca po nią razem z resztą adresów.

Źródła

Przewijanie do góry