500 Wewnętrzny błąd serwera

TL;DR — Błąd 500 Internal Server Error oznacza, że serwer zepsuł się podczas budowania strony — nie jest to problem z adresem URL, przeglądarką ani crawlerem wyszukiwarki. Pojedynczy 500 zwykle zostanie przez Google ponowiony i nie ma reguły mówiącej, że kosztuje to witrynę cokolwiek. Udokumentowane zagrożenie pojawia się wtedy, gdy wiele stron przez pewien czas zwraca 500 — wtedy Google spowalnia crawlowanie i ostatecznie może usunąć strony z wyników. Zacznij naprawę od logów błędów serwera, a nie od przeglądarki.

Czym jest błąd 500

500 Internal Server Error to internetowa wersja komunikatu „coś poszło nie tak, ale nie mogę dokładnie powiedzieć co”. Serwer otrzymał żądanie, zaczął budować stronę, napotkał problem i zrezygnował — zwracając ogólny błąd zamiast strony. W moim przewodniku Ahrefs o kodach stanu ująłem to tak: serwer “encounters some kind of issue and doesn’t have a better or more specific error code.” (tłumaczenie) „napotyka jakiś problem i nie ma lepszego ani bardziej szczegółowego kodu błędu”. Evidence for this claim A 500 response means the server encountered an unexpected condition that prevented it from fulfilling the request. Scope: RFC 9110 defines the generic response semantics; it does not diagnose the underlying server fault. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.1 — 500 Internal Server Error

To najważniejsza rzecz do zrozumienia: 500 jest kodem ogólnym. Mówi, że coś zepsuło się po stronie serwera. Nie mówi co. Ustalenie tego „co” jest całym zadaniem.

To zwykle problem serwera, a nie Twój

Błędy 500 należą do rodziny 5xx — błędów serwera. To coś innego niż błędy 4xx, takie jak 404 (nie znaleziono strony), które dotyczą żądania (błędnego lub brakującego adresu URL). Przy 500 adres URL może być całkowicie poprawny; serwer po prostu nie zdołał dokończyć pracy. Spotkasz też krewniaków 500 — 502, 503 i 504 — które również dotyczą serwera, ale wskazują bardziej konkretne sytuacje (błędną bramę, serwer chwilowo niedostępny lub przekroczenie czasu bramy).

Czy błąd 500 szkodzi SEO?

Pojedynczy, sporadyczny 500 na jednej stronie? Google zwykle wróci i spróbuje ponownie, a jeśli przy ponowieniu strona się załaduje, sprawa zazwyczaj na tym się kończy. Google nie publikuje ogólnej obietnicy, że odosobniona awaria jest nieszkodliwa — po prostu nie opisuje mechanizmu karzącego za jednorazową przerwę.

Rzeczywiste, udokumentowane ryzyko dotyczy utrzymujących się 500 na wielu stronach. Gdy to nastąpi:

1. Google wciąż ponawia próby, widzi, że błędy trwają, i spowalnia tempo crawlowania witryny.
2. Jeśli błędy nadal nie ustąpią, Google ostatecznie usuwa te strony z indeksu — przestają pojawiać się w wyszukiwarce. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

Dobra wiadomość: własna dokumentacja Google opisuje stopniowe odzyskiwanie po naprawieniu problemu źródłowego i ponownym powodzeniu crawlowania — ale nie gwarantuje harmonogramu ani wyniku. “Recovery is usually quick” (tłumaczenie) „Odzyskiwanie jest zwykle szybkie” opisuje częsty przypadek, a nie obietnicę.

Jak zacząć naprawę

• Najpierw sprawdź logi błędów serwera. To w nich znajduje się prawdziwy powód — nie w przeglądarce. Przeglądarka pokazuje tylko „500”; logi pokazują „dlaczego”.
• Sprawdź, co ostatnio się zmieniło. Nowa wtyczka, motyw lub moduł? Niedawne wdrożenie kodu? Edycja pliku konfiguracyjnego, takiego jak .htaccess? Ostatnie zmiany są zwykłymi podejrzanymi.
• Sprawdź Google Search Console. Raport indeksowania stron zawiera sekcję „Błąd serwera (5xx)”, która pokazuje, dla których adresów URL Google widzi 500.
• Zapytaj hosting. Szczególnie na hostingu współdzielonym wiele odpowiedzi 500 wynika z limitów pamięci lub zasobów — dostawca często może sprawdzić to po swojej stronie.

Chcesz poznać głębszą wersję — dokładnie to, jak Google eskaluje reakcję, nieoficjalną regułę około 1%, różnicę między 500 a 503 oraz pełną kolejność diagnozy? Przejdź do karty Advanced.

