10 problemów z WordPress

10 problemów z WordPressem – jak szybko naprawiamy.

Biały ekran WordPress, krytyczny błąd, problemy z logowaniem, wirusy czy niedziałający formularz – to codzienność w WordPress. Pokazujemy 10 typowych awarii i nasze sprawdzone sposoby naprawy.

Jeśli masz stronę na WordPressie, to pewnie prędzej czy później zobaczysz jeden z klasycznych komunikatów: „Wystąpił krytyczny błąd na tej stronie”, biały ekran, dziwne reklamy albo po prostu – strona wczytuje się w nieskończoność. WordPress jest bardzo rozbudowany, a połączenie dziesiątek wtyczek, motywów i aktualizacji sprawia, że awarie zdarzają się częściej niż jeszcze kilka lat temu. 

Poniżej pokazujemy 10 najczęstszych problemów, z jakimi zgłaszają się do nas właściciele stron, oraz to, jak je naprawiamy – szybko i bez zgadywania.

„Krytyczny błąd” i biały ekran po aktualizacji

Typowy scenariusz: aktualizujesz WordPressa, motyw albo wtyczkę i nagle widzisz tylko komunikat o „krytycznym błędzie” albo biały ekran. Do panelu czasem da się wejść, a czasem nie.

Najczęstsze przyczyny:

• konflikt między wtyczkami po aktualizacji, 
• motyw niezgodny z nową wersją WordPressa, 
• błąd w kodzie wtyczki (np. źle napisane rozszerzenie). 

Jak to naprawiamy:

• w pierwszej kolejności weryfikujemy, czy strona ma aktualną kopię zapasową (czasem klient o niej nie wie, ale robi ją hosting), 
• włączamy tryb debugowania i sprawdzamy, która wtyczka lub plik motywu wywołuje błąd, 
• wyłączamy problematyczne wtyczki z poziomu FTP/bazy danych, jeśli nie można wejść do panelu, 
• przywracamy stabilną wersję WordPressa, motywu lub wtyczki, a dopiero potem aktualizujemy ostrożnie, krok po kroku. 

Case study: nowa wtyczka „do wszystkiego” i biały ekran WordPress

Klient z małej firmy usługowej zainstalował jedną rozbudowaną wtyczkę „all‑in‑one” do cache, obrazków i bezpieczeństwa. Po jej aktywacji – biały ekran na stronie i w panelu.

W ciągu kilkunastu minut:

– wyłączyliśmy wtyczkę przez FTP,
– przywróciliśmy poprzednie ustawienia cache,
– dobraliśmy lżejsze, pojedyncze wtyczki zamiast jednego „kombajnu”.
Strona wróciła do działania tego samego dnia, a klient dostał informację, których wtyczek „nie dotykać” bez konsultacji.

Strona ładuje się bardzo wolno i traci klientów

Użytkownicy oczekują, że strona załaduje się w 2–3 sekundy, zwłaszcza na telefonie. Jeśli WordPress jest wolny, klient po prostu wraca do wyników Google.

Najczęstsze problemy:

• brak cache i kompresji,
• zbyt ciężkie grafiki (prosto z aparatu),
• tani motyw „z marketplace’u”, przeładowany skryptami,
• zbyt dużo wtyczek, które dublują funkcje.

Jak to naprawiamy:

• robimy prosty audyt PageSpeed i Web Vitals,
• włączamy i konfigurujemy cache, kompresję oraz lazy load grafik,
• optymalizujemy zdjęcia (webp/avif),
• usuwamy niepotrzebne skrypty z motywu,
• tam gdzie trzeba – sugerujemy zmianę motywu na lżejszy, lepiej napisany.

Case study: „ładna” strona, której nikt nie ogląda

Firma usługowa miała bardzo efektowną wizualnie stronę, ale wyniki: PageSpeed na mobile ~30, czas ładowania ponad 8 sekund.
Po naszej ingerencji:
– uporządkowaliśmy wtyczki,
– zoptymalizowaliśmy grafiki,
– dodaliśmy cache i minifikację,
– poprawiliśmy kilka błędów w motywie.
Efekt: czas ładowania spadł do ok. 2,5 sekundy, a współczynnik odrzuceń i liczba zapytań z formularza zauważalnie się poprawiły.

Problemy z logowaniem i pętla „przekierowanie zbyt wiele razy”

Częsta sytuacja: próbujesz wejść do panelu, a przeglądarka pokazuje komunikat o zbyt wielu przekierowaniach albo ciągle wraca do ekranu logowania.

Najczęstsze przyczyny:

