Honnan tudod, hogy tényleg AI-bot járt nálad, és nem valaki más adta ki magát annak

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

Ha megnyitod a szerver naplóját, és meglátod benne a GPTBot vagy a ClaudeBot nevét, a reakció általában kétféle: vagy örülsz, hogy az AI-motorok felfedezték az oldaladat, vagy megijedsz, hogy valaki elviszi a tartalmadat. A napló azonban egyik állítást sem támasztja alá önmagában. Az a sor csak annyit mond el, hogy valaki küldött egy kérést, és egy általa megválasztott szöveget írt bele a kérés fejlécébe. Ez az útmutató arról szól, hogyan tudod kiszűrni, mi ebből valódi, és mit érdemes kezdeni azzal, ami nem az.

Miért nem bizonyít semmit a user agent karakterlánc?

Rövid válasz: mert a user agent egy szabadon kitölthető HTTP-fejléc, nem azonosító. Bárki, aki egy parancssoros eszközt el tud indítani, három másodperc alatt kiadhatja magát bármelyik AI-botnak.

Hivatalosan igazolt: a HTTP-szabvány szerint a User-Agent fejléc a kliens önbevallása, semmilyen ellenőrzés nem tartozik hozzá. A Google saját dokumentációja is kifejezetten arra figyelmeztet, hogy a user agentet bárki hamisíthatja, ezért a Googlebot azonosításához mindig DNS-alapú ellenőrzést kell végezni.

A gyakorlatban ez így néz ki: egy curl hívásnál egyetlen kapcsolóval megadható, hogy a szerver mit lásson. Ugyanez igaz minden scraper-keretrendszerre. Ezért van az, hogy sok oldalon látszólag hatalmas AI-bot forgalom jelenik meg, közben viszont a kérések nagy része egyszerű tartalomgyűjtő szkript, ami csak azt reméli, hogy a bot neve miatt átengeded.

Saját tapasztalat: kisebb magyar oldalakon, ahol a napló eleve nem túl zajos, gyakran előfordul, hogy az AI-bot nevet használó kérések jelentős része nem igazolható. Ez nem általános törvényszerűség, csak annyit jelent, hogy érdemes tényleg megnézni, mielőtt bármilyen következtetést levonsz a saját oldaladról.

Mit jelent a fordított DNS-ellenőrzés, és mikor elég?

A fordított DNS-ellenőrzés azt jelenti, hogy a kérést küldő IP-címből visszakérdezel egy állomásnevet, majd abból a névből előre megint feloldod az IP-t. Csak akkor fogadod el a kérést valódinak, ha a kör bezárul, és a név a szolgáltató hivatalos tartományába tartozik.

Két lépésből áll, és egyik sem hagyható ki:

1. IP-ből név: host 66.249.66.1, a válaszban például egy googlebot.com végű névnek kell állnia.
2. Névből vissza IP: host crawl-66-249-66-1.googlebot.com, és az eredménynek pontosan az eredeti IP-t kell visszaadnia.

Ha csak az első lépést csinálod meg, becsapható vagy: a fordított DNS-bejegyzést az IP-tartomány tulajdonosa állítja be, tehát elvben bárki írhat oda félrevezető nevet a saját címéhez. A második, előre irányuló feloldás az, ami ezt kizárja, mert azt már a valódi tartomány gazdája felügyeli.

Hivatalosan igazolt: a Google a googlebot.com, google.com és googleusercontent.com végződéseket nevezi meg, a Microsoft a Bingbothoz a search.msn.com végződést. Ezeknél a kétirányú DNS-ellenőrzés önmagában elegendő.

Fontos korlát: nem minden AI-szolgáltató tart fenn ilyen fordított DNS-bejegyzéseket. Ahol nincs, ott nem a DNS, hanem a közzétett IP-lista a hiteles forrás.

Hogyan használd a közzétett IP-tartományokat?

A nagy szolgáltatók gépi olvasásra szánt JSON- vagy szövegfájlban teszik közzé, mely IP-tartományokból indulnak a crawlereik. Az ellenőrzés ilyenkor abból áll, hogy megnézed, a naplóban szereplő IP beleesik-e valamelyik közzétett tartományba.

Hivatalosan igazolt (a szolgáltatók saját dokumentációja alapján):

• A Google több listát is közread, külön a keresőbotokra, külön a felhasználói kérésre induló letöltőkre és külön az egyéb Google-forgalomra.
• A Microsoft közzéteszi a Bingbot tartományait, és böngészőből használható ellenőrző eszközt is ad.
• Az OpenAI külön listát ad a tartalomgyűjtő crawlerhez, a keresési célú botjához és a felhasználó kérésére induló lekéréshez, mert ezek más célt szolgálnak.
• Az Anthropic szintén közzéteszi a crawlereihez tartozó címtartományokat.
• A Perplexity is publikál IP-listát a saját botjához.

Két dolgot érdemes fejben tartani. Egyrészt ezek a listák változnak, tehát ha automatizálod az ellenőrzést, időnként frissítsd őket, ne másold be egyszer és felejtsd el. Másrészt vannak olyan robots.txt-ben használt nevek, amelyek nem crawlerek: a Google-Extended például egy vezérlő token, amivel a tartalom AI-tanításra való felhasználását szabályozhatod, nem pedig egy user agent, ami megjelenik a naplóban. Ha ilyen nevet keresel a logban, hiába keresed.

Hogyan csináld végig egy magyar tárhelyen, lépésről lépésre?

A legtöbb hazai tárhelyszolgáltatónál hozzáférsz a nyers naplóhoz, akár cPanelt, akár ispmanagert, akár Pleskt használsz. A menüpont neve általában Nyers hozzáférési naplók, Raw Access Logs vagy egyszerűen Naplók, és a fájl .gz tömörítéssel érkezik.

1. Töltsd le a naplót. Vezérlőpultból vagy FTP-n, a logs mappából. Ha van SSH-d, egyszerűbb helyben dolgozni.
2. Szűrd ki az AI-bot neveket: zcat access.log.*.gz | grep -Ei 'gptbot|oai-searchbot|chatgpt-user|claudebot|claude-user|perplexitybot|bingbot|googlebot' > ai.log
3. Nézd meg, mennyiről van szó: wc -l ai.log, majd awk '{print $1}' ai.log | sort | uniq -c | sort -rn | head -30. Ez kiírja, melyik IP hány kérést adott le. Itt derül ki, hogy tíz kérésről vagy tízezerről beszélünk.
4. Ellenőrizd a neveket: for ip in $(awk '{print $1}' ai.log | sort -u); do echo -n "$ip "; host $ip | awk '{print $NF}'; done. Ahol a válasz NXDOMAIN vagy nem a szolgáltató tartománya, ott gyanús a kérés.
5. Zárd be a kört a gyanús esetekre: a kapott nevet oldd fel előre (host <nev>), és nézd meg, visszakapod-e ugyanazt az IP-t.
6. Ahol nincs fordított DNS, ott az IP-t vesd össze a szolgáltató közzétett tartományaival. Egy kisebb listánál ez kézzel is megvan, nagyobb forgalomnál érdemes szkriptet írni rá.

Egy buktató, ami sok mérést elront: ha CDN vagy proxy van az oldal előtt, a napló első oszlopában a proxy IP-je állhat, nem a látogatóé. Ilyenkor az eredeti címet a továbbított fejlécből kell kiolvasnod, különben minden kérés ugyanarról a néhány IP-ről látszik érkezni, és az egész ellenőrzés értelmetlen lesz.

Miből derül ki, hogy valaki AI-botnak álcázva scrape-el?

Rövid válasz: abból, hogy a név nem igazolható, a viselkedés pedig nem illik egy komoly szolgáltató crawleréhez. A DNS és az IP-lista adja a bizonyítékot, a mintázat pedig a megerősítést.

Tipikus árulkodó jelek:

• A név ismert AI-boté, de sem a fordított DNS, sem a közzétett IP-tartomány nem igazolja.
• Az IP lakossági internetszolgáltatóhoz, VPN-hez vagy olcsó VPS-hálózathoz tartozik, nem a szolgáltató infrastruktúrájához.
• Nagyon rövid idő alatt sok kérés, szabályos időközökkel, emberi böngészésre jellemző szünetek nélkül.
• A robots.txt lekérése teljesen hiányzik. A hivatalos crawlerek jellemzően lekérik.
• Olyan oldalakat és paraméterezett URL-eket jár végig, amelyekre belső hivatkozás nincs, vagy szisztematikusan végigmegy egy terméklistán.
• Ugyanaz az IP váltogatja a user agentjét: hol AI-bot, hol asztali böngésző.

Hivatalosan igazolt: a Cloudflare 2025-ben nyilvánosan beszámolt olyan esetekről, amikor a közzétett tartományokon kívülről érkező forgalom ismert AI-bot nevét használta, illetve amikor a botok álcázott böngésző-azonosítóval tértek vissza. Az érintett szolgáltató ezt vitatta. Szakmai feltételezés: az ilyen álcázás inkább erősödni fog, mert az AI-tartalomgyűjtés üzletileg értékes, a tiltás pedig egyre gyakoribb. Ezért érdemes az ellenőrzést szokássá tenni, nem egyszeri akciónak.

Mikor tiltsd, és mikor csak korlátozd a forgalmat?

Használható döntési szabály: ami igazolható és nem terhel, azt hagyd békén; ami igazolható és terhel, azt korlátozd; ami nem igazolható, azt blokkold, de szűken.

• Igazolt bot, elhanyagolható terhelés: ne csinálj semmit. Ez a láthatóságod része. Ha nem akarod, hogy a tartalmad AI-tanításhoz kerüljön, azt a robots.txt-ben jelezd, ne tűzfalban.
• Igazolt bot, érezhető terhelés: korlátozás, ne tiltás. Kérés/másodperc limit az adott user agentre, vagy a nehéz, dinamikus végpontok (kereső, szűrők, kosár) kizárása. A tartalmat továbbra is elérheti, csak lassabban.
• Nem igazolható, AI-bot nevét használó forgalom: ez a tiltás valódi esete. Ilyenkor nem a nevet tiltod, hanem a konkrét IP-t vagy tartományt, mert a nevet a következő percben megváltoztatja.
• Nem igazolható és agresszív: tűzfal- vagy CDN-szintű blokk, lehetőleg hálózati tartományra, plusz emelt szintű naplózás, hogy lásd, visszatér-e más címről.

A sorrend nem véletlen. A saját nézőpontom ebben nagyon egyszerű: mérj, mielőtt tiltasz. A blokkolás azonnali, látható, jó érzés, és pontosan ezért nyúlnak hozzá sokan először. Csakhogy ha nem tudod megmondani, hány kérésről és mekkora erőforrásról beszélsz, azt sem tudod megmondani, hogy a tiltás segített-e.

Miért veszélyes a túl széles tiltás?

Mert a legkényelmesebb szabályok a legpontatlanabbak, és a valódi keresőbot ugyanazokba a mintázatokba esik bele, mint a scraper.

A klasszikus hiba a bot szórészletre szűrő szabály. Ez kizárja a Googlebot és a bingbot nevet is, vagyis egy mozdulattal leveszed magad a keresőkről. Hasonlóan kockázatos a teljes hálózati tartományok (ASN-ek) tiltása: a felhőszolgáltatók címtartományaiban legitim és nem kívánt forgalom egyaránt van, és a Google egyes felhasználói kérésre induló lekérései sem a klasszikus crawler-tartományból jönnek.

További csapdák: a HTTP 403 helyett használt 5xx válaszkód azt jelzi a keresőnek, hogy az oldalad hibás, nem azt, hogy nem engeded be. Az agresszív, minden gyanús kérésre kiugró ellenőrző oldal pedig az igazolt botokat is elkaphatja. Szakmai feltételezés: a legtöbb valódi kár nem a scrapingből származik, hanem az elkapkodott védekezésből, amit hetekig senki nem vesz észre.

Ezért minden tiltás után nézd meg a keresőkonzol lefedettségi és feltérképezési jelentését, és ellenőrizd, hogy az igazolt botok kérései változatlanul 200-as válaszokat kapnak. Ez nem garantál hibátlan beállítást, de a legdurvább melléfogásokat jó eséllyel elkapja.

Milyen ellenőrzőlistával zárd le a vizsgálatot?

• Megvan a nyers napló legalább hét napra, és tudod, hogy a napló IP-oszlopa a valódi forrást mutatja, nem a proxyt.
• Minden AI-bot nevet használó IP-hez lefutott a kétirányú DNS-ellenőrzés vagy az IP-listás összevetés.
• Külön listád van az igazolt és a nem igazolt forgalomról, kérésszámmal és forgalommal.
• Tudod, mely URL-eket célozták a leginkább, és ezek közül melyik drága a szervernek.
• A beavatkozás a döntési szabály szerint történt: korlátozás az igazoltra, tiltás a nem igazoltra.
• Egyetlen szabály sem szűr puszta szórészletre a user agentben.
• A beavatkozás után visszaellenőrizted, hogy a keresőbotok nem kaptak hibás választ.
• Naptárban van egy visszatérő időpont, amikor újra megnézed, mert az IP-listák és a botnevek változnak.

Ez a kör kis oldalnál nagyjából egy óra, és sokkal többet ér, mint egy találomra bemásolt tiltólista. A cél nem az, hogy senki ne érjen hozzá a tartalmadhoz, hanem hogy tudd, ki jár nálad, és ennek megfelelően dönts.

Források és további olvasnivalók

• Google Search Central: Verifying Googlebot and other Google crawlers, valamint a Google crawlers áttekintés és a közzétett IP-listák
• Bing Webmaster Tools dokumentáció: How to Verify Bingbot, és a Bingbot IP-lista
• OpenAI dokumentáció: GPTBot, OAI-SearchBot és ChatGPT-User leírás, a hozzájuk tartozó IP-tartományokkal
• Anthropic támogatási dokumentáció: a ClaudeBot és a hozzá tartozó crawler-IP-k
• Perplexity dokumentáció: PerplexityBot és a közzétett IP-tartományok
• Cloudflare blog és Cloudflare Radar: AI-crawler forgalom, hitelesített botok, álcázott crawlerekről szóló elemzések
• IETF RFC 9309: Robots Exclusion Protocol
• MDN Web Docs: User-Agent HTTP-fejléc
• Schema.org és W3C: strukturált adat és webes szabványok