TL;DR — RFC 9110 definiuje 500 jako nieoczekiwany warunek, który uniemożliwił serwerowi spełnienie żądania — to cała granica samego kodu stanu; przyczyna, czas trwania i zasadność ponowienia należą do diagnozy, a nie semantyki. Udokumentowana reakcja Google jest stopniowa: odosobnione 500 są zwykle ponawiane; utrzymujące się, obejmujące całą witrynę 500 powodują wolniejsze crawlowanie i, jeśli problem nie ustąpi, ostateczne usunięcie stron z indeksu. Mueller podał przybliżoną, osobistą regułę — wskaźnik błędów powyżej około 1% prawdopodobnie oznacza, że coś jest zepsute — ale nie jest to udokumentowany próg Google, a sekwencja ponowienie → wolniejsze crawlowanie → usunięcie opisuje udokumentowane zachowania, nie stały timer. Najpierw diagnozuj na podstawie logów serwera, potem raportu “Server error (5xx)” (tłumaczenie) „Błąd serwera (5xx)” w GSC i statystyk crawlowania “by response” (tłumaczenie) „według odpowiedzi”. Różnica 500–503 ma znaczenie: 503 jest zatwierdzonym kodem “come back later” (tłumaczenie) „wróć później” z około dwudniowym okresem łagodnego ponawiania, a niekontrolowany 500 nie ma takiej ulgi. Evidence for this claim RFC 9110 defines 500 as an unexpected condition encountered by the server that prevented it from fulfilling the request. Scope: web requests Confidence: high · Verified: 2026-07-16 RFC 9110: HTTP Semantics

Czym naprawdę jest 500

Zacznij od specyfikacji, a nie od skrótu używanego przez praktyków. RFC 9110 — standard semantyki HTTP — definiuje 500 Internal Server Error jako nieoczekiwany warunek, który uniemożliwił serwerowi spełnienie żądania. To cała granica tego, co sam kod stanu mówi. Nie identyfikuje przyczyny, wadliwego komponentu, czasu trwania problemu, tego, czy to samo żądanie powiedzie się po ponowieniu, ani tego, czy odzyskanie jest prawdopodobne. Wszystko poza „serwer napotkał coś, czego nie potrafił obsłużyć” jest diagnozą, a diagnozy szuka się w logach błędów serwera, nie w specyfikacji ani przeglądarce. Evidence for this claim A 500 response means the server encountered an unexpected condition that prevented it from fulfilling the request. Scope: RFC 9110 defines the generic response semantics; it does not diagnose the underlying server fault. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.1 — 500 Internal Server Error

W przewodniku Ahrefs o kodach stanu zachowuję celowo prostą definicję dla praktyków: serwer “encounters some kind of issue and doesn’t have a better or more specific error code.” (tłumaczenie) „napotyka jakiś problem i nie ma lepszego ani bardziej szczegółowego kodu błędu”. To opisowe wyjaśnienie tej samej granicy RFC — nadal kod ogólny, nadal objaw, a nie diagnoza.

500 należy do rodziny 5xx razem z 502 (błędna brama), 503 (usługa niedostępna) i 504 (przekroczenie czasu bramy) — wszystkie dotyczą serwera, ale 500 oznacza, że “no better code applies.” (tłumaczenie) „nie ma zastosowania lepszy kod”. Ponieważ sam kod stanu nie zawiera szczegółów diagnostycznych, odświeżenie strony w przeglądarce nie mówi nic o tym, dlaczego problem wystąpił; źródłem prawdy są logi błędów serwera.

Jak Googlebot traktuje 500

Crawler Google jest z założenia uprzejmy — dostosowuje tempo do kondycji serwera, a odpowiedzi 5xx są jednym z sygnałów “slow down” (tłumaczenie) „zwolnij”. Aktualna dokumentacja Google potwierdza kształt tej reakcji: odpowiedzi 5xx i 429 powodują tymczasowe zmniejszenie szybkości crawlowania (zależne od liczby adresów URL, których dotyczą), a adresy URL, które nadal zawodzą, mogą ostatecznie zostać usunięte z indeksu; treść już zindeksowana pozostaje w międzyczasie, do czasu udanego odświeżenia. Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers John Mueller opisał tę samą sekwencję własnymi słowami podczas sesji Google SEO Office Hours, zrelacjonowanej przez Search Engine Journal:

“We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (tłumaczenie) „Google nie publikuje tu twardych progów: najpierw ponawia 500, potem może spowolnić crawlowanie, a przy dalszych błędach usunąć adresy URL z indeksu.”

Odczytaj to jako opis udokumentowanych zachowań — ponowienia, wolniejsze crawlowanie, możliwe usunięcie — a nie stały trzyetapowy timer z gwarantowanymi przejściami lub terminami; Google nie publikuje dokładnych progów, przy których jeden etap staje się kolejnym. Pojedynczy 500 pod jednym adresem URL jest zwykle ponawiany, a następne udane pobranie zazwyczaj kończy sprawę — ale to opis częstego przypadku, a nie gwarancja zerowego kosztu jednorazowej awarii. Rzeczywiste, udokumentowane ryzyko dotyczy błędów, które nie ustępują.

Dlaczego 500 w całej witrynie jest gorszy niż odosobniony

Gdy naraz 500 zwraca duża część witryny, pojawia się trudniejsza dynamika. Aktualna dokumentacja Google potwierdza, że obniżenie szybkości crawlowania skaluje się z liczbą adresów URL, których dotyczy problem — im większa część witryny zawodzi, tym bardziej crawlowanie zwalnia. Mueller opisał bardziej szczegółowo powód, ujmując go jako podejrzenie Google, że własne crawlowanie może być częścią przeciążenia:

“But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (tłumaczenie) „Gdy duża część witryny stale zwraca 500, Google może spowolnić crawlowanie całej witryny i ostatecznie usunąć strony.”

