W pracy przy audytach bezpieczeństwa (także na większą skalę, w środowiskach korporacyjnych opartych o narzędzia klasy SIEM) widać jeden powtarzający się schemat: właściciel małej firmowej strony dowiaduje się o ataku nie od swojego hostingu, tylko od klienta, który dostał ostrzeżenie w przeglądarce, albo od spadku ruchu w Google Analytics. Im później atak zostanie wykryty, tym więcej szkód robi w SEO – nie tylko w samym bezpieczeństwie.
Jak zhakowana strona wygląda z punktu widzenia Google
Google skanuje strony pod kątem złośliwego oprogramowania i treści spamowych niezależnie od tego, czy sam właściciel to zauważy. Kiedy wykryje problem, dzieje się jedno z trzech:
- Ostrzeżenie w przeglądarce – Chrome pokazuje czerwony ekran „Ta strona może Cię zaatakować” (Google Safe Browsing). Większość użytkowników w tym momencie po prostu zamyka kartę.
- Etykieta w wynikach wyszukiwania – przy adresie strony pojawia się ostrzeżenie „Ta strona może być zhakowana”, jeszcze zanim ktokolwiek ją otworzy.
- Ręczna akcja (manual action) w Search Console – Google jawnie informuje, że na stronie wykryto spamową treść lub złośliwy kod, i ogranicza jej widoczność do czasu naprawy.
Każdy z tych trzech scenariuszy ma ten sam skutek biznesowy: ruch organiczny spada gwałtownie, często w ciągu 24–48 godzin, nie stopniowo jak przy zwykłym spadku pozycji.
Najczęstsze typy ataków na małe strony firmowe
Spam japoński / doorway spam
To najczęstszy scenariusz na WordPressie z nieaktualną wtyczką. Atakujący wgrywa setki ukrytych podstron z treścią po japońsku lub chińsku (często farmaceutyki, podróbki, hazard), które Google zaczyna indeksować pod Twoją domeną. W wynikach wyszukiwania obok Twojej oferty nagle pojawiają się dziesiątki obcojęzycznych tytułów – to pierwszy sygnał, że coś jest nie tak, zanim jeszcze zareaguje Safe Browsing.
Przekierowania (malware redirect)
Złośliwy kod w motywie lub pliku .htaccess przekierowuje część odwiedzających (czasem tylko z wyników Google, czasem tylko na telefonach) na zewnętrzne strony – fałszywe sklepy, strony z fałszywymi aktualizacjami przeglądarki, strony phishingowe. Właściciel, który wchodzi na stronę bezpośrednio wpisując adres, często niczego nie zauważa.
Backdoory i webshelle w plikach
Ukryty plik PHP, który daje atakującemu pełny dostęp do serwera, nawet po zmianie hasła do WordPressa. To najgroźniejszy wariant – pozwala wrócić po „posprzątaniu” strony, jeśli backdoor nie zostanie znaleziony i usunięty razem z resztą infekcji.
Jak atak realnie niszczy pozycje w Google (mechanika SEO)
| Mechanizm | Co się dzieje z SEO |
|---|---|
| Wpis na liście Safe Browsing | Ostrzeżenie blokuje ruch z Google niezależnie od pozycji – użytkownicy nie klikają w wynik z czerwonym ostrzeżeniem |
| Ręczna akcja za spam | Google celowo obniża widoczność strony w wynikach, dopóki nie przejdzie ona przeglądu (Request Review) |
| Setki zaindeksowanych spamowych podstron | Rozwadniają „budżet indeksowania” i jakość domeny w oczach algorytmu; po usunięciu trzeba je jeszcze wyrejestrować z indeksu |
| Przekierowania do złośliwych domen | Utracone zaufanie użytkowników i wysoki współczynnik odrzuceń liczony przez Google jako sygnał słabej jakości strony |
Jak sprawdzić, czy Twoja strona jest zaatakowana
Pięciominutowa, samodzielna diagnoza, zanim zadzwonisz po pomoc:
- Search Console → Bezpieczeństwo i ręczne działania – pierwsze miejsce, w którym Google informuje wprost o wykrytym problemie.
- Zapytanie
site:twojadomena.plw Google – przejrzyj wyniki; obce języki, słowa typu „casino”, „viagra” czy nieznane adresy podstron to jasny sygnał. - Sprawdzenie w Google Safe Browsing (transparencyreport.google.com/safe-browsing) – pokazuje, czy domena jest aktualnie oznaczona jako niebezpieczna.
- Data modyfikacji plików na serwerze – pliki zmienione lub dodane w nocy, w czasie, kiedy nikt z zespołu nie pracował nad stroną, to częsty trop.
- Lista użytkowników w WordPressie – nieznane konto administratora to prosty sposób, by atakujący wrócił po posprzątaniu strony.
Co zrobić krok po kroku po wykryciu ataku
- Odetnij stronę od ruchu – tryb konserwacji lub tymczasowe wyłączenie hostingu, żeby infekcja nie rozsyłała się dalej do odwiedzających.
- Zabezpiecz dowody – zrób kopię zainfekowanej wersji (plików i bazy) przed czyszczeniem; ułatwia to analizę źródła ataku i ewentualne zgłoszenie incydentu.
- Przywróć z czystego backupu sprzed infekcji lub ręcznie wyczyść pliki, bazę danych i konta użytkowników, jeśli backup jest niedostępny lub też zainfekowany.
- Zmień wszystkie hasła i klucze – WordPress, FTP/SFTP, baza danych, panel hostingu, a przy większych wdrożeniach także klucze API i tokeny integracji.
- Zaktualizuj WordPressa, motyw i wszystkie wtyczki do najnowszych wersji – większość infekcji wchodzi przez znaną, już załataną lukę (więcej w naszej checkliście bezpiecznej aktualizacji WordPressa).
- Zgłoś przegląd w Search Console (Security Issues → Request Review) dopiero po pełnym usunięciu infekcji – przedwczesne zgłoszenie kończy się odrzuceniem.
- Monitoruj stronę przez kolejne tygodnie – nawroty w ciągu 2–4 tygodni po ataku są częste, jeśli backdoor nie został znaleziony za pierwszym razem.
Jak zabezpieczyć się na przyszłość
Większość infekcji da się zapobiec kilkoma nawykami, które kosztują ułamek tego, co odbudowa pozycji po ataku:
- Warstwa ochronna przed serwerem – CDN z ochroną anty-DDoS i podstawowym WAF (opisaliśmy wdrożenie w poradniku Cloudflare dla małej firmy) zatrzymuje dużą część automatycznych ataków, zanim w ogóle dotrą do WordPressa.
- Regularne aktualizacje – rdzeń, motyw i wtyczki, zgodnie z checklistą w poradniku o bezpiecznej aktualizacji WordPressa.
- Minimalna liczba wtyczek – każda nieaktywna, niezaktualizowana wtyczka to potencjalny wektor ataku; usuwaj to, czego faktycznie nie używasz.
- Silne, unikalne hasła i uwierzytelnianie dwuskładnikowe dla panelu WordPressa i FTP – zdecydowana większość infekcji na małych stronach to wciąż efekt słabego lub wykradzionego hasła.
- Kopie zapasowe poza serwerem produkcyjnym, z rotacją na kilka punktów w czasie – backup trzymany na tym samym serwerze co strona zostaje zaszyfrowany lub usunięty razem z nią przy poważniejszym ataku.
- Monitoring zmian plików – nawet prosty, automatyczny alert o nowym lub zmienionym pliku PHP wykrywa infekcję dnia, a nie tygodnie później.
Z naszej strony technicznej: traktujemy bezpieczeństwo stron naszych klientów jak monitoring infrastruktury IT – z regularnym przeglądem logów i alertami na nietypową aktywność, a nie jednorazowym „zabezpieczeniem i zapomnieniem”. Dla firmy oznacza to, że atak jest wykrywany w godzinach, a nie dniach czy tygodniach.
Audyt bezpieczeństwa to też audyt SEO
Jeśli nigdy nie sprawdzałeś, czy Twoja strona jest zaindeksowana w całości tak, jak powinna – to dobry moment. Część prostych sprawdzeń opisaliśmy w poradniku Audyt SEO krok po kroku, a pełen, techniczny przegląd bezpieczeństwa, wydajności i konfiguracji hostingu realizujemy w ramach usługi hosting, domeny i bezpieczeństwo.
Najczęstsze pytania
Czy zhakowana strona wróci na starą pozycję po naprawie?
Zwykle tak, ale nie od razu. Po usunięciu złośliwego kodu i przejściu przeglądu w Search Console Google stopniowo przywraca widoczność strony. W zależności od tego, jak długo trwał atak i ile spamowych podstron zdążył zaindeksować, powrót do poprzednich pozycji trwa od kilku dni do kilku tygodni.
Jak długo Google sprawdza stronę po zgłoszeniu Request Review?
Najczęściej od kilku dni do około dwóch tygodni. Czas zależy od skali ataku i tego, czy wszystkie ślady (złośliwe pliki, ukryte podstrony, nieautoryzowani użytkownicy) zostały faktycznie usunięte – jeśli Google ponownie znajdzie coś podejrzanego, przegląd kończy się odrzuceniem i trzeba zgłosić go jeszcze raz.
Czy warto zgłosić atak na stronę firmową do CERT Polska?
Tak, szczególnie gdy strona rozsyłała malware do odwiedzających, wysyłała spam z firmowej skrzynki lub doszło do wycieku danych klientów (np. z formularza kontaktowego). Zgłoszenie do CERT Polska (cert.pl) jest bezpłatne, a w przypadku wycieku danych osobowych zgłoszenie incydentu do UODO może być prawnym obowiązkiem administratora.