TL;DR: Żeby sprawdzić, czy strona ma wirusa, nie wystarczy na nią wejść ani wkleić adresu do jednego skanera. Zacznij od tego, co wie Google: raport „Problemy dotyczące bezpieczeństwa” w Search Console, stan witryny w Bezpiecznym przeglądaniu i wyszukiwanie site:twojadomena.pl. Potem skanery online, np. Sucuri SiteCheck i VirusTotal, a na końcu skan po stronie serwera: wtyczka bezpieczeństwa i porównanie plików z oryginałami z WordPress.org. Każde narzędzie widzi tylko część obrazu. Skanery online nie widzą plików na serwerze ani bazy danych, a wtyczki działają wewnątrz WordPressa, który może być już przejęty. Wynik „czysto” z jednego narzędzia nie oznacza, że strona jest czysta.
Często dostaję zrzut ekranu z darmowego skanera z zielonym napisem „No malware detected” i pytanie: „To skąd te przekierowania, o których mówią klienci?”. Odpowiedź prawie zawsze jest ta sama: skaner sprawdził to, co mógł zobaczyć z zewnątrz, a infekcja siedziała tam, gdzie nie miał dostępu. W tym wpisie pokazuję, jak sprawdzić stronę krok po kroku, co widzi każde z popularnych narzędzi i czego nie wykryje żadne z nich. Jeśli szukasz listy objawów włamania, znajdziesz ją we wpisie zhakowana strona WordPress - objawy i co zrobić od razu. Tu skupiam się na samym sprawdzaniu.
Dlaczego „u mnie strona działa normalnie” nic nie znaczy
Złośliwy kod na stronach rzadko pokazuje się każdemu. Sucuri, opisując działanie swojego skanera, wymienia infekcje wyświetlane tylko adresom IP Google, a także takie, które pokazują się raz dziennie, raz na adres IP, raz w tygodniu albo w innych określonych warunkach[2]. W innym opisanym przez Sucuri przypadku malware przekierowywało wyłącznie odwiedzających na urządzeniach mobilnych, a po pierwszym przekierowaniu zapisywało ciasteczko, żeby nie robić tego drugi raz. Jak piszą badacze, to bardzo utrudnia diagnozę, bo odwiedzający nie potrafią powtórzyć przekierowania[3].
Właściciel wchodzi na stronę z komputera, z zakładki, często zalogowany do WordPressa. Malware zwykle omija właśnie takie wizyty. Dlatego sprawdzanie zaczynam od źródeł, które nie zależą od tego, jak ja widzę stronę.
Krok 1: sprawdź, co wie Google
Search Console
Jeśli Google ustali, że witryna została zhakowana, wyniki pojawią się w raporcie „Problemy dotyczące bezpieczeństwa” w Search Console[4]. To pierwsze miejsce, do którego zaglądam, bo pokazuje nie tylko sam problem, ale też przykładowe zainfekowane adresy. Przy okazji zajrzyj do ustawień i sprawdź listę właścicieli usługi. Nieznany właściciel to bardzo zły znak.
Drugie narzędzie z Search Console to Sprawdzanie adresu URL. Google zaleca je właśnie do wykrywania maskowania (cloakingu), czyli treści pokazywanej tylko robotowi Google: narzędzie pozwala zobaczyć ukrytą zawartość strony[5].
Bezpieczne przeglądanie i wyszukiwanie site:
Stan domeny na liście Bezpiecznego przeglądania Google sprawdzisz bez logowania w Raporcie przejrzystości Google[13]. Wpisujesz adres i widzisz, czy Google uważa stronę za niebezpieczną.
Proste, a bardzo skuteczne jest też wpisanie w Google site:twojadomena.pl. Google w poradniku o japońskim spamie SEO podaje, że w ten sposób zobaczysz strony zaindeksowane w Twojej witrynie, w tym strony dodane przez hakera[5]. Jeśli przy wyniku site: widzisz tytuły po japońsku, z kasynem, lekami albo markowymi butami, masz odpowiedź. Warto dopisać do zapytania słowa typu casino, viagra, replica, żeby szybciej znaleźć spam. Jak hakerzy na tym zarabiają, opisałem we wpisie o spamie SEO i ukrytych przekierowaniach.
Jeśli Google już oznaczył stronę, kolejne kroki opisałem w osobnym wpisie: „Ta witryna mogła paść ofiarą ataku hakerów” - jak zdjąć ostrzeżenie Google.
Krok 2: skanery stron online
Skaner online to narzędzie, które pobiera Twoją stronę tak jak przeglądarka i szuka w niej znanych wzorców złośliwego kodu, a do tego sprawdza adres na listach blokujących. Najpopularniejsze:
| Narzędzie | Co sprawdza | Czego nie widzi |
|---|---|---|
| Sucuri SiteCheck | znane malware, obecność na czarnych listach (m.in. Google, PhishTank), błędy strony, nieaktualne oprogramowanie, podatne wtyczki[1] | niczego po stronie serwera: backdoorów, skryptów do wysyłki spamu, stron phishingowych w ukrytych katalogach[1] |
| VirusTotal (skan URL) | reputację adresu w ponad 70 bazach programów antywirusowych i list blokujących[6] | plików na serwerze; wynik w dużej mierze zależy od tego, czy ktoś już zgłosił adres |
| Quttera | infekcje, obecność na czarnych listach, problemy z SSL[14] | tak jak pozostałe, tylko to, co widać z zewnątrz |
Sucuri bardzo uczciwie opisuje ograniczenia swojego narzędzia: zdalny skaner ma dostęp tylko do tego, co widać na poziomie przeglądarki, i nie wykryje niczego po stronie serwera[1]. Już w 2012 roku pisali wprost, że jeśli masz ukryty backdoor w wp-content/uploads albo zmieniony plik rdzenia, który nic nie wyświetla w przeglądarce, skaner tego nie wykryje[2].
Przy VirusTotal pamiętaj o fałszywych alarmach. Dokumentacja opisuje je jako zwykłe, nieszkodliwe elementy uznane przez jeden lub więcej skanerów za złośliwe[6]. Jedno trafienie na siedemdziesiąt silników to sygnał do sprawdzenia, nie wyrok.
Krok 3: skaner wewnątrz WordPressa
Wtyczki bezpieczeństwa mają przewagę nad skanerami online: działają na serwerze, więc widzą pliki. Wordfence porównuje pliki rdzenia, motywów i wtyczek z wersjami z repozytorium WordPress.org[7]. Wtyczka Sucuri Security monitoruje integralność plików i wykrywa nieautoryzowane zmiany, a do skanu z zewnątrz używa SiteCheck[8].
Ograniczenia, o których warto wiedzieć:
- Sygnatury w darmowej wersji są opóźnione. W Wordfence nowe sygnatury malware trafiają do wersji darmowej z 30-dniowym opóźnieniem, w czasie rzeczywistym dostają je tylko użytkownicy Premium[7]. Świeża infekcja może więc przejść niezauważona.
- Wtyczka działa wewnątrz przejętego systemu. Jeśli atakujący ma uprawnienia administratora albo dostęp do plików, może wtyczkę wyłączyć, zmienić jej ustawienia albo ukryć przed nią swoje pliki. Zielony wynik ze skanera na zhakowanej stronie trzeba traktować ostrożnie.
- Motywy i wtyczki premium nie mają wzorca w repozytorium, więc nie da się ich porównać z oryginałem w ten sam sposób.
- Baza danych to osobny świat. Złośliwy kod w treści wpisów, opcjach albo widżetach skaner plików może zwyczajnie przeoczyć.
Krok 4: porównanie plików z oryginałem (dla osób z dostępem SSH)
Jeśli masz dostęp SSH i WP-CLI, najbardziej obiektywnym testem jest polecenie wp core verify-checksums. Pobiera ono sumy kontrolne bieżącej wersji WordPressa z WordPress.org i porównuje je z zainstalowanymi plikami, a ze względów bezpieczeństwa robi to bez ładowania WordPressa[9]. Dzięki temu złośliwy kod w instalacji nie może wpłynąć na wynik. Z opcją --include-root polecenie ostrzeże też o plikach, które w katalogu głównym nie należą do WordPressa[9]. Analogiczne polecenie wp plugin verify-checksums robi to samo dla wtyczek z WordPress.org[10].
To pewny sposób na wykrycie zmienionych plików rdzenia i wtyczek, ale nie powie nic o katalogu uploads, motywie potomnym, wtyczkach premium ani bazie danych.
Czego nie wykryje żaden automat
Listy blokujące i skanery są dobre w wykrywaniu tego, co widać na zewnątrz. Sucuri w raporcie za 2018 rok podało, że tylko około 11% zainfekowanych stron trafiło na listę którejś z dużych instytucji blokujących, i dodało, że listy słabo wykrywają infekcje, które nie objawiają się na zewnątrz strony, np. backdoory[11]. A backdoory są bardzo częste: w raporcie za 2023 rok co najmniej jeden miało 49,21% zainfekowanych stron[12].
Z mojej praktyki: najtrudniejsze przypadki to te, w których automaty nie miały szans.
- Webshell w czystym PHP, bez
evali base64, w katalogu wtyczki o nazwie wyglądającej jak normalny dodatek z WordPress.org. Żadna sygnatura go nie łapała. - Spamowe podstrony jako fizyczne katalogi na serwerze, przy zupełnie czystej bazie danych i czystym panelu WordPressa.
- Złośliwe pliki z celowo zmienionymi datami modyfikacji, żeby nie wpadały w filtr „pliki zmienione w ostatnich dniach”. Wyłapałem je dopiero po charakterystycznym rozmiarze.
- Nieznany administrator i hasło aplikacji, przez które atakujący wracał. Żaden skaner plików nie zgłosi tego jako malware.
Dlatego przy podejrzeniu włamania skanery traktuję jako potwierdzenie, a nie dowód czystości. Pełna diagnoza to przegląd logów serwera, kont użytkowników, haseł aplikacji, zadań cron, bazy danych i wszystkich stron na tym samym koncie hostingowym.
Skaner coś znalazł. Co dalej?
Nie zaczynaj od kasowania plików wskazanych przez skaner. Usunięcie jednego podejrzanego pliku zwykle nic nie daje, a niszczy ślady, po których da się ustalić, którędy wszedł atakujący. Najpierw zrób kopię stanu zainfekowanego, zmień hasła i sprawdź konta. Kolejność działań w pierwszej godzinie opisałem w poradniku co zrobić, gdy strona WordPress została zhakowana.
Jeśli nie masz czasu albo dostępu do serwera, czyszczenie, zamknięcie luki i zgłoszenie do Google mogę wziąć na siebie w ramach usuwania wirusów i naprawy zhakowanych stron.
FAQ - jak sprawdzić, czy strona ma wirusa
Czy darmowy skaner online wystarczy, żeby sprawdzić stronę?
Jako szybki test tak, jako dowód czystości nie. Skaner online widzi tylko to, co strona pokazuje przeglądarce. Backdoory, skrypty na serwerze i złośliwy kod w bazie danych są dla niego niewidoczne.
Czy antywirus na moim komputerze wykryje wirusa na stronie?
Może zablokować złośliwy skrypt, kiedy wejdziesz na stronę, ale nie przeskanuje plików na serwerze. Poza tym malware często omija wizyty właściciela, więc antywirus nie ma czego zablokować.
Jak często sprawdzać stronę?
Raport w Search Console warto mieć podpięty z powiadomieniami e-mail, bo Google sam napisze, gdy coś znajdzie. Do tego automatyczny skan wtyczką raz na dobę i ręczny przegląd użytkowników oraz wtyczek raz w miesiącu. Więcej o zapobieganiu w praktycznej liście zabezpieczeń WordPressa.
Skaner pokazuje „nieaktualne oprogramowanie”. Czy to znaczy, że mam wirusa?
Nie, ale to otwarte drzwi. Nieaktualny WordPress lub wtyczka z publicznie znaną luką to najczęstsza droga włamania. Zaktualizuj jak najszybciej, a jeśli wersja była stara od dawna, sprawdź stronę dokładniej.
Wtyczka bezpieczeństwa nic nie znalazła, a Google pokazuje ostrzeżenie. Kto ma rację?
Zwykle Google. Wtyczka szuka znanych wzorców w plikach, a Google widzi, co strona faktycznie pokazuje użytkownikom i swojemu robotowi. W takiej sytuacji potrzebny jest ręczny przegląd plików, bazy i kont.
Wynik skanu niejasny albo klienci zgłaszają dziwne zachowanie strony?
Sprawdzę stronę po stronie serwera, a nie tylko z zewnątrz: pliki, bazę danych, konta, logi i całe konto hostingowe. Jeśli strona jest zainfekowana, wyczyszczę ją i zamknę lukę. Szczegóły na stronie naprawa i czyszczenie stron. Telefon: +48 606 719 343, e-mail: lukasz@freelancerka.com.
Przypisy i źródła
Wszystkie źródła zweryfikowane; dostęp: 19 października 2026.
- Sucuri, „SiteCheck - Free Website Security Check & Malware Scanner” - sitecheck.sucuri.net
- Sucuri Blog, Daniel Cid, „Ask Sucuri: How Does SiteCheck Work?” (20.10.2012) - blog.sucuri.net
- Sucuri Blog, „Legacy Mauthtoken Malware Continues to Redirect Mobile Users” (04.11.2020) - blog.sucuri.net
- Pomoc Search Console, „Raport Problemy dotyczące bezpieczeństwa” - support.google.com
- Google, web.dev, „Fix the Japanese keyword hack” - web.dev
- VirusTotal, „How it works” - docs.virustotal.com
- WordPress.org, „Wordfence Security - Firewall, Malware Scan, and Login Security” - wordpress.org
- WordPress.org, „Sucuri Security - Auditing, Malware Scanner and Security Hardening” - wordpress.org
- WordPress Developer Resources, „wp core verify-checksums” - developer.wordpress.org
- WordPress Developer Resources, „wp plugin verify-checksums” - developer.wordpress.org
- Sucuri, „2018 Hacked Website and Malware Threat Report” - sucuri.net
- Sucuri, „2023 Hacked Website & Malware Threat Report” (czerwiec 2024) - sucuri.net
- Google, Raport przejrzystości, „Bezpieczne przeglądanie Google - stan witryny” - transparencyreport.google.com
- Quttera, „Website Malware Scanner” - quttera.com
