Zhakowana strona WordPress: co robić krok po kroku

Czerwone ostrzeżenie w Chrome, przekierowanie na obcą domenę i panel administracyjny, w którym wszystko wygląda jak zawsze. Tryb awaryjny dla witryny na WordPressie: czego nie wolno zrobić w pierwszej godzinie, gdzie naprawdę kryje się infekcja i jak pozbyć się ostrzeżenia Google'a.

W czwartek rano dzwoni klient i mówi, że Chrome zamiast Państwa sklepu wyświetla mu na całym ekranie czerwone ostrzeżenie; otwierają Państwo witrynę w telefonie, a przeglądarka po półtorej sekundy wyrzuca ją na zupełnie obcą domenę — za to na służbowym komputerze, na którym panel administracyjny jest otwarty od poniedziałku, wszystko wygląda dokładnie tak jak zawsze. Tak najczęściej wygląda zhakowana strona WordPress: nie podmieniona strona główna z podpisem napastnika, tylko witryna, która właścicielowi pokazuje jedną twarz, a odwiedzającym drugą — i dlatego pierwsze godziny mijają zwykle na sporze o to, czy problem w ogóle istnieje.

Pytania, na które jest tu odpowiedź, padają zwykle dokładnie w tej kolejności: co wolno, a czego nie wolno zrobić w pierwszej godzinie, dopóki nikt jeszcze nie wie, jak głęboko napastnik wszedł; gdzie w instalacji WordPressa kod bywa ukryty, bo bez tego czyszczenie jest zgadywanką; oraz jak doprowadzić do zdjęcia ostrzeżenia Google'a, nie psując sobie drugiego podejścia. Pośrodku zostaje krok pomijany przez właścicieli najczęściej — wymiana danych dostępowych we właściwym momencie i we właściwej kolejności.

Wszystko, co trzeba zrobić w najbliższych godzinach, jest tutaj i po drodze nie trzeba nigdzie zaglądać. Poza tekstem zostało tylko to, co przydaje się później, kiedy witryna znowu działa — strategia kopii zapasowych, utwardzanie systemu i ochrona przed następnym razem, taka sama niezależnie od platformy — a osobny przewodnik o tym wskazujemy dalej. Rzecz idzie o to, co WordPressa odróżnia: ekosystem wtyczek, katalog wp-content, tabele bazy danych, w których infekcja przeżywa czyszczenie plików, i polecenia obiecujące więcej, niż faktycznie sprawdzają. Z naszego doświadczenia to właśnie te cztery rzeczy decydują, czy witryna jest czysta po jednym dniu, czy dopiero za trzecim podejściem.

Pierwsza godzina: nie usuwać niczego

Pierwszy odruch jest niemal zawsze jednym z dwóch — otworzyć menedżer plików u hostingodawcy, znaleźć tam coś obcego i to skasować albo nacisnąć przycisk przywracający wczorajszą kopię zapasową. Prosimy nie robić ani jednego, ani drugiego, a powód jest praktyczny, nie biurokratyczny. Pośpiech jest zrozumiały, bo każda godzina z czerwonym ostrzeżeniem kosztuje odwiedzających, ale to właśnie w pośpiechu zapadają dwie decyzje, które wydłużają odzyskiwanie z ośmiu godzin do tygodnia, i obie są nieodwracalne.

Kiedy zainfekowane pliki zostają skasowane, znika też jedyny materiał, po którym da się później ustalić punkt wejścia: czasy modyfikacji plików, zawartość skryptów wgranych przez napastnika i wpisy w serwerowym dzienniku dostępu pokrywające się z tymi czasami. Bez punktu wejścia czyszczenie usuwa wyłącznie objawy, a cena za to została zmierzona — w badaniu Google i Uniwersytetu Kalifornijskiego w Berkeley, obejmującym 760 935 przypadków przejęcia witryn między lipcem 2014 a czerwcem 2015 roku, 12% stron zostało zhakowanych ponownie w ciągu 30 dni, bo usunięto objawy, a nie przyczynę (Li i in., WWW 2016).