To konkretne ujęcie przyczynowe „zakładamy, że sami to powodujemy” traktuj jako charakterystykę Muellera, a nie dosłowne sformułowanie z aktualnej oficjalnej dokumentacji Google — sam mechanizm jest udokumentowany (więcej zawodzących adresów URL oznacza większe ograniczenie crawlowania), choć dokładniej można zweryfikować jego przyczynowe uzasadnienie w wypowiedzi Muellera. Tak czy inaczej warto zapamiętać praktyczną pętlę sprzężenia zwrotnego: agresywne crawlowanie przy wyczerpaniu zasobów może wywołać więcej 500 → Google wycofuje się z crawlowania całej witryny → a jeśli błędy nadal trwają, strony są usuwane. Oznacza to również, że problem 500 nie zawsze jest błędem kodu — czasem serwer ugina się pod równoległym obciążeniem, które pojawia się tylko przy skokach ruchu lub crawlowania.

Ile to „za dużo”?

Nie ma twardej granicy — własna dokumentacja Google dotycząca diagnozowania nie publikuje żadnego progu odsetka błędów. Mueller podał przybliżoną, osobistą regułę w SEO Office Hours (ponownie zrelacjonowaną przez Search Engine Journal, a nie z oficjalnej publikacji Google):

“My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (tłumaczenie) „Moje odczucie jest takie, że odsetek powyżej jednego procenta brzmi jak oznaka rzeczywistego problemu.”

Około 1% potraktuj jako nieoficjalny test zapachowy, przypisywany Muellerowi, a nie udokumentowany lub egzekwowany limit Google. Poniżej prawdopodobnie wszystko jest w porządku; powyżej warto zbadać sytuację — ale nie traktuj przekroczenia 1% jako automatycznego wyzwalacza i nie uznawaj pozostania poniżej tej wartości za gwarancję. Jedyna liczba, do której Google publicznie się zobowiązuje, to brak liczby: „nie mamy żadnych silnych progów”.

500 a 503 — różnica, która ma znaczenie

Tu wiele osób popełnia błąd. 503 Service Unavailable jest zatwierdzonym sposobem powiedzenia crawlerowi “I’m temporarily down, come back later.” (tłumaczenie) „tymczasowo nie działam, wróć później”. Google traktuje go jako zamierzony i daje okres łagodnego ponawiania. Własny dokument Google dotyczący diagnozowania crawlowania mówi wprost:

“Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (tłumaczenie) „Przy przeciążeniu zwróć tymczasowo 503 lub 429; Googlebot ponawia te adresy przez około 2 dni, a dłuższe kody niedostępności mogą trwale spowolnić lub zatrzymać crawlowanie.”

Różnica jest taka: 503 jest zamierzony i ma około dwudniowy okres ponawiania; niekontrolowany 500 jest niezamierzony i nie ma takiej ulgi — Google po prostu ponawia, aż zrezygnuje. Praktyczny wniosek: przy planowanej konserwacji lub celowej ochronie przed przeciążeniem zwracaj 503 (najlepiej z nagłówkiem Retry-After), a nie 500 ani stronę błędu z kodem 200. Nigdy nie udawaj prawdziwej awarii kodem 200.

Jak zdiagnozować 500

Przechodź przez warstwy — aplikacja/kod, platforma/CMS, infrastruktura i zasoby, a następnie konfiguracja — zaczynając od kroków najtańszych i najbardziej prawdopodobnych. Kroki oznaczone (specyficzne dla WordPressa) są częstą praktyką WordPressa, a nie uniwersalnymi naprawami; dostosuj je do rzeczywistego stosu.

1. Logi błędów serwera. error.log / access.log (albo przeglądarka logów platformy). Dopasuj znaczniki czasu do zawodnych żądań. Tu znajdziesz właściwy ślad stosu, krytyczny błąd PHP lub awarię połączenia z bazą danych. Wszystko poniżej jest zgadywaniem, dopóki ich nie odczytasz.
2. GSC — raport Błąd serwera (5xx). Raport indeksowania stron w Google Search Console oznacza adresy URL, dla których samo Google widzi 500. Następnie otwórz Statystyki crawlowania i odczytaj w czasie rozkład „według odpowiedzi” — tak odróżnisz chwilową przerwę od rzeczywistego, utrzymującego się problemu z dostępnością.
3. Bing Webmaster Tools. Alerty o błędach crawlowania grupują błędy serwera (5xx) i wskazują konkretne adresy URL oraz narzędzie Crawl Information.
4. Odtwórz problem jako bot, nie tylko w przeglądarce. Strona może zwracać 500 Googlebotowi, a Tobie ładować się poprawnie — przy obciążeniu wywołanym crawlowaniem, błędnej konfiguracji wykrywania botów/zapory lub limitach wydajności działających dopiero przy równoległym ruchu bota. Użyj URL Inspection (GSC), Fetch as Bingbot albo curl z user-agentem bota, aby wykryć awarie dotyczące tylko botów. „U mnie w przeglądarce działa” nie oznacza pełnej sprawności.
5. Konflikty wtyczek / motywów / modułów (wzorzec specyficzny dla WordPressa; dostosuj gdzie indziej). Najpierw wykonaj kopię zapasową — zawsze miej drogę powrotu, zanim zaczniesz wyłączać elementy. Następnie wyłącz rozszerzenia i włączaj je pojedynczo, aby odizolować winowajcę, sprawdzając uprawnienia i właściciela plików, których dotykasz. Przewodniki dostawców hostingu dotyczące WordPressa często opisują ten wzorzec, ale jest to obserwacja zależna od stosu, a nie dowód, że wszędzie jest to główna przyczyna — w innym CMS-ie lub aplikacji niestandardowej odpowiednikiem będzie konflikt modułu, pakietu lub oprogramowania pośredniczącego.
6. Wyczerpanie zasobów. Limity pamięci PHP, połączeń z bazą, możliwości hostingu oraz skoki ruchu lub crawlowania. Dostawca hostingu często może potwierdzić to po swojej stronie.
7. Konfiguracja i ostatnie zmiany. Uszkodzony .htaccess, błędna edycja konfiguracji serwera, świeże wdrożenie lub nieprawidłowe dane dostępowe do bazy. Ostatnie zmiany dają największą szansę na szybkie znalezienie przyczyny.

