Strona WordPress zhakowana? Google pokazuje ostrzeżenie – procedura

Zamiast strony odwiedzający widzi czerwony ekran z komunikatem „Deceptive site ahead” albo „Ta witryna zawiera złośliwe oprogramowanie”. Albo strona otwiera się normalnie u Ciebie, ale po kliknięciu w wynik Google przerzuca na obcą domenę. Albo w wynikach wyszukiwania pod Twoim adresem widnieje podpis „Ta witryna mogła zostać zhakowana”. Każdy z tych objawów oznacza to samo dla biznesu: ruch, który przez lata budowałeś, właśnie przestał docierać na stronę, a klienci, którzy jednak weszli, zobaczyli ostrzeżenie o zagrożeniu z Twoją domeną w tytule.

Poniżej masz procedurę: co zrobić w pierwszych trzydziestu minutach, jak odróżnić włamanie od zwykłej awarii, jak wyczyścić stronę, co wymienić poza hasłem do panelu, jak zgłosić stronę do ponownej weryfikacji w Google i dlaczego u wielu osób infekcja wraca po tygodniu. To procedura obronna i naprawcza – nie znajdziesz tu ani narzędzi ataku, ani opisu, jak takie włamanie przeprowadzić.

Kolejność ma znaczenie. Pierwsze cztery kroki zatrzymują straty, reszta przygotowuje czyszczenie.

1. Niczego nie kasuj. Skasowany plik to dowód, którego nie odzyskasz, a bez niego nie ustalisz, którędy ktoś wszedł.
2. Zrób kopię stanu obecnego – pliki i baza danych, nawet zainfekowane. Bez niej nie porównasz, co się zmieniło, a przy nieudanym czyszczeniu nie będzie do czego wrócić.
3. Zablokuj stronę dla odwiedzających – tryb konserwacji, hasło na katalog albo wyłączenie strony w panelu hostingu. Jeśli strona rozsyła złośliwe pliki, każda minuta pracy pogłębia problem z listami ostrzeżeń.
4. Zmień hasła z czystego urządzenia: panel hostingu, FTP/SFTP, baza danych, konta administratorów WordPressa. Nie z komputera, na którym mogłeś mieć trojana.
5. Wyloguj wszystkie sesje – wymiana kluczy w wp-config.php (opisana niżej). Sama zmiana hasła nie zrywa sesji, która już trwa.
6. Sprawdź listę użytkowników w Kokpit → Użytkownicy. Konto administratora, którego nie zakładałeś, to potwierdzenie włamania, nie podejrzenie.
7. Otwórz Search Console → Problemy dotyczące bezpieczeństwa. Tam jest napisane, co dokładnie widzi Google i w której kategorii Cię zakwalifikował.
8. Napisz do hostingu. Na serwerze współdzielonym mogło ucierpieć więcej stron, a hosting ma logi dostępu, których Ty nie masz.
9. Sklep WooCommerce: sprawdź konfigurację płatności – metody płatności, dane odbioru przelewów, adresy powiadomień o zamówieniach. To pierwsze miejsce, gdzie włamanie zamienia się w bezpośrednią stratę pieniędzy.
10. Nie zgłaszaj jeszcze prośby o sprawdzenie do Google. Wniosek złożony przed wyczyszczeniem zostanie odrzucony i wydłuży rozpatrzenie kolejnego.

Jeśli prowadzisz sklep i każda godzina przestoju ma cenę, zadzwoń zamiast czytać dalej: +48 575 067 607.

Część objawów włamania wygląda identycznie jak zwykła usterka i odwrotnie – kilka osób miesięcznie czyści serwer po nieudanej aktualizacji wtyczki. Rozróżnienie jest ważne, bo procedury są całkiem inne: awarię się cofa, włamanie się czyści i zamyka.

Dwa objawy warto wykluczyć w pierwszej kolejności, bo mają zupełnie inną naprawę. Jeśli problem pojawił się dokładnie po aktualizacji, zacznij od objawów, które daje sama aktualizacja WordPressa – cofnięcie zmiany zajmuje kwadrans i nie wymaga niczego więcej. Jeśli widzisz wyłącznie komunikat serwera bez śladów obcej treści, sprawdź listę przyczyn błędu 500, zanim uznasz, że ktoś Cię zaatakował.

