Amikor a tűzfal vagy biztonsági bővítmény kizárja a Googlebotot

Scheo · 2026-10-11 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Egy biztonsági bővítmény vagy tárhelyes tűzfal dolga az, hogy kiszűrje a gyanús forgalmat. A gond ott kezdődik, amikor a Googlebot is gyanúsnak tűnik neki. A robot rövid idő alatt sok kérést küld, rengeteg különböző URL-t nyit meg, nem tárol sütit, és nem lép be sehova. Pontosan ezt a viselkedést mutatja egy tartalomlopó vagy sebezhetőséget kereső robot is. Ebben a cikkben végigmegyünk azon, hogyan veszed észre, ha a védelem a keresőrobotot is megfogja, hogyan igazolod, hogy tényleg a Google jár nálad, és hogyan adsz neki kivételt úgy, hogy a hamis „Googlebotok” közben kint maradjanak.

A szövegben jelöljük, mi számít hivatalosan igazolt információnak (a Google vagy az eszköz gyártójának dokumentációja), mi saját tapasztalat, és mi szakmai feltételezés.

Miért blokkolhatja egy biztonsági eszköz a Googlebotot?

Röviden: mert a legtöbb védelem viselkedés alapján dönt, és a keresőrobot viselkedése sok ponton hasonlít egy támadóéhoz. Ha a szabály nem különbözteti meg az igazolt robotot, a Googlebot is fennakadhat.

A leggyakoribb okok, amelyekkel a gyakorlatban találkozunk (saját tapasztalat):

• Rate limit: a bővítmény vagy a szerver percenként csak meghatározott számú kérést enged egy IP-címről, a Googlebot ezt nagyobb oldalon könnyen túllépi.
• 404-figyelés: egyes bővítmények kitiltják azt az IP-t, amely sok nem létező oldalt kér le. A Googlebot régi, törölt URL-eket is újra meglátogat, így ez a szabály rá is lecsaphat.
• Ország- vagy hálózatszintű tiltás: ha valaki az amerikai IP-címeket vagy az adatközponti hálózatokat tiltja, a Google robotjai is a tiltott körbe kerülhetnek.
• JavaScript- vagy CAPTCHA-kihívás: a „támadás alatt” típusú módok egy ellenőrző oldalt mutatnak, amit egy robot nem feltétlenül tud teljesíteni.
• Hibás „hamis Googlebot” szűrés: ha a bővítmény DNS-alapú ellenőrzése nem kap választ a szerver névfeloldójától, a valódi robotot is hamisnak minősítheti (szakmai feltételezés, amit a naplóval tudsz igazolni vagy cáfolni).

Milyen tünetek jelzik a Search Console-ban, hogy a robot falba ütközik?

Röviden: a Feltérképezési statisztikák jelentésben megugrik a 403-as, 429-es vagy 5xx-es válaszok aránya, csökken a napi feltérképezési kérések száma, az Oldalindexelés jelentésben pedig „Hozzáférés megtagadva (403)” vagy szerverhiba típusú okok jelennek meg.

Hol érdemes nézni:

1. Beállítások, Feltérképezési statisztikák. Itt látod a napi kérésszámot, az átlagos válaszidőt és a válaszok bontását állapotkód szerint. A „Gazdagép állapota” blokkban a robots.txt lekérése, a DNS-feloldás és a szerverkapcsolat hibái külön jelennek meg.
2. Oldalindexelés jelentés. A nem indexelt oldalak okai között a „Hozzáférés megtagadva (403)”, a „Szerverhiba (5xx)” és az „Egyéb 4xx probléma miatt letiltva” a tűzfalra utaló jel lehet.
3. URL-ellenőrzés, élő teszt. Ha az élő teszt hibát ad, miközben a böngésződben az oldal rendben betölt, ez erős jel, hogy a szerver a Google kérését másképp kezeli, mint a tiédet.

Hivatalosan igazolt: a Google dokumentációja szerint a 429, 500 és 503 kódokra a Googlebot lassítja a feltérképezést, és ha ezek tartósan fennállnak, az érintett URL-ek kikerülhetnek az indexből. A 4xx kódok (a 429 kivételével) azt jelzik, hogy a tartalom nem érhető el, ezért a Google nem használja fel indexeléshez, a már indexelt oldalt pedig idővel eltávolíthatja. A Google kifejezetten azt kéri, hogy a feltérképezés lassítására ne 403-at vagy 404-et használj.

Saját tapasztalat: a tűzfal okozta hiba ritkán teljes kiesés. Sokkal gyakoribb, hogy a kérések egy része hibára fut, a válaszidő megnő, és a Google fokozatosan kevesebbet kér. Ez a grafikonon lassú lejtőként látszik, ezért könnyű elsiklani felette.

Mit mutat a szervernapló, ha a tűzfal a Googlebotot fogja meg?

Röviden: a Googlebot user-agentű kérések mellett 403-as, 429-es vagy 503-as állapotkódok jelennek meg, gyakran sorozatban, egy adott időpont után. Ha a kérések a naplóban egyáltalán nem szerepelnek, a tiltás a webszerver előtt (CDN-en vagy hálózati tűzfalon) történik.

Egy szabványos (combined) formátumú Apache- vagy Nginx-naplóban a kilencedik mező az állapotkód. Az alábbi parancs megmutatja, milyen válaszokat kapott a magát Googlebotnak mondó forgalom:

grep -i 'googlebot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Ha a kimenetben a 200 mellett jelentős számú 403 vagy 429 áll, nézd meg azokat a sorokat is, ahol ezek először jelentek meg:

grep -i 'googlebot' access.log | awk '$9==403 || $9==429' | head -20

Ezután vesd össze a dátumot a bővítmény vagy a tárhely naplójával. A legtöbb biztonsági bővítménynek van saját blokkolási listája vagy élő forgalom nézete, ahol a tiltott IP és a tiltás oka is szerepel. Ha ugyanaz az IP-cím mindkét helyen felbukkan, megvan a bűnös szabály.

Fontos, hogy a naplóban szereplő user-agent önmagában semmit nem bizonyít. Bárki küldhet „Googlebot” feliratú kérést, és a gyakorlatban rengeteg hamis robot él ezzel (saját tapasztalat). Mielőtt bármit átállítasz, igazolni kell, hogy a blokkolt IP valóban a Google-é.

Hogyan igazolod hitelesen, hogy tényleg a Googlebot jár nálad?

Röviden: a kérő IP-címre fordított DNS-lekérdezést futtatsz, a kapott gépnévnek googlebot.com, google.com vagy googleusercontent.com végződésűnek kell lennie, majd erre a gépnévre előre irányuló lekérdezéssel ellenőrzöd, hogy ugyanarra az IP-re mutat-e.

Hivatalosan igazolt: ezt a kétlépéses módszert a Google Search Central írja le. Alternatívaként a Google JSON-fájlokban közzéteszi a robotjai IP-tartományait (külön a Googlebotra, a speciális robotokra és a felhasználó által indított lekérésekre), és az IP-t ezekkel is összevetheted.

Így néz ki a gyakorlatban egy terminálban:

1. host 66.249.66.1 → a válaszban egy crawl-66-249-66-1.googlebot.com jellegű név jelenik meg.
2. host crawl-66-249-66-1.googlebot.com → a válasznak vissza kell adnia a 66.249.66.1 címet.

Ha az első lépés nem Google-domént ad vissza, vagy a második lépés másik IP-t, a kérés hamis. A második lépést nem szabad kihagyni, mert a fordított DNS-rekordot az IP-tartomány tulajdonosa állítja be, így egy támadó saját IP-jéhez is beírhat googlebot.com végződésű nevet. Az előre irányuló lekérdezés viszont a Google névszerveréből jön, azt nem tudja meghamisítani.

Nagyobb mennyiségnél a kézi ellenőrzés helyett érdemesebb a közzétett IP-listákat letölteni és rendszeresen frissíteni, mert a DNS-lekérdezés minden kérésnél lassíthatja a szervert (szakmai feltételezés, ami erősen függ a gyorsítótárazástól).

Hogyan adj biztonságosan kivételt a Googlebotnak?

Röviden: a kivétel az igazolt robotra vonatkozzon, ne a user-agent szövegére, és csak azt a szabályt kerülje meg, amely a robotot zavarja. A bejelentkezési oldal védelme, a fájlfeltöltési szűrők és a sebezhetőségi szabályok maradjanak érvényben.

Három biztonságos megközelítés létezik, erősorrendben:

1. Beépített „igazolt Google-robot” beállítás. Több bővítmény és CDN maga végzi el a DNS-alapú ellenőrzést. Ha ilyen van, ez a legegyszerűbb, mert nem neked kell karbantartani.
2. IP-alapú kivétel a hivatalos listából. A Google közzétett tartományait engedélyezett listára teszed, és ütemezetten frissíted. Ez szerverszintű tűzfalnál működik jól.
3. Lazább rate limit a teljes oldalon. Ha egyik sem megoldható, a korlátot olyan szintre emeled, amely egy ember számára még gyanús, a robotnak viszont elég. Ez a leggyengébb megoldás, mert a támadóknak is több mozgásteret ad.

Amit kerülj: a „ha a user-agent Googlebot, engedd át” típusú szabályt. Ezzel egy nyitott ajtót hagysz bárkinek, aki átírja a böngészője azonosítóját. Ha a CDN-ed támogatja, egy Cloudflare-szabályban az igazolt robot jelzésére épülő kifejezés biztonságosabb, például (cf.client.bot), amelyre csak a ráta- vagy bot-szabályokat kihagyó műveletet állítasz be. A mező pontos neve változhat, ezért a beállítás előtt nézd meg a Cloudflare aktuális dokumentációját.

Ha a feltérképezés terhelése valódi gondot okoz a szervernek, a tiltás helyett a Google által ajánlott út az ideiglenes 503-as vagy 429-es válasz, rövid időre (hivatalosan igazolt). Tartósan ez sem jó megoldás, mert az URL-ek kieshetnek az indexből.

Mit nézz meg a gyakori WordPress-biztonsági bővítményekben?

Röviden: minden bővítményben három területet kell átnézni, a rate limitet, a 404-alapú kitiltást és a hamis robotok szűrését, valamint a blokkolási naplót, hogy volt-e már igazolt Google IP a tiltottak között.

Wordfence

• A Rate Limiting beállításoknál van egy külön opció arra, hogyan kezelje a Google robotjait. Az igazolt Google-robotokra vonatkozó, korlátozást kikapcsoló beállítás a biztonságosabb választás (hivatalosan igazolt a Wordfence dokumentációja alapján).
• Az „Immediately block fake Google crawlers” opció hasznos, de csak akkor, ha a szerver DNS-feloldása megbízható.
• A Live Traffic nézetben szűrj Google-forgalomra, és nézd meg, volt-e blokkolt kérés.
• Ellenőrizd az ország szerinti tiltást, ha be van kapcsolva.

Solid Security (korábban iThemes Security)

• A 404-figyelés kitiltási küszöbe legyen elég magas, és nézd át a zárolási naplót, szerepel-e benne Google IP.
• A tiltott user-agentek listájában ne legyen általános minta, például „bot” vagy „crawler”.
• Az IP-kitiltásoknál ne legyenek teljes adatközponti tartományok.

All In One WP Security

• A tűzfalbeállításokban található „hamis Googlebotok blokkolása” opció DNS-alapú, ez jól működhet, de a bekapcsolása után nézd meg a naplót.
• Az erősebb (6G típusú) .htaccess-szabályok egyes lekérdezési paramétereket tilthatnak, ami paraméteres URL-eknél a robotot is érintheti (saját tapasztalat).

Minden bővítménynél

• Két biztonsági bővítmény egyszerre gyakran ütközik és duplán szűr, ezért egyet használj.
• A robots.txt és a sitemap.xml soha ne legyen kihívás vagy tiltás mögött.
• Bármilyen módosítás után futtass élő tesztet az URL-ellenőrzőben.

Mit nézz meg a tárhelyes tűzfalban és a CDN-ben?

Röviden: a szerverszintű védelem (ModSecurity, Imunify360, CSF, Fail2ban) és a CDN bot-kezelése a WordPress előtt dönt, ezért ha a naplóban nincs nyoma a blokkolt kérésnek, ezeknél keresd a hibát.

• ModSecurity: a tárhely naplójában keresd a Google IP-khez tartozó szabályazonosítókat. Egyetlen túl szigorú szabályt célzottan ki lehet kapcsolni egy útvonalra, nem kell az egészet leállítani.
• Imunify360 vagy hasonló WAF: nézd meg, van-e keresőrobot-kivétel, és hogy a szürkelistára került IP-k között szerepel-e Google-cím.
• CSF vagy Fail2ban kapcsolatlimit: az egy IP-ről engedett párhuzamos kapcsolatok száma nagyobb oldalon kevés lehet. Ehhez általában a tárhelyszolgáltató segítsége kell.
• Cloudflare vagy más CDN: a bot-elleni módokban legyen engedélyezve az igazolt robotok átengedése, a rate limit szabályok pedig zárják ki őket. A „támadás alatt” módot csak rövid időre kapcsold be, és utána ellenőrizd a Feltérképezési statisztikákat (szakmai feltételezés, hogy tartósan használva visszafoghatja a feltérképezést).
• Földrajzi tiltás: a Googlebot jellemzően amerikai IP-címekről érkezik, ezért egy országszintű tiltás könnyen kizárja (hivatalosan igazolt, hogy a Googlebot elsősorban USA-beli címekről dolgozik).

Mit tegyél a kivétel beállítása után?

Röviden: ellenőrizd élő teszttel, kövesd a naplót és a Feltérképezési statisztikákat legalább két-három hétig, és kérj újraellenőrzést a fontos oldalakra. A helyreállás üteme nem garantált.

1. Futtass élő tesztet az URL-ellenőrzőben néhány korábban hibás oldalra.
2. A naplóban futtasd újra az állapotkód-összesítést, és nézd meg, eltűntek-e a 403-as és 429-es válaszok.
3. Az Oldalindexelés jelentésben indítsd el a javítás ellenőrzését az érintett hibatípusra.
4. Kövesd a napi kérésszám alakulását. Hivatalosan igazolt: a Googlebot a hibák megszűnése után fokozatosan emeli vissza a feltérképezést, így a görbe lassan áll helyre.
5. Tegyél be egy havi ellenőrző pontot. Bővítményfrissítés vagy tárhelyes szabálycsere után a hiba visszatérhet (saját tapasztalat).

A védelem és a láthatóság nem zárja ki egymást. A cél egy olyan beállítás, amely az igazolt Google-robotot átengedi, mindenki mást pedig ugyanúgy szűr, mint eddig.

Források és további olvasnivalók

• Google Search Central: A Googlebot és más Google-robotok ellenőrzése
• Google Search Central: A HTTP-állapotkódok, a hálózati és a DNS-hibák hatása a Google Keresésre
• Google Search Central: A Googlebot feltérképezési sebességének csökkentése
• Search Console súgó: Feltérképezési statisztikák jelentés
• Search Console súgó: Oldalindexelés jelentés és URL-ellenőrző eszköz
• Cloudflare dokumentáció: Verified Bots
• Wordfence dokumentáció: Rate Limiting beállítások
• IETF RFC 6585: További HTTP-állapotkódok (429 Too Many Requests)