Błąd 503 (Service Unavailable) oznacza, że serwer tymczasowo nie może obsłużyć żądania – jest przeciążony, w trakcie konserwacji lub jego zasoby zostały wyczerpane. W odróżnieniu od błędu bazy danych czy 404 (strona nie istnieje), 503 mówi: „strona istnieje, serwer działa, ale w tej chwili nie jest w stanie odpowiedzieć ��� spróbuj za chwilę”.
Co dokładnie oznacza HTTP 503
Kod statusu 503 Service Unavailable należy do rodziny 5xx (błędy serwera) – oznacza problem po stronie serwera, nie użytkownika. Serwer rozumie żądanie, ale nie może go teraz obsłużyć. Typowo: serwer jest tymczasowo niedostępny z powodu: przeciążenia (zbyt dużo jednoczesnych żądań), planowanej konserwacji (maintenance), awarii backendu (PHP, baza danych, usługa zewnętrzna) lub wyczerpania zasobów (RAM, CPU, połączenia).
Kluczowe słowo: tymczasowo. 503 to nie trwała awaria – serwer mówi „jestem zajęty, wróć później”. Dlatego przeglądarki i boty (w tym Googlebot) wiedzą, że powinny spróbować ponownie za jakiś czas.
Najczęstsze przyczyny błędu 503
1. Serwer jest przeciążony (zbyt dużo ruchu)
Hosting współdzielony ma ograniczone zasoby (CPU, RAM, PHP workers). Jeśli Twoja strona nagle dostanie spike ruchu (viralowy post, kampania reklamowa, atak DDoS), serwer nie nadąża z obsługą żądań → 503 dla nadmiarowych (serwuje kto może, resztę odrzuca z 503).
Rozwiązanie: włącz page cache (LiteSpeed Cache, WP Rocket) – cache serwuje gotowy HTML bez odpalania PHP, co zmniejsza obciążenie serwera 10–100x. Jeśli cache nie pomaga: upgrade hostingu (VPS z gwarantowanymi zasobami zamiast shared). Lub: Cloudflare z APO – cache na edge, serwer prawie nie jest obciążany.
2. Planowana konserwacja (Maintenance Mode)
Serwer (lub aplikacja) jest celowo wyłączony na czas aktualizacji, migracji lub konserwacji. WordPress wyświetla 503 gdy jest w trybie maintenance (plik .maintenance w katalogu głównym). Hosting może wyświetlać 503 podczas migracji serwera, aktualizacji oprogramowania lub operacji na bazie danych.
Rozwiązanie: jeśli to planowane – czekaj. Jeśli WordPress utknął w maintenance mode – usuń plik .maintenance przez FTP.
3. PHP-FPM workers wyczerpane
Serwer PHP ma ograniczoną liczbę PHP workers (procesów obsługujących żądania PHP). Jeśli wszystkie workers są zajęte (wolne zapytania do bazy, ciężkie wtyczki, brak cache) – nowe żądania czekają w kolejce, a po timeout → 503.
Rozwiązanie: (1) włącz cache (mniej żądań = mniej workers potrzebnych), (2) obniż TTFB (szybsze żądania = workers zwalniają się szybciej), (3) zwiększ liczbę PHP workers (w panelu hostingu lub php-fpm.conf na VPS: pm.max_children), (4) Redis Object Cache (mniej zapytań do MySQL = szybsze PHP).
4. Baza danych MySQL nie odpowiada
Jeśli MySQL jest przeciążony (za dużo połączeń, wolne zapytania, baza zablokowana) – WordPress nie może pobrać danych → PHP czeka → timeout → 503 (lub Error establishing a database connection). Różnica: 503 = serwer web zwraca błąd, EDBC = WordPress sam wyświetla komunikat.
Rozwiązanie: sprawdź obciążenie MySQL (hosting panel → baza → statystyki), zoptymalizuj bazę (WP-Optimize, usuń rewizje/transienty), włącz Redis (mniej zapytań do MySQL).
5. Reverse proxy / load balancer nie dociera do backendu
Jeśli przed Twoim serwerem stoi reverse proxy (Cloudflare, Nginx jako proxy, load balancer): proxy łączy się z backendem (Apache/PHP), ale backend nie odpowiada → proxy zwraca 503 do użytkownika. Przyczyna: backend padł, jest w maintenance, albo połączenie proxy → backend ma timeout.
Rozwiązanie: sprawdź logi backendu (/var/log/apache2/error.log, /var/log/nginx/error.log). Jeśli Cloudflare → sprawdź status serwera w panelu hostingu (czy w ogóle żyje). Jeśli problem trwa: skontaktuj się z hostingiem.
6. Atak DDoS
Atak DDoS na warstwie 7 (HTTP flood) generuje tysiące żądań → serwer jest przeciążony → 503 dla normalnych użytkowników. WAF i Cloudflare absorbują takie ataki – jeśli nie masz ochrony, DDoS może Cię położyć na godziny.
Rozwiązanie: Cloudflare (darmowy – DDoS protection unlimited) + Under Attack Mode (wł��cz na czas ataku). Jeśli atak trwa: skontaktuj się z hostingiem – mogą filtrować ruch na poziomie sieci.
7. Wtyczka lub motyw WordPress powoduje crash PHP
Aktualizacja wtyczki → konflikt → PHP fatal error → serwer zwraca 503 (bo PHP nie generuje odpowiedzi). WordPress od 5.2 ma Recovery Mode (wyłącza problematyczną wtyczkę) – ale nie zawsze łapie wszystko.
Rozwiązanie: FTP → zmień nazwę wp-content/plugins na plugins-off → odśwież stronę. Jeśli działa: winowajca to wtyczka. Przywróć folder i wyłączaj wtyczki po jednej.
Jak sprawdzić przyczynę 503
Logi serwera to jedyne wiarygodne źródło informacji o przyczynie. Gdzie szukać:
| Hosting / serwer | Gdzie logi |
|---|---|
| cPanel | Metrics → Errors → error_log |
| DirectAdmin | System Info → Error Logs |
| Plesk | Domains → [domena] → Logs |
| VPS (Apache) | /var/log/apache2/error.log |
| VPS (Nginx) | /var/log/nginx/error.log |
| VPS (PHP-FPM) | /var/log/php-fpm/error.log |
| WordPress | wp-content/debug.log (jeśli WP_DEBUG włączone) |
| Cloudflare | Dashboard → Analytics → Errors |
Szukaj wpisów z czasem wystąpienia 503 – logi pokażą: „max_children reached” (wyczerpane PHP workers), „upstream timed out” (backend nie odpowiada), „Out of memory” (brak RAM), „Too many connections” (MySQL limit).
Nagłówek Retry-After – kiedy serwer wróci
Odpowiedź 503 może zawierać nagłówek Retry-After: Retry-After: 300 (spróbuj za 300 sekund) lub Retry-After: Wed, 21 Apr 2026 14:00:00 GMT (spróbuj po tej dacie). Googlebot czyta ten nagłówek – wie, kiedy wrócić. Jeśli Twój serwer zwraca 503 z Retry-After → Google nie interpretuje tego jako „strona nie istnieje”, tylko „spróbuję później”.
Jeśli robisz planowaną konserwację: ustaw 503 z Retry-After (nie 200 z komunikatem „strona w budowie” – bo Google zindeksuje stronę w budowie). 503 + Retry-After = prawidłowy sygnał „wrócę”.
Błąd 503 a SEO – wpływ na pozycje
Krótkotrwały 503 (minuty–godziny): zero wpływu na SEO. Googlebot spróbuje ponownie i zaindeksuje normalnie. Google jawnie mówi: „503 to tymczasowy błąd, nie deindeksujemy stron z tego powodu”.
Długotrwały 503 (dni): Google zacznie traktować stronę jako niedostępną – może tymczasowo usunąć z indeksu. Powrót do indeksu po naprawie: godziny–dni. Długotrwały 503 jest lepszy niż długotrwały 404 – bo 503 mówi „wrócę”, a 404 mówi „nie istnieje”.
503 podczas planowanej konserwacji: poprawny HTTP – nie szkodzi SEO, o ile konserwacja trwa godziny, nie dni. Z nagłówkiem Retry-After: jeszcze lepiej.
503 vs inne kody błędów – porównanie
| Kod | Nazwa | Znaczenie | Przyczyna |
|---|---|---|---|
| 500 | Internal Server Error | Ogólny błąd serwera (coś poszło źle, ale nie wiadomo co) | Crash PHP, .htaccess error, brak pamięci |
| 502 | Bad Gateway | Proxy/load balancer nie dostał poprawnej odpowiedzi od backendu | Backend padł, timeout |
| 503 | Service Unavailable | Serwer tymczasowo nie obsługuje żądań | Przeci��żenie, maintenance, wyczerpane zasoby |
| 504 | Gateway Timeout | Proxy czekał zbyt długo na odpowiedź backendu | Wolne zapytanie PHP/MySQL, timeout konfiguracja |
Najczęściej zadawane pytania
Czy 503 to problem z moją stroną czy z hostingiem?
Zwykle jedno i drugie. Jeśli Twoja strona jest jedyną na serwerze (VPS): problem jest u Ciebie (za dużo ruchu, ciężkie wtyczki, brak cache). Jeśli hosting współdzielony: może być problem sąsiada (inny klient na tym samym serwerze obciąża zasoby) – skontaktuj się z supportem hostingu.
Jak naprawić 503 jeśli nie mam dostępu do serwera?
Na hostingu współdzielonym: czekaj 5–15 minut (serwer się odciąży) → jeśli nie mija, skontaktuj się z supportem hostingu (czat, telefon). Powiedz: „moja strona zwraca 503, proszę o sprawdzenie logów serwera”. Hosting zobaczy: czy problem to Twoja strona (wtyczki, ruch), czy ich serwer (awaria, przeciążenie).
Czy powinienem się martwić o jednorazowy 503?
Nie – pojedynczy 503 (np. podczas aktualizacji wtyczki WP, chwilowy spike ruchu) to normalność. Martwić się należy gdy: 503 wraca regularnie (codziennie w godzinach szczytu → za mały hosting), 503 trwa godzinami (problem strukturalny → analiza logów + potencjalny upgrade).
Jak uniknąć 503 w przyszłości?
Checklista zapobiegawcza: (1) page cache ON (mniej PHP = mniej obciążenia), (2) Redis Object Cache (mniej MySQL = szybsze PHP), (3) Cloudflare CDN (odciąża serwer), (4) zoptymalizowane obrazki (mniej transferu), (5) mniej wtyczek (mniej PHP per żądanie), (6) monitoring uptime (UptimeRobot – darmowy, alert SMS gdy strona padnie).