Trzy miejsca, w których włamanie widać niezależnie od tego, co pokazuje przeglądarka: raport „Problemy dotyczące bezpieczeństwa” w Search Console, publiczny raport Google Safe Browsing dla Twojej domeny oraz logi dostępu i skan antywirusowy po stronie hostingu.

Ostrzeżenia bywają mylone ze sobą, a różnią się źródłem i skutkiem.

Trzy rzeczy, które trzeba rozdzielić. Czerwony ekran w przeglądarce pochodzi z Google Safe Browsing i widzą go użytkownicy Chrome, Firefoxa i Safari – czyli praktycznie wszyscy. Podpis w wynikach wyszukiwania to osobna sygnalizacja: strona jest dostępna, ale traci klikalność. Blokada hostingu to decyzja Twojego dostawcy i zdejmuje ją dostawca, nie Google.

Ostrzeżenia Google nie zdejmuje ani hosting, ani usunięcie pliku, ani czekanie. Zdejmuje je Google – po wyczyszczeniu strony i po zgłoszeniu prośby o sprawdzenie w Search Console. Do tego momentu ostrzeżenie zostaje, nawet jeśli strona jest już czysta od trzech dni.

Kolejność jest odwrotna do intuicyjnej: zaczynasz nie od szukania złośliwego kodu, tylko od ustalenia, gdzie sięga włamanie i z czym w ogóle porównujesz pliki. Szukanie „czegoś podejrzanego” bez punktu odniesienia to metoda, która kończy się usunięciem tego, co widać, i zostawieniem tego, czego nie widać.

Zapisz datę i godzinę pierwszego objawu, kto co robił w ostatnich dniach, jakie wtyczki instalowano, czy ktoś dostał podejrzaną wiadomość. Ten opis to podstawa raportu z incydentu – przyda się i Tobie, i osobie, która ewentualnie przejmie sprawę.

Włamanie rzadko kończy się na katalogu WordPressa. Sprawdź, czy na tym samym koncie hostingowym nie stoją inne strony, czy nie ma dodatkowych katalogów poza public_html, czy w panelu hostingu nie pojawiły się nowe konta FTP, przekierowania poczty ani zadania cron. Wyczyszczenie jednej strony na koncie, na którym stoi pięć, kończy się powrotem infekcji w ciągu doby.

Najpewniejszy sposób znalezienia zmian nie polega na szukaniu podejrzanych fragmentów kodu, tylko na porównaniu tego, co masz, z tym, co powinno być. WordPress i wtyczki z oficjalnego katalogu mają sumy kontrolne:

Bez dostępu do WP-CLI to samo zrobisz ręcznie – pobierz z wordpress.org tę samą wersję, którą masz na stronie, i porównaj katalogi:

Pierwsze polecenie wypisuje pliki PHP zmienione w ciągu dwóch tygodni. Drugie pokazuje, czym Twój wp-includes różni się od oryginalnego. Każda różnica wymaga wyjaśnienia – pliku, którego nie ma w czystej paczce, nie da się „naprawić”, tylko usunąć.

Wgraj przez FTP katalogi wp-admin i wp-includes z czystej paczki, z nadpisaniem. Nie wgrywaj wp-content ani wp-config.php.

Wtyczki z oficjalnego katalogu usuń i zainstaluj od nowa w bieżącej wersji. Wtyczki premium pobierz ponownie z konta u producenta. Motyw potraktuj tak samo – z jednym wyjątkiem: jeśli ktoś dopisywał kod do functions.php motywu, przenieś tę część świadomie, linia po linii, a nie kopiując cały plik.

Wtyczki i motywy, których nie używasz, po prostu skasuj. Wyłączony kod nadal leży na serwerze i nadal daje się wykonać.

W katalogu z mediami mają leżeć wyłącznie media. Plik .php w uploads nie ma tam czego szukać niezależnie od nazwy.

