100 problemów z WordPressem i jak je rozwiązać (2026)

WordPress jest wygodny, bo pozwala zbudować i rozwijać stronę bez programisty. Ta sama elastyczność sprawia jednak, że każda strona to inna kombinacja hostingu, wersji PHP, motywu i kilkunastu wtyczek, a problemy pojawiają się w różnych miejscach. Zebraliśmy 100 sytuacji, z którymi właściciele stron zgłaszają się do nas najczęściej, i przy każdej opisaliśmy najczęstszą przyczynę oraz sposób naprawy.

Lista jest podzielona na 10 grup. Szukając konkretnego objawu, użyj spisu treści albo wyszukiwania w przeglądarce (Ctrl+F). Zanim zmienisz cokolwiek na działającej stronie, zrób kopię zapasową plików i bazy danych, a większe zmiany testuj na kopii strony (środowisku testowym).

Awarie i błędy krytyczne

Gdy strona przestaje działać, liczy się kolejność: najpierw przywrócić działanie, potem znaleźć przyczynę, żeby awaria nie wróciła.

1. Na stronie pojawia się „błąd krytyczny” albo biały ekran

Najczęściej przyczyną jest wtyczka lub motyw, który po aktualizacji przestał być zgodny z wersją PHP albo z innym dodatkiem, a naprawa polega na wyłączeniu winowajcy i sprawdzeniu dziennika błędów. Od wersji 5.2 WordPress wysyła na adres administratora maila z nazwą wtyczki i linkiem do trybu odzyskiwania.

Rozwiązanie: Zaloguj się linkiem z maila albo zmień przez FTP nazwę folderu podejrzanej wtyczki w wp-content/plugins. Włącz WP_DEBUG_LOG w wp-config.php i przeczytaj wp-content/debug.log, który wskaże plik i linię błędu. Szczegóły i naprawa krok po kroku.

2. Komunikat „Błąd podczas nawiązywania połączenia z bazą danych”

WordPress nie może połączyć się z bazą MySQL, bo dane w wp-config.php są niepoprawne, serwer bazy danych nie działa albo tabele są uszkodzone. Komunikat często pojawia się po przeniesieniu strony, zmianie hasła do bazy albo przy przeciążeniu hostingu.

Rozwiązanie: Porównaj DB_NAME, DB_USER, DB_PASSWORD i DB_HOST w wp-config.php z danymi w panelu hostingu. Jeśli się zgadzają, sprawdź, czy serwer MySQL działa, a uszkodzone tabele napraw przez phpMyAdmin albo WP_ALLOW_REPAIR. Szczegóły i naprawa krok po kroku.

3. Błąd 500 Internal Server Error

Najczęstsze przyczyny błędu 500 to uszkodzony plik .htaccess, przekroczony limit pamięci PHP albo błąd w kodzie wtyczki. Serwer nie mówi wprost, co się stało, więc odpowiedzi trzeba szukać w dzienniku błędów.

Rozwiązanie: Zmień nazwę pliku .htaccess i wygeneruj nowy, zapisując bezpośrednie odnośniki w Ustawieniach. Jeśli to nie pomaga, przeczytaj error_log w panelu hostingu, podnieś limit pamięci i wyłącz wtyczki, zmieniając nazwę folderu plugins.

4. Strona główna działa, a podstrony pokazują błąd 404

To prawie zawsze problem z regułami przepisywania adresów: brakuje pliku .htaccess, jest pusty albo serwer nie obsługuje mod_rewrite. Zdarza się to po migracji na nowy serwer lub po zmianie struktury bezpośrednich odnośników.

Rozwiązanie: Wejdź w Ustawienia, Bezpośrednie odnośniki i kliknij Zapisz zmiany bez niczego zmieniając, co odtworzy reguły. Na serwerze Nginx reguły trzeba dodać w konfiguracji serwera, bo Nginx nie czyta pliku .htaccess.

5. Strona utknęła w komunikacie o zaplanowanych pracach konserwacyjnych

Aktualizacja została przerwana, a WordPress nie usunął pliku .maintenance z głównego katalogu strony. Ten plik powstaje na czas aktualizacji i powinien zniknąć sam po jej zakończeniu.

Rozwiązanie: Usuń plik .maintenance przez FTP lub menedżer plików hostingu, a potem sprawdź, czy przerwana aktualizacja wtyczki lub rdzenia się zakończyła. Jeśli nie, powtórz ją pojedynczo, a nie wszystkie aktualizacje naraz.

6. Błąd „Allowed memory size exhausted”

Skrypt potrzebował więcej pamięci, niż pozwala limit PHP; zwykle winna jest ciężka wtyczka, page builder albo import dużego pliku. Komunikat podaje plik, który przekroczył limit, co pomaga znaleźć źródło problemu.

Rozwiązanie: Podnieś limit stałą WP_MEMORY_LIMIT w wp-config.php oraz memory_limit w ustawieniach PHP w panelu hostingu (np. do 256 MB). Jeśli limit ciągle jest za mały, szukaj wtyczki, która zużywa pamięć, zamiast podnosić go bez końca.

7. Błąd 403 Forbidden przy wejściu na stronę lub do panelu

Serwer odmawia dostępu zwykle przez złe uprawnienia plików, regułę w .htaccess albo zaporę (WAF) wtyczki bezpieczeństwa lub hostingu, która uznała Twoje żądanie za atak. Częsty przypadek to zablokowany adres IP po kilku nieudanych logowaniach.

Rozwiązanie: Sprawdź uprawnienia (foldery 755, pliki 644), przejrzyj .htaccess pod kątem reguł blokujących i dziennik zapory. Jeśli blokada wynika z WAF, dodaj wyjątek albo poproś obsługę hostingu o odblokowanie adresu IP.

8. Błędy 502, 503 lub 504 i strona działa tylko czasami

Serwer nie nadąża z odpowiedzią: procesy PHP są zajęte, skrypt działa za długo albo hosting ogranicza zasoby. Błędy pojawiają się zwykle przy większym ruchu, wizytach agresywnych botów albo ciężkich zadaniach w tle.

Rozwiązanie: Sprawdź w panelu hostingu wykorzystanie CPU i procesów, zablokuj niepotrzebne boty i włącz cache stron. Jeśli limity są przekraczane regularnie, potrzebujesz mocniejszego planu albo optymalizacji wtyczek wykonujących ciężkie zapytania.

9. Strona wyświetla się bez stylów, jako sam tekst

Przeglądarka nie może pobrać plików CSS, najczęściej przez zły adres witryny (http zamiast https, stara domena) albo przez wtyczkę optymalizacyjną, która błędnie połączyła pliki. Po migracji to jeden z typowych objawów.

Rozwiązanie: Sprawdź w Ustawieniach ogólnych Adres WordPressa i Adres witryny, wyczyść cache wtyczki i CDN, a w konsoli przeglądarki (F12) zobacz, które pliki zwracają błąd. Jeśli winna jest optymalizacja, wyłącz łączenie plików CSS.

10. Nie mogę zalogować się do panelu WordPressa

Najczęściej to zapomniane hasło, wtyczka bezpieczeństwa blokująca logowanie albo zmieniony adres witryny, przez który logowanie przekierowuje w kółko. Gdy nie działa też reset hasła, problemem jest zwykle wysyłka maili.

Rozwiązanie: Skorzystaj z opcji „Nie pamiętasz hasła?”, a gdy mail nie dochodzi, zmień hasło przez phpMyAdmin albo WP-CLI. Przy pętli logowania wyczyść ciasteczka i sprawdź adresy witryny w tabeli wp_options lub w wp-config.php.

Aktualizacje WordPressa, wtyczek i motywów

Aktualizacje łatają luki bezpieczeństwa, ale robione bez przygotowania są też najczęstszym powodem awarii.

11. Czy aktualizować WordPressa, skoro strona działa?