Jak to naprawić (dopasuj naprawę do przyczyny)

Dopasuj naprawę do warstwy wskazanej przez diagnozę. To typowe wzorce opisywane w różnych materiałach praktyków, a nie ranking uniwersalnych lub najbardziej prawdopodobnych przyczyn w Twoim konkretnym stosie:

• Spowodowała to konfiguracja/wdrożenie → cofnij zmianę; napraw .htaccess, konfigurację lub dane dostępowe.
• Wyczerpanie zasobów → zwiększ limity (pamięć PHP, połączenia z bazą) albo podnieś klasę hostingu; jeśli crawlowanie wywołuje przeciążenie, jest to również temat ograniczenia jego szybkości.
• Konflikt wtyczki/modułu → usuń albo zastąp problematyczne rozszerzenie.
• Błąd kodu → napraw kod i dodaj brakującą obsługę błędów.
• Nie wiesz → przekaż sprawę hostingowi wraz z dokładnymi znacznikami czasu i wierszami logów. Nie zgaduj na produkcji.

Zapobieganie nawrotom

Monitorowanie i alarmowanie o odsetku 5xx, testowanie zmian na stagingu przed wdrożeniem na produkcji, testy obciążenia przed znanymi skokami ruchu oraz — jeśli samo crawlowanie Googlebota wywołuje problem — zarządzanie obciążeniem crawlowania (i celowe zwracanie 503/429 podczas rzeczywistego przeciążenia, zamiast pozwalać serwerowi emitować niekontrolowane 500).

FAQ

Czy błąd 500 szkodzi SEO? Udokumentowane ryzyko dotyczy głównie utrzymywania się problemu na dużą skalę. Pojedyncze 500 są zwykle ponawiane, bez udokumentowanej kary za jednorazową przerwę; utrzymujące się 500 w całej witrynie spowalniają crawlowanie i mogą doprowadzić do usunięcia z indeksu.

Po jakim czasie Google usunie z indeksu stronę z 500? Nie ma stałego harmonogramu. Google najpierw ponawia próby i spowalnia crawlowanie; usunięcie z indeksu następuje dopiero, jeśli błędy trwają. Napraw problem, a strony zwykle wracają, gdy crawlowanie ponownie się powiedzie.

Dlaczego moja witryna zwraca 500 Googlebotowi, ale działa w przeglądarce? 500 dotyczące tylko botów zwykle oznacza problemy z pojemnością lub obsługą botów — obciążenie wywołane crawlowaniem, reguły zapory/botów albo limity działające dopiero przy równoległym ruchu botów. Ufaj logom, nie ręcznemu testowi w przeglądarce.

Czy 500 może spowolnić crawlowanie całej witryny, a nie tylko dotkniętych stron? Tak — dokumentacja Google potwierdza, że zmniejszenie szybkości crawlowania skaluje się z liczbą zawodzących adresów URL, więc duża część witryny zwracająca 500 spowalnia crawlowanie w całej witrynie. Mueller dodatkowo ujął przyczynę jako podejrzenie Google, że jego własne crawlowanie może być częścią przeciążenia — to jego charakterystyka, a nie dosłowne brzmienie aktualnej oficjalnej dokumentacji.

Co powoduje 500 w WordPressie? W samym WordPressie dostawcy hostingu i społeczność WordPressa najczęściej wskazują konflikty wtyczek/motywów, uszkodzony .htaccess lub osiągnięcie limitu pamięci PHP — to raporty dotyczące tej platformy, a nie twierdzenie, że są to uniwersalnie najczęstsze przyczyny każdego 500. Opisana wyżej kolejność diagnozy (najpierw logi, potem ostatnie zmiany) jest taka sama niezależnie od CMS-a.

Czy można bezpiecznie automatycznie ponowić żądanie po 500? Tylko po sprawdzeniu metody i idempotencji żądania — sam status 500 nie uprawnia do zastosowania dowolnej polityki ponowień. GET, HEAD, PUT i DELETE zwykle można bezpiecznie ponawiać, ponieważ są idempotentne (powtórzenie nie powinno powodować dodatkowych skutków ubocznych); zwykły POST zazwyczaj nie jest, chyba że API wyraźnie gwarantuje idempotencję (na przykład przez klucz idempotencji) — ślepe ponowienie grozi zduplikowanym zamówieniem, e-mailem albo podwójnie pobraną płatnością. Gdy ponawiasz próbę, użyj wykładniczego backoffu z jitterem, ogranicz liczbę prób i ustaw budżet ponowień, aby nie obciążać walczącego z problemem serwera lawiną kolejnych żądań.