Plik .htaccess bywa nie jeden – sprawdź katalog główny, wp-admin, wp-content i uploads. Zregeneruj go, zapisując Ustawienia → Bezpośrednie odnośniki, a reguły, które naprawdę potrzebujesz, dodaj z powrotem pojedynczo.

Osobno przejrzyj cztery pliki, które wpływają na każde żądanie: index.php, header.php, footer.php i functions.php.

W bazie sprawdź: tabelę użytkowników (konta i ich role), tabelę opcji pod kątem wpisów, które wykonują kod przy każdym ładowaniu strony, oraz treść wpisów i stron pod kątem doklejonych odnośników i przekierowań. Zajrzyj też do zaplanowanych zadań (cron w opcjach) – zadanie, które co godzinę przywraca usunięty plik, potrafi udawać, że czyszczenie nie działa.

Uruchom skan zdalny (skaner odpytuje stronę jak zwykły odwiedzający) oraz skan aplikacyjny z wtyczki, która widzi pliki na dysku. Te dwa rodzaje narzędzi wykrywają co innego i żadne z nich osobno nie wystarczy.

Zmiana hasła do WordPressa to jedna pozycja z listy, na której jest ich siedem. Pominięcie choćby jednej sprawia, że atakujący wraca bez potrzeby ponownego szukania drogi wejścia.

Klucze uwierzytelniania wygenerujesz pod adresem api.wordpress.org/secret-key/1.1/salt/. Wynik zastępuje istniejący blok w wp-config.php:

Po zapisaniu pliku wszyscy – Ty też – zostaną wylogowani. To znaczy, że zadziałało.

Ostatnia rzecz z tej listy, o której zapomina prawie każdy: hasła zmienia się dwa razy. Raz na początku, żeby odciąć dostęp w trakcie czyszczenia, i drugi raz po zakończeniu, bo w trakcie pracy nowe hasła mogły przejść przez środowisko, które wciąż było zainfekowane.

Techniczna część odpowiedzi jest wykonalna. Ustal, do czego dało się dostać z poziomu, na którym był atakujący: baza sklepu z zamówieniami i adresami, zgłoszenia z formularzy, lista subskrybentów newslettera, załączniki, kopie zapasowe leżące w katalogu publicznym. Sprawdź logi dostępu pod kątem pobrań plików kopii i nietypowo dużego ruchu wychodzącego. Jeżeli sklep przyjmuje płatności przez zewnętrzną bramkę, dane kart nie leżą u Ciebie – ale dane osobowe, adresy i historia zamówień już tak.

Część prawna wygląda inaczej i tu kończy się rola tego tekstu. Incydent obejmujący dane osobowe ma własny reżim zgłoszeniowy i własne terminy, a ocena, czy w Twoim przypadku doszło do naruszenia i co z niego wynika, należy do administratora danych – czyli do Ciebie jako właściciela strony lub sklepu. To pytanie do prawnika albo inspektora ochrony danych, nie do osoby czyszczącej serwer, i nie do artykułu w internecie, włącznie z tym. Zadaj je od razu, równolegle z czyszczeniem, a nie po zamknięciu tematu technicznego.

Praktyczna konsekwencja dla czyszczenia: to kolejny powód, żeby nie kasować dowodów. Bez logów i bez kopii stanu sprzed czyszczenia nikt nie będzie w stanie ocenić zakresu incydentu.

Kolejność jest sztywna: najpierw czysta strona, potem wniosek.

1. Otwórz Search Console i przejdź do raportu Problemy dotyczące bezpieczeństwa. Zobaczysz kategorię problemu i przykładowe adresy – Google rozróżnia między innymi wstrzyknięcie kodu, wstrzyknięcie treści, złośliwe oprogramowanie i strony wprowadzające w błąd.
2. Otwórz kilka wskazanych adresów i potwierdź, że problem zniknął. Adres z listy, który nadal pokazuje obcą treść, przekreśla cały wniosek.
3. Kliknij Poproś o sprawdzenie i opisz, co zrobiłeś.
4. Czekaj. Google podaje, że rozpatrzenie zajmuje zwykle od kilku dni do kilku tygodni.

