Japanese Keyword Hack i Chinese SEO Spam — jak usunąć spam z WordPressa i Google?

Jeśli Twoja strona internetowa działa prawidłowo, ale w Google lub Google Search Console pojawiły się tysiące obcych adresów URL z chińskimi albo japońskimi znakami, reklamami podróbek, leków czy innych produktów, których nigdy nie publikowałeś, możesz mieć do czynienia z infekcją określaną jako Japanese Keyword Hack, Japanese SEO Spam, Chinese SEO Spam lub SEO spam injection. Atakujący wykorzystuje przejętą stronę do generowania treści przeznaczonych dla wyszukiwarek, często bez widocznej zmiany wyglądu witryny. Problem nie zawsze kończy się wraz z usunięciem złośliwego kodu, ponieważ Google mógł wcześniej odkryć i zaindeksować tysiące wygenerowanych adresów. Dlatego nawet po oczyszczeniu WordPressa raporty Search Console mogą przez wiele tygodni lub miesięcy zawierać ślady infekcji. W tym poradniku wyjaśniamy, jak usunąć przyczynę Japanese Keyword Hack, sprawdzić skuteczność naprawy i uporządkować spamowe adresy w Google.

Traktuj Japanese Keyword Hack jako incydent bezpieczeństwa. Jeżeli pod Twoją domeną pojawiły się obce treści, nie zaczynaj od masowego usuwania adresów w Google Search Console. Najpierw zabezpiecz informacje o infekcji, usuń złośliwy kod i zamknij możliwość ponownego dostępu do strony. Dopiero później zajmij się jej skutkami w wyszukiwarce.

• Co to jest Japanese Keyword Hack i Chinese SEO Spam?
• Dlaczego w WordPressie pojawiły się chińskie lub japońskie strony?
• Co zabezpieczyć przed rozpoczęciem naprawy?
• Jak usunąć Japanese Keyword Hack z WordPressa?
• Jak sprawdzić, czy infekcja została usunięta?
• Google Search Console po Japanese Keyword Hack
• Co zrobić ze spamowymi adresami URL?
• Jak naprawić mapę witryny po infekcji?
• Jak uporządkować raport Indeksowanie stron?
• Jak analizować raport Skuteczność po ataku?
• Czy trzeba usunąć 100 tysięcy błędów z Search Console?
• Jak zabezpieczyć WordPress przed kolejną infekcją?

Zadbaj o bezpieczeństwo WordPressa już na poziomie hostingu. W SEOHOST wykorzystujemy Monarx Security, który pomaga wykrywać złośliwe pliki i niebezpieczną aktywność aplikacji PHP. Sprawdź nasz hosting z ochroną Monarx oraz możliwości przeniesienia strony do SEOHOST.

Co to jest Japanese Keyword Hack i Chinese SEO Spam?

Japanese Keyword Hack to rodzaj ataku SEO spam, w którym zainfekowana strona internetowa zostaje wykorzystana do publikowania lub generowania obcych treści przeznaczonych dla wyszukiwarek. W klasycznym wariancie są to strony zawierające japońskie znaki i reklamy produktów. Podobne infekcje mogą wykorzystywać język chiński, inne języki lub treści reklamujące podróbki, leki, hazard i niezwiązane z witryną usługi.

Określenia Japanese Keyword Hack, Chinese SEO Spam i SEO spam injection nie muszą oznaczać dokładnie tego samego złośliwego oprogramowania. Opisują jednak podobny problem: wykorzystanie przejętej witryny do manipulowania wynikami wyszukiwania.

Nie zawsze są to zwykłe wpisy dodane do WordPressa. Złośliwy mechanizm może generować strony dynamicznie, tworzyć lub modyfikować pliki, ingerować w bazę danych, zmieniać reguły .htaccess, dodawać własne mapy witryny albo stosować cloaking, czyli pokazywać różną zawartość w zależności od tego, kto odwiedza stronę.

Dlatego możesz otworzyć swoją witrynę i nie zobaczyć żadnego problemu, mimo że Google odkrywa tysiące obcych adresów. Co więcej, część stron spamowych może być widoczna tylko dla określonych robotów lub użytkowników, a pozostałym osobom wyświetlać normalną zawartość albo błąd.

Nie szukaj jednego pliku o nazwie japanese-spam.php. Nie istnieje uniwersalny generator Japanese Keyword Hack. Sposób przejęcia WordPressa, lokalizacja złośliwego kodu i mechanizm tworzenia adresów mogą być różne. Usunięcie jednego podejrzanego pliku nie zawsze oznacza zakończenie infekcji.