Podsumowanie AI

Skrót wersji Advanced:

• 500 = granica nieoczekiwanego warunku z RFC 9110. To cały zakres samego kodu stanu — bez przyczyny źródłowej, czasu trwania i informacji o zasadności ponowienia. To objaw, nie diagnoza; przyczyny szukaj w logach serwera, a nie w przeglądarce. Różni się od błędów 4xx (klienta/żądania) oraz rodzeństwa 5xx: 502/503/504.
• Udokumentowana reakcja Google jest stopniowa: tymczasowe zmniejszenie szybkości crawlowania (zależne od liczby dotkniętych adresów URL) i możliwe ostateczne usunięcie z indeksu adresów, które stale zawodzą, z odzyskaniem po ponownym udanym pobraniu. Mueller opisuje to jako ponowienie → wolniejsze crawlowanie → usunięcie z indeksu — opis udokumentowanych zachowań, a nie stały timer. Pojedynczy 500 jest zwykle ponawiany; nie ma obietnicy, że jest bezkosztowy, ale rzeczywiste udokumentowane ryzyko dotyczy utrzymywania się błędów na dużą skalę.
• 500 w całej witrynie jest gorszy: zmniejszenie szybkości crawlowania skaluje się z liczbą błędów. Mueller ujmuje przyczynę jako podejrzenie, że własne crawlowanie Google może być częścią przeciążenia — to jego charakterystyka, nie dosłowne sformułowanie oficjalnej dokumentacji — a tak czy inaczej powstaje pętla, w której obciążenie crawlowania może wywołać więcej 500.
• Reguła orientacyjna, nie próg: Mueller powiedział, że odsetek błędów powyżej około 1% jest „prawdopodobnie oznaką awarii”, ale to jego osobiste ujęcie z SEO Office Hours, a nie udokumentowany limit Google — Google mówi, że nie ma twardych progów.
• 500 a 503: 503 (lub 429) to zatwierdzony sygnał “come back later” (tłumaczenie) „wróć później”, z około dwudniowym okresem ponawiania według dokumentacji Google; niekontrolowany 500 nie ma ulgi. Przy planowanym przestoju użyj 503 (z Retry-After).
• Kolejność diagnozy (według warstwy): logi serwera → raport GSC Błąd serwera (5xx) + statystyki crawlowania „według odpowiedzi” → Bing Webmaster Tools → odtworzenie jako bot (URL Inspection / curl) → konflikty wtyczek/modułów (wzorzec specyficzny dla WordPressa; dostosuj gdzie indziej, najpierw wykonaj kopię) → wyczerpanie zasobów → zmiany konfiguracji/wdrożenia.
• Bezpieczeństwo ponowień zależy od żądania, a nie kodu stanu. Metody idempotentne (GET/HEAD/PUT/DELETE) można zwykle bezpiecznie ponawiać; zwykły POST zazwyczaj nie, jeśli nie ma klucza idempotencji. Użyj backoffu, limitu prób i budżetu ponowień.
• Odzyskanie jest zwykle szybkie po naprawie — usunięte strony zazwyczaj wracają po udanym crawlowaniu, choć Google nie gwarantuje harmonogramu ani wyniku.

Oficjalna dokumentacja

Dokumentacja źródłowa wyszukiwarek i specyfikacji HTTP.

Google

• Diagnozowanie błędów crawlowania Google Search — sposób obsługi błędów serwera przez Google oraz zatwierdzone użycie 503/429 przy tymczasowym przeciążeniu.
• Szczegółowy przewodnik po działaniu Google Search — harmonogram crawlowania i fakt, że odpowiedzi 5xx są odczytywane jako „zwolnij”.
• Raport statystyk crawlowania — rozkład „według odpowiedzi” (w tym Błąd serwera (5xx)), pomagający odróżnić chwilową przerwę od utrzymującego się problemu.
• Zmniejszanie szybkości crawlowania Googlebota — właściwy, celowy sposób spowolnienia crawlowania, zamiast pozwalania serwerowi emitować niekontrolowane 500.

Bing / Microsoft

• Bing Webmaster Tools — lista alertów o błędach crawlowania — sposób grupowania błędów serwera (5xx) przez Bing i miejsce sprawdzania dotkniętych adresów URL.

Specyfikacja HTTP / referencja

• MDN — 500 Internal Server Error — definicja samego kodu stanu.
• RFC 9110 §15.6.1 — 500 Internal Server Error — autorytatywna semantyka HTTP.

Cytaty ze źródeł

Wypowiedzi źródłowe. Gdy strona źródłowa jest renderowana przez JavaScript albo cytat pochodzi z relacji wtórnej, zaznaczono to w elemencie <small>.

Google — ścieżka eskalacji

