Jeśli na czas awaryjnej aktualizacji PHP wyłączasz stronę, zwracaj kod HTTP 503, a nie timeout, 404 ani 500. Taką wskazówkę 21 października 2026 r. podał John Mueller z Google, komentując falę łatania dwóch krytycznych luk w PHP, o której napisał Search Engine Roundtable pod hasłem „PHP2Shell”. Dla SEO najważniejsze jest to, że krótka, dobrze zakomunikowana przerwa nie musi kosztować widoczności, a źle przeprowadzona potrafi.

Co się stało i skąd temat w SEO

20 i 21 października 2026 r. projekt PHP opublikował poprawki bezpieczeństwa w wersjach 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Naprawiają one dwie podatności, obie oceniane w skali CVSS v4.0 na 9,2, które według komunikatu PHP umożliwiają zdalne wykonanie kodu bez uwierzytelnienia:

  • CVE-2026-109618 – błąd związany z obsługą braku pamięci (OOM), w którym sprzątanie po żądaniu może potraktować częściowo zainicjowane dane jako poprawne,
  • CVE-2026-109619 – stan wewnętrzny żądania, który przeżywa zwolnienie pamięci i może zostać użyty przez kolejne żądanie na tym samym procesie roboczym.

Nazwa „PHP2Shell” to branżowy przydomek, pod którym temat opisał Search Engine Roundtable. Oficjalny komunikat PHP posługuje się wyłącznie numerami CVE. Zgodnie z komunikatem pełnym rozwiązaniem jest aktualizacja. Tymczasowe ustawienia (m.in. session.upload_progress.enabled=0 i limity rozmiaru żądań) tylko zawężają ścieżki ataku.

Skoro luka pozwala przejąć serwer bez logowania, część administratorów zdecydowała się wyłączyć serwisy na czas aktualizacji. I tu zaczyna się problem SEO: Googlebot nie wie, że to przerwa techniczna. Widzi tylko odpowiedź serwera.

Co dokładnie powiedział Google

John Mueller napisał 21 października na Bluesky:

If you’re taking PHP sites down to schedule time to deal with “unplanned updates”, use HTTP 503 instead of letting responses time out / 404 / 500. You can do this outside of PHP / point DNS elsewhere / CDN.

Innymi słowy: jeśli wyłączasz strony PHP, żeby zyskać czas na „niezaplanowane aktualizacje”, zwracaj HTTP 503, zamiast dopuszczać do timeoutów, błędów 404 czy 500. Kod 503 można przy tym serwować poza PHP, na przykład przekierowując DNS w inne miejsce albo korzystając z CDN-a. Pod wpisem Mueller podlinkował dwa materiały Google: wpis o planowanym przestoju strony i dokumentację o tymczasowym wstrzymaniu działania serwisu. Search Engine Roundtable przypomina, że podobną poradę Google dawał przy okazji podatności Log4j w 2021 r.

Dlaczego 503, a nie 404, 500 lub timeout

Każda ze złych odpowiedzi mówi robotowi coś innego, niż chcesz powiedzieć:

OdpowiedźCo interpretuje GoogleRyzyko
503Chwilowa niedostępność, warto wrócić późniejNajmniejsze, to właściwy sygnał
404 / 410Strona przestała istniećWypadanie z indeksu przy kolejnych odwiedzinach
500Błąd serwera, niejasny charakterStan niepewny, dłuższa seria błędów obniża zaufanie do hosta
TimeoutSerwer nie odpowiadaPodobnie jak 500, do tego marnujesz budżet indeksowania

Dokumentacja Google o tymczasowym wstrzymaniu strony wymienia 403, 404 i 410 wśród odpowiedzi, które mogą usunąć serwis z wyników. To wniosek, z którym zgadza się praktyka: nie chcesz, żeby przerwa na patch wyglądała dla robota jak decyzja o usunięciu treści.

Jak zrobić to dobrze

1. Serwuj 503 poza PHP