Dlaczego w WordPressie pojawiły się chińskie lub japońskie strony?

Najpierw rozdzielmy dwie rzeczy: sposób, w jaki atakujący uzyskał dostęp do WordPressa, oraz mechanizm odpowiedzialny za generowanie spamu. Usunięcie samych podstron bez zamknięcia drogi włamania może spowodować, że po kilku dniach problem pojawi się ponownie.

Najczęściej warto sprawdzić następujące obszary:

Ciekawej analizy przyczyn przejęć WordPressa podjął się Wordfence, którego zespół zajmuje się badaniem podatności i bezpieczeństwa WordPressa. Wśród typowych problemów wymienia między innymi nieaktualne oprogramowanie, przejęte dane dostępowe i podatne rozszerzenia.

Nie oznacza to jednak, że automatycznie winna jest konkretna wtyczka. Bez analizy logów i plików zainfekowanej strony nie zawsze można jednoznacznie ustalić punkt wejścia. Podobne zagrożenia omawiamy również w naszym poradniku o malware w WordPressie.

Co zabezpieczyć przed rozpoczęciem naprawy infekcji?

Naturalną reakcją po odkryciu tysięcy obcych podstron jest próba natychmiastowego usunięcia wszystkiego, co wygląda podejrzanie. Zanim jednak zaczniesz zmieniać pliki i przywracać kopie zapasowe, warto zachować informacje, które pomogą ustalić przyczynę incydentu.

Przygotuj przede wszystkim:

• Zrzuty ekranu z Google i Google Search Console, pokazujące spamowe wyniki, liczbę wykrytych URL-i oraz ewentualne komunikaty bezpieczeństwa.
• Listę przykładowych spamowych adresów – zapisz kilkanaście URL-i z różnymi schematami ścieżek.
• Dostępne logi serwera, które mogą pomóc w ustaleniu czasu i przebiegu włamania.
• Informacje o podejrzanych plikach, w tym lokalizację i datę modyfikacji.
• Kopię aktualnego, zainfekowanego stanu strony, wykonaną przed rozpoczęciem czyszczenia i przechowywaną w odizolowanym miejscu.

Ostatni punkt może wydawać się zaskakujący. Taka kopia nie służy do późniejszego przywracania zainfekowanego WordPressa na serwer produkcyjny. Jest materiałem diagnostycznym, do którego administrator może wrócić podczas poszukiwania podatności, backdoora lub mechanizmu generującego obce podstrony.

Przy poważnym incydencie warto również ograniczyć możliwość dalszych zmian na przejętym koncie lub stronie, tak aby zachować dowody i zatrzymać działanie atakującego. Sposób zabezpieczenia środowiska powinien uwzględniać dostępność usług i zakres przejęcia.

Podobne podejście do odzyskiwania przejętej strony przedstawia oficjalna dokumentacja WordPressa dotycząca zhakowanych witryn.

Jak usunąć Japanese Keyword Hack z WordPressa?

Nie istnieje jedna procedura, która naprawi każdy przypadek Japanese Keyword Hack. Na podstawie powtarzających się scenariuszy można jednak przygotować kolejność działań pozwalającą usunąć złośliwy kod, odzyskać prawidłowe działanie strony i ograniczyć ryzyko ponownej infekcji.

1. Sprawdź dostępy i administratorów

Przejrzyj konta administratorów WordPressa, panelu hostingowego i pozostałych systemów zarządzania witryną. Usuń nieznane konta, zmień przejęte lub potencjalnie ujawnione hasła oraz unieważnij niepotrzebne aktywne sesje. Zmianę danych dostępowych wykonuj z zaufanego urządzenia, a jeżeli podejrzewasz przejęcie poczty administratora, zabezpiecz również tę skrzynkę.

Sprawdź też konta FTP, SFTP i SSH, klucze dostępowe oraz ustawienia uwierzytelniania. Jeżeli atakujący nadal ma dostęp do serwera, może ponownie zainstalować usunięte malware.

2. Zaktualizuj WordPress, wtyczki i motyw

Zaktualizuj używane komponenty do bezpiecznych, wspieranych wersji, a niepotrzebne wtyczki i motywy usuń. Pamiętaj jednak, że aktualizacja oprogramowania nie jest równoznaczna z usunięciem infekcji. Może zamknąć podatność, ale niekoniecznie usunie backdoor, który atakujący wcześniej zapisał na serwerze.