Dlatego pierwszą czynnością jest pełna kopia — wszystkie pliki i cała baza danych za jednym razem, zanim ktokolwiek ruszy choćby jeden bajt, bo widoczne przekierowanie albo podmieniona strona główna rzadko są wszystkim, co się w witrynie dzieje: według danych Sucuri w 2023 roku na 49,21% zainfekowanych stron znaleziono co najmniej jeden backdoor (tylne drzwi), a w ciągu roku zespół tej firmy usunął 21 062 takie programy (Sucuri, „2023 Hacked Website & Malware Threat Report”, czerwiec 2024). Kopię trzeba trzymać poza tym samym serwerem, bo to właśnie tam napastnik wciąż ma dostęp.

Następny telefon idzie do firmy hostingowej i nie z grzeczności: to ona ma dzienniki dostępu, które w Państwa panelu widać zwykle tylko kilka dni wstecz, a na serwerze współdzielonym musi sprawdzić, czy to samo nie dzieje się na sąsiednich kontach. Jeśli witryna przyjmuje płatności albo zbiera dane osobowe, w tym momencie trzeba ją wyłączyć lub włączyć tryb konserwacji — każdy odwiedzający, który w ciągu najbliższej godziny wpisze dane karty, to osobny problem, którego jeszcze Państwo nie mają. Tryb konserwacji kosztuje jeden dzień obrotu; przegapiony moment kosztuje list do klientów.

Jeśli wp-admin już się nie otwiera — na zhakowanej witrynie tak bywa — trybu konserwacji z panelu włączyć się nie da i zostają dwie drogi: w pliku .htaccess w katalogu głównym dopisać regułę, która wszystkich poza Państwa adresem IP odsyła na jedną statyczną stronę z komunikatem o pracach technicznych, albo w tej samej rozmowie poprosić hostingodawcę o czasowe zawieszenie konta. Druga możliwość wygląda brutalnie, ale działa również wtedy, gdy do plików nie ma już dostępu.

Wczorajsza kopia zapasowa wygląda na najkrótszą drogę powrotną i czasem rzeczywiście jest właściwym krokiem, ale tylko wtedy, gdy wiadomo, którego dnia napastnik wszedł. Z naszego doświadczenia infekcję zauważa się znacznie później, niż się zaczęła — kod najpierw przez jakiś czas milczy, a dopiero potem zaczyna serwować strony spamowe albo przekierowania — co znaczy, że we wczorajszej kopii tylne drzwi najpewniej już siedzą. Przywrócenie ukrywa wtedy objawy na parę godzin i cofa witrynę dokładnie do stanu, w którym ją kiedyś zhakowano, dlatego odzyskiwanie zhakowanej strony zaczynamy zwykle w ciągu kilku godzin i nawet w pośpiechu zaczynamy od kopii, a nie od kasowania — także wtedy, gdy klient dzwoni i prosi, żeby po prostu szybko wszystko wyczyścić.

Zhakowana strona WordPress — po czym ją poznać

Przekierowanie, które działa u odwiedzającego przychodzącego z wyniku Google, a nie działa, gdy adres wpisze się w pasku przeglądarki, nie jest nieporozumieniem, tylko świadomym wyborem napastnika: w politykach Google dotyczących spamu przekierowania są osobno wymienionym rodzajem zhakowanej treści, w którym napastnik wstrzykuje kod przekierowujący tylko część użytkowników na złośliwe lub spamerskie strony (Google Search Central, sprawdzone w sierpniu 2026 roku). I właśnie to „tylko część” wprowadza właściciela w błąd. Sprawdzenie zajmuje minutę: otworzyć witrynę w oknie incognito, potem znaleźć ją w wynikach Google i wejść stamtąd, a następnie powtórzyć jedno i drugie na telefonie.

Druga grupa objawów siedzi po stronie administracyjnej i jest znacznie konkretniejsza: wp-admin nagle zwraca 404, formularz logowania po poprawnym haśle po prostu ładuje się od nowa, na liście użytkowników jest konto administratora, którego nikt z Państwa zespołu nie zakładał, albo w Ustawieniach → Ogólne adres witryny nie jest już Państwa. W bazie danych ten ostatni objaw to tylko dwa wiersze w tabeli wp_options — siteurl i home — i właśnie dlatego adres widoczny w ustawieniach i adres, na którym ląduje odwiedzający, mogą się różnić.