Wniosek rozpatruje człowiek i czyta ten opis. Krótki, konkretny opis wygląda tak:

Strona przyklad.pl została zainfekowana; problem wykryty 05.09.2026. Wymieniliśmy pliki rdzenia z czystej paczki w tej samej wersji, przeinstalowaliśmy wszystkie wtyczki i motyw, usunęliśmy pliki PHP z katalogu uploads oraz nieautoryzowane konto administratora, zregenerowaliśmy .htaccess i wyczyściliśmy wpisy w bazie. Wymieniliśmy hasła do WordPressa, FTP, bazy i panelu hostingu oraz klucze uwierzytelniania w wp-config.php. Zamknęliśmy drogę wejścia: [tu wpisz, co konkretnie]. Strona przeszła skan zdalny i aplikacyjny bez wykryć. Prosimy o ponowne sprawdzenie.

Osobno pamiętaj o dwóch rzeczach poza Google: zgłoś stronę w Bing Webmaster Tools, jeśli tam też jest oznaczona, i skontaktuj się z hostingiem, jeśli to on zablokował stronę – jego blokady Google nie zdejmie.

To pytanie zadaje większość osób, które czyściły stronę samodzielnie. Odpowiedź prawie zawsze mieści się w tej tabeli.

Trzeba przy tym powiedzieć rzecz, którą pomijają poradniki obiecujące wyczyszczenie w pół godziny: nie każdą infekcję da się wiarygodnie wyczyścić w miejscu. Przy ręcznie modyfikowanym motywie, wtyczkach spoza oficjalnego katalogu i kodzie pisanym na zamówienie nie ma z czym porównać plików. Można wtedy powiedzieć „skan nic nie znalazł”, ale nie można powiedzieć „ten plik jest czysty” – a to dwa różne zdania.

Wybór między jednym a drugim to decyzja o tym, jakie ryzyko akceptujesz – a nie o tym, która metoda jest „porządniejsza”.

Czyszczenie kończy incydent. Nie kończy przyczyny.

1. Włącz uwierzytelnianie dwuskładnikowe dla wszystkich kont z rolą administratora.
2. Ogranicz liczbę administratorów. Osoba, która dodaje wpisy na bloga, nie potrzebuje roli administratora – wystarczy redaktor.
3. Zablokuj edycję plików z panelu. Jedna linia w wp-config.php zdejmuje edytor motywu i wtyczek, przez który wygodnie wkleja się obcy kod:

1. Aktualizuj WordPressa, wtyczki i motyw – na kopii testowej, nie na produkcji.
2. Usuń wszystko, czego nie używasz. Nieaktywna wtyczka to nadal kod na serwerze.
3. Utrzymuj wspieraną wersję PHP. Wersje bez poprawek bezpieczeństwa to problem, który narasta w tle.
4. Trzymaj kopie poza hostingiem, z retencją liczoną w tygodniach, i raz na jakiś czas sprawdź, czy da się z nich odtworzyć stronę. Kopia, której nikt nie odtworzył, jest hipotezą, nie zabezpieczeniem.
5. Włącz monitoring, który wykrywa zmianę treści, nie tylko dostępność strony. Przekierowanie wstrzyknięte w nocy nie wywoła błędu – strona odpowiada kodem 200 i wygląda dobrze z Twojego adresu IP.
6. Sprawdzaj listę kont w WordPressie, w panelu hostingu i w FTP – regularnie, a nie po incydencie.

Punkty 4, 7 i 8 to praca cykliczna, która ma sens tylko wtedy, gdy ktoś ją naprawdę wykonuje co tydzień. Jeśli w firmie nie ma osoby, która to robi, sensowniej jest oddać ten zestaw na zewnątrz – na tym polega stała opieka techniczna nad stroną: aktualizacje wchodzą najpierw na kopię, kopie zapasowe leżą poza serwerem, a skan bezpieczeństwa biegnie co tydzień, nie po telefonie od klienta.

Część przypadków da się zamknąć samodzielnie w kilka godzin. Poniższe do nich nie należą:

• Sklep przyjmuje płatności. Ryzyko nie kończy się na przestoju: chodzi o dane zamówień, konfigurację bramki i zaufanie klientów, którzy właśnie zobaczyli ostrzeżenie z Twoją domeną.
• Nie masz dostępu do hostingu ani FTP, bo stronę robił ktoś, kto przestał odpowiadać. Wtedy pierwszym krokiem jest odzyskanie dostępów po wykonawcy.
• Strona ma kod pisany na zamówienie i nie wiesz, co robi połowa plików. Bez punktu odniesienia „czysty” jest nieweryfikowalne.
• Infekcja wróciła po czyszczeniu. Drugi raz ta sama metoda da ten sam wynik – brakuje ustalenia drogi wejścia, a to inna praca niż usuwanie plików.
• Ostrzeżenie Google wisi od kilku dni. Każdy dzień to ruch, który nie wraca sam po zdjęciu blokady – pozycje odbudowują się tygodniami.
• Podejrzewasz, że wyciekły dane osobowe. Tu decyzje trzeba podejmować równolegle z czyszczeniem i z udziałem prawnika, a nie po fakcie.

W tych sytuacjach są dwie drogi. Jednorazowe czyszczenie po włamaniu: ktoś przechodzi procedurę do końca, ustala drogę wejścia, zgłasza stronę do weryfikacji i przekazuje raport z tego, co znalazł. Albo stała opieka, w której skan bezpieczeństwa, kopie poza serwerem i testowane aktualizacje odbierają temat z Twojej listy. Awarię wyłączającą stronę lub sprzedaż bierzemy od razu, poza kolejnością – również u kogoś, kto jeszcze nie jest naszym klientem.

Włamanie na stronę WordPress ma trzy warstwy i mylenie ich ze sobą kosztuje najwięcej. Warstwa pierwsza to objawy – przekierowania, obce podstrony, ostrzeżenie w przeglądarce. Warstwa druga to czyszczenie: wymiana plików z oryginału, uporządkowanie bazy, wymiana haseł, kluczy i sesji w komplecie. Warstwa trzecia, najczęściej pomijana, to droga wejścia – dopóki jest otwarta, dwie pierwsze robi się w kółko.

Ostrzeżenia Google nie zdejmie ani hosting, ani czas. Zdejmuje je Google, po wyczyszczeniu strony i po zgłoszeniu prośby o sprawdzenie – i dlatego wniosek wysłany za wcześnie jest gorszy niż niewysłany wcale.

Jeśli strona jest zablokowana, sklep nie sprzedaje albo infekcja wróciła po Twoim czyszczeniu, zadzwoń: +48 575 067 607. Możesz też zgłosić stronę do wyczyszczenia – przejdziemy procedurę do końca, ustalimy drogę wejścia i zgłosimy stronę do ponownej weryfikacji. A jeśli wolisz, żeby o skanach, kopiach i aktualizacjach myślał ktoś inny, pakiety opieki zaczynają się od 349 zł netto miesięcznie.

Źródła:

• FAQ My site was hacked – dokumentacja WordPress: https://wordpress.org/documentation/article/faq-my-site-was-hacked/
• Hardening WordPress – dokumentacja WordPress: https://wordpress.org/documentation/article/hardening-wordpress/
• Editing wp-config.php – dokumentacja WordPress: https://developer.wordpress.org/apis/wp-config-php/
• WordPress secret key generator: https://api.wordpress.org/secret-key/1.1/salt/
• Security Issues report – pomoc Google Search Console: https://support.google.com/webmasters/answer/9044101
• Malware and unwanted software – Google Search Central: https://developers.google.com/search/docs/monitor-debug/security/malware
• Social engineering (phishing and deceptive sites) – Google Search Central: https://developers.google.com/search/docs/monitor-debug/security/social-engineering
• Google Safe Browsing – raport przejrzystości: https://transparencyreport.google.com/safe-browsing/search
• Zgłaszanie naruszeń ochrony danych osobowych – UODO: https://uodo.gov.pl/pl/134/233