Skip to content
· 9 min czytania

Na Państwa stronie WordPress jest spam SEO. Czyszczenie tego nie naprawi.

Spam SEO w WordPressie wraca po każdym czyszczeniu, ponieważ backdoor i złośliwe konto administratora to przetrwają. Oto 20-minutowy audyt, dane wyjaśniające, dlaczego usuwanie zawodzi, i przebudowa, która kończy ten cykl.

WordPressSecuritySEOBusiness Strategy
Udostępnij

Spam SEO w WordPressie wraca wciąż od nowa, ponieważ czyszczenie usuwa objaw i zostawia drogę wejścia nietkniętą. Sucuri znalazło backdoora na 49,21% przejętych witryn w momencie infekcji oraz co najmniej jedno złośliwe konto administratora na 55% stron ze złośliwym oprogramowaniem w bazie danych.

Skanuje Pan strony, kasuje wstrzyknięte odnośniki, aktualizuje każdą wtyczkę, a w niecały miesiąc linki do aptek są z powrotem. Konto, które je ponownie instaluje, powstało podczas pierwszego włamania i przetrwało całe czyszczenie.

Każdy, kto choć raz czyścił zhakowaną instalację WordPressa, wie: druga infekcja przychodzi szybciej niż pierwsza. Dalej: szkody dla pozycji w wyszukiwarce, 20-minutowy audyt bez kupowania jakiegokolwiek skanera, powody, dla których usuwanie zawodzi, oraz sposób na trwałe zamknięcie luki.

  • Spam SEO należy do najczęstszych infekcji usuwanych przez Sucuri. Pojawił się na 20,30% zainfekowanych witryn podczas czyszczenia i na 42,22% w skanach zdalnych.
  • Czyszczenie usuwa ładunek i zostawia dostęp. 49,21% przejętych witryn miało backdoora, a 55% stron ze złośliwym oprogramowaniem w bazie danych złośliwe konto administratora.
  • Łatanie często bywa niemożliwe. Patchstack naliczył w 2025 roku 11 334 nowe podatności WordPressa, 91% z nich we wtyczkach, a dla 46% w dniu publikacji nie istniała żadna poprawka.
  • Większość spamu żyje w bazie danych. 38,3% przejętych baz zawierało spam SEO i właśnie dlatego skaner plików melduje czystą witrynę, podczas gdy Google pokazuje tytuły z apteki.
  • Statyczna przebudowa kończy ten cykl. Bez bazy danych w czasie działania i bez warstwy wtyczek na serwerze nie zostaje nic, w co dałoby się coś wstrzyknąć.

Co wstrzyknięcie spamu SEO robi ze stroną WordPress

Atakującemu zależy na reputacji Państwa domeny. Witryna, której Google już ufa, przekazuje to zaufanie stronom sprzedającym podrabiane leki, zapisy do kasyn albo fałszywe sneakersy. Odnośniki pozostają ukryte przed Państwem i trafiają do Googlebota. W przeglądarce strona wygląda nienagannie, w indeksie czyta się jak apteka.

  • Ukryte bloki odnośników. Setki znaczników kotwicy wypchniętych poza ekran przez CSS, wstrzykniętych w stopkę, obszar widżetów albo stary wpis, którego nikt nie otwiera.
  • Strony maskowane (cloaking). Serwer sprawdza user-agent i referrer, zanim zdecyduje, co wysłać. Ludzie dostają Państwa stronę główną, Googlebot dostaje spam, a właściciel dowiaduje się ostatni.
  • Japanese keyword hack. Google Search Central dokumentuje go pod tą nazwą: tysiące automatycznie generowanych stron z japońskim tekstem i linkami afiliacyjnymi, plus obcy właściciel dodany w Search Console, żeby atakujący zachował dostęp po wyczyszczeniu przez Państwa plików.
  • Przekierowania warunkowe. Odwiedzający przychodzący z wyniku wyszukiwania lądują na spamerskim celu. Kto wpisze domenę wprost, zobaczy normalną stronę, i dlatego właściciele rzadko dają wiarę pierwszemu zgłoszeniu.

38,3% przejętych baz danych w zbiorze Sucuri zawierało spam SEO, głównie ukryte odnośniki do podrabianych leków i hazardu. Ta liczba tłumaczy najbardziej frustrującą część. Skaner złośliwego oprogramowania przechodzi system plików, melduje, że wszystko czyste, a wstrzyknięta treść siedzi w tabeli bazy danych, której nigdy nie otworzył.

Jeśli w Państwa wynikach wyszukiwania widać już spamerskie strony, droga przez przebudowę liczy się bardziej niż kolejne skanowanie. Usługa migracji WordPressa od webvise obejmuje przejście na statyczny frontend w Next.js wraz z mapą przekierowań, która przenosi obecne pozycje.

Potwierdzenie infekcji w 20 minut

Proszę wykonać te cztery sprawdzenia, zanim zapłacą Państwo komukolwiek za czyszczenie. Każde zajmuje kilka minut, nie wymaga żadnej wtyczki i wychwytuje coś, co skaner w panelu przeoczy.

