Blog · 7 listopada 2026 · 9 min czytania

Strona zhakowana: jak to poznać, co sprawdzić w 10 minut i co zrobić najpierw

Włamanie na firmową stronę rzadko wygląda jak w filmie. Nikt nie podmienia strony głównej na czaszkę. Zamiast tego strona działa jak zwykle, tylko w Google pojawia się kilkaset podstron o lekach i kasynach, klienci z telefonu lądują w sklepie z podróbkami, a formularz kontaktowy rozsyła spam z Twojej domeny. Właściciel dowiaduje się ostatni – od klienta, od hostingu albo z czerwonego ekranu w Chrome. Poniżej: dziewięć objawów, które możesz zauważyć sam, test w 10 minut (w tym jak zobaczyć stronę tak, jak widzi ją Google), pierwsze kroki w dobrej kolejności i jak wrócić do wyników wyszukiwania.

Dziewięć objawów, które widać bez logowania na serwer

1. W Google są podstrony, których nie tworzyłeś. Wpisz site:twojafirma.pl – jeśli wśród wyników są adresy w obcym języku, o lekach, hazardzie, tanich butach albo „darmowych kodach”, ktoś dopisał je do Twojej strony. Google nazywa to wstrzykiwaniem adresów URL (URL injection): włamywacz tworzy nowe strony „często zawierające spamerskie słowa lub linki”.
2. Strona przekierowuje gdzie indziej – ale nie zawsze. Typowo: tylko z telefonu, tylko po wejściu z Google, tylko za pierwszym razem. Właściciel wchodzi z zakładki na komputerze i wszystko działa. Google opisuje przekierowania ustawiane m.in. „przez modyfikację plików konfiguracyjnych serwera”.
3. Czerwone ostrzeżenie w przeglądarce. Przy złośliwym oprogramowaniu na stronie Chrome pokazuje w pasku adresu etykietę „Niebezpieczna” i stronę ostrzegawczą przed wejściem; w wynikach wyszukiwania strona może dostać etykietę ostrzegawczą. To moment, w którym ruch spada do zera z dnia na dzień.
4. E-mail z Search Console o problemach dotyczących bezpieczeństwa. Jeśli strona jest zweryfikowana w Search Console, Google wysyła powiadomienie i pokazuje raport z przykładowymi adresami. Jeśli nie jest – nikt Ci nie powie; to jeden z powodów, by założyć konto dziś.
5. Hosting pisze o spamie, nadużyciu albo wyłącza konto. Zhakowane strony rozsyłają pocztę, atakują inne serwery albo obciążają procesor. Hosting widzi to wcześniej niż Ty.
6. Spadek ruchu i pozycji bez powodu. Google obniża strony ze spamem i ostrzeżeniami; w statystykach widać schodek, a nie powolny zjazd.
7. Nowe konta administratora, wtyczki lub pliki. W panelu CMS konto „admin2”, wtyczka, której nikt nie instalował, pliki ze świeżą datą zmiany w katalogach, których nikt nie ruszał od roku.
8. Strona nagle zwolniła. Google wymienia wśród złośliwego kodu „uruchamianie koparki kryptowalut w przeglądarce, gdy strona jest otwarta” – telefon klienta grzeje się, a wynik wydajności spada o 30 punktów bez żadnej Twojej zmiany.
9. Spam widzi tylko Google. Według Google „wielu hakerów wprowadza zmiany widoczne tylko dla maszyn Google”: linki renderowane tylko wtedy, gdy odwiedzający przychodzi z Google, ukryte przed zalogowanym właścicielem. To zwane jest maskowaniem (cloaking) i dlatego „wszystko wygląda dobrze” nic nie znaczy.

Test w 10 minut