Trzecia grupa przychodzi z zewnątrz i boli najbardziej, bo o stanie Państwa witryny mówi ktoś inny: firma hostingowa bez ostrzeżenia zawiesza konto, z którego wyszedł spam, w Search Console pojawia się wpis o problemie z bezpieczeństwem albo obok witryny w wynikach wyszukiwania wyświetla się etykieta „Ta strona mogła paść ofiarą ataku hakerów”, którą Google pokazuje, gdy uzna, że napastnik zmienił istniejące podstrony lub dodał nowe strony spamowe (pomoc wyszukiwarki Google, sprawdzona w sierpniu 2026 roku). Tę etykietę Google dokłada z własnej inicjatywy, a nie po czyjejś skardze, i pojawia się ona także wtedy, gdy witryna wydaje się Państwu nienaganna.

Nazwy nie są tu kwestią akademicką, bo po nich będą Państwo szukać rozwiązania i po nich oceniać, czy wykonawca rozumie Państwa przypadek: Google w swojej dokumentacji wymienia trzy — gibberish hack, Japanese keyword hack oraz cloaked keywords and links hack, w którym strony utworzone przez napastnika pokazują wyszukiwarce jedną treść, a odwiedzającemu inną. Popularny w branży „pharma hack” pochodzi od firmy Sucuri (2020) i w dokumentacji Google go nie ma. Praktyczne sprawdzenie jest jednak dla wszystkich trzech takie samo: wpisać w wyszukiwarce zapytanie site: ze swoją domeną, a podstrony, których nikt w Państwa firmie nie napisał, widać od razu. W wariancie japońskim są to automatycznie generowane strony z japońskimi nagłówkami, w losowo nazwanych katalogach i z Państwa domeną w adresie.

A teraz część nieprzyjemna: czysty wynik skanowania nie dowodzi, że witryna jest czysta, bo skaner widzi tylko to, co serwer mu pokaże, a kod napastnika często rozpoznaje skanery i roboty wyszukiwarek; Google w swoim poradniku o maskowanych frazach ostrzega, że włamanie bywa ukrywane tak, aby właściciel uwierzył, że problem już minął. Jeśli skan jest czysty, a hostingodawca skarży się na wychodzącą pocztę, proszę wierzyć hostingodawcy. Wtedy na miejscu jest audyt bezpieczeństwa strony internetowej z ręcznym przeglądem plików i dzienników, bo skaner odpowiada na pytanie, czy w witrynie jest coś z listy znanych wzorców, a nie na to, czy ktoś wciąż w niej siedzi.

Gdzie naprawdę leży ryzyko WordPressa

Z naszego doświadczenia, kiedy przyczyna w końcu się znajduje, prawie nigdy nie jest nią sam rdzeń WordPressa. W raporcie Patchstack „State of WordPress Security in 2026” naliczono 11 334 nowe podatności ujawnione w ekosystemie WordPressa w 2025 roku — o 42% więcej niż rok wcześniej — a najważniejszy jest teraz rozkład tej liczby: 91% z nich dotyczyło wtyczek, 9% motywów, a w samym rdzeniu WordPressa przez cały rok zgłoszono tylko sześć, w dodatku wszystkie o niskim priorytecie. Prawie każda nowo odkryta podatność siedzi więc nie w tym WordPressie, który kiedyś Państwo zainstalowali, ale w tym, co przez lata do niego dołożono.

Każda wtyczka to osobna baza kodu, pisana przez osobnego autora z osobną — i dość często już porzuconą — dyscypliną aktualizacji, więc witryna z czterdziestoma wtyczkami nie ma jednego problemu z bezpieczeństwem, tylko czterdzieści niezależnych od siebie. Z naszego doświadczenia typowej stronie firmowej w zupełności wystarcza dziesięć do piętnastu wtyczek, a reszta została tam zwykle po dawno zapomnianych zadaniach: galeria, której już się nie wyświetla, formularz zastąpiony innym, slider, z którego obecny projekt graficzny nie korzysta. Kiedy przejmujemy tworzenie stron na WordPressie i opiekę nad nimi, ograniczenie liczby wtyczek jest pierwszą robotą, a nie ostatnią.

I tu pojawia się błąd powtarzający się częściej niż jakikolwiek inny: zbędna wtyczka zostaje wyłączona, a nie usunięta — wyłączenie mówi WordPressowi, żeby jej już nie wczytywał, ale pliki zostają na serwerze na swoim miejscu, część z nich nadal jest osiągalna wprost po HTTP, a skryptowi napastnika wystarczy znajomość ścieżki. Wordfence udokumentował w czerwcu 2021 roku aktywnie wykorzystywaną podatność zero-day we wtyczce Fancy Product Designer, którą w niektórych konfiguracjach da się wykorzystać nawet wtedy, gdy wtyczka jest wyłączona, i zalecił nie wyłączenie jej, lecz pełne odinstalowanie. Jeśli wtyczka nie jest już potrzebna, jej miejsce nie jest na liście wtyczek w szarym kolorze, tylko poza serwerem.

