Strona WordPress nie działa — jak w 10 minut ustalić przyczynę

Strona „nie działa” to w praktyce kilkanaście różnych awarii, które z zewnątrz wyglądają podobnie. Czasem winna jest wygasła domena, czasem hosting, który zawiesił konto, czasem jedna wtyczka po nocnej aktualizacji. Każdą naprawia się inaczej i często ktoś inny: Ty, hosting, rejestrator domeny albo administrator strony.

Diagnozujemy w stałej kolejności: najpierw ustalamy, czy problem jest tylko po stronie odwiedzającego, potem czytamy dokładny komunikat, a dopiero na końcu zaglądamy do plików WordPressa. Ten poradnik przeprowadzi Cię tą samą drogą. Komendy i komunikaty sprawdziliśmy na WordPressie 7.1.3 w polskiej wersji językowej, z WP-CLI 2.12.

Ścieżki w tekście są oznaczone: Bez dostępów to kroki dla każdego, Panel / FTP wymaga logowania do hostingu, SSH to polecenia dla osoby technicznej. Jeśli nie masz czasu na diagnozę, zgłoś awarię przez formularz. W godzinach dyżuru (pn–pt 8–20, sob 10–16) odezwiemy się w godzinę.

Czy strona nie działa tylko u Ciebie

Zacznij od tego, bo czasem można tu zakończyć poszukiwania. Jeśli nie działa jedna strona internetowa, a reszta internetu tak, problem zwykle leży po stronie tej witryny. Zdarza się jednak, że winna jest Twoja sieć: router z zapamiętanym starym adresem serwera, filtr treści w sieci firmowej, VPN, antywirus z funkcją ochrony przeglądania albo blokada Twojego adresu IP.

Bez dostępów: test w 2 minuty

1. Telefon bez Wi-Fi. Wyłącz Wi-Fi i otwórz stronę przez internet komórkowy. To inna sieć i inne serwery DNS niż w biurze.
2. Okno incognito. Na komputerze otwórz stronę w trybie prywatnym, z wyłączonym VPN. Jeśli tam działa, winna jest pamięć przeglądarki albo ciasteczka. Wyczyść je dla tej domeny.
3. Test z wielu krajów. Wpisz adres w narzędziu sprawdzającym dostępność z wielu lokalizacji (np. check-host.net, zakładka HTTP). Zobaczysz kod odpowiedzi z kilkunastu serwerów na świecie.
4. Zapisz wynik. Godzina, adres, komunikat, sieć, z której testowałeś. Przyda się przy zgłoszeniu do hostingu.

Jeśli strona działa wszędzie poza Twoim biurem, uruchom ponownie router i wyczyść pamięć DNS komputera (Windows: ipconfig /flushdns w wierszu poleceń). Jeśli z biura nie działa ani strona, ani poczta, ani FTP, a z telefonu wszystko jest w porządku, najpewniej zapora serwera zablokowała adres IP biura. Na hostingach z panelem DirectAdmin lub cPanel dzieje się tak po kilku błędnych logowaniach do poczty lub FTP, np. gdy program pocztowy na jednym komputerze ma stare hasło. Podaj hostingowi swój publiczny adres IP, poproś o zdjęcie blokady, a potem popraw hasło w programie pocztowym. Podobnie blokuje wtyczka bezpieczeństwa WordPressa, ale wtedy zwykle tylko stronę.

SSH lub terminal: test w 30 sekund

Polecenia działają w terminalu na macOS i Linuksie. W systemie Windows 10 i 11 nslookup i curl są wbudowane (w PowerShellu wpisz curl.exe, bo samo curl to tam alias innego polecenia), a openssl i grep znajdziesz np. w Git Bash.

# 1. Jaki kod HTTP zwraca serwer i dokąd przekierowuje
curl -sIL --max-redirs 10 https://twojadomena.pl | grep -iE "^(HTTP|location)"

# 2. Na jakie adresy IPv4 i IPv6 wskazuje domena (pytamy publiczny DNS, nie router)
nslookup -type=A twojadomena.pl 1.1.1.1
nslookup -type=AAAA twojadomena.pl 1.1.1.1

# 3. Czy serwer działa, gdy pominiesz DNS i CDN (IP podaje hosting w panelu)
curl -skI --resolve twojadomena.pl:443:203.0.113.10 https://twojadomena.pl

# 4. Do kiedy ważny jest certyfikat SSL
echo | openssl s_client -connect twojadomena.pl:443 -servername twojadomena.pl 2>/dev/null | openssl x509 -noout -enddate

Test nr 3 rozstrzyga najczęstszy spór „to DNS czy serwer?”. Jeśli z wymuszonym adresem IP serwer odpowiada kodem 200 albo przekierowaniem 301 lub 302 (np. na wersję z www), serwer działa, a problem leży w domenie, rekordach DNS lub CDN. Jeśli i tak dostajesz błąd 5xx albo brak odpowiedzi, szukaj na serwerze. Przełącznik -k pomija sprawdzanie certyfikatu, bo za Cloudflare serwer często ma certyfikat, którego curl nie uzna.

Dlaczego strona nie działa: diagnoza według objawu

Odpowiedz na pytania po kolei. Każda gałąź kończy się wskazaniem warstwy i linkiem do sekcji z dalszymi krokami.

Drzewko diagnozy: odpowiadaj na pytania po kolei