Tak, bo aktualizacje łatają znane luki bezpieczeństwa, a boty automatycznie szukają stron z nieaktualnymi wtyczkami i motywami. Strona, która „działa”, może być podatna na atak od miesięcy, zanim ktokolwiek to zauważy.

Rozwiązanie: Ustal stały rytm, np. co tydzień: kopia zapasowa, aktualizacja na kopii testowej, sprawdzenie najważniejszych stron i formularzy, aktualizacja na produkcji. Poprawki bezpieczeństwa instaluj od razu po wydaniu.

12. Strona przestała działać po aktualizacji wtyczki

Nowa wersja wtyczki jest niezgodna z motywem, inną wtyczką albo wersją PHP, a naprawa polega na cofnięciu jej do poprzedniej wersji. Błąd warto zgłosić autorowi, bo zwykle szybko wydaje poprawkę.

Rozwiązanie: Wyłącz wtyczkę w trybie odzyskiwania lub przez FTP, przywróć poprzednią wersję z kopii albo z archiwum wersji na wordpress.org i powtórz aktualizację po wydaniu poprawki. Dziennik błędów pokaże, z czym wtyczka koliduje.

13. Aktualizacja nie powiodła się albo trwa w nieskończoność

Typowe przyczyny to brak uprawnień do zapisu plików, za mało miejsca na serwerze, limit czasu wykonania PHP lub zablokowane połączenie serwera z wordpress.org. WordPress nie może wtedy pobrać albo rozpakować paczki.

Rozwiązanie: Sprawdź wolne miejsce i uprawnienia folderu wp-content, usuń plik .maintenance, jeśli został, i powtórz aktualizację pojedynczo. W ostateczności zaktualizuj ręcznie, wgrywając pliki przez FTP zgodnie z dokumentacją WordPressa.

14. Czy włączyć automatyczne aktualizacje?

Dla wydań bezpieczeństwa rdzenia tak, i WordPress domyślnie instaluje je sam; dla wtyczek automat ma sens tylko przy kopiach zapasowych i monitoringu, który wykryje awarię. Bez nadzoru automatyczna aktualizacja może zepsuć stronę w nocy i nikt tego nie zauważy.

Rozwiązanie: Zostaw automatyczne aktualizacje bezpieczeństwa rdzenia, włącz je dla prostych, sprawdzonych wtyczek, a duże dodatki (page builder, sklep, formularze) aktualizuj ręcznie po teście. Dodaj monitoring dostępności z powiadomieniem.

15. Wtyczka nie była aktualizowana od lat

Porzucona wtyczka nie dostaje poprawek bezpieczeństwa i z czasem traci zgodność z nowym PHP i WordPressem. Wtyczki zamknięte w katalogu wordpress.org, np. z powodu niezałatanej luki, nie są już dostępne do pobrania.

Rozwiązanie: Sprawdź na stronie wtyczki datę ostatniej aktualizacji i zgodność z wersją WordPressa. Znajdź aktywnie rozwijany zamiennik albo zastąp funkcję prostym kodem, a przed zmianą zrób kopię i test na kopii strony.

16. Motyw premium nie pokazuje aktualizacji

Motywy kupione poza katalogiem wordpress.org aktualizują się tylko z aktywną licencją i kluczem wpisanym w panelu, a często nikt go nie wpisał albo licencja wygasła. W efekcie strona latami działa na starej wersji motywu.

Rozwiązanie: Odszukaj konto, na którym kupiono motyw, odnów licencję i wpisz klucz w ustawieniach motywu. Jeśli motyw nie jest już rozwijany, zaplanuj przejście na inny, zamiast utrzymywać przestarzały kod.

17. Zmiany w motywie znikają po aktualizacji

Ktoś edytował pliki motywu bezpośrednio, a aktualizacja nadpisała je nową wersją. Własne zmiany w kodzie trzeba trzymać w motywie potomnym (child theme) albo we własnej wtyczce.

Rozwiązanie: Odtwórz zmiany z kopii zapasowej i przenieś je do motywu potomnego, a style do pola Dodatkowy CSS albo pliku motywu potomnego. Od tej chwili aktualizacja motywu nadrzędnego nie usunie Twoich poprawek.

18. Układ strony rozjechał się po aktualizacji page buildera

Page buildery (np. Elementor, WPBakery, Divi) przy dużych wersjach zmieniają sposób generowania kodu, a zapisane wcześniej pliki CSS nie pasują do nowej wersji. Często wystarczy wygenerować style na nowo.

Rozwiązanie: Wyczyść cache buildera (regenerację plików CSS w jego ustawieniach), cache wtyczki i CDN. Jeśli układ dalej jest zły, przywróć poprzednią wersję i zaktualizuj buildera razem z jego dodatkami na kopii testowej.

19. Nie ma gdzie testować aktualizacji

Bez kopii testowej (stagingu) każda aktualizacja jest sprawdzana na żywej stronie, na oczach klientów. Wiele hostingów udostępnia staging jednym kliknięciem w panelu. Na kopii testowej możesz też bez ryzyka sprawdzić zmianę wersji PHP i nowe wtyczki.

Rozwiązanie: Utwórz kopię testową w panelu hostingu albo wtyczką do klonowania, zabezpiecz ją hasłem i zablokuj indeksowanie. Tam sprawdzaj aktualizacje i zmiany, a na produkcję przenoś tylko to, co działa.

20. Po aktualizacji edytor wygląda zupełnie inaczej

Od wersji 5.0 domyślnym edytorem WordPressa jest edytor blokowy (Gutenberg), a kolejne wersje rozwijają edycję całej witryny. Starsze strony mogą dalej korzystać z klasycznego edytora przez oficjalną wtyczkę Classic Editor.

Rozwiązanie: Zdecyduj, czy przechodzisz na bloki, czy zostajesz przy klasycznym edytorze, i trzymaj się jednej metody w całej stronie. Przy przejściu konwertuj stare wpisy stopniowo i sprawdzaj ich wygląd po konwersji.

Kopie zapasowe i przywracanie strony

Kopia zapasowa jest warta tyle, ile da się z niej odtworzyć działającą stronę.

21. Strona nie ma żadnej kopii zapasowej

To najpoważniejsze zaniedbanie, bo przy włamaniu, awarii serwera albo nieudanej aktualizacji nie ma do czego wrócić. Pełna kopia to zawsze dwa elementy: pliki (zwłaszcza folder wp-content) i baza danych.

Rozwiązanie: Zrób dziś ręczną kopię plików i bazy, a potem ustaw automatyczne kopie (wtyczką lub po stronie hostingu) przechowywane poza serwerem strony. Zapisz, gdzie są kopie i kto ma do nich dostęp.

22. Kopie są zapisywane na tym samym serwerze co strona

Jeśli serwer ulegnie awarii, zostanie zainfekowany albo hosting zawiesi konto, stracisz stronę i kopie jednocześnie. Kopia musi leżeć w innym miejscu niż oryginał.

Rozwiązanie: Ustaw wysyłkę kopii do zewnętrznego magazynu (chmura, osobny serwer) i przechowuj kilka wersji z różnych dni. Dostęp do magazynu zabezpiecz innym hasłem niż panel strony i włącz dla niego logowanie dwuskładnikowe.

23. Kopia nie zawiera bazy danych albo zdjęć

Niektóre wtyczki domyślnie kopiują tylko bazę, inne tylko pliki, a duży folder uploads bywa wyłączany z powodu limitów. Bez bazy nie ma treści, bez uploads nie ma zdjęć i dokumentów.

Rozwiązanie: Sprawdź w ustawieniach kopii, czy obejmuje bazę oraz cały wp-content (wtyczki, motywy, uploads). Pobierz jedną kopię i upewnij się, że zawiera plik .sql i foldery z mediami.

24. Kopia istnieje, ale nie da się z niej odtworzyć strony

Kopie, których nikt nigdy nie testował, często okazują się niekompletne, uszkodzone albo zapisane w formacie, którego nie da się łatwo przywrócić. Zwykle wychodzi to na jaw w najgorszym momencie, czyli podczas awarii.