1. Proszę zapytać Google, co ma w indeksie

Proszę wyszukać własną domenę operatorem site i odczytać liczbę wyników, zanim przeczytają Państwo same wyniki.

  • site:panstwadomena.pl viagra oraz site:panstwadomena.pl casino zwracają strony, których nikt u Państwa nie napisał. Wystarczy jedno trafienie.
  • site:panstwadomena.pl samo w sobie zwraca dużo więcej stron, niż witryna w ogóle posiada. Witryna wizytówka na 40 podstron raportująca 6000 zaindeksowanych adresów URL to już pełna diagnoza.
  • Tytuły wyników wyświetlają się w znakach japońskich, cyrylicy albo chińskich na stronie publikującej po polsku lub angielsku.

2. Proszę pobrać własną stronę jako Googlebot

Maskowany spam pojawia się wyłącznie wtedy, gdy serwer wierzy, że pyta Googlebot. Proszę porównać w terminalu, co otrzymują obaj odwiedzający.

curl -s https://panstwadomena.pl | grep -ci "casino\|viagra\|payday" zwraca liczbę, którą widzi zwykły odwiedzający. Proszę uruchomić polecenie ponownie, dokładając -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)". Różne liczby potwierdzają cloaking.

Identyczne liczby nie oczyszczają witryny z podejrzeń. Wiele wstrzyknięć celuje w konkretne adresy URL zamiast w stronę główną. Proszę więc powtórzyć porównanie na dwóch lub trzech głębszych podstronach, zanim zaufają Państwo wynikowi.

3. Proszę przeczytać Search Console, a potem sprawdzić, kto jeszcze może

Najpierw sekcje Ręczne działania i Problemy dotyczące bezpieczeństwa. Ręczne działanie za spam po włamaniu, nagły skok wyświetleń dla zapytań niezwiązanych z Państwa działalnością albo nieznany zweryfikowany właściciel w Ustawieniach wskazują w tę samą stronę. Ten ostatni punkt umyka niemal zawsze, a to właśnie on pozwala atakującemu ponownie zweryfikować usługę długo po przebudowie witryny.

4. Proszę przeszukać bazę danych, a nie pliki

W tym miejscu skaner plików przestał szukać. Trzy zapytania wydobywają większość tego, obok czego przeszedł.

  • SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%display:none%' OR post_content LIKE '%position:absolute;left:-%'; znajduje ukryte bloki odnośników zapisane w Państwa treściach.
  • SELECT user_login, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 10; wypisuje najnowsze konta. Proszę zakwestionować każde, do którego nie potrafią Państwo dopasować twarzy.
  • SELECT option_name FROM wp_options WHERE autoload='yes' AND LENGTH(option_value) > 100000; wyłapuje przerośnięte wstrzyknięte ładunki ustawione tak, by ładowały się przy każdym pojedynczym żądaniu.

Dlaczego czyszczenie wciąż zawodzi

Czyszczenie celuje w widoczny ładunek. Droga dostępu to zupełnie inna sprawa i przeżywa ona skanowanie, aktualizację wtyczek oraz przywrócenie kopii zapasowej, które większość agencji wykonuje jako pierwszy krok.

Dane Sucuri z usuwania infekcji wskazują backdoora na 49,21% przejętych witryn w momencie infekcji. Na stronach ze złośliwym oprogramowaniem w bazie danych w 55% przypadków dochodziło do tego co najmniej jedno złośliwe konto administratora, więc za drugim razem atakujący loguje się drzwiami frontowymi i oszczędza sobie exploita. Kasowanie spamerskich odnośników z witryny, która wciąż ma jedno i drugie, to sprzątanie. Ponowna infekcja jest raczej zaplanowana niż zaskakująca.

WP Automatic czyni ten schemat namacalnym. Patchstack opublikował CVE-2024-27956 13 marca 2024 roku, nieuwierzytelnione wstrzyknięcie SQL z oceną 9,8, a późniejsze ataki wykorzystywały je do zakładania nowych kont administratora. Badacze odnotowali ponad 5,5 miliona prób jego wykorzystania. Każda witryna trafiona, a następnie wyczyszczona bez sprawdzenia tabeli użytkowników oddała atakującemu działający login.

Co zostawiła po sobie infekcjaUsuwane przez typowe czyszczenieNadal obecne po nim
Wstrzyknięte odnośniki w treści wpisówTakWstawiane ponownie przy kolejnym przebiegu
Powłoka PHP wgrana do wp-content/uploadsZwykleDruga i trzecia kopia gdzie indziej
Złośliwe konto administratoraRzadko sprawdzanePełny dostęp do panelu
Obcy właściciel w Search ConsoleNiemal nigdy nie sprawdzanyDostęp do usługi po przebudowie
Zadanie cron przepisujące ładunekRzadko sprawdzaneUruchamia się zgodnie z harmonogramem
Niezałatana wtyczka, która umożliwiła wejścieTylko jeśli istnieje poprawka46% nie miało poprawki w dniu ujawnienia

Ostatni wiersz przesądza o całej strategii. Patchstack naliczył 11 334 nowe podatności WordPressa w 2025 roku, o 42% więcej niż rok wcześniej, przy czym 91% z nich we wtyczkach, a 46% bez poprawki w dniu publikacji. Dla blisko połowy wszystkiego, co ujawniono w zeszłym roku, założenie łatki po prostu nie było opcją dostępną dla Państwa.

Dokładnie to zamienia pytanie o utrzymanie w pytanie o platformę. Ta sama argumentacja przewija się przez zagrożenia bezpieczeństwa przestarzałej instalacji, a rachunek pogarsza się z każdym rokiem, w którym liczba podatności rośnie.

Ile spam naprawdę kosztuje Państwa w Google

Szkody dla pozycji wyprzedzają odkrycie o bardzo długi dystans. Kiedy spamerska strona wypływa w wyszukiwaniu operatorem site, Google indeksuje ją już od tygodni, a wzorzec, którego nauczył się o Państwa domenie, jest już utrwalony.

Odzyskiwanie ma stałą kolejność i nic w nim nie idzie szybko. Wyczyścić witrynę, usunąć obce konta i właścicieli, złożyć wniosek o ponowne rozpatrzenie, a potem czekać na zdjęcie ręcznego działania. Google nie podaje żadnego terminu rozpatrzenia tej weryfikacji. Strony wyindeksowane jako spam nie wracają ze swoimi dawnymi pozycjami.

Witryna, która przez dwa miesiące serwowała maskowane strony aptek, wnosi tę historię we wszystko, co powstanie później, a to podnosi stawkę samej przebudowy. Mechanika utrzymania pozycji przy relaunchu zasługuje na lekturę, zanim ktokolwiek ruszy DNS.

Usunięcie powierzchni ataku zamiast łatania jej

WordPress wykonuje PHP na Państwa serwerze, przy każdym żądaniu czyta i zapisuje bazę danych oraz uruchamia kod wtyczek od podmiotów trzecich z niemal pełnym dostępem do obu tych rzeczy. Właśnie tych trzech własności potrzebuje wstrzyknięcie spamu SEO. Statycznie generowana witryna Next.js nie oferuje żadnej z nich w czasie działania.

  • Brak bazy danych w czasie działania. Strony powstają przy wdrożeniu i są serwowane jako pliki z CDN. Nie ma tabeli wp_posts, w której ktoś mógłby zapisać ukryte znaczniki div.
  • Brak warstwy wtyczek. 91% podatności WordPressa z 2025 roku siedziało we wtyczkach. Witryna bez warstwy wtyczek nie dziedziczy żadnej z nich.
  • Nic zapisywalnego na serwerze. Tylko wdrożenie zmienia to, co widzą odwiedzający, a wychodzi ono z kontroli wersji. Wstrzyknięty plik pojawia się jako różnica w kodzie, zanim w ogóle trafi na produkcję.
  • Brak panelu administracyjnego wystawionego do internetu. Problem złośliwego konta administratora przestaje istnieć, gdy nie ma formularza logowania, do którego dałoby się dotrzeć.
Powierzchnia atakuWordPressStatyczny Next.js
Kod podmiotów trzecich działający na Państwa serwerzeTypowa instalacja używa od 20 do 50 wtyczekŻaden
Baza danych zapisywalna w trakcie żądaniaPrzy każdym wczytaniu stronyŻadna w czasie działania
Publiczny formularz logowaniawp-admin, domyślnie wystawionyŻaden
Nowe podatności opublikowane w 2025 roku11 334 w całym ekosystemieAktualizacje frameworka, wgrywane przez ponowne wdrożenie
Poprawka dostępna, gdy luka staje się publiczna46% jej nie miałoPodniesienie wersji zależności i ponowne wdrożenie

Sama migracja jest wielkością znaną: pełny audyt istniejącej witryny, przebudowa w Next.js ze statyczną generacją, przekierowanie 301 dla każdego dzisiejszego adresu URL, a po przełączeniu monitoring pozycji. webvise pracuje dokładnie w tej kolejności, z działającym prototypem na tyle wcześnie, by zobaczyli Państwo swoje treści na miejscu przed podjęciem decyzji o zmianie. Czy ten krok pasuje do Państwa witryny, zależy od tego, jak duża jej część naprawdę potrzebuje serwera.

Najpierw proszę wykonać te cztery sprawdzenia. Jeśli wyszukiwanie operatorem site zwraca strony, których nikt u Państwa nie napisał, drogę dostępu trzeba zamknąć przed czymkolwiek innym, a oferta czyszczenia leżąca w skrzynce kupuje kilka spokojnych tygodni zamiast rozwiązania. webvise sprawdza istniejącą instalację, raportuje ustalenia i buduje od nowa na fundamencie, w który nie ma czego wstrzyknąć: proszę zamówić audyt tutaj.

Praktyki webvise są zgodne z normami ISO 27001 i ISO 42001.