1. site:twojafirma.pl w oknie incognito. Przejrzyj kilka stron wyników. Potem to samo z dopiskiem słów, których na Twojej stronie być nie powinno: site:twojafirma.pl viagra, site:twojafirma.pl casino, site:twojafirma.pl cheap. Każdy wynik to dowód.
2. Wejdź na stronę tak, jak klient: z telefonu, przez wyszukiwarkę Google, nie z zakładki. Sprawdź stronę główną i dwie podstrony. Zwróć uwagę na mignięcie innego adresu przed załadowaniem.
3. Search Console → „Bezpieczeństwo i ręczne działania” → „Problemy dotyczące bezpieczeństwa”. Raport rozróżnia treści zhakowane (złośliwe oprogramowanie, wstrzyknięty kod, wstrzyknięta treść, wstrzyknięte adresy URL), złośliwe i niechciane oprogramowanie oraz inżynierię społeczną (strony wprowadzające w błąd, szkodliwe pliki do pobrania). Przy każdym problemie są przykładowe adresy.
4. Zobacz stronę oczami Google. W Search Console wklej adres w narzędzie do sprawdzania adresów URL i otwórz podgląd zindeksowanej strony – Google zaleca je właśnie do tego, by „zobaczyć stronę tak, jak widzi ją Google”. Jeśli w kodzie są linki lub tekst, których nie widzisz w przeglądarce, masz maskowanie.
5. Dla osób technicznych: pobierz stronę z linii poleceń, udając wejście z Google (Google w swojej pomocy wskazuje cURL lub Wget z własnym nagłówkiem referrer i user-agent) i porównaj z wersją „zwykłą”:

   curl -sL -A "Mozilla/5.0 (Linux; Android 14) Chrome/130 Mobile Safari/537.36" \
     -e "https://www.google.com/" https://twojafirma.pl/ | grep -i -c "casino\|viagra\|<iframe"

   Wynik większy od zera przy stronie, która nie ma nic wspólnego z kasynami, oznacza wstrzykniętą treść.
6. Nie otwieraj podejrzanych podstron w zwykłej przeglądarce. Google ostrzega wprost, że otwarcie zainfekowanej strony „może uszkodzić komputer”. Adresy z raportu sprawdzaj narzędziem z punktu 4 albo z linii poleceń.
7. Zajrzyj do panelu CMS: lista użytkowników (nieznane konta z uprawnieniami administratora), lista wtyczek i motywów (nieznane, nieaktualne), data ostatniej zmiany plików w menedżerze plików hostingu.
8. Zapisz wszystko, co znalazłeś – adresy, zrzuty, daty. Przyda się hostingowi, wykonawcy i w prośbie o ponowne sprawdzenie.

Co zrobić najpierw – w tej kolejności

1. Powiadom hosting. Większość hostingów ma procedurę: skan plików, logi dostępu, informacja, przez co weszli. Poproś o kopię logów z ostatnich 30 dni, zanim zostaną nadpisane.
2. Zmień wszystkie hasła z czystego komputera: panel hostingu, FTP/SFTP, panel CMS (wszyscy administratorzy), baza danych, konto e-mail powiązane ze stroną. Włącz weryfikację dwuetapową tam, gdzie się da. Jeśli hasła były używane gdzie indziej – tam też.
3. Odetnij szkody. Jeśli strona rozsyła złośliwe oprogramowanie lub przekierowuje klientów, włącz stronę konserwacyjną z kodem 503 (mówi Google „wróć później”, nie „strona zniknęła”). Jeśli tylko dopisano spam, możesz czyścić „na żywo”, ale szybko.
4. Przywróć czystą kopię albo wyczyść ręcznie. Google pisze wprost: „zastąp zainfekowane pliki ostatnią dobrą kopią zapasową” lub usuń spam samodzielnie. Kopia musi pochodzić sprzed włamania – data w logach z punktu 1 mówi, która. Po przywróceniu natychmiast zaktualizuj CMS, wtyczki, motyw i PHP, bo stara wersja ma tę samą dziurę. Usuń nieznane konta i wtyczki.
5. Napraw w całej witrynie, nie tylko na przykładach. Google ostrzega, że naprawa „tylko części stron nie da częściowego powrotu do wyników”. Zaplecze włamywacza bywa w kilku miejscach: pliki .htaccess, katalog uploads, zadania cron, konta w bazie.
6. Sprawdź, kto ma dostęp do Search Console i do profilu w Google (użytkownicy i właściciele). Włamywacze bywają sprytniejsi niż właściciele i dodają sobie dostęp, żeby po czyszczeniu wrócić.
7. Poproś o ponowne sprawdzenie. Dopiero gdy wszystkie problemy z raportu są naprawione na wszystkich stronach, kliknij w Search Console „Poproś o sprawdzenie” i opisz, co było i co zrobiłeś – Google chce w prośbie dokładnego opisu problemu, kroków naprawy i efektu. Czas: „od kilku dni do kilku tygodni”. Nie wysyłaj prośby ponownie przed decyzją – przedwczesne, powtarzane prośby mogą skończyć się statusem recydywisty i dłuższym czekaniem.

