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

Co drugie zgłoszenie, które trafia do mnie w poniedziałek rano, zaczyna się tak samo: "strona padła, klienci dzwonią, pomóż". Błąd 500, biały ekran, menu mobilne, które nie chce się otworzyć na iPhonie. Przy 40% stron internetowych opartych o WordPressa to matematyka – jeśli prowadzisz firmę z WP, prędzej czy później zobaczysz któryś z tych komunikatów.

Robię to od 20 lat. Lista typowych awarii jest zaskakująco krótka, ale ich przyczyny zmieniają się razem z PHP 8.3, nowymi wersjami WordPressa i coraz grubszymi wtyczkami. Tu masz dokładnie to, co u siebie w agencji stosuję jako pierwszy punkt kontaktu z awaryjnym zgłoszeniem – komendy, procedury, realne ceny.

Żeby nie było abstrakcji, zacznijmy od dowodu z tego tygodnia. 22 kwietnia 2026 dostaliśmy w Google opinię, która dobrze opisuje moją codzienność:

Z ogromną przyjemnością wystawiam opinię tej firmie za świetnie wykonaną pracę przy stronie opartej na WordPressie. Strona wcześniej generowała liczne błędy na serwerze, co znacząco utrudniało jej funkcjonowanie. Po wdrożeniu poprawek wszystko działa teraz bez zarzutu – stabilnie, szybko i bez żadnych problemów.

>

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.

>

Dodatkowo firma wykazała się dużym profesjonalizmem i zaangażowaniem, wykonując bezpłatnie poprawki związane z nieprawidłowym wyświetlaniem menu w wersji mobilnej. Dzięki temu strona jest teraz w pełni responsywna i wygodna w obsłudze na każdym urządzeniu.

>

Świetny kontakt, szybka realizacja i realne efekty – zdecydowanie polecam współpracę!

>

– admin SP nr 1 im. Lecha Bądkowskiego w Luzinie, 22.04.2026, Zobacz oryginał w Google

Trzy rzeczy, które wymienia szkoła – błędy 500, migracja PHP 8.3, responsywność mobilna – to trzy najczęstsze wpisy w moim logu zgłoszeń. Dlatego w tym poradniku każda sekcja ma realny przypadek i konkretną ścieżkę wyjścia.

Spis treści

• Jak diagnozować problemy WordPress (fundament)
• Błąd 500 (Internal Server Error) – diagnoza i 7 przyczyn
• Migracja na PHP 8.3 bez przebudowy strony – case study Luzino
• Responsywność menu mobilnego – 3 konkretne przyczyny
• Biały ekran śmierci (WSOD)
• Błąd połączenia z bazą danych
• WordPress wolno się ładuje – diagnostyka
• Konflikty wtyczek – jak znaleźć tę jedną winną
• Zhakowana strona – jak rozpoznać i odzyskać
• Emaile nie są wysyłane – konfiguracja SMTP
• Aktualizacje łamią stronę – bezpieczny workflow
• Kiedy warto oddać WordPress do agencji

Zasady, której nie łamię nigdy: zanim coś zmienię, mam backup z ostatnich 15 minut. Bez porządnej kopii zapasowej każda próba naprawy to rosyjska ruletka.

Jak diagnozować problemy WordPress (fundament)

Najczęstsza wpadka przy naprawie to skok od razu do działania: deaktywacja wszystkich wtyczek, podmiana motywu, reinstalacja core. Ja zaczynam od czegoś innego – od przeczytania error loga. Pięć minut na dobrej diagnozie oszczędza trzy godziny chaotycznego klikania.

Gdzie szukać error loga

Na większości hostingów PHP error log znajdziesz w panelu. W CloudPanel klikasz Sites → twoja domena → Vhost → Logs. W cPanelu szukaj Errors albo Error log w sekcji Metrics. Bezpośrednio na serwerze przez SSH zajrzyj do /var/log/nginx/error.log albo /home/uzytkownik/logs/. Sam WordPress potrafi logować własne błędy w /wp-content/debug.log, ale trzeba to najpierw włączyć.

Jak włączyć WP_DEBUG bezpiecznie

W pliku wp-config.php przed linią / That's all, stop editing! / wstaw:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Taka konfiguracja zapisuje błędy do /wp-content/debug.log, ale nie pokazuje ich odwiedzającym. To ważne, bo odsłanianie komunikatów PHP na froncie to dziura bezpieczeństwa i słaby obrazek dla klientów.

