Ha megnyitod egy átlagos weboldal hozzáférési naplóját, jó eséllyel találsz benne GPTBot, ClaudeBot vagy PerplexityBot nevű kéréseket. Egy részük valóban az OpenAI, az Anthropic vagy a Perplexity gépeiről jön, egy másik részük csak a nevet kölcsönzi. Ez a cikk azt mutatja meg, hogyan választod szét a kettőt, és hogyan szűröd ki a hamisakat úgy, hogy a valódi botok zavartalanul dolgozhassanak.
Miért hivatkozik annyi forgalom AI-botokra, amelyek valójában nem ők?
A user agent egy szabadon kitölthető fejléc, amelyet a kérést küldő program maga állít be, és semmi nem ellenőrzi. Ezért egy árfigyelő scraper, egy sebezhetőség-kereső vagy egy tartalomlopó szkript minden akadály nélkül GPTBotnak nevezheti magát. Azért teszik, mert sok oldal külön engedélyt ad az ismert AI-botoknak a robots.txt-ben vagy a tűzfalban, és egy népszerű név mögött kevesebb szűrésbe ütköznek.
Saját tapasztalat. Amikor weboldalak naplóit nézzük át, rendszeresen találunk olyan kéréseket, amelyek ismert AI-bot nevével érkeznek, de lakossági internetszolgáltató, olcsó virtuális szerver vagy ismeretlen tárhely IP-címéről. A viselkedésük is árulkodó, gyakran a bejelentkezési oldalt, az admin felületet vagy a kosarat próbálgatják, amire egy tartalomgyűjtő botnak nincs szüksége.
A gond kettős. A hamis botok terhelik a szervert és torzítják a statisztikádat, ha pedig emiatt a nevük alapján tiltasz, a valódi botot is kizárod. A megoldás az, hogy a kérés forrását vizsgálod, és a névnek csak akkor hiszel, ha a forrás igazolja.
Hogyan igazolható, hogy egy bot tényleg az, akinek mondja magát?
Két megbízható módszer létezik, az oda-vissza fordított DNS-ellenőrzés és a szolgáltató által közzétett IP-tartományokkal való összevetés. Mindkettő ugyanarra kérdez rá más forrásból, vagyis arra, hogy a kérést küldő IP-cím ahhoz a céghez tartozik-e, amelynek a nevét a user agent hordozza.
Fordított DNS, két lépésben
Hivatalosan igazolt. A Google és a Microsoft (Bing) is ezt a módszert írja le a saját dokumentációjában. Az első lépésben az IP-címhez tartozó hosztnevet kérdezed le, és megnézed, a szolgáltató domainjére végződik-e. A második lépésben ezt a hosztnevet előre irányban feloldod, és ellenőrzöd, hogy ugyanarra az IP-címre mutat-e.
- A
host 66.249.66.1parancs eredménye példáulcrawl-66-249-66-1.googlebot.com. - A
host crawl-66-249-66-1.googlebot.comparancsnak vissza kell adnia a66.249.66.1címet.
A második lépés nem hagyható el. A fordított DNS-rekordot az állítja be, aki az IP-tartományt birtokolja, így egy csaló a saját szerverére is beírhat googlebot.com végű nevet. Csak az oda-vissza egyezés bizonyít. A Google esetében az elfogadott végződések a googlebot.com, a google.com és a googleusercontent.com, a Bingnél a search.msn.com, az Apple botjánál az applebot.apple.com.
Közzétett IP-tartományok
Hivatalosan igazolt. Több szolgáltató gépileg olvasható JSON-fájlban teszi közzé, milyen címtartományokból dolgoznak a botjai. A Google külön listát ad a Googlebotnak, a speciális feltérképezőknek és a felhasználó által indított lekérőknek. Az OpenAI a GPTBot, az OAI-SearchBot és a ChatGPT-User címeit külön fájlokban közli, a Perplexity szintén külön listát tart fenn a PerplexityBotnak és a Perplexity-Usernek. A Bing és az Apple is kiad ilyen listát.
Ez a módszer gyorsabb, mert nem kell minden kérésnél DNS-lekérdezést futtatni, elég megnézni, hogy a cím beleesik-e valamelyik tartományba. A hátránya, hogy a listák változnak, ezért rendszeresen frissítened kell őket.
Mikor melyiket használd?
- Naplóelemzéshez, utólagos vizsgálathoz mindkettő jó. Néhány száz egyedi címnél a fordított DNS is kényelmesen lefuttatható.
- Valós idejű szerver- vagy CDN-szabályhoz az IP-lista a jobb választás. A kérésenkénti DNS-lekérdezés lassít, és ha a DNS akadozik, valódi botot is elutasíthatsz.
- Ha a szolgáltató csak az egyiket támogatja, azt használd. Az OpenAI dokumentációja az IP-listákat adja meg ellenőrzési módként, a botjai felhőszolgáltatói címekről érkeznek, így náluk a fordított DNS nem ad használható választ.
Szakmai feltételezés. Az Anthropic és a kisebb AI-szolgáltatók botjainál az igazolás lehetősége az elmúlt időszakban többször változott. Mielőtt szabályt írsz, nézd meg a szolgáltató aktuális dokumentációját. Ha nincs közzétett lista vagy DNS-minta, ne tiltsd a bot nevét viselő kéréseket csak azért, mert nem tudod igazolni őket, ilyenkor a forgalomkorlátozás biztonságosabb.
Hivatalosan igazolt. Külön csapda a Google-Extended. Ez csak egy robots.txt-token, amellyel azt szabályozod, felhasználhatja-e a Google a tartalmadat a Gemini modellekhez. Saját user agentje nincs, a naplóban sosem fogod látni, ezért szerverszabályt sem érdemes írni rá.
Hogyan szűröd ki a hamis botokat a naplóból lépésről lépésre?
A naplóelemzéssel kezdd, mert így látod, mekkora a probléma és kik a valódi látogatók, mielőtt bármit tiltanál. A lenti parancsok a szokásos combined formátumú Nginx vagy Apache naplóra épülnek.
- Válogasd ki az AI-botnak mondott kéréseket.
grep -Ei 'gptbot|oai-searchbot|chatgpt-user|claudebot|claude-user|perplexity|googlebot|bingbot|applebot' access.log > botnevek.log - Számold össze az IP-cím és user agent párokat.
awk -F'"' '{split($1,a," "); print a[1], $6}' botnevek.log | sort | uniq -c | sort -rn > parok.txt. Így a legtöbb kérést küldő források kerülnek a lista tetejére. - Töltsd le a hivatalos IP-listákat. A Googlebotnál például
curl -s https://developers.google.com/static/search/apis/ipranges/googlebot.json | jq -r '.prefixes[] | .ipv4Prefix // .ipv6Prefix' > googlebot.txt. Az OpenAI és a Perplexity fájljai hasonló szerkezetűek, az elérhetőségüket a botjaikat bemutató dokumentációs oldalon találod. - Vesd össze a címeket a listákkal. Egy rövid Python-szkript elég hozzá, az
ipaddressmodulip_address(cim) in ip_network(tartomany)vizsgálatával. Minden párhoz írd oda, hogy igazolt-e a cím, és melyik szolgáltató listáján szerepel. - A listán kívüli, DNS-sel ellenőrizhető címeknél futtasd az oda-vissza lekérdezést. A Googlebotnál és a Bingbotnál ez plusz megerősítést ad, ha egy cím valamiért nincs benne a letöltött listában.
- Sorold három csoportba a forrásokat. Igazolt, egyértelműen hamis (ismert bot neve, de a cím semmilyen hivatalos forrással nem egyezik), valamint bizonytalan (olyan szolgáltató, amely nem ad igazolási módot).
- Nézd meg a hamisak kéréseit tartalom szerint. Ha a
wp-login.php, azxmlrpc.phpvagy a paraméteres kereső-URL-ek dominálnak, az megerősíti, hogy nem tartalomgyűjtésről van szó.
Saját tapasztalat. Legalább egy hét naplóját érdemes feldolgozni, mert a valódi botok ritmusa napról napra ingadozik, és egyetlen nap alapján könnyű rossz következtetést levonni.
Hogyan írj szűrőszabályt a szerveren vagy a CDN-en?
A szabály logikája minden környezetben ugyanaz. Ha a kérés ismert AI-bot nevét viseli, de a címe nincs benne az igazolt tartományokban, elutasítod, minden más kérés érintetlenül megy tovább.
Nginx szerveren
A geo modul a címlistát, a map modul a user agentet kezeli. Az igazolt tartományokat egy külön fájlba generálod, soronként egy tartománnyal és egy 1-es értékkel, például 203.0.113.0/24 1;.
geo $ai_igazolt { default 0; include /etc/nginx/ai-igazolt.conf; }map $http_user_agent $ai_nev { default 0; ~*(gptbot|oai-searchbot|chatgpt-user|perplexitybot|perplexity-user) 1; }map $ai_nev$ai_igazolt $hamis_ai { default 0; 10 1; }- A
serverblokkbanif ($hamis_ai) { return 403; }
Ez az egyszerű változat közös listát használ. Szigorúbb megoldás, ha szolgáltatónként külön geo változót veszel fel, így egy Perplexity-címről érkező GPTBot sem jut át. A /robots.txt útvonalat vedd ki a szabály alól, hogy egy tévesen besorolt valódi bot legalább a szabályaidat elolvashassa. A Googlebotot és a Bingbotot csak akkor vedd fel a mintába, ha a listájuk frissítése is automatikusan fut, mert egy elavult lista a keresési láthatóságodat is érintheti.
Cloudflare-en
Hivatalosan igazolt. A Cloudflare az ellenőrzött bot-listáján szereplő botokat a cf.client.bot mezővel jelöli. Egy egyéni WAF-szabály kifejezése így nézhet ki: (http.user_agent contains "GPTBot" or http.user_agent contains "PerplexityBot") and not cf.client.bot. Műveletnek kezdetben a Managed Challenge a kíméletesebb, a Block csak a tapasztalatok után jöjjön.
Mielőtt erre építesz, nézd meg a Cloudflare Radar bot-könyvtárában, hogy az adott bot tényleg szerepel-e az ellenőrzött listán. Ha nem, a szabály a valódi botot is megfogja. Ilyenkor biztonságosabb, ha a hivatalos tartományokat egy Cloudflare IP-listába töltöd, és a kifejezésben az ip.src in $ai_igazolt feltételre hivatkozol.
A listák automatikus frissítése
A közzétett tartományok változnak, ezért a listát naponta egyszer érdemes ütemezett feladattal újragenerálni. Három védőkorlát kell hozzá. A letöltött JSON-t ellenőrizd, mielőtt felhasználod (érvényes, nem üres, és a tartományok száma nagyjából a korábbi körül van). Hiba esetén a régi lista maradjon életben. Az Nginx újratöltése előtt fusson le az nginx -t, és csak sikeres teszt után jöjjön a nginx -s reload.
Mit ne blokkolj, nehogy valódi botot zárj ki?
A leggyakoribb hiba a túl széles tiltás. Ezeket a lépéseket kerüld, illetve ezekre figyelj külön:
- Ne tilts csak user agent alapján. Ha a GPTBot szót egyszerűen kitiltod, a valódit is kizárod, a hamis pedig másnap más nevet választ.
- Ne tilts teljes felhőszolgáltatói tartományt. Az Azure, az AWS és a Google Cloud címterét a valódi AI-botok is használják.
- Vedd fel a felhasználó által indított lekérőket is. A ChatGPT-User, a Claude-User, a Perplexity-User vagy a Google felhasználói lekérői akkor jönnek, amikor valaki egy AI-asszisztensben kifejezetten a te oldaladra kérdez rá. Ezek gyakran más listán szerepelnek, mint a feltérképező botok.
- Ne hagyd ki az IPv6-ot. Ha a listádban csak IPv4-tartományok vannak, az IPv6-on érkező valódi bot hamisnak tűnik.
- Ne engedd, hogy egy hibás frissítés kiürítse a listát. Üres lista mellett minden valódi bot hamisnak minősül.
- Ne tilts ott, ahol nincs igazolási mód. A bizonytalan csoportra forgalomkorlátozás való, például 429-es válasz egy kérésszám fölött.
- Hagyd elérhetőnek a robots.txt-t és az XML oldaltérképet. Ezek kiszolgálása olcsó, és egy tévesen besorolt valódi botnak is jelzi, mit engedsz.
Szakmai feltételezés. Az első napokban érdemes a szabályt csak naplózó módban futtatni (Nginxben például külön naplóba írva a $hamis_ai értékét), és a tiltást akkor bekapcsolni, ha a hamisnak jelölt kérések között egyetlen igazolható valódi bot sincs. Ez lassabb, de jó eséllyel megóv attól, hogy egy téves tartomány miatt kiess egy AI-kereső forrásai közül.
Mit nézz meg blokkolás után 48 órával?
Két nap alatt a legtöbb aktív bot legalább egyszer visszatér, így kiderül, hogy a szabály azt fogja-e meg, amit kell. Ez az ellenőrzőlista segít végigmenni rajta:
- A hamisnak jelölt IP-címek között van-e olyan, amely valamelyik friss hivatalos listán szerepel?
- A Googlebot, a Bingbot és az igazolt AI-botok kéréseire továbbra is 200-as, illetve szándékos 301-es vagy 304-es válasz megy-e?
- A Google Search Console feltérképezési statisztikáiban nőtt-e a 403-as válaszok aránya, vagy megjelent-e hosztelérhetőségi figyelmeztetés?
- A Bing Webmaster Tools feltérképezési hibái között van-e új tétel?
- A robots.txt lekérése minden valódi botnál sikeres volt-e?
- Lefutott-e a listafrissítő feladat, és a tartományok száma a várt nagyságrendben maradt-e?
- Csökkent-e a szerver terhelése és a sikertelen bejelentkezési kísérletek száma, vagyis tényleg a problémás forgalmat fogtad-e meg?
- Megjelent-e új, eddig nem látott user agent ugyanazokról a címekről? Ez arra utalhat, hogy a hamis forgalom nevet váltott.
- A CDN eseménynaplójában a szabály találatai néhány forrásra koncentrálódnak-e? A sok, szétszórt forrásból álló minta téves besorolásra is utalhat.
- Érkezett-e hibajelzés partnertől vagy integrációtól, amely véletlenül bot-nevet használ a user agentjében?
Saját tapasztalat. Az AI-keresőkből érkező hivatkozó forgalom változását 48 óra alatt nem érdemes megítélni. Ahhoz hetek kellenek, és sok más tényező is befolyásolja.
Mit nem old meg a hamis botok kiszűrése?
A szűrés csak a más nevében érkező forgalmat fogja meg. Az a scraper, amely hétköznapi böngészőnek álcázza magát, átjut rajta, arra forgalomkorlátozás, viselkedésalapú szűrés vagy a CDN botvédelme való. Arra sem érdemes számítani, hogy a tisztább napló önmagában javítja a megjelenésedet az AI-válaszokban. Annyit ad, hogy a döntéseidet valós adatra építed, és a szervered erőforrásai a valódi látogatókra és a valódi botokra jutnak.
Források és további olvasnivalók
- Google Search Central, Googlebot és más Google-feltérképezők ellenőrzése
- Google Search Central, a Google feltérképezőinek és lekérőinek áttekintése
- Bing Webmaster Tools súgó, a Bingbot ellenőrzése
- OpenAI dokumentáció, Overview of OpenAI Crawlers
- Anthropic súgóközpont, az Anthropic webes feltérképezőiről szóló cikk
- Perplexity dokumentáció, Perplexity Crawlers
- Apple támogatás, About Applebot
- Cloudflare dokumentáció, Verified bots és WAF custom rules
- Nginx dokumentáció, ngx_http_geo_module és ngx_http_map_module
- IETF RFC 9309, Robots Exclusion Protocol
- A user agent szabadon kitölthető szöveg, önmagában semmit nem bizonyít egy bot eredetéről.
- A fordított DNS-ellenőrzés csak oda-vissza irányban megbízható, a második, előre irányú lekérdezés nem hagyható ki.
- Valós idejű szerver- vagy CDN-szabályhoz a hivatalos IP-listák alkalmasabbak, utólagos naplóelemzéshez mindkét módszer jó.
- Ne tilts teljes felhőszolgáltatói tartományt, és vedd fel a listára a felhasználó által indított lekérőket és az IPv6-tartományokat is.
- Blokkolás után 48 órával nézd át a naplót, a Search Console feltérképezési statisztikáit és a listafrissítő feladat futását.
Gyakori kérdések
Elég a robots.txt-ben tiltani a hamis botokat?
Nem. A robots.txt egy kérés a jóhiszemű botok felé, a hamis botok jellemzően figyelmen kívül hagyják. A kiszűrésükhöz szerver- vagy CDN-szintű szabály kell, amely a kérés IP-címét vizsgálja.
Miért nem elég a fordított DNS első lépése?
Mert a fordított DNS-rekordot az IP-tartomány birtokosa állítja be, így egy csaló is beírhat googlebot.com végű nevet. Csak akkor igazolt a bot, ha a kapott hosztnév előre irányban feloldva ugyanarra az IP-címre mutat.
Hogyan igazolom a GPTBot valódiságát?
Az OpenAI a GPTBot, az OAI-SearchBot és a ChatGPT-User IP-tartományait külön JSON-fájlban teszi közzé. A kérés IP-címét ezekkel a tartományokkal kell összevetni, a listát pedig rendszeresen frissíteni.
Blokkolnom kell a Google-Extended user agentet?
Nem lehet és nem is kell. A Google-Extended csak robots.txt-token, saját user agent nélkül, ezért a naplóban nem jelenik meg. Azt szabályozza, felhasználhatja-e a Google a tartalmadat a Gemini modellekhez.
Mit tegyek, ha egy AI-szolgáltató nem ad igazolási módot?
Ilyenkor ne tilts végleg, mert a valódi botot is kizárhatod. A forgalomkorlátozás, például 429-es válasz egy kérésszám fölött, biztonságosabb, és közben érdemes figyelni a szolgáltató dokumentációjának változását.
Mennyi idő után látszik, hogy a szűrés jól működik?
A technikai hatás, vagyis hogy a valódi botok továbbra is 200-as választ kapnak-e, 48 óra alatt jó eséllyel kiderül. Az AI-keresőkből érkező forgalom alakulását viszont hetek alatt érdemes megítélni.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.