# Japoński spam SEO na WordPressie — jak rozpoznać i usunąć atak Japanese keyword hack to jeden z najczęstszych ataków na WordPressa. Strona działa normalnie, a w Google wyświetla setki japońskich podstron nieistniejącego sklepu. Pokazuję, jak to rozpoznać, dlaczego cloaking ukrywa atak przed właścicielem i jak posprzątać go do końca. **Canonical:** https://spoko.space/pl/blog/japonski-spam-seo-wordpress/ **Language:** pl **Published:** 2026-06-18 **Tags:** WordPress, bezpieczeństwo, SEO, Japanese keyword hack, malware, cloaking **Category:** Bezpieczeństwo --- **Strona klienta działała bez zarzutu. A w Google wyświetlała setki japońskich stron sklepu, którego nigdy nie było.** To nie pomyłka wyszukiwarki ani literówka w adresie — to klasyczny *Japanese keyword hack*, jeden z najczęstszych i najbardziej podstępnych ataków na WordPressa. Podstępny, bo właściciel strony zwykle nie ma pojęcia, że padł ofiarą. Niedawno sprzątałem dokładnie taki przypadek i w tym artykule pokazuję, jak go rozpoznać, dlaczego potrafi działać miesiącami w ukryciu i jak usunąć go do końca — a nie tylko zamieść pod dywan. --- ## Jak wyglądał atak Pierwszym sygnałem nie była sama strona, tylko Google. Wpisanie komendy `site:domena.pl` zwracało listę wyników, których nigdy nikt nie publikował: setki podstron z tytułami i opisami po japońsku, datami sprzed kilku dni i cenami w jenach. ![Wyniki wyszukiwania Google dla zaatakowanej domeny — setki japońskich podstron z cenami w jenach, których właściciel nigdy nie utworzył](../../assets/images/blog/japanese-seo-spam-wordpress.webp "Japanese keyword hack widoczny w wynikach Google przez komendę site:") Klikając w którykolwiek wynik, trafiało się na stronę wyglądającą jak prawdziwy sklep — japońskie opisy, zdjęcia torebek i zegarków marek premium, ceny w jenach, przyciski „dodaj do koszyka". Wszystko podłożone pod cudzą, zaufaną domenę. ![Fałszywa japońska strona produktowa (podrobiona torebka Louis Vuitton) obok panelu analizy linków UPER pokazującego setki odnośników wewnętrznych; domeny zredagowane](../../assets/images/blog/wordpress-japanese-spam-page.webp "Fałszywa japońska strona produktowa i analiza jej linków w narzędziu UPER") ## Cloaking — dlaczego właściciel niczego nie widział Najważniejszy element tego ataku, i powód, dla którego potrafi pozostać niewykryty przez wiele miesięcy: **wchodząc na stronę bezpośrednio, właściciel widział swoją normalną zawartość. Dopiero wejście z wyników wyszukiwania Google lub Bing serwowało wersję po japońsku.** To technika zwana **cloakingiem**. Skrypt atakującego sprawdza, kto i skąd odwiedza stronę — analizuje nagłówek `Referer` (czy ktoś przyszedł z wyszukiwarki), `User-Agent` (czy to robot Google), a czasem to, czy odwiedzający jest zalogowanym administratorem. Na tej podstawie podejmuje decyzję: - **Właściciel wpisujący adres ręcznie albo zalogowany admin** → dostaje oryginalną, czystą stronę. Wszystko wygląda normalnie. - **Googlebot oraz użytkownik klikający z wyników wyszukiwania** → dostaje japońską stronę spamową. Efekt jest taki, że osoba prowadząca stronę może codziennie ją otwierać i nie zauważyć absolutnie niczego. Atak żyje wyłącznie w przestrzeni między wyszukiwarką a użytkownikiem przychodzącym z wyszukiwarki — czyli dokładnie tam, gdzie właściciel nie zagląda. Stąd żelazna zasada: **stanu strony nie ocenia się po tym, jak wygląda po zalogowaniu, tylko po tym, co widzi Google.** Komenda `site:twojadomena.pl` to pierwsze i najszybsze narzędzie diagnostyczne. Atak nie ograniczał się zresztą do Google. Poniżej ten sam przypadek widziany z poziomu Bing — w indeksie obok prawdziwych, norweskich podstron sklepu (logowanie, regulamin) siedzą wstrzyknięte japońskie strony produktowe. To pokazuje skalę: spam trafił do wielu wyszukiwarek naraz. ![Wyniki wyszukiwania `site:` w Bing dla zaatakowanej domeny — legalne norweskie podstrony sklepu wymieszane z japońskimi stronami spamowymi; domeny zredagowane](../../assets/images/blog/bing-japanese-spam-wordpress.webp "Bing: japoński spam zaindeksowany obok prawdziwych podstron sklepu — atak nie ograniczał się do Google") ## Po co komuś japoński spam na cudzej stronie Ten atak nie ma na celu zniszczenia strony ani wyłudzenia danych. To **parasite SEO** — pasożytowanie na cudzym autorytecie. Zbudowanie zaufania domeny w Google zajmuje lata. Atakujący nie chce go budować — chce go **ukraść**. Podkładając tysiące podstron pod dobrze ocenianą, istniejącą domenę, błyskawicznie wprowadza swój spam do indeksu z gotowym autorytetem. Te strony rankują na japońskie frazy zakupowe, a ruch z nich jest przekierowywany do realnych (najczęściej scamowych) sklepów albo sprzedawany dalej. Ofiara płaci za to: - **utratą pozycji** — Google obniża ranking całej domeny, gdy wykryje spam, - **ostrzeżeniem o złośliwym oprogramowaniu** w wynikach i przeglądarce, - **spaleniem reputacji domeny**, której odbudowa trwa miesiącami. Szczególnie obrywają sklepy. Instalacje WooCommerce i inne platformy e-commerce mają zwykle więcej wtyczek (czyli większą powierzchnię ataku), a fałszywe podstrony produktowe wtapiają się w prawdziwy katalog — przez co atak dłużej pozostaje niezauważony. Nieprzypadkowo spam udaje właśnie oferty sklepowe: ceny, przyciski „dodaj do koszyka", karty produktów. W analizowanym przypadku część spamowych nagłówków zdradzała nawet mechanikę generowania treści — sztywne szablony „marka + model + słowo zakupowe" po japońsku, powielane tysiące razy. ![Analiza nagłówków zaatakowanej podstrony — japoński H1 z szablonową frazą produktową, typowy dla automatycznie generowanego spamu](../../assets/images/blog/japanese-keyword-hack-headings.webp "Japoński nagłówek H1 wygenerowany automatycznie — ten sam szablon powielony w tysiącach podstron") ## Lawina linków wewnętrznych Drugą rzeczą, która rzuca się w oczy po analizie, jest skala linkowania wewnętrznego. Pojedyncza spamowa podstrona zawierała kilkaset odnośników do kolejnych podstron tego samego sklepu — w analizowanym przypadku audyt linków (na zrzucie poniżej, z mojego narzędzia UPER) wykrył **328 linków wewnętrznych na jednej stronie**. Co więcej, linkowała praktycznie każda grafika. Zdjęcia produktów były hotlinkowane z zewnętrznego CDN-u — atakujący nie trzymał ich nawet na zaatakowanym serwerze — a każda taka miniaturka japońskiego ogłoszenia była jednocześnie odnośnikiem do następnej podstrony WordPressa. To celowy mechanizm: gęsta sieć wzajemnych linków sprawia, że robot Google błyskawicznie odkrywa i indeksuje całe tysiące spamowych adresów, zamiast utknąć na jednej stronie. ![Panel analizy linków UPER dla zaatakowanej podstrony — 328 linków wewnętrznych prowadzących do kolejnych adresów /shop/ tego samego sklepu, domeny zredagowane](../../assets/images/blog/japanese-spam-internal-links.webp "Jedna spamowa podstrona zawierała 328 linków wewnętrznych do kolejnych adresów sklepu") ![Panel UPER z listą 44 grafik z jednej spamowej podstrony — zdjęcia hotlinkowane z zewnętrznego CDN-u, każda jako miniatura-odnośnik](../../assets/images/blog/japanese-spam-hotlinked-images.webp "44 grafiki na jednej podstronie — wszystkie hotlinkowane z zewnętrznego CDN-u") Zanim przejdziemy do wykrywania — oto cały mechanizm w pięciu krokach: ## Jak rozpoznać, że to ten atak Zanim zaczniesz cokolwiek czyścić, potwierdź diagnozę. Sygnały Japanese keyword hack: site:twojadomena.pl w Google' }, { term: 'Inna treść dla wyszukiwarki niż dla Ciebie', detail: 'Narzędzie „Sprawdzenie adresu URL” w Google Search Console (opcja „Pobierz jako Google”)' }, { term: 'Gwałtowny skok liczby zaindeksowanych stron', detail: 'Raport „Indeksowanie stron” w GSC' }, { term: 'Ostrzeżenia bezpieczeństwa', detail: '„Problemy związane z bezpieczeństwem” w GSC' }, { term: 'Nieznane konta administratorów', detail: 'Użytkownicy → Wszyscy w panelu WP' }, { term: 'Podejrzane wpisy w .htaccess i wp-config.php', detail: 'Menedżer plików / FTP' }, ]} /> Najwięcej powie Ci **Google Search Console**. Jeśli nie masz do niej dostępu — to pierwszy krok, który trzeba wykonać przed czymkolwiek innym. To ona pokaże prawdziwą, „googlebotową" wersję strony, której cloaking nie ukryje. ## Najczęstszy błąd przy czyszczeniu — ukryta sitemapa Tu zaczyna się część, na której potyka się większość osób sprzątających ten atak samodzielnie. Usuwają japońskie strony, kasują podejrzane pliki, strona wygląda na czystą — a po kilku dniach spam wraca, albo Google dalej indeksuje setki japońskich URL-i, mimo że żadnej z tych stron już nie ma. Samo poprawienie `.htaccess` i zaktualizowanie wtyczek zwykle pomaga tylko na chwilę — po kilku dniach albo tygodniach strona infekuje się ponownie. Dopóki nie wyczyścisz serwera do końca, atak wraca, bo złośliwe skrypty PHP bywają zaszyte głęboko w strukturze katalogów: w podfolderach `wp-content/uploads`, w plikach udających elementy motywu lub wtyczki, czasem w kilku kopiach naraz. Jedna przeoczona linijka wystarczy, żeby backdoor odtworzył całą resztę. Trzeba też pamiętać o sąsiednich stronach. Jeśli na jednym koncie hostingowym trzymasz kilka serwisów, a `open_basedir` nie jest poprawnie ustawione (nie izoluje katalogów od siebie), infekcja jednej witryny zwykle rozlewa się na wszystkie pozostałe. Klasyczny scenariusz: w katalogu `/blog/` stoi WordPress, a obok — sklep na Magento czy PrestaShop. Dziurawy WordPress staje się wtedy furtką do sklepu, mimo że sam sklep był aktualny i dobrze zabezpieczony. Dlatego i przy czyszczeniu, i przy planowaniu, co gdzie postawić, trzeba patrzeć na całe konto hostingowe, a nie pojedynczą stronę. Powód, który świetnie udokumentowało Sucuri: **podmieniona, ukryta sitemapa**. Atak często zostawia własny plik mapy strony (np. `sitemap.xml` wskazujący na spamowe URL-e albo dodatkowy plik typu `wp-sitemap-xxxx.xml`) i zgłasza go do Google. Nawet po usunięciu wszystkich spamowych stron Google nadal trzyma w kolejce indeksowania adresy z tej sitemapy. Dopóki jej nie znajdziesz i nie usuniesz, walczysz z wiatrakami. Dlatego czyszczenie tego ataku to **nie jest** kasowanie widocznych stron. To usunięcie całego mechanizmu: 1. **Backdoora** — pliku PHP, który pozwala atakującemu wrócić (często ukryty w `wp-content/uploads`, podszywający się pod nazwę systemowego pliku). 2. **Fałszywego konta administratora** — dodanego, żeby utrzymać dostęp nawet po zmianie haseł. 3. **Wpisów w `.htaccess`** — odpowiadających za cloaking i przekierowania. 4. **Doklejonego kodu w `wp-config.php`** i plikach motywu. 5. **Złośliwej sitemapy** i wszystkich plików, które ją generują. ## Jak usunąć atak krok po kroku Skrócony, sprawdzony przepływ usuwania: 1. **Zrób kopię zapasową** całości (pliki + baza) przed jakąkolwiek ingerencją — to materiał dowodowy i siatka bezpieczeństwa. 2. **Zidentyfikuj zakres** w Google Search Console — ile URL-i, jakie wzorce, od kiedy. 3. **Usuń fałszywe konta** administratorów i zresetuj hasła wszystkim pozostałym. 4. **Wyczyść pliki** — porównaj instalację z czystym WordPressem, usuń backdoory, przywróć oryginalny `.htaccess` i `wp-config.php`. Skaner (np. Wordfence) pomaga, ale nie zastępuje ręcznego przeglądu. 5. **Wyczyść bazę danych** ze spamowych wpisów i opcji dodanych przez atak. 6. **Znajdź i usuń złośliwą sitemapę**, a poprawną zgłoś ponownie w GSC. 7. **Zaktualizuj wszystko** — rdzeń, motyw, wszystkie wtyczki. Usuń te nieużywane. 8. **Poproś Google o ponowne sprawdzenie** w raporcie „Problemy związane z bezpieczeństwem". Jeśli na którymkolwiek kroku nie masz pewności, czy plik jest częścią WordPressa, czy backdoorem — to moment, żeby oddać sprawę komuś, kto robił to wcześniej. Pominięty backdoor oznacza, że za tydzień zaczynasz od zera. A jeśli nie masz aktualnej kopii zapasowej ani strony w repozytorium (Git)? Wtedy ręczne czyszczenie bywa loterią — nigdy nie masz stuprocentowej pewności, że wyłapałeś każdy backdoor, bo nie ma czystego punktu odniesienia do porównania. W takiej sytuacji najskuteczniejszym rozwiązaniem jest często **postawienie strony od nowa**: świeża instalacja, zabezpieczona od pierwszej minuty, z możliwie najmniejszą liczbą zewnętrznych wtyczek — wyłącznie w aktualnych wersjach. Brzmi drastycznie, ale zwykle jest szybsze i pewniejsze niż tropienie pojedynczych zainfekowanych plików w instalacji, której nie da się z niczym zestawić. ## Jak się zabezpieczyć na przyszłość Najpierw szersza perspektywa: WordPress napędza ponad 40% wszystkich stron w internecie i **właśnie ta popularność czyni go najczęściej atakowanym systemem**. Boty automatycznie skanują tysiące witryn naraz w poszukiwaniu znanych podatności w popularnych wtyczkach — nie musisz być „ciekawym celem", wystarczy, że masz nieaktualny, dziurawy dodatek. Skalę problemu widać w publicznych bazach podatności — [Patchstack](https://patchstack.com/database/), [Wordfence Intelligence](https://www.wordfence.com/threat-intel/vulnerabilities) czy [WPScan](https://wpscan.com/wordpresses/) — gdzie niemal codziennie przybywają nowe wpisy o SQL injection, XSS czy obejściu uwierzytelniania w konkretnych wtyczkach. To nie znaczy, że WordPress jest zły; po prostu im więcej osób czegoś używa, tym bardziej opłaca się to atakować. Sam atak prawie zawsze wchodzi przez **nieaktualną wtyczkę lub motyw** z publicznie znaną podatnością, słabe hasło albo piracki motyw premium z doklejonym kodem. WordPress jako taki jest bezpieczny — dziurą jest zwykle jeden zaniedbany dodatek. Minimum higieny: - **Aktualizuj** rdzeń, motyw i wtyczki natychmiast po wydaniu łatek. - **Ogranicz liczbę wtyczek** — każda to potencjalny wektor ataku. - **Silne hasła + 2FA** dla wszystkich kont z dostępem do panelu. - **Nie instaluj** motywów i wtyczek z nieoficjalnych źródeł („darmowych" wersji premium). - **Monitoruj** stronę i jej linki — Google Search Console i Bing Webmaster Tools (oba darmowe), a profil linków w narzędziach takich jak Ahrefs. To one pierwsze pokażą nagły skok zaindeksowanych stron albo spam ukryty cloakingiem. - **Regularne kopie zapasowe** trzymane poza serwerem strony. Jedno zastrzeżenie do „aktualizuj wszystko": sama aktualność nie gwarantuje bezpieczeństwa. Zdarza się, że backdoora zawiera **oficjalna, najnowsza wersja wtyczki** — gdy ktoś przejmie konto jej autora i wstrzyknie złośliwy kod do paczki w repozytorium (atak na łańcuch dostaw). Opisałem taki przypadek w artykule o [ataku na łańcuch dostaw wtyczek WordPress](https://uper.pl/blog/atak-lancuch-dostaw-wtyczki-wordpress-2026/). Dlatego im mniej wtyczek i im bardziej zaufane ich źródło, tym mniejsze ryzyko — a aktualizacje warto wdrażać z krótką zwłoką i po sprawdzeniu, co dana wersja faktycznie zmienia. Z tego samego powodu opcja **„włącz automatyczne aktualizacje"** przy każdej wtyczce nie zawsze jest dobrym pomysłem. Wygodnie łata znane dziury, ale jednocześnie potrafi w środku nocy zaciągnąć przejętą wersję, zanim ktokolwiek zdąży ją wychwycić — czyli dokładnie ten scenariusz, w którym auto-aktualizacja sama wpuszcza backdoora na serwer. Rozsądny kompromis to auto-aktualizacje rdzenia i krytycznych łatek bezpieczeństwa, ale ręczna, świadoma kontrola przy wtyczkach, którym ufasz najmniej. Pełną, praktyczną listę zabezpieczeń WordPressa — od konfiguracji po wtyczki — zebrałem w osobnym przewodniku: [jak zabezpieczyć WordPress](https://uper.pl/blog/jak-zabezpieczyc-wordpress/). Warto też zajrzeć do oficjalnej dokumentacji: [Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/). Warto też zadać sobie szczersze pytanie: czy ta strona w ogóle musi być na WordPressie? Jeśli to witryna wizytówkowa albo firmowa, która rzadko się zmienia, to cała powierzchnia ataku — wtyczki, panel, PHP, baza — jest zbędnym ryzykiem. Statyczna strona zbudowana w nowoczesnym stacku (jak ten, na którym stoi spoko.space) nie ma panelu logowania ani bazy do przejęcia, więc ten konkretny atak jest na niej fizycznie niemożliwy. Różnice w bezpieczeństwie i utrzymaniu rozpisałem w [porównaniu strony statycznej z aplikacją webową](https://spoko.space/pl/blog/aplikacja-webowa-vs-strona-internetowa/), ale warto mieć je z tyłu głowy przy kolejnym „znowu mnie zhakowali". --- ## Podsumowanie Japoński spam SEO jest groźny właśnie dlatego, że jest cichy. Cloaking sprawia, że właściciel widzi czystą stronę, podczas gdy Google indeksuje tysiące japońskich podstron i obniża ranking całej domeny. Klucz do skutecznego sprzątania to zrozumienie, że widoczne strony to objaw, a nie choroba — trzeba usunąć backdoora, fałszywe konto, wpisy w `.htaccess` oraz ukrytą sitemapę, inaczej spam wróci. A najlepszą obroną pozostaje profilaktyka: aktualizacje, mniej wtyczek, silne hasła i regularne zaglądanie do Google Search Console — bo to ona, a nie Twoja przeglądarka, widzi prawdę o stanie strony.