Problemy WordPress 2026: 10 najczęstszych błędów i jak je naprawić

Zacznij od adresu, czasu i dokładnej czynności, która zawiodła. Sprawdź log oraz ostatnią zmianę, zabezpiecz kopie i testuj uzasadnioną poprawkę na odizolowanym środowisku. Nie utożsamiaj kodu błędu z jedną przyczyną i nie przywracaj starej bazy sklepu bez ochrony nowych zapisów.

Zanim zaczniesz: zapisz objaw i zabezpiecz stan

Najpierw ustal, czy problem dotyczy całej strony, pojedynczego adresu, panelu czy konkretnej czynności. Zapisz komunikat i czas. Sprawdź ostatnią aktualizację lub zmianę konfiguracji, ale traktuj ją jako trop, nie gotowy dowód przyczyny.

Zabezpiecz dostępne pliki i bazę przed ingerencją. W sklepie starszy backup może nie zawierać nowych zamówień, więc pełne odtworzenie wymaga planu zachowania bieżących zapisów. Nie wyłączaj wszystkich wtyczek i nie usuwaj plików na próbę.

Korzystaj z prywatnych logów hostingu. Dokumentacja WordPressa zaznacza: "It is not recommended to use WP_DEBUG or the other debug tools on live sites". Dodatkową diagnostykę prowadź na kopii, z ukrytym wyświetlaniem błędów i logiem poza publicznym katalogiem. Samo wyłączenie komunikatów na ekranie nie chroni pliku debug.log.

Jeżeli nie wiesz, gdzie zacząć, ogólny poradnik błędów WordPressa prowadzi przez pierwsze sprawdzenia i dostęp do kopii.

1. Błąd 500 lub inny komunikat serwera

Kod 500 mówi o problemie po stronie serwera, ale nie wskazuje automatycznie uszkodzonej wtyczki. Przy 502, 503 i 504 również potrzebny jest kontekst odpowiedzi oraz log z tej samej chwili. Zapisz adres i sprawdź, czy inne czynności działają.

Nie zaczynaj od usuwania .htaccess, restartu PHP ani zwiększania timeoutu. Te działania mają sens tylko przy potwierdzonej przyczynie i możliwości cofnięcia. Cache może sprawiać, że strona główna wygląda poprawnie mimo awarii innych żądań.

Przejdź do diagnozy błędu 500, aby dobrać sprawdzenie do komunikatu. Po poprawce ponów dokładnie tę czynność, która wcześniej zawiodła, zamiast oceniać wyłącznie ekran główny.

2. Problemy po zmianie wersji PHP

Po zmianie PHP sprawdź log i zgodność używanego core, motywu oraz rozszerzeń. Działająca strona główna nie potwierdza poprawnego zapisu w edytorze lub działania integracji. Testuj reprezentatywne funkcje na kopii przed przełączeniem produkcji.

Według tabeli wsparcia PHP poprawki bezpieczeństwa dla 8.2 kończą się 31 grudnia 2026, dla 8.3 rok później, a dla 8.4 w 2028. PHP 8.5 również jest wspieraną linią. Nie wybieraj wersji wyłącznie na podstawie starszego poradnika.

Macierz zgodności WordPressa dotyczy konkretnych wersji core. Nie jest certyfikatem zgodności wszystkich dodatków. Jeżeli potrzebne jest cofnięcie zmiany, ustal jego zakres i potraktuj je jako etap odzyskania działania, a nie stały powrót do niewspieranego środowiska.

Tak zmianę PHP opisano w rzeczywistej opinii SP nr 1 im. Lecha Bądkowskiego w Luzinie z 22 kwietnia 2026:

Na szczególne uznanie zasługuje fakt, że udało się bezpiecznie uruchomić stronę na PHP w wersji 8.3, co wcześniej wydawało się niemożliwe bez gruntownej przebudowy.

