Új AI-crawlerek figyelése és a robots.txt rendszeres karbantartása

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

A robots.txt-t a legtöbb weboldalon egyszer beállítják, aztán évekig senki nem nyúl hozzá. Klasszikus keresőmotoroknál ez sokáig elég is volt, mert a Googlebot és a Bingbot neve ritkán változik. Az AI-crawlereknél más a helyzet. Új bot jelenik meg, egy meglévő kettéválik képzési és keresési feladatra, egy régi user-agent nevet pedig az üzemeltető csendben visszavon. A kiindulópontunk ezért egyszerű. A robots.txt élő dokumentum, amelynek felelőse van, és minden AI-szabályának van dátuma és oka.

Miért évül el egy fél éve beállított robots.txt?

Azért, mert a szabályok user-agent nevekre hivatkoznak, és ezek a nevek az AI-cégeknél gyakrabban változnak, mint amilyen gyakran a fájlt átnézik. Ha egy új botnak nincs saját csoportja, a User-agent: * csoport vonatkozik rá, ami sok oldalon mindent enged.

Hivatalosan igazolt. A robots.txt működését az IETF RFC 9309 szabványa írja le. Eszerint a crawler azt a csoportot követi, amelyik a legpontosabban illeszkedik a saját nevére, és ha ilyen nincs, a csillagos csoportot. Az Anthropic korábban az anthropic-ai és a Claude-Web neveket használta, a mostani leírása viszont a ClaudeBot, a Claude-User és a Claude-SearchBot neveket sorolja fel. Az OpenAI három külön botot ír le (GPTBot, OAI-SearchBot, ChatGPT-User), eltérő céllal. A Google-nél a Google-Extended egy token, amellyel azt szabályozhatod, hogy a tartalmad bekerülhet-e a Google AI-modelljeihez. A feltérképezést ettől függetlenül a Googlebot végzi, külön crawler nincs mögötte.

Saját tapasztalat. Az átnézett oldalakon gyakran találunk olyan robots.txt-t, amely még csak a régi, visszavont neveket tiltja. A tulajdonos úgy tudja, hogy kizárta az AI-képzést, közben az új nevű bot szabadon jár. A fordítottja is előfordul. Valaki egy hír hatására minden AI-botot tilt, és ezzel azokat is kizárja, amelyek az AI-keresők válaszaiban hivatkozott forrásként látogatót hozhatnának.

Honnan veszed észre, hogy új AI-crawler jelent meg?

Három forrásból, és mindhárom kell. A szervernaplóból látod, ki jár nálad ténylegesen. Az üzemeltetők dokumentációjából látod, milyen néven és milyen céllal jelentkeznek. A harmadik a saját robots.txt-d előzménye, ebből derül ki, mire van már szabályod.

A napló a legmegbízhatóbb jelzés, mert nem a bejelentésekre vár. Egy Apache vagy Nginx combined formátumú access logból egyetlen paranccsal kigyűjtheted a leggyakoribb user-agenteket.

awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -40

Ezt érdemes leszűrni azokra, amelyek botnak tűnnek, és dátummal elmenteni, hogy a következő hónapban legyen mihez hasonlítani.

awk -F'"' '{print $6}' access.log | grep -iE 'bot|crawl|spider|agent|fetch' | sort | uniq -c | sort -rn > botok_2026-10.txt

Amit a listán nem ismersz, azt jelöld meg. Nézd meg, melyik IP-tartományból jön, milyen URL-eket kér, és lekéri-e egyáltalán a robots.txt-t. Tárhelyes WordPress-oldalnál, ahol nincs közvetlen naplóhozzáférés, a tárhelypanel statisztikája vagy egy CDN (például Cloudflare) botjelentése adhat hasonló képet, kevésbé részletesen.

Hogyan ismered fel az átnevezett user-agentet?

Átnevezésre utal, ha egy régi név kérésszáma hónapról hónapra csökken, miközben ugyanabból az IP-tartományból egy új név jelenik meg hasonló mintázattal. Ilyenkor ne töröld azonnal a régi sort. Írd mellé, hogy a dokumentáció már nem említi, és ha a következő negyedéves átnézésnél a naplóban sem látszik, vedd ki.

Szakmai feltételezés. Egy új AI-bot jó eséllyel előbb jelenik meg a naplóban, mint a te figyelmedben, mert az üzemeltetők leírása sokszor csak később frissül, vagy a változást külön be sem jelentik.

Hogyan néz ki a havi rutin lépésről lépésre?

Havonta egy rövid, rögzített lépésekből álló kör elég, amelynek a végén vagy nincs teendő, vagy van egy dokumentált módosítás.