To sedno wskazówki Muellera. Jeśli problemem jest sam PHP, nie możesz polegać na tym, że wygeneruje on poprawną stronę błędu. Rozsądne warianty:

  • statyczna strona z konfiguracji serwera WWW (Nginx, Apache) zwracana z kodem 503,
  • reguła na CDN-ie lub w zaporze, która odpowiada 503 zanim żądanie dotrze do origin,
  • przekierowanie DNS na prosty statyczny host, który wszystkim zwraca 503.

Przy ostatnim wariancie pamiętaj o czasie propagacji DNS i o tym, że po powrocie zmiana też nie jest natychmiastowa.

2. Sprawdź, co faktycznie zwraca serwer

Dokumentacja Google zaleca weryfikację statusu narzędziem takim jak curl -I. Test dotyczy każdego adresu, także strony głównej, podstron i plików statycznych.

3. Dodaj nagłówek Retry-After

Google opisuje go jako wskazówkę „best effort” z przybliżoną datą lub czasem trwania. Nie gwarantuje on określonego zachowania robota, ale pomaga.

4. Nie blokuj robots.txt

Tu łatwo o błąd, który robi więcej szkody niż sama przerwa. Według wytycznych Google plik robots.txt musi pozostać dostępny: jeśli zwróci 503, zablokuje to całe indeksowanie. Nie należy też podmieniać go na wersję z Disallow: /. Jeśli chcesz odświeżyć wiedzę o tym pliku, zajrzyj do artykułu robots.txt – jak działa i jak go poprawnie skonfigurować.

5. Zadbaj o lekką stronę błędu

Wytyczne Google radzą, by strona 503 była prosta: statyczny HTML, style inline, minimum zewnętrznych zasobów. Dla ludzi dodaj informację, kiedy serwis wróci, i kontakt.

Jak długo można być offline

Tu trzeba uczciwie powiedzieć, czego nie wiadomo. Dokumentacja Google traktuje całkowite wyłączenie serwisu jako rozwiązanie niezalecane i mówi o nim w kontekście „najwyżej kilku dni”. Dla okresu 1–2 dni zaleca stronę informacyjną z kodem 503, a dla dłuższego – indeksowalną stronę główną z kodem 200 jako zastępnik. Nie podaje jednak progu, po którym 503 prowadzi do usunięcia z indeksu, ani nie opisuje precyzyjnie, jak traktuje Retry-After.

Wśród skutków ubocznych dokumentacja wymienia możliwą utratę informacji w panelach wiedzy (np. numeru telefonu czy logo), niepowodzenie weryfikacji w Search Console i trudne do przyspieszenia odbudowywanie widoczności po dłuższej przerwie. Dopóki strony zwracają 503, Google nie odświeży też tytułów, opisów ani danych strukturalnych.

Patch PHP zwykle trwa minuty lub godziny, nie dni, więc w większości przypadków jesteśmy w bezpiecznym obszarze. Ryzyko pojawia się, gdy „krótka przerwa” rozciąga się przez problemy z migracją, kompatybilnością wtyczek lub odtwarzaniem po incydencie.

Czy w ogóle wyłączać stronę

Nie ma jednej odpowiedzi i trzeba ją oprzeć na ryzyku. Przy luce umożliwiającej zdalne wykonanie kodu bez logowania zwłoka ma realny koszt: przejęty serwer oznacza malware, spam w indeksie i ostrzeżenia przeglądarki, a to uderza w widoczność mocniej niż godzina 503. Komunikat PHP wskazuje przy tym wyraźnie, że najbardziej narażone są konfiguracje z mod_php.

Z mojej praktyki audytowej wynika, że w SEO nie psuje przerwa sama w sobie, tylko jej nieprzemyślana realizacja: strona główna z kodem 200 i komunikatem „trwają prace”, przekierowanie wszystkiego na jeden adres, blokada w robots.txt albo noindex wrzucony „na chwilę” i zapomniany. To są właśnie błędy, które Google wymienia jako powód wypadania z wyników.

Jeśli możesz zaktualizować PHP bez wyłączania serwisu (rolling update, przełączenie ruchu na zaktualizowany serwer), to jest to rozwiązanie lepsze od jakiegokolwiek 503. Powiązane tematy znajdziesz w artykułach o zabezpieczaniu WordPressa i kopiach zapasowych WordPressa; przed każdą aktualizacją sprawdź, czy backup działa.

