Google biztonsági figyelmeztetés az oldalad előtt: így kerülj le a feketelistáról

Frissítve: 2026. október · Írta: Busai Gábor, 15+ év WordPress-tapasztalat

Van egy pillanat, ami minden más hibánál rosszabb: amikor a weboldalad helyett egy piros, egész képernyős figyelmeztetés jelenik meg, hogy „Megtévesztő webhely” vagy „Ez a webhely káros programokat tartalmazhat”. Az oldal technikailag működik – csak senki nem jut el hozzá.

A forgalom ilyenkor nem csökken, hanem megáll. A Google saját adatai szerint a látogatók elsöprő többsége visszafordul egy ilyen figyelmeztetésnél, és a Chrome, a Firefox és a Safari ugyanazt a Safe Browsing listát használja – vagyis egyszerre mindhárom böngészőben megjelenik.

Ez a cikk végigvezet a teljes folyamaton: hogyan állapítsd meg, min vagy listán, miért ne kérj felülvizsgálatot elsőként, és hogyan kerülj le rendesen – úgy, hogy ne kerülj vissza.

Mit lát a látogató?

Nem az oldaladat. Egy piros köztes képernyőt, amin a „Vissza a biztonságos helyre” a hangsúlyos gomb, és a továbblépés egy apró, szürke link mögé van rejtve. A szöveg attól függ, mit talált a Google:

Ez utóbbi fontos: nem minden esetben a te oldalad a fertőzött. Előfordul, hogy egy harmadik féltől betöltött szkript – régi hirdetési kód, elhagyott widget, lejárt domainre mutató JS – viszi a figyelmeztetést. Ilyenkor a megoldás annak az erőforrásnak az eltávolítása.

1. lépés: pontosan mi a baj? (Search Console)

Ne tippelj – a Google megmondja. Search Console → Biztonság és kézi műveletek → Biztonsági problémák.

Itt három dolgot kapsz, és mind a három kell:

• A probléma típusa – malware, megtévesztő oldal, kártékony letöltés, nem kívánt szoftver.
• Minta URL-ek – konkrét oldalak, ahol a Google látta a problémát. Ez a legértékesebb, mert megmutatja, hol kezdj keresni.
• Az észlelés dátuma – ehhez tudod igazítani a fájldátum-vizsgálatot és a naplókat.

Ha nincs még Search Console-od az oldalhoz, most állítsd be – enélkül nem is tudsz felülvizsgálatot kérni. A hitelesítés DNS-rekorddal vagy HTML-fájllal megy, pár perc.

Második forrás: a Google Safe Browsing átláthatósági oldalán (transparencyreport.google.com) is megnézheted a domain állapotát bejelentkezés nélkül. Ez akkor hasznos, ha ügyfél oldaláról van szó, és még nincs hozzáférésed.

2. lépés: mentés, mielőtt bármihez hozzányúlsz

Igen, a fertőzött állapotról is. Két okból:

• Ez lesz a bizonyíték: a fájldátumok, a kártékony kód és a naplók együtt mondják meg, hogyan jutottak be. Ha ezt nem tudjuk meg, a lyuk nyitva marad.
• Ez lesz a visszaút, ha a takarítás során letörlünk valamit, amire mégis szükség volt.

Fájlok és adatbázis, külön fájlba, letöltve a szerverről – ne csak a szerveren hagyva.

3. lépés: a takarítás – és miért ez a nehéz része

A takarítás nem az, hogy megkeressük a kártékony fájlt és letöröljük. Az a látható része. A tényleges munka a hátsó ajtók megtalálása: azok a kis kódrészletek, amik lehetővé teszik, hogy a támadó bármikor visszatérjen, és újratelepítse az egészet.

Ezért fordul elő olyan gyakran, hogy valaki „kitakarította” az oldalt, három nap múlva pedig ott van minden újra.

Amit végig kell nézni:

1. A Search Console minta URL-jei – itt kezdj, mert a Google konkrétumot adott.
2. PHP-fájlok az uploads mappában – ott soha nem szabadna lennie: find wp-content/uploads -name "*.php"
3. A mu-plugins mappa – ami ott van, automatikusan aktív, és nem kapcsolható ki az adminból.
4. Az .htaccess fájlok – minden könyvtárban, nem csak a gyökérben. A rejtett átirányítások kedvelt helye.
5. A core fájlok – hasonlítsd össze egy friss WordPress letöltéssel. Minden eltérés gyanús.
6. Az adatbázis – a wp_options táblában, különösen az automatikusan betöltődő sorokban, és a bejegyzések tartalmában elhelyezett szkriptek.
7. Ütemezett események – a cron-ba beültetett újratelepítő.
8. Felhasználók – ismeretlen admin, vagy megemelt szerepkör.