1. Przeglądarka w ogóle nie łączy się z serwerem? („Ta witryna jest nieosiągalna”, DNS_PROBE_FINISHED_NXDOMAIN, ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_REFUSED)
   • Tak, błąd DNS albo „nie można znaleźć adresu IP” → domena wygasła lub zmieniono rekordy DNS. Sprawdź domenę i DNS.
   • Tak, przekroczony czas lub odmowa połączenia → serwer nie odpowiada albo blokuje Twój adres. Co oznacza „witryna nieosiągalna”.
   • Nie, coś się wyświetla → pytanie 2.
2. Przeglądarka ostrzega o bezpieczeństwie? („Połączenie nie jest prywatne”, NET::ERR_CERT_DATE_INVALID, czerwony ekran o niebezpiecznej witrynie)
   • Ostrzeżenie o certyfikacie → wygasły lub błędny SSL. Certyfikat SSL.
   • Czerwony ekran o oszustwie lub złośliwym oprogramowaniu → Google wykrył infekcję. Postępuj jak przy włamaniu.
   • Nie → pytanie 3.
3. Widzisz kod błędu HTTP?
   • 500, 502, 504, 520–524 od Cloudflare → błąd PHP, przeciążenie lub zbyt długie zadanie.
   • 503 albo napis o pracach konserwacyjnych → tryb konserwacji lub limit zasobów.
   • 403 → uprawnienia, zapora albo zawieszone konto. Sprawdź konto hostingu.
   • 404 na podstronach, a strona główna działa → bezpośrednie odnośniki i .htaccess.
   • Nie → pytanie 4.
4. Widzisz komunikat WordPressa?
   • „W witrynie wystąpił błąd krytyczny”, „Na stronie wystąpił błąd krytyczny” albo pusta biała strona → wtyczka, motyw lub PHP.
   • „Błąd łączenia się z bazą danych” → baza danych.
   • „Ta strona przekierowała Cię zbyt wiele razy” → pętla przekierowań.
   • Nie → pytanie 5.
5. Strona się otwiera, ale coś jest nie tak?
   • Przenosi na obcą stronę (często tylko na telefonie albo tylko z Google) → możliwe włamanie.
   • Wyświetla się bez stylów, rozsypana → mieszana treść HTTP/HTTPS lub pamięć podręczna.
   • Zamiast strony widać stronę powitalną hostingu albo listę plików „Index of /” → domena wskazuje na zły katalog lub serwer.
   • Nie da się zalogować do panelu → logowanie, blokada lub ciasteczka.
   • Działa, ale bardzo wolno albo co jakiś czas pada → wydajność i limity hostingu.
   • Była niedostępna, a teraz działa → ustal przyczynę po fakcie.

Biały ekran lub „W witrynie wystąpił błąd krytyczny”

To najczęstszy objaw awarii samego WordPressa. Od wersji 5.2 WordPress przechwytuje błąd PHP, zamiast pokazywać pustą stronę, i wysyła na adres administratora e-mail z tematem „[Nazwa witryny] Twoja witryna ma problemy techniczne”. W środku jest nazwa wtyczki lub motywu, który wywołał błąd, i link do trybu odzyskiwania. Odwiedzający bez uprawnień widzą inną wersję komunikatu: „Na stronie wystąpił błąd krytyczny. Skontaktuj się z administratorem witryny…”. Jeśli klient przysłał Ci taki zrzut, chodzi o ten sam problem.

Czysty biały ekran bez żadnego tekstu ma trzy źródła: błąd PHP wystąpił, zanim zadziałał mechanizm przechwytywania; poprzedni administrator wyłączył ten mechanizm stałą WP_DISABLE_FATAL_ERROR_HANDLER; albo błędu w ogóle nie ma, bo szablon się nie załadował. Ten trzeci przypadek zdarzył się 10 marca 2026 r.: po wydaniu bezpieczeństwa 6.9.2 część stron pokazywała pustą stronę publiczną, bo nowe zabezpieczenie odrzucało szablony podawane przez niektóre motywy w niestandardowy sposób. Panel działał, a w logu nie było błędu. Poprawka 6.9.3 wyszła tego samego dnia (komunikat WordPress.org o wydaniu 6.9.3).

Pełną procedurę, z trybem odzyskiwania i tabelą komunikatów z logu, opisaliśmy w poradniku błąd krytyczny w witrynie WordPress — jak go naprawić krok po kroku. Skrót znajdziesz niżej, w drabinie diagnozy.

Kto naprawia: administrator strony (Ty lub wykonawca). Hosting pomoże najwyżej z logami.

„Błąd łączenia się z bazą danych”

Po polsku WordPress pokazuje „Błąd łączenia się z bazą danych”, po angielsku „Error establishing a database connection”. Strona nie może połączyć się z MySQL lub MariaDB. Typowe przyczyny: serwer bazy danych chwilowo leży lub jest przeciążony, ktoś zmienił hasło użytkownika bazy, a nie zaktualizował wp-config.php, po przeniesieniu strony w pliku zostały stare dane dostępowe, tabela uszkodziła się albo skończyło się miejsce na koncie. Jeśli błąd pojawia się i znika przy większym ruchu, często chodzi o limit jednoczesnych połączeń do bazy na koncie (max_user_connections).

Panel / FTP: porównaj cztery wartości z wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST) z tym, co widzisz w panelu hostingu w sekcji baz danych. Jeśli się zgadzają, a błąd trwa, napisz do hostingu, bo zwykle to po ich stronie. Uszkodzone tabele naprawisz poleceniem wp db repair albo wbudowaną stroną naprawy, którą włącza linia define( 'WP_ALLOW_REPAIR', true ); w wp-config.php. Strona /wp-admin/maint/repair.php działa wtedy bez logowania, więc usuń tę linię zaraz po naprawie. Kto naprawia: najczęściej hosting, po migracji osoba, która przenosiła stronę.

