A tipikus bejelentés így hangzik: az oldal reggel még gyors volt, délutánra viszont 6-8 másodperc alatt tölt be, a tárhelyszolgáltató pedig azt írja, hogy túllépted a processzoridő-keretet. Az első gyanúsított az utóbbi időben szinte mindig valamelyik AI-crawler. Néha jogosan, sokkal gyakrabban viszont azért, mert a bot forgalma csak láthatóvá tette azt a szerkezeti hibát, ami addig is ott volt az oldalon.
Ebben a cikkben végigveszem, hogyan ismered fel a tüneteket, hogyan igazolod vissza őket adatból, és milyen sorrendben érdemes beavatkozni, hogy ne lőj túl a célon. Saját tapasztalat: a hozzám kerülő terhelési panaszok többségében nem a bot volt az igazi probléma, hanem egy kezeletlen URL-szerkezet, amit bármelyik intenzívebb crawler pillanatok alatt kinyit.
Milyen tünetekből ismerhető fel, hogy AI-crawlerek terhelik a szervert?
Rövid válasz: ha a kérésszám megugrik, miközben a valós látogatószám nem mozdul, és a plusz kérések néhány ismétlődő user agenttől érkeznek, jellemzően szűrős vagy paraméteres URL-ekre, akkor jó eséllyel crawlerforgalomról van szó.
Tovább a témában: robots.txt és az AI-botok kezelése · WordPress gyorsítótár-bővítmény választása
A gyakorlatban ezek a jelek szoktak együtt megjelenni:
- A tárhely statisztikájában a havi kérésszám megduplázódik vagy megháromszorozódik, a Google Analytics viszont ugyanazt a látogatószámot mutatja. Ez már önmagában elárulja, hogy a plusz forgalom nem emberi, mert a szokásos mérőkód JavaScriptet futtat, a legtöbb crawler pedig nem.
- A lassulás nem egyenletes, hanem hullámokban jön: néhány órán át magas a terhelés, aztán csendesebb időszak jön. A crawlerek jellemzően szakaszosan dolgoznak.
- A logban ugyanaz a user agent tűnik fel több ezerszer. A leggyakoribbak a
GPTBot, azOAI-SearchBot, aChatGPT-User, aClaudeBot, aPerplexityBot, aBytespider, aAmazonbotés aCCBot. - A leggyakrabban lekért URL-ek listáján nem a szokásos aloldalak vannak elöl, hanem szűrőkombinációk:
?szin=kek&meret=42&rendezes=ar_novekvotípusú címek, naptárnézetek, oldalszámozott listák vagy keresési találati oldalak. - Az adatbázis lassul be először, nem a fájlkiszolgálás. Ez azért árulkodó, mert a paraméteres listaoldalak szinte mindig egyedi adatbázis-lekérdezést futtatnak, tehát cache-ből nem kiszolgálhatók.
Szakmai feltételezés: a felismerést nehezíti, hogy nem minden bot vallja be magát. Vannak forgalmi minták, amelyek crawlerre hasonlítanak, de általános user agentet küldenek. Ilyenkor a viselkedés árulkodik: emberi látogató nem kér le 400 oldalt 90 másodperc alatt, és nem hagyja ki minden esetben a képeket, a CSS-t és a JavaScriptet.
Hogyan igazolod vissza szerverlogból vagy tárhely-statisztikából?
Rövid válasz: az access log user agent és URL szerinti csoportosítása néhány perc alatt megmutatja, ki mennyi kérést generált és mire. Enélkül minden beavatkozás találgatás.
Ha van SSH-hozzáférésed, a nyers log a leggyorsabb út. Egy tipikus Apache- vagy Nginx-logban a user agent az utolsó mező, így a leggyakoribb kliensek így jönnek ki:
awk -F'\"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -20
Egyetlen bot kérésszáma pedig egyszerűen:
grep -c GPTBot access.log
Ez viszont még csak a mennyiség. A lényeg az, hogy mit kérnek le. Erre való a következő lépés, ami a bot által látogatott URL-eket rangsorolja:
grep GPTBot access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30
Ha ennek a listának a tetején paraméteres URL-ek állnak, megvan a valódi ok. Saját tapasztalat: egy webshopnál nem ritka, hogy 40-60 termékből több tízezer bejárható URL-cím keletkezik a szűrők kombinálódása miatt, és a bot ezt becsületesen végigjárja. Nem a crawler agresszív, hanem az oldal kínál fel értelmetlen mennyiségű címet.
Ha nincs SSH, akkor is van mit nézni. A cPanel vagy Plesk felületén az AWStats, a Webalizer és a nyers naplók letöltése általában elérhető. Ott keresd a látogatók és a kérések számának arányát, a legtöbbet kért oldalak listáját, valamint a robotok szerinti bontást. A Google Search Console Feltérképezési statisztika jelentése ugyanezt megmutatja, de csak a Google saját botjaira, tehát az AI-crawlerek nagy részét nem látod benne. Ha van Cloudflare a domain előtt, a forgalmi elemzésben külön szűrhetők a verifikált botok.
Miért az URL-szerkezet a valódi ok a legtöbb esetben?
Rövid válasz: mert egy rosszul kezelt paraméterrendszer néhány száz valódi oldalból tízezres nagyságrendű bejárható címet gyárt, és ezek egyike sem szolgálható ki cache-ből.
Ez az én szakmai álláspontom, és következetesen ezt látom vissza a logokban. Nézd meg, mi történik egy átlagos webshopban: van hat szűrőd, mindegyikhez négy-öt érték, plusz háromféle rendezés és oldalszámozás. A kombinációk száma exponenciálisan nő. Ha ezek mind linkelt, követhető, indexelhető címek, akkor a botnak nincs oka megállni. A WordPress-alapú oldalakon ugyanez a naptárnézetekkel, a címkearchívumokkal és a belső keresés találati oldalaival történik meg.
A különbség a hagyományos keresőmotorokhoz képest az, hogy most egyszerre több szereplő jár be. Hivatalosan igazolt: az OpenAI, az Anthropic és a Perplexity is dokumentálja a saját crawlereit, publikálja a user agent neveket és az IP-tartományokat, és mindegyik a robots.txt betartását ígéri. Vagyis ezek nem rejtőzködő botok, hanem szabályozható forgalom. Ha viszont a robots.txt mindent enged, akkor mindegyik ugyanazt a felduzzasztott URL-halmazt fogja bejárni, egymástól függetlenül.
Milyen sorrendben avatkozz be?
Rövid válasz: a legkevésbé kockázatos és legkisebb hatókörű eszközzel kezdd, és csak akkor lépj tovább, ha a mérés szerint nem volt elég. A blokkolás mindig az utolsó lehetőség, mert a láthatóságot is elvágja.
1. lépés: kísérlet a crawl-delay lassítással
A robots.txt-be tett Crawl-delay arra kéri a botot, hogy a kérések között várjon a megadott másodpercig. Hivatalosan igazolt: ezt a direktívát a Google nem támogatja, és a Robots Exclusion Protocol szabványa (RFC 9309) sem tartalmazza. A Bing viszont figyelembe veszi, és több AI-crawler is értelmezi. Emiatt ez inkább kísérlet, mint megoldás, de olcsó és gyorsan visszavonható.
User-agent: GPTBot
Crawl-delay: 10
Egy hét után nézd meg a logot: csökkent-e az adott bot óránkénti kérésszáma. Ha nem, lépj tovább.
2. lépés: a paraméteres URL-ek kizárása
Ez az a lépés, ami a tapasztalatom szerint a legtöbb esetben egyedül is megoldja a problémát. A cél nem az, hogy kizárd a botot, hanem hogy elvedd tőle azt a több tízezer értelmetlen címet, amit amúgy sem szeretnél a keresőkben és a válaszmotorokban látni.
User-agent: *
Disallow: /*?szures=
Disallow: /*?rendezes=
Disallow: /kereses/
Fontos, hogy a kanonikus címkék (rel=canonical) ezt kiegészítik, de nem helyettesítik: a kanonikus címke akkor is lekérésbe kerül, ha a végén nem indexelődik. A terhelést a lekérés okozza, nem az indexelés. Ha viszont a robots.txt tiltja, a kérés el sem indul, ez a különbség.
3. lépés: cache- és CDN-réteg
Ha a lekért oldalak nagy része statikusan kiszolgálható, akkor a bot forgalma szinte ingyenessé válik. Egy teljes oldal-cache (WordPress alatt például a szerveroldali page cache) a PHP-t és az adatbázist teljesen kihagyja a kiszolgálásból. Egy CDN ezen még tovább lép: a kérés el sem éri a szervert.
Ez a lépés azért is jó befektetés, mert a valódi látogatóknak is gyorsabb lesz az oldal, tehát akkor sem veszett kárba, ha kiderül, hogy a botok csak a terhelés kisebb részéért felelősek. Saját tapasztalat: egy jól beállított cache-réteg után a korábban riasztónak tűnő botforgalom sokszor észrevétlenné válik, mert a szűk keresztmetszet nem a kérésszám volt, hanem az adatbázis.
4. lépés: célzott sebességkorlátozás
Ha az előző három lépés után is marad probléma, jöhet a rate limit. Nginx alatt ez így néz ki:
limit_req_zone $binary_remote_addr zone=aibot:10m rate=1r/s;
Apache alatt a mod_ratelimit vagy egy user agent alapú szabály használható a .htaccess fájlban. A legfontosabb technikai részlet: a túlterhelt szerver ne 403-as vagy 500-as hibával válaszoljon, hanem 429 vagy 503 státusszal, lehetőleg Retry-After fejléccel. Hivatalosan igazolt: a Google Search Central dokumentációja szerint a crawler ezekre a válaszokra ideiglenesen lassít, míg a tartós hibakódokat a tartalom eltűnéseként is értelmezheti. Ugyanez a logika a többi jól viselkedő botnál is működik.
Mit mérj a beavatkozás előtt és után?
Rövid válasz: ugyanazt, ugyanolyan hosszú időszakon, ugyanabból a forrásból. Beavatkozás előtt legalább 7, ideális esetben 14 nap adatát rögzítsd, hogy a heti ingadozás ne torzítson.
Ellenőrzőlista, amit érdemes leírni egy táblázatba:
- Napi összes kérésszám (szerverlog).
- Napi kérésszám botonként, a három-négy legaktívabb user agentre külön.
- A tíz leggyakrabban lekért URL és azok kérésszáma.
- Átlagos válaszidő és a leglassabb 5 százalék válaszideje.
- CPU- és memóriahasználat csúcsértéke, valamint az adatbázis-lekérdezések száma.
- Az 5xx és 429 válaszok aránya az összes kéréshez képest.
- Valós látogatószám és organikus forgalom (hogy lásd, nem esett-e vissza).
- Az AI-eszközökből érkező hivatkozó forgalom a GA4-ben (ez mutatja meg, hogy a szigorítás nem vágta-e el a láthatóságot).
A beavatkozás után 7 és 30 nappal mérd újra ugyanezeket. Ha a botok kérésszáma csökkent, a válaszidő javult, és a látogatószám nem mozdult lefelé, akkor a lépés jó irányba vitt. Ha a kérésszám csökkent, de az organikus forgalom is, akkor túllőttél a célon, és lazítanod kell. Szakmai feltételezés: az AI-válaszokban való megjelenés visszaesése lassabban jelentkezik, mint a klasszikus organikus forgalomé, ezért érdemes a 30 napos mérést sem kihagyni.
Mikor olcsóbb bővíteni a tárhelyet, mint botokat üldözni?
Rövid válasz: akkor, ha a szerver az egyébként kívánatos forgalomtól esik el, és a bot csak a kapacitáshiányt tette láthatóvá. Ez gyakoribb helyzet, mint gondolnád.
Nézd meg őszintén az arányokat. Ha a botok az összes kérés 15-20 százalékát adják, és nélkülük is 80 százalékon áll a processzorterhelés, akkor a botok kizárása nem old meg semmit, csak elodázza a problémát a következő kampányig. Ha az oldalad több éve ugyanazon a belépő szintű csomagon fut, közben viszont megháromszorozódott a tartalom és a látogatószám, akkor a csomag a szűk keresztmetszet.
Az idő is költség. Egy alapos logelemzés, a szabályok kialakítása, a tesztelés és a két mérési kör összesen több munkaóra. Ha ennél kevesebbe kerül egy nagyobb csomag vagy egy CDN-előfizetés egy évre, akkor a bővítés a racionális döntés, és utána is ráérsz rendbe tenni az URL-szerkezetet, csak már nem tűzoltásként.
Fordítva viszont nem működik: ha a paraméteres URL-ek tízezreit hagyod bejárhatóan, akkor a nagyobb csomag is elfogy, csak később. A kapacitásbővítés időt vesz, nem okot szüntet meg.
Milyen hibákat érdemes elkerülni?
Rövid válasz: a teljes és válogatás nélküli botkizárást, a rossz hibakódot és a mérés nélküli beavatkozást.
- Mindent tiltó robots.txt. Ha az összes AI-crawlert kizárod, a szervered megnyugszik, de a márkád eltűnik azokból a válaszokból, ahol a versenytársaid megjelennek. Ez üzleti döntés, ne technikai reflexből szülessen.
- 403-as blokkolás 429 helyett. A tartós tiltás azt üzeni, hogy a tartalom nem elérhető, nem azt, hogy most éppen sok a kérés.
- IP-cím alapú tiltás user agent ellenőrzés nélkül. A nagy szolgáltatók IP-tartományai változnak, a publikált listákat kellene követni, különben előbb-utóbb valós forgalmat is levágsz.
- Egyszerre több beavatkozás. Ha egyszerre kapcsolsz be cache-t, írsz robots.txt-t és állítasz rate limitet, sosem fogod tudni, melyik hatott.
- A mérés elhagyása. A beavatkozás előtti alapérték nélkül nincs bizonyíték, csak vélemény arról, hogy javult-e valami.
A józan sorrend tehát: előbb értsd meg, mit kérnek le és miért annyit, utána vedd el a felesleges címeket, gyorsíts cache-sel, és csak a végén korlátozz. A bot ritkán ellenség, sokkal inkább egy szigorú tesztelő, aki megtalálja az oldalad gyenge pontját.
Források és további olvasnivalók
- Google Search Central: Robots.txt specifikáció és a Crawl-delay kezelése
- Google Search Central: Feltérképezési statisztika jelentés és a HTTP állapotkódok kezelése
- RFC 9309: Robots Exclusion Protocol (IETF)
- OpenAI dokumentáció: GPTBot, OAI-SearchBot és ChatGPT-User crawlerek
- Anthropic dokumentáció: ClaudeBot és a webes hozzáférés szabályozása
- Perplexity dokumentáció: PerplexityBot és felhasználói ügynökök
- Cloudflare dokumentáció: AI Crawl Control és botkezelés
- MDN Web Docs: HTTP 429 Too Many Requests és Retry-After fejléc
- Nginx dokumentáció: ngx_http_limit_req_module
- A gyanút mindig szerverlog vagy tárhely-statisztika igazolja vissza, nem az érzés, hogy lassú az oldal.
- A tünet jellemzően megugró kérésszám változatlan valós látogatószám mellett, ismétlődő user agentekkel, szűrős és paraméteres URL-eken.
- A beavatkozás sorrendje számít: robots.txt és paraméter-kizárás, utána cache és CDN, és csak végül sebességkorlátozás.
- Mérj ugyanazokat a mutatókat a beavatkozás előtt és után, különben nem tudod bizonyítani a hatást.
- Sok esetben olcsóbb és gyorsabb a tárhelycsomag bővítése vagy a cache bekapcsolása, mint hetekig botokat üldözni.
Gyakori kérdések
Honnan tudom biztosan, hogy nem valódi látogatók terhelik a szervert?
Hasonlítsd össze a szerverlog kérésszámát a Google Analytics látogatószámával ugyanarra az időszakra. A mérőkód JavaScriptet futtat, a legtöbb crawler pedig nem, ezért ha a kérésszám megugrik, de az analitika ugyanazt mutatja, a különbözet szinte biztosan gépi forgalom.
Tényleg betartják az AI-botok a robots.txt-t?
A nagy szolgáltatók (OpenAI, Anthropic, Perplexity) hivatalosan vállalják a robots.txt betartását, és publikálják a user agent neveket. Ez nem jelent garanciát minden botra: kisebb vagy magukat álcázó crawlerek nem feltétlenül követik. Ezért van értelme a rate limitnek mint utolsó lépésnek.
Ha kizárom az AI-crawlereket, elveszítem a láthatóságomat a válaszmotorokban?
Jó eséllyel igen, legalábbis részben. A tartalombejáró botok tiltása azt jelenti, hogy az adott rendszer nem tud friss információt szerezni az oldaladról. Ezért érdemes először a felesleges paraméteres URL-eket kizárni, és csak a fő tartalmat hagyni bejárhatóan.
Mennyi idő alatt látszik a beavatkozás hatása?
A szerverterhelés jellemzően napokon belül reagál, a bejárási minta viszont lassabban áll át, mert a botok ütemezése eltérő. Reális az, hogy 7 nap után látod a trendet, és 30 nap után tudsz megalapozott következtetést levonni.
A cache önmagában elég lehet?
Sok esetben igen, ha az oldal nagy része statikusan kiszolgálható. A paraméteres listaoldalak viszont jellemzően nem cache-elhetők jól, mert minden kombináció egyedi. Ilyenkor a cache mellé a paraméterek kezelése is kell.
Milyen hibakóddal válaszoljon a szerver, ha korlátozni akarom a botot?
429 (Too Many Requests) vagy 503 (Service Unavailable) állapotkóddal, lehetőleg Retry-After fejléccel. Ezeket a crawlerek ideiglenes állapotként értelmezik és lassítanak. A 403 vagy a 404 tartós hiányt jelez, ami hosszabb távon a tartalom kiesését okozhatja.
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.