Zhakowana strona: co zrobić, żeby oczyścić ją i wrócić do Google

Krótka odpowiedź: co zrobić, gdy strona jest zhakowana

Najpierw odetnij stronę od użytkowników, zmień wszystkie hasła i powiadom firmę hostingową. Potem usuń to, co dodał atakujący, i załataj lukę, przez którą wszedł. Na końcu, jeśli Google oznaczył stronę w raporcie Problemy dotyczące bezpieczeństwa w Search Console, poproś o sprawdzenie. Kolejność jest ważna: prośba o sprawdzenie strony, która dalej jest zainfekowana, według Google tylko wydłuża czas, przez który witryna jest oznaczona jako niebezpieczna.

Co atakujący robią ze stroną firmy

Google w zasadach dotyczących spamu opisuje „treści zmodyfikowane przez hakerów” jako materiały umieszczone w witrynie bez pozwolenia przez lukę w zabezpieczeniach i wymienia cztery typowe formy:

• wstrzyknięty kod: szkodliwy JavaScript na istniejących stronach albo w elementach iframe;
• wstrzyknięte strony: nowe podstrony ze spamem albo wyłudzaniem danych, podczas gdy Twoje strony wyglądają normalnie;
• wstrzyknięte treści: ukryte linki i tekst, które widzi wyszukiwarka, choć Ty ich nie widzisz;
• przekierowania: część osób trafia na stronę ze spamem, na przykład tylko po kliknięciu wyniku w Google, a po wpisaniu adresu w przeglądarce wszystko działa.

Znany przykład to atak z japońskim spamem SEO. W losowych katalogach powstają nowe strony z automatycznym tekstem po japońsku i linkami do sklepów z podróbkami. Atakujący zwykle dodaje się też jako właściciel w Search Console, żeby zmieniać ustawienia, na przykład mapy witryny.

Google pisze wprost, że hakerzy często stosują maskowanie, żeby właściciel nie zauważył ataku. Dlatego zdanie „u mnie strona działa” niczego nie dowodzi.

Jak sprawdzić, czy strona jest zhakowana

1. W Search Console otwórz raport Problemy dotyczące bezpieczeństwa. Google dzieli w nim problemy na treści zmodyfikowane przez hakerów, złośliwe i niechciane oprogramowanie oraz inżynierię społeczną i pokazuje przykładowe adresy URL.
2. Sprawdź też raport Ręczne działania. Działanie „Witryna zaatakowana spamem przez osoby trzecie” dotyczy głównie spamu na forach, w księgach gości czy w wewnętrznej wyszukiwarce, ale Google przy nim odsyła też do poradnika o zhakowanych stronach.
3. Przejrzyj listę użytkowników i właścicieli w Search Console. Nieznany właściciel to według Google mocny sygnał włamania. Usuń go razem z tokenem weryfikacyjnym, na przykład plikiem HTML na serwerze albo metatagiem na stronie głównej.
4. Wpisz w Google site:twojadomena.pl i przejrzyj kilka stron wyników. Szukaj adresów, których nie tworzyłeś, tytułów po japońsku albo o lekach, kasynach czy podróbkach. Jeśli w Google nic nie widać, Google radzi wpisać to samo w innej wyszukiwarce.
5. Podejrzany adres sprawdź w narzędziu do sprawdzania adresów URL. Zobaczysz stronę tak, jak widzi ją Googlebot, czyli także treść ukrytą przez maskowanie.
6. W raporcie Skuteczność szukaj nagłych skoków wyświetleń i kliknięć na frazy niezwiązane z firmą. W październiku 2026 roku jeden z właścicieli opisywał na Reddicie, że zwykle miał kilkaset kliknięć dziennie, a w dniu włamania kilka tysięcy, na 3 lub 4 frazy.

Uwaga na błąd 404: przy maskowaniu wstrzyknięta strona może pokazywać Ci komunikat, że nie istnieje, a Googlebotowi treść ze spamem.

