Pierwsze kroki: zabezpiecz stronę i zbierz informacje

Najpierw ustal zakres problemu: czy nie działa cała witryna, tylko panel administracyjny, konkretna podstrona czy płatności/formularze. Zanotuj dokładny komunikat, godzinę wystąpienia oraz ostatnie zmiany: aktualizację WordPressa, wtyczki, motywu, PHP, DNS lub konfiguracji hostingu.

1. Sprawdź stronę z innej przeglądarki lub sieci i zweryfikuj, czy problem nie dotyczy cache.
2. Sprawdź status usług i komunikaty w panelu hostingu; przy 5xx poproś o logi serwera i PHP.
3. Wykonaj kopię aktualnego stanu plików oraz bazy przed zmianami. Nie nadpisuj jedynej kopii.
4. Jeśli podejrzewasz włamanie, nie usuwaj logów ani plików przed zabezpieczeniem dowodów i skontaktuj się z hostingiem/specjalistą.

1. Biały ekran lub komunikat o błędzie krytycznym

Pusta strona może wynikać z błędu PHP, konfliktu wtyczki lub motywu, wyczerpania limitu pamięci albo problemu z bazą. Nie zakładaj od razu, że przyczyną jest pamięć. Sprawdź najpierw e-mail administratora WordPressa — komunikat o błędzie krytycznym może zawierać link do trybu odzyskiwania.

1. Otwórz e-mail administratora oraz log błędów PHP w panelu hostingu.
2. Jeśli masz dostęp do panelu WordPressa, użyj trybu odzyskiwania albo wyłącz ostatnio zmienioną wtyczkę i sprawdź stronę.
3. Jeśli panel jest niedostępny, wykonaj kopię, a następnie przez FTP/menedżer plików zmień nazwę folderu podejrzanej wtyczki w wp-content/plugins. Jeśli nie znasz winowajcy, tymczasowe przemianowanie folderu plugins dezaktywuje wszystkie wtyczki; przywróć nazwę i aktywuj je pojedynczo po odzyskaniu dostępu.
4. Jeśli problem zaczął się po zmianie motywu, przełącz na motyw domyślny przez panel lub po uzgodnieniu z administratorem.
5. Jeżeli log wskazuje błąd pamięci, sprawdź limit u hosta. Zwiększenie wartości w konfiguracji nie podniesie limitu, jeśli serwer go nie dopuszcza.

Nie usuwaj ani nie edytuj wielu wtyczek i plików jednocześnie — utrudni to ustalenie przyczyny i cofnięcie zmiany.

2. Błąd 500 Internal Server Error

Kod 500 oznacza, że serwer nie może prawidłowo obsłużyć żądania. Przyczyną może być błąd PHP, wtyczka, limit zasobów, konfiguracja serwera lub — w przypadku Apache/LiteSpeed — problem z plikiem .htaccess. Najpierw sprawdź error log, bo sam komunikat 500 nie wskazuje konkretnej przyczyny.

1. Sprawdź logi serwera i PHP z czasu awarii oraz panel hostingu pod kątem limitów i przerw.
2. Jeśli awaria nastąpiła po zmianie wtyczki/motywu, cofnij tę zmianę lub wykonaj procedurę diagnostyczną z poprzedniej sekcji.
3. Jeśli log wskazuje .htaccess i serwer korzysta z Apache/LiteSpeed, pobierz kopię pliku, zmień jego nazwę tymczasowo i sprawdź witrynę. Jeśli to pomaga, odtwórz reguły zgodne z konfiguracją serwera. Po przywróceniu dostępu zapisz ustawienia bezpośrednich odnośników w WordPressie.
4. Przy Nginx reguły przekierowań/permalinków są zwykle w konfiguracji serwera, nie w .htaccess; poproś hosting o sprawdzenie.
5. Pliki rdzenia WordPressa wymieniaj tylko wtedy, gdy masz przesłanki ich uszkodzenia, pobieraj je z oficjalnego WordPress.org i nie nadpisuj wp-content ani wp-config.php. Najpierw wykonaj kopię i skonsultuj to z administratorem.

3. Błąd połączenia z bazą danych

Komunikat „Error establishing a database connection” oznacza, że WordPress nie może połączyć się z bazą. Przyczyną mogą być nieprawidłowe dane w wp-config.php, niedostępny serwer bazy, limit przestrzeni/połączeń albo awaria hostingu.

