Gdy strona firmowa przestaje działać, liczy się kolejność działań. Najpierw ustal, na jakim etapie występuje awaria: przeglądarka, domena, serwer czy sama aplikacja (CMS, wtyczki, motyw). Potem zabezpiecz kopię i dopiero wtedy naprawiaj. Wiele typowych usterek, jak błąd 500 czy biała strona po aktualizacji, da się opanować w kilkanaście minut. Atak hakerski, utrata danych albo awaria sklepu w trakcie sprzedaży to sytuacje, w których warto od razu oddać stronę w ręce specjalisty. Poniżej znajdziesz praktyczną ścieżkę: od diagnozy, przez najczęstsze błędy, po decyzję, czy naprawiać sam, czy zlecić to komuś.
Krótko mówiąc
- Zacznij od komunikatu błędu i sprawdzenia strony w innej przeglądarce lub na telefonie. To wskazuje, którą warstwę naprawiać.
- Przed każdą zmianą zrób kopię plików i bazy danych. Bez niej naprawa może pogłębić problem.
- W WordPressie błąd krytyczny zwykle wywołuje wtyczka lub motyw. Tryb odzyskiwania albo zmiana nazwy folderu wtyczki przez FTP często wystarcza.
- Po ataku hakerskim najpierw odizoluj stronę i zachowaj logi, a dopiero potem przywracaj kopię.
- Regularna opieka techniczna, czyli aktualizacje, kopie i monitoring, kosztuje mniej nerwów niż gaszenie pożarów.
Spis treści
- Najpierw ustal, gdzie leży problem
- Najczęstsze awarie i jak je naprawić
- Strona po ataku hakerskim: kolejność działań
- Kopia zapasowa, która naprawdę ratuje stronę
- Samodzielnie czy ze specjalistą?
- Opieka techniczna i redesign w M Studio
- Nasze podejście do naprawy stron
- Jak zapobiegać kolejnym awariom
- Najczęściej zadawane pytania
- Źródła
Najpierw ustal, gdzie leży problem
Najczęstszy błąd przy naprawie to poprawianie czegoś, co działa. Ktoś zmienia ustawienia domeny, choć winna jest wtyczka. Ktoś reinstaluje motyw, choć problem leży po stronie serwera. Dlatego zanim cokolwiek zmienisz, odpowiedz na kilka prostych pytań:
- Czy błąd widać wszędzie? Otwórz stronę w trybie incognito, w innej przeglądarce i na telefonie przez sieć komórkową. Jeśli problem znika, przyczyna leży po Twojej stronie (pamięć podręczna, rozszerzenie, sieć firmowa).
- Jaki jest dokładny komunikat? „Nie można znaleźć serwera” wskazuje na domenę lub DNS. „500 Internal Server Error” to błąd serwera lub aplikacji. „W witrynie wystąpił błąd krytyczny” to typowy komunikat WordPressa.
- Co zmieniło się ostatnio? Aktualizacja, nowa wtyczka, zmiana hostingu, odnowienie domeny. W większości przypadków awaria ma związek z ostatnią zmianą.
- Czy działa panel administracyjny? Jeśli możesz się zalogować, naprawa jest zwykle prostsza.
Poniższa tabela pomaga przypisać objaw do prawdopodobnej przyczyny.
| Objaw | Prawdopodobna warstwa | Pierwszy krok |
|---|---|---|
| Strona nie otwiera się, przeglądarka nie znajduje adresu | Domena lub DNS | Sprawdź, czy domena jest opłacona i czy wskazuje na właściwy serwer |
| Błąd 500 | Serwer lub aplikacja | Sprawdź plik .htaccess i ostatnio dodane wtyczki |
| Pusta, biała strona | Aplikacja (PHP, wtyczka, motyw) | Włącz tryb debugowania lub tryb odzyskiwania |
| „Błąd krytyczny” w WordPressie | Wtyczka lub motyw | Skorzystaj z linku z e-maila o trybie odzyskiwania |
| Rozjechany wygląd | Motyw, pliki CSS, pamięć podręczna | Wyczyść cache i sprawdź ostatnią aktualizację |
| Dziwne przekierowania, obce linki, reklamy | Infekcja złośliwym kodem | Odizoluj stronę i zachowaj logi |
Najczęstsze awarie i jak je naprawić
Błąd 500 Internal Server Error
Błąd 500 to ogólny sygnał, że serwer nie poradził sobie z żądaniem. Częstym winowajcą bywa uszkodzony lub błędnie zmieniony plik .htaccess. Możesz to sprawdzić, łącząc się z serwerem przez FTP i zmieniając nazwę pliku na .htaccess.old. Jeśli strona wróci, wiesz, gdzie szukać. W WordPressie możesz potem odtworzyć poprawny plik, zapisując ponownie ustawienia bezpośrednich odnośników.
Jeśli zmiana nazwy nic nie daje, sprawdź logi błędów w panelu hostingu. Zwykle wskazują konkretny plik i linię kodu, które wywołały problem.
Biała strona i błąd krytyczny w WordPressie
Pusta strona bez komunikatu to najczęściej błąd PHP, wyczerpany limit pamięci albo konflikt wtyczek. WordPress ma na to wbudowane narzędzie. Tryb odzyskiwania pozwala zalogować się do kokpitu i wyłączyć wadliwą wtyczkę lub motyw bez używania FTP. Link do niego WordPress wysyła na adres e-mail administratora.
Gdy nie masz dostępu do panelu, ta sama dokumentacja podpowiada drogę ręczną: w katalogu wp-content/plugins zmień przez FTP nazwę folderu podejrzanej wtyczki. WordPress przestanie ją wczytywać, a Ty odzyskasz dostęp.
Jeśli nie wiesz, która wtyczka jest winna, dokumentacja typowych błędów WordPressa zaleca dezaktywować wszystkie wtyczki, a potem włączać je pojedynczo. Można też tymczasowo przełączyć motyw na domyślny. Ta metoda jest żmudna, ale skuteczna.
Strona przestała działać po aktualizacji
To jedna z najczęstszych sytuacji, z którymi zgłaszają się właściciele stron. Według tej samej dokumentacji WordPressa nieudana automatyczna aktualizacja może dać biały ekran, komunikat o niepowodzeniu albo błąd PHP. Przyczyną bywają problemy z połączeniem lub nieprawidłowe uprawnienia plików.
Co zrobić:
- Sprawdź, czy strona nie utknęła w trybie konserwacji. Jeśli widzisz komunikat o planowanej konserwacji, w głównym katalogu zwykle został plik .maintenance, który można usunąć.
- Wyłącz wtyczki zaktualizowane jako ostatnie.
- Jeśli to nie pomaga, przywróć kopię zapasową sprzed aktualizacji.
Pamiętaj też, że zgodnie z instrukcją aktualizacji WordPressa zmodyfikowane pliki rdzenia zostaną nadpisane. Jeśli ktoś kiedyś „poprawiał” pliki WordPressa bezpośrednio, po aktualizacji te zmiany znikną. To częsta przyczyna nagle niedziałających funkcji.
Niedziałający formularz, koszyk lub rozjechany wygląd
Takie usterki są mniej widoczne, ale bywają najdroższe. Formularz kontaktowy, który nie wysyła wiadomości, oznacza utracone zapytania. Koszyk, który nie przyjmuje płatności, to utracona sprzedaż. Najpierw przetestuj ścieżkę jak klient: wyślij formularz, złóż testowe zamówienie, sprawdź stronę na telefonie. Problemy z wyglądem często rozwiązuje wyczyszczenie pamięci podręcznej wtyczki i serwera. Jeśli nie, przyczyną jest zwykle konflikt motywu z nową wersją wtyczki lub przestarzały kod.
Strona po ataku hakerskim: kolejność działań
Objawy włamania to m.in. przekierowania na obce witryny, nieznane konta administratorów, spam w wynikach wyszukiwania czy ostrzeżenia przeglądarki. Tu nie warto improwizować. CERT Polska w swojej bazie wiedzy opisuje ścieżkę postępowania, którą streszczamy poniżej:
- Odizoluj stronę. Wyłącz serwer z sieci lub włącz tryb konserwacji. To ogranicza dalsze działania atakującego.
- Zabezpiecz logi. Są potrzebne, by ustalić, jak i kiedy doszło do włamania.
- Ustal wektor i czas infekcji. Dopiero wtedy wiesz, która kopia zapasowa jest czysta.
- Przywróć kopię sprzed incydentu albo, gdy nie da się ustalić momentu włamania, odbuduj stronę z czystej instalacji CMS i aktualnych komponentów. Przenieś tylko sprawdzone treści.
- Zmień wszystkie hasła do panelu, FTP, bazy danych i hostingu.
- Przechowuj kopie poza serwerem, żeby kolejny atak ich nie objął.
Incydent możesz też zgłosić do CERT Polska. Jeśli na stronie były dane klientów, na przykład w sklepie lub formularzu, skonsultuj z osobą odpowiedzialną za ochronę danych, czy musisz powiadomić organ nadzorczy.
Luki w popularnych systemach pojawiają się regularnie. W 2026 roku CERT Polska opublikował komunikat o krytycznej podatności w rdzeniu WordPressa, pozwalającej na zdalne wykonanie kodu bez logowania, i zalecił niezwłoczną aktualizację. To dobry przykład, dlaczego aktualizacje nie mogą czekać miesiącami.
Kopia zapasowa, która naprawdę ratuje stronę
Kopia zapasowa jest podstawą każdej naprawy, ale sama jej obecność nie wystarcza. Jak wskazuje baza wiedzy gov.pl o odporności organizacji, przed ponownym uruchomieniem trzeba sprawdzić, czy usunięto przyczynę incydentu i czy odzyskane dane są kompletne. Test odtworzenia całej usługi potrafi ujawnić braki w konfiguracji lub uprawnieniach, zanim staną się problemem.
Dobra kopia strony spełnia kilka warunków:
- Obejmuje pliki i bazę danych. Sama baza bez plików motywu i wtyczek nie odtworzy strony.
- Jest przechowywana poza serwerem. Kopia na tym samym hostingu znika razem z nim.
- Ma kilka wersji wstecz. Infekcja bywa wykryta po tygodniach, a wtedy wczorajsza kopia jest już zainfekowana.
- Jest testowana. Przynajmniej raz na jakiś czas warto odtworzyć ją na wersji testowej.
Samodzielnie czy ze specjalistą?
Nie każda awaria wymaga programisty. Jeśli masz dostęp do panelu i FTP, aktualną kopię oraz wiesz, co zmieniło się ostatnio, wiele drobnych usterek usuniesz sam. Granica przebiega tam, gdzie ryzyko pomyłki staje się większe niż koszt pomocy.
| Sytuacja | Możesz spróbować sam | Lepiej zlecić specjaliście |
|---|---|---|
| Błąd po aktualizacji jednej wtyczki | Tak, wyłącz ją i sprawdź | Gdy wtyczka jest kluczowa, np. obsługuje płatności |
| Błąd 500 lub biała strona | Tak, jeśli masz kopię i dostęp FTP | Gdy logi wskazują na kod motywu lub serwera |
| Włamanie, obce przekierowania | Nie | Zawsze, ze względu na logi i ustalenie wektora ataku |
| Awaria sklepu internetowego | Tylko drobne poprawki | Gdy dotyczy koszyka, płatności lub danych klientów |
| Brak kopii zapasowej | Nie eksperymentuj | Zanim cokolwiek zmienisz |
| Stara strona, która psuje się po każdej zmianie | Nie | Gdy naprawy się powtarzają, rozważ redesign |
Ostatni wiersz jest ważny. Jeśli strona ma kilka lat, opiera się na porzuconych wtyczkach i każda aktualizacja kończy się awarią, kolejne łatanie przestaje mieć sens. Wtedy rozsądniej jest zaplanować redesign strony internetowej na nowoczesnych, wspieranych rozwiązaniach.
Co przygotować, zanim zgłosisz awarię
Dobrze przygotowane zgłoszenie skraca diagnozę. Zanim napiszesz do specjalisty, zbierz:
- adres strony i dokładną treść komunikatu błędu, najlepiej ze zrzutem ekranu,
- informację, kiedy problem się pojawił i co zmieniano tuż przed nim,
- dane dostępowe do panelu CMS, hostingu i FTP lub zgodę na ich przekazanie w bezpieczny sposób,
- informację, czy i gdzie są kopie zapasowe,
- listę funkcji, które muszą działać w pierwszej kolejności, np. formularz lub płatności.
Opieka techniczna i redesign w M Studio
Jeśli nie chcesz sam pilnować aktualizacji, kopii i bezpieczeństwa, możemy zrobić to za Ciebie. W ramach opieki technicznej nad stroną dbamy o aktualizacje, bezpieczeństwo i hosting, żeby Twoja strona działała stabilnie i wydajnie.
Gdy naprawa starej strony przestaje się opłacać, proponujemy redesign. Każdy projekt realizujemy indywidualnie, bez gotowych szablonów. Termin i cenę znasz przed startem, a po wdrożeniu zapewniamy wsparcie, poprawki i rozwój strony. Zapytaj o wycenę i opisz, co dzieje się z Twoją stroną.
Nasze podejście do naprawy stron
Z naszej perspektywy najlepsza naprawa to ta, której nie trzeba robić w pośpiechu. Większość awarii, które widzimy, ma wspólny początek: strona po wdrożeniu została bez opieki. Wtyczki się starzeją, kopie nie są robione, a nikt nie sprawdza, co dzieje się po aktualizacji.
Dlatego nie traktujemy strony jako projektu zamkniętego w dniu publikacji. Projektujemy ją indywidualnie, z myślą o tym, żeby dało się ją bezpiecznie aktualizować i rozwijać. Potem zostajemy przy kliencie, bo wsparcie po wdrożeniu, poprawki i rozwój są częścią naszej pracy.
Gdy trafia do nas strona po awarii, najpierw szukamy przyczyny, a nie objawu. Czasem wystarczy usunąć konflikt wtyczek. Czasem uczciwie mówimy, że stara konstrukcja będzie się psuć dalej i lepiej ją przebudować. Wolimy jedną przemyślaną decyzję niż serię kosztownych łatek.
Mariusz
Jak zapobiegać kolejnym awariom
Najtańsza naprawa to ta, której udało się uniknąć. Kilka nawyków znacząco zmniejsza ryzyko:
- Kopia przed każdą aktualizacją. Pełna kopia plików i bazy pozwala cofnąć zmiany w kilka minut.
- Rozważne automatyczne aktualizacje. Dokumentacja WordPressa o automatycznych aktualizacjach radzi, by przed ich włączeniem upewnić się, że możesz przywrócić poprzednią wersję strony.
- Mniej wtyczek. Każda dodatkowa wtyczka to kolejny kod do aktualizowania i potencjalne źródło konfliktu.
- Wersja testowa. Większe zmiany sprawdzaj najpierw na kopii strony, nie na wersji, którą widzą klienci.
- Monitoring dostępności. Dzięki niemu o awarii dowiesz się szybciej niż od klienta.
- Szybkość i technika pod kontrolą. Wolna strona też jest problemem, bo traci odwiedzających i pozycje w Google. Pomaga w tym techniczne SEO i optymalizacja szybkości.
Jeśli zastanawiasz się, jaki system zarządzania treścią będzie najłatwiejszy w utrzymaniu, zajrzyj do naszego poradnika o tym, jak wybrać stronę www z CMS.
Najczęściej zadawane pytania
Ile trwa naprawa strony internetowej?
To zależy od przyczyny. Konflikt wtyczki lub błędny plik .htaccess można usunąć w kilkanaście minut. Odbudowa strony po włamaniu, z analizą logów i czyszczeniem kodu, może zająć kilka dni.
Czy naprawa strony po ataku hakerskim usuwa problem na stałe?
Tylko wtedy, gdy usunięto przyczynę, czyli lukę, przez którą doszło do włamania. Samo przywrócenie kopii bez aktualizacji i zmiany haseł zostawia otwarte drzwi. Dlatego po naprawie potrzebne są aktualizacje i regularna opieka.
Co zrobić, gdy nie mam kopii zapasowej?
Nie wprowadzaj żadnych zmian na ślepo. Najpierw zrób kopię obecnego stanu, nawet uszkodzonego, i sprawdź, czy Twój hosting nie przechowuje automatycznych kopii. Jeśli strona jest kluczowa dla firmy, skontaktuj się ze specjalistą, zanim zaczniesz naprawiać.
Kiedy lepiej zrobić nową stronę niż naprawiać starą?
Gdy awarie się powtarzają, strona korzysta z porzuconych wtyczek lub przestarzałej wersji PHP, a każda zmiana wymaga obejść. Wtedy koszt kolejnych napraw szybko przewyższa koszt redesignu na nowoczesnych rozwiązaniach.
Jakie dostępy są potrzebne do naprawy strony?
Najczęściej dostęp do panelu administracyjnego CMS, do panelu hostingu oraz do serwera przez FTP lub SFTP. Przy problemach z domeną potrzebny bywa też dostęp do panelu rejestratora. Po zakończeniu naprawy warto zmienić hasła przekazane na czas prac.
Źródła
- WordPress.org: Recovery Mode
- WordPress Developer: Common WordPress errors
- WordPress.org: Updating WordPress
- WordPress.org: Plugin and themes auto-updates
- CERT Polska: Przejęta strona internetowa
- CERT Polska: Zgłoszenie incydentu
- CERT Polska: Krytyczna podatność w WordPress Core
- Gov.pl: Reagowanie i odporność organizacji