Dlaczego dzieje się to wszystko automatycznie i bez żadnego osobistego powodu, tłumaczy skala: według W3Techs 5 sierpnia 2026 roku WordPress napędzał 41,2% wszystkich stron internetowych. W ekosystemie tej wielkości każda opublikowana podatność wtyczki jest od razu użyteczna przeciwko bardzo dużej liczbie identycznie zbudowanych witryn, więc atak opłaca się automatyzować, a nie celować — skrypt czyta numery wersji, nie nazwy firm. Nikt nie wybrał akurat Państwa witryny i właśnie dlatego niewielka strona firmowa bez danych klientów i bez płatności zostaje zhakowana równie spokojnie jak duży sklep internetowy.

Gdzie napastnik ukrywa kod w instalacji WordPressa

Pierwsze miejsce, które otwieramy, to wp-content/uploads — katalog, w którym z założenia leżą wyłącznie obrazy, pliki PDF i wideo i w którym nigdy nie powinien wykonać się żaden plik PHP. Jeśli między zdjęciami produktów z 2019 roku leży plik z rozszerzeniem .php, nie trafił tam przypadkiem: prawie zawsze jest to albo uploader, którym napastnik wprowadza na serwer kolejne pliki, albo webshell pozwalający wykonywać polecenia w imieniu Państwa serwera. Że problem jest realny, a nie teoretyczny, widać już po tym, że zarówno Sucuri, jak i Wordfence dają osobne ustawienie utwardzające, które regułą w .htaccess wyłącza silnik PHP właśnie w tym katalogu.

Drugie miejsce to wp-content/mu-plugins. Umieszczone tam wtyczki włączają się automatycznie, nie da się ich wyłączyć z panelu administracyjnego i — co w tym przypadku najważniejsze — nie pojawiają się na zwykłej liście wtyczek, więc właściciel witryny może miesiącami patrzeć na pozornie czysty panel; firma Sucuri opisała w lipcu 2025 roku dokładnie taki przypadek, z backdoorem w tym katalogu. Obok tego zawsze sprawdzamy .htaccess — i w katalogu głównym, i w podkatalogach — bo przekierowanie działające tylko u odwiedzających z wyszukiwarki albo tylko na urządzeniach mobilnych najczęściej jest wpisane właśnie tam, i to jest powód, dla którego własna witryna wydaje się Państwu zupełnie normalna.

Kod bywa też wpisany w pierwsze wiersze istniejących, całkowicie legalnych plików, najczęściej na początku wp-config.php i w pliku functions.php motywu, i prawie nigdy nie wygląda na złośliwy kod: to jeden długi wiersz z wywołaniem base64_decode, gzinflate albo eval, za którym idą setki pustych wierszy, żeby w edytorze plik sprawiał wrażenie zakończonego. Dlatego porównanie plików z czystym oryginałem jest warte więcej niż czytanie ich okiem: tego wiersza nie znajdzie okiem nikt, bo nikt nie przewija pliku do dziewięćsetnego wiersza.

A potem jest baza danych, do której skaner plików nie zagląda i w której sprawdzić trzeba trzy miejsca: wiersze siteurl i home w tabeli wp_options, które napastnik nadpisuje, żeby zasoby Państwa podstron ładowały się z obcego serwera; tabelę wp_users, w której bywa konto administratora o wiarygodnie brzmiącej nazwie; oraz treść wpisów w wp_posts, gdzie ukryte odnośniki i ramki iframe wbudowuje się w środek starych artykułów, których nikt już nie otwiera. Jeśli pliki zostaną wyczyszczone, a wstrzyknięcie w bazie danych zostanie, infekcja wraca tego samego dnia. Sam wiersz się nie wykonuje — przy każdym wczytaniu odczytuje go i uruchamia niewielki loader w pliku functions.php motywu albo w katalogu mu-plugins — i właśnie ta para odtwarza skasowane pliki szybciej, niż zdążą Państwo sprawdzić wynik. Dlatego przy odzyskiwaniu zhakowanej strony czyszczenie plików i bazy danych jest u nas jedną robotą, a nie dwiema.