Błąd 500, 502 lub 504

W Chrome zobaczysz „Ta strona nie działa” i niżej „HTTP ERROR 500”. Kod 500 to ogólny błąd serwera: najczęściej błąd PHP we wtyczce lub motywie, uszkodzony plik .htaccess, przekroczony limit pamięci PHP albo plik pozostały po usuniętej wtyczce (opisujemy to w drabinie, krok 4). Diagnozujesz go tak samo jak błąd krytyczny, zaczynając od logu błędów.

Kody 502 (Bad Gateway) i 504 (Gateway Timeout) mówią coś innego: serwer pośredniczący, np. nginx przed PHP albo Cloudflare przed hostingiem, nie dostał odpowiedzi na czas. Pojedyncze 504 przy imporcie produktów to zbyt długie zadanie. Seria 502 lub 504 na zwykłych podstronach to przeciążony serwer, zawieszone procesy PHP albo atak botów. Kto naprawia: przy 500 administrator strony, przy 502 i 504 najpierw hosting.

Błąd 503 lub „zaplanowane prace konserwacyjne”

Komunikat „Witryna jest tymczasowo niedostępna z powodu zaplanowanych prac konserwacyjnych. Zapraszamy ponownie za minutę.” pokazuje WordPress podczas aktualizacji. Tworzy wtedy w katalogu głównym plik .maintenance i usuwa go po zakończeniu.

WordPress sam ignoruje plik .maintenance starszy niż 10 minut (sprawdziliśmy w wp-includes/load.php wersji 7.1). Jeśli komunikat wisi godzinę, usuń plik przez FTP lub menedżer plików, ale szukaj też innej przyczyny: wtyczki trybu „wkrótce” lub „konserwacja”, pamięci podręcznej serwera, która wciąż serwuje zapisaną stronę z komunikatem, albo przerwanej aktualizacji, która zostawiła niekompletne pliki.

503 bez tego tekstu, zwłaszcza „Service Unavailable” lub 508 „Resource Limit Is Reached”, to zwykle hosting, który odcina stronę po przekroczeniu limitu procesów, procesora lub pamięci. Kto naprawia: przy pliku .maintenance Ty, przy limitach hosting razem z administratorem strony.

„Ta strona przekierowała Cię zbyt wiele razy”

Kod ERR_TOO_MANY_REDIRECTS oznacza pętlę: adres A przekierowuje na B, a B z powrotem na A. Najczęściej po włączeniu SSL w Cloudflare w trybie „Flexible” przy jednoczesnym wymuszeniu HTTPS na serwerze, po migracji, gdy w ustawieniach WordPressa zostały stare adresy, albo gdy wtyczka przekierowań i reguły w .htaccess robią to samo w przeciwnych kierunkach.

SSH: pętlę zobaczysz w wyniku polecenia curl -sIL z pierwszej sekcji, w kolejnych liniach location. Kto naprawia: administrator strony, czasem z dostępem do konta Cloudflare.

Strona przekierowuje na obcą witrynę

Jeśli zamiast Twojej strony otwiera się kasyno, sklep z lekami albo „wygrałeś iPhone’a”, to niemal zawsze włamanie. Złośliwy kod często przekierowuje tylko część odwiedzających: wejścia z telefonu, z wyników Google albo osoby niezalogowane. Dlatego właściciel, który wpisuje adres ręcznie na komputerze, długo niczego nie widzi.

Nie usuwaj niczego w pośpiechu, bo zatrzesz ślady. Plan pierwszej godziny, test ukrytych przekierowań i czyszczenie opisaliśmy w poradniku co robić, gdy strona WordPress została zhakowana. Jeśli na stronie były dane klientów (zamówienia, formularze), sprawdź tam też, czy musisz zgłosić naruszenie do UODO: termin to 72 godziny od jego wykrycia. Kto naprawia: administrator strony lub specjalista od usuwania malware. Hosting zwykle tylko blokuje konto.

„Ta witryna jest nieosiągalna”

Jeśli pod tym napisem Chrome dodaje „Nie można znaleźć adresu IP serwera” i kod DNS_PROBE_FINISHED_NXDOMAIN, domena nie wskazuje na żaden serwer. Przyczyna to wygasła domena, zmienione serwery DNS albo usunięty rekord A. Jeśli widzisz ERR_CONNECTION_TIMED_OUT lub ERR_CONNECTION_REFUSED, domena działa, ale serwer pod wskazanym adresem nie odpowiada albo zapora blokuje Twój adres. Szczegóły w sekcji o domenie, DNS i hostingu.

„Połączenie nie jest prywatne”

Kod NET::ERR_CERT_DATE_INVALID to wygasły certyfikat SSL. NET::ERR_CERT_COMMON_NAME_INVALID oznacza, że certyfikat wystawiono dla innej nazwy, np. bez „www” albo dla starego serwera po przeniesieniu. Darmowe certyfikaty Let’s Encrypt odnawiają się automatycznie, ale odnowienie przestaje działać, gdy domena chwilowo wskazywała gdzie indziej albo gdy Cloudflare blokuje weryfikację. Kto naprawia: hosting (ponowne wystawienie certyfikatu w panelu), czasem administrator, gdy problem leży w ustawieniach Cloudflare.

Podstrony dają błąd 404, a strona główna działa