Checklist diagnostyczny w kolejności

Zaczynam od backupu bazy i plików – UpdraftPlus, snapshot w panelu albo wp db export z WP-CLI. Potem zaglądam do error loga, żeby zobaczyć, co naprawdę mówi PHP, a nie zgadywać na podstawie objawów. Trzeci krok to pytanie o ostatnią zmianę: aktualizacja wtyczki, motywu, zmiana PHP, nowy plugin – dziewięć razy na dziesięć winowajca jest świeży. Czwarty to status hostingu (panel, strony statusu w rodzaju status.cyberfolks.pl czy status.lh.pl, komunikaty o awariach). Piąty – DNS i SSL: czy domena się propaguje, czy certyfikat nie wygasł, czy nie ma pętli przekierowań HTTPS.

Dopiero po takim przeglądzie wiem, od czego zacząć. Więcej o ustawieniach w poradniku o problemach z konfiguracją WordPressa.

Cheat sheet kodów błędów serwera

Gdy otwierasz stronę i widzisz trzycyfrowy komunikat, szybki skrót pomaga nie strzelać na oślep. Trzymaj ten kod pod ręką:

Te cztery kody pokrywają ~90% zgłoszeń, które widzę w KC Mobile. Reszta (521, 522, 525) wskazuje zwykle na Cloudflare lub problem z certyfikatem.

Błąd 500 (Internal Server Error) – diagnoza i 7 przyczyn

Błąd 500 to komunikat serwera w stylu: "coś się stało, ale nie powiem ci co". Dla użytkownika – pusta strona z napisem 500 Internal Server Error. Dla admina – zagadka, która w 90% przypadków ma bardzo konkretną przyczynę.

7 najczęstszych przyczyn błędu 500

Statystyki z mojego dziennika zgłoszeń z ostatnich 12 miesięcy wyglądają tak. Około 30% przypadków to uszkodzony lub przeładowany .htaccess, zwłaszcza po aktualizacji wtyczek cache. Kolejne 25% to konflikty wtyczek – typowo Yoast z RankMath albo dwa pluginy cache jednocześnie. Trzecia pozycja (20%) to przekroczony memory_limit PHP; domyślne 64 MB nie wystarcza dla WooCommerce z liczniejszym katalogiem. Niekompatybilny motyw, najczęściej custom theme po zmianie PHP, to około 10% zgłoszeń. Błędna wersja PHP – za stara dla nowej wtyczki albo za nowa dla starego kodu – daje kolejne 8%. Rzadziej trafiam na uszkodzony plik core (zwykle po nieudanej aktualizacji przez FTP) oraz malware w .htaccess po kompromitacji hasła FTP. Te dwa ostatnie razem dają resztę.

Fix krok po kroku

Zawsze w tej kolejności: najpierw error log, potem działanie.

# 1. Zmień nazwę .htaccess (serwer wygeneruje nowy, domyślny)
mv .htaccess .htaccess.backup

# 2. Zwiększ memory_limit (w wp-config.php)
# define( 'WP_MEMORY_LIMIT', '256M' );
# define( 'WP_MAX_MEMORY_LIMIT', '512M' );

# 3. Deaktywuj wszystkie wtyczki (WP-CLI, najszybsze)
wp plugin deactivate --all

# 4. Przełącz na domyślny motyw
wp theme activate twentytwentyfour

# 5. Sprawdź wersję PHP w panelu hostingowym

Po każdym kroku odśwież stronę. Gdy błąd zniknie, masz winowajcę. Wtyczki aktywuj pojedynczo, żeby wskazać, która konkretnie wywala stronę. Pełną procedurę rozpisałem w Błąd 500 WordPress – jak naprawić krok po kroku, a ogólny zestaw napraw masz w WordPress błędy – jak naprawić.

Kiedy fix nie działa

Jeśli po tych pięciu krokach błąd trwa, sprawdź uprawnienia plików (folder 755, pliki 644), reinstaluj core komendą wp core download --force --skip-content i zadzwoń do wsparcia hostingu z pytaniem o limity procesów. Gdy masz WooCommerce, a błąd pojawia się tylko przy koszyku, winowajcą bywa limit max_input_vars – podnieś go do 3000.

Migracja na PHP 8.3 bez przebudowy strony – case study Luzino