Porównanie plików ze zweryfikowanymi oryginałami

Pierwsze narzędzie, po które sięgamy, gdy pełna kopia plików i bazy danych jest już zabezpieczona, to wp core verify-checksums: porównuje skrót każdego pliku z sumami kontrolnymi publikowanymi przez WordPress.org i od razu pokazuje, które pliki zostały zmienione, a których w instalacji w ogóle nie powinno być. Kłopot zaczyna się tam, gdzie kończy się zasięg tego polecenia — sprawdza ono wyłącznie wp-admin/, wp-includes/ i pliki wp-* z katalogu głównego, natomiast cały katalog wp-content, a więc wtyczki, motywy i wgrane pliki, kod źródłowy świadomie pomija (kod źródłowy WP-CLI checksum-command, przejrzany 5 sierpnia 2026 roku). Jeden plik z katalogu głównego ten sam kod wyklucza osobno — wp-config.php — więc plik, w którego pierwszych wierszach najczęściej dopisuje się kod, dla tego sprawdzenia nie istnieje. Czysty wynik polecenia nie oznacza czystej witryny.

Dla wtyczek istnieje osobne polecenie wp plugin verify-checksums, ale i ono porównuje pliki wyłącznie z sumami kontrolnymi repozytorium WordPress.org, więc komercyjna wtyczka kupiona u producenta jest przy sprawdzaniu po prostu pomijana; dla motywów odpowiednika tego polecenia w dokumentacji WP-CLI nie ma wcale (dokumentacja WP-CLI, przejrzana 5 sierpnia 2026 roku). Automatycznej weryfikacji nie poddają się zatem ani motywy, ani wtyczki kupione poza repozytorium, a wp core verify-checksums pomija cały katalog wp-content — tę część kodu, w której powstały wszystkie 11 334 podatności naliczone przez Patchstack za 2025 rok poza sześcioma z rdzenia. W witrynach, które przejmujemy, to właśnie motyw bywa jedyną rzeczą, której nikt nigdy nie sprawdził.

Sumy kontrolne są więc u nas punktem wyjścia, a nie metodą: rdzenia i wtyczek nie leczymy, tylko zastępujemy, to znaczy pobieramy te same wersje z oryginalnego źródła i nadpisujemy całe katalogi, a nie pojedyncze pliki. Ze starej instalacji zostawiamy wp-content/uploads, i to dopiero po sprawdzeniu, czy między obrazami nie ma plików PHP — z tego samego powodu, dla którego w ogóle warto wyłączyć w tym katalogu silnik PHP. Motyw odtwarzamy z systemu kontroli wersji, jeśli taki jest; jeśli go nie ma, bierzemy kopię dostarczoną przez producenta i nakładamy modyfikacje świadomie, jedna po drugiej, bo tylko wtedy da się później powiedzieć, który wiersz w witrynie jest nasz, a który nie.

Znaleźć zły wiersz i go skasować brzmi taniej i właśnie dlatego jest to błąd powtarzany najczęściej: napastnik rzadko zostawia jedno wejście, a jedne niezauważone tylne drzwi czynią całą resztę pracy bezużyteczną. Kod bywa rozbity na kilka plików, ukryty za wywołaniem base64 lub gzinflate, wpisany do tabeli opcji w bazie danych albo podrzucony do tego samego katalogu mu-plugins, którego panel administracyjny nie pokazuje. Szukanie po wzorcu znajduje to, co już Państwo znają; pełne zastąpienie uwalnia również od tego, czego Państwo nie znają.

Jest też praca, której na tym etapie nie wykonujemy: nie polegamy na wtyczce proponującej „wyleczenie” zainfekowanych plików jednym przyciskiem, bo pracuje ona z tą samą listą znanych wzorców i w dodatku w tym samym środowisku, do którego napastnik wciąż ma dostęp. Nie porównujemy też plików ręcznie, gdy witryna jest wielkości zwykłej wizytówki albo bloga, bo świeża instalacja z przeniesioną treścią zajmuje mniej godzin niż porównywanie dwóch katalogów wiersz po wierszu, a wynik da się zweryfikować. Staranne porównanie ręczne jest na miejscu tam, gdzie motyw albo wtyczka są unikatowe, a systemu kontroli wersji nie ma; jak postępować z kopiami zapasowymi, żeby ten wybór w ogóle istniał, opisaliśmy w ogólnym przewodniku po odzyskiwaniu witryn.

