Strona nie wstaje, sklep nie przyjmuje zamówień albo panel nie wpuszcza po aktualizacji. Nazywam się Mariusz Szatkowski, z WordPressem pracuję od 2006 roku i takie awarie naprawiam sam. Zaczynam od faktów, robię kopię, szukam warstwy, która zawiodła, i sprawdzam poprawkę na tych samych ścieżkach, na których strona padła. Niżej opisuję też stały serwis: aktualizacje, kopie i monitoring, przy których awarii jest po prostu mniej.
Z kim pracujesz
- Komercyjny WordPress od 2006 roku, sprzed Gutenberga i REST API
- Prowadzenie przez seniora: ten sam inżynier od discovery po tydzień szósty
- Bez przekazywania do offshore, bez warstwy PM w rachunku
- Organizator WordCamp Europe, mentor WordPress Foundation Credits
- Shopify Academy: ścieżka CRO plus Partner Marketing (Credly, 2025)
Certyfikaty Shopify Academy
Naprawa strony WordPress: objaw, przyczyna i bezpieczny pierwszy krok
Najczęstsze awarie mają opisane w dokumentacji WordPressa przyczyny. Tabela mówi, co zwykle stoi za objawem i co możesz sprawdzić sam, nie pogarszając sytuacji. Jeśli pierwszy krok nie pomaga albo nie masz dostępu do plików, zatrzymaj się i wyślij opis.
| Objaw | Najczęstsza przyczyna | Bezpieczny pierwszy krok |
|---|---|---|
| Biały ekran bez komunikatu | Błąd PHP we wtyczce albo motywie, często zaraz po aktualizacji | Przez SFTP zmień nazwę katalogu wp-content/plugins, a gdy to nie pomoże, katalogu aktywnego motywu |
| „W witrynie wystąpił błąd krytyczny.” | Błąd krytyczny PHP przechwycony przez WordPressa (od wersji 5.2) | Sprawdź skrzynkę adresu administratora: wiadomość zawiera link do trybu odzyskiwania, który wstrzymuje winną wtyczkę |
| 500 Internal Server Error | Uszkodzony plik .htaccess, wtyczka albo limit pamięci | Zmień nazwę .htaccess, a po powrocie strony zapisz ponownie Ustawienia, Bezpośrednie odnośniki |
| Błąd łączenia się z bazą danych | Złe dane w wp-config.php albo niedziałający serwer bazy | Porównaj DB_NAME, DB_USER, DB_PASSWORD i DB_HOST z panelem hostingu, zapytaj hosting o stan MySQL |
| Allowed memory size exhausted | Za niski limit pamięci PHP albo kod, który zjada pamięć w pętli | Podnieś WP_MEMORY_LIMIT w wp-config.php, a potem ustal, co tyle zużywa, bo sam limit tylko odsuwa problem |
| Strona utknęła w trybie konserwacji | Przerwana aktualizacja zostawiła plik .maintenance | Usuń .maintenance z katalogu głównego i dokończ aktualizację, która się przerwała |
| Przekierowania na obce strony, spam w wynikach Google | Włamanie, zwykle przez nieaktualną albo porzuconą wtyczkę | Nie kasuj plików na ślepo: zrób kopię jako dowód, zmień hasła do panelu, SFTP i bazy, potem sprzątanie, opisane krok po kroku na stronie usuwanie wirusów WordPress |
| Sklep WooCommerce nie przyjmuje zamówień | Konflikt wtyczek, cache na koszyku albo błąd po stronie bramki płatności | Zajrzyj do WooCommerce, Status, Dziennik zdarzeń i sprawdź, na którym kroku zamówienie się zatrzymuje |
Źródła: Common WordPress Errors, Debugging in WordPress, Fatal Error Recovery Mode in 5.2, FAQ Ja site was hacked.
Aktualizacje: o czym warto wiedzieć, zanim coś się zepsuje
- WordPress, wtyczki i motyw dostają nowe wersje przez cały czas. Każda pominięta aktualizacja to kolejna znana luka, którą automaty skanują w całej sieci.
- Większość ataków jest przypadkowa. Bot nie wybiera Twojej firmy, tylko szuka konkretnej dziurawej wtyczki. Skutek bywa niewidoczny dla właściciela, na przykład przekierowanie tylko dla gości z telefonów.
- Im dłużej strona stoi bez aktualizacji, tym trudniej i drożej ją potem bezpiecznie podnieść.
- Sama aktualizacja też może coś zepsuć, częściowo albo całkiem. Dlatego testuję ją najpierw na stagingu.
- Brak nowych wersji wtyczki nie znaczy, że jest bezpieczna. Często znaczy, że autor ją porzucił.
- Nie da się zabezpieczyć strony w stu procentach. Da się mieć kopię, z której ktoś, kto wie jak, przywróci stronę po awarii albo włamaniu.
Sprawdź, co Twoja strona pokazuje publicznie
Podaj adres strony, którą prowadzisz. Pobieramy ją tak, jak zrobiłaby to przeglądarka, i pokazujemy, co z niej wynika, razem z tym, co dokładnie odczytaliśmy.
Wklej adres swojej strony. Narzędzie pobiera ją tak jak przeglądarka gościa i pokazuje kod odpowiedzi po przekierowaniach, nagłówki, ciężar startu strony i ślady WordPressa. Nie loguje się i nie widzi panelu, więc nie zastąpi diagnozy, ale wynik wklejony do zgłoszenia przyspiesza start pracy. Pełny opis tego, co mierzy, jest na stronie sprawdzenia strony WordPress.
Jeśli Twoja strona powstała albo została mocno przerobiona przez narzędzie AI, porządkuję ją osobnym torem w ramach naprawy stron zrobionych przez AI. Wygenerowany kod częściej ukrywa błędne założenia niż jawne błędy, więc szukanie zaczyna się gdzie indziej.
Serwis WordPress: co obejmuje stała opieka
Stały serwis to praca, dzięki której do napraw dochodzi rzadziej. Aktualizacje, kopie i monitoring prowadzę w jednym rytmie, żeby poprawka wydajności nie weszła w konflikt z łatką bezpieczeństwa.
- Aktualizacje rdzenia, wtyczek i motywu, najpierw na stagingu, potem na produkcji.
- Kopie zapasowe przechowywane co najmniej 30 dni w krajach UE.
- Monitoring dostępności co 1 do 5 minut, z alertem, który trafia do mnie.
- Umowa powierzenia z art. 28 RODO, podpisana przed pierwszym dostępem do strony z danymi osobowymi.
Hostingu nie sprzedaję. Pracuję na serwerze, który już masz. Szczegóły stałej opieki są na stronie utrzymanie WordPressa.
Jak szybko usuwam pilną awarię?
Nie mam dyżuru 24/7 i nie obiecuję gwarantowanego czasu reakcji. Po zgłoszeniu odpisuję, kiedy mogę zacząć, a czas samej naprawy zależy od tego, co zawiodło, czy są logi i czy mam dostępy. Przy stałym serwisie monitoring sprawdza stronę co 1 do 5 minut i wysyła alert, więc o awarii zwykle dowiaduję się, zanim napiszesz.
Jak przebiega naprawa strony WordPress?
1
Zgłoszenie z faktami
Adres podstrony, moment awarii, ostatnie zmiany i to, co jest zablokowane: koszyk, logowanie albo publikacja.
2
Kopia przed zmianą
Punkt przywracania plików i bazy, a gdy incydent na to pozwala, odtworzenie błędu poza produkcją.
3
Izolacja warstwy
Hosting, rdzeń, motyw, wtyczka, kod własny, zewnętrzne API, cache albo DNS. Poprawiam tylko tę warstwę, która zawiodła.
4
Sprawdzenie i zapis
Scenariusz zgłoszenia i ścieżki sąsiednie przechodzą od nowa, a zmiana i punkt wycofania trafiają do notatki.
Dobre zgłoszenie zaczyna się od faktów. Potrzebuję adresu podstrony, na której widać problem, momentu, w którym pojawił się pierwszy raz, listy ostatnich wdrożeń i aktualizacji oraz informacji, czy zablokowany jest koszyk, logowanie albo publikacja. Zrzuty ekranu pomagają, ale logi przeglądarki i serwera oraz dokładne kroki odtworzenia skracają diagnozę znacznie bardziej.
Przed zmianą na produkcji robię kopię, z której da się wrócić, i jeśli incydent na to pozwala, odtwarzam błąd na osobnej kopii strony. Potem szukam najmniejszej warstwy, która odpowiada za problem: hosting, rdzeń WordPressa, motyw, wtyczka, kod własny, zewnętrzne API, cache albo DNS. Dzięki temu jeden objaw nie kończy się przebudową całej strony.
Naprawa jest skończona, gdy przechodzi pierwotny scenariusz i ścieżki obok niego. Przy błędzie koszyka sprawdzam przejście do płatności, potwierdzenie, e-mail, stan magazynu i analitykę. Przy błędzie w redakcji testuję podgląd, publikację, media, uprawnienia i czyszczenie cache. W notatce zapisuję, co zmieniłem, czego celowo nie ruszałem i jak wycofać zmianę. Gdy źródło problemu leży poza stroną, na przykład u hostingu albo dostawcy płatności, przekazuję dowody i plan ograniczenia skutków, a obejścia nie nazywam trwałą naprawą.
Pomoc techniczna WordPress: co przygotować do zgłoszenia
Na początku awarii najwięcej czasu zjada zdobywanie dostępów i ustalanie, co się zmieniło. Te rzeczy przyspieszają start najbardziej:
Opis awarii
- adres podstrony, na której widać problem
- kiedy pojawił się pierwszy raz
- co zmieniło się tuż przed: aktualizacja, nowa wtyczka, przeprowadzka, zmiana DNS
- treść komunikatu błędu albo zrzut ekranu
Dostępy
- osobne konto administratora w WordPressie, nie Twoje własne
- SFTP albo SSH do plików strony
- panel hostingu z dostępem do bazy i logów błędów
- przy sklepie: dostęp do panelu bramki płatności w trybie podglądu
Dostępy przekazuj osobnym kanałem, nie w treści formularza. Po zakończonej pracy usuń konto, które dla mnie założyłeś, i zmień hasło SFTP. To dobra praktyka przy każdym wykonawcy. Zalecenia WordPressa dotyczące haseł, kont i uprawnień są w przewodniku Hardening WordPress.
Naprawa WooCommerce: kiedy sklep przestaje sprzedawać
Awaria sklepu kosztuje więcej niż awaria strony firmowej, bo w tym czasie nie wpadają zamówienia. Przy WooCommerce działająca strona główna niczego nie dowodzi. Naprawa jest skończona, gdy testowe zamówienie przechodzi przez koszyk, płatność, e-mail z potwierdzeniem i zmianę stanu magazynowego. WooCommerce zapisuje błędy w logach w panelu (WooCommerce, Status, Dziennik zdarzeń), a wersje, środowisko i nadpisane szablony pokazuje raport systemowy w tej samej sekcji. Oba warto dołączyć do zgłoszenia.
Gdy sklep działa, ale od dłuższego czasu gubi zamówienia, płatności albo integracje, lepiej od pojedynczej naprawy sprawdza się zamknięty w czasie sprint ratunkowy WooCommerce.
Strona WordPress nie działa. Opisz, co widzisz
Adres, moment awarii i ostatnie zmiany wystarczą na start. Wycena jest indywidualna i powstaje po opisie incydentu, a praca rusza po spisanym zakresie.
Wyślij opis awariiStałą opiekę po naprawie opisuję na stronie utrzymanie WordPressa.