W przypadku zmodyfikowanych plików WordPressa lub dodatków warto porównać je z czystymi kopiami pochodzącymi z zaufanych źródeł. Samodzielnie zmieniany kod, w tym motywy potomne, wymaga ostrożnej weryfikacji, aby nie usunąć prawidłowych modyfikacji.

3. Sprawdź pliki i konfigurację WordPressa

Przejrzyj między innymi pliki wp-config.php i .htaccess, katalogi wp-admin, wp-includes, wp-content/plugins, wp-content/themes, wp-content/uploads oraz wp-content/mu-plugins.

Zwróć uwagę na nieznane pliki PHP, kod dodany do prawidłowych plików oraz nietypowe przekierowania. Sprawdź również, czy nie zmieniono ustawień witryny, adresów URL i sposobu generowania stron dla odwiedzających oraz robotów wyszukiwarek.

4. Sprawdź bazę danych i zadania CRON

Nie wszystkie infekcje zapisują się wyłącznie w plikach PHP. Złośliwy kod może być przechowywany w bazie danych WordPressa, w ustawieniach wtyczek, treściach stron albo zadaniach uruchamianych automatycznie.

Sprawdź więc użytkowników CMS, podejrzane rekordy w bazie, zadania WP-Cron, harmonogram zadań po stronie hostingu oraz MU-plugins (wtyczki ładowane automatycznie przez WordPress). Jest to szczególnie istotne, gdy spamowe podstrony wracają mimo usunięcia wykrytych plików.

5. Rozważ przywrócenie czystej kopii zapasowej

Jeżeli masz kopię wykonaną przed infekcją, jej przywrócenie może być łatwiejsze niż ręczne usuwanie zmian z wielu plików. Musisz jednak upewnić się, że kopia rzeczywiście pochodzi sprzed włamania i nie zawiera tego samego złośliwego kodu.

Po przywróceniu strony nadal trzeba usunąć przyczynę incydentu, zaktualizować podatne komponenty i zabezpieczyć dostęp. Przywrócenie kopii nie rozwiązuje automatycznie problemu z przejętymi kontami ani podatnościami.

Jeżeli korzystasz z SEOHOST, sprawdź dostępność kopii dla swojej usługi i wybranego terminu. Kopie dostępne na koncie możesz przywracać za pomocą narzędzi przywracania kopii zapasowej w DirectAdmin. Zachęcamy również do wykonywania własnych backupów, korzystając z instrukcji jak wykonać kopię zapasową w DirectAdmin.

6. Przeskanuj środowisko i usuń pozostałe zagrożenia

Po oczyszczeniu plików i konfiguracji wykonaj kontrolę całej instalacji. W SEOHOST dodatkową warstwą ochrony jest Monarx Security, który analizuje pliki, aktywność aplikacji PHP oraz wybrane zdarzenia związane z ruchem kierowanym do strony.

Monarx może pomagać wykrywać złośliwy kod i blokować określone zagrożenia. Nie jest jednak narzędziem do pełnego skanowania baz danych WordPressa ani poczty e-mail i nie zastępuje analizy źródła infekcji.

Nie kończ naprawy na komunikacie o usunięciu malware. Zweryfikuj, czy złośliwe pliki nie pojawiają się ponownie, czy konta i dostęp do serwera są zabezpieczone oraz czy pod spamowymi adresami nie są nadal generowane obce treści.

Jak sprawdzić, czy Japanese Keyword Hack został faktycznie usunięty?

Samo otwarcie strony głównej WordPressa nie wystarczy. Wykorzystaj spamowe adresy, które zapisałeś przed rozpoczęciem naprawy, i sprawdź, jak odpowiada na nie serwer.

Jeżeli adres należał wyłącznie do złośliwej, wygenerowanej podstrony, która została już usunięta, prawidłową odpowiedzią będzie zwykle 404 Not Found lub 410 Gone. Jeśli natomiast atak zmienił zawartość legalnej podstrony, powinieneś przywrócić jej prawidłową treść i działanie, zamiast usuwać poprawny adres.

Sprawdź również, czy:

• nie pojawiają się nowe spamowe adresy URL,
• usunięte złośliwe pliki nie są ponownie tworzone,
• nie istnieją nieznane konta administratorów WordPressa,
• nie ma nieznanych użytkowników i metod weryfikacji własności w Google Search Console,
• w konfiguracji domeny nie pozostały nieautoryzowane zmiany DNS i przekierowań,
• nie istnieją nieznane mapy witryny,
• skaner bezpieczeństwa nie zgłasza dalszych wykryć,
• prawidłowe strony i ich warianty adresowe działają poprawnie.