Objaw → przyczyna → kto naprawia

Jak nie wrócić do tego tekstu

• Aktualizacje w tygodniu wydania, nie „raz na kwartał”. Większość włamań idzie przez znane dziury w wtyczkach, na które poprawka była od tygodni. Dla WordPressa: 10 ustawień bezpieczeństwa na godzinę.
• Kopie zapasowe poza serwerem, codzienne, z co najmniej 30 dniami wstecz – żeby było do czego wrócić, gdy włamanie zauważysz po trzech tygodniach.
• Osobne, długie hasła i 2FA do panelu, hostingu i poczty. Jedno konto administratora na osobę; byłym pracownikom i agencjom dostęp zabieraj tego samego dnia.
• Search Console z Twoim adresem e-mail – darmowe powiadomienie o problemach z bezpieczeństwem i narzędzie do powrotu. Bez tego dowiadujesz się od klientów.
• Nagłówki bezpieczeństwa, zwłaszcza Content-Security-Policy – nie zatrzymają włamania na serwer, ale utrudniają uruchomienie obcych skryptów u klientów: nagłówki po ludzku.
• Ktoś z zewnątrz, kto patrzy codziennie i porówna stronę z wczorajszą: przekierowanie, tytuł, wygląd. Włamanie, które widać w ciągu doby, kosztuje godziny; po miesiącu – pozycje w Google i reputację domeny.

Co sprawdzamy w Webskanie

Nie skanujemy plików na serwerze ani nie usuwamy złośliwego kodu – od tego jest hosting, wykonawca i wtyczki bezpieczeństwa. Patrzymy na stronę z zewnątrz, jak klient i jak Google. Audyt pogłębiony wykrywa rzeczy, które ułatwiają włamanie albo są jego śladem: nagłówki serwera zdradzające wersje oprogramowania, brakujące nagłówki bezpieczeństwa (w tym Content-Security-Policy), formularze wysyłane przez niezaszyfrowane połączenie, mixed content, adres kanoniczny wskazujący inną domenę, blokadę indeksowania i błędne strony. Webskan Monitor sprawdza dostępność co minutę, a raz dziennie porównuje stronę główną z poprzednim dniem i wysyła alert, gdy strona zaczyna przekierowywać na inny adres, traci tytuł albo adres kanoniczny wskazuje obcą domenę, zwraca prawie pustą treść, przestaje przekierowywać na https, albo gdy jej wygląd zmienił się znacząco (ponad jedna trzecia pikseli; w e-mailu są zrzuty wczoraj/dziś, a treść alertu wprost każe sprawdzić, czy to nie włamanie). Czego Monitor nie zobaczy: spamu renderowanego tylko dla Googlebota ani podstron, których nie ma w nawigacji – do tego służy punkt 3 i 4 testu wyżej.

Źródła i narzędzia

• Google Search Console – Centrum pomocy, Raport „Problemy dotyczące bezpieczeństwa” – kategorie problemów, opisy wstrzykniętych adresów/treści/kodu, maskowanie, sprawdzanie strony oczami Google (narzędzie do sprawdzania adresów URL, cURL/Wget), ostrzeżenie przed otwieraniem zainfekowanych stron, prośba o sprawdzenie i jej czas
• Google, How do I know if my site was hacked? – kolejność: Search Console → przykładowe adresy → sprawdzenie maskowania (site:, narzędzie do sprawdzania adresów URL)
• Google, Raport przejrzystości – stan Bezpiecznego przeglądania – sprawdzenie, czy Google oznacza dany adres jako niebezpieczny
• Webskan, WordPress: 10 ustawień bezpieczeństwa na godzinę i Nagłówki bezpieczeństwa HTTP po ludzku