Rozwiązanie: Raz na kwartał przywróć kopię na serwerze testowym i sprawdź, czy strona działa. Spisz procedurę przywracania krok po kroku, żeby w razie awarii nie zgadywać.

25. Wtyczka kopii zapasowych przerywa pracę albo spowalnia stronę

Na hostingu współdzielonym kopia dużej strony przekracza limit czasu lub pamięci PHP, a w trakcie jej tworzenia strona działa wolniej. Problem rośnie razem z folderem uploads.

Rozwiązanie: Planuj kopie w nocy, dziel je na części albo używaj kopii przyrostowych. Najlepiej korzystać z kopii po stronie serwera (hosting lub skrypt w cronie), które nie obciążają WordPressa.

26. Jak często robić kopię zapasową strony?

Tak często, jak dużo danych możesz stracić bez szkody: strona wizytówka zmieniana raz w miesiącu wystarczy z kopią tygodniową, a sklep czy strona z formularzami potrzebuje codziennej kopii bazy. Zawsze rób też kopię przed aktualizacją.

Rozwiązanie: Ustal częstotliwość osobno dla bazy (zmienia się często) i plików (rzadziej), przechowuj kilka ostatnich wersji i ustaw powiadomienie, gdy kopia się nie wykona.

27. Hosting robi kopie, czy to wystarczy?

Kopie hostingu są dobrym uzupełnieniem, ale nie powinny być jedyne: zwykle obejmują kilka ostatnich dni, leżą w infrastrukturze tego samego dostawcy, a przywrócenie bywa dodatkowo płatne albo wymaga zgłoszenia. Warunki znajdziesz w regulaminie usługi.

Rozwiązanie: Sprawdź, jak długo hosting przechowuje kopie i jak je przywrócić, a dodatkowo prowadź własne kopie w niezależnym miejscu. Dwie niezależne kopie to bezpieczne minimum.

28. Trzeba przywrócić tylko jeden wpis albo samą bazę

Nie musisz przywracać całej strony, żeby odzyskać skasowaną treść. Usunięte wpisy często są jeszcze w koszu, a starsze wersje treści w rewizjach.

Rozwiązanie: Sprawdź najpierw kosz i rewizje wpisu. Jeśli treść zniknęła na dobre, odtwórz kopię bazy na kopii testowej i przenieś z niej wpis eksportem, zamiast nadpisywać całą bazę produkcyjną i tracić nowsze dane.

29. Kopie zawierają dane osobowe klientów

Baza strony z formularzami lub sklepem zawiera dane osobowe, więc kopie podlegają tym samym zasadom RODO co sama strona: zabezpieczeniu, ograniczonemu dostępowi i określonemu czasowi przechowywania. Dotyczy to zarówno kopii robionych przez wtyczkę, jak i tych przechowywanych przez hosting.

Rozwiązanie: Przechowuj kopie w zaszyfrowanym miejscu, u dostawcy, z którym masz umowę powierzenia danych, ustaw automatyczne usuwanie starych kopii i opisz ten proces w dokumentacji ochrony danych.

30. Po przywróceniu kopii brakuje zdjęć albo linki prowadzą do starej domeny

Kopię przywrócono pod innym adresem, a w bazie zostały stare adresy, albo kopia nie obejmowała folderu uploads. WordPress zapisuje pełne adresy plików w treściach i ustawieniach.

Rozwiązanie: Sprawdź, czy folder wp-content/uploads zawiera pliki, a stare adresy zamień narzędziem obsługującym dane serializowane (np. WP-CLI search-replace). Zwykła zamiana tekstu w pliku SQL może uszkodzić ustawienia wtyczek i widżetów.

Bezpieczeństwo i włamania

Większość ataków na WordPressa jest zautomatyzowana: boty szukają znanych luk i słabych haseł, a nie konkretnej firmy.

31. Strona została zhakowana, co robić?

Najpierw odetnij atakującego: zmień wszystkie hasła (panel, FTP, baza, hosting), włącz tryb konserwacji i zrób kopię zainfekowanego stanu do analizy. Dopiero potem czyść pliki albo przywracaj czystą kopię sprzed włamania.

Rozwiązanie: Przywróć kopię sprzed infekcji albo podmień rdzeń, wtyczki i motywy na czyste wersje, usuń nieznane pliki i konta, zaktualizuj wszystko i zamknij lukę, przez którą weszło włamanie. Pełną procedurę opisaliśmy w poradniku WordPress zhakowany - 7 kroków do odzyskania strony.

32. Strona przekierowuje odwiedzających na podejrzane witryny

To typowy objaw infekcji: złośliwy kod w plikach motywu, .htaccess albo w bazie danych przekierowuje część odwiedzających, często tylko z telefonów lub z wyników Google, żeby administrator tego nie zauważył.

Rozwiązanie: Sprawdź .htaccess, index.php, functions.php motywu oraz opcje siteurl i home w bazie, a potem przeskanuj stronę skanerem złośliwego kodu. Traktuj sprawę jak pełne włamanie (problem 31), bo samo usunięcie przekierowania zwykle nie usuwa tylnych drzwi.

33. W Google pojawiają się obce podstrony ze spamem, np. po japońsku

Atakujący utworzył na Twojej domenie strony ze spamem, często widoczne tylko dla Googlebota. Taka infekcja wymaga zarówno wyczyszczenia strony, jak i usunięcia spamerskich adresów z indeksu.

Rozwiązanie: Wyczyść stronę jak po włamaniu, upewnij się, że spamerskie adresy zwracają 404 lub 410, i sprawdź raport problemów bezpieczeństwa w Search Console. Usuń nieznanych właścicieli usługi w Search Console i prześlij mapę witryny ponownie.

34. Tysiące prób logowania do wp-login.php

Boty próbują zgadywać hasła (atak brute force) na praktycznie każdej stronie WordPress, więc samo zjawisko jest normalne; groźne staje się przy słabym haśle. Takie ataki dodatkowo obciążają serwer.

Rozwiązanie: Ustaw silne, unikalne hasła, włącz uwierzytelnianie dwuskładnikowe dla administratorów i ogranicz liczbę prób logowania. Jeśli strona nie używa XML-RPC, zablokuj go, a ruch botów filtruj zaporą aplikacyjną (WAF).

35. Administrator ma login „admin” i proste hasło

Login „admin” to pierwsze, co sprawdzają boty, a hasło używane w kilku serwisach może wyciec z któregoś z nich. Konto administratora daje pełną kontrolę nad stroną i możliwość instalowania kodu.

Rozwiązanie: Utwórz nowe konto administratora z unikalną nazwą, przypisz mu treści i usuń stare. Hasła trzymaj w menedżerze haseł, a każdej osobie daj osobne konto z najniższą potrzebną rolą (np. Redaktor, Autor).

36. Motyw lub wtyczka z nieoficjalnego źródła (tzw. nulled)

Płatne dodatki pobrane za darmo z nieoficjalnych stron często zawierają tylne drzwi lub ukryte linki i nie dostają aktualizacji. To jedna z typowych dróg infekcji stron WordPress.

Rozwiązanie: Usuń taki dodatek i zainstaluj oryginał z oficjalnego źródła z licencją. Po usunięciu przeskanuj całą stronę, bo kod mógł już zostawić złośliwe pliki w innych miejscach.

37. W folderze uploads są pliki PHP

Folder na zdjęcia i dokumenty nie powinien zawierać plików wykonywalnych, więc plik .php w wp-content/uploads to niemal zawsze ślad włamania. Atakujący zostawiają tam skrypty, które dają im dostęp do serwera.

Rozwiązanie: Skopiuj podejrzane pliki do analizy i usuń je ze strony, zablokuj wykonywanie PHP w folderze uploads regułą serwera i przejrzyj stronę pod kątem innych śladów infekcji.

38. Google lub przeglądarka ostrzega, że strona jest niebezpieczna