Klucze, sesje i hasła: co naprawdę robi każde z nich

Klucze uwierzytelniające i sole w pliku wp-config.php niczego nie szyfrują, choć twierdzi tak niemal każdy poradnik: WordPress używa ich jako podstawy klucza, którym funkcja wp_generate_auth_cookie() podpisuje algorytmem HMAC-SHA256 ciasteczko uwierzytelniające, a samo ciasteczko jest jawnym tekstem z nazwą użytkownika, terminem ważności i tokenem sesji (WordPress Developer Resources, przejrzane 5 sierpnia 2026 roku). Dlatego po wymianie tych wartości każdy wcześniej wystawiony podpis przestaje dawać się zweryfikować, a serwer odrzuca każde dotąd wydane ciasteczko, nawet jeśli sama sesja formalnie jeszcze się nie skończyła.

Praktyczny skutek jest dokładnie taki, jakiego trzeba w chwili włamania: oficjalna dokumentacja WordPressa opisuje wymianę kluczy jako sposób na wyrzucenie każdego, kto mógłby być jeszcze zalogowany (WordPress.org, „FAQ My site was hacked”, zaktualizowane 26 lipca 2026 roku), więc jeśli napastnik trzyma w ręku ważną sesję, kończy się ona w tej samej chwili. Razem z sesjami nieważne stają się wszystkie wydane tokeny nonce, więc rozpoczęte formularze i przerwane w połowie kroki zamówień w tym momencie się urywają — moment wymiany wybieramy więc świadomie, a nie przypadkiem w środku dnia roboczego.

Wymiana kluczy i soli nie zmienia żadnego hasła. Skróty haseł WordPress tworzy za pomocą algorytmu bcrypt i osobnej losowej soli dla każdego hasła, niezwiązanej ze stałymi z wp-config.php (funkcja wp_hash_password(); bcrypt domyślnie od WordPressa 6.8), więc napastnik, który zna hasło administratora albo zdążył założyć sobie konto, po wymianie kluczy po prostu loguje się od nowa. Hasła zmienia się osobno i wszystkie, także te, których rzekomo nikt nie zna, a równocześnie trzeba przejść całą listę użytkowników w poszukiwaniu kont, których nikt z Państwa zespołu nie zakładał.

Na WordPressie lista danych dostępowych się nie kończy: za jednym razem zmienia się hasło do panelu hostingowego, dane dostępowe FTP i SFTP, hasło użytkownika bazy danych wraz z odpowiadającym mu wpisem w wp-config.php, a także klucze SSH, których nie zmienia się jak haseł, tylko generuje od nowa, kasując stary klucz publiczny z serwerowego pliku authorized_keys. Na końcu wymienia się wszystkie klucze API przechowywane w witrynie — bramki płatniczej, usługi wysyłającej pocztę, integracji z dostawą i księgowością — bo one zwykle zostają nietknięte najdłużej: nikt ich na co dzień nie ogląda na żadnym ekranie.

Proszę założyć, że napastnik ma pełną kopię bazy danych, bo to najtańszy krok w całym ataku: wszystko, co w tej bazie było — adresy e-mail klientów, historia zamówień, skróty haseł i klucze wpisane w ustawieniach wtyczek — trzeba uznać za rzecz, która trafiła w obce ręce. Jeśli któregoś z tych haseł użyto jeszcze gdzieś indziej, tamto miejsce też jest skompromitowane i zwykle w tym momencie rozmowa przenosi się z witryny na konta pocztowe, system księgowy i konto płatnicze sklepu.

Kolejność jest równie ważna jak sama lista: klucze i hasła wymienia się po usunięciu tylnych drzwi, bo w przeciwnym razie napastnik odczyta nowe wartości w tym samym pliku wp-config.php albo po prostu przechwyci następne logowanie. Właśnie ten porządek — najpierw pełna kopia, potem przyczyna, potem czyszczenie i dopiero na końcu dane dostępowe — jest miejscem, w którym odzyskiwanie prowadzone własnymi siłami najczęściej się zatrzymuje albo rozjeżdża, dlatego ten etap bierzemy na siebie i na koniec przekazujemy pisemny raport z tego, co zostało zmienione, kiedy i dlaczego.