Jak naprawić zhakowaną stronę krok po kroku

1. Odetnij stronę od odwiedzających

Google zaleca przełączyć witrynę w tryb offline: zatrzymać serwer albo skierować domenę na statyczną stronę na innym serwerze, która zwraca kod 503. Sam kod 4xx lub 5xx z zainfekowanego serwera nie wystarczy, bo dalej może podawać szkodliwe treści. Blokada w robots.txt też nie, bo działa tylko na roboty. Według Google krótkie lub sporadyczne wyłączenie strony na czas naprawy nie powinno wpłynąć na jej pozycje. Ten sam kierunek podał John Mueller z Google 21 października 2026 roku, przy łataniu luki PHP2Shell: kod 503 zamiast przekroczenia czasu, 404 albo 500, ustawiony poza PHP, przez zmianę DNS albo w CDN.

2. Hasła, konta i hosting

Zmień hasła do panelu CMS, FTP, bazy danych i konta hostingowego. Usuń konta, których nie znasz, ale najpierw zapisz ich nazwy. Powiadom firmę hostingową: jeśli atak objął też jej serwer, pomoże ocenić skalę.

3. Usuń zmiany atakującego

Najprościej przywrócić kopię zapasową, ale tylko taką, która powstała przed atakiem, a potem zainstalować wszystkie aktualizacje. Jeśli nie masz czystej kopii, Google zaleca czystą instalację systemu i dodatków zamiast samej aktualizacji. W obu przypadkach usuń nieużywane wtyczki i sprawdź plik .htaccess. Atakujący potrafi ukryć w nim regułę weryfikacji Search Console, więc jeśli nie masz własnych reguł, Google radzi zastąpić ten plik nową kopią. Sprawdź też mapy witryny: hakerzy dopisują do nich swoje adresy, żeby Google szybciej je zindeksował.

4. Ustaw kod 404 dla adresów dodanych przez atakującego

Strony utworzone przez atakującego usuń i ustaw dla nich kod 404, a z indeksu znikną z czasem. Różnicę między 404 a 410 opisujemy w tekście o błędzie 404 i kiedy jest w porządku. Gdy takich stron jest dużo albo szkodzą użytkownikom, możesz przyspieszyć sprawę narzędziem do tymczasowego usuwania adresów z Google. Nie używaj go dla własnych stron, które atakujący tylko zmienił: po oczyszczeniu mają wrócić do wyników.

5. Załataj lukę

Bez tego atakujący może wejść ponownie tą samą drogą. Google wśród najczęstszych przyczyn wymienia między innymi odgadnięte hasła, stare oprogramowanie oraz nieaktualne motywy i wtyczki.

Prośba o sprawdzenie i czas oczekiwania

Zanim klikniesz, Google wymaga czterech rzeczy: zweryfikowanej własności w Search Console, oczyszczonej strony, usuniętej luki i strony z powrotem online. Strony muszą być dostępne dla Googlebota, bez noindex.

1. Otwórz raport Problemy dotyczące bezpieczeństwa i znajdź problem.
2. Kliknij Poproś o sprawdzenie.
3. Dla każdej kategorii problemu napisz krótko, co zrobiłeś, na przykład: „Usunęliśmy wstrzyknięte strony ze spamem i zaktualizowaliśmy przestarzałą wtyczkę, przez którą nastąpiło włamanie”.

Według aktualnej pomocy Search Console sprawdzenie może potrwać od kilku dni do kilku tygodni. Starszy poradnik Google podaje: przy spamie od hakera nawet kilka tygodni, przy złośliwym oprogramowaniu kilka dni, przy wyłudzaniu danych około jednego dnia. Przy złośliwym oprogramowaniu odpowiedź przyjdzie w wiadomościach Search Console. Przy spamie od hakera po zatwierdzeniu problemy znikną z raportu Problemy dotyczące bezpieczeństwa. Po zatwierdzeniu ostrzeżenia w wynikach i przeglądarkach znikają w ciągu 72 godzin. Jeśli Google znajdzie dalsze problemy, ostrzeżenia zostaną, a raport może pokazać kolejne przykładowe adresy.