Jeżeli podejrzewasz cloaking, porównaj rzeczywistą odpowiedź serwera z informacjami widocznymi w narzędziu Sprawdzenie adresu URL w Google Search Console. Pomocne mogą być także zapisane wcześniej zrzuty ekranu i treści spamowych wyników.

Dopiero po upewnieniu się, że infekcja została usunięta, przejdź do porządkowania jej skutków w Google.

Google Search Console po Japanese Keyword Hack

Możesz posiadać witrynę składającą się z 100 prawidłowych podstron, podczas gdy Google Search Console będzie nadal pokazywać 20 tysięcy, 100 tysięcy albo więcej adresów wygenerowanych podczas infekcji.

Nie jest to odosobniony scenariusz. Przy rozległym SEO spamie Google może odkryć ogromną liczbę adresów, również takich, które nigdy nie zostały utworzone jako osobne wpisy w bazie WordPressa. Niektóre zdążą trafić do indeksu, inne pozostaną wyłącznie wykrytymi URL-ami.

Dlatego musisz odróżnić aktywną infekcję od historycznych informacji zapisanych przez Google. To, że obcy adres nadal znajduje się w raporcie, nie oznacza automatycznie, że pod tym adresem wciąż działa złośliwa strona.

Stare spamowe adresy w Google Search Console nie są same w sobie dowodem trwającej infekcji. Sprawdź, czy serwer nadal generuje obce treści, czy pojawiają się nowe URL-e oraz co zwracają adresy utworzone podczas ataku.

Sprawdź raporty bezpieczeństwa i ręczne działania

Po oczyszczeniu WordPressa sprawdź w Google Search Console raport Problemy dotyczące bezpieczeństwa. Jeżeli Google oznaczył witrynę jako zhakowaną lub niebezpieczną, zapoznaj się z podanymi przykładami i upewnij się, że wskazane problemy zostały naprawione.

Jeżeli raport umożliwia przesłanie prośby o ponowne sprawdzenie strony, zrób to dopiero po zakończeniu czyszczenia i zabezpieczeniu witryny. W opisie warto wskazać, jakie problemy wykryto i jakie działania wykonano.

Sprawdź również raport Ręczne działania. Ewentualne ręczne działanie dotyczące spamu wymaga osobnej kontroli i zastosowania procedury opisanej przez Google.

Nie każda infekcja Japanese Keyword Hack skutkuje takim powiadomieniem. Brak ostrzeżenia w tych raportach również nie daje gwarancji, że na serwerze nie ma już malware.

Co zrobić ze spamowymi adresami URL po usunięciu infekcji?

Jeżeli podstrona powstała wyłącznie w wyniku działania złośliwego kodu i po oczyszczeniu WordPressa już nie istnieje, powinna zwracać prawidłowy kod odpowiedzi HTTP:

• 404 Not Found – zasób nie został znaleziony.
• 410 Gone – zasób został usunięty i nie jest już dostępny.

Obie odpowiedzi pozwalają Google ustalić, że określona strona nie powinna pozostawać w indeksie. Nie ma potrzeby masowego zmieniania wszystkich odpowiedzi 404 na 410 tylko po to, aby wymusić szybsze zniknięcie adresów z raportu.

Nie twórz pustych stron zwracających 200 OK i nie przekierowuj tysięcy nieistniejących adresów na stronę główną. Takie przekierowania nie rozwiązują problemu i mogą utrudniać wyszukiwarce zrozumienie, że spamowe strony przestały istnieć.

Nie blokuj również tych adresów w robots.txt wyłącznie w celu ich usunięcia z indeksu. Jeżeli robot Google nie może ponownie odwiedzić adresu, nie zobaczy odpowiedzi 404 lub 410, która potwierdza usunięcie zasobu.

Nie stosuj masowej reguły 410 bez sprawdzenia adresów. Jeżeli złośliwe URL-e wykorzystują schemat podobny do prawidłowych artykułów, taka reguła może przypadkowo usunąć z wyszukiwarki legalne strony. Najpierw ustal, które adresy rzeczywiście zostały wygenerowane przez infekcję.

Czy używać narzędzia Usunięcia w Google Search Console?