• “We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (tłumaczenie) „Nie mamy tu żadnych mocnych progów. Zasadniczo przy błędach 500 spróbujemy ponowić żądania. Jeśli nadal będziemy widzieć …te błędy 500, spowolnimy crawlowanie. A jeśli nadal będą występować błędy 500, usuniemy te adresy URL z indeksu.” — John Mueller, Google. Przeczytaj omówienie Przekazane za transkrypcją Search Engine Journal z nagrania Google SEO Office Hours; przed uznaniem za ostateczne potwierdź dokładne brzmienie w nagraniu źródłowym.
• “But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (tłumaczenie) „Jeśli jednak duża część witryny stale zwraca błędy 500 i możemy założyć, że to my powodujemy problem, spowolnimy crawlowanie całej witryny, a w pewnym momencie stwierdzimy: wygląda na to, że te strony naprawdę zniknęły — usuniemy je.” — John Mueller, Google. Przeczytaj omówienie Przekazane za Search Engine Journal; zweryfikuj dosłownie z oryginalnym nagraniem.
• “My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (tłumaczenie) „Moje odczucie jest takie, że jeśli widzisz coś powyżej jednego procenta, brzmi to tak, jakby coś było zepsute.” — John Mueller, Google, on a rough error-rate rule of thumb. Przeczytaj omówienie Przekazane za Search Engine Journal; zweryfikuj dosłownie z oryginalnym nagraniem.

Google — zatwierdzony sygnał „zwolnij” (dokumentacja, zweryfikowane)

• “Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (tłumaczenie) „Przy przeciążeniu zwróć tymczasowo kody statusu HTTP 503 lub 429 dla żądań Googlebota. Googlebot będzie ponawiać te adresy URL przez około 2 dni. Pamiętaj, że zwracanie kodów oznaczających brak dostępności przez więcej niż kilka dni spowoduje, że Google trwale spowolni lub zatrzyma crawlowanie adresów URL w Twojej witrynie.” — Google Search Central docs. Przejdź do cytatu

Patrick Stox — definicja (Ahrefs, zweryfikowana)

• “500 Internal Server Error – The server encounters some kind of issue and doesn’t have a better or more specific error code.” (tłumaczenie) „500 Internal Server Error — serwer napotyka jakiś problem i nie ma lepszego ani bardziej szczegółowego kodu błędu.” — my HTTP status codes guide on the Ahrefs blog. Przejdź do cytatu

Lista kontrolna triage’u błędu 500

Wykonaj od góry do dołu, gdy tylko pojawią się 500:

• Pobrano logi błędów serwera i znaleziono rzeczywisty błąd (ślad stosu / krytyczny błąd PHP / awaria bazy) — a nie tylko „500” w przeglądarce.
• Sprawdzono co ostatnio się zmieniło — nowa wtyczka/motyw/moduł, świeże wdrożenie, edycja .htaccess lub konfiguracji serwera, zmienione dane dostępowe do bazy.
• Otwarto GSC → Indeksowanie stron → Błąd serwera (5xx), aby zobaczyć, dla których adresów URL Google widzi 500.
• Odczytano w czasie statystyki crawlowania GSC „według odpowiedzi”, aby ocenić, czy problem jest chwilowy, czy utrzymujący się.
• Sprawdzono alerty o błędach crawlowania w Bing Webmaster Tools dla tych samych adresów URL.
• Odtworzono problem jako bot (URL Inspection / Fetch as Bingbot / curl z user-agentem bota), a nie tylko w przeglądarce.
• Wykluczono wyczerpanie zasobów (pamięć PHP, połączenia z bazą, możliwości hostingu) wraz z dostawcą hostingu.
• Odizolowano konflikt wtyczki/modułu, wyłączając elementy i włączając je ponownie pojedynczo.
• Potwierdzono, że podczas planowanego przestoju witryna nie emituje niekontrolowanych 500 — używa 503 (z Retry-After).
• Po naprawie odsetek błędów wrócił poniżej nieoficjalnego testu zapachowego około 1% (reguła orientacyjna Muellera, a nie udokumentowany próg Google), a GSC pokazuje ponowne udane crawlowanie.

Runbook: „Witryna zwraca 500 — co sprawdzić najpierw?”

Kolejność działań bez paniki. Wykonuj je po kolei i zatrzymaj się, gdy znajdziesz oraz naprawisz przyczynę.

0. Określ zakres (2 minuty). Czy dotyczy to jednego adresu URL, jednego szablonu/sekcji, czy całej witryny? Jeden adres URL oznacza małą stawkę (Google ponawia próby). Cała witryna to sytuacja awaryjna — właśnie ten wzorzec sprawia, że Google spowalnia crawlowanie całej witryny.

1. Odczytaj logi błędów serwera. Najpierw error.log. Dopasuj znaczniki czasu do awarii. Szukasz prawdziwej przyczyny: krytycznego błędu PHP, awarii połączenia z bazą, błędu segmentacji lub zabicia procesu z powodu braku pamięci. Wszystko poniżej jest zgadywaniem, dopóki tego nie sprawdzisz.

2. Skoreluj z „tym, co się zmieniło”. Posortuj ostatnie zmiany: ostatnie wdrożenie, dodana lub zaktualizowana wtyczka/motyw/moduł, edycja .htaccess, obrócone dane dostępowe do bazy, zmiana konfiguracji. Większość 500 wynika ze zmiany z ostatnich godzin lub dni. Jeśli możesz, najpierw cofnij zmianę, potem diagnozuj — przywrócenie usługi daje Ci czas.