Typowy objaw po przeprowadzce na inny hosting albo po podmianie pliku .htaccess: strona główna się otwiera, a każda podstrona, wpis czy produkt kończy się błędem 404. WordPress nie dostaje wtedy przyjaznych adresów, bo brakuje reguł przepisywania. Zaloguj się do panelu, otwórz Ustawienia → Bezpośrednie odnośniki i kliknij „Zapisz zmiany” bez zmieniania czegokolwiek. Jeśli to nie pomoże, odtwórz .htaccess według wzoru z drabiny diagnozy. Na serwerze nginx reguły ustawia hosting w konfiguracji serwera, więc napisz do niego.

Strona wyświetla się bez stylów lub rozsypana

Tekst jest, ale bez kolorów, czcionek i układu. Po przejściu na HTTPS lub migracji zwykle winna jest mieszana treść: strona ładuje się przez https://, a arkusze stylów i skrypty przez http:// albo ze starej domeny, więc przeglądarka je blokuje. Otwórz narzędzia deweloperskie (F12), zakładkę Console, i szukaj ostrzeżeń „Mixed Content” albo błędów 404 przy plikach CSS. Inne przyczyny: niezgodne adresy w Ustawienia → Ogólne, pamięć podręczna wtyczki lub CDN z plikami sprzed zmian albo zablokowany CDN. Po poprawce wyczyść pamięć podręczną na wszystkich poziomach (opisujemy to po drabinie).

Zamiast strony widać stronę hostingu lub listę plików

Strona powitalna hostingu, strona parkingowa rejestratora albo lista plików „Index of /” oznaczają, że domena trafia na serwer, ale nie do katalogu ze stroną. Przyczyny: rekord A wskazuje na inny serwer (np. nowy hosting, na który strony jeszcze nie przeniesiono), domena nie jest przypisana do właściwego katalogu w panelu albo w katalogu brakuje pliku index.php, bo ktoś go usunął lub nadpisał. Strona parkingowa rejestratora przy wygasłej domenie to osobny przypadek, opisany niżej.

Strona działa, ale nie da się zalogować

Po kliknięciu „Zaloguj się” formularz przeładowuje się bez komunikatu, pokazuje błąd ciasteczek albo „Zbyt wiele nieudanych prób”. Przyczyną bywa wtyczka bezpieczeństwa, która zablokowała Twój IP, zmieniony adres logowania, niezgodne adresy w ustawieniach (siteurl i home) albo konto administratora usunięte przez włamywacza. Ten ostatni scenariusz sprawdź, zanim uznasz problem za drobny: jeśli w bazie widzisz administratorów, których nie znasz, postępuj jak przy włamaniu.

Strona działa, ale bardzo wolno lub co jakiś czas pada

Strona, która ładuje się 10 sekund rano i pada wieczorem, zwykle dobija do limitów hostingu. Winni są ciężki motyw z kreatorem stron, brak pamięci podręcznej, boty skanujące formularze i strony logowania albo zadania cron, które uruchamiają się przy każdej wizycie. Sprawdź w panelu hostingu wykresy zużycia procesora, pamięci i liczby procesów z godzin, w których strona padała.

Jeśli w logu dostępu widzisz tysiące żądań z kilku adresów albo do wp-login.php i xmlrpc.php, to ruch botów lub atak. Poproś hosting o włączenie zapory aplikacji (WAF) albo blokadę zakresów adresów. Strona za Cloudflare z ograniczaniem liczby żądań zwykle znosi takie fale bez przestoju.

Strona była niedostępna, a teraz działa

Krótka awaria, która minęła sama, i tak ma przyczynę, a ta zwykle wraca. Ustal ją, póki logi są świeże:

• Panel hostingu: wykresy zasobów z godziny awarii (skok procesora, procesów, pamięci) i komunikaty o przekroczeniu limitów.
• Log błędów serwera z tego okresu: poproś o niego hosting, jeśli nie widzisz go w panelu.
• Google Search Console: Ustawienia → Statystyki indeksowania pokazują błędy serwera i problemy z dostępnością hosta z ostatnich 90 dni, z dokładnością do dnia.
• E-mail od WordPressa o automatycznych aktualizacjach z tego dnia: czasem aktualizacja przez chwilę psuje stronę, a potem zostaje cofnięta (opisujemy to w sekcji o aktualizacjach).

Kod błędu i komunikat: kto naprawia

Tabela zbiera komunikaty, które najczęściej widzą właściciele stron. Komunikaty WordPressa podajemy w brzmieniu z polskiej wersji językowej. Kolumna „kto naprawia” wskazuje, do kogo napisać najpierw.

Domena, DNS, hosting i SSL — warstwy poza WordPressem

Zaczynamy od infrastruktury, bo jeśli domena wygasła, żadna zmiana w WordPressie nie pomoże, a każda godzina grzebania w plikach to strata czasu.

Wygasła domena: jak to sprawdzić

Bez dostępów: wpisz domenę w wyszukiwarce WHOIS na stronie rejestru dns.pl (dla domen .pl) lub u swojego rejestratora. Dla domen .pl data ważności to pole renewal date. Nie myl go z option expiration date: to data wygaśnięcia opcji, czyli rezerwacji domeny na przyszłość, a nie samej domeny. Na końcu wyniku zobaczysz też nazwę rejestratora, do którego trzeba się zgłosić.

Jeśli data minęła, skontaktuj się z rejestratorem jeszcze dziś. Według rejestru dns.pl domena .pl po zakończeniu opłaconego okresu pozostaje w tym stanie do 30 dni, a szczegóły odnowienia określa regulamin rejestru i umowa z rejestratorem. Przy innych końcówkach (.com, .eu) okres i opłata za przywrócenie zależą od rejestru i rejestratora. Pamiętaj, że razem ze stroną przestaje działać poczta w tej domenie, więc z rejestratorem kontaktuj się z innego adresu.