Sekcja, której większość poradników nie ma. Standardowa rada to "zrób backup, zaktualizuj, sprawdź" i tyle. Ja pokażę realną ścieżkę na przykładzie Szkoły Podstawowej nr 1 im. Lecha Bądkowskiego w Luzinie – klienta, którego opinię cytuję na górze.

Dlaczego PHP 8.3 w 2026

PHP 7.4 przestało dostawać poprawki bezpieczeństwa w listopadzie 2022 roku. PHP 8.0 skończyło życie w listopadzie 2023. Hostingi coraz częściej wymuszają minimum 8.1 albo 8.2. PHP 8.3 to dziś najlepszy kompromis między stabilnością a wsparciem: WordPress 6.5+ obsługuje je natywnie, większość poważnych wtyczek też. PHP 8.4 jest dostępne, ale zbyt świeże dla produkcji w małych firmach.

Zysk wydajności 8.3 względem 7.4 to realne 15–25% skrócenia czasu generowania strony w WooCommerce. Przy sklepie z 5000 odwiedzin dziennie to wymierna oszczędność zasobów.

Matryca zgodności PHP z WordPress (stan 04.2026)

Zanim ruszysz migrację, sprawdź, czy cała układanka się spina. Tabela poniżej pokazuje, co jest w ogóle wspierane, co zaleca WordPress, a co jest już martwe:

Jeśli Twój hosting oferuje już 8.4 – odpuść na razie. Za mało wtyczek (zwłaszcza w e-commerce) pokrywa ją testami.

Case study: co zastaliśmy w SP Luzino

Szkoła przyszła z konkretną listą objawów. Strona na starym, customowym motywie generowała 500-tki na podstronach galerii. Hosting zapowiedział wymuszoną zmianę PHP na 8.2 w ciągu miesiąca. Menu mobilne nie otwierało się na iPhonie. Poprzedni "informatyk" zasugerował przebudowę od zera za kilkanaście tysięcy złotych.

Diagnoza zajęła dwie godziny. Error log pokazał Uncaught Error: Call to undefined function each() – funkcję usuniętą w PHP 8.0. Za tym szedł konflikt trzech wtyczek po aktualizacji, bo jedna z nich odwoływała się jeszcze do create_function(). Memory_limit siedział na 64 MB przy WooCommerce z 300 produktami. Menu mobilne zostało zabite przez display: none !important w motywie, dodatkowo kłóciło się z headerem z Elementora.

Checklist migracji, którą stosujemy u każdego klienta

Moja procedura ma sześć kroków i wygląda tak samo u szkoły publicznej, jak u sklepu internetowego.

1. Backup pełny (pliki + baza) – zwykle UpdraftPlus plus snapshot w panelu hostingu.
2. Audyt kompatybilności – wtyczka PHP Compatibility Checker plus grep po kodzie: grep -rn "each(" wp-content/themes/ oraz grep -rn "create_function" wp-content/.
3. Aktualizacja motywu i wtyczek do najnowszych wersji zgodnych z PHP 8.3.
4. Test w środowisku lokalnym (LocalWP albo staging w panelu hostingu).
5. Przełączenie PHP w panelu hostingu na produkcji, poza godzinami ruchu.
6. Monitoring error loga przez 48h i test kluczowych funkcji (formularze, checkout, logowanie).

Typowe błędy po migracji i jak je naprawić

Po wejściu na 8.3 w logach najczęściej zobaczysz trzy rodzaje komunikatów. Deprecated: Creation of dynamic property to ostrzeżenie, nie zatrzymuje strony, ale w motywie custom wypada posprzątać. Fatal error: Uncaught TypeError: Cannot pass null as parameter oznacza, że wtyczka przekazuje null tam, gdzie PHP 8 oczekuje stringa – zwykle starczy podbić wersję wtyczki albo znaleźć zamiennik. Return type should either be compatible with ArrayAccess::offsetGet to klasyczny błąd zgodności w starszych wtyczkach i najczęściej konieczna aktualizacja lub patch.

W przypadku SP Luzino podmieniłem each() na pętlę foreach, wywaliłem jedną porzuconą wtyczkę bez zamiennika i podniosłem memory_limit. Cała operacja: 6 godzin pracy. Zero przebudowy, zero nowej warstwy graficznej. Klient zapłacił mniej niż 20% tego, co proponował poprzedni wykonawca. Szczegółowe podejście do problemów z PHP opisałem tutaj, a sama procedura bezpiecznej aktualizacji to materiał na pełny przewodnik po aktualizacjach WordPressa.

