Hamis Googlebotok felismerése és blokkolása .htaccess segítségével – Hatékony védelem weboldaladnak

A hamis Googlebotok .htaccess fájllal történő felismerése és blokkolása azt jelenti, hogy azokat a kártékony botokat, amelyek úgy próbálják álcázni magukat, mintha Googlebot lennének, a felhasználói ügynök, IP-cím ellenőrzés és hozzáférési naplók alapján elkülönítjük, és a valódi Googlebotokat nem érintve 403-as tiltással megállítjuk. A leghatékonyabb megoldás az, ha nem csak a User-Agent mezőre hagyatkozunk, hanem figyelembe vesszük a Google hivatalos IP-tartományait vagy a reverse DNS ellenőrzést, először naplózzuk a gyanús kéréseket, majd szigorú, jól átgondolt .htaccess szabályokkal szűrjük a forgalmat.

Sok támadó bot azért adja ki magát Googlebotnak, Google-InspectionToolnak, AdsBot-Google-nak vagy Googlebot-Image-nek, hogy megússza a tűzfalak és egyszerű bot-szűrők akadályait. A weboldal tulajdonosok ugyanis gyakran óvakodnak a Googlebot letiltásától. Ez a rés lehetőséget ad tartalommásolásra, túlzott erőforrás-felhasználásra, hamis forgalom generálására, űrlap spamre, betörési kísérletekre és a SEO-adatok torzulására. Különösen megosztott tárhelyeken, WordPress, WooCommerce alapú webáruházaknál, hírportálokon és gyakran frissülő blogokon ennek a forgalomnak a kezelése rövid idő alatt a CPU, RAM és I/O kvóták kimerüléséhez vezethet. Ebben az útmutatóban lépésről lépésre megmutatjuk, hogyan ismerheted fel a hamis Googlebot viselkedést, miként állíthatsz fel biztonságos .htaccess szabályokat, és milyen ellenőrzéseket végezz, hogy véletlenül se zárd ki a valódi Googlebotot. Ha megbízható, gyors és skálázható webkiszolgálóra van szükséged, érdemes lehet megnézned a Hostragons web hosting megoldások és az SSL tanúsítvány telepítése témaköröket is.

Mi az a hamis Googlebot, és miért veszélyes?

A hamis Googlebot olyan automatikus lekérdező, amely a HTTP kérés User-Agent mezőjében úgy tünteti fel magát, mint a Google hivatalos keresőrobotja, de valójában nem a Google IP-címeiről érkezik. A User-Agent egy egyszerű szöveges azonosító, így bárki könnyedén hamisíthatja azt. Ezért önmagában a User-Agent ellenőrzése nem elegendő a biztonságos szűréshez.

A valódi Googlebot célja, hogy feltérképezze weboldaladat, indexelje az oldalakat, és frissítéseket keressen, miközben minőségi jeleket gyűjt a kereső számára. A hamis Googlebot ezzel szemben gyakran más célokat szolgál: lehívhatja a termékek árait, lemásolhatja a tartalmakat, próbálgathatja az adminisztrációs felületek URL-jeit, túlterhelheti a keresési oldalakat, vagy sebezhetőségeket kereshet bővítményekben. Egyes támadók másodpercenként akár több tucat kérést is küldhetnek, ami egy kisebb webhelyen is komoly teljesítménycsökkenést okozhat.

Gyakran az alábbi jelek utalnak hamis botokra:

• Rövid idő alatt több száz 404-es, 403-as vagy 500-as hibaválasz generálása.
• Érzékeny útvonalak, mint pl. wp-login.php, xmlrpc.php, admin, phpmyadmin vagy backup.zip keresése.
• Googlebotnak tűnő User-Agent, de az IP-cím nem szerepel a Google ASN vagy hivatalos IP tartományai között.
• Robots.txt szabályok figyelmen kívül hagyása, például szűrők, keresési oldalak, kosár vagy fiók oldalak látogatása.
• A valódi Googlebothoz képest túlzottan nagy gyakorisággal ismétlődő URL-kérések.