Najczęstszy scenariusz w firmach: domenę rejestrował dawny pracownik lub agencja na swój e-mail, więc przypomnień o płatności nikt nie czytał.

DNS po zmianie hostingu lub poczty

Drugi częsty przypadek: ktoś przeniósł pocztę do nowego dostawcy i przy okazji zmienił serwery DNS domeny. Poczta działa, strona nie, bo w nowej strefie DNS nikt nie dodał rekordu A wskazującego na hosting strony. Panel / FTP: w panelu hostingu znajdziesz adres IP serwera. Porównaj go z wynikiem nslookup -type=A twojadomena.pl 1.1.1.1. Jeśli adresy się różnią, popraw rekord A tam, gdzie domena ma obecnie ustawione serwery nazw.

Dwa wyjątki, przy których różnica jest prawidłowa albo mylą się nawet technicy:

• Cloudflare lub inny CDN. Jeśli domena jest w Cloudflare z włączonym proxy (pomarańczowa chmurka), nslookup pokaże adresy Cloudflare, a nie Twojego serwera. To normalne. Rekord sprawdzaj wtedy w panelu DNS Cloudflare i nie wyłączaj proxy „na próbę”.
• Stary rekord AAAA (IPv6). Po przeprowadzce w strefie często zostaje adres IPv6 starego serwera. Strona działa wtedy w części sieci, a w innych, zwłaszcza komórkowych z IPv6, nie. Sprawdź nslookup -type=AAAA twojadomena.pl 1.1.1.1. Jeśli adres nie należy do obecnego hostingu, popraw go albo usuń.

Hosting zawiesił konto

Hosting najczęściej wyłącza stronę z jednego z czterech powodów: nieopłacona faktura, przekroczone limity zasobów, wykryte złośliwe oprogramowanie (konto blokowane, żeby nie rozsyłało spamu) albo naruszenie regulaminu. Zaloguj się do panelu klienta, nie do panelu strony, i sprawdź komunikaty oraz skrzynkę, na którą hosting wysyła powiadomienia. Przy blokadzie za malware hosting zwykle odblokuje konto dopiero po wyczyszczeniu plików, więc samo opłacenie czy prośba nie wystarczą.

Sprawdź też zajęte miejsce i liczbę plików (i-węzłów) na koncie. Po przekroczeniu limitu konto formalnie działa, ale WordPress nie zapisze sesji, pamięci podręcznej ani przesłanego pliku, a baza danych potrafi przestać przyjmować zapisy. Objawy są wtedy dziwne i zmienne.

Uważaj na wygaśnięcie samej usługi hostingu. Po okresie karencji wielu dostawców trwale usuwa pliki i bazę. Jeśli domena i hosting to jeden pakiet, nieopłacona faktura wyłącza oba naraz. Zapytaj dostawcę o termin usunięcia danych i, jeśli jedyna kopia leży na tym koncie, traktuj każdy dzień jako ważny.

Certyfikat SSL i Cloudflare

Jeśli strona stoi za Cloudflare, część błędów generuje Cloudflare, a nie Twój serwer. Kody 52x dzielą się na trzy grupy:

• 521, 522, 523: serwer nie odpowiada, odpowiada za wolno na nawiązanie połączenia albo jest nieosiągalny dla Cloudflare. Najczęściej hosting leży albo jego zapora blokuje adresy Cloudflare. To sprawa hostingu.
• 524: serwer przyjął połączenie, ale strona nie wygenerowała odpowiedzi w ok. 100 sekund. Zwykle to długi import, wolne zapytanie do bazy albo przeciążony PHP, czyli sprawa administratora i hostingu razem.
• 520: serwer zwrócił pustą lub nietypową odpowiedź, często po awarii procesu PHP. Zacznij od logu błędów.

525 i 526 to problem z certyfikatem na serwerze hostingu. Test z wymuszonym adresem IP serwera z pierwszej sekcji pokaże, czy hosting działa bez Cloudflare.

Diagnoza w WordPressie: drabina od prostych kroków

Jeśli domena, DNS, hosting i certyfikat są w porządku, problem leży w samym WordPressie. Kolejność poniżej układa kroki od najmniej do najbardziej inwazyjnych. Po każdym kroku sprawdź stronę i zapisz wynik.

