CleanOps

Strona po usunięciu wirusa nie działa — 6 najczęstszych przyczyn i jak je naprawić

4 października 2026 • 3 min czytania • naprawa, WordPress, Joomla, błąd 500

Programista analizujący kod na dwóch monitorach

Udało się usunąć malware, a strona… zniknęła. Zamiast niej biała strona, błąd 500, układ bez styli albo surowy HTML bez obrazków. To bardzo częsty scenariusz i w większości przypadków ma prostą przyczynę: plik, którego strona potrzebuje, został zainfekowany, a potem usunięty razem z infekcją. Oto sześć najczęstszych sytuacji.

1. Plik szablonu był zainfekowany i wylądował w kwarantannie

Objaw: strona zwraca kod 200 i prawie pusty HTML, albo tylko nagłówek bez treści.

Dropper lubi nadpisywać index.php szablonu (Joomla: templates/nazwa/index.php, WordPress: wp-content/themes/nazwa/index.php lub header.php). Po przeniesieniu takiego pliku do kwarantanny szablon przestaje istnieć.

Rozwiązanie: nie przywracaj zainfekowanego pliku. Odzyskaj czystą wersję z paczki szablonu (jeśli ją masz), z repozytorium autora albo z archiwum internetu dla plików statycznych. Jeśli szablon był customowy i nie ma źródła, trzeba odtworzyć strukturę ręcznie: na podstawie HTML-a zapisanego w archive.org i plików CSS, które zwykle przeżyły.

2. Plik rdzenia naprawiono „wersją od AI” zamiast oryginałem

Objaw: błąd 500 albo Parse error wskazujący na plik rdzenia.

Automaty, które „leczą” plik rdzenia, przepisując go, potrafią zgubić linię. Pliki rdzenia WordPressa i Joomli nie wymagają leczenia — wystarczy wziąć oryginał z oficjalnego wydania tej samej wersji.

Rozwiązanie: sprawdź wersję (wp-includes/version.php lub libraries/src/Version.php), pobierz to wydanie z oficjalnego źródła i podmień plik. Składnię sprawdzisz komendą php -l plik.php.

3. .htaccess został zmieniony albo usunięty

Objaw: strona główna działa, ale każda podstrona zwraca 404; albo brak styli i obrazków (ścieżki do /assets/... nie działają).

Infekcje często modyfikują .htaccess (dopisują przekierowania, auto_prepend_file, allowlisty shelli). Przy czyszczeniu plik bywa usuwany w całości, razem z regułami przepisywania adresów, od których zależy routing CMS-a.

Rozwiązanie: przywróć domyślny .htaccess dla swojego CMS-a (WordPress ma standardowy blok # BEGIN WordPress, Joomla ma htaccess.txt w katalogu głównym do skopiowania jako .htaccess). Potem dopisz własne reguły, jeśli je miałeś.

4. Uprawnienia plików

Objaw: 403 na części plików, błędy zapisu, panel administracyjny nie zapisuje ustawień.

Czyszczenie czasem ustawia pliki na 600 lub katalogi na 700, gdy właścicielem jest inny użytkownik niż ten, pod którym działa PHP.

Rozwiązanie: katalogi 755, pliki 644, wp-config.php / configuration.php 640 lub 600 (zależnie od hostingu). Sprawdź właściciela plików.

5. Cache trzyma starą, zainfekowaną lub zepsutą wersję

Objaw: strona wygląda inaczej zalogowanym niż niezalogowanym, albo zmiany „nie wchodzą”.

Rozwiązanie: wyczyść cache CMS-a (wp-content/cache, Joomla cache/ i administrator/cache/), cache wtyczki (WP Rocket, LiteSpeed) i cache po stronie hostingu, jeśli jest.

6. To nie pliki — to blokada hostingu

Objaw: każda strona PHP zwraca ten sam krótki komunikat (często 403 „Malware detected”), a statyczne pliki działają.

Rozwiązanie: żadna zmiana w plikach tego nie odblokuje. Dokończ czyszczenie i zgłoś ponowny skan w panelu hostingu. Więcej w osobnym wpisie o blokadzie hostingu.

Jak diagnozować po kolei

  1. Pobierz stronę i spójrz na kod odpowiedzi i długość HTML (curl -sI https://domena.pl, curl -s https://domena.pl | wc -c).
  2. Zajrzyj do logu błędów PHP (error_log w katalogu strony lub logs/ konta). Tam jest nazwa pliku i linia.
  3. Sprawdź składnię podejrzanego pliku: php -l plik.php.
  4. Porównaj z oryginałem z wydania, jeśli to plik rdzenia.
  5. Dopiero wtedy zmieniaj cokolwiek, zawsze z kopią.

Jak robi to CleanOps

Po każdej naprawie panel sam sprawdza, czy strona odpowiada poprawnym HTML-em. Jeśli nie, próbuje odtworzyć zniszczony szablon z archiwum internetu, a potem pyta klienta, czy strona działa. Gdy nie działa, do dyspozycji jest asystent AI, który ma dostęp do plików i logów strony, przechodzi powyższą listę i proponuje konkretne poprawki — każda wykonuje się dopiero po zatwierdzeniu. A jeśli i to nie wystarcza, sprawą zajmuje się człowiek.

Czytaj też