Jeżeli chcesz szybko ukryć szczególnie problematyczne spamowe wyniki, możesz skorzystać z narzędzia Usunięcia w Google Search Console. Jest to jednak rozwiązanie tymczasowe, które nie zastępuje usunięcia złośliwej treści ani prawidłowej odpowiedzi serwera.

Narzędzie nie służy do wyczyszczenia całej historii wykrytych adresów. Przy tysiącach lub setkach tysięcy spamowych URL-i ważniejsze jest usunięcie przyczyny infekcji i zapewnienie, że nieistniejące strony zwracają właściwe odpowiedzi HTTP.

Jak naprawić mapę witryny po Japanese Keyword Hack?

Sprawdź wszystkie mapy witryny zgłoszone w Google Search Console oraz pliki sitemap znajdujące się na serwerze. Jeżeli infekcja utworzyła własną mapę albo dopisała spamowe adresy do prawidłowej sitemapy, usuń złośliwe wpisy i przygotuj aktualną mapę witryny.

Po oczyszczeniu sitemap powinna zawierać wyłącznie prawidłowe, kanoniczne adresy stron, które chcesz indeksować. W typowej konfiguracji będą to URL-e zwracające 200 OK, dostępne dla wyszukiwarki i nieoznaczone dyrektywą noindex.

Następnie sprawdź, czy Google Search Console nie zawiera zgłoszonych przez atakującego obcych map, i prześlij ponownie aktualną sitemapę.

Nie oczekuj jednak, że samo wysłanie nowej mapy natychmiast usunie spamowe adresy z raportów. Google mógł poznać je wcześniej, a dane historyczne nie znikają automatycznie po zmianie pliku XML.

Jak uporządkować raport Indeksowanie stron w Google Search Console?

To jeden z najbardziej uciążliwych skutków Japanese Keyword Hack. Witryna może mieć przykładowo 300 prawidłowych stron, z których 260 znajduje się w indeksie, a 40 wymaga sprawdzenia. Po ataku raport nagle pokazuje setki tysięcy wykrytych URL-i, błędy 404 i adresy oznaczone jako „Wykryto – obecnie nie zindeksowano”.

Analiza staje się wtedy trudna, ponieważ prawidłowe podstrony stanowią niewielką część wszystkich znanych Google adresów.

Nie musisz jednak analizować całego raportu bez żadnego rozróżnienia. W zależności od dostępnych opcji interfejsu Google Search Console możesz wybrać zakres obejmujący:

• wszystkie znane strony,
• wszystkie przesłane strony,
• strony nieprzesłane w sitemapie,
• adresy z wybranej zgłoszonej mapy witryny.

Po infekcji szczególnie przydatna jest analiza adresów z czystej, aktualnej sitemapy. Pozwala skupić się na stronach, które faktycznie chcesz utrzymywać i indeksować, zamiast przeglądać całą historię adresów wygenerowanych przez malware.

Nie oznacza to oczywiście, że zgłoszona sitemap obejmuje wszystkie prawidłowe adresy serwisu. Warto osobno kontrolować strony pominięte w mapie, które powinny do niej należeć, oraz adresy odkryte przez Google poza sitemapą.

Filtrowanie raportu nie usuwa spamowych URL-i z Google Search Console. Pomaga jednak ponownie analizować rzeczywistą kondycję strony. Jeśli dopiero poznajesz to narzędzie, sprawdź nasz poradnik co to jest Google Search Console.

Jak analizować raport Skuteczność po Japanese Keyword Hack?

Jeżeli spamowe adresy zaczęły wyświetlać się w wynikach wyszukiwania, również raport Skuteczność może zostać zanieczyszczony. Pojawiają się w nim wtedy obce zapytania, adresy niezwiązane z tematyką witryny oraz wyświetlenia, które nie odzwierciedlają rzeczywistej widoczności prawidłowych treści.

W takiej sytuacji wykorzystaj filtry stron dostępne w Google Search Console. Jeżeli spamowe URL-e mają charakterystyczny fragment adresu lub schemat, możesz zastosować filtr wykluczający taki wzorzec. Przy bardziej skomplikowanych przypadkach pomocne będą wyrażenia regularne (RegEx).

Możesz również ograniczyć analizę do prawidłowych katalogów albo wybranych podstron, które funkcjonowały jeszcze przed infekcją.

Dzięki temu łatwiej porównasz ruch i widoczność swojej właściwej strony bez mieszania jej danych ze spamem pozostawionym przez atakującego.