Zleć migrację specjalistom. Jeśli Twój hosting wymusza zmianę PHP, a Ty nie masz czasu ani ochoty grzebać w kodzie, skontaktuj się z KC Mobile. Audyt kompatybilności robimy bezpłatnie, samą migrację rozliczamy ryczałtowo – bez niespodzianek.

Responsywność menu mobilnego – 3 konkretne przyczyny

Drugi punkt z opinii szkoły. Menu mobilne to często pomijany bug, bo admin testuje stronę na desktopie. Dopiero klient na telefonie zgłasza: "hamburger nie działa, nie ma menu". Z mojego doświadczenia w 95% przypadków problem sprowadza się do trzech rzeczy.

Przyczyna #1 – konflikt CSS z motywem

Najczęstszy scenariusz: custom CSS albo wtyczka nadpisuje style hamburgera klasą display: none w media query powyżej 768px, ale omija wyjątek dla mobilu. Otwierasz DevTools (F12 w Chrome), przełączasz na widok telefonu (ikonka tabletu), klikasz w miejscu, gdzie powinien być hamburger i patrzysz w panelu Styles, która reguła CSS wygrywa. W Luzinie winowajcą był pojedynczy selektor w style.css motywu z !important, który blokował wyświetlanie ikony poniżej 480px.

Przyczyna #2 – JavaScript błąd w togglerze

Hamburger ma ikonę, ale kliknięcie nic nie robi. Otwierasz konsolę w DevTools (zakładka Console) i widzisz czerwony błąd: Uncaught TypeError: $ is not a function albo jQuery is not defined. Powód: wtyczka deferuje jQuery, a motyw ładuje skrypt menu wcześniej. Fix: w ustawieniach wtyczki optymalizacyjnej (Autoptimize, WP Rocket, LiteSpeed) wykluczasz jQuery z opóźniania.

Przyczyna #3 – cache serwuje stare CSS

Zmieniłeś CSS, zapisałeś, ale menu dalej nie działa. Sprawdzasz stronę i okazuje się, że przeglądarka, Cloudflare albo WP Rocket serwują wersję sprzed poprawki. Rozwiązanie: w tej kolejności wyczyść cache wtyczki, cache Cloudflare (przycisk Purge Everything) i przeładuj stronę z Ctrl+Shift+R. W panelu motywu z Elementorem lub Divi często trzeba dodatkowo kliknąć Regenerate CSS.

Jak zdiagnozować w 5 minut

Rutyna przy zgłoszeniu "menu nie działa na telefonie" jest u mnie zawsze ta sama. Najpierw DevTools, toggle device toolbar, widok iPhone 14 Pro. W zakładce Network przeładowuję stronę z wyłączonym cache (checkbox Disable cache) i patrzę, czy wszystkie zasoby się pobierają. Potem Console – szukam czerwonych błędów JS, bo one najczęściej blokują togglera. W zakładce Elements zaznaczam hamburger i sprawdzam computed styles. Jeśli JS czysty, a style wyglądają poprawnie, zostaje z-index nakładki – typowa wartość to 9999, często przykryta przez header sticky z niższym indexem.

Więcej o motywach i ich typowych wpadkach masz w poradniku Problemy z motywami w WordPress – jak rozwiązać.

Biały ekran śmierci (WSOD)

White Screen of Death to sytuacja, gdy zamiast strony widzisz czystą, białą pustkę. Powód: fatal error PHP, którego nie widać, bo display_errors jest wyłączone na produkcji (i słusznie).

Trzy ścieżki wyjścia z WSOD

Pierwsza rzecz: włącz WP_DEBUG_LOG w wp-config.php (konfiguracja wyżej), odśwież stronę i zajrzyj do /wp-content/debug.log. Tam niemal zawsze znajdziesz fatal error ze ścieżką do pliku i numerem linii.

Jeżeli admin też jest biały, skorzystaj z Recovery Mode WordPressa (od wersji 5.2). WP wysyła mail z linkiem na adres z wp_options.admin_email – ten link pozwala zalogować się w trybie awaryjnym i deaktywować problematyczną wtyczkę przez interfejs.

Gdy recovery mode nie zadziała (bo np. SMTP jest zepsute – patrz sekcja o emailach), wejdź przez FTP do /wp-content/plugins/ i zmień nazwę folderu plugins na plugins_off. WordPress straci wszystkie wtyczki, admin powinien wrócić. Wtedy przywracasz folder i deaktywujesz pluginy pojedynczo.