Jak doprowadzić do zdjęcia ostrzeżenia Google'a i co robić potem

Raport „Problemy dotyczące bezpieczeństwa” w Google Search Console to jedyne miejsce, w którym widać, co dokładnie Google w Państwa witrynie znalazł: podany jest tam rodzaj zagrożenia i próbka konkretnych dotkniętych podstron, a od tego zależy również to, co widzi teraz odwiedzający. Rodzaj zagrożenia nie zmienia jednak tego, co odwiedzający widzi: Chrome nie różnicuje już nagłówka ostrzeżenia zależnie od tego, czy wykryto phishing, złośliwe oprogramowanie czy niechciane oprogramowanie, tylko we wszystkich przypadkach pokazuje to samo pełnoekranowe ostrzeżenie — po polsku „Niebezpieczna strona” — które człowieka na witrynę po prostu nie wpuszcza, podczas gdy wspomniana już etykieta „Ta strona mogła paść ofiarą ataku hakerów” w wynikach wyszukiwania jest tylko napisem obok odnośnika, przez który da się kliknąć dalej (strona pomocy Google Chrome o niebezpiecznych stronach, sprawdzona w sierpniu 2026 roku). Starszych nagłówków, różniących się według rodzaju zagrożenia — na przykład „Deceptive site ahead” — Chrome już nie używa, choć wciąż można je znaleźć w części dokumentacji Google. Pierwsze blokuje, drugie ostrzega, a to zmienia, ile czasu naprawdę Państwo mają.

Zanim naciśnie się przycisk „Poproś o sprawdzenie”, trzeba mieć pewność, że witryna naprawdę jest czysta, a nie tylko czysto wygląda w Państwa przeglądarce. Google w swoim poradniku o maskowanych frazach i odnośnikach wprost ostrzega, że napastnicy starają się wywołać wrażenie, iż podstrona została już usunięta albo naprawiona, dlatego każdą dawną stronę spamową trzeba sprawdzić narzędziem do sprawdzania adresów URL, które pokazuje widok Googlebota, a nie Państwa. Drugi krok pomijany najczęściej to lista właścicieli: przy japońskim ataku na frazy napastnik dopisuje się jako zweryfikowany właściciel witryny w Search Console (dokumentacja Google w serwisie web.dev), a dopóki nie zostanie z tej listy usunięty, wie o stanie witryny dokładnie tyle samo, co Państwo.

Szukany przycisk to „Poproś o sprawdzenie” w raporcie o problemach dotyczących bezpieczeństwa, a nie przycisk, który Google przewidział dla ręcznych działań, a w treści zgłoszenia warto napisać trzy rzeczy: co znaleziono, jak napastnik wszedł i co konkretnie zrobiono, żeby to zamknąć. Terminu nie obiecujemy, bo nie obiecuje go i Google: strona dokumentacji o inżynierii społecznej pisze, że sprawdzanie „może potrwać kilka dni”, a pomoc Search Console — że „kilka dni lub tygodni” (obie sprawdzone w sierpniu 2026 roku). Jeśli ktoś podaje Państwu konkretne 24 albo 72 godziny, powtarza liczbę, której nie ma w żadnym źródle Google.

Pośpiech na tym kroku kosztuje więcej niż czekanie. W tym samym badaniu Google i Uniwersytetu Kalifornijskiego w Berkeley 80% właścicieli doprowadziło do uznania witryny za czystą już przy pierwszym podejściu, pozostałym 20% potrzeba było kilku prób, a mediana czasu, jaki spędzili na wyczesywaniu kodu pozostawionego przez napastnika, wyniosła cały tydzień. Dane pochodzą z lat 2014–2015 i tak też należy je czytać, ale arytmetyka się nie zmieniła: odrzucone zgłoszenie oznacza, że ostrzeżenie zostaje na kolejny cykl, a za drugim razem nie są już Państwo zgłaszającym po raz pierwszy.

Kiedy ostrzeżenie zniknie, praca jeszcze się nie kończy, bo w indeksie zostają podstrony utworzone przez napastnika, a tych nie wolno przekierowywać na stronę główną — muszą zwracać kod 404 albo 410, żeby Google usunął je całkiem, podczas gdy narzędzie do usuwania w Search Console tylko je na jakiś czas ukrywa. Pozycje nie wracają przekręceniem przełącznika: podstrony trzeba przeindeksować od nowa, a to dzieje się w tempie Google, nie Państwa. Jak na tym etapie wykorzystać dzienniki serwera i kopie zapasowe, żeby następnym razem punkt wyjścia był lepszy, opisaliśmy w osobnym przewodniku po odzyskiwaniu zhakowanych witryn.