Miért nem elég csak a User-Agent ellenőrzése?

A HTTP fejlécben szereplő Googlebot User-Agent még nem bizonyítja, hogy a kérés valóban a Google-tól származik. Például egy egyszerű curl parancssorból könnyedén hamisítható ez az érték. Ezért a .htaccess fájlba csak a "Googlebot" kifejezést keresve vagy letiltva hibás stratégia: az egyik esetben a valódi Googlebotot blokkolhatjuk, a másik esetben pedig a támadókat engedjük be.

A 2026-os SEO és biztonsági trendek szerint a helyes megközelítés háromrétegű: az állított identitás ellenőrzése, IP- vagy DNS-alapú hitelesítés, valamint a szokatlan viselkedés naplóalapú monitorozása. Ez a módszer egyszerre védi meg a Google láthatóságot és a szerver erőforrásait a felesleges botforgalomtól.

Hogyan igazoljuk a valódi Googlebotot?

A Google két fő módszert javasol a keresőrobotjainak ellenőrzésére: a reverse DNS ellenőrzést és a hivatalos IP-tartományok használatát. A reverse DNS esetén a kérés IP-címéhez tartozó domain névnek a googlebot.com vagy google.com végződésűnek kell lennie, majd ezt a domain nevet újra vissza kell fordítani ugyanarra az IP-címre. Ez a kétirányú ellenőrzés megakadályozza a hamis PTR rekordokkal való megtévesztést.

A másik megoldás a Google által közölt hivatalos IP-tartományok használata. Googlebot, speciális robotok és felhasználó által indított lekérések külön JSON listákban érhetők el. Mivel ezek a listák idővel változhatnak, nem ajánlott hosszú távon kézzel karbantartott IP-listákra hagyatkozni. Ha saját VPS-ed vagy szervered van, érdemes ezeket rendszeresen lekérni és tűzfal vagy Apache include fájl formájában frissíteni. Megosztott tárhely esetén a hozzáférési naplók, .htaccess és biztonsági modulok segítségével fokozatosan szűrhetsz.

Hamis Googlebot blokkolás .htaccess segítségével – az alapok

A .htaccess az Apache szerverek könyvtárankénti szabályait kezeli. URL átirányításra, hozzáférés szabályozására, tömörítésre, gyorsítótárazásra és biztonsági korlátozásokra használható. A hamis Googlebotok esetén a .htaccess feladata a bejövő kérések szűrése bizonyos feltételek alapján, és a gyanús kérések 403 Forbidden válasszal való leállítása.

Fontos megjegyezni, hogy a .htaccess önmagában nem alkalmas valós idejű reverse DNS lekérdezések futtatására, mert a HostnameLookups funkció teljesítménybeli okokból általában ki van kapcsolva. Ezért a legpraktikusabb megoldás, hogy a Googlebot User-Agentet mutató kéréseket IP engedélyező listához hasonlítjuk, vagy szigorúbb szabályokat alkalmazunk bizonyos érzékeny útvonalakon. Összetettebb ellenőrzéshez WAF, szerveroldali tűzfal, CDN vagy naplóalapú automatizáció ajánlott. Ehhez segítségül hívhatod a Mi az a CDN és hatása a weboldal teljesítményére tartalmat.

Lépésről lépésre: hamis Googlebotok felismerése és blokkolása

1. Ellenőrizd a hozzáférési naplókat

Mielőtt szabályokat írnál, legalább 24-72 órányi access logot vizsgálj meg. Nagyobb forgalmú oldalak esetén egy óra naplója is elég információt adhat. Figyeld az IP-címeket, dátumot, lekért URL-eket, HTTP státuszkódokat, válaszméretet, hivatkozót és a User-Agent mezőt. Például, ha ugyanaz az IP-cím 10 perc alatt 800 lekérést küld, és ezek közül sok 404-es hibával tér vissza, miközben Googlebotnak álcázza magát, az erős gyanúra ad okot.