WSOD to zwykle wyczerpany memory_limit PHP po aktywacji ciężkiej wtyczki (WooCommerce + Elementor + Slider Revolution). Podniesienie limitu do 256 MB rozwiązuje 70% przypadków.

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

Komunikat Error establishing a database connection oznacza, że WordPress nie może się dogadać z MySQL. Powodów jest kilka i każdy ma inny fix.

Złe dane dostępowe w wp-config.php

Najczęstszy scenariusz, zwłaszcza po migracji strony – stare credentials nie pasują do nowego serwera. Sprawdź DB_NAME, DB_USER, DB_PASSWORD i DB_HOST w wp-config.php, a potem przetestuj połączenie z terminala:

mysql -h localhost -u DB_USER -p DB_NAME

Jeśli mysql się nie loguje, dane są błędne – zacznij od nowa, kopiując je z panelu hostingu.

Serwer MySQL padł albo jest przeciążony

Zbyt dużo połączeń, pusty pakiet, stary proces, który zawisł. Rzadkość na hostingach współdzielonych, dość częste na VPS. Jeśli masz dostęp, systemctl status mysql albo mysqladmin status pokaże, co się dzieje. Gdy nie – dzwonisz do wsparcia.

Uszkodzone tabele

Najczęściej po nagłym restarcie serwera albo wyciągnięciu wtyczki, która pisała do bazy w momencie crashu. Napraw komendą wp db repair z poziomu WP-CLI albo wejdź w phpMyAdmin, zaznacz wszystkie tabele i wybierz operację Repair. Zajmuje minuty, działa w 95% przypadków.

DDoS albo skan botów

MySQL odrzuca nowe połączenia, bo bot próbuje wymusić setki logowań na wp-login.php w ciągu minuty. Cloudflare (nawet darmowy plan) plus fail2ban na serwerze rozwiązują temat. Głębsze rozwiązania opisałem w poradniku Problemy z bazą danych w WordPress.

WordPress wolno się ładuje – diagnostyka

Wolna strona nie jest błędem w sensie technicznym, ale dla użytkownika i Google to poważny problem. Od 2021 roku Core Web Vitals są czynnikiem rankingowym, a od 2024 INP zastąpiło FID. Moja mapa diagnostyczna układa się w trzy etapy.

Benchmark i diagnoza

Zaczynam od PageSpeed Insights, GTmetrix i WebPageTest. Interesują mnie dwie metryki: LCP powyżej 2,5 s oraz INP powyżej 200 ms. To poziomy, które Google traktuje jako poor. Jeśli oba są zielone, a strona i tak wydaje się wolna, problem zwykle siedzi w TTFB – pokaże go waterfall w WebPageTest.

Pięciu typowych winowajców

W 80% zgłoszeń o wolny WordPress trafiam na ten sam zestaw: nieskompresowane obrazy, brak cache, słaby hosting, nadmiar wtyczek (powyżej 30) i ciężki page builder z nieużywanymi widgetami. Ten piąty jest najbardziej perfidny – Elementor albo WPBakery ładuje dziesiątki stylów, z których strona korzysta w 10%.

Quick wins i hosting

Zanim zaczniesz grzebać w kodzie, zainstaluj WP Rocket albo LiteSpeed Cache, przekonwertuj obrazy do WebP i podłącz CDN Cloudflare (darmowy plan wystarczy). Trzy zmiany, każda zajmuje kwadrans. Jeśli TTFB dalej przekracza 800 ms, problem jest w hostingu. Polecam CyberFolks (szybki NVMe, LiteSpeed, sensowne ceny), LH.pl albo Zenbox. Nigdy nie polecam nazwa.pl ani home.pl – drogo i wolno, widzę to u klientów migracyjnych tydzień w tydzień.

Pełny proces diagnozy masz w WordPress wolno się ładuje – diagnoza i naprawa, a konkretne ustawienia cache w Problemy z cache w WordPress. Jeśli myślisz o zmianie serwera, mam osobny materiał jaki hosting wybrać dla WordPressa.

Konflikty wtyczek – jak znaleźć tę jedną winną