Mechanizm Bezpieczne przeglądanie Google wykrył na stronie złośliwe oprogramowanie, phishing lub szkodliwe pliki do pobrania. Czerwone ostrzeżenie skutecznie odstrasza odwiedzających, dopóki go nie usuniesz. Google może też ograniczyć widoczność takiej strony w wynikach wyszukiwania.

Rozwiązanie: Sprawdź raport Problemy dotyczące bezpieczeństwa w Search Console, wyczyść stronę i dopiero wtedy poproś o weryfikację. Prośba złożona przed usunięciem przyczyny zostanie odrzucona i wydłuży czas oczekiwania.

39. W panelu są konta administratorów, których nikt nie zna

Nieznane konto administratora to sygnał włamania albo pozostałość po byłych wykonawcach, a w obu przypadkach otwarta furtka do strony. Atakujący często nadają takim kontom nazwy przypominające prawdziwego użytkownika lub wtyczkę.

Rozwiązanie: Usuń nieznane konta (treści przypisz istniejącemu użytkownikowi), zmień hasła pozostałych i wygeneruj nowe klucze bezpieczeństwa w wp-config.php, co wyloguje wszystkie sesje. Następnie sprawdź stronę tak jak po włamaniu.

40. Czy wtyczka bezpieczeństwa wystarczy?

Nie. Wtyczka pomaga (zapora, skaner, limit logowań), ale nie zastąpi aktualizacji, kopii zapasowych poza serwerem, silnych haseł i dobrego hostingu. Kilka wtyczek bezpieczeństwa naraz często się wzajemnie blokuje i spowalnia stronę.

Rozwiązanie: Używaj jednej wtyczki bezpieczeństwa i połącz ją z regularnymi aktualizacjami, kopiami poza serwerem, logowaniem dwuskładnikowym i monitoringiem. Pełną listę zaleceń zawiera oficjalny przewodnik po zabezpieczaniu WordPressa (hardening).

Wtyczki i motywy

Wtyczki dają WordPressowi elastyczność, ale każda kolejna to dodatkowy kod, który trzeba utrzymywać i aktualizować.

41. Jak znaleźć wtyczkę, która psuje stronę?

Najszybciej metodą wyłączania: dezaktywujesz wszystkie wtyczki, a potem włączasz je po kolei, aż problem wróci. Wtyczka Health Check & Troubleshooting pozwala zrobić to tylko dla siebie, bez wpływu na odwiedzających.

Rozwiązanie: Zrób kopię, włącz tryb rozwiązywania problemów w Narzędzia, Zdrowie witryny, przełącz motyw na domyślny i włączaj wtyczki pojedynczo. Gdy znajdziesz parę, która się gryzie, zgłoś to autorom albo wymień jedną z nich.

42. Na stronie jest kilkadziesiąt wtyczek

Sama liczba wtyczek nie jest problemem, problemem są wtyczki zbędne, ciężkie, dublujące się albo porzucone. Każda z nich zwiększa ryzyko konfliktu i luki bezpieczeństwa.

Rozwiązanie: Zrób listę wtyczek z opisem, do czego służą, usuń nieaktywne i zbędne, połącz dublujące się funkcje i zastąp drobne wtyczki prostym kodem w motywie potomnym. Usuwaj je po jednej i za każdym razem sprawdzaj stronę.

43. Jedna wtyczka bardzo spowalnia stronę

Wtyczki, które wykonują dużo zapytań do bazy, ładują skrypty na każdej podstronie albo uruchamiają zadania w tle, potrafią spowolnić całą witrynę. Winowajcę widać w narzędziach do profilowania.

Rozwiązanie: Zainstaluj na chwilę wtyczkę Query Monitor i sprawdź, która wtyczka generuje najwięcej zapytań i czasu. Ogranicz ładowanie jej skryptów do stron, gdzie jest potrzebna, albo znajdź lżejszy zamiennik.

44. Po usunięciu wtyczki w bazie zostały jej dane

Wiele wtyczek przy usuwaniu zostawia tabele i opcje w bazie, w tym opcje ładowane automatycznie przy każdym wejściu na stronę. Z czasem baza rośnie i spowalnia witrynę.

Rozwiązanie: Przed usunięciem sprawdź w ustawieniach wtyczki opcję usuwania danych. Stare tabele i opcje kasuj ostrożnie, po kopii bazy, sprawdzając prefiks i nazwę wtyczki, do której należą.

45. Shortcode wyświetla się jako tekst w nawiasach kwadratowych

Wtyczka lub motyw, który obsługiwał shortcode, został wyłączony albo usunięty, więc WordPress pokazuje jego surowy zapis. Zdarza się to najczęściej po zmianie motywu lub page buildera. Sam shortcode nie psuje działania strony, ale szpeci treść i ukrywa funkcję, która miała się w tym miejscu wyświetlać.

Rozwiązanie: Przywróć wtyczkę albo zastąp shortcode blokiem lub nową funkcją. Przy wielu wystąpieniach znajdź je wyszukiwaniem w bazie i zamień hurtowo, po wcześniejszej kopii zapasowej.

46. Formularz kontaktowy nie wysyła wiadomości

Formularz zwykle działa poprawnie, a zawodzi wysyłka maili z serwera: wiadomości są odrzucane albo trafiają do spamu. Rzadziej winny jest błąd JavaScript lub zabezpieczenie antyspamowe blokujące wysyłkę. Objaw wygląda tak samo: klient widzi podziękowanie, a do skrzynki nic nie trafia.

Rozwiązanie: Skonfiguruj wysyłkę przez SMTP i sprawdź rekordy SPF, DKIM i DMARC (problemy 71-73). Włącz zapisywanie zgłoszeń w bazie, żeby żadne zapytanie nie zginęło nawet przy awarii poczty.

47. Wtyczka premium przestała się aktualizować po wygaśnięciu licencji

Większość wtyczek premium działa dalej bez licencji, ale nie dostaje aktualizacji ani wsparcia, a niektóre wyłączają część funkcji. Brak aktualizacji z czasem staje się ryzykiem bezpieczeństwa.

Rozwiązanie: Zbierz w jednym miejscu listę licencji z datami odnowienia i kontem, na które je kupiono. Odnawiaj licencje wtyczek krytycznych dla strony, a niepotrzebne zastąp darmowymi odpowiednikami.

48. Edycja pliku motywu w panelu zablokowała stronę

Wbudowany edytor plików pozwala zapisać kod z błędem składni, który od razu wyłącza stronę. Od wersji 4.9 WordPress próbuje cofnąć zmianę powodującą błąd krytyczny, ale nie zawsze się to udaje.

Rozwiązanie: Popraw plik przez FTP lub menedżer plików hostingu, przywracając go z kopii. Na przyszłość wyłącz edytor plików stałą DISALLOW_FILE_EDIT w wp-config.php i wprowadzaj zmiany w motywie potomnym na kopii testowej.

49. Page builder sprawia, że strona jest ciężka

Page buildery generują dużo dodatkowego kodu HTML, CSS i JavaScript, co pogarsza szybkość, zwłaszcza na telefonach. Nie zawsze trzeba z nich rezygnować, często wystarczy je odchudzić. Na stronach z dużą liczbą sekcji i animacji różnica bywa wyraźna już w PageSpeed Insights.

Rozwiązanie: Wyłącz nieużywane widżety i moduły buildera, włącz jego wbudowane optymalizacje i ogranicz animacje. Przy przebudowie strony rozważ lekki motyw z edytorem blokowym zamiast ciężkiego buildera.

50. Motyw jest porzucony przez autora

Motyw bez aktualizacji z czasem traci zgodność z PHP i WordPressem, a luki w nim nie zostaną załatane. Im dłużej zwlekasz ze zmianą, tym trudniej ją przeprowadzić.

Rozwiązanie: Sprawdź, ile funkcji strony zależy od motywu (shortcode, własne typy treści, ustawienia). Zaplanuj przejście na nowy motyw na kopii testowej, przenosząc funkcje do wtyczek, żeby kolejna zmiana wyglądu była prostsza.