1. Naplókivonat. Futtasd le a fenti parancsot az előző hónap naplójára, és mentsd el dátummal.
2. Összevetés. Hasonlítsd össze az előző havi listával. Az új nevek és a hirtelen megugrott kérésszámok kerülnek a vizsgálandók közé.
3. Azonosítás. Minden ismeretlen botnál keresd meg az üzemeltető hivatalos oldalát. Ha a user-agent szövegében van URL, onnan indulj. Ha nincs hivatalos leírás, kezeld óvatosan.
4. Ellenőrzés. Vesd össze az IP-címet a közzétett tartományokkal, vagy végezz fordított DNS-ellenőrzést, ha az üzemeltető ezt a módszert írja le.
5. Döntés. Döntsd el, kell-e új szabály. Engedni, tiltani vagy csak egyes útvonalakat korlátozni is lehet.
6. Rögzítés. Ha módosítasz, írd be a változásnaplóba a dátumot, az okot és a felelőst, és frissítsd a fájl fejlécében az átnézés dátumát.

Saját tapasztalat. A legtöbb hónapban nincs teendő. A rutin értéke abban van, hogy amikor mégis jön valami új, legfeljebb egy hónapig fut szabály nélkül.

Mit érdemes negyedévente átnézni?

Negyedévente a dokumentációkat és a saját döntéseidet nézd át, mert ezek lassabban változnak, de nagyobb a hatásuk.

• Az OpenAI, az Anthropic, a Google, az Apple, a Perplexity, a Meta és a Common Crawl crawler-leírásait. Figyeld, van-e új név, visszavont név vagy megváltozott cél.
• A közzétett IP-tartományok listáit. Az OpenAI és a Google is gépi úton olvasható JSON-fájlban teszi közzé a botjai címtartományait.
• Az üzleti döntésedet. Akarsz-e még megjelenni AI-keresők válaszaiban, és ehhez melyik botot kell engedned?
• A fájl méretét és olvashatóságát. A Google dokumentációja szerint az 500 KiB fölötti részt figyelmen kívül hagyja.
• A Disallow szabályokat, amelyek régi, már nem létező útvonalakra mutatnak.

Hivatalosan igazolt. A Google a robots.txt-t általában legfeljebb 24 óráig tárolja gyorsítótárban, így a módosítás nem azonnal hat. Más crawlereknél ez eltérhet, ezt az adott üzemeltető leírásában találod.

Hogyan néz ki egy jól kommentezett AI-szakasz a robots.txt-ben?

Úgy, hogy egy külső ember is megérti belőle, ki, mikor és miért döntött. A # jellel kezdődő sorokat a crawlerek figyelmen kívül hagyják, ezért a megjegyzés semmilyen szabályt nem ront el. Az alábbi példa egy lehetséges döntést mutat, és nem ajánlás minden oldalra.

# ==== AI-crawlerek ==== # Felelős: [név], marketing # Utolsó átnézés: 2026-10-30 # Következő átnézés: 2026-11-30 # Elv: AI-keresők idézhetnek, modellképzésre nem adjuk a tartalmat. # OpenAI, ChatGPT keresési találatok. Engedve 2026-03-12, ok: AI-keresős megjelenés. User-agent: OAI-SearchBot Disallow: /wp-admin/ # OpenAI, modellképzés. Tiltva 2026-03-12, ok: tulajdonosi döntés. User-agent: GPTBot Disallow: / # Anthropic, modellképzés. Tiltva 2026-03-12. # A régi anthropic-ai és Claude-Web sor 2026-10-30-án törölve, # ok: a dokumentáció már nem említi, a naplóban sem látszik. User-agent: ClaudeBot Disallow: / # Anthropic, keresési index. Engedve 2026-10-30, ok: új név a naplóban. User-agent: Claude-SearchBot Disallow: /wp-admin/ # Google AI-modellek. Csak token, a Googlebot olvassa. Tiltva 2026-03-12. User-agent: Google-Extended Disallow: / # Common Crawl, nyilvános adatkészlet. Tiltva 2026-03-12. User-agent: CCBot Disallow: / # Minden más bot, az admin felület kivételével engedve. User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php

Hivatalosan igazolt. Az RFC 9309 szerint az a bot, amelynek saját csoportja van, a csillagos csoport szabályait nem örökli. Ezért szerepel a példában az engedett AI-botoknál is külön a /wp-admin/ tiltása. Ha ezt kihagyod, az engedett bot az admin útvonalat is feltérképezheti.

Hogyan verziózd a robots.txt-t és rögzítsd a módosítás okát?

A legegyszerűbb, ha a fájl verziókezelőben (például Gitben) él, és minden módosításhoz rövid, beszédes üzenet tartozik. Ha nincs fejlesztői környezet, egy közös táblázat is megteszi, amelyben a dátum, a régi és az új sor, az ok, a forrás és a felelős neve szerepel. Egy jó változásnapló-bejegyzés körülbelül így néz ki.

2026-10-30 | [név] | anthropic-ai és Claude-Web törölve, Claude-SearchBot felvéve | ok: az Anthropic leírása a régi neveket már nem sorolja fel | forrás: Anthropic crawler-leírás, megnyitva 2026-10-30