Strona się wywala, ale nie wiesz, po której aktywacji. Klasyczna technika: binary search (połowienie). Deaktywuj połowę wtyczek, sprawdź stronę. Jeśli działa, winowajca jest w deaktywowanej połowie – aktywujesz połowę z tamtej połowy. W 5–6 iteracjach zawęzisz 40 wtyczek do jednej.

Szybki wariant przez WP-CLI:

wp plugin deactivate --all
wp plugin activate pluginA pluginB pluginC pluginD
# test strony
wp plugin activate pluginE pluginF pluginG pluginH
# test strony

Typowe pary, które się nie lubią

Pewne zestawienia wtyczek powtarzają się w zgłoszeniach co tydzień. Yoast razem z RankMath to podwójny zestaw meta tagów i konflikt w schemie. Dwa pluginy cache jednocześnie (WP Rocket i W3 Total Cache) zwykle dają pustą stronę. Dwa firewalle obok siebie (Wordfence i iThemes Security) skutecznie blokują logowanie – również Tobie. Dwóch page builderów (Elementor i Divi Builder) na jednej stronie robi chaos w stylach i load order. Zasada jest prosta: jedno narzędzie na jedną funkcję.

Więcej o diagnostyce i konfliktach pluginów w Problemy z wtyczkami w WordPress.

Zhakowana strona – jak rozpoznać i odzyskać

Sygnały kompromitacji

Czerwone lampki, które widzę u klientów, powtarzają się w zestawie. Zaczyna się od przekierowań na dziwne domeny (pharma, gambling, porno), szczególnie gdy wchodzi się z Google, a nie wpisując URL ręcznie. Potem pojawiają się nowi użytkownicy z rolą administrator, których nikt nie pamięta. W /wp-content/uploads/ lądują pliki PHP (tam z definicji nie powinno być żadnych). Google Safe Browsing pokazuje ostrzeżenie "Ta strona może zawierać szkodliwe oprogramowanie". Transfer w panelu hostingu rośnie skokowo, mimo że ruch w analytics stoi. Spam w komentarzach walą bez ładu w tempie 200+ na godzinę.

Procedura naprawy

Sprzątanie zawsze w tej samej kolejności:

1. Izolacja – zablokuj dostęp do strony (hasło w .htaccess, tryb maintenance).
2. Forensic backup – oddzielna kopia "brudna" do analizy, nigdy nie nadpisuj nią świeżego backupu.
3. Skan – Sucuri SiteCheck (online), Wordfence, MalCare. Komenda find wp-content/ -name "*.php" -mtime -7 -ls pokaże pliki zmienione w ostatnich 7 dniach.
4. Clean reinstall – nadpisz core i wszystkie wtyczki świeżymi plikami z wordpress.org. wp core download --force --skip-content i ręczne pobranie wtyczek.
5. Zmiana wszystkich haseł – admin, FTP, baza, hosting, Google.
6. WAF – Cloudflare + Wordfence albo Sucuri Firewall na stałe.

Więcej o zabezpieczaniu WordPressa w Bezpieczeństwo WordPress – hardening, a o konfiguracji SSL, która często pada po ataku, w Problemy z SSL w WordPress.

Ważne: jeśli nie masz doświadczenia w forensic cleanup, oddaj stronę specjalistom. Niewłaściwie posprzątana witryna zostaje zainfekowana ponownie w ciągu 7–14 dni, bo hakerzy zostawiają backdoory w miejscach, o których laik nie pomyśli (modyfikacje w wp-config.php, cron jobs, obcy użytkownicy w bazie).

Emaile nie są wysyłane – konfiguracja SMTP

Powiadomienia o zamówieniu, reset hasła, wiadomość z formularza – nic nie dochodzi. WordPress używa funkcji mail() PHP, a większość hostingów ją blokuje albo poczta ląduje w SPAM, bo nie ma SPF, DKIM i DMARC.

Jak to naprawić w 20 minut

Zainstaluj WP Mail SMTP i wybierz dostawcę. Gmail Workspace jest najprostszy, ale limit 500 wiadomości dziennie wyklucza go dla sklepów. SendGrid daje darmowe 100/dzień i dobrze sprawdza się dla małej firmy. Mailgun i Amazon SES są najtańsze przy większych wolumenach, ale setup wymaga więcej cierpliwości. Brevo (dawniej Sendinblue) to wygodny kompromis dla klientów z newsletterem.