1. Szukaj e-maila od WordPressa. Przejrzyj skrzynkę administratora, łącznie ze spamem, w poszukiwaniu tematu „Twoja witryna ma problemy techniczne”. Link z e-maila otwiera tryb odzyskiwania, w którym wyłączysz winną wtyczkę z panelu. WordPress wysyła taki e-mail najwyżej raz na dobę i link jest ważny przez ten sam czas. Nie dotrze, gdy serwer nie wysyła poczty albo adres administratora jest nieaktualny. Inny adres ustawisz stałą RECOVERY_MODE_EMAIL.
2. Włącz zapis błędów. Dopisz w wp-config.php linie z ramki poniżej. Odśwież stronę i otwórz plik wp-content/debug.log. Ostatnie linie z „PHP Fatal error” zwykle wskazują ścieżkę z nazwą winnej wtyczki lub motywu.
3. Wyłącz podejrzaną wtyczkę. Przez FTP lub menedżer plików zmień nazwę jej folderu w wp-content/plugins, np. z nazwa-wtyczki na nazwa-wtyczki-off. Jeśli nie wiesz, która to, zmieniaj nazwy po kolei, zaczynając od ostatnio aktualizowanych. Pojedyncze wyłączanie od razu wskazuje winną wtyczkę.
4. Sprawdź mu-plugins i drop-iny. Pliki w wp-content/mu-plugins oraz object-cache.php i advanced-cache.php w wp-content ładują się zawsze. Nie wyłączysz ich zmianą nazwy katalogu plugins. Częsty przypadek to plik pozostały po usuniętej wtyczce cache. Zmień nazwę podejrzanego pliku, np. na object-cache.php-off. Po usunięciu wtyczki z zaporą (np. Wordfence) sprawdź też .user.ini i .htaccess: linia auto_prepend_file wskazująca na nieistniejący plik wywraca całą stronę.
5. Przełącz motyw na domyślny. Zmień nazwę folderu aktywnego motywu w wp-content/themes, a potem zaloguj się do panelu i otwórz Wygląd → Motywy. Dopiero wtedy WordPress przełączy stronę na motyw domyślny (w wersji 7.1 to Twenty Twenty-Five), a gdy go brak, na najnowszy zainstalowany motyw domyślny. Bez tego wejścia strona jest pusta i nie mówi nic o przyczynie. Zmiana zapisuje się w bazie, więc po naprawie przywróć nazwę folderu, włącz swój motyw ręcznie i sprawdź menu oraz widżety. Gdy panel nie działa, użyj WP-CLI (niżej).
6. Odtwórz plik .htaccess. Przy błędzie 500 zmień nazwę .htaccess na .htaccess-old i wgraj podstawową wersję z ramki poniżej. Jeśli strona wróci, w starym pliku była błędna reguła. Nie widzisz pliku? Włącz pokazywanie plików ukrytych w kliencie FTP lub menedżerze plików.
7. Sprawdź wersję PHP. Jeśli awaria zbiegła się ze zmianą PHP w panelu hostingu, przywróć poprzednią wersję i zaplanuj aktualizację wtyczek na kopii strony.
8. Zwiększ limit pamięci. Jeśli w logu jest „Allowed memory size of … bytes exhausted”, dodaj w wp-config.php linię define( 'WP_MEMORY_LIMIT', '256M' );. Limit nie przekroczy tego, na co pozwala hosting.
9. Wgraj czyste pliki WordPressa. Pobierz tę samą wersję (dla polskiej instalacji z pl.wordpress.org), usuń katalogi wp-admin i wp-includes, wgraj je z paczki i nadpisz pliki z katalogu głównego oprócz wp-config.php. Nie ruszaj wp-content. Przez SSH: wp core download --version=$(wp core version) --locale=pl_PL --skip-content --force (nie usuwa obcych plików). Przy podejrzeniu włamania najpierw skopiuj zmienione pliki jako materiał dowodowy.

Kod do wp-config.php. Wstaw go nad linią /* That's all, stop editing! Happy publishing. */ (w polskich instalacjach ten komentarz bywa przetłumaczony i zaczyna się od „To wszystko”). Jeśli te stałe już są w pliku, zmień ich wartości zamiast dopisywać drugi raz.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // zapis do wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // nie pokazuj błędów odwiedzającym
@ini_set( 'display_errors', 0 );

Jak czytać wpisy w logu i co oznaczają najczęstsze komunikaty, rozpisaliśmy w tabeli w poradniku o naprawie błędu krytycznego. Opis stałych debugowania jest w oficjalnej dokumentacji WordPressa.

Podstawowy .htaccess dla pojedynczej strony WordPress na serwerze Apache lub LiteSpeed, zgodny z dokumentacją WordPressa:

# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Ten wzór działa dla WordPressa w katalogu głównym domeny. Jeśli strona stoi w podkatalogu, zmień RewriteBase / na RewriteBase /katalog/ i ostatnią regułę na RewriteRule . /katalog/index.php [L]. Podstawowy plik nie ma reguł wtyczki cache, zabezpieczeń, przekierowań 301 ani wymuszania HTTPS. Gdy strona wróci, przenieś ze starego pliku sprawne sekcje po jednej i po każdej sprawdź stronę.

Uwaga przy wyłączaniu wtyczek: WordPress dezaktywuje brakujące wtyczki dopiero po otwarciu ekranu Wtyczki w panelu. Jeśli przywrócisz nazwę folderu, zanim tam wejdziesz, wtyczka zostanie aktywna. Jeśli wejdziesz na ten ekran, gdy folder ma zmienioną nazwę, po przywróceniu trzeba ją włączyć ręcznie. Przy zmianie nazwy całego katalogu plugins dotyczy to wszystkich wtyczek naraz.

Ścieżka SSH: WP-CLI

Jeśli hosting daje dostęp SSH i ma zainstalowane WP-CLI (aktualna wersja to 2.12), diagnozę z drabiny zrobisz w kilka minut. Przełączniki --skip-plugins --skip-themes pomijają wtyczki i motyw, więc polecenia działają nawet wtedy, gdy wtyczka wywołuje błąd krytyczny. Wyjątek: pliki z mu-plugins i drop-iny ładują się zawsze. Jeśli błąd siedzi w nich, WP-CLI też się wywróci i trzeba zmienić nazwę pliku ręcznie.

# wersje i adresy
wp core version --skip-plugins --skip-themes
wp eval 'echo PHP_VERSION;' --skip-plugins --skip-themes   # PHP terminala, nie zawsze strony
wp option get siteurl --skip-plugins --skip-themes
wp option get home --skip-plugins --skip-themes

# czy pliki są oryginalne (--include-root: obce pliki w katalogu głównym)
wp core verify-checksums --include-root --skip-plugins --skip-themes
wp plugin verify-checksums --all --skip-plugins --skip-themes