cPanel vagy egyéb admin felületeken elérhető a Raw Access Logs, ahonnan letöltheted a naplókat. SSH hozzáférés esetén grep, awk vagy sort parancsokkal szűrheted a Googlebot User-Agentes IP-k viselkedését, hogy ne egyes kéréseket, hanem IP-alapú mintázatokat elemezz.

2. Ellenőrizd a Googlebotnak mondott IP-ket

Azonosítsd a gyanús IP-címeket, majd végezz reverse DNS (PTR) és forward DNS ellenőrzést. Ha egy IP-hez tartozó PTR rekord például crawl-66-249-66-1.googlebot.com, az első lépést sikeresen teljesítette. Ezután a domain nevet újra visszafordítva ugyanarra az IP-re kell mutatnia. Ha nincs PTR rekord, vagy az eltérő domainre mutat, vagy forward DNS nem egyezik az IP-vel, akkor ne fogadd el valódi Googlebotként.

Ezzel az ellenőrzéssel megakadályozhatod, hogy a valódi Googlebotot blokkoló szabályokat alkalmazz. Hiszen a valódi Googlebot letiltása késleltetheti az új tartalmak feltérképezését, csökkentheti az indexfrissítések gyakoriságát, és a Google Search Console-ban hibák megjelenését okozhatja, ami organikus látogatószám csökkenéshez vezethet. Ezért ne hozz döntést egyetlen User-Agent sor alapján, mindig végezd el az ellenőrzést.

3. Naplózás után jöhet a blokkolás

A biztonságos üzemeltetés érdekében először ajánlott az észlelt gyanús IP-k és User-Agent-ek naplózása. Második lépésben csak az egyértelműen káros viselkedést mutató útvonalakat korlátozd. Harmadik lépésként pedig zárd ki azokat a lekéréseket, amelyek Googlebotnak adják ki magukat, de nem esnek a Google IP-tartományaiba.

Különösen fontos ez e-kereskedelmi oldalak esetén, mert egy hibás szabály megzavarhatja a fizetési folyamatot, kosarat, termékváltozatokat vagy készletkezelést. Ha nagy forgalmad van, mindenképp teszteld a szabályokat egy fejlesztői környezetben. Ehhez a WordPress oldal átköltöztetése és tesztkörnyezet létrehozása is segítséget nyújt.

Biztonságos .htaccess szabályminták

Az alábbi példák előtt mindig teszteld a szervered Apache verzióját, az aktív modulokat és a tárhelyed engedélyeit. Az Apache 2.4 és a mod_rewrite modul jellemzően elérhető, de egyes megosztott környezetekben bizonyos direktívák tiltottak lehetnek. Mielőtt módosítod a .htaccess fájlt, készíts róla biztonsági másolatot! Egyetlen szintaktikai hiba 500 Internal Server Error-t okozhat az oldaladon.

Egyszerű viselkedésalapú szűrő – érzékeny útvonalakon hamis botok leállítása

Ezzel a módszerrel megakadályozhatod, hogy a Googlebotnak tűnő botok hozzáférjenek adminisztrációs vagy támadásra célzott fájlokhoz. A valódi Googlebot nem keres fel wp-login.php-t, phpmyadmin-t vagy biztonsági mentés ZIP fájlokat, így a téves blokkolás kockázata alacsony.

• RewriteEngine On
• RewriteCond %{HTTP_USER_AGENT} (Googlebot|Google-InspectionTool|AdsBot-Google|Mediapartners-Google) [NC]
• RewriteCond %{REQUEST_URI} (wp-login[.]php|xmlrpc[.]php|phpmyadmin|adminer|backup|[.]sql|[.]zip) [NC]
• RewriteRule ^ - [F,L]

Ez a szabály, ha egy Googlebotnak álcázott kliens érzékeny útvonalat kér, 403-as választ ad. A SEO-t nem befolyásolja, mert ezek az oldalak nem szerepelnek a Google indexében. WordPress esetén azonban érdemes átnézni a biztonsági bővítményeket, az XML-RPC használatát és a távoli publikálás igényét.

IP engedélyező lista (allowlist) – Googlebot IP-k ellenőrzése

Egy erősebb megoldás, ha csak a Google hivatalos IP tartományairól érkező Googlebot User-Agentes kéréseket engedélyezed. Az alábbi példa szemlélteti az elvet, de a valós környezetben mindig a Google aktuális, JSON alapú IP-listáját használd. Régi vagy hiányos lista téves tiltásokat eredményezhet.

• RewriteEngine On
• RewriteCond %{HTTP_USER_AGENT} (Googlebot|Googlebot-Image|Googlebot-News|Google-InspectionTool|AdsBot-Google) [NC]
• RewriteCond expr "! ( %{REMOTE_ADDR} -ipmatch '66.249.64.0/19' || %{REMOTE_ADDR} -ipmatch '64.233.160.0/19' || %{REMOTE_ADDR} -ipmatch '72.14.192.0/18' )"
• RewriteRule ^ - [F,L]

Az itt szereplő IP-k csak példaértékűek. A gyakorlatban automatikusan frissített, naprakész Googlebot IP tartományokat kell használni. Ha a szervered nem támogatja az Apache expr kifejezést vagy az -ipmatch operátort, kérd ki a tárhelyszolgáltatód támogatását az Apache 2.4-es szintaxisra. Alternatív megoldásként a CDN vagy WAF rétegben is megvalósítható a szabályozás.

Szokatlan kérésgyorsaság csökkentése

A .htaccess nem a legjobb eszköz a fejlett rate limitinghez, de néhány rosszindulatú viselkedés gyors leállítására alkalmas lehet. A valódi sebességkorlátozáshoz mod_evasive, mod_security, CDN rate limiting vagy alkalmazásszintű védelem ajánlott. Különösen a másodpercenként 5-10-nél több folyamatos kérést indító botok növelik jelentősen az adatbázis lekérdezések számát. WordPress alapú oldalakon a keresési, szűrő vagy kategória oldalak könnyen kihasználhatók botok által. Ezeknél a területeknél a robots.txt, canonical címkék, noindex direktívák és biztonsági szabályok együttes alkalmazása javasolt. A WordPress sebesség optimalizálási útmutató segít a teljesítmény javításában.

Összehasonlító táblázat: mikor melyik módszert válaszd?

Mit ellenőrizz, hogy véletlenül se blokkolj valódi Googlebotot?

A hamis Googlebotok elleni védekezés legnagyobb kockázata, hogy véletlenül a valódi Googlebotokat is kizárod. Ezért minden változtatás után érdemes végignézni az alábbi listát:

• Van-e hirtelen visszaesés vagy 403-as hibák növekedése a Google Search Console Felderítési statisztikákban?
• A szerver naplóiban a valódi Google IP-címekről érkező kérésekre 200, 301 vagy más megfelelő státuszkódok érkeznek?
• A robots.txt fájl nem tiltja el a Googlebotot olyan kritikus könyvtáraktól, amelyek elengedhetetlenek az indexeléshez?
• A .htaccess módosítás előtt és után tesztelted a webhelytérképet, kezdőlapot, kategória- és fontos termékoldalakat?
• Dokumentáltad az IP-lista forrását és frissítésének időpontját?

Technikailag a 403-as válasz erős jelzés a botoknak, de ha a valódi Googlebot ismételten 403-at kap fontos oldalakon, akkor azok indexelése csökkenhet. Ezért a 403-at csak a valóban nemkívánatos botokra és érzékeny útvonalakra alkalmazd. Bizonyos esetekben, például karbantartás vagy ideiglenes túlterheltség esetén a 429 Too Many Requests válasz is megfelelő lehet, de egyszerű botblokkoláshoz a 403 a legelterjedtebb és leginkább érthető.

Extra intézkedések WordPress és webáruházak számára

WordPress oldalakon a hamis Googlebot forgalom gyakran az xmlrpc.php, wp-login.php, REST API végpontok, keresési URL-ek és szerzői archívumok körül koncentrálódik. E-kereskedelmi oldalakon a szűrő paraméterek, készletlekérdezések, kosár funkciók és termékváltozatok a fő célpontok. Ezért ne csak a Googlebotnak álcázókat szűrd, hanem általános bot-higiéniát is tarts fenn.

• Használj kétfaktoros hitelesítést és próbálkozás korlátozást a bejelentkezési oldalon.
• Kapcsold ki vagy korlátozd az XML-RPC funkciókat, ha nem használod.
• A keresési és szűrő URL-eknél alkalmazz noindex, canonical és robots.txt szabályokat együtt.
• Mindig frissebb PHP verziót, naprakész témát és megbízható bővítményeket használj.
• Aktiváld az SSL tanúsítványt, mert a HTTPS alapvető a biztonságos munkamenethez és űrlapokhoz. Hostragons SSL tanúsítványok
• Rendszeresen ellenőrizd domain DNS beállításaidat, mert a rossz DNS és gyenge e-mail konfigurációk biztonsági kockázatot jelentenek. Domain ellenőrzés és DNS kezelés

Teljesítményhatás: hogyan emészti fel a botforgalom a szerver erőforrásait?

A botforgalom nem csak biztonsági probléma, hanem jelentős hosting teljesítménycsökkentő tényező is. Egy statikus kép lekérése kevés erőforrást igényel, de egy WordPress keresési oldal vagy WooCommerce szűrőoldal több adatbázis-lekérdezést generál. Ha egy hamis Googlebot percenként 300 dinamikus kérést indít, a gyorsítótárazatlan oldalak PHP-folyamatai elfoglalhatják a munkameneteket, az adatbázis kapcsolatok száma nő, és a valódi látogatók lassú válaszokat kapnak.

Például, ha egy termék szűrőoldal átlagosan 250 ms PHP feldolgozási időt igényel, akkor 600 bot kérés percenként összesen 150 másodpercnyi processzoridőt fogyaszt. Ez párhuzamosan futva megközelítheti a CPU határt, és növeli a TTFB értékeket. A Core Web Vitals mutatókban a lassú szerverválasz negatívan hat a felhasználói élményre és a konverziós arányokra. Ezért a botblokkolás nemcsak a biztonsági csapat, hanem a SEO és a teljesítmény-optimalizáció kulcseleme is.

Hogyan teszteld, hogy működnek-e a szabályok?

A .htaccess szabályok hozzáadása után három tesztet érdemes elvégezni. Először böngészőből ellenőrizd a kezdőlapot, fontos kategóriaoldalakat és bejelentkezési folyamatokat. Másodszor a Google Search Console URL-ellenőrző eszközzel tesztelj egy kulcsfontosságú URL-t. Harmadszor pedig a naplókban ellenőrizd, hogy a Googlebot User-Agenttel érkező gyanús IP-k 403-as választ kapnak, míg a valódi Google IP-k továbbjutnak.

Parancssorból is kipróbálhatod, hogy a User-Agent mező változtatásával elérsz-e 403-at, de ez csak a szabály User-Agent részének működését mutatja, nem bizonyítja a valódi Googlebot elleni blokkolást. Az IP és DNS alapú ellenőrzés nélkülözhetetlen. Ha 500-as hibát kapsz, valószínűleg szintaktikai hibát követtél el a .htaccess-ben. Ilyenkor távolítsd el az új szabályokat, nézd át a hibanaplókat, és ellenőrizd az Apache verzióját és moduljait.

Karbanartási javaslatok: milyen gyakran frissítsd a szabályokat?

A botblokkolás nem egyszeri feladat. A Google IP tartományai változhatnak, a támadók új User-Agent mintákat használhatnak, és az oldal URL-struktúrája is módosulhat. Kis forgalmú oldalaknál havi egy naplóellenőrzés is elegendő, de nagyobb hírportálok, webshopok vagy kampányoldalak esetén heti rendszeresség javasolt. Nagy projektek esetén érdemes automatikus riasztásokat beállítani: például ha egy adott időszakban megnő a Googlebot User-Agenttel érkező, de nem hitelesített IP-k száma, értesítés érkezzen.

Emellett verziókövetéssel tartsd nyilván a .htaccess változásait. Egy egyszerű dátumos mentés (például htaccess-2026-02-15.bak) jelentősen megkönnyíti a hibák visszavonását. Ha több ember dolgozik a weboldalon, a szabályokhoz fűzzetek rövid megjegyzéseket, hogy ki, mikor és miért tette be a módosítást – ezzel minimalizálható a hibákból eredő leállás.

Összegzés

A hamis Googlebotok .htaccess segítségével történő felismerése és blokkolása megfelelő alkalmazás esetén megóvja SEO láthatóságodat, és felszabadítja szervered erőforrásait a rosszindulatú robotoktól. Az alapelv egyértelmű: a User-Agent önmagában nem bizonyíték, IP, DNS, viselkedés és naplóelemzés együttes értékelése szükséges. Először figyeld a forgalmat, majd korlátozd a kockázatos útvonalakat, végül a Google hivatalos IP listájával ellenőrizve szűrd a kéréseket.

Ha a Hostragons infrastruktúráján fut webhelyed, a biztonságos tárhely, naprakész SSL, megfelelő DNS beállítások és rendszeres mentések együtt stabilabb és gyorsabb webélményt biztosítanak. Kezdheted a botforgalom elemzésével, és ha szükséges, a Hostragons hosting csomagok közül választhatsz még hatékonyabb és biztonságosabb megoldást.

Gyakran ismételt kérdések

Befolyásolja a hamis Googlebot a valódi Google rangsorolásomat?

Közvetetten igen. Ha a hamis Googlebot túlzott erőforrást fogyaszt, a valódi felhasználók és a valódi Googlebot lassabb válaszokat kapnak. Emellett a naplóadatok és analitikák torzulhatnak, ami félrevezető SEO döntéseket eredményez. A helyes blokkolás segít megőrizni a feltérképezési költségvetést és a szerver teljesítményét.

Jó ötlet az összes Googlebot User-Agentet blokkolni .htaccess-ben?

Nem. Ez a megközelítés könnyen letilthatja a valódi Googlebotot, ami indexelési problémákhoz vezethet. Először mindig IP- vagy DNS-alapon igazold a Googlebotot, és csak a hamisnak bizonyult kéréseket tiltsd le. A legbiztonságosabb módszer a allowlist és viselkedésalapú szabályok kombinációja.

Milyen gyakran frissítsem a Googlebot IP listákat?

Nagy forgalmú oldalak esetén heti, kisebb oldalaknál havi rendszerességgel javasolt a frissítés. A legjobb, ha automatikusan lekéred a Google hivatalos JSON IP-forrásait, mert a kézzel karbantartott listák idővel elavulhatnak, és téves tiltásokhoz vezethetnek.

500-as hibát kaptam a .htaccess szabály hozzáadása után, mit tegyek?

Az 500-as hiba általában szintaktikai hiba, nem támogatott Apache direktíva vagy helytelen karakterhasználat miatt jön létre. Távolítsd el az utoljára hozzáadott sorokat, ellenőrizd a hibanaplókat, és győződj meg róla, hogy a szerver Apache 2.4-es, mod_rewrite és kifejezés-támogatással rendelkezik. Ezért is fontos mindig biztonsági másolatot készíteni a .htaccess fájlról.

Ha CDN vagy WAF-t használok, szükség van még .htaccess szabályokra?

A CDN és WAF erős védelmi réteget adnak a botok ellen, de a .htaccess továbbra is fontos kiegészítő réteg lehet, különösen az alkalmazáshoz közeli, finomhangolt szabályozásban. A legjobb eredmény akkor születik, ha a CDN/WAF-ben rate limit és bot-ellenőrzés, míg a szerveren érzékeny útvonalakon .htaccess korlátozások futnak.