Po wyborze dostawcy dodaj w DNS rekordy SPF, DKIM i DMARC zgodne z jego instrukcją – każdy dostawca publikuje dokładny zestaw wartości do wklejenia. Na koniec przetestuj wtyczką Check & Log Email, która pokaże, czy mail faktycznie wychodzi i gdzie ląduje.

DMARC warto skonfigurować na p=none przez pierwsze 14 dni, potem p=quarantine, potem p=reject. To uchroni domenę przed podszywaniem i stopniowo poprawi dostarczalność. Szczegóły w Problemy ze SMTP w WordPress.

Aktualizacje łamią stronę – bezpieczny workflow

Aktualizacja minor (z 6.5.1 na 6.5.2) rzadko coś psuje. Aktualizacja major (6.5 na 6.6) albo większa zmiana wtyczki bywa ryzykowna. Mój proces u klientów jest stały: backup przed każdym update, kopia strony na subdomenie (staging) do testów, weryfikacja kluczowych funkcji (logowanie, checkout, formularze, edytor stron), push na produkcję po zielonym świetle w stagingu i monitoring error loga przez 48h po wdrożeniu.

Auto-update – co włączać, a co trzymać na ręczne

Core minor zostawiam włączone (ustawienie domyślne od WordPress 5.6). Core major wyłączam i robię ręcznie w oknie serwisowym, bo raz na kilka wersji wpada zmiana, która psuje custom kod. Wtyczki kluczowe (WooCommerce, SEO, security) aktualizuję ręcznie, zawsze z backupem – pojedyncza minor w WooCommerce potrafi zmienić zachowanie checkoutu. Wtyczki pomocnicze (proste widgety, drobne fixy) mają auto-update włączony. Motywy zawsze ręcznie, bo aktualizacja motywu nadpisuje customizacje, jeśli nie pracujesz na child theme.

Gdy aktualizacja zepsuje stronę, cofasz zmianę – wtyczka WP Rollback albo ręczne przywrócenie z backupu. Jeśli update wyłączył Ci panel, skorzystaj z recovery mode. Szczegóły w Problemy z aktualizacjami w WordPress.

Kiedy warto oddać WordPress do agencji

Nie każdy problem wymaga specjalisty. Zwykle doradzam klientom prostą kalkulację: ile kosztuje Twoja godzina i ile kosztuje przestój. Jeśli jako przedsiębiorca liczysz sobie 200 zł za godzinę, a naprawa z YouTube zajmuje cztery godziny, straciłeś 800 zł na czymś, co agencja zrobi za 300 zł. Przy e-commerce z 20 zamówieniami dziennie każda godzina downtime'u kosztuje 500–2000 zł utraconego obrotu, więc rachunek robi się jeszcze wyraźniejszy. Blog hobbystyczny wytrzyma dobę, sklep nie wytrzyma godziny. I trzecia rzecz, najtwardsza: jeśli nie masz świeżego backupu, oddaj natychmiast. Próby naprawy bez kopii zapasowej to największy generator straconych stron, jaki znam w tej branży.

Wracając do historii z początku – SP nr 1 im. Lecha Bądkowskiego w Luzinie trafiła do nas po próbie "taniej" naprawy, która nie wyszła. Po naszym wejściu: stabilne PHP 8.3, poprawione menu mobilne, zero błędów serwera, pełna responsywność. Szkoła publiczna to wymagający klient – potrzebuje stabilności, bezpieczeństwa danych uczniów i szybkiego kontaktu. To, co robimy dla instytucji, robimy tak samo dla firm prywatnych.

Co obejmuje nasza opieka techniczna WordPress

Pakiet KC Mobile obejmuje diagnozę błędów w ciągu 24 godzin od zgłoszenia, migracje PHP i aktualizacje WordPressa bez przebudowy strony, optymalizację Core Web Vitals i responsywności, bezpieczeństwo (WAF, monitoring, codzienne backupy) oraz pomoc przy wyborze hostingu i migracji – również z tych, których nie polecam (nazwa.pl, home.pl) na sensowny serwer.

Jeśli dotarłeś do tego miejsca, prawdopodobnie masz konkretny problem z WordPressem. Umów bezpłatną diagnozę strony – obejrzymy error log, powiemy, co jest nie tak i ile realnie kosztuje naprawa. Bez zobowiązania, bez "to zależy, musimy się spotkać". Konkretna odpowiedź w 24h.

Zobacz też ofertę stron WordPress i cennik usług – wszystko z jasnymi widełkami, bez ukrytych kosztów.

