Naprawa awarii strony/sklepu
Biała strona, komunikat o błędzie krytycznym, błąd 500 albo sklep, który przestał przyjmować zamówienia. Ustalam przyczynę z logów serwera zamiast zgadywać, przywracam działanie i pokazuję, co zrobić, żeby nie powtórzyło się przy kolejnej aktualizacji.
Z czym najczęściej się zgłaszacie
Nie musisz wiedzieć, co się stało ani nazywać problemu po imieniu. Wystarczy, że rozpoznasz objaw i podasz mi adres strony.
Biała, pusta strona
Zamiast witryny ładuje się czysty biały ekran, czasem tylko w panelu, czasem wszędzie. To najczęściej błąd PHP, którego serwer nie pokazuje, bo ma wyłączone wyświetlanie komunikatów.
W witrynie wystąpił błąd krytyczny
Klasyczny komunikat WordPressa, zwykle po aktualizacji wtyczki lub motywu. Na skrzynkę administratora przychodzi wtedy mail z nazwą winowajcy - jeśli go masz, naprawa idzie szybciej.
Błąd 500 albo 503
Serwer odrzuca żądanie, zanim WordPress zdąży się uruchomić. Przyczyną bywa uszkodzony plik konfiguracyjny, przekroczony limit pamięci albo wyczerpane zasoby konta hostingowego.
Błąd połączenia z bazą danych
Strona informuje, że nie może połączyć się z bazą. Czasem to zmienione dane dostępowe, czasem uszkodzone tabele, a czasem baza po prostu przekroczyła limit na serwerze.
Strona rozjechała się po aktualizacji
Witryna działa, ale układ się rozsypał, sekcje zniknęły albo edytor przestał zapisywać zmiany. Zwykle to konflikt między nową wersją wtyczki a motywem lub inną wtyczką.
Sklep nie przyjmuje zamówień
Koszyk gubi produkty, płatność kończy się błędem albo zamówienia nie zapisują się w panelu. Przy sklepie liczy się każda godzina, więc te zgłoszenia biorę poza kolejnością.
Awaria rzadko bierze się znikąd
W większości przypadków, które trafiają do mnie, przyczyną jest zmiana wprowadzona chwilę wcześniej: aktualizacja wtyczki, podniesienie wersji PHP przez hosting albo nowy fragment kodu wklejony do motywu. Strona działała, coś się zmieniło, przestała działać.
To dobra wiadomość, bo daje punkt zaczepienia. Logi serwera i daty modyfikacji plików pokazują, co wydarzyło się w momencie awarii, więc zamiast wyłączać wtyczki po kolei i patrzeć, co pomoże, można od razu wskazać winowajcę.
Najczęstsze przyczyny
- Konflikt po aktualizacji wtyczki, motywu albo samego WordPressa
- Podniesienie wersji PHP przez hosting, przy starym kodzie w motywie
- Przekroczony limit pamięci lub zasobów konta hostingowego
- Brak miejsca na serwerze, przez co baza przestaje zapisywać dane
- Uszkodzone tabele w bazie po przerwanym imporcie albo aktualizacji
- Zmiana w kodzie wprowadzona bez kopii zapasowej
Co dokładnie robię przy naprawie
Kolejność ma znaczenie. Najpierw ustalam przyczynę, dopiero potem naprawiam - odwrotna kolejność kończy się stroną, która działa do następnej aktualizacji.
Odczyt logów serwera
Zaczynam od logów błędów PHP i serwera, nie od zgadywania. W większości przypadków wskazują dokładny plik i linię, w której coś poszło nie tak, razem z godziną zdarzenia.
Tryb diagnostyczny
Włączam rejestrowanie błędów do pliku, a nie na ekran, żeby odwiedzający nie zobaczyli komunikatów technicznych ani ścieżek do plików na serwerze.
Kopia przed naprawą
Pełna kopia plików i bazy w stanie zastanym, zanim cokolwiek zmienię. Przy awarii to szczególnie ważne, bo część prób naprawy potrafi pogorszyć sytuację.
Izolacja winowajcy
Wyłączam podejrzany komponent na poziomie plików, bez dostępu do panelu, i sprawdzam, czy strona wraca. Potem szukam wersji, która działa, zamiast zostawiać wtyczkę wyłączoną na stałe.
Zgodność z wersją PHP
Jeśli awarię wywołało podniesienie PHP, sprawdzam, które komponenty tego nie przetrwały. Część da się zaktualizować, część wymaga poprawki w kodzie motywu.
Naprawa bazy danych
Przy błędach połączenia i uszkodzonych tabelach wykonuję naprawę i optymalizację bazy, a w razie potrzeby odtwarzam dane z ostatniej sprawnej kopii.
Testy po naprawie
Strona wstaje - to dopiero połowa. Sprawdzam formularze, logowanie, a przy sklepach cały proces zakupowy z płatnością włącznie, żeby nie okazało się, że coś zostało po drodze.
Zabezpieczenie na przyszłość
Kopia zapasowa poza serwerem, plan bezpiecznych aktualizacji i, jeśli chcesz, środowisko testowe, żeby następna aktualizacja nie odbywała się na żywym organizmie.
Od zgłoszenia do działającej strony
Nie musisz niczego diagnozować samodzielnie ani tłumaczyć się z tego, co próbowałeś wcześniej. Wystarczy adres strony i dostęp do hostingu.
-
1
Zgłoszenie
do kilku godzinPiszesz albo dzwonisz, podajesz adres i mówisz, co widzisz na ekranie oraz co działo się tuż przed awarią. Jeśli dostałeś od WordPressa maila o błędzie krytycznym, prześlij go - zawiera nazwę komponentu, który wywrócił stronę.
-
2
Bezpłatna diagnoza
zwykle w godzinęSprawdzam stronę z zewnątrz i, jeśli mam już dostępy, zaglądam w logi. Wracam z informacją, co się stało, ile potrwa naprawa i ile będzie kosztować. Dopiero wtedy decydujesz.
-
3
Kopia i naprawa
zwykle kilka godzinPełna kopia w stanie zastanym, potem izolacja przyczyny i przywrócenie działania. Przy sklepach pracuję na kopii testowej wszędzie tam, gdzie to możliwe, żeby nie zatrzymywać sprzedaży.
-
4
Testy
ten sam dzieńSprawdzam nie tylko stronę główną: podstrony, formularze, logowanie, a w sklepie pełną ścieżkę zakupową z płatnością. Testuję też na telefonie, bo część problemów widać wyłącznie tam.
-
5
Podsumowanie
po naprawieDostajesz krótką informację: co było przyczyną, co zrobiłem i co warto zmienić, żeby nie powtórzyło się przy kolejnej aktualizacji. Bez żargonu i bez straszenia.
Z kim właściwie pracujesz?
Nazywam się Bartosz Ciachurski i od dekady zajmuję się WordPressem od strony kodu, nie tylko panelu administracyjnego. Przy awariach to różnica praktyczna: kiedy problemu nie da się rozwiązać wyłączeniem wtyczki, trzeba wejść w pliki i poprawić kod.
Dzwonisz i rozmawiasz z osobą, która za chwilę zajrzy w logi Twojego serwera. Nie ma opiekuna klienta, systemu zgłoszeń ani przekazywania sprawy dalej - przy awarii, która kosztuje Cię sprzedaż, to ma znaczenie.
Płacisz za czas naprawy, nie za diagnozę
Sprawdzenie, co się stało, jest bezpłatne. Cenę podaję przed rozpoczęciem prac, a poniżej widełki, w które mieści się większość zgłoszeń.
Awaria prosta
- Jedna przyczyna, dająca się szybko wskazać
- Konflikt po aktualizacji wtyczki lub motywu
- Biała strona lub błąd krytyczny WordPressa
- Kopia zapasowa przed naprawą
- Testy podstron i formularzy
- Informacja o przyczynie po naprawie
Awaria złożona
- Wszystko z awarii prostej
- Błąd 500 lub problem po stronie serwera
- Uszkodzona baza danych i odtworzenie tabel
- Niezgodność kodu z nową wersją PHP
- Poprawki w kodzie motywu, gdy nie ma innego wyjścia
- Kontakt z hostingiem w Twoim imieniu
- Plan bezpiecznych aktualizacji na przyszłość
Sklep WooCommerce
- Zgłoszenia obsługiwane poza kolejnością
- Naprawa koszyka, kasy i bramek płatniczych
- Weryfikacja, czy zamówienia nie zostały utracone
- Sprawdzenie integracji z ERP i Baselinkerem
- Praca na kopii testowej, bez zatrzymywania sprzedaży
- Pełny test ścieżki zakupowej po naprawie
Co warto wiedzieć
- Wszystkie kwoty są netto. Do faktury doliczam 23% VAT.
- Diagnoza jest bezpłatna. Cenę naprawy podaję przed rozpoczęciem prac i nie zmieniam jej po fakcie.
- Jeśli okaże się, że naprawa nie ma sensu i taniej wyjdzie odbudowa strony, mówię to wprost.
- Nie liczę dodatkowo za to, że stronę budował ktoś inny. Bez znaczenia, kto ją robił i w jakim jest stanie.
- Potrzebuję dostępu do panelu hostingu lub FTP. Do WordPressa nie zawsze - przy poważnej awarii i tak się nie zaloguję.
- Hasła zmieniasz po zakończeniu prac. Domena i hosting przez cały czas zostają na Twoje dane.
- Awarie sklepów i stron całkowicie niedostępnych biorę poza kolejnością, także w weekend.
- Jednorazowa naprawa nie zastępuje kopii zapasowych. Jeśli ich nie masz, powiem o tym w podsumowaniu.
Co dostajesz po zakończeniu naprawy
Nie tylko działającą stronę. Chodzi o to, żebyś wiedział, co ją wywróciło, i żeby kolejna aktualizacja nie skończyła się tak samo.
Wiesz, co się stało
Konkretna wtyczka, wersja PHP albo limit serwera - z fragmentem logu, jeśli chcesz go zachować albo pokazać hostingowi.
Stan przed naprawą
Pełna kopia plików i bazy sprzed prac. Zostaje u Ciebie, więc masz punkt odniesienia, gdyby coś jeszcze wymagało uwagi.
Sprawdzona całość
Podstrony, formularze, logowanie, a w sklepie pełna ścieżka zakupowa z płatnością - także na telefonie.
Jak tego uniknąć
Co zmienić w kolejności aktualizacji, jakie komponenty wymienić i czy warto uruchomić środowisko testowe.
Ile realnie czekasz na reakcję
Przy awarii najbardziej boli niewiedza, jak długo to potrwa. Poniżej maksymalne czasy, do których się zobowiązuję.
| Sytuacja | Czas reakcji | Co się dzieje dalej |
|---|---|---|
| Sklep nie przyjmuje zamówień Koszyk, kasa lub płatności nie działają - każda godzina to utracona sprzedaż | Reakcja do 4 h, także w weekend | Naprawa zwykle tego samego dnia |
| Strona całkowicie niedostępna Biała strona, błąd 500, brak dostępu do panelu | Reakcja do 4 h w dni robocze | Przywrócenie zwykle tego samego dnia |
| Strona działa, ale z błędami Rozjechany układ, formularz nie wysyła, błąd na jednej podstronie | Reakcja do 12 h | Naprawa do 2 dni roboczych |
| Problem powtarzający się Strona pada cyklicznie, zwykle przy większym ruchu | Reakcja do 24 h | Diagnoza pod obciążeniem, potem plan naprawy |
| Diagnoza przed decyzją Nie wiesz, czy to awaria, czy coś innego | Reakcja do 24 h | Bezpłatne sprawdzenie i wycena przed startem |
| Dostępy potrzebne do startu | Panel hostingu lub FTP | WordPress, jeśli logowanie w ogóle działa |
| Praca w weekend | Sklepy i strony całkowicie niedostępne | Pozostałe zgłoszenia w dni robocze |
To są górne granice, nie średnie. W praktyce odpowiadam zwykle w ciągu dwóch, trzech godzin w dni robocze, bo zgłoszenie trafia bezpośrednio na moją skrzynkę, a nie do kolejki przeglądanej raz dziennie.
Nie obiecuję za to dyżuru całodobowego. Jestem jedną osobą i uczciwiej powiedzieć wprost, że nocą zwykle śpię, niż sprzedać gwarancję, której nie da się dotrzymać. Przy sklepach i stronach całkowicie niedostępnych reaguję również w weekendy.
Naprawiać po fakcie czy zapobiegać?
Nie namawiam na abonament każdego - przy stronie, która stoi nietknięta od dwóch lat, jednorazowa naprawa jest tańsza i w zupełności wystarczy. Poniżej różnice, żebyś mógł policzyć to samodzielnie.
| Obszar | Naprawa jednorazowa | Stała opieka |
|---|---|---|
| Kiedy wchodzę do gry | Po awarii, na zgłoszenie. Strona już nie działa i liczy się czas przywrócenia | Zanim awaria wystąpi. Aktualizacje testowane, kopie robione, monitoring pilnuje dostępności |
| Kopia zapasowa | Robiona dopiero w chwili naprawy, więc odtworzyć da się tylko stan zastany - już uszkodzony | Regularna i przechowywana poza serwerem, więc jest do czego wrócić sprzed awarii |
| Czas przestoju | Od zgłoszenia do naprawy, zwykle kilka do kilkunastu godzin | Zwykle zero, bo problem jest wyłapywany przy aktualizacji na kopii testowej |
| Kto zauważa problem | Najczęściej klient, który chciał coś kupić albo napisać | Monitoring, w ciągu sekund od zdarzenia, zanim ktokolwiek zdąży trafić na błąd |
| Koszt | Od 150 zł netto za naprawę, ale bez utraconej sprzedaży w rachunku | Od 199 zł netto miesięcznie, przewidywalnie i z pulą godzin na zmiany |
| Znajomość strony | Poznaję ją przy okazji awarii, pod presją czasu | Znam historię wdrożenia, więc szybciej wiem, gdzie szukać |
| Dla kogo to lepsze | Strony wizytówkowe, które rzadko się zmieniają i nie generują sprzedaży wprost | Sklepy i strony, z których realnie przychodzą zapytania i zamówienia |
Powiązane usługi
Przywrócenie strony to jedno. Poniżej rzeczy, o które warto zadbać zaraz po naprawie, żeby nie wracać do tego tematu za kwartał.
Stała opieka WordPress
Aktualizacje testowane przed wdrożeniem, kopie zapasowe poza serwerem i monitoring dostępności. Większość awarii, które naprawiam, po prostu by się nie wydarzyła.
Naprawa zhakowanej strony
Jeśli za awarią stoi infekcja - przekierowania, obce treści, ostrzeżenie Google - potrzebna jest inna procedura niż zwykła naprawa błędu.
Audyt strony
Dla stron, które padają cyklicznie. Sprawdzam wydajność, konfigurację serwera i komponenty bez wsparcia, a na koniec dostajesz listę priorytetów.
Przyspieszenie strony
Część awarii to w rzeczywistości przeciążenie: strona nie tyle pada, co przestaje odpowiadać przy większym ruchu. Wtedy pomaga optymalizacja, nie naprawa.
Migracja na lepszy hosting
Jeśli awarie wynikają z limitów konta albo przestarzałego środowiska, tańsze i skuteczniejsze bywa przeniesienie niż kolejna naprawa.
Odbudowa strony bez kopii
Kiedy awaria zniszczyła pliki, a kopii nie ma. Odtwarzam, co się da, z archiwum internetu i pozostałości w bazie danych.
FAQ - naprawa awarii strony i sklepu
Ile trwa naprawa awarii?
Prosty przypadek - konflikt po aktualizacji, biała strona, błąd krytyczny - zwykle kilka godzin od otrzymania dostępów. Sprawy z uszkodzoną bazą albo niezgodnością kodu z nową wersją PHP potrafią zająć dzień roboczy. Po bezpłatnej diagnozie podaję konkretny czas, zanim zaczniemy.
Ile kosztuje sama diagnoza?
Nic. Sprawdzam, co się stało, i wracam z informacją o przyczynie, czasie i koszcie naprawy. Dopiero wtedy decydujesz, czy działamy. Płacisz za naprawę, nie za ustalenie, co jest zepsute.
Czy stracę treści, produkty albo zamówienia?
W ogromnej większości przypadków nie - awaria zwykle blokuje działanie, a nie kasuje dane. Pierwszą rzeczą przed naprawą jest pełna kopia w stanie zastanym, a przy sklepach sprawdzam po wszystkim, czy zamówienia i płatności są kompletne.
Próbowałem naprawić sam i pogorszyłem sprawę. Weźmiesz to?
Tak i naprawdę nie ma w tym nic wstydliwego - połowa zgłoszeń wygląda właśnie tak. Powiedz tylko, co robiłeś: które wtyczki wyłączałeś, co wgrywałeś przez FTP, czy przywracałeś kopię. To skraca diagnozę, zamiast ją utrudniać.
Nie mam kopii zapasowej. Da się coś zrobić?
Zwykle tak. Awaria najczęściej wynika z jednego uszkodzonego elementu, a nie z utraty całej strony, więc kopia nie jest potrzebna do naprawy. Gorzej, gdy pliki zostały skasowane - wtedy odtwarzam, co się da, z archiwum internetu i pozostałości w bazie.
Nie mogę zalogować się do panelu. To problem?
Nie. Przy poważnej awarii panel i tak nie działa, więc pracuję przez FTP albo menedżer plików w panelu hostingu. Wystarczy dostęp do hostingu - konto WordPressa mogę odtworzyć później.
Strona pada regularnie. Naprawa pomoże na stałe?
Jednorazowa naprawa usuwa objaw. Jeśli awarie wracają co kilka tygodni, przyczyna leży zwykle głębiej: w limitach hostingu, w komponencie bez wsparcia albo w wydajności przy większym ruchu. Wtedy proponuję audyt zamiast kolejnej doraźnej naprawy - taniej wychodzi.
Co, jeśli awaria wyszła po aktualizacji, którą zrobił hosting?
To częsty przypadek przy podniesieniu wersji PHP. Ustalam, które komponenty tego nie przetrwały, i albo je aktualizuję, albo poprawiam kod motywu. Jeśli trzeba wrócić do poprzedniej wersji PHP na czas naprawy, kontaktuję się z hostingiem w Twoim imieniu.
Mój sklep stoi. Jak szybko możesz się tym zająć?
Sklepy i strony całkowicie niedostępne biorę poza kolejnością, także w weekend. Zadzwoń zamiast pisać - przy zatrzymanej sprzedaży to najszybsza droga.
Czy po naprawie zostawiacie wyłączoną wtyczkę?
Staram się tego unikać, bo to nie naprawa, tylko obejście. Szukam wersji, która działa, albo zastępnika o tej samej funkcji. Jeśli jedynym wyjściem jest trwałe usunięcie komponentu, mówię o tym wprost i proponuję, czym go zastąpić.
Napisz, co widzisz na ekranie
Podaj adres strony i opisz objaw własnymi słowami - nie musisz znać nazw błędów. Sprawdzę, co się stało, i wrócę z informacją o przyczynie, czasie i koszcie. Jeśli stoi sklep, dzwoń zamiast pisać.