Kiedy przestać robić to samodzielnie i ile to kosztuje

Część opisanych tu rzeczy doświadczony właściciel witryny robi sam i mówimy to bez owijania w bawełnę również ludziom, którzy dzwonią do nas z otwartą Search Console i z już znalezioną winną wtyczką. Jeśli infekcja to jedna podmieniona strona główna, jeśli z dzienników widać, która wtyczka ją wpuściła, jeśli na liście użytkowników nie ma obcych administratorów i jeśli jest wczorajsza kopia zapasowa, którą ktoś kiedyś naprawdę przywrócił w środowisku testowym, to osiem opłaconych godzin kupi Państwu spokojniejszy sen, a nie szybszy wynik.

Są cztery sytuacje, w których radzimy się zatrzymać, a pierwszą jest ponowna infekcja po czyszczeniu: jeśli witryna zostaje zhakowana drugi raz, nie jest to kwestia pecha, tylko dowód, że punkt wejścia wciąż stoi otworem, a trzecie czyszczenie w tym samym środowisku będzie kosztowało dokładnie tyle, ile dwa pierwsze. Druga to jakikolwiek cień podejrzenia wobec danych klientów lub płatności, bo obok pracy technicznej pojawiają się tam obowiązki wobec organu nadzorczego i terminy, których dobrą wolą przedłużyć się nie da. Trzecia to witryna, z której firma zarabia każdego dnia, a czwarta — zwykły brak czasu: czyszczenie nie jest intelektualnie trudne, ale jest długie, monotonne i nie wybacza ani jednego pominiętego pliku.

Nasze odzyskiwanie zhakowanych stron internetowych kosztuje 90 € za godzinę bez VAT, przy minimalnym rozliczeniu ośmiu godzin roboczych płatnych z góry. Pracę zaczynamy zwykle w ciągu kilku godzin od zgłoszenia, a cały proces od początku do przekazania trwa najczęściej 8–72 godziny, przy czym o różnicy między ośmioma a siedemdziesięcioma dwiema godzinami niemal zawsze decyduje to, jak głęboko napastnik zdążył się zadomowić i jak stara jest ostatnia czysta kopia. Minimum nie jest liczbą marketingową: pełna kopia, szukanie przyczyny w dziennikach, czyszczenie i sprawdzenie rzadko mieszczą się w krótszym czasie.

Kolejność jest ta sama, która została opisana wyżej, tylko bez Państwa weekendu. Zanim czegokolwiek dotkniemy, zdejmujemy pełną kopię plików i bazy danych, żeby incydent dało się później w ogóle zbadać, i dopiero wtedy witryna zostaje odizolowana; dalej jest oczyszczana ze złośliwego oprogramowania i tylnych drzwi, baza danych sprawdzona, dane dostępowe i klucze wymienione, przyczyna włamania znaleziona i zamknięta, zgłoszenie do sprawdzenia złożone w Google, a monitoring uruchomiony; na końcu zaś otrzymują Państwo pisemny raport o tym, co się stało i co zostało zmienione. Jeśli witryna w tej chwili nie działa albo nie mają Państwo pewności co do tego, co widzą, mogą Państwo zamówić pilne sprawdzenie strony, a my powiemy, czy w ogóle jest tu za co płacić.

W wielu przypadkach właściwą odpowiedzią nie jest jednak odzyskiwanie, tylko to, co dzieje się po nim: jeśli witryna nazbierała dwadzieścia wtyczek, a przy połowie z nich nikt już nie pamięta powodu, problem leży w opiece nad stroną i rozwiązuje go tworzenie stron na WordPressie i opieka nad nimi, a nie kolejny cykl czyszczenia za pół roku. Najtańsza godzina w całej tej historii to ta wydana wcześniej: skasowanie nieużywanej wtyczki z wp-content/plugins zamiast jej wyłączenia oraz kopia zapasowa, którą ktoś kiedyś naprawdę przywrócił w środowisku testowym, razem kosztują mniej niż jeden dzień naszej pracy.