3. Potwierdź widok wyszukiwarki. GSC → Indeksowanie stron → Błąd serwera (5xx) dla dotkniętych adresów URL, potem Statystyki crawlowania → według odpowiedzi, aby sprawdzić, czy problem jest chwilowy, czy utrzymujący się. Porównaj to z alertami o błędach crawlowania w Bing Webmaster Tools. To pokaże, jak pilny jest zegar SEO.

4. Odtwórz problem tak, jak widzi go bot. Jeśli ludzie widzą stronę poprawnie, ale Googlebot dostaje 500, przetestuj jako bot: URL Inspection, Fetch as Bingbot albo curl -A "Googlebot" <url>. 500 tylko dla botów wskazuje na pojemność, reguły zapory/botów lub obciążenie wywołane crawlowaniem — wymaga innej naprawy niż błąd kodu.

5. Przeprowadź bisekcję typowych podejrzanych.

• Wtyczki/moduły: wyłącz wszystkie i włączaj po jednym, aż problem pojawi się ponownie.
• Zasoby: wraz z hostingiem sprawdź limit pamięci PHP, maksymalną liczbę połączeń z bazą i możliwości hostingu — szczególnie jeśli 500 grupują się przy skokach ruchu lub crawlowania.
• Konfiguracja: przywróć .htaccess / konfigurację serwera do znanej, działającej wersji.

6. Jeśli crawlowanie jest wyzwalaczem, nie przyjmuj tego bez reakcji. Gdy własny wolumen crawlowania Googlebota przeciąża serwer, właściwą tymczasową dźwignią jest zwracanie 503/429 (z Retry-After) — a nie pozwalanie serwerowi emitować niekontrolowanych 500. Google respektuje 503 jako „wróć później” przez około 2 dni; 500 nie daje takiej ulgi.

7. Zweryfikuj odzyskanie. Odsetek błędów poniżej nieoficjalnego testu zapachowego około 1%, czyste logi i statystyki crawlowania GSC pokazujące ponownie udane pobrania. Usunięte strony zwykle wracają, gdy crawlowanie znów się powiedzie — bez gwarantowanego harmonogramu, ale zazwyczaj szybko.

Wzorzec eskalacji do zapamiętania: sporadyczny 500 → zwykle ponowiony, małe udokumentowane ryzyko → utrzymujący się 500 → wolniejsze crawlowanie → nadal utrzymujący się problem → usunięcie adresów URL z indeksu. Google nie publikuje dokładnego czasu tych przejść; Twoim zadaniem jest przerwać łańcuch, zanim zajdzie tak daleko.

Jaki kod serwera powinienem zwracać?

Skorzystaj z tego, gdy decydujesz, co serwować, albo interpretujesz to, co widzisz.

Czy awaria jest zamierzona (konserwacja / celowa ochrona przed przeciążeniem)?

• Tak → Zwróć 503 Service Unavailable z nagłówkiem Retry-After. Google traktuje go jako tymczasowy i ponawia próby przez około 2 dni. Nie serwuj strony błędu z kodem 200 i nie pozwól, aby problem przeszedł w 500.
• Nie (to prawdziwa, nieoczekiwana awaria) → przejdź dalej.

Czy błąd otrzymują wszyscy, czy tylko crawler?

• Wszyscy → To problem kodu / konfiguracji / bazy danych. Przejdź do logów błędów serwera i listy „co się zmieniło”. Cofnij ostatnie zmiany.
• Tylko Googlebot/Bingbot → Podejrzewaj pojemność, reguły wykrywania botów/zapory albo obciążenie wywołane crawlowaniem. Odtwórz problem jako bot; sprawdź zasoby serwera i reguły botów.

Czy dotyczy to jednego adresu URL, czy dużej części witryny?

• Jeden adres URL / sporadycznie → Niska pilność. Google ponawia próbę; napraw w dogodnym momencie, ale potwierdź, że problem rzeczywiście jest odosobniony.
• Cała witryna / trwale → Sytuacja awaryjna. Ten wzorzec sprawia, że Google spowalnia crawlowanie całej witryny i ostatecznie usuwa strony z indeksu. Najpierw przywróć usługę (cofnij zmianę), potem znajdź przyczynę źródłową.

Czy odsetek błędów przekracza około 1%?

• Tak → Warto to zbadać jako prawdopodobny rzeczywisty problem — to nieoficjalna reguła orientacyjna Muellera, a nie udokumentowany próg Google.
• Nie → Prawdopodobnie wszystko jest w porządku — ale monitoruj trend, nie tylko pojedynczy odczyt.

Prompt: skoreluj błąd 500 z logami i wdrożeniem

Diagnose this HTTP 500 incident from the sanitized evidence I provide. Build a
timeline across deployment events, request IDs, access logs, application errors,
resource signals, and affected URL patterns. Rank likely causes by evidence, separate
the fastest service-restoration action from the root-cause fix, and give exact
validation and rollback checks. Do not invent missing stack traces or thresholds.

[PASTE TIMELINE, HEADERS, LOGS, AND RECENT CHANGES]

Prompt: zamień ślad stosu na bezpieczny plan testów