A gyanús kód tipikus jelei: eval(, base64_decode, gzinflate, str_rot13, hosszú értelmetlen karakterláncok, és olyan fájlok, amiknek a neve hitelesnek hangzik, de nem tartozik egyetlen telepített bővítményhez sem.

A feltörés felismeréséről részletesen itt írtam: Honnan tudod, hogy feltörték a WordPress oldalad? 12 árulkodó jel

4. lépés: jelszavak és sózókulcsok

Ez a lépés az, amit a leggyakrabban kihagynak – és amitől a támadó bent marad a takarítás után is.

• Minden WordPress admin jelszó, és nézd át a felhasználólistát.
• FTP/SFTP és SSH jelszavak.
• Adatbázis-jelszó (utána a wp-config.php-ban is át kell írni).
• A tárhely vezérlőpultjának jelszava.
• A WordPress sózókulcsok – a wp-config.php AUTH_KEY blokkja. Generálj újat az api.wordpress.org/secret-key szolgáltatással. Ez minden meglévő bejelentkezést érvénytelenít, beleértve a támadóét is. Enélkül a jelszócsere nem elég.
• Alkalmazásjelszavak – ha használsz ilyet, vond vissza mindet és generálj újat.

5. lépés: ellenőrizd, hogy tényleg tiszta

Mielőtt felülvizsgálatot kérsz, legyen bizonyosságod. Ha elutasítják a kérelmet, a következő körre hosszabb a várakozás, és a forgalmad közben áll.

1. Nézd meg a Search Console minta URL-jeit – mindegyiket, egyenként, a saját böngészőben és privát ablakban is.
2. Mobil teszt mobilhálózaton, a Google találatról kattintva. A szelektív átirányítások csak így jönnek elő.
3. site:adomainod.hu a Google-ben – van még idegen tartalom az indexben?
4. Futtass le egy külső szkennert (Sucuri SiteCheck, VirusTotal URL-ellenőrzés). Nem tökéletesek, de a maradék nyilvánvaló dolgokat megfogják.
5. Nézd meg a kimenő kéréseket a böngésző Network fülén: tölt-e be az oldal olyan domaint, amit nem ismersz fel?
6. Hibanapló: van-e még gyanús bejegyzés? (naplóolvasás útmutató)

6. lépés: a felülvizsgálati kérelem

Search Console → Biztonsági problémák → Felülvizsgálat kérése.

A kérelem szövege számít. A Google munkatársa azt szeretné látni, hogy érted, mi történt, és hogy a lyuk is be van zárva – nem csak a tünet eltüntetve. Konkrétumok kellenek, nem ígéretek.

Ez a szerkezet nálam bevált (írhatod magyarul, de angolul általában gyorsabb):

A fertőzést 2026-10-14-én azonosítottuk.

Amit találtunk:
- Kártékony PHP-fájlok a wp-content/uploads/2026/08/ mappában (4 db),
  amelyek rejtett átirányítást végeztek a keresőből érkező mobil
  látogatóknál.
- Egy hátsó ajtó a wp-content/mu-plugins/ mappában.
- Egy ütemezett esemény, amely újratelepítette a kódot.

A belépési pont:
- Egy elavult bővítmény ismert sérülékenysége (a bővítményt eltávolítottuk).

Amit tettünk:
- Az összes érintett fájlt eltávolítottuk, a WordPress core-t és
  minden bővítményt a hivatalos forrásból telepítettük újra.
- Az adatbázist átvizsgáltuk, a beszúrt szkripteket eltávolítottuk.
- Minden jelszót (WordPress, FTP, adatbázis, vezérlőpult) és a
  WordPress sózókulcsokat lecseréltük; az ismeretlen admin
  felhasználót töröltük.
- Az ütemezett eseményt eltávolítottuk.
- A PHP futtatását letiltottuk az uploads mappában.
- Bekapcsoltuk a kétlépcsős azonosítást, és beállítottuk az
  automatikus frissítéseket.

Az érintett URL-eket egyenként ellenőriztük, asztali és mobil
eszközön, keresőből érkezve is. Az oldal tiszta.

Amit ne írj: „kitakarítottuk, kérem a feloldást”. Ez túl kevés információ, és a kérelmeket gyakran elutasítják miatta.

Meddig tart?

A malware-figyelmeztetés feloldása jellemzően egy-három nap, de lehet rövidebb is. Adathalászat esetén általában lassabb. Az állapotot a Search Console-ban követheted – a kérelem „Felülvizsgálat folyamatban” állapotba kerül.

Amíg tart: ne nyúlj az oldalhoz érdemben, és ne adj be újabb kérelmet. A többszörös kérelem nem gyorsít, inkább hátráltat.

Nem csak a Google listázza

A Safe Browsing feloldása után is maradhatnak nyomok máshol. Érdemes végigmenni rajtuk:

• Norton Safe Web és McAfee SiteAdvisor – saját újraértékelési űrlapjuk van. Ezek sok vállalati hálózatban és antivírusban aktívak.
• Yandex Webmaster – ha van orosz nyelvű forgalmad.
• E-mail feketelisták (Spamhaus, SORBS) – ha az oldal spamet küldött, a szerver IP-je is listára kerülhetett. Ez külön feloldási folyamat, és a leveleid kézbesítését érinti.
• A tárhelyszolgáltató – néhányan felfüggesztik vagy karanténba teszik a fiókot. Szólj nekik, hogy a takarítás megtörtént.
• Cloudflare vagy CDN – ürítsd a gyorsítótárat, különben a régi, fertőzött verziót szolgálja ki.

Mit mondj közben az ügyfeleknek?

Ez a rész technikailag nem tartozik a javításhoz, de üzletileg sokszor fontosabb nála. A látogatóid és az ügyfeleid egy piros figyelmeztetést láttak a nevedben, és ez bizalmi kérdés.

Néhány dolog, ami segít:

• Szólj előbb, mint ahogy megkérdezik. Egy rövid e-mail vagy közösségi bejegyzés arról, hogy tudtok a problémáról, dolgoztok rajta, és mikorra várható a megoldás – ez többet ér, mint a hallgatás.
• Ne bagatellizáld, de ne is dramatizáld. „Biztonsági incidens történt, a hibát azonosítottuk és javítjuk” pontos és nyugodt.
• Ha webshop vagy, és fizetési adatok is érintve lehettek, az külön elbírálás alá esik: ott tájékoztatási és adatvédelmi kötelezettséged is lehet. Ez jogi kérdés, nem technikai – érdemes szakemberrel egyeztetni, mert az elmulasztott bejelentésnek következménye van.
• Ha van hírleveled, azt ne a fertőzött oldalról küldd ki – a szerver IP-je lehet, hogy épp feketelistán van, és a levél sem érne célba.

A legtöbb ügyfél megértő, ha látja, hogy kézben van a helyzet. Amit rosszul tűrnek, az a csend és a bizonytalanság.

Mi lesz a Google-helyezéssel?

A jó hír: a biztonsági figyelmeztetés nem büntetés, hanem védelem. A feloldás után a helyezések jellemzően visszaállnak – de nem azonnal.

Amire számíthatsz:

• A forgalom néhány nap alatt tér vissza, ahogy a böngészők frissítik a Safe Browsing listát.
• Az indexelt spam oldalak maradnak egy ideig. Ha sok ilyen keletkezett, a Search Console eltávolítási eszközével kérheted a törlésüket, és érdemes 410-es választ adni rájuk, hogy a Google véglegesen kivegye őket.
• A hosszabb fertőzés nyomot hagyhat. Ha hónapokig tartott, a helyreállás is hetekbe telhet – de visszajön.

Hogy ne kerülj vissza

1. Frissíts. A behatolások túlnyomó többsége ismert, már javított sérülékenységen jön be.
2. Dobd ki, amit nem használsz. A kikapcsolt bővítmény kódja is támadható.
3. Tiltsd le a PHP futtatását az uploads mappában – egyetlen .htaccess szabály, és a leggyakoribb támadási utat zárja le.
4. Kétlépcsős azonosítás minden admin fióknál.
5. Fájlváltozás-figyelés. Ha valami módosul a core-ban vagy a bővítményekben, arról kapj levelet.
6. Search Console legyen bekötve, és olvasd a leveleit. A legtöbb oldalnál a Google szól először.
7. Független mentés, amit a szerverről nem lehet elérni – és amiről tudod, hogy mikor készült, és hogy még tiszta volt.

Erről bővebben: Miért fontos a havi karbantartás és a saját biztonsági mentés? · Havi WordPress karbantartás

Gyakori kérdések

Kapcsolódó olvasnivaló: Honnan tudod, hogy feltörték a WordPress oldalad? · Hol van a WordPress hibanapló? · Fehér képernyő a WordPress oldalon