Źródło: opinia w profilu Google KC Mobile. Ten opis dotyczy wskazanej realizacji; zakres prac dla innej strony wynika z jej własnej konfiguracji.

3. Menu mobilne nie otwiera się lub zasłania treść

Sprawdź problem przy szerokości, przy której go zauważono, oraz na rzeczywistym urządzeniu. Zwróć uwagę, czy kliknięcie dociera do przycisku i czy konsola zgłasza błąd JavaScript. Nakładka zgód, warstwa nagłówka albo niedostarczony skrypt mogą dać podobny objaw.

Samo ustawienie bardzo wysokiego z-index nie rozwiązuje wszystkich problemów nakładania. Po zmianie sposobu ładowania skryptów ustal, który zasób i zależność przestały działać. Testuj pojedynczą korektę na kopii.

Po naprawie sprawdź otwarcie, zamknięcie i wybór linku, a także klawiaturę oraz widok po zmianie orientacji. Upewnij się, że przeglądarka pobiera aktualną wersję zasobów. Nie wyłączaj całej optymalizacji tylko dlatego, że jeden przycisk nie odpowiada.

4. Biały ekran lub błąd krytyczny bez panelu

Odczytaj log PHP i sprawdź, czy WordPress udostępnił wiadomość Recovery Mode. Ten mechanizm może ułatwić odzyskanie dostępu przy określonych błędach rozszerzeń, ale nie pojawia się w każdej awarii. Brak wiadomości nie oznacza, że jedynym wyjściem jest reinstalacja.

Jeśli log pokazuje Allowed memory size exhausted, sprawdź limit pamięci PHP. Nie zakładaj, że ustawienie 256 lub 512 MB naprawi każdy biały ekran. Inny fatal wymaga innego działania.

Przy braku dostępu do panelu wykorzystaj zaufany dostęp hostingu i możliwość testu na kopii. Nie twórz administratora przez przypadkowy skrypt z internetu ani nie publikuj konfiguracji strony w prośbie o pomoc.

5. WordPress nie łączy się z bazą

Error establishing a database connection nie dowodzi utraty danych. Sprawdź status hostingu i właściwy komunikat w logu. Przy awarii po migracji porównaj konfigurację z danymi operatora, upewniając się, że chodzi o właściwą domenę i bazę.

Działający phpMyAdmin może używać innego konta lub sposobu połączenia niż aplikacja. Access denied nie jest automatycznym poleceniem resetu hasła. Nie uruchamiaj też naprawy wszystkich tabel, ponieważ narzędzia mają ograniczenia zależne od silnika.

Poradnik problemów z bazą rozdziela połączenie, uprawnienia, limity i uszkodzenie tabel. Przed odtworzeniem bazy sklepu zabezpiecz nowsze zamówienia oraz inne zapisy powstałe po dacie backupu.

6. Strona działa, ale ładuje się wolno

Ustal, czy opóźnienie dotyczy odpowiedzi HTML, pobierania obrazu czy reakcji na kliknięcie. Porównuj ten sam adres i podobne warunki. Pojedynczy wynik testu nie pozwala przypisać problemu hostingowi ani konkretnej wtyczce.

Google określa dobry LCP jako maksymalnie 2,5 sekundy, a dobry INP jako maksymalnie 200 ms. Kategoria poor zaczyna się dopiero powyżej 4 sekund i 500 ms. Ocena danych użytkowników odnosi się do 75. percentyla.

Nie dokładaj automatycznie kolejnej wtyczki cache. Najpierw zmierz warstwę opóźnienia i sprawdź istniejące ustawienia. Szczegółowy przebieg znajdziesz w diagnozie wolnej strony.

7. Konflikt wtyczki lub motywu

Jeżeli problem wystąpił po aktualizacji dodatku, sprawdź changelog i błąd z tej samej czynności. Związek czasowy jest dobrym tropem, ale możliwe są zależności między rozszerzeniami. Nie usuwaj całej grupy wtyczek z działającego sklepu, aby szybciej znaleźć winnego.