Explain this stack trace in plain language, identify the failing component and its
inputs, and propose the smallest reversible test that distinguishes code, dependency,
configuration, and resource-exhaustion causes. Include what evidence would falsify
each hypothesis and how to confirm the URL returns a stable non-5xx response afterward.
Redact secrets and do not suggest exposing debug output publicly.

[PASTE SANITIZED STACK TRACE]

Shell: pobierz próbkę kodów 5xx dla listy adresów URL

Uruchom to z jednym bezwzględnym adresem URL w każdym wierszu pliku urls.txt.

while IFS= read -r url; do
  curl -sS -o /dev/null -w '%{http_code},%{time_total},%{url_effective}\n' "$url"
done < urls.txt

Wynik oddziela odosobnione trasy od szerokiej awarii i zapisuje opóźnienie bez pobierania ciał odpowiedzi.

PowerShell: wyeksportuj tę samą próbkę statusów

Get-Content .\urls.txt | ForEach-Object {
  $r = Invoke-WebRequest -Uri $_ -SkipHttpErrorCheck
  [PSCustomObject]@{ Status = $r.StatusCode; Url = $_ }
} | Export-Csv .\status-sample.csv -NoTypeInformation

Shell: policz statusy 5xx w logu dostępu

Przed poleganiem na wyniku dopasuj pozycję pola statusu do udokumentowanego formatu logu.

awk '$9 ~ /^5[0-9][0-9]$/ { count[$9]++ } END { for (code in count) print code, count[code] }' access.log

Narzędzia do znajdowania i diagnozowania 500

• Logi błędów serwera — error.log / access.log albo przeglądarka logów hosta/platformy. Najważniejsze narzędzie; prawdziwa przyczyna jest tutaj.
• Google Search Console — indeksowanie stron — sekcja „Błąd serwera (5xx)” wymienia adresy URL, dla których Google widzi 500.
• GSC — raport statystyk crawlowania — rozkład „według odpowiedzi” w czasie odróżnia chwilową przerwę od utrzymującego się problemu z dostępnością.
• GSC — URL Inspection — pobierz pojedynczy adres URL jako Google, aby odtworzyć 500 dotyczący tylko bota.
• Bing Webmaster Tools — alerty o błędach crawlowania grupują błędy serwera (5xx) i wskazują narzędzie Crawl Information.
• curl — odtwórz problem z dowolnym user-agentem: curl -I -A "Googlebot" <url>, aby zobaczyć kod stanu tak, jak widzi go bot.
• Crawlery / audyty witryny — Ahrefs Site Audit i Screaming Frog SEO Spider wykrywają odpowiedzi 5xx w całej witrynie i pozwalają zauważyć wzorce (awaria całego szablonu lub sekcji).
• Monitoring dostępności/statusu — alarmowanie o odsetku 5xx pozwala dowiedzieć się o skoku, zanim dowie się o nim Google.

Zasoby warte Twojego czasu

Moje powiązane teksty

• Kody stanu HTTP: przewodnik po wpływie na SEO i UX — pełna referencja kodów stanu, w tym definicja 500 i szersze omówienie crawlowania przy błędach 5xx.
• Przewodnik dla początkujących po technicznym SEO — miejsce błędów serwera w szerszym obrazie technicznego SEO.

Moje wystąpienia

• Jak działa wyszukiwarka (SlideShare) — omówienie crawlowania i sposobu, w jaki kondycja serwera wpływa zwrotnie na crawlowanie. (Obowiązuje moje stałe zastrzeżenie: “This is my understanding of systems… not going to be 100% complete or accurate.” (tłumaczenie) „To moje rozumienie systemów… nie będzie w 100% kompletne ani dokładne.)”)

Z branży

• Jak kody błędów 500 mogą negatywnie wpływać na indeksowanie (Search Engine Journal) — tekst Matta G. Southerna z cytatami Johna Muellera o ponowieniu → wolniejszym crawlowaniu → usunięciu z indeksu oraz z regułą orientacyjną około 1%.
• Jak naprawić błąd “Server error (5xx)” w Google Search Console (Search Engine Land) — instrukcja krok po kroku dotycząca raportu GSC.
• Jak naprawić “Server Error (5xx)” w Google Search Console (Onely) — czym są błędy 5xx, gdzie znaleźć je w GSC i jak je naprawiać.
• Jak naprawić błąd 500 Internal Server Error w swojej witrynie (Kinsta) — szczegółowa lista napraw skupiona na hostingu WordPressa (logi serwera, wtyczki/motywy, pamięć PHP, .htaccess, uprawnienia).
• Błędy serwera 5xx: przewodnik po znajdowaniu i naprawianiu problemów 5xx (Lumar) — perspektywa audytu korporacyjnego/technicznego, mocna w obszarze plików logów i budżetu crawlowania.
• Jak naprawić błąd serwera 5xx w Google Search Console (Sitechecker) — kolejne omówienie raportu GSC.

Filmy

• Google Search Central (YouTube) — archiwum SEO Office Hours, z którego pochodzą przytoczone wyżej wskazówki Johna Muellera dotyczące błędów serwera i crawlowania (ponowienie → wolniejsze crawlowanie → usunięcie z indeksu). Kanał

Sprawdź się: 500 Internal Server Error

Pięć krótkich pytań o to, czym jest 500 i jaki ma wpływ na SEO. Wybierz odpowiedź na każde, a następnie sprawdź wynik.

Dziennik zmian