# aktywne wtyczki, mu-plugins, drop-iny i wyłączenie podejrzanej
wp plugin list --status=active --skip-plugins --skip-themes
wp plugin list --status=must-use --skip-plugins --skip-themes
wp plugin list --status=dropin --skip-plugins --skip-themes
wp plugin deactivate nazwa-wtyczki --skip-plugins --skip-themes

# przełączenie na motyw domyślny
wp theme activate twentytwentyfive --skip-plugins --skip-themes

# tryb konserwacji i baza danych
wp maintenance-mode status --skip-plugins --skip-themes
wp db check

# ostatnie błędy z logu
tail -n 50 wp-content/debug.log

Wersja PHP w terminalu na hostingach współdzielonych często różni się od tej, z którą działa strona. Wersję strony sprawdzisz w panelu hostingu (wybór wersji PHP dla domeny) albo w Narzędzia → Stan witryny → Informacja → Serwer. Jeśli hosting ma kilka wersji PHP, uruchamiaj WP-CLI tą samą, której używa strona.

Polecenie verify-checksums porównuje pliki z sumami kontrolnymi z wordpress.org. Zmienione pliki rdzenia to sygnał włamania albo ręcznych poprawek poprzedniego wykonawcy. W obu przypadkach nie nadpisuj ich na ślepo, tylko najpierw zrób kopię. Wtyczki premium spoza katalogu wordpress.org zgłoszą brak sum kontrolnych i polecenie zakończy się błędem. To nie jest dowód włamania: takie wtyczki porównaj z paczką od producenta.

Po naprawie: wyczyść pamięć podręczną

Strona działa u Ciebie, a klienci dalej widzą błąd albo komunikat o konserwacji? To zapisana kopia strony z czasu awarii. Wyczyść pamięć podręczną na każdym poziomie, który masz: we wtyczce cache, w pamięci serwera (np. LiteSpeed Cache w panelu hostingu), w Cloudflare lub innym CDN (opcja usunięcia całej zawartości). Potem sprawdź stronę w oknie incognito i z telefonu bez Wi-Fi.

Strona przestała działać po aktualizacji

To jeden z najczęstszych scenariuszy w zgłoszeniach awarii: wieczorem włączyły się automatyczne aktualizacje, rano strona nie działa. Masz dwie drogi: cofnąć konkretny element albo przywrócić całą kopię.

Od WordPressa 6.6 automatyczna aktualizacja aktywnej wtyczki, po której strona główna zwraca błąd krytyczny, jest cofana automatycznie. WordPress sprawdza to jednym zapytaniem do strony głównej, więc błąd tylko na podstronie, w koszyku albo w panelu przejdzie niezauważony. W e-mailu o automatycznych aktualizacjach taka wtyczka pojawi się na liście tych, których nie udało się zaktualizować. Strona mogła więc wrócić sama, a wtyczka zostać na starej wersji.

Panel / FTP: jeśli wiesz, która wtyczka się zaktualizowała (lista w e-mailu od WordPressa lub w historii hostingu), wyłącz ją zmianą nazwy folderu i sprawdź stronę. Jeśli wróciła, zostaw wtyczkę wyłączoną i poczekaj na poprawkę albo wgraj poprzednią wersję z zakładki „Widok zaawansowany” (sekcja „Poprzednie wersje”) na stronie wtyczki w katalogu wordpress.org.

SSH: poprzednią wersję zainstalujesz jednym poleceniem. Numer wersji znajdziesz w dzienniku zmian wtyczki.

wp plugin install nazwa-wtyczki --version=2.4.1 --force --skip-plugins --skip-themes

Starsza wersja to rozwiązanie tymczasowe, bo może mieć znane luki bezpieczeństwa. Wtyczek premium nie pobierzesz w ten sposób ani z katalogu wordpress.org, tylko z konta u producenta.

Jeśli zaktualizowało się kilka rzeczy naraz albo nie wiesz co, szybciej będzie przywrócić kopię z panelu hostingu z godziny sprzed aktualizacji. Pamiętaj, że przywrócenie bazy cofa też zamówienia, wiadomości z formularzy i komentarze z tego okresu. W sklepie najpierw wyeksportuj nowe zamówienia.

Jak zgłosić awarię do hostingu — szablon

Zgłoszenie „strona nie działa, proszę o pomoc” zwykle kończy się odpowiedzią „u nas wszystko działa”. Konsultant potrzebuje faktów, które może sprawdzić w logach. Skopiuj szablon i uzupełnij pola.

Temat: Awaria strony twojadomena.pl — kod HTTP [500/503/…] od [godzina]

Domena: twojadomena.pl
Login / numer klienta: …
Od kiedy: [data, godzina] (strefa czasowa: Polska)
Co widać: [dosłowny komunikat, np. „HTTP ERROR 500”], zrzut w załączniku
Kod HTTP: [wynik curl -I lub narzędzia online]
Adres IP, na który wskazuje domena: [wynik nslookup]
Mój publiczny adres IP: [jeśli strona nie działa tylko z biura]
Czy błąd występuje z innych sieci: [tak/nie, z jakich]
Ostatnie zmiany: [aktualizacje, zmiana PHP, DNS, nowa wtyczka]
Co już sprawdziłem: [np. domena opłacona do …, wyłączona wtyczka X, brak zmian]

Proszę o:
1. fragment logu błędów serwera (error log) dla tej domeny z ostatnich 2 godzin,
2. informację, czy konto przekroczyło limity zasobów lub zostało zablokowane,
3. datę i godzinę najnowszej kopii zapasowej sprzed awarii.