1. Sprawdź status bazy danych i dostępność serwera w panelu hostingu.
2. Zweryfikuj z danymi dostarczonymi przez hosting nazwę bazy, użytkownika, hasło i host bazy w wp-config.php. Nie wklejaj tu tych danych i nie wysyłaj ich publicznie.
3. Jeśli konfiguracja jest poprawna, zgłoś się do hostingu z godziną awarii i prośbą o sprawdzenie usługi, limitów i logów bazy.
4. Jeśli logi wskazują uszkodzone tabele, wykonaj kopię bazy i poproś administratora/hosting o sprawdzenie oraz naprawę.

Nie uruchamiaj publicznego skryptu naprawy bazy na produkcji bez zrozumienia jego zabezpieczeń. Funkcje diagnostyczne mogą ujawniać lub zmieniać dane; najbezpieczniej wykonać naprawę po kopii przez hosting lub kompetentnego administratora.

4. Nieudana aktualizacja i zawieszony tryb konserwacji

Jeśli błąd pojawił się w trakcie aktualizacji, najpierw sprawdź, czy proces nadal trwa oraz czy hosting nie zgłasza problemu z przestrzenią, uprawnieniami lub połączeniem. Nie rozpoczynaj kolejnej aktualizacji, dopóki nie sprawdzisz stanu plików i bazy.

Komunikat o zaplanowanych pracach nie znika

WordPress na czas aktualizacji tworzy w katalogu instalacji tymczasowy plik .maintenance. Jeśli aktualizacja została przerwana i nie trwa już żaden proces, po wykonaniu kopii możesz usunąć ten plik przez menedżer plików/FTP. Nie usuwaj go w trakcie rzeczywistej aktualizacji.

Aktualizacja wtyczki, motywu lub WordPressa nie powiodła się

• Sprawdź komunikat w panelu oraz logi; zweryfikuj przestrzeń i prawa zapisu.
• Przywróć działanie z kopii, jeśli aktualizacja uszkodziła produkcyjną stronę.
• Wykonuj kolejną próbę na stagingu i aktualizuj komponenty pojedynczo, aby wykryć konflikt.
• Po aktualizacji sprawdź front, panel, formularze, sklep i płatności.

5. Debugowanie bez ujawniania błędów odwiedzającym

Tryb debugowania może pomóc znaleźć źródło błędu, ale logi mogą zawierać ścieżki, dane techniczne lub informacje wrażliwe. Włączaj go tymczasowo, najlepiej na stagingu. Jeśli musisz diagnozować na produkcji, zapisuj błędy do logu i nie wyświetlaj ich odwiedzającym.

Po wykonaniu kopii i uzgodnieniu z administratorem można tymczasowo ustawić w wp-config.php (przed komentarzem końcowym konfiguracji) następujące wartości, o ile nie są już zdefiniowane:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Log znajduje się zwykle w wp-content/debug.log. Ogranicz do niego dostęp, pobierz tylko potrzebne wpisy, a po diagnozie wyłącz debugowanie i bezpiecznie usuń log. Nie pozostawiaj go publicznie dostępnym. Jeśli problem dotyczy produkcyjnego sklepu lub zawiera dane klientów, skontaktuj się z hostingiem.

Interaktywna checklista ratunkowa

Odhaczaj kroki podczas diagnozy. Zaznaczenia są zapisywane lokalnie w tej przeglądarce; nie zapisują informacji o awarii ani danych logowania.

0 z 8 kroków

• Zanotuj komunikat, zakres awarii i ostatnie zmiany.
• Wykonaj kopię plików i bazy przed zmianami.
• Sprawdź e-mail administratora, logi PHP i status hostingu.
• Testuj jedną hipotezę naraz, zaczynając od ostatniej zmiany.
• Przed zmianą nazwy/edycją pliku pobierz jego kopię.
• Po przywróceniu strony sprawdź panel, formularze i kluczowe funkcje.
• Wyłącz debugowanie i zabezpiecz lub usuń logi.
• Zapisz przyczynę i plan zapobiegania powtórce.

Najczęściej zadawane pytania (FAQ)

Oficjalna dokumentacja

• WordPress Developer Resources: najczęstsze błędy WordPressa
• WordPress Developer Resources: debugowanie
• WordPress.org: FAQ rozwiązywania problemów
• WordPress.org: wymagania środowiska

Poradnik ma charakter informacyjny. Instrukcje należy dostosować do wersji WordPressa, konfiguracji serwera i hostingu. Przed zmianami w środowisku produkcyjnym wykonaj pełny backup.