• nieprawidłowo ustawione adresy strony i WordPressa,
• konflikty z wtyczkami bezpieczeństwa lub cache,
• błędna konfiguracja SSL/HTTPS,
• mix treści http i https po migracji.

Jak to naprawiamy:

• sprawdzamy konfigurację adresów URL w bazie danych i pliku wp-config,
• wyłączamy potencjalnie problematyczne wtyczki (zwłaszcza bezpieczeństwa i cache),
• poprawiamy reguły w .htaccess i wymuszamy poprawne przekierowania (z http na https lub z www na bez www),
• czyścimy cache po stronie serwera i przeglądarki.

Certyfikat SSL niby jest, ale „strona nie jest bezpieczna”

Właściciele stron często widzą zieloną kłódkę na części podstron, a na innych komunikat o braku bezpieczeństwa.

Najczęstsze przyczyny:

• część zasobów (obrazki, skrypty) dalej ładuje się po http,
• motyw lub wtyczka wymusza stare adresy,
• brak wymuszenia https w konfiguracji serwera lub WordPressa.

Jak to naprawiamy:

• włączamy wymuszenie https w WordPressie i na serwerze,
• wyszukujemy i poprawiamy adresy w bazie danych (zamiana http → https tam, gdzie trzeba),
• sprawdzamy motyw i wtyczki pod kątem twardo wpisanych linków,
• wykonujemy testy na kilku podstronach, aż wszystkie są oznaczone jako bezpieczne.

Case study: sklep z „półbezpiecznym” koszykiem

Sklep internetowy miał poprawny certyfikat, ale podczas składania zamówienia pojawiał się komunikat o niezabezpieczonej stronie. Po analizie okazało się, że jeden ze skryptów w szablonie koszyka był ładowany po http. Po poprawce i wymuszeniu https na całym serwisie problem zniknął, a klient przestał dostawać maile typu „boję się podać dane”.

Konflikty wtyczek i motywów – „coś przestało działać po instalacji…”

WordPress pozwala na instalację dziesiątek wtyczek, ale każda z nich to dodatkowy kod, który może wejść w konflikt z inną.

Typowe objawy:

• formularz nagle przestaje wysyłać wiadomości,
• nie da się zapisać wpisu albo strony,
• znika część treści lub elementów na stronie,
• edytor blokowy „mieli” i nic się nie zapisuje.

Jak to naprawiamy:

• sprawdzamy logi błędów i konsolę przeglądarki,
• wyłączamy nowe lub podejrzane wtyczki i testujemy działanie,
• aktualizujemy motyw i wtyczki do wersji, które współpracują ze sobą,
• jeśli trzeba – zamieniamy problematyczną wtyczkę na inną, bardziej stabilną.

Dziwne reklamy, przekierowania, komunikaty antywirusa – infekcja

Jeśli strona nagle zaczyna przekierowywać na nieznane witryny, pojawiają się reklamy kasyn, fałszywe przyciski „Download” albo przeglądarka zgłasza zagrożenie, najczęściej oznacza to infekcję.

Najczęstsze przyczyny:

• nieaktualne wtyczki i motywy,
• brak podstawowego zabezpieczenia,
• zainfekowane wtyczki z nieoficjalnych źródeł.

Jak to naprawiamy:

• skanujemy pliki i bazę danych pod kątem podejrzanych wpisów i skryptów,
• usuwamy złośliwe fragmenty i nadpisujemy oryginalne pliki WordPressa, motywu i wtyczek,
• wymuszamy zmianę haseł, kluczy bezpieczeństwa i ograniczamy dostęp,
• konfigurujemy dodatkowe zabezpieczenia i kopie zapasowe, żeby sytuacja się nie powtórzyła.

Case study: „strona sama otwiera inne strony”

Klient zadzwonił z informacją, że jego witryna „po chwili sama otwiera jakieś inne strony”. Po analizie odkryliśmy złośliwy kod w kilku plikach motywu i w bazie danych – typowy efekt ataku przez nieaktualną wtyczkę. Po oczyszczeniu plików, aktualizacji wszystkiego i dodaniu podstawowych zabezpieczeń, problem zniknął, a w Google Search Console stopniowo zostały usunięte ostrzeżenia.

Formularz kontaktowy nie wysyła wiadomości

Często strona wygląda dobrze, ale formularz kontaktowy „milczy” – właściciel nie dostaje żadnego maila, choć użytkownicy z niego korzystają.

Najczęstsze przyczyny:

• wiadomości wpadają do spamu,
• serwer ma zablokowaną wysyłkę z funkcji mail(),
• wtyczka formularza jest źle skonfigurowana,
• brakuje SMTP lub jest źle ustawione.

Jak to naprawiamy:

• testujemy formularz różnymi adresami mailowymi,
• konfigurujemy wysyłkę przez SMTP (np. dedykowany serwer pocztowy lub usługę zewnętrzną),
• poprawiamy adresy nadawcy i odbiorcy,
• dodajemy logowanie wysyłek, żeby łatwo sprawdzić, co się z nimi dzieje.

Motyw „rozjechał się” po zmianach lub aktualizacji

Po aktualizacji motywu albo próbie jego modyfikacji strona przestaje wyglądać tak jak wcześniej:

• nagłówek znika lub jest rozciągnięty,
• menu nie działa poprawnie na telefonie,
• układ sekcji jest „rozsypany”.

Najczęstsze przyczyny:

• zmiana struktury motywu w nowej wersji,
• modyfikacje w plikach motywu bez użycia motywu potomnego,
• konflikty z wtyczkami odpowiadającymi za budowę stron.

Jak to naprawiamy:

• przywracamy poprzednią wersję motywu (jeśli jest dostępna),
• wydzielamy indywidualne zmiany do motywu potomnego,
• poprawiamy CSS i ustawienia buildera,
• testujemy zachowanie na różnych rozdzielczościach, ze szczególnym naciskiem na mobile.

Edytor blokowy (Gutenberg) działa „dziwnie” lub wcale

Coraz więcej funkcji WordPressa przenosi się do edytora blokowego i pełnej edycji witryny. Bywa, że po aktualizacji:

• nie można zapisać zmian,
• bloki znikają lub zachowują się inaczej,
• edytor ładuje się bardzo wolno.

Najczęstsze przyczyny:

• stara wtyczka do page buildera miesza się z nowym systemem bloków,
• motyw nie nadąża za zmianami w WordPressie,
• konflikt skryptów JS.

Jak to naprawiamy:

• sprawdzamy, czy problem dotyczy tylko jednego wpisu, czy całej instalacji,
• wyłączamy dodatki do Gutenberga i buildery, testując je pojedynczo,
• aktualizujemy motyw do wersji kompatybilnej z aktualnym WordPressem,
• jeśli trzeba – sugerujemy przejście na bardziej nowoczesny motyw blokowy.

Brak aktualnej kopii zapasowej – największy „cichy” problem

Najpoważniejszy problem to brak działającego backupu. Dopóki wszystko działa, nikt o nim nie pamięta. W momencie większej awarii, infekcji lub błędu przy aktualizacji okazuje się, że nie ma czego przywrócić.

Najczęstsze problemy:

• hosting robi kopie, ale tylko raz na jakiś czas i przechowuje bardzo krótko,
• wtyczka do backupu jest zainstalowana, ale nie skonfigurowana,
• brak kopii poza serwerem (np. w chmurze).

Jak to naprawiamy:

• sprawdzamy, czy hosting ma jakiekolwiek kopie i z jakiego okresu,
• konfigurujemy regularne backupy (np. co tydzień pliki, co kilka codziennie baza),
• ustawiamy zrzuty na własny dedykowany serwer lub do chmury (Google Drive, Dropbox itp.),
• testujemy przywrócenie na środowisku testowym, żeby upewnić się, że backup naprawdę działa.

Case study: awaria + brak backupu

Dość typowa historia: klient zlecił komuś „posprzątanie” na stronie, po czym witryna przestała działać, a hosting nie miał żadnej kopii.
Uratowaliśmy sytuację, odtwarzając stronę z:

– archiwów cache wyszukiwarki,
– starych plików i fragmentów bazy, które udało się odzyskać.
Od tego momentu klient korzysta z naszej obsługi technicznej, ma regularne aktualizacje i kopie zapasowe oraz plan działania na wypadek awarii.

Jak możemy pomóc, gdy WordPress „przestaje działać”?

Większość właścicieli stron nie ma czasu ani ochoty analizować logów błędów, plików na FTP i ustawień serwera – i bardzo dobrze – bo to nie jest ich problem i ich praca. 

Jesteśmy od tego aby się tym zająć:

• szybko przywrócić stronę do działania,
• zabezpieczyć ją na przyszłość,
• poukładać aktualizacje, backupy i podstawowe bezpieczeństwo tak, żeby nie trzeba było o tym pamiętać na co dzień.

Im wcześniej zareagujesz na problemy z WordPressem, tym większa szansa, że zakończy się na prostym „naprawić” zamiast „budować od nowa”. Jeśli widzisz którykolwiek z opisanych wyżej objawów – nie klikaj na oślep, tylko zgłoś awarię do nas. W tym czasie zrób kawę i zjedź ciastko a my to sprawnie ogarniemy problem.