Pamiętaj jednak, że filtrowanie nie zmienia historycznych danych w Google. Jeśli spamowe URL-e generowały wyświetlenia, pozostaną one częścią wcześniejszych statystyk, nawet po zakończeniu infekcji.

Nie zdziw się także, jeśli zewnętrzne narzędzia do monitorowania widoczności pokazują zupełnie inny obraz niż Search Console. Systemy tego rodzaju analizują określone zapytania i zestawy wyników, podczas gdy Google Search Console korzysta z danych o rzeczywistych wyświetleniach i kliknięciach dla Twojej witryny.

Czy trzeba usunąć 100 tysięcy błędów z Google Search Console?

Nie. Nie musisz ręcznie usuwać każdego spamowego adresu z raportów Google Search Console.

Co więcej, nie istnieje przycisk pozwalający natychmiast wyczyścić całą historię URL-i wygenerowanych podczas infekcji. Jeżeli WordPress jest już czysty, nowe spamowe strony nie powstają, a nieistniejące adresy zwracają 404 lub 410, pozwól Google ponownie je przetworzyć.

Duża liczba błędów 404 może wyglądać niepokojąco, ale w przypadku usuniętych spamowych adresów odpowiedź 404 jest prawidłowa. Nie należy jej naprawiać przez masowe przekierowania na stronę główną.

Porządkowanie raportu potrwa. Przy dużej liczbie URL-i mogą to być tygodnie, a nawet miesiące. Tempo zależy między innymi od ponownego odwiedzania adresów przez Google i sposobu, w jaki wcześniej zostały odkryte.

W tym czasie ważniejsze od samej liczby błędów jest sprawdzanie, czy:

• prawidłowe strony nadal znajdują się w indeksie,
• Google odkrywa aktualne, wartościowe treści,
• nowe spamowe adresy przestały powstawać,
• nieistniejące URL-e zwracają odpowiednie kody HTTP,
• raporty bezpieczeństwa nie wskazują dalszych problemów.

Nie oceniaj więc skuteczności usunięcia Japanese Keyword Hack wyłącznie na podstawie tego, czy liczba adresów w raporcie Indeksowanie szybko spada.

Jak zabezpieczyć WordPress przed kolejną infekcją?

Po usunięciu Japanese Keyword Hack nie kończ pracy na sprawdzeniu, czy strona główna ponownie wygląda prawidłowo. Taki incydent jest powodem, aby przejrzeć całą instalację WordPressa, dostęp do kont oraz wykorzystywane oprogramowanie.

Najważniejsze działania profilaktyczne to:

• Regularne aktualizacje WordPressa, wtyczek i motywu.
• Usuwanie niepotrzebnych rozszerzeń i starych instalacji pozostawionych na serwerze.
• Stosowanie silnych, unikalnych haseł oraz uwierzytelniania dwuskładnikowego dla administratorów.
• Kontrola użytkowników i uprawnień w WordPressie, hostingu i Google Search Console.
• Wykonywanie kopii zapasowych, w tym przechowywanie przynajmniej jednej kopii poza głównym kontem hostingowym.
• Monitorowanie zmian w plikach i podejrzanej aktywności aplikacji.
• Regularna kontrola Google Search Console, szczególnie nowych adresów, map witryn i raportów bezpieczeństwa.
• Korzystanie z ochrony po stronie hostingu, która pomaga wykrywać i blokować złośliwe działania.

Więcej rozwiązań opisujemy w poradniku Narzędzia do ochrony WordPress.

Japanese Keyword Hack wymaga działania na dwóch poziomach. Pierwszy dotyczy odzyskania bezpieczeństwa strony i usunięcia mechanizmu generowania spamu. Drugi obejmuje uporządkowanie adresów, które Google poznał podczas infekcji. Są to osobne procesy, dlatego ich zakończenie nie musi nastąpić w tym samym momencie.

Potrzebujesz pomocy z bezpieczeństwem strony? Jeśli korzystasz z hostingu SEOHOST i podejrzewasz infekcję WordPressa, skontaktuj się z naszym zespołem pomocy technicznej. Przygotuj przykładowe spamowe URL-e i informacje o wykrytych problemach, aby ułatwić analizę zgłoszenia.

Najważniejsza jest właściwa kolejność: zabezpiecz informacje o incydencie, usuń infekcję i jej przyczynę, sprawdź odpowiedzi spamowych URL-i, przygotuj czystą mapę witryny i dopiero wtedy porządkuj Google Search Console. Nie walcz z historycznymi adresami, dopóki atakujący może generować kolejne.