SEO-spam: A weboldalad főoldala rendben működik, a Google-ban mégis idegen nyelvű termékek, ismeretlen ajánlatok vagy furcsa aloldalak jelennek meg a domained alatt. Megnyitod az egyik találatot, és egy másik honlapra kerülsz. Máskor a cím már hibát ad, de a keresőben továbbra is látható.
A SEO-spam jelenségeit nem lehet kizárólag a főoldal megtekintésével megítélni. Külön kell vizsgálni, mit szolgál ki most a weboldal, mit ismer róla a kereső, és milyen jogosulatlan tartalom vagy hozzáférés maradhatott a háttérben.
Cikksorozatunk negyedik részében a feltört weboldalakra kerülő SEO-spamről lesz szó. Bemutatjuk a jellemző megjelenési formákat, a felderítés eszközeit, valamint azt, hogyan kapcsolódik össze a biztonsági helyreállítás és a keresőtalálatok rendezése.
Mi az a SEO-spam?
Ebben a cikkben SEO-spam alatt a keresőbeli megjelenés befolyásolására szolgáló, jogosulatlanul elhelyezett tartalmakat és hivatkozásokat értjük. A Google a feltört tartalmak között új oldalak létrehozását, meglévő tartalmak módosítását, rejtett szövegeket és linkeket, valamint átirányításokat is bemutat. [1]
Itt a kifejezés a visszaélés célját írja le. Nem azonosít egyetlen vírust vagy malware-családot. A biztonsági vizsgálatnak külön kell megállapítania, milyen hozzáféréssel és milyen program vagy művelet segítségével került a tartalom az oldalra.
Kitalált példa: egy szolgáltató honlapján engedély nélkül több száz, teljesen más témájú ajánlati oldal jelenik meg – ez SEO-spam. A támadó azt szeretné, hogy ezek a keresőből látogatókat kapjanak. A főoldal közben változatlan marad, ezért a tulajdonos ott nem látja az új tartalmakat.
Milyen formában jelenhet meg a SEO-spam?
Idegen aloldalak és kulcsszavakkal teli tartalmak
A Google egyik útmutatója olyan támadást ismertet, amely automatikusan hoz létre kulcsszavakkal teli, értelmetlen szövegű oldalakat. Az oldalak keresőből vonzanak látogatókat, majd más honlapokra irányíthatják őket. [2]
Egy külön útmutató az úgynevezett japán kulcsszavas feltörést mutatja be: ennél a támadók japán szövegű tartalmakat és linkeket generálnak a megtámadott oldalon. Ez egy dokumentált megjelenési forma; a nyelvből önmagában nem lehet azonosítani a támadót vagy a bejutás módját. [3]
Kitalált példa: egy magyar bemutatkozó honlaphoz idegen nyelvű kereskedelmi oldalak tartoznak, amelyekre a menüből nem vezet link. A főoldal ellenőrzése mellett a konkrét idegen URL-ek működését is meg kell vizsgálni.
Rejtett hivatkozások és meglévő tartalmak módosítása
A Google leírása szerint a támadó meglévő oldalakba is illeszthet tartalmat. A rejtést HTML- és CSS-megoldások vagy összetettebb feltételes működés is szolgálhatja. [1]
Ezért az ismert cikkek és oldalak is beletartozhatnak az ellenőrzésbe. A vizsgálatnak azt kell tisztáznia, melyik tartalom és hivatkozás tartozik a jóváhagyott állapothoz, és melyik került oda engedély nélkül.
Eltérő tartalom a keresőnek és a látogatónak SEO-spam esetén
A cloaking a Google meghatározása szerint olyan eltérő tartalomkiszolgálás, amely a kereső és a felhasználó megtévesztését, illetve a rangsorolás manipulálását célozza. Feltört oldalon a beavatkozás elrejtésére is használható. [1]
Egyetlen közvetlen megnyitás ezért nem feltétlenül írja le a teljes működést. A japán kulcsszavas támadásról szóló útmutató olyan helyzetet is ismertet, amelyben a tulajdonosnak a tartalom hiányát sugalló oldal jelenik meg. [3]
Technikai magyarázat: A „nem található” felirat, a tényleges HTTP-státuszkód és a más körülmények között kiszolgált válasz külön vizsgálati adat. A felirat önmagában nem bizonyítja, hogy az idegen tartalom minden kérésnél megszűnt.
Három külön állapotot kell összehasonlítani
A felderítéshez hasznos különválasztani a következőket:
| Vizsgált állapot | Mire ad választ? |
|---|---|
| A weboldal aktuális válasza | Mit szolgál ki most az adott URL, az adott körülmények között? |
| A Google indexelt változata | Milyen korábban feldolgozott információ szerepel az URL-ről? |
| A Search Console jelzései | Milyen indexelési, biztonsági vagy kézi intézkedési információ áll rendelkezésre? |
A Search Console URL-ellenőrző eszköze külön kezeli az indexelt állapot adatait és az élő URL tesztjét. Az élő teszt eredménye nem helyettesíti a biztonsági problémák vagy kézi intézkedések ellenőrzését. [4]
Kitalált összehasonlítás: az indexelt állapot még idegen szöveget mutat, az élő teszt viszont már a helyreállított oldalt látja. Ez más helyzet, mint amikor az élő válaszban is megjelenik a spam. Az első esetben a korábbi keresőbeli állapot rendezése, a másodikban az aktuális jogosulatlan működés feltárása is feladat.
Hogyan találhatók meg az idegen URL-ek?
A site: keresés jó kiindulópont, de nem teljes leltár
A Google-ban például a következő keresés segíthet a saját domainhez tartozó találatok áttekintésében:
site:pelda.huA pelda.hu helyére a saját domained kerül. Ha már ismert egy gyanús szó vagy kifejezés, azzal együtt is lehet keresni.
A Google dokumentációja szerint a site: operátor nem ad feltétlenül teljes listát az indexelt URL-ekről. A találatok számából ezért nem érdemes pontos fertőzöttségi darabszámot készíteni, és egy üres vagy rövid lista sem igazolja a teljes weboldal tisztaságát. [5]
A Search Console mintáit ki kell egészíteni
A Biztonsági problémák jelentés a Google által feltárt biztonsági gondokat mutatja. A példaként felsorolt URL-ek nem feltétlenül teljes körűek, és egy jelzéshez akár mintacímek nélkül is tartozhat probléma. [6]
A felderítési leltárhoz ezért több forrást érdemes összevetni: a megtalált keresőtalálatokat, a Search Console adatait, a weboldal tartalmait és az alkalmazás működését. Minden talált címhez hasznos rögzíteni az észlelés idejét és az aktuális válasz eredményét.
Technikai magyarázat: A URL útvonala önmagában nem mondja meg, melyik fájl vagy adatbázis-bejegyzés áll mögötte. Kitalált példa: ugyanaz a jogosulatlan program sok különböző címre generál választ. Ebben az esetben nem feltétlenül található minden spam-URL-hez külön fájl a tárhelyen.
Miért furcsa a Google-találat címe vagy leírása?
A Google a találati címet több forrásból állítja össze, például az oldal címéből és látható címsoraiból. A javítások feldolgozásához az oldal újbóli feltérképezése és feldolgozása is szükséges lehet. [7]
A találati leírás, vagyis snippet szintén nem egyszerűen a metaleírás változatlan másolata: a Google elsősorban az oldal tartalmából készíti, és a kereséstől függően más részletet is választhat. [8]
Ezért idegen találati szövegnél a tényleges oldalválaszt, a releváns tartalmakat és az indexelési adatokat is össze kell hasonlítani. A metaleírás átírása önmagában nem teljes biztonsági vizsgálat.
WordPress: spambejegyzéshez sem feltétlenül kell fertőzött programfájl
A WordPress REST API dokumentált műveleteket biztosít bejegyzések létrehozására és módosítására. A hitelesítéshez alkalmazásjelszó is használható; a végezhető műveleteket a felhasználó jogosultságai határozzák meg. [9][10]
Kitalált példa: a támadó hozzájut egy tartalomközlésre jogosult fiók alkalmazásjelszavához, és API-n keresztül spambejegyzéseket hoz létre. Az alaprendszer fájljait ehhez a példában nem módosítja. A helyreállításnak ezért a tartalmak mellett az érintett hozzáférést is kezelnie kell.
Technikai magyarázat: Az alkalmazásjelszavak és a REST API szabályos funkciók. A visszaélés lehetősége nem jelenti azt, hogy minden API-kérés támadás, vagy hogy a teljes API letiltása szükséges. A konkrét fiókot, jogosultságot és hitelesítési módot kell értékelni. [10]
A WordPress hivatalos biztonsági útmutatója a fájlok mellett a hozzáférések, adatbázis, mentések és megfigyelés szerepét is tárgyalja. SEO-spamnél ez azért lényeges, mert a látható eredmény lehet adatbázisban tárolt tartalom is. [11]
Joomla: a spam tartalom és a kihasznált hiba külön vizsgálati tárgy
A Joomla dokumentációja külön bemutatja az SQL-injectiont, az XSS-t és a veszélyes fájlfeltöltést. Ezek biztonsági hibák és támadási lehetőségek; nem azonosak a SEO-spam céljával. [12]
Kitalált példa: egy komponens hibáján keresztül jogosulatlan tartalom kerül az oldalra. A tartalom törlése a látható eredményt kezeli, a hiba javítása pedig a bejutás egyik lehetőségét. Ha közben további hozzáférés keletkezett, azt külön is vizsgálni kell.
Joomla-oldalon ezért a cikkek és más megjelenő tartalmak mellett az azokat kiszolgáló összetevőket és a felhasználói jogosultságokat is be lehet vonni a felderítésbe. A spam megjelenési helye önmagában nem azonosítja az eredeti belépési pontot.
Hogyan kezeljük a spam-URL-eket?
A biztonsági helyreállítás és az indexelés rendezése két összefüggő feladat. A keresőből való elrejtés nem törli a szerveren lévő tartalmat és nem szünteti meg a jogosulatlan hozzáférést.
Először azt kell eldönteni, mi legyen az adott címen: helyreállított eredeti tartalom, végleg megszüntetett oldal vagy indokolt új célpont. Az alábbi táblázat szerkesztési és vizsgálati kiindulópont.
| Az URL helyzete | A helyreállítás célja |
|---|---|
| Eredeti, hasznos oldalba került spam | A jóváhagyott tartalom és működés visszaállítása |
| Kizárólag a támadó által létrehozott oldal | A tartalom és létrehozó mechanizmus eltávolítása, megfelelő nem található válasz |
| Valóban új címre költözött eredeti oldal | Tartalmilag megfelelő átirányítás |
| Még vizsgálat alatt álló cím | A nyomok megőrzése mellett a károkozás korlátozása |
Tényleges megszüntetés: 404 vagy 410
Ha a jogosulatlan oldal megszűnik, a kiszolgált HTTP-válasznak is ezt kell tükröznie. A Google dokumentációja szerint a 404 és 410 válaszok a tartalom hiányát jelzik a feldolgozás számára; egy korábban indexelt URL ennek alapján kikerülhet az indexből. [13]
Nem elég egy hibaüzenetet megjeleníteni sikeres 200 válasszal. A tartalmat és a státuszkódot együtt kell ellenőrizni.
Nem minden címnek a főoldal az új helye
A Google URL-változásokról szóló útmutatója óv attól, hogy sok régi címet tartalmilag nem megfelelő célra, például a főoldalra irányítsunk. Az ilyen működést soft 404-ként is értelmezheti. [14]
Egy támadó által létrehozott, az oldalhoz nem tartozó ajánlatnak ezért nem kell mesterséges „utódoldalt” kijelölni. Előbb azt kell eldönteni, hogy a tartalomnak egyáltalán van-e jogos helye a honlapon.
Ideiglenes elrejtés: a Removals eszköz
A Search Console eltávolítási eszköze ideiglenesen elrejthet találatokat. A Google tájékoztatója szerint az ilyen elrejtés körülbelül hat hónapig tart; a tartós rendezéshez a tartalom vagy az indexelhetőség megfelelő kezelése is szükséges. [15]
Egyedi URL és címelőtag alapján is lehet kérni elrejtést. Az előtag hatókörét különösen gondosan kell megválasztani, hogy a kérés ne érintsen megtartandó tartalmakat. [15]
Miért nem elég a robots.txt tiltása?
A robots.txt a feltérképezést szabályozza. Egy letiltott URL más hivatkozások alapján továbbra is megjelenhet a keresőben. A Google ezért nem ezt javasolja az indexből való eltávolítás általános eszközeként. [16]
Ha egy elérhető oldalt noindex utasítással kívánunk kizárni, a Google-nak hozzá kell férnie a válaszhoz, hogy az utasítást feldolgozhassa. A feltérképezés egyidejű tiltása ezt akadályozhatja. [17]
Technikai magyarázat: A
noindexaz indexelést befolyásolja, nem hozzáférés-védelem és nem malware-eltávolítás. Egy megszüntetett spamoldal és egy megtartott, de nem indexelendő oldal eltérő helyzet. A teljes webhely véletlen kizárását kerülni kell.
Search Console: biztonsági felülvizsgálat vagy kézi intézkedés?
A Biztonsági problémák jelentésben a Google biztonsági megállapításai szerepelnek. A jelzett probléma helyreállítása után az ehhez kapcsolódó felülvizsgálat az adott jelentésből indítható. A javításnak a teljes érintett működésre kell kiterjednie, nem csupán a példaként felsorolt címekre. [6]
A Kézi intézkedések jelentés külön terület. Ha ott intézkedés szerepel, a leírás szerinti problémákat kell rendezni, majd indokolt esetben felülvizsgálatot kérni. A Google a kérelemben a probléma, a javítási lépések és az eredmény dokumentálását kéri. [18]
Nem minden idegen találat jelent kézi intézkedést. A két jelentést külön kell ellenőrizni, és az indexelési kérelemmel sem szabad összekeverni őket.
A Search Console hozzáféréseit is nézd át
A Google dokumentációja külön kezeli a felhasználókat és az igazolt tulajdonosokat. Egy eltávolított tulajdonos megmaradt ellenőrző tokennel újra igazolhatja a tulajdonjogát. [19]
Helyreállításkor ezért érdemes áttekinteni az ismeretlen hozzáféréseket és a hozzájuk tartozó igazolásokat is. Az ellenőrző fájlok vagy DNS-bejegyzések azonosítás nélkül történő tömeges törlése helyett az adott jogosultsághoz tartozó elemet kell megkeresni, mert más szolgáltatás is támaszkodhat rá. [19]
Mikor rendeződnek a keresőtalálatok?
A Google szerint a feltérképezés napoktól hetekig is eltarthat, és a kérelem nem jelent azonnali indexelést. Ugyanazon URL ismételt beküldése nem gyorsítja a feltérképezést. [20]
A fontos, helyreállított eredeti oldalaknál használható az URL-ellenőrző indexelési kérelme. Több oldal felfedezését sitemap is segítheti. A sitemap ugyanakkor nem garantálja minden felsorolt cím feltérképezését és indexelését. [20][21]
Kitalált példa: a spamoldal már következetesen 404 választ ad, de egy korábbi keresőtalálat még látható. Ez nem azonos azzal az esettel, amikor a szerver ismét spamet szolgál ki. A követés során az aktuális válaszokat és a keresőbeli adatokat külön kell dokumentálni.
A korábbi helyezések visszatérésére nem érdemes konkrét határidőt ígérni. A feltérképezés, az indexelés és az esetleges felülvizsgálat külön folyamat, és egyik eredményét sem helyettesíti a másik.
Rövid helyreállítási munkamenet
Az alábbi sorrend szerkesztett javaslat, amelyet az adott incidenshez kell igazítani:
- Készíts leltárt. Rögzítsd az idegen címeket, tartalmakat, észlelési körülményeket és válaszokat.
- Tárd fel az eredetet. A tartalom mellett vizsgáld a létrehozó kódot, hozzáférést vagy hibát is.
- Állítsd helyre a weboldalt. Az eredeti oldalakat tisztítsd meg, a jogosulatlan tartalmat és mechanizmust kezeld.
- Rendezd az URL-ek válaszait. Különítsd el a megtartott, megszüntetett és valóban áthelyezett tartalmakat.
- Ellenőrizd a Search Console-t. Nézd át a jelzéseket, hozzáféréseket, és a helyzethez illő kérelmet használd.
- Kövesd külön a biztonsági és keresőbeli állapotot. Az újabb jogosulatlan változás és a régi indexadat eltérő feladatot jelent.
A következő rész: adatlopó kódok és webes adathalászat
A következő cikkben az adatlopó működéseket és az adathalász tartalmakat vizsgáljuk meg: milyen adatok kerülhetnek veszélybe, hogyan kapcsolódhat a megtévesztő felület és a háttérben futó kód, és milyen kérdésekre kell választ keresni egy incidens kivizsgálásakor.
Források
Forrásellenőrzés: 2026. október 27. A példák kitalált szemléltető esetek. A vizsgálati táblázatok és a munkamenet szerkesztett javaslatok; konkrét oldal diagnózisát külön vizsgálat adhatja meg. A régebbi támadástípusokat ismertető útmutatókat a működés szemléltetésére használjuk, nem jelenlegi gyakoriság megállapítására.
- Google Search Central: Spam policies – hacked content and cloaking.
- Google web.dev: Fix the gibberish hack.
- Google web.dev: Fix the Japanese keyword hack.
- Search Console Help: URL Inspection tool.
- Google Search Central: Site search operator.
- Search Console Help: Security issues report.
- Google Search Central: Title links.
- Google Search Central: Snippets and meta descriptions.
- WordPress REST API: Posts.
- WordPress REST API: Authentication.
- WordPress: Hardening WordPress.
- Joomla: Common Vulnerabilities.
- Google Crawling Infrastructure: HTTP status codes.
- Google Search Central: Site moves with URL changes.
- Search Console Help: Removals tool.
- Google Search Central: Introduction to robots.txt.
- Google Search Central: Block indexing with noindex.
- Search Console Help: Manual actions report.
- Search Console Help: Managing owners, users, and permissions.
- Google Search Central: Ask Google to recrawl URLs.
- Google Search Central: Sitemaps overview.
Ha gyanús, hogy weboldalad vírusos vagy feltört, segítünk a helyreállításban !