Odtwórz sytuację na zabezpieczonej kopii. Zmieniaj jeden podejrzany element, zapisuj wynik i przywracaj stan wyjściowy, gdy hipoteza się nie potwierdzi. Przy rozszerzeniu zależnym od innego sprawdź ich zgodne wersje.

Po znalezieniu przyczyny wybierz poprawkę, aktualizację lub uzasadnione cofnięcie wersji. Sprawdź również funkcje, których dotyczy dana zależność. Samo zniknięcie komunikatu po wyłączeniu wtyczki nie oznacza, że strona nadal realizuje wszystkie potrzebne zadania.

8. Podejrzane przekierowania lub oznaki infekcji

Zapisz objaw, czas i adres, a następnie poinformuj hosting. Ograniczenie skutków oraz zachowanie prywatnego snapshotu powinny poprzedzać przypadkowe czyszczenie. Tryb konserwacji nie izoluje wszystkich endpointów i dodatkowych plików na serwerze.

Nie kasuj każdego pliku PHP w uploads ani wszystkich nieznanych kont na podstawie samej nazwy. Skaner jest częścią analizy, a nie dowodem czystości całej instalacji. Nadpisanie core może pozostawić inne mechanizmy utrzymywania dostępu.

Przejdź do procedury po włamaniu do WordPressa. Odtworzenie kopii musi obejmować usunięcie przyczyny wejścia, kontrolę dostępów i test wcześniejszych objawów, aby ograniczyć ryzyko nawrotu.

9. Formularz lub sklep nie wysyła wiadomości

Rozdziel trzy pytania: czy aplikacja wygenerowała wiadomość, czy przekazała ją do transportu i czy dostawca dostarczył ją odbiorcy. Potwierdzenie działania wp_mail nie jest potwierdzeniem obecności wiadomości w skrzynce.

Sprawdź ustawienia powiadomienia i dostępne logi, bez uruchamiania masowych ponowień. Przy sklepie ważny jest też status zamówienia, który powinien wyzwalać dany e-mail. Dopiero potem sprawdza się połączenie z dostawcą i uwierzytelnianie domeny.

Poradnik SMTP w WordPressie opisuje dalszą konfigurację. Test wysyłki wykonuj w kontrolowanym środowisku, bez adresów klientów. Nie zmieniaj kilku mechanizmów wysyłania jednocześnie, bo trudno będzie ustalić, który faktycznie obsługuje wiadomość.

10. Aktualizacja utknęła lub zostawiła tryb konserwacji

Sprawdź, czy proces nadal pracuje, oraz komunikat w panelu i logu. Plik .maintenance może pozostać po przerwanym zadaniu, ale jego usunięcie nie potwierdza kompletności aktualizacji. Najpierw ustal stan plików i bazy.

Dokumentacja WordPressa przypomina, że aktualizacje w tle wprowadzono w wersji 3.7. Od 5.6 nowe instalacje mają domyślnie także automatyczne główne aktualizacje core, z warunkami opisanymi w dokumentacji. Nie należy mieszać tych dwóch mechanizmów.

Przy cofnięciu wersji uwzględnij możliwe zmiany bazy. Starsze pliki nie zawsze pasują do nowszego schematu danych. Skorzystaj z poradnika aktualizacji, a po naprawie sprawdź panel i funkcje powiązanych rozszerzeń.

Jak sprawdzić naprawę i poprosić o pomoc

Wróć do dokładnej czynności, która zawiodła. Sprawdź wynik, nowy log i ważne funkcje powiązane ze zmianą. Testy zapisu, wiadomości i płatności prowadź na kopii, bez prawdziwych operacji klientów. Zachowaj informację o poprawce oraz możliwość odtworzenia poprzedniego stanu.

Jeżeli potrzebujesz pomocy, wyślij przez kontakt adres strony i opis objawu. Czas, komunikat, ostatnia zmiana i dostępność backupu są opcjonalne. Nie musisz przygotowywać pełnego briefu ani przesyłać sekretów.