Nie wysyłaj prośby na próbę: według Google prośba o sprawdzenie wciąż zainfekowanej strony tylko wydłuża czas, przez który jest oznaczona jako niebezpieczna. Uważaj też na ponowne infekcje. Strony, które w krótkim czasie wielokrotnie przechodzą od stanu bezpiecznego do niebezpiecznego, Bezpieczne przeglądanie Google uznaje za recydywistów, a wtedy przez 30 dni nie poprosisz o sprawdzenie w Search Console.

Jeśli raporty nie pokazują problemu, nie wyślesz z nich prośby o sprawdzenie. Przy błędnym ostrzeżeniu o wyłudzaniu danych albo po oczyszczeniu strony phishingowej Google przyjmuje też zgłoszenie przez osobny formularz Bezpiecznego przeglądania. Poza tym możesz poczekać na ponowną wizytę Googlebota albo poprosić o ponowne przeskanowanie oczyszczonych adresów w narzędziu do sprawdzania adresów URL.

Co się działo w 2026 roku: WordPress i PHP

Jesień 2026 roku przyniosła kilka zdarzeń związanych z bezpieczeństwem WordPressa, jego wtyczek i PHP:

• 22 września WordPress opublikował poprawkę krytycznej luki (ocena 9,2 na 10) w wersjach od 4.7 do 7.1.1. Przy dwóch warunkach pozwalała bez logowania uruchomić kod na serwerze: aktywny motyw ma katalog zaczynający się od page- (na przykład Twenty Twelve, Twenty Fourteen, Neve, Hestia czy Sydney), a na serwerze jest odpowiedni plik PHP, na przykład pearcmd.php przy włączonym register_argc_argv. Poprawione wersje to między innymi 7.1.2, 7.0.6 i 6.9.9.
• 1 i 2 października Wordfence opisał dwie luki średniej wagi we wtyczce All in One SEO, używanej na ponad 2 milionach stron. Poprawka: wersja 5.0.2.1.
• 6 października wyszedł WordPress 7.1.3 z poprawkami 7 luk.
• 17 i 18 października firma TeamUpdraft wykryła nieautoryzowany dostęp do swojego serwisu. Według firmy atakujący dostali się do bazy klientów, w której były też klucze UpdraftCentral. Potem instalowali złośliwe wtyczki na stronach z UpdraftPlus (ponad 3 miliony instalacji), które miały aktywne połączenie z UpdraftCentral Cloud. Wersje 1.26.13 i 2.26.13 odcinają klucze, ale nie usuwają złośliwych wtyczek ani kont, które już powstały. Te konta mogą mieć rolę redaktora z dodanymi uprawnieniami administratora.
• 21 października wydano PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12 z poprawkami dwóch luk pozwalających zdalnie uruchomić kod na serwerze, nazwanych PHP2Shell. Starsze wersje, od 5.4 do 8.1, też są podatne, a projekt PHP ich już nie aktualizuje. Dla 7.4, 8.0 i 8.1 udostępnił tylko poprawki do samodzielnej kompilacji. Exploity krążyły już wcześniej.

Co z tego wynika, to nasz wniosek: aktualizacja po fakcie nie usuwa skutków włamania. Jeśli strona miała podatną wersję w tym okresie, przejrzyj listę wtyczek, wszystkie konta użytkowników wraz z ich uprawnieniami oraz wyniki site:, nawet jeśli Search Console nic nie pokazuje.

Kiedy oddać sprawę specjaliście

Jeśli strona po oczyszczeniu wypadła z indeksu, raport bezpieczeństwa wraca z nowymi adresami albo nie wiesz, którędy wszedł atakujący, opisz nam problem: sprawdzimy stronę tak, jak widzi ją Google, i powiemy, co trzeba zrobić, żeby wróciła do wyników.