FAQ – najczęstsze pytania o problemy WordPress

Ile kosztuje naprawa błędu 500 w WordPress?

W agencji rozliczamy naprawę błędu 500 najczęściej w przedziale 250–600 zł netto, zależnie od przyczyny. Proste przypadki (uszkodzony .htaccess, memory_limit) to 15–30 minut pracy. Konflikt wtyczek po aktualizacji PHP albo zainfekowana strona to 2–4 godziny, czasem dzień. Zawsze zaczynamy od bezpłatnej diagnozy przez error log – dzięki temu wiemy, z czym mamy do czynienia, zanim podamy cenę.

Czy mogę samodzielnie zaktualizować PHP do 8.3?

Tak, pod warunkiem że masz świeży backup i znasz panel hostingu. W CyberFolks czy LH.pl zmiana wersji PHP to dwa kliknięcia. Problem pojawia się, gdy motyw lub wtyczka używa funkcji usuniętych w nowszym PHP – wtedy strona się wywala. Przed zmianą przetestuj witrynę w stagingu lub zainstaluj wtyczkę PHP Compatibility Checker. Jeśli widzisz komunikaty typu Deprecated albo Fatal error, odłóż migrację i popraw kod.

Jak długo trwa migracja WordPressa na nowszą wersję PHP?

Typowa migracja z PHP 7.4 na 8.3 zajmuje 2–6 godzin pracy, jeśli strona jest w rozsądnym stanie. Audyt zgodności zabiera około godziny, aktualizacja wtyczek i motywu kolejna godzina, a test frontu i panelu około 30 minut. Jeżeli trafimy na stary motyw custom albo porzucone wtyczki, czas rośnie do 1–2 dni, bo trzeba podmienić funkcje w kodzie albo znaleźć zamiennik.

Po czym poznać, że strona WordPress została zhakowana?

Najczęstsze sygnały to przekierowania na obce domeny, nowi użytkownicy z rolą administratora, nieznane pliki PHP w /wp-content/uploads/ oraz ostrzeżenie Google Safe Browsing w przeglądarce. W panelu hostingu zobaczysz nagły wzrost transferu, a w Search Console – ostrzeżenia o niebezpiecznych treściach. Uruchom Sucuri SiteCheck i Wordfence, sprawdź pliki zmodyfikowane w ostatnich 7 dniach komendą find. Jeżeli coś wygląda podejrzanie, odizoluj stronę i oddaj specjalistom.

Czy trzeba robić backup przed każdą zmianą?

Tak, bez wyjątku. Zasada w mojej agencji jest prosta: zanim cokolwiek zmieniam w WordPressie klienta, mam backup z ostatnich 15 minut. UpdraftPlus robi to w 3 kliknięcia, CyberFolks i LH.pl mają snapshot w panelu. To jedyny sposób, żeby cofnąć się w 5 minut, zamiast spędzić pół dnia na ratowaniu wszystkiego z fragmentów. Pominięcie backupu przed aktualizacją PHP albo pluginu to najdroższy błąd, jaki można popełnić.

Ile kosztuje opieka techniczna nad stroną WordPress?

W KC Mobile pakiety opieki zaczynają się od 299 zł netto miesięcznie za małą witrynę firmową (aktualizacje, backup, monitoring, 1h pracy w miesiącu). Sklep WooCommerce z WAF i codziennym backupem to 599–899 zł. Interwencje awaryjne poza pakietem liczymy godzinowo (250 zł netto). Pełne stawki znajdziesz w naszym cenniku – często okazuje się, że opieka kosztuje mniej niż jeden większy downtime.

Czy warto samemu naprawiać WordPressa, czy zlecić agencji?

Decydują trzy rzeczy: wartość Twojej godziny, czy strona zarabia i czy masz backup. Jeśli prowadzisz firmę, a strona generuje leady lub zamówienia, każda godzina przestoju to realny koszt. Samodzielny fix jest sensowny, gdy masz czas, kopię zapasową i znasz podstawy PHP. Gdy po 30 minutach prób nie ma postępów, oddaj agencji – dalsze eksperymenty zwykle pogłębiają problem i wydłużają naprawę.

O autorze: Krzysztof Czapnik, CEO KC Mobile. 20+ lat w digital marketingu, specjalizacja w WordPressie, WooCommerce i optymalizacji stron firmowych. Profil na LinkedIn: linkedin.com/in/krzysztof-czapnik.