Jeśli strona właśnie przestała działać, nie zaczynaj od pisania do nikogo. Zacznij od dziesięciu minut, które zmieniają zgłoszenie „strona nie działa” w zgłoszenie, na które da się odpowiedzieć konkretem. To centrum prowadzi przez ten triage, pokazuje, gdzie leżą logi i co w nich szukać, mówi dokładnie, co wysłać, i opisuje, co dzieje się po naszej stronie po otrzymaniu wiadomości. Jeśli spieszysz się bardziej niż czytasz, przewiń do sekcji „Co wysłać w zgłoszeniu” i skopiuj listę.
Zanim napiszesz: dziesięć minut triage
Cztery pytania, w tej kolejności. Odpowiedzi na nie zwykle wskazują przyczynę szybciej niż jakiekolwiek narzędzie.
Co dokładnie nie działa. Cała strona, jedna podstrona, czy tylko panel administracyjny? Otwórz adres w oknie prywatnym i na innym łączu, na przykład na telefonie z transmisją komórkową. Jeśli w oknie prywatnym strona działa, problem jest po stronie cache przeglądarki albo Twojej sesji, a nie serwera. Jeśli działa na telefonie, a nie w biurze, sprawdź DNS i firewall po swojej stronie, zanim ktokolwiek zacznie grzebać w WordPressie.
Jaki jest dokładny komunikat. „Nie działa” to pięć różnych awarii. Biały ekran to zwykle błąd PHP z wyłączonym wyświetlaniem błędów. Błąd 500 to błąd serwera, najczęściej wtyczka, motyw albo limit pamięci. „Error establishing a database connection” to baza danych, czyli zupełnie inna ścieżka. Błąd 403 przy logowaniu to zwykle reguła bezpieczeństwa, a nie awaria. Zanotuj kod i pełną treść, łącznie z numerem linii, jeśli jest.
Co się zmieniło tuż przed. Awarie rzadko przychodzą same z siebie. Aktualizacja wtyczki, aktualizacja rdzenia, zmiana wersji PHP przez hosting, wygaśnięcie certyfikatu, zmiana rekordu DNS, koniec ważności domeny, przekroczenie limitu na hostingu. Data i godzina ostatniej zmiany to najczęściej najcenniejsza informacja w całym zgłoszeniu.
Czy masz kopię zapasową. Nie przywracaj jej odruchowo, ale ustal, że istnieje i z kiedy pochodzi. Jeśli hosting robi kopie nocne, sprawdź w panelu, kiedy była ostatnia. To jest ta informacja, która decyduje, czy naprawa jest ryzykowna, czy odwracalna.
Komunikat błędu, warstwa, pierwsza czynność
Ta tabela skraca najdłuższy etap każdej awarii, czyli zgadywanie, gdzie w ogóle szukać.
| Co widzisz | Najprawdopodobniejsza warstwa | Pierwsza czynność |
|---|---|---|
| Pusty biały ekran | PHP, błąd krytyczny z ukrytym komunikatem | Włącz zapis błędów do pliku i odśwież stronę |
| HTTP 500 | Serwer WWW albo PHP | Odczytaj error_log z katalogu strony |
| HTTP 502 lub 504 | PHP-FPM, timeout, zewnętrzne API | Sprawdź czas odpowiedzi i limity procesu |
| Error establishing a database connection | Baza danych | Sprawdź dane dostępu w wp-config.php i status usługi MySQL |
HTTP 403 przy /wp-admin | Reguła bezpieczeństwa, firewall aplikacyjny | Sprawdź logi zapory i listę blokad IP |
| Strona ładuje się bardzo długo | Baza, zewnętrzne API, brak cache | Zmierz TTFB i porównaj front z panelem |
| Przekierowanie na obcą domenę | Infekcja albo podmieniona wtyczka | Nie kasuj plików, zabezpiecz kopię dowodową |
| „Twoje połączenie nie jest prywatne” | Certyfikat TLS | Sprawdź datę ważności certyfikatu |
| Strona pokazuje ofertę rejestratora | Domena wygasła | Sprawdź datę wygaśnięcia w bazie whois |
Kolumna środkowa jest ważniejsza od prawej. Większość straconego czasu w awariach bierze się z naprawiania niewłaściwej warstwy: ktoś wyłącza wtyczki, gdy problem siedzi w DNS, albo przenosi hosting, gdy winna jest jedna zapytująca zewnętrzne API wtyczka.
Gdzie są logi i co w nich szukać
Bez logu diagnoza jest zgadywaniem. Są trzy miejsca, w tej kolejności użyteczności.
Log błędów PHP. Na większości hostingów współdzielonych leży jako error_log w katalogu strony albo w panelu w sekcji z logami. Szukasz ostatnich wpisów PHP Fatal error z godziny awarii. Taki wpis zawiera plik i numer linii, a to zwykle wskazuje winną wtyczkę w pierwszej sekundzie.
Log WordPressa. Jeśli hosting nie daje logu PHP, włącz własny. W wp-config.php, powyżej linii z komentarzem „That’s all, stop editing”:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Błędy trafią do wp-content/debug.log, a odwiedzający nic nie zobaczą. Po diagnozie wyłącz to i skasuj plik; log zostawiony na produkcji na miesiąc potrafi urosnąć do gigabajtów i sam stać się awarią.
Log serwera WWW. Nginx i Apache zapisują osobno dostęp i błędy. Interesuje Cię ten drugi, z godziny zdarzenia. Na hostingu z dostępem do powłoki wystarczy tail -n 100 /ścieżka/do/logs/error.log. Jeśli masz tylko panel, pobierz plik i otwórz w edytorze tekstu, nie w arkuszu kalkulacyjnym, bo długie linie zostaną ucięte.
Czego szukać we wszystkich trzech: znacznika czasu zgodnego z momentem awarii, powtarzającej się tej samej linii (to zwykle pętla, nie przypadek) i nazwy katalogu wtyczki w ścieżce pliku. Czego nie robić: nie wklejaj do zgłoszenia całego pliku na dziesięć tysięcy linii. Dwadzieścia linii wokół pierwszego wystąpienia błędu jest wartościowsze niż komplet.
Cztery najczęstsze awarie i pierwsza pomoc
Poniższe kroki są bezpieczne, odwracalne i nie wymagają programisty. Jeśli któryś wykracza poza Twój komfort, przerwij i napisz; przerwana naprawa jest łatwiejsza do dokończenia niż naprawa pogłębiona.
Biały ekran albo błąd 500 po aktualizacji. Najpierw wyłącz ostatnio zaktualizowaną wtyczkę. Jeśli nie masz dostępu do panelu, zmień nazwę jej katalogu w wp-content/plugins/ przez menedżer plików hostingu albo FTP; WordPress ją wtedy zdezaktywuje. Jeśli to nie pomoże, zmień nazwę całego katalogu plugins na plugins-off, sprawdź stronę i przywróć nazwę. To rozstrzyga w minutę, czy winna jest wtyczka, czy motyw. Gdy masz dostęp do wiersza poleceń, wp plugin deactivate --all robi to samo czyściej i pozwala włączać wtyczki pojedynczo.
Strona nagle wolna. Sprawdź, czy wolne jest ładowanie strony, czy panel. Wolny panel przy szybkim froncie to zwykle baza albo zewnętrzne API, na przykład wtyczka odpytująca serwer licencji przy każdym wejściu. Wolny front przy szybkim panelu to zwykle cache, obrazy albo hosting. Zmierz, zanim zaczniesz optymalizować: PageSpeed Insights pokaże jednocześnie wynik laboratoryjny i dane realnych użytkowników z CrUX, a te drugie są ważniejsze, bo opisują to, czego doświadczają ludzie, a nie symulację. Osobno sprawdź sam czas odpowiedzi serwera, na przykład curl -o /dev/null -s -w "%{time_starttransfer}\n" https://twojadomena.pl/. Wynik powyżej sekundy oznacza problem po stronie serwera, a nie w obrazkach czy skryptach.
Nie mogę się zalogować. Zanim uznasz to za awarię, sprawdź trzy rzeczy: czy adres logowania nie został zmieniony przez wtyczkę bezpieczeństwa, czy Twoje IP nie zostało zablokowane po nieudanych próbach i czy zegar na serwerze się nie rozjechał, bo to psuje sesje. Reset hasła przez formularz wymaga działającej poczty, więc jeśli maile nie wychodzą, to nie zadziała. Awaryjne wyjście: wp user update admin --user_pass=NoweHaslo z wiersza poleceń albo zmiana hasła bezpośrednio w bazie funkcją MD5, którą WordPress akceptuje przy pierwszym logowaniu i od razu podmienia na własny hash.
Podejrzenie infekcji. Objawy: przekierowania na obcą domenę tylko z wyników wyszukiwania, nowi administratorzy, których nie zakładałeś, ostrzeżenie w Search Console, spam w treści widoczny wyłącznie dla Googlebota. Sprawdź listę użytkowników z rolą administratora i daty modyfikacji plików, na przykład find . -type f -mtime -7 -name "*.php", żeby zobaczyć, co zmieniło się w ostatnim tygodniu. Nie usuwaj plików i nie przywracaj kopii, dopóki nie ustalisz daty pierwszego wejścia; kopia sprzed tygodnia zwykle zawiera już tę samą lukę. Zmień hasła, w tym do bazy i FTP, i napisz do nas z adnotacją o infekcji.
Awaria w sklepie WooCommerce ma inną kolejność
W sklepie odruch „wyłącz wszystkie wtyczki” jest kosztowny, bo razem z diagnozą wyłącza płatności, wysyłkę i integracje magazynowe. Kolejność jest odwrotna niż na stronie wizytówkowej.
Najpierw ustal, czy zamówienia wchodzą. Lista zamówień z ostatniej godziny odpowiada na to szybciej niż jakikolwiek log. Jeśli wchodzą, a klienci zgłaszają problem, awaria jest w powiadomieniach albo w płatności, a nie w samym sklepie. Jeśli nie wchodzą wcale, sprawdź stronę koszyka i finalizacji zamówienia w oknie prywatnym, bo obie są wyłączone z cache i psują się inaczej niż reszta strony.
Powiadomienia mailowe to osobna, bardzo częsta awaria, która wygląda jak awaria sklepu. Sprawdź, czy poczta wychodzi w ogóle, i czy nie ląduje w spamie odbiorcy. Trzy rekordy DNS decydują o tym niemal całkowicie: SPF, DKIM i DMARC. Jeśli sklep wysyła maile bezpośrednio z serwera hostingu bez tych rekordów, część wiadomości nie dotrze i żadna zmiana we wtyczce tego nie naprawi.
Jeśli awaria dotyczy jednej metody płatności, sprawdź w panelu operatora, czy nie wygasł klucz API albo certyfikat integracji. To sytuacja, w której strona działa poprawnie, logi są czyste, a sprzedaż stoi, więc bez sprawdzenia po stronie operatora można szukać godzinami we własnym kodzie.
Kiedy to w ogóle nie jest awaria strony
Cztery przypadki, w których WordPress jest niewinny, a diagnostyka po jego stronie tylko traci czas.
Domena wygasła. Objaw: zamiast strony widać ofertę rejestratora albo pustkę. Sprawdzasz to w bazie whois, jednym zapytaniem, i widzisz datę wygaśnięcia. Odnowienie działa zwykle w kilkanaście minut, choć w skrajnych przypadkach domena wchodzi w okres wykupu i kosztuje wielokrotnie więcej niż zwykłe przedłużenie.
Zmiana DNS jeszcze się nie rozeszła. Objaw: część osób widzi nową stronę, część starą. dig twojadomena.pl +short pokazuje, na jaki adres wskazuje domena z Twojej perspektywy. Zmiany propagują się według wartości TTL, więc jeśli ktoś ustawił ją na dobę, tyle właśnie potrwa i nie da się tego przyspieszyć po stronie strony.
Certyfikat wygasł. Objaw: ostrzeżenie przeglądarki o niezaufanym połączeniu. Datę ważności odczytasz poleceniem openssl s_client -connect twojadomena.pl:443 2>/dev/null | openssl x509 -noout -dates. Automatyczne odnawianie potrafi się wyłożyć, gdy w międzyczasie zmienił się DNS albo dodano przekierowanie blokujące weryfikację.
Hosting zawiesił konto. Objaw: komunikat hostingu zamiast strony, czasem po przekroczeniu limitu transferu albo po niezapłaconej fakturze. Tu nie ma czego naprawiać w kodzie, jest tylko rozmowa z hostingiem, ale warto potem sprawdzić, co wygenerowało ruch, bo równie często jest to bot, a nie klienci.
Co wysłać w zgłoszeniu
Im więcej z tej listy podasz od razu, tym mniej rund pytań i tym szybciej dostaniesz odpowiedź merytoryczną, a nie prośbę o uzupełnienie.
| Informacja | Dlaczego jest potrzebna |
|---|---|
| Adres strony i konkretnej podstrony z błędem | Odtwarzamy problem u siebie, zanim cokolwiek zmienimy |
| Nazwa hostingu i rodzaj konta | Limity, wersja PHP i dostęp do logów różnią się między hostingami |
| Data i godzina wystąpienia | Pozwala znaleźć zdarzenie w logach serwera |
| Dokładna treść błędu | Kod i komunikat wskazują warstwę: PHP, baza, serwer WWW, sieć |
| Dwadzieścia linii logu wokół błędu | Skraca diagnozę bardziej niż jakikolwiek opis słowny |
| Ostatnia zmiana przed awarią | Najczęstsza przyczyna i najszybsza droga do cofnięcia |
| Kto jeszcze ma dostęp | Wyklucza równoległą pracę dwóch osób na tej samej stronie |
| Czy istnieje kopia i z kiedy | Decyduje, czy naprawa jest odwracalna |
| Czy sprzedaż stoi | Ustawia kolejność prac, zanim zaczniemy |
Czego nie wysyłać w pierwszej wiadomości: haseł. Dostęp ustalamy po zakresie i najlepiej jako osobne konto administratora, które kasujesz po zakończeniu prac. Jeśli sprawa jest pilna, napisz to wprost i podaj, co dokładnie oznacza pilne: sklep nie przyjmuje zamówień to co innego niż formularz kontaktowy wysyła dwa razy.
Co dzieje się po naszej stronie
Zgłoszenie trafia do jednej osoby, nie do kolejki pierwszej linii, więc nie tłumaczysz sprawy dwa razy. Pierwsza odpowiedź zawiera to, co udało się ustalić z Twojego opisu, i pytanie tylko o to, czego naprawdę brakuje.
Dalej diagnoza. Jest osobnym, skończonym etapem z własną ceną, więc wiesz, na co się zgadzasz, zanim ktokolwiek dotknie strony. Jej wynikiem jest przyczyna, zakres naprawy i koszt, na piśmie. Prace ruszają po potwierdzeniu zakresu, nie po ustnym „działajcie”. Jeśli w trakcie wyjdzie coś poza zakresem, zatrzymujemy się i wyceniamy osobno, zamiast dopisywać to do rachunku po fakcie.
Naprawę robimy na kopii albo na środowisku testowym wszędzie tam, gdzie to możliwe, a zmiany na produkcji wchodzą jednym wdrożeniem z możliwością cofnięcia. Po zakończeniu dostajesz opis tego, co było przyczyną, i co zrobić, żeby nie wróciło. To ostatnie zwykle jest ważniejsze od samej naprawy, bo awaria, która wróci za trzy miesiące, kosztuje drugi raz.
Czego nie robimy
Nie projektujemy graficznie. Layout i rozmieszczenie elementów na widoku, czyli wireframe, dostarcza klient; my wdrażamy z niego responsywny interfejs, integracje i warstwę wydajności. Do zebrania układu mamy gotowy szablon arkusza, który wysyłamy na starcie.
Nie prowadzimy dyżuru nocnego ani weekendowego i nie sprzedajemy czasu reakcji, którego nie potrafimy dotrzymać. Jeśli Twój sklep wymaga gwarantowanego okna reakcji, to jest osobna umowa opiekuńcza, a nie dopisek do zgłoszenia awarii.
Nie robimy „przy okazji”. Każda nowa rzecz, która wyjdzie w trakcie, dostaje własną wycenę. To brzmi sztywno, a w praktyce oszczędza obu stronom rachunku, którego nikt się nie spodziewał.
Nie sprzedajemy też przebudowy jako odpowiedzi na awarię. Jeśli stronę da się naprawić w kilka godzin, mówimy to, nawet jeśli propozycja migracji byłaby dla nas korzystniejsza. Migracja ma sens wtedy, gdy koszt utrzymania obecnego rozwiązania przewyższa koszt zmiany, i to da się policzyć, a nie wyczuć.
Gdy strona wróciła sama, sprawa nie jest zamknięta
Awaria, która minęła bez interwencji, jest gorsza od tej, która trwa, bo znika razem z dowodami i wraca w gorszym momencie. Trzy najczęstsze przyczyny przerywanych awarii wyglądają identycznie z zewnątrz.
Pierwsza to limit zasobów. Hosting współdzielony przydziela stronie określoną liczbę równoczesnych procesów PHP i po jej przekroczeniu odrzuca kolejne żądania, zwykle błędem 503 albo 508. Wystarczy, że bot przejdzie po sklepie z filtrami, i przez trzy minuty strona nie odpowiada nikomu. W logu dostępu zobaczysz wtedy serię żądań z jednego adresu w tej samej sekundzie.
Druga to zadanie cykliczne. WordPress uruchamia własny harmonogram przy okazji odwiedzin, więc ciężkie zadanie, na przykład generowanie raportu albo synchronizacja z magazynem, trafia na przypadkowego użytkownika i blokuje mu stronę. Objaw: awarie o regularnych porach albo zawsze po tej samej akcji w panelu.
Trzecia to zewnętrzne API bez limitu czasu. Wtyczka odpytuje serwer dostawcy, dostawca ma awarię, a Twoja strona czeka na odpowiedź tak długo, jak pozwala konfiguracja PHP. Wtedy strona nie jest zepsuta, tylko czeka, i wraca sama, gdy tamten serwer wstanie.
Co zrobić, żeby złapać to następnym razem: włącz zapis błędów do pliku zanim wróci, zanotuj dokładne godziny wystąpień z ostatnich dni i sprawdź, czy się układają we wzór. Trzy znaczniki czasu i log to komplet, z którym da się pracować. Bez nich zostaje czekanie na kolejny raz.
Gdzie iść dalej
Jeśli już wiesz, czego potrzebujesz, przejdź od razu do właściwej strony zamiast pisać zgłoszenie ogólne.
- Awaria, błąd, coś przestało działać: naprawa, serwis i wsparcie techniczne
- Stała opieka, aktualizacje, kopie i monitoring: utrzymanie stron WordPress
- Podejrzenie włamania albo audyt przed wdrożeniem: audyt bezpieczeństwa WordPress
- Strona działa, ale jest wolna: przyspieszenie strony WordPress
- Nowy projekt albo przebudowa: strona kontaktowa
Dwie rzeczy do zrobienia dziś, zanim coś się zepsuje
Sprawdź, czy Twoja kopia zapasowa da się odtworzyć. Nie czy istnieje, tylko czy działa. Backup, którego nikt nigdy nie przywrócił, jest założeniem, nie zabezpieczeniem, a moment awarii to najgorszy czas, żeby się o tym przekonać. Procedura zajmuje pół godziny: postaw środowisko testowe u tego samego hostingodawcy, przywróć na nim ostatnią kopię, zaloguj się do panelu, otwórz trzy losowe podstrony i sprawdź, czy liczba wpisów i zamówień zgadza się z produkcją. Zapisz, ile to trwało, bo to jest Twój realny czas powrotu po awarii i lepiej znać go z próby niż z awarii.
Druga rzecz zajmuje minutę: spisz, gdzie leży domena, gdzie hosting, kto ma do nich dostęp i kiedy wygasają. Zaskakująco często awaria to nie awaria, tylko wygasła domena albo certyfikat, a odpowiedź na pytanie „u kogo to jest” zajmuje pół dnia, bo osoba, która to zakładała, dawno nie pracuje w firmie. Do tej samej kartki dopisz, kto jest administratorem w WordPressie i czy każde z tych kont jest nadal potrzebne. Konta byłych współpracowników są najczęstszym wejściem, którego nikt nie pilnuje.