Lista kontrolna na czas awaryjnej przerwy

  1. Ustal, czy da się zaktualizować bez przestoju. Jeśli nie, zaplanuj okno i ogranicz je do minimum.
  2. Przygotuj odpowiedź 503 niezależną od PHP (serwer WWW, CDN albo osobny host).
  3. Dodaj nagłówek Retry-After.
  4. Upewnij się, że robots.txt zwraca 200 i nie blokuje indeksowania.
  5. Sprawdź curl -I dla strony głównej i kilku podstron.
  6. Nie używaj noindex, 404 ani 410 jako „tymczasowego” rozwiązania.
  7. Po aktualizacji zdejmij 503, sprawdź kody odpowiedzi i raport indeksowania w Search Console.
  8. Jeśli to możliwe, sprawdź, czy po przywróceniu nie zostały stare reguły przekierowań.

Podsumowanie

Google nie ma nic przeciwko krótkiej przerwie technicznej, jeśli jasno ją zakomunikujesz: kodem 503, najlepiej serwowanym spoza PHP, z dostępnym robots.txt i bez dodatkowych sygnałów usuwających stronę z indeksu. Nie wiadomo, jak długo dokładnie Google toleruje 503, więc traktuj każdą przerwę jako sprawę godzin, nie tygodni. Samej łatki nie warto odkładać ze względu na SEO: przejęta strona kosztuje znacznie więcej niż chwilowy 503.

Często zadawane pytania

Jaki kod odpowiedzi zwracać, gdy wyłączam stronę na czas aktualizacji PHP?

HTTP 503 (Service Unavailable). Według wskazówki Johna Muellera lepiej zwracać 503 niż dopuszczać do timeoutów, błędów 404 czy 500. Dodaj nagłówek Retry-After i sprawdź odpowiedź narzędziem curl.

Czy 503 można serwować bez PHP?

Tak, i tak właśnie warto. Mueller wskazał, że 503 można zwracać poza PHP, np. przekierowując DNS w inne miejsce albo wykorzystując CDN. Alternatywą jest statyczna strona błędu w konfiguracji Nginx lub Apache.

Jak długo strona może zwracać 503 bez szkody dla pozycji?

Google nie podaje dokładnego progu. Dokumentacja traktuje całkowite wyłączenie jako rozwiązanie na „najwyżej kilka dni”, a dla 1–2 dni zaleca stronę informacyjną z kodem 503. Im dłuższa przerwa, tym trudniejszy i mniej przewidywalny powrót do wcześniejszej widoczności.

Czy podczas przerwy zablokować roboty w robots.txt?

Nie. Plik robots.txt powinien pozostać dostępny i nie może zwracać 503, bo to wstrzymuje całe indeksowanie. Nie wolno też wgrywać wersji z Disallow: /. Więcej w artykule o robots.txt.

Czy łatać PHP od razu, nawet jeśli oznacza to przerwę w działaniu strony?

Przy lukach pozwalających na zdalne wykonanie kodu bez logowania ryzyko przejęcia serwera zwykle przewyższa koszt krótkiego 503. Najlepiej zaktualizować bez przestoju; jeśli się nie da, zaplanuj przerwę tak, by trwała godziny, nie dni.

Źródła

  1. Search Engine Roundtable: Google on taking sites offline while patching PHP2Shell https://www.seroundtable.com/google-php2shell-42353.html
  2. John Mueller, wpis na Bluesky https://bsky.app/profile/johnmu.com/post/3myfhjovzvk27
  3. PHP.net – archiwum wiadomości 2026 (advisory z 21.10.2026) https://www.php.net/archive/2026.php#2026-10-21-5
  4. Google Search Central – Temporarily pause or disable a website https://developers.google.com/search/docs/crawling-indexing/pause-online-business
  5. Google Search Central Blog – How to deal with planned site downtime (2011) https://developers.google.com/search/blog/2011/01/how-to-deal-with-planned-site-downtime