Możesz zlecić naprawę WordPressa, a po rozwiązaniu awarii ustalić regularną opiekę. Zakres dalszych działań powinien wynikać z przyczyny problemu i potrzeb konkretnej witryny.

Najczęstsze pytania

Od czego zacząć, gdy WordPress przestaje działać?

Zapisz komunikat, adres i czas, a następnie sprawdź zakres awarii oraz dostęp do panelu. Zanotuj ostatnią zmianę i ustal dostępność kopii. Odczytaj prywatny log hostingu, zanim zaczniesz zmieniać konfigurację. Nie wyłączaj wszystkich wtyczek na próbę. Jeśli nie wiesz, jak przejść dalej, w pierwszym zgłoszeniu wystarczy adres strony i konkretny objaw problemu.

Co zrobić bez dostępu do wp-admin?

Sprawdź informacje operatora hostingu, prywatny log i dostępną wiadomość Recovery Mode. Ten mechanizm pomaga tylko w określonych sytuacjach, więc brak wiadomości nie rozstrzyga przyczyny. Korzystaj z zaufanego dostępu do środowiska i zabezpiecz stan przed zmianami. Nie twórz administratora przez przypadkowy skrypt ani nie publikuj danych konfiguracji. Przy braku dostępu poproś hosting o pomoc.

Czy cofnięcie aktualizacji naprawia każdą awarię?

Nie. Aktualizacja może zmienić pliki i bazę, a problem może wynikać również z zależności lub konfiguracji. Najpierw ustal przyczynę i zakres cofnięcia. Starszy backup sklepu może nadpisać nowsze zamówienia, dlatego zabezpiecz bieżące dane. Przetestuj rozwiązanie na kopii i potwierdź działanie tej samej czynności, zamiast oceniać naprawę tylko po wyglądzie strony głównej.

Jak wybrać wersję PHP dla WordPressa w 2026?

Sprawdź aktualną tabelę wsparcia PHP oraz macierz zgodności używanej wersji WordPressa. Następnie zweryfikuj motyw i rozszerzenia, bo zgodność samego core nie gwarantuje działania całej instalacji. Zmianę przetestuj na kopii z ważnymi funkcjami i logiem błędów. Nie pozostawaj bezterminowo na niewspieranej wersji tylko dlatego, że ukrywa problem starej wtyczki lub własnego kodu.

Czy błąd 500 oznacza włamanie do strony?

Nie. To ogólna informacja o błędzie serwera, która może wynikać z różnych problemów aplikacji lub konfiguracji. Dopiero log i dodatkowe objawy pomagają rozpoznać przyczynę. Przy nieautoryzowanych przekierowaniach lub kontach uruchom ścieżkę incydentu i zabezpiecz dowody. Nie kasuj plików ani nie przywracaj całej instalacji wyłącznie na podstawie samego numeru statusu odpowiedzi HTTP.

Dlaczego strona działa, a formularz lub panel nie?

Strona główna może pochodzić z cache, natomiast panel, formularz i integracja korzystają z innych żądań oraz uprawnień. Dlatego poprawne wyświetlenie jednego adresu nie potwierdza działania całości. Sprawdź dokładną nieudaną czynność, status i komunikat. Po naprawie powtórz ten sam scenariusz na kopii, bez wysyłania prawdziwych wiadomości lub wykonywania operacji na danych klientów.

Jak zgłosić problem bez przygotowania pełnego audytu?

Wystarczy adres strony i opis tego, co przestało działać. Jeśli masz czas, dopisz komunikat, moment wystąpienia, ostatnią zmianę i informację o kopii. Te szczegóły są pomocne, ale nie powinny opóźniać pierwszego kontaktu. Nie przesyłaj haseł, cookies ani pełnego wp-config.php. Potrzebny zakres dostępu można ustalić później przez odpowiedni bezpieczny kanał obsługi zgłoszenia.