Ostatnie trzy prośby są najważniejsze. Log błędów serwera często zawiera to, czego nie ma w debug.log, a informacja o kopii pozwala zdecydować, czy szybciej będzie przywrócić stronę, czy ją naprawiać. W panelach DirectAdmin i cPanel log błędów znajdziesz też sam, w sekcji ze statystykami i logami domeny. Hostingi z własnym panelem udostępniają go w różnych miejscach albo na prośbę przez pomoc techniczną.

Ile kosztuje każda godzina przestoju

Koszt awarii to nie tylko cena naprawy. Policz go, zanim zdecydujesz, czy spędzić nad diagnozą jeszcze trzy godziny.

• Utracona sprzedaż lub zapytania. Podziel miesięczny przychód z internetu przez liczbę godzin, w których klienci realnie kupują. Przykład: sklep z obrotem 60 000 zł miesięcznie i sprzedażą rozłożoną na 16 godzin dziennie traci około 125 zł na każdej godzinie awarii (60 000 ÷ 30 dni ÷ 16 godzin).
• Opłacona reklama. Kampanie Google Ads i Meta zwykle działają dalej i płacisz za kliknięcia prowadzące na niedziałającą stronę. Przy dłuższej awarii wstrzymaj je ręcznie.
• Widoczność w Google. Według dokumentacji Google przy błędach 5xx roboty zwalniają skanowanie, a adresy, które uparcie zwracają błąd serwera, są w końcu usuwane z indeksu. Kilka godzin awarii zwykle nie szkodzi, kilka dni już tak.
• Twój czas. Godzina właściciela firmy spędzona w FTP to godzina, w której nie obsługuje klientów.

Dla sklepów na WooCommerce przygotowaliśmy kalkulator kosztu awarii sklepu. Szerszy obraz, czyli ile kosztuje utrzymanie strony w skali roku i ile kosztują awarie bez stałej opieki, znajdziesz w poradniku ile kosztuje utrzymanie strony internetowej.

Kiedy przestać i zlecić naprawę

Samodzielna diagnoza ma sens, dopóki każdy krok przybliża Cię do przyczyny. Przestań i przekaż sprawę, gdy:

• po godzinie nadal nie wiesz, która warstwa zawiodła,
• w debug.log nie ma błędów, a strona dalej nie działa,
• verify-checksums pokazuje zmienione pliki rdzenia, w panelu są nieznani administratorzy albo strona przekierowuje na obce domeny,
• hosting zablokował konto z powodu złośliwego oprogramowania,
• nie masz aktualnej kopii, a naprawa wymaga zmian w bazie danych,
• to sklep i każda godzina kosztuje więcej niż naprawa.

Nie musimy być autorami Twojej strony, żeby ją naprawić. Potrzebujemy dostępu do panelu hostingu lub FTP i opisu objawów. Naprawa WordPress u nas kosztuje od 490 zł netto, a stałą cenę podajemy po diagnozie i przed rozpoczęciem pracy. Gdy przyczyną jest włamanie, usunięcie złośliwego kodu kosztuje od 790 zł netto i obejmuje 30 dni gwarancji.

Hosting czy wykonawca: kto odpowiada za awarię

Hosting odpowiada za serwer, sieć i bazę danych, ale nie za kod wtyczek, motywu ani za to, co wgrał Twój wykonawca. Wykonawca strony odpowiada za awarie po swoich zmianach tylko wtedy, gdy macie umowę na utrzymanie lub gwarancję. Bez umowy nikt nie ma obowiązku reagować, dlatego przy pierwszej awarii zwykle okazuje się, że każdy odsyła do kogoś innego. Jeśli nie masz nawet dostępów do hostingu i domeny, bo zostały u dawnej agencji, zacznij od uporządkowania tego. Pomaga w tym audyt przejęcia strony za 390 zł.

Jak dowiedzieć się o awarii, zanim zadzwoni klient

Większość właścicieli dowiaduje się o awarii od klienta albo pracownika, często po kilku godzinach. Trzy proste zabezpieczenia skracają ten czas do minut:

• Monitoring dostępności. Zewnętrzna usługa sprawdza stronę co minutę lub kilka minut i wysyła SMS lub e-mail, gdy przestanie odpowiadać. Ustaw sprawdzanie nie tylko strony głównej, ale też kluczowej podstrony, np. formularza kontaktowego lub koszyka.
• Domena i certyfikat. Upewnij się, że rejestrator i hosting mają Twój aktualny e-mail, a nie adres dawnego pracownika, i zapisz w kalendarzu datę renewal date z WHOIS na miesiąc przed terminem. Z certyfikatem kalendarz nie wystarczy: Let’s Encrypt od czerwca 2025 r. nie wysyła już przypomnień e-mailem, a certyfikaty publiczne wystawiane od 15 marca 2026 r. mogą być ważne najwyżej 200 dni. Datę ważności niech pilnuje monitoring: większość takich usług ma alert o wygasającym SSL.
• Kopie poza hostingiem. Kopia trzymana na tym samym serwerze znika razem z kontem, gdy hosting je zablokuje lub usunie. Sprawdź raz na kwartał, czy kopię da się przywrócić.

Jeśli wolisz, żeby pilnował tego ktoś inny, mamy stałą opiekę techniczną z monitoringiem co minutę, aktualizacjami testowanymi na kopii i kopiami poza hostingiem. Wtedy o awarii dowiadujemy się my, zwykle zanim zauważy ją ktokolwiek z Twoich klientów.