PHP, serwer i hosting

Wiele „błędów WordPressa” to w rzeczywistości ograniczenia albo ustawienia serwera.

51. WordPress ostrzega o przestarzałej wersji PHP

Narzędzie Zdrowie witryny pokazuje ostrzeżenie, gdy wersja PHP nie jest już wspierana; stare PHP nie dostaje poprawek bezpieczeństwa, a nowe wtyczki przestają z nim działać. Aktualne zalecenia podaje strona wymagań na wordpress.org.

Rozwiązanie: Sprawdź zgodność motywu i wtyczek, a potem przełącz PHP w panelu hostingu na wspieraną wersję 8.x, najpierw na kopii testowej, a po teście na stronie produkcyjnej.

52. Strona przestała działać po zmianie wersji PHP

Stary motyw lub wtyczka używa funkcji usuniętych w nowszym PHP, co kończy się błędem krytycznym. Najszybciej przywrócić poprzednią wersję PHP, a potem spokojnie naprawić kod.

Rozwiązanie: Przywróć poprzednią wersję PHP w panelu hostingu, sprawdź dziennik błędów, który wskaże niezgodny plik, i zaktualizuj albo wymień ten dodatek. Zgodność kodu możesz sprawdzić narzędziem PHPCompatibility na kopii strony.

53. Import lub kopia przerywa się z powodu limitu czasu

PHP ma limit czasu wykonania skryptu (max_execution_time), po którym przerywa długie operacje: import, generowanie miniatur, kopie zapasowe. Komunikat „Maximum execution time exceeded” wskazuje właśnie ten limit. Na hostingu współdzielonym limit bywa ustawiony nisko i nie zawsze można go zmienić.

Rozwiązanie: Podnieś max_execution_time w ustawieniach PHP hostingu, a ciężkie zadania uruchamiaj przez WP-CLI, gdzie limity czasu zwykle nie obowiązują. Duże importy dziel na mniejsze pliki.

54. Nie mogę wgrać pliku, bo przekracza maksymalny rozmiar

Limit ustawia serwer (upload_max_filesize i post_max_size w PHP), a nie WordPress. Na tańszych hostingach bywa ustawiony nisko. Ten sam limit blokuje też import dużych plików, np. kopii bazy przez wtyczkę.

Rozwiązanie: Podnieś oba limity w ustawieniach PHP w panelu hostingu, pamiętając, że post_max_size musi być większy lub równy upload_max_filesize. Duże pliki, np. wideo, lepiej trzymać w zewnętrznym serwisie i osadzać na stronie.

55. Hosting spowalnia lub wyłącza stronę za przekroczenie limitów

Plan hostingu ma limity CPU, pamięci lub procesów, a strona je przekracza przez ruch botów, ciężkie wtyczki albo brak cache. Hosting w odpowiedzi ogranicza zasoby lub czasowo blokuje konto.

Rozwiązanie: Sprawdź w panelu, kiedy limity są przekraczane, i porównaj to z logami dostępu. Zablokuj agresywne boty, włącz cache stron i obiektów, a jeśli strona po prostu urosła, przejdź na mocniejszy plan.

56. Dostęp do hostingu i domeny ma tylko były wykonawca

Domena i hosting zarejestrowane na wykonawcę to ryzyko: bez dostępu nie zmienisz serwera, nie odnowisz domeny i nie naprawisz awarii. Abonentem domeny powinna być Twoja firma.

Rozwiązanie: Poproś o przekazanie domeny (kod transferu, tzw. AuthInfo) i dostępów do hostingu na konto firmy. Zrób listę wszystkich dostępów (domena, hosting, FTP, panel WordPress, Search Console, Analytics) i przechowuj ją w menedżerze haseł.

57. Zaplanowane wpisy się nie publikują, a zadania nie wykonują

WP-Cron uruchamia zadania tylko przy wejściu na stronę, więc gdy ruch jest mały albo cache zwraca strony bez udziału WordPressa, zadania się opóźniają. Wpisy zostają wtedy z błędem pominiętego harmonogramu.

Rozwiązanie: Wyłącz WP-Cron stałą DISABLE_WP_CRON w wp-config.php i ustaw prawdziwe zadanie cron na serwerze, które co kilka minut wywołuje wp-cron.php. Listę zadań podejrzysz wtyczką WP Crontrol.

58. Gdzie szukać przyczyny błędu, skoro strona nic nie mówi?

W dzienniku błędów: WordPress zapisuje je do pliku wp-content/debug.log po włączeniu WP_DEBUG i WP_DEBUG_LOG, a serwer prowadzi własny error_log dostępny w panelu hostingu. Tam znajdziesz plik i linię, która spowodowała awarię.

Rozwiązanie: W wp-config.php ustaw WP_DEBUG i WP_DEBUG_LOG na true, a WP_DEBUG_DISPLAY na false, żeby błędy nie były widoczne dla odwiedzających. Po diagnozie wyłącz logowanie i usuń plik, bo może zawierać ścieżki serwera.

59. Na serwerze skończyło się miejsce

Miejsce zajmują zwykle stare kopie zapasowe na serwerze, logi, nieużywane miniatury i pliki cache. Przy pełnym dysku przestają działać aktualizacje, wgrywanie plików, a nawet baza danych. Problem narasta niezauważony, bo wiele paneli hostingu nie ostrzega o kończącym się miejscu.

Rozwiązanie: Sprawdź w panelu, które foldery są największe, przenieś stare kopie poza serwer i usuń je, wyczyść logi i cache. Wyłącz zbędne rozmiary miniatur, a obrazy kompresuj przy wgrywaniu.

60. Po zmianie treści odwiedzający widzą starą wersję strony

Stronę zwraca cache serwera, wtyczki albo CDN, który nie został wyczyszczony po zmianie. Przy kilku warstwach cache trzeba wyczyścić każdą z nich. Najczęściej dotyczy to zmian w menu, cenach, godzinach pracy i plikach CSS.

Rozwiązanie: Ustal, jakie warstwy cache działają (wtyczka, serwer, CDN, przeglądarka), i włącz automatyczne czyszczenie po publikacji. Przy zmianach CSS i JS dodawaj numer wersji do plików, żeby przeglądarki pobrały nowe.

SSL, domena i DNS

Problemy z certyfikatem i domeną wyłączają stronę dla wszystkich odwiedzających naraz, dlatego warto je monitorować.

61. Przeglądarka pokazuje „Połączenie nie jest prywatne”

Certyfikat SSL wygasł, nie obejmuje adresu, pod który wchodzi odwiedzający (np. wersji z www), albo jest wystawiony dla innej domeny. Przeglądarka blokuje wtedy wejście na stronę pełnoekranowym ostrzeżeniem. Ostrzeżenie widzą wszyscy odwiedzający, a część z nich rezygnuje z wejścia na stronę.

Rozwiązanie: Sprawdź w panelu hostingu status certyfikatu i listę domen, które obejmuje. Włącz automatyczne odnawianie (np. Let's Encrypt) i dodaj monitoring, który ostrzeże przed wygaśnięciem.

62. Certyfikat SSL wygasa i nikt o tym nie wie

Certyfikaty mają ograniczoną ważność, a automatyczne odnawianie potrafi przestać działać po zmianie DNS lub serwera. O problemie dowiadujesz się wtedy od klientów. Dotyczy to zwłaszcza certyfikatów kupowanych i instalowanych ręcznie.

Rozwiązanie: Ustaw automatyczne odnawianie i monitoring, który powiadomi z wyprzedzeniem o kończącej się ważności. Po każdej zmianie DNS lub hostingu sprawdź, czy odnowienie dalej działa.

63. Kłódka w przeglądarce jest przekreślona mimo certyfikatu

Strona działa na https, ale część plików (obrazy, skrypty, czcionki) ładuje się przez http. To tzw. mieszana zawartość, którą przeglądarki blokują lub oznaczają jako niebezpieczną.

Rozwiązanie: Zamień w bazie stare adresy http na https narzędziem obsługującym dane serializowane, sprawdź ustawienia motywu i wtyczek, a pozostałe adresy znajdziesz w konsoli przeglądarki. Na koniec ustaw przekierowanie 301 z http na https.

64. Strona działa pod adresem z www i bez www jednocześnie

Dwa adresy tej samej strony to duplikaty dla Google, kłopoty z sesją logowania i czasem z certyfikatem. Strona powinna mieć jeden adres główny, a drugi powinien na niego przekierowywać.

Rozwiązanie: Wybierz jedną wersję, ustaw ją w Ustawieniach ogólnych i przekieruj drugą przekierowaniem 301 na poziomie serwera. Upewnij się, że certyfikat obejmuje obie wersje, bo przekierowanie z https zadziała dopiero po nawiązaniu bezpiecznego połączenia.

65. Po włączeniu HTTPS strona wpada w pętlę przekierowań

Komunikat o zbyt wielu przekierowaniach oznacza, że serwer i WordPress przekierowują się nawzajem, często przez CDN lub proxy, które łączy się z serwerem przez http. WordPress nie wie wtedy, że odwiedzający jest już na https.

Rozwiązanie: Zostaw jedną regułę przekierowania (w .htaccess, wtyczce albo CDN). Za proxy obsłuż w wp-config.php nagłówek X-Forwarded-Proto, a w Cloudflare ustaw tryb SSL na Full (strict) zamiast Flexible.

66. Cloudflare lub inny CDN psuje stronę albo panel

CDN może zapisywać w cache strony, które nie powinny być zapisywane (panel, koszyk, formularze), albo modyfikować skrypty. Typowe objawy to stara treść, problemy z logowaniem i niedziałające formularze.

Rozwiązanie: Wyklucz z cache wp-admin, wp-login.php, strony z formularzami i żądania zalogowanych użytkowników. Wyłącz funkcje modyfikujące JavaScript, jeśli psują stronę, i po każdej zmianie wyczyść cache CDN.

67. Domena wygasła i strona zniknęła

Domena nie została odnowiona, bo karta płatnicza wygasła, powiadomienia szły na nieaktualny adres e-mail albo domena była na koncie byłego wykonawcy. Po upływie okresu ochronnego domenę może zarejestrować ktoś inny. Razem ze stroną przestaje działać poczta w tej domenie.

Rozwiązanie: Odnów domenę natychmiast u rejestratora, włącz automatyczne odnawianie i zaktualizuj dane kontaktowe abonenta. Sprawdź też, czy domena jest zarejestrowana na Twoją firmę.

68. Po zmianie hostingu strona raz działa, a raz nie

Zmiana rekordów DNS rozchodzi się po sieci stopniowo, więc przez pewien czas część osób trafia na stary serwer, a część na nowy. Wysoka wartość TTL wydłuża ten okres.

Rozwiązanie: Przed migracją obniż TTL rekordów, w okresie przejściowym nie zmieniaj treści na żadnej z kopii i wyłącz stary serwer dopiero wtedy, gdy cały ruch trafia na nowy.

69. Jak zmienić domenę strony WordPress?

Przy zmianie domeny trzeba zaktualizować adresy w bazie, ustawić przekierowania 301 ze starej domeny na nową i zgłosić zmianę w Search Console. Bez przekierowań tracisz ruch z Google i wartość linków.

Rozwiązanie: Zamień adresy narzędziem do wyszukiwania i zamiany (np. WP-CLI search-replace), przekieruj 301 każdy stary adres na odpowiednik w nowej domenie i użyj narzędzia zmiany adresu w Search Console. Utrzymuj starą domenę i przekierowania jak najdłużej.

70. Poczta firmowa przestała działać po przeniesieniu strony

Przy zmianie hostingu lub serwerów nazw zmieniono rekordy DNS, a rekordy MX poczty nie zostały przeniesione. Strona działa, ale maile nie dochodzą. Problem często wychodzi na jaw dopiero po kilku dniach, gdy klienci zgłaszają brak odpowiedzi.

Rozwiązanie: Przed zmianą serwerów nazw zapisz wszystkie rekordy DNS (MX, SPF, DKIM, DMARC, rekordy weryfikacyjne usług) i odtwórz je u nowego dostawcy. Po zmianie wyślij testowe maile w obie strony.

Poczta i formularze

Formularz, z którego nie dochodzą wiadomości, oznacza utracone zapytania, o których nikt nie wie.

71. WordPress nie wysyła maili

Najczęstszą przyczyną jest wysyłka funkcją PHP mail() z serwera hostingu, bez uwierzytelnienia, przez co skrzynki odbiorców odrzucają wiadomości albo kierują je do spamu. Naprawa to wysyłka przez SMTP z firmowej skrzynki lub usługi transakcyjnej oraz poprawne rekordy SPF, DKIM i DMARC.

Rozwiązanie: Zainstaluj wtyczkę SMTP, połącz ją ze skrzynką w swojej domenie, wyślij mail testowy i włącz dziennik wysyłki. Szczegóły i naprawa krok po kroku.

72. Maile z formularza trafiają do spamu

Skrzynka odbiorcy nie ufa nadawcy, bo domena nie ma rekordów SPF, DKIM lub DMARC albo mail jest wysyłany z adresu w innej domenie niż serwer, z którego wychodzi. Filtry oceniają też treść wiadomości i reputację serwera.

Rozwiązanie: Ustaw w DNS rekordy SPF i DKIM dla serwera, który wysyła pocztę, oraz rekord DMARC. Wysyłaj z adresu w swojej domenie, a adres osoby z formularza wpisuj w pole Reply-To, a nie w pole nadawcy.

73. Czym są SPF, DKIM i DMARC i czy muszę je mieć?

To rekordy DNS, które potwierdzają, że dany serwer może wysyłać pocztę z Twojej domeny (SPF), że wiadomość nie została zmieniona po drodze (DKIM), i mówią, co zrobić z mailami, które nie przejdą weryfikacji (DMARC). Gmail i Yahoo wymagają uwierzytelnienia poczty od nadawców, a od wysyłających dużo wiadomości wszystkich trzech mechanizmów.

Rozwiązanie: Sprawdź rekordy domeny w narzędziu do testowania DNS, dodaj brakujące u dostawcy DNS i zacznij od DMARC w trybie monitorowania (p=none). Po analizie raportów zaostrz politykę.

74. Formularz kontaktowy zalewa spam

Boty automatycznie wypełniają formularze bez zabezpieczeń. Zbyt agresywna ochrona z kolei blokuje prawdziwych klientów, więc trzeba znaleźć równowagę. Spam w skrzynce utrudnia też wyłapanie prawdziwych zapytań od klientów.

Rozwiązanie: Włącz ukryte pole-pułapkę (honeypot) i niewidoczną weryfikację (np. reCAPTCHA v3 albo Cloudflare Turnstile), a zgłoszenia zapisuj w bazie. Co jakiś czas przeglądaj odrzucone wiadomości, żeby nie gubić prawdziwych zapytań.

75. Nie dochodzi mail z resetem hasła

To ten sam problem co z formularzami: serwer wysyła maile bez uwierzytelnienia, więc trafiają do spamu albo są odrzucane. Dodatkowo wtyczki bezpieczeństwa mogą blokować reset hasła dla niektórych kont. Bez działającego resetu hasła użytkownik, który zapomni hasła, traci dostęp do konta.

Rozwiązanie: Skonfiguruj SMTP (problem 71) i sprawdź folder spam. Gdy potrzebujesz dostępu od razu, zmień hasło przez phpMyAdmin lub WP-CLI, a potem napraw wysyłkę maili.

76. Maile ze strony przychodzą z adresu wordpress@domena

To domyślny nadawca WordPressa, gdy nikt nie ustawił innego. Taki adres często nie istnieje, co pogarsza dostarczalność i wygląda nieprofesjonalnie. Część serwerów pocztowych odrzuca wiadomości z adresów, dla których nie istnieje skrzynka.

Rozwiązanie: Ustaw nadawcę we wtyczce SMTP na istniejący adres w Twojej domenie (np. kontakt@ lub powiadomienia@) i wymuś go dla wszystkich maili wysyłanych przez stronę i wtyczki.

77. Hosting blokuje wysyłkę maili ze strony

Hostingi ograniczają liczbę maili na godzinę albo blokują wysyłkę po wykryciu spamu z konta, np. z zainfekowanej strony. Wtedy nie wychodzi żadna wiadomość, także powiadomienia o zamówieniach.

Rozwiązanie: Sprawdź w panelu hostingu limity i komunikaty o blokadzie. Przy większej liczbie maili (sklep, powiadomienia) użyj zewnętrznej usługi wysyłki transakcyjnej, a przy blokadzie za spam najpierw sprawdź, czy strona nie została zhakowana.

78. Wiadomości z formularza giną bez śladu

Wiele wtyczek formularzy domyślnie tylko wysyła mail i niczego nie zapisuje. Gdy wiadomość nie dojdzie, zapytanie przepada, a nikt nie wie, ile ich było. Nie da się też policzyć, ile zapytań faktycznie przyszło ze strony.

Rozwiązanie: Włącz zapisywanie zgłoszeń w bazie (funkcja wtyczki albo dodatek), ustaw powiadomienie na dwa adresy i raz w tygodniu porównaj zgłoszenia w bazie z wiadomościami w skrzynce.

79. Formularz przestał działać po włączeniu cache lub optymalizacji

Formularz ma jednorazowy klucz bezpieczeństwa (nonce), który zapisany w cache po pewnym czasie przestaje być ważny. Optymalizacja JavaScript może też opóźnić lub wyłączyć skrypt wysyłki.

Rozwiązanie: Wyklucz strony z formularzami z cache albo użyj wtyczki, która odświeża klucz przez AJAX. Wyklucz skrypty formularza z opóźniania i łączenia JS i przetestuj wysyłkę w oknie incognito.

80. Czy formularz kontaktowy musi mieć informację RODO?

Tak, formularz zbiera dane osobowe, więc osoba wysyłająca musi wiedzieć, kto jest administratorem danych, w jakim celu je przetwarza i gdzie znajdzie więcej informacji. Zwykle wystarcza krótka informacja przy formularzu z linkiem do polityki prywatności (to opis ogólny, nie porada prawna).

Rozwiązanie: Dodaj pod formularzem informację o administratorze i celu przetwarzania z odnośnikiem do polityki prywatności. Zbieraj tylko potrzebne pola i ustaw usuwanie starych zgłoszeń z bazy.

Szybkość i wydajność

Szybkość wpływa na wygodę odwiedzających i jest jednym z sygnałów, które bierze pod uwagę Google.

81. Strona na WordPressie działa wolno

Najczęstsze przyczyny to słaby hosting, brak cache, ciężkie obrazy i za dużo skryptów z wtyczek oraz page buildera. Zacznij od pomiaru, a nie od instalowania kolejnej wtyczki „przyspieszającej”.

Rozwiązanie: Zmierz stronę w PageSpeed Insights i sprawdź czas odpowiedzi serwera. Włącz cache stron, kompresję obrazów, aktualne PHP z OPcache i usuń zbędne skrypty; jeśli serwer odpowiada wolno mimo cache, problemem jest hosting.

82. Słaby wynik LCP

LCP mierzy, kiedy pojawia się największy element strony, a dobry wynik to do 2,5 s. Najczęściej spowalnia go duże zdjęcie w nagłówku, wolny serwer albo pliki CSS blokujące wyświetlanie. LCP mierzy się osobno dla telefonów i komputerów, a wynik mobilny jest zwykle słabszy.

Rozwiązanie: Zmniejsz i skompresuj główne zdjęcie (WebP lub AVIF), nie ładuj go leniwie, nadaj mu wysoki priorytet pobierania (fetchpriority="high") i skróć czas odpowiedzi serwera dzięki cache stron.

83. Strona wolno reaguje na kliknięcia (INP)

INP mierzy, jak szybko strona reaguje na interakcje, a dobry wynik to do 200 ms. Winne są zwykle ciężkie skrypty: page buildery, slidery, czaty, piksele reklamowe i narzędzia śledzące.

Rozwiązanie: Usuń nieużywane skrypty, ładuj czaty i widżety dopiero po interakcji, ogranicz skrypty zewnętrzne i sprawdź w zakładce Performance w Chrome, które zadania blokują główny wątek.

84. Elementy strony skaczą podczas ładowania (CLS)

CLS mierzy przesunięcia układu, a dobry wynik to do 0,1. Przesunięcia powodują obrazy i ramki bez wymiarów, późno ładowane banery na górze strony i podmieniane czcionki.

Rozwiązanie: Nadaj obrazom i osadzeniom atrybuty width i height lub proporcje w CSS, rezerwuj miejsce na banery i reklamy, a czcionki ładuj z font-display i wstępnym ładowaniem najważniejszych krojów.

85. Zdjęcia ważą po kilka megabajtów

Zdjęcia wgrywane prosto z aparatu lub telefonu są wielokrotnie większe, niż potrzeba do wyświetlenia na stronie. To jedna z najczęstszych przyczyn wolnego ładowania. Na telefonie z wolniejszym łączem różnica w czasie ładowania jest szczególnie widoczna.

Rozwiązanie: Ustaw automatyczne zmniejszanie i kompresję przy wgrywaniu, konwersję do WebP lub AVIF i leniwe ładowanie obrazów poniżej pierwszego ekranu. Istniejące zdjęcia przetwórz hurtowo wtyczką do optymalizacji obrazów.

86. Wtyczka cache psuje stronę

Agresywne ustawienia optymalizacji (łączenie i opóźnianie JS, usuwanie nieużywanego CSS) potrafią zepsuć menu, formularze i slidery. Sam cache stron rzadko jest problemem, problemem są dodatkowe optymalizacje. Problem często widać tylko u niezalogowanych odwiedzających, bo administrator omija cache.

Rozwiązanie: Włączaj optymalizacje pojedynczo i po każdej sprawdzaj stronę w oknie incognito. Gdy coś się psuje, wyklucz konkretny skrypt zamiast wyłączać całą optymalizację, a strony dynamiczne wyklucz z cache.

87. Baza danych jest ogromna i strona zwalnia

Baza rośnie przez rewizje wpisów, przeterminowane dane tymczasowe (transients), logi wtyczek i opcje ładowane automatycznie (autoload). Szczególnie duże opcje autoload spowalniają każde wejście na stronę.

Rozwiązanie: Zrób kopię bazy, ogranicz liczbę rewizji stałą WP_POST_REVISIONS, usuń przeterminowane transients i dane po usuniętych wtyczkach. Narzędzie Zdrowie witryny w nowszych wersjach WordPressa ostrzega o zbyt dużych opcjach autoload.

88. Panel administracyjny działa wolno

Panel nie korzysta z cache stron, więc każda wolna wtyczka, zewnętrzne zapytanie (np. sprawdzanie licencji) czy duża baza od razu daje się w nim odczuć. Na tańszym hostingu panel bywa wyraźnie wolniejszy niż sama strona.

Rozwiązanie: Sprawdź wtyczką Query Monitor, co spowalnia ekrany panelu, wyłącz zbędne widżety kokpitu, włącz cache obiektów (np. Redis) i ogranicz częstotliwość Heartbeat API.

89. Plik admin-ajax.php obciąża serwer

Wiele wtyczek wykonuje zapytania przez admin-ajax.php, a Heartbeat API wysyła je cyklicznie przy otwartym panelu. Przy kilku otwartych kartach i wolnych wtyczkach serwer dostaje bardzo dużo kosztownych zapytań. Obciążenie widać w panelu hostingu jako skoki użycia CPU w godzinach pracy osób edytujących stronę.

Rozwiązanie: Sprawdź w logach dostępu, które akcje admin-ajax pojawiają się najczęściej, ogranicz Heartbeat i zamykaj nieużywane karty panelu. Wtyczki nadużywające AJAX zastąp lżejszymi.

90. Strona jest szybka na komputerze, a wolna na telefonie

Telefony mają słabsze procesory i często wolniejsze łącze, więc ciężki JavaScript i duże obrazy szkodzą im najbardziej. Google ocenia też przede wszystkim mobilną wersję strony.

Rozwiązanie: Mierz wynik mobilny w PageSpeed Insights i dane z rzeczywistych wizyt w raporcie Podstawowe wskaźniki internetowe w Search Console. Podawaj mniejsze obrazy na telefony i ograniczaj skrypty; przykład naprawy opisaliśmy we wpisie o wolnym sklepie WooCommerce na telefonie.

Migracje, monitoring i stała opieka

Ostatnia grupa to problemy organizacyjne: kto, kiedy i jak dba o stronę, zanim coś się zepsuje.

91. Jak przenieść stronę WordPress na nowy hosting bez przestoju?

Najbezpieczniej skopiować pliki i bazę na nowy serwer, sprawdzić tam stronę przed zmianą DNS (np. przez wpis w pliku hosts), a dopiero potem przełączyć domenę. Odwiedzający nie zauważą wtedy przerwy.

Rozwiązanie: Zrób pełną kopię, przenieś pliki i bazę, popraw dane w wp-config.php, przetestuj stronę na nowym serwerze, obniż TTL, przełącz DNS i zostaw stary serwer na kilka dni. Pamiętaj o rekordach poczty (problem 70).

92. Po migracji część ustawień i widżetów zniknęła

Adresy zamieniono zwykłą zamianą tekstu w pliku SQL, co uszkodziło dane serializowane: ustawienia widżetów, motywu i wtyczek. WordPress odrzuca uszkodzone wpisy i wraca do ustawień domyślnych. Objawy to puste widżety, zresetowane menu i domyślne kolory motywu.

Rozwiązanie: Przywróć bazę z kopii sprzed migracji i zamień adresy narzędziem rozumiejącym serializację (WP-CLI search-replace lub wtyczka migracyjna). Po migracji sprawdź widżety, menu i ustawienia motywu.

93. Strona nie działała przez kilka dni, a nikt tego nie zauważył

Bez monitoringu o awarii dowiadujesz się od klientów albo wcale. Monitoring dostępności sprawdza stronę co kilka minut i od razu powiadamia o przerwie.

Rozwiązanie: Ustaw monitoring dostępności z powiadomieniem mailowym lub w komunikatorze, który sprawdza stronę główną i najważniejszą podstronę (np. z formularzem). Dodaj monitoring ważności certyfikatu SSL i domeny.

94. Nikt nie wie, kto ma dostęp do strony

Dostępy rozdawane latami trafiają do byłych pracowników, agencji i freelancerów. Każde nieużywane konto to potencjalna furtka dla atakującego. Szczególnie ryzykowne są wspólne konta administratora, z których korzysta kilka osób.

Rozwiązanie: Przejrzyj użytkowników WordPressa, konta FTP, bazy danych, hostingu i narzędzi Google. Usuń zbędne, zmień hasła współdzielone i prowadź listę dostępów z informacją, kto i po co ma dostęp.

95. Wykonawca strony przestał odpowiadać

Strona bez opiekuna szybko się starzeje: brakuje aktualizacji, kopii i reakcji na awarie. Najważniejsze jest odzyskanie dostępów i pełna kopia strony. Problem jest poważniejszy, gdy domena lub hosting są zarejestrowane na wykonawcę.

Rozwiązanie: Ustal, gdzie są domena, hosting i kopie, odzyskaj dostępy (problem 56) i zrób pełną kopię. Potem zleć przegląd stanu strony (wersje, wtyczki, bezpieczeństwo, szybkość) i ustal stałą opiekę.

96. Baner cookies nie blokuje skryptów przed zgodą

Wiele banerów tylko wyświetla informację, a narzędzia analityczne i reklamowe ładują się od razu po wejściu na stronę. Pliki cookies, które nie są niezbędne, wymagają zgody przed ich zapisaniem.

Rozwiązanie: Użyj narzędzia do zarządzania zgodami, które blokuje skrypty do momentu zgody, i połącz je z Consent Mode w Google. W narzędziach przeglądarki sprawdź, jakie cookies zapisują się przed kliknięciem zgody.

97. Kopia testowa strony jest widoczna w Google

Kopia robocza na subdomenie lub w katalogu nie była zabezpieczona i Google ją zaindeksował. To duplikat treści i ryzyko pokazania klientom niegotowych materiałów.

Rozwiązanie: Zabezpiecz kopię testową hasłem na poziomie serwera, a adresy, które już są w indeksie, ukryj narzędziem Usunięcia w Search Console. Przy przenoszeniu zmian na produkcję uważaj, żeby nie skopiować blokady indeksowania.

98. Po starcie nowej strony nie ma jej w Google

Najczęściej w Ustawienia, Czytanie została zaznaczona opcja „Proś wyszukiwarki o nieindeksowanie tej witryny”, włączona na czas budowy. To częsta przyczyna braku nowej strony w wynikach.

Rozwiązanie: Odznacz tę opcję, sprawdź robots.txt i meta robots na kilku podstronach, prześlij mapę witryny w Search Console i poproś o zaindeksowanie strony głównej. Inne przyczyny opisaliśmy w liście 100 problemów z pozycjonowaniem SEO.

99. Co obejmuje stała opieka nad WordPressem i ile kosztuje?

Opieka obejmuje zwykle aktualizacje, kopie zapasowe poza serwerem, monitoring dostępności i bezpieczeństwa oraz pomoc przy awariach; koszt zależy od wielkości strony i oczekiwanego czasu reakcji. Nasza opieka nad stroną zaczyna się od 299 zł netto miesięcznie.

Rozwiązanie: Porównując oferty, sprawdź, co dokładnie obejmuje abonament, jak często i gdzie są robione kopie oraz jak szybko wykonawca reaguje na awarię. Więcej o kosztach w artykule ile kosztuje utrzymanie strony WordPress.

100. Kiedy naprawiać stronę, a kiedy ją przebudować?

Przebudowa ma sens, gdy strona opiera się na porzuconym motywie i wtyczkach, nie działa na aktualnym PHP, a każda zmiana wymaga obejść. W pozostałych przypadkach zwykle taniej jest uporządkować to, co już działa.

Rozwiązanie: Zrób przegląd: wersje, zależność od motywu, liczba porzuconych wtyczek, szybkość i bezpieczeństwo. Jeśli większość punktów wymaga wymiany, zaplanuj przebudowę z przekierowaniami 301, żeby nie stracić ruchu z Google.

Od czego zacząć

Najpierw zabezpiecz to, czego nie da się odtworzyć: kopie zapasowe poza serwerem i dostępy do domeny oraz hostingu (problemy 21-30, 56 i 94). Potem aktualizacje i bezpieczeństwo (11-20 i 31-40), następnie pocztę i formularze (71-80), bo każdy niewysłany mail to utracone zapytanie. Szybkość i porządki we wtyczkach zostaw na koniec. Dlaczego regularna administracja się opłaca, wyjaśniamy we wpisie dlaczego strona WordPress potrzebuje regularnej administracji.

Jeśli nie wiesz, w jakim stanie jest Twoja strona, zacznij od bezpłatnego skanu strony: w kilka minut sprawdzi szybkość, podstawy bezpieczeństwa i SEO. Gdy wolisz oddać stronę w ręce specjalistów, nasz zespół przejmie aktualizacje, kopie, monitoring i awarie w ramach usługi opieka nad stroną WWW.