WordPressnél külön figyelj arra, hogy a robots.txt fizikai fájl vagy virtuális. Ha nincs fájl a gyökérkönyvtárban, a WordPress vagy egy SEO-bővítmény generálja, és egy bővítményfrissítés átírhatja. A havi körben ezért nézd meg az élő /robots.txt címet is, és vesd össze a jóváhagyott példánnyal.

curl -s https://pelda.hu/robots.txt | diff - robots_jovahagyott.txt

Ha a parancs eltérést mutat, előbb derítsd ki, honnan jött, és csak utána állítsd vissza. Lehet, hogy egy kolléga jó okkal módosított, csak nem írta be a naplóba.

Saját tapasztalat. A legtöbb „rejtélyes” robots.txt-változás mögött egy bővítmény, egy tárhelyköltözés vagy egy CDN-szabály áll, és ritkábban tudatos emberi döntés. A verziózott példány nélkül ezt nagyon nehéz visszakövetni.

Mi a teendő, ha egy bot nem tartja be a szabályt?

Előbb ellenőrizd, hogy tényleg az a bot-e, aminek mondja magát, és tényleg vonatkozik-e rá a szabály. Szerveroldali tiltáshoz csak ezután nyúlj.

Hivatalosan igazolt. Az RFC 9309 kimondja, hogy a robots.txt nem hozzáférés-védelmi eszköz, a betartása a crawleren múlik. A user-agent szöveget ráadásul bárki hamisíthatja. Egyes üzemeltetők leírása szerint a felhasználó által indított lekérésekre (például ChatGPT-User vagy Perplexity-User) a robots.txt nem feltétlenül ugyanúgy vonatkozik, mint az automatikus feltérképezésre. Ezt mindig az aktuális dokumentációban nézd meg, mert ez is változhat.

1. Időzítés. Nézd meg, eltelt-e a módosítás óta annyi idő, amennyi a gyorsítótár frissüléséhez kell.
2. Azonosítás. Vesd össze az IP-címet a hivatalos tartományokkal. Ha nem egyezik, hamisított user-agentről van szó, és az eredeti üzemeltetőnek ehhez nincs köze.
3. Szintaxis. Ellenőrizd, hogy a csoport neve pontos, a fájl UTF-8 kódolású, a gyökérben érhető el, és a szabály tényleg arra az útvonalra vonatkozik.
4. Jelzés. Valódi, szabályt sértő botnál írj az üzemeltető hivatalosan megadott címére, és csatold a naplórészletet időponttal, IP-vel és URL-lel.
5. Szerveroldali tiltás. Ha a jelzés nem hoz változást, tilts user-agentre és IP-tartományra a webszerveren, a tűzfalon vagy a CDN-ben. Ez már valódi hozzáférés-korlátozás, ezért a hatását a következő havi naplóban mérd vissza.

Nginx alatt egy egyszerű user-agent alapú tiltás így néz ki.

if ($http_user_agent ~* "PeldaBot") { return 403; }

Szakmai feltételezés. A szerveroldali tiltást érdemes a legutolsó lépésnek tartani, mert egy rosszul megírt minta valódi látogatókat vagy hasznos botokat is kizárhat. Ha a gond főleg a terhelés, a lassítás (rate limit) gyakran kisebb kockázattal jár a teljes tiltásnál. A változásnaplóba a szerveroldali szabály is kerüljön be, különben a következő átnézésnél senki nem fogja tudni, miért kap egy bot 403-as választ.

Milyen ellenőrzőlistával dolgozz?

• A fájl fejlécében ott a felelős neve, az utolsó és a következő átnézés dátuma.
• Minden AI-bot csoportja fölött ott a bot célja, a döntés dátuma és az oka.
• A visszavont user-agent neveket megjelölted vagy törölted, és ezt naplóztad.
• A havi naplókivonat el van mentve, és összevetetted az előző hónappal.
• Az élő robots.txt megegyezik a jóváhagyott, verziózott példánnyal.
• A saját csoporttal bíró botokra az admin és egyéb tiltásokat külön is megírtad.
• A szabálysértő botot IP alapján azonosítottad, mielőtt szerveren tiltottad.
• Negyedévente átnézted az üzemeltetői dokumentációkat és a saját üzleti döntésedet.

Források és további olvasnivalók

• IETF RFC 9309, Robots Exclusion Protocol
• Google Search Central, a robots.txt bevezetője és specifikációja
• Google Search Central, a Google crawlerek és fetcherek áttekintése (Google-Extended)
• OpenAI, Overview of OpenAI Crawlers
• Anthropic Help Center, az Anthropic crawlereinek leírása
• Apple Support, About Applebot
• Perplexity, Perplexity Crawlers dokumentáció
• Common Crawl, CCBot leírás