A főoldal működik, a látogató mégis máshová jut
Hétfő reggel megnézed a céges weboldalt. Betölt, a kapcsolatfelvételi űrlap is a helyén van, így visszatérsz a munkához. Később egy ügyfél különös üzenetet küld: a Google találatára kattintva egy kaszinóoldalon kötött ki. Nálad továbbra is a megszokott főoldal látszik. A két tapasztalat együtt egy olyan hibára utalhat, amelyet az egyszerű rendelkezésreállás-figyelés nem vesz észre.
Ez szemléltető helyzet, de a jogosulatlan átirányítás és a rejtett tartalom valódi támadási forma. A Google spamirányelvei is nevesítik ezeket. Egy feltört weboldal külsőre működőképes maradhat, miközben más belépési útvonalon idegen tartalmat szolgál ki. Az ügyfél ilyenkor a te céged nevéből indult, és a rossz élményt is ahhoz köti.
Az első jelnek ezért nem kell teljes leállásnak lennie. A keresési találat, egy váratlan felugró ablak vagy egy megmagyarázhatatlan adminfiók is elindíthatja a vizsgálatot. A hasznos kérdés az, hogy ki veszi észre ezeket, és ki dönt a következő lépésről. A gyors reakcióhoz ennek már a nyugodt időszakban világosnak kell lennie.
Az első négy jel az ügyfeled előtt jelenik meg
A látogatói bejelentéshez kérd el az érintett webcímet, az időpontot és azt, hogyan jutott oda az illető. Egy keresőtalálatból, hirdetésből vagy közvetlenül megnyitott oldal eltérően viselkedhet. Egy meglévő képernyőkép is segíthet; a böngésző veszélyjelzését azonban ne kapcsoltassuk ki az ügyféllel a reprodukció kedvéért. A további vizsgálatot az üzemeltető végezze biztonságos körülmények között.
- 1. Váratlan átirányítás: a keresési találat a céges szolgáltatás helyett más, oda nem illő oldalra visz. Az érkezés útvonala is fontos nyom.
- 2. Idegen tartalom a keresési találatban: olyan termék, ajánlat vagy szöveg jelenik meg, amelyet a vállalkozás soha nem tett közzé. A tartalom jogosulatlan eredete számít, nem az írásrendszere.
- 3. Biztonsági figyelmeztetés: a böngésző vagy a vírusvédelem veszélyes működést jelez. Az üzenet és az érintett URL maradjon meg a vizsgálathoz.
- 4. Ismeretlen reklám vagy felugró ablak: olyan elem jelenik meg, amelyhez nincs jóváhagyott kampány vagy beépített szolgáltatás. Külső beágyazás is lehet a forrása.
A Google Search Console Biztonsági problémák jelentése segíthet megismerni a kereső észlelését és az érintett példákat. A jelentés a vizsgálat egyik bemenete. Az üzemeltető a saját naplóival és az oldal tényleges tartalmával együtt tudja megállapítani, hol keletkezett a probléma.
Az adminfelületen a jogosultságok és változások adnak nyomot
Az adminfelület ellenőrzésénél a korábbi, jóváhagyott állapotból induljunk ki. Ki hozhat létre fiókot, milyen bővítmény került fel, ki módosított beállítást? Egy ismeretlen név még lehet elfelejtett szolgáltatói hozzáférés, de ezt a felelősnek igazolnia kell. A változási napló és a jogosultságlista sokkal többet mond, mint az, hogy az adminoldal most megnyitható-e.
- 5. Ismeretlen adminfiók: nincs megmagyarázható gazdája vagy jóváhagyása. Ha törlés után visszatér, a létrehozás okát is fel kell tárni.
- 6. Sorozatos frissítési hibák: a CMS, vagyis a tartalomkezelő, illetve a bővítmények nem frissülnek. Kérj konkrét hibaelemzést; jogosultság vagy konfiguráció is okozhatja.
- 7. Kéretlen regisztrációk tömege: a saját működéshez képest szokatlan fiókok keletkeznek. A regisztrációs spam önmagában nem igazolja, hogy a támadó már programot futtat a szerveren.
Az ellenőrzéshez legyenek meg a szükséges hozzáférések és felelősök. Ha a marketing, a fejlesztő és a tárhelyszolgáltató külön kezeli a weboldal részeit, egyetlen ember fogja össze a vizsgálatot. Így egy gyanús adminfiók nem marad két szolgáltató között, miközben mindkettő arra vár, hogy a másik válaszoljon.
A szerver jeleihez az üzemeltető mérései kellenek
A szerveroldali tünetek gyakran hétköznapi üzemzavarnak látszanak. A weboldal lassú, a levelezés problémás, vagy egy frissítés után új fájl jelenik meg. Ezeket érdemes a szokásos működéssel összevetni. A korábbi terhelés, a telepítések ideje és a levélküldési napló nélkül könnyű rossz okra következtetni.
- 8. Megmagyarázatlanul magas terhelés: a processzor vagy más erőforrás szokatlanul foglalt. A futó műveletet azonosítsuk; forgalmi csúcs és hibás program is lehet a háttérben.
- 9. Visszapattanó levelek áradata: kézbesítési hibaüzenetek érkeznek olyan levelekről, amelyeket nem küldtél. A szolgáltató ellenőrizze, történt-e tényleges küldés; feladóhamisítás is okozhat ilyen tünetet.
- 10. Váratlan fájl vagy módosítás: a telepítési előzményekkel nem magyarázható változás látszik. A fájl neve mellett a tartalmát, eredetét és futását kell ellenőrizni.
Egy jó hibajelzés után konkrét kérdés következik: melyik művelet terheli a gépet, melyik fiók küldött levelet, melyik telepítés változtatta meg a fájlt? Ha erre nincs válasz, a tünet továbbra is nyitott. A puszta újraindítás vagy fájltörlés átmenetileg eltüntetheti a látható problémát anélkül, hogy a bejutás oka megszűnne.
A kereső figyelmeztetése már a forgalmadat is érintheti
A Melapress 2026-os WordPress-felmérése 319 érvényes választ elemzett. Az incidenst tapasztalt válaszadók 42,6%-a furcsa működésről szóló bejelentést jelölt meg felismerési módként; ebbe látogató, ügyfél, kolléga és adminisztrátor is beletartozhatott. A kereső figyelmeztetésével felismert incidenseknél 45,9%, más felismerési módoknál 14,5% számolt be keresési helyezésvesztésről.
Ez válaszadói összefüggés, nem bizonyítja, hogy a Google figyelmeztetése okozta a kárt, vagy hogy a veszteség végleges. A minta WordPress-környezetből származik. A korai észlelés üzleti jelentőségét jelzi, de nem ad minden weboldalra alkalmazható előrejelzést.
Egy szolgáltató cég számára a keresőből érkező látogató egy lehetséges ajánlatkérés. Ha a biztonsági figyelmeztetésnél visszafordul, az ajánlatkérő neve sem kerül be a saját nyilvántartásba. Emiatt a kárt a technikai helyreállítás mellett az üzlet oldaláról is érdemes követni: alakulnak-e a beérkező érdeklődések, működnek-e a fontos céloldalak, milyen tapasztalatot jeleznek az ügyfelek?
A látogató védelme és az ellenőrzött helyreállítás együtt számít
Igazolt támadásnál az üzemeltető akadályozza meg a káros tartalom kiszolgálását. A Google elkülönítési útmutatója szerint a karbantartó válasz a fertőzött környezeten kívülről is adható. A rövid, átmeneti leállást 503-as HTTP-válasz jelezheti. Egy hibakód azonban önmagában nem teszi biztonságossá a mellé kiszolgált tartalmat. A robots.txt tiltása sem akadályozza meg, hogy a látogató elérje azt.
Rövid kiesésre tervezzünk, és a tartós leállást külön kezeljük. A Google ideiglenes szüneteltetésről szóló útmutatója szerint a hosszabb teljes leállás az indexelést is kedvezőtlenül érintheti. A karbantartó felületen a látogató kapjon használható tájékoztatást és elérhetőséget. A teljes webhely véletlen noindex jelölése további keresési problémát okozhat.
A tisztítás előtt legyen megőrzött napló és mentés a vizsgálathoz. A WordPress helyreállítási útmutatója is javasolja a tünetek dokumentálását és a környezet rögzítését. Ezután a bejutás okát, a jogosulatlan változásokat és a hozzáféréseket együtt kell rendezni. A mentés visszaállítása csak akkor használható megoldás, ha a visszaállított állapot és a megmaradó támadási lehetőség is ellenőrzött.
Ha a Google biztonsági problémát jelzett, a javítás után a Search Console felületén felülvizsgálat kérhető. Ez napokig vagy hetekig tarthat. A figyelmeztetés megszüntetése nem a keresési helyezések visszatérésének határideje. A helyreállítás után ezért a biztonsági eseményeket és a keresőből érkező forgalmat is tovább kell figyelni.
Már most legyen világos, ki kapja a riasztást, ki intézkedik, és ki ellenőrzi, hogy tiszta állapot állt helyre. A válasz legyen elérhető a munkatársaknak és a szolgáltatóknak. Egy rövid próba megmutathatja, hogy egy gyanús átirányításról szóló ügyfélüzenet valóban eljut-e ahhoz, aki meg tudja állítani a káros kiszolgálást.
