Egy átlagos magyar vállalkozói weboldal szervernaplójában ma háromféle AI-forgalom keveredik. Az egyik modelltanításhoz gyűjt szöveget, a másik egy AI-kereső saját indexét tölti fel, a harmadik pedig akkor jelenik meg, amikor valaki éppen kérdez valamit a ChatGPT-től, a Perplexitytől vagy a Claude-tól, és az asszisztens a te oldaladat nyitja meg, hogy válaszolni tudjon. Ez a harmadik csoport a legkisebb volumenű, mégis ez áll a legközelebb egy valódi látogatóhoz, hiszen mögötte egy konkrét ember konkrét kérdése van. Ebben a cikkben szétválasztjuk a három típust, és végigmegyünk rajta, hogyan kezeld őket a robots.txt-ben, a tűzfalban és a naplóelemzésben.
A szövegben jelöljük, mi a forrása egy-egy állításnak. Hivatalosan igazolt az, ami a szolgáltatók saját dokumentációjában szerepel (a cikk írásakor, ezek a leírások gyakran változnak). Saját tapasztalat az, amit weboldalak naplóinak és tűzfalbeállításainak átnézésekor rendszeresen látunk. Szakmai feltételezés az, amire logikus következtetés utal, de nyilvános bizonyíték nincs.
Miben különbözik a tanító crawler, a keresőbot és az élő lekérés?
A tanító crawler előre és tömegesen gyűjt tartalmat modellfejlesztéshez, a keresőbot egy AI-kereső indexét építi, az élő lekérés pedig egyetlen felhasználói kérdésre, valós időben nyit meg néhány konkrét oldalt. A három más célú, más ütemű, és a nagy szolgáltatók külön user agenttel jelölik őket.
Tanító crawlerek
Ide tartozik az OpenAI GPTBot, az Anthropic ClaudeBot és a Common Crawl CCBot. A Google-nél a Google-Extended nem külön bot, csak egy robots.txt-token, amellyel szabályozhatod, hogy a Googlebot által begyűjtött tartalmat felhasználhatják-e a Gemini-modellekhez. A Google keresőbeli megjelenésedre ez a dokumentáció szerint nincs hatással. Hasonló logikájú token az Applebot-Extended.
Keresőindexet építő botok
Az OAI-SearchBot a ChatGPT keresőfunkciójához, a Claude-SearchBot a Claude kereséséhez, a PerplexityBot a Perplexity indexéhez gyűjt. Ezek jó eséllyel abban játszanak szerepet, hogy az oldalad egyáltalán bekerül-e az adott AI-kereső forráskészletébe.
Élő, felhasználó által indított lekérések
A ChatGPT-User, a Claude-User és a Perplexity-User akkor érkezik, amikor egy felhasználó kérdése miatt az asszisztens megnyit egy oldalt, vagy a felhasználó maga ad meg egy URL-t. A Google is külön csoportban tartja nyilván a felhasználó által indított lekérőit (például a NotebookLM vagy a felolvasó funkció lekérőit). Ezek jellemzően egy-két oldalt kérnek le, rövid idő alatt, és nem rendszeres bejárást végeznek.
Hivatalosan igazolt. Az OpenAI, az Anthropic és a Perplexity is külön user agentet és külön leírást ad a tanító, a kereső és a felhasználó által indított forgalomhoz, így a három csoport egymástól függetlenül szabályozható.
Miért nem elég az élő lekéréseket a robots.txt-ben kezelni?
Mert a robots.txt önkéntes megállapodás, és az élő lekéréseknél több szolgáltató kifejezetten jelzi, hogy a felhasználó nevében érkező kérésre nem feltétlenül alkalmazza. Ráadásul a robots.txt semmit nem szabályoz a sebességről, és a hamisított kéréseket sem állítja meg.
Hivatalosan igazolt. Az OpenAI dokumentációja szerint a ChatGPT-User műveleteit a felhasználó indítja, ezért a robots.txt szabályai nem feltétlenül érvényesülnek rájuk. A Perplexity hasonlóan fogalmaz, a Perplexity-User általában figyelmen kívül hagyja a robots.txt-t, mivel a lekérést a felhasználó kérte. Az Anthropic leírása ezzel szemben azt mondja, hogy a Claude-User letiltása a robots.txt-ben megakadályozza, hogy a rendszer felhasználói kérdésre lekérje a tartalmadat. A Google a felhasználó által indított lekérőire szintén azt írja, hogy általában nem veszik figyelembe a robots.txt-t. Ugyanaz a Disallow sor tehát az egyik asszisztensnél működik, a másiknál nem.
Van még két gyakorlati korlát. A robots.txt-t csak a tisztességes bot olvassa el, a ChatGPT-User nevet felvevő hamisítvány nem törődik vele. A robots.txt-ben ezenfelül nincs megbízható eszköz a terhelés szabályozására, a Crawl-delay utasítást a nagy szolgáltatók többsége nem veszi figyelembe.
A robots.txt ettől még hasznos, csak a szándékodat rögzíti, a végrehajtást nem. Egy tipikus, csoportokra bontott beállítás így nézhet ki, ha a tanítást tiltanád, a keresést és az élő lekérést engednéd:
User-agent: GPTBot/Disallow: /User-agent: ClaudeBot/Disallow: /User-agent: OAI-SearchBot/Allow: /User-agent: Claude-SearchBot/Allow: /User-agent: ChatGPT-User/Allow: //Disallow: /fiokom/User-agent: Claude-User/Allow: //Disallow: /fiokom/
A /fiokom/ típusú, bejelentkezéshez kötött területet viszont ne a robots.txt-re bízd. Ami valóban nem nyilvános, azt hitelesítés védje.
Mi történik, ha a tűzfal vagy a bot-védelem kiszűri az élő lekéréseket?
Az asszisztens a felhasználó kérdésére nem tudja elolvasni az oldaladat, ezért más forrásból válaszol, korábbi tudására támaszkodik, vagy jelzi, hogy az oldal nem érhető el. Egyik esetben sem a te aktuális tartalmad kerül a válaszba.
Saját tapasztalat. A blokkolás ritkán tudatos döntés. Leggyakrabban ezek a beállítások okozzák:
- CDN-szintű bot-védelem vagy egy általános „AI-botok blokkolása” kapcsoló, amelyről a tulajdonos nem is tud, mert egy korábbi beállításkor kapcsolták be.
- JavaScript-alapú kihívó oldal. Az élő lekérést végző rendszer jellemzően nem futtat JavaScriptet, így a „böngésző ellenőrzése” oldalon akad el.
- WordPress biztonsági bővítmény sebességkorlátja, amely egy rövid ideig tartó sorozatos lekérést támadásnak vesz.
- Országalapú szűrés. Az élő lekérések jellemzően külföldi adatközponti IP-címekről érkeznek, egy „csak magyar IP” szabály ezeket is kizárja.
- Tárhelyszintű szabályok, amelyek a user agentben szereplő „bot” szóra szűrnek.
A kihívó oldal különösen alattomos, mert gyakran 200-as státuszkóddal tér vissza. A naplóban sikeresnek látszik, közben az asszisztens egy ellenőrző szöveget kapott a tartalmad helyett. Érdemes ezért a válasz méretét is megnézni, egy termékoldalnál gyanús az 5-10 kilobájtos válasz, ha a valódi oldal több száz kilobájt.
Szakmai feltételezés. Ha egy oldal tartósan elérhetetlen az élő lekérések számára, az ronthatja az esélyét, hogy az adott AI-szolgáltatás később forrásként használja. Erre nincs nyilvános, szolgáltatói megerősítés, de a működési logikából következik, hogy egy rendszer a sikeresen elolvasható forrásokat részesíti előnyben.
Hogyan különböztetheted meg a naplóban a valódi lekérést a hamisítványtól?
A user agent önmagában semmit nem bizonyít, bárki beírhatja. A valódiságot az IP-cím igazolja, vagyis hogy a kérés a szolgáltató által közzétett IP-tartományból jött-e, illetve ahol elérhető, a kérés kriptográfiai aláírása.
Egy valódi élő lekérés naplósora nagyjából így néz ki (az IP itt dokumentációs célú példacím):
203.0.113.7 - - [14/Oct/2026:10:12:44 +0200] "GET /szolgaltatasok/ HTTP/1.1" 200 48211 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot"
Az ellenőrzés lépései:
- Szűrd ki a sorokat user agent alapján.
grep -E 'ChatGPT-User|Perplexity-User|Claude-User' access.log > elo.log - Gyűjtsd ki az IP-címeket gyakoriság szerint.
awk '{print $1}' elo.log | sort | uniq -c | sort -rn - Töltsd le a hivatalos IP-listát. Az OpenAI és a Perplexity botonként külön JSON-fájlban teszi közzé a tartományait, a Google is ad JSON-listát a felhasználó által indított lekérőihez. Az Anthropicnál a dokumentáció aktuális ellenőrzési módját kövesd.
- Vesd össze a kettőt. Egy rövid Python-szkript elég hozzá (a mezőnevek szolgáltatónként eltérhetnek, nézd meg a letöltött fájlt).
- Nézd meg a viselkedést is. A valódi élő lekérés kevés, egymáshoz tartalmilag kapcsolódó URL-t kér rövid idő alatt. A hamisítvány gyakran
wp-login.php,xmlrpc.phpvagy.envcímeket próbálgat, és több száz oldalt kér egy IP-ről.
Az összevető szkript váza:
import ipaddress, jsonlista = json.load(open('chatgpt-user.json'))halok = [ipaddress.ip_network(p.get('ipv4Prefix') or p.get('ipv6Prefix')) for p in lista['prefixes']]def valodi(ip): return any(ipaddress.ip_address(ip) in h for h in halok)for sor in open('elo.log'): ip = sor.split()[0]; print(ip, 'OK' if valodi(ip) else 'GYANUS')
Hivatalosan igazolt. Az OpenAI a ChatGPT agent módban végzett böngészést HTTP Message Signatures alapú aláírással is jelöli, amelyet egyes CDN-szolgáltatók automatikusan ellenőrizni tudnak. Ahol ez elérhető, megbízhatóbb az IP-listánál, mert nem kell frissítened.
Saját tapasztalat. A ChatGPT-User nevet viselő sorok jelentős része egyes oldalakon hamisítvány szokott lenni, főleg WordPress-oldalakon, ahol a támadó szkriptek azért veszik fel ezt a nevet, mert tudják, hogy sok tűzfal átengedi.
Melyik típust érdemes engedni, korlátozni vagy tiltani?
A legtöbb vállalkozásnak az igazolt élő lekéréseket és keresőbotokat érdemes engedni, a tanító crawlerekről üzleti döntés kell, a hamisítványokat pedig tiltani. Sebességkorlátot minden csoportra be lehet állítani, ha a szerver terhelése indokolja.
Döntési tábla
- Élő lekérés, igazolt IP-ről (ChatGPT-User, Claude-User, Perplexity-User). Javaslat: engedd. Mögötte egy felhasználó kérdése áll, a forgalom kicsi. Korlátozás csak szélsőséges terhelésnél.
- Keresőbot, igazolt IP-ről (OAI-SearchBot, Claude-SearchBot, PerplexityBot). Javaslat: engedd, mérsékelt sebességkorláttal, ha a tárhely gyenge. Ezek nélkül nehezebb bekerülni az AI-keresők forrásai közé.
- Tanító crawler (GPTBot, ClaudeBot, CCBot, Google-Extended token). Javaslat: üzleti döntés. Ha a tartalmad maga a termék, a tiltás védheti. Ha az ismertség a cél, az engedés inkább segíthet.
- Ismeretlen, AI-szerű user agent, dokumentáció nélkül. Javaslat: korlátozd és figyeld, amíg ki nem derül, kié.
- Ismert AI-név, de nem igazolt IP-ről. Javaslat: tiltsd. Ez hamisítvány, és jellemzően sérülékenységet keres.
- Bármelyik bot bejelentkezéshez kötött, kosár-, pénztár- vagy belső keresési oldalon. Javaslat: tiltsd vagy irányítsd el, és a védelmet hitelesítés adja, ne a robots.txt.
Hogyan állítsd be lépésről lépésre?
Először mérj, utána szabályozz, és minden változtatás után ellenőrizd a naplóban, hogy az élő lekérések 200-as kóddal és valódi tartalommal kapnak választ.
- Töltsd le az elmúlt 30 nap hozzáférési naplóját, és válogasd szét az AI-forgalmat a három csoportra.
- Minden csoportnál nézd meg a státuszkódokat. Ha az élő lekérésekre 403, 429 vagy 503 jön, keresd meg, melyik réteg adja (CDN, tárhely, bővítmény).
- Ellenőrizd a 200-as válaszok méretét, hogy kiszűrd a kihívó oldalakat.
- Vesd össze az IP-címeket a hivatalos listákkal, és a nem igazolt sorokat jelöld hamisítványnak.
- A CDN-ben vagy tűzfalban engedd az igazolt botokat (sok szolgáltatónál van „ellenőrzött botok” kategória), a hamisítványokat tiltsd.
- Írd meg a robots.txt-t csoportonként külön blokkal, a döntési tábla szerint.
- Állíts be ésszerű sebességkorlátot a keresőbotokra és a tanító crawlerekre, ha terhelést okoznak.
- Ütemezd havonta az IP-listák frissítését, mert a tartományok változnak.
- Kérdezz rá egy-két oldaladra a ChatGPT-ben vagy a Perplexityben, és nézd meg a naplóban, megjelenik-e a lekérés és milyen kóddal.
Mit tudunk biztosan, és mi az, amit csak feltételezünk?
A user agentek neve, szerepe és a robots.txt-hez való viszonyuk dokumentált, a láthatóságra gyakorolt hatásuk viszont nem. Ezt érdemes szem előtt tartani, mielőtt bármelyik csoportot tiltod.
- Hivatalosan igazolt. A három csoport külön user agenttel érkezik. Az OpenAI és a Perplexity jelzi, hogy az élő lekérésekre a robots.txt nem feltétlenül vonatkozik, az Anthropic szerint a Claude-User tiszteletben tartja. Az OpenAI és a Perplexity közzéteszi az IP-tartományait.
- Saját tapasztalat. Az élő lekérések blokkolása többnyire nem szándékos, hanem egy általános bot-védelmi beállítás mellékhatása. A hamisított AI-user agentek gyakoriak.
- Szakmai feltételezés. A tartósan sikertelen élő lekérés ronthatja az esélyt a későbbi forrásként való megjelenésre. A keresőbotok engedése segítheti a bekerülést az AI-válaszokba, de semmit nem garantál, mert a forrásválasztás sok más tényezőn is múlik.
Egy dolgot érdemes még tudni. A szolgáltatók gyakorlata nem mindig egyezik a dokumentációval, a Cloudflare például 2025-ben nyilvánosan kifogásolta, hogy a Perplexity nem deklarált user agentekkel is lekért oldalakat (a Perplexity ezt vitatta). Ezért a naplód a végső igazság, a dokumentáció csak kiindulópont.
Források és további olvasnivalók
- OpenAI dokumentáció, Overview of OpenAI Crawlers
- Anthropic Súgóközpont, az Anthropic botjairól és a robots.txt-ről szóló leírás
- Perplexity dokumentáció, Perplexity Crawlers
- Google Search Central, a Google crawlerek és felhasználó által indított lekérők áttekintése
- Google Search Central, a Googlebot ellenőrzése
- IETF RFC 9309, Robots Exclusion Protocol
- IETF RFC 9421, HTTP Message Signatures
- Cloudflare dokumentáció, Verified Bots és Web Bot Auth
- Az AI-forgalom három külön csoport: tanító crawler, keresőindexet építő bot és a felhasználó kérdésére indított élő lekérés.
- Az élő lekéréseknél a szolgáltatók eltérően kezelik a robots.txt-t, az OpenAI és a Perplexity jelzi, hogy ilyenkor nem feltétlenül alkalmazzák.
- A user agent hamisítható, a valódiságot a szolgáltató által közzétett IP-tartomány vagy kriptográfiai aláírás igazolja.
- Ha a bot-védelem kihívó oldalt vagy 403-at ad az élő lekérésre, az asszisztens a te aktuális tartalmad nélkül válaszol.
- Az igazolt élő lekéréseket és keresőbotokat érdemes engedni, a tanító crawlerekről üzleti döntés kell, a hamisítványokat tiltani.
Gyakori kérdések
Mi a különbség a GPTBot, az OAI-SearchBot és a ChatGPT-User között?
A GPTBot modelltanításhoz gyűjt tartalmat, az OAI-SearchBot a ChatGPT keresőfunkciójának indexét építi, a ChatGPT-User pedig akkor nyitja meg az oldaladat, amikor egy felhasználó kérdésére a ChatGPT valós időben forrást keres. A három külön user agent, ezért a robots.txt-ben és a tűzfalban is külön kezelhető.
Ha letiltom a ChatGPT-User-t a robots.txt-ben, biztosan nem jön többet?
Nem biztos. Az OpenAI dokumentációja szerint a felhasználó által indított műveleteknél a robots.txt szabályai nem feltétlenül érvényesülnek. Ha valóban el akarod zárni a tartalmat, azt szerveroldalon, hitelesítéssel vagy tűzfalszabállyal teheted meg.
Honnan tudom, hogy egy ChatGPT-User nevű kérés valódi?
Vesd össze a kérés IP-címét a szolgáltató által közzétett IP-tartomány-listával. Ha az IP nincs a listán, a kérés jó eséllyel hamisított, akármi szerepel a user agentben.
Árt a láthatóságnak, ha a Cloudflare kihívó oldalt mutat az AI-botoknak?
Árthat. Az élő lekérést végző asszisztens általában nem futtat JavaScriptet, így a kihívó oldalon akad el, és a te aktuális tartalmad nélkül válaszol. Hogy ez hosszabb távon mennyire befolyásolja a forrásként való megjelenést, arra nincs nyilvános adat.
Érdemes tiltani a tanító crawlereket?
Ez üzleti döntés. Ha a tartalmad maga a termék (fizetős tudás, egyedi adatbázis), a tiltás védheti. Ha a cél a láthatóság és az ismertség, a tiltás inkább hátrány lehet. A keresőbotok és az élő lekérések kezelése ettől független döntés.
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.