Szerveroldali naplóelemzés: mit csinálnak valójában a botok az oldaladon

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

Ha tudni akarod, mit csinál a Googlebot, a Bingbot vagy a GPTBot az oldaladon, a legpontosabb forrás nem az analitika és nem is a Search Console, hanem a webszerver saját naplófájlja, az access log. Saját nézőpont: ez az egyetlen olyan forgalmi adat, ami nem mintavételezett, nem függ JavaScripttől, és nem lehet cookie-bannerrel vagy reklámblokkolóval kikapcsolni. Ha egy kérés eljutott a szerverig, ott van a naplóban, másodpercre pontos időbélyeggel. Minden más mérőeszköz ehhez képest szűrt, összesített vagy hiányos.

Miért mutat mást a naplófájl, mint a Google Analytics?

Rövid válasz: mert a kettő nem ugyanazt méri. A GA4 és a hasonló mérőkódok JavaScriptet futtatnak a látogató böngészőjében, a napló viszont minden beérkező HTTP-kérést rögzít, akkor is, ha a kliens oldalon egy sor kód sem fut le.

Hivatalosan igazolt: a GA4-ben az ismert botok és pókok forgalmának kiszűrése alapértelmezetten aktív, és nem kapcsolható ki. Vagyis az analitikád szándékosan nem mutatja azt, amit itt keresel. A Search Console Feltérképezési statisztikák jelentése közelebb visz, mert valódi feltérképezési adat, de csak a Google saját botjairól szól, összesített formában, és nem árulja el URL-szinten, hogy melyik oldalt mikor kérték le. A Bing, az OpenAI vagy az Anthropic botjairól pedig végképp nem mond semmit.

Saját tapasztalat: kisebb magyar céges oldalakon és webshopokon nem ritka, hogy a szerverhez beérkező kérések fele vagy annál is több nem embertől jön. Ez önmagában nem baj, sőt egy részét kifejezetten akarod. A gond az, hogy amíg nem nézel bele a naplóba, csak tippelsz arról, mire megy el a szerver kapacitása és a feltérképezési keret. Egy naplóelemzés jellemzően fél óra alatt olyan dolgokat hoz felszínre, amikre hónapokig nem derül fény máshonnan.

Hol találod meg az access logot cPanelben, Pleskben, ispmanagerben és VPS-en?

Rövid válasz: minden komolyabb tárhelypanelen van nyers naplóletöltés, csak máshol hívják és máshol tárolják. A négy leggyakoribb eset:

• cPanel: a Metrics (Statisztikák) blokkban a Raw Access menüpont, innen tömörített naplót töltesz le domainenként. Fontos: kapcsold be az „Archive logs” opciót, különben a rendszer a havi statisztikafuttatás után eldobja a régi fájlokat. SSH-hozzáféréssel a naplók a ~/access-logs/ könyvtárban is ott vannak.
• Plesk: Websites & Domains, majd a domain alatt a Logs menüpont. A beépített Log Browser már szűrni is tud státuszkódra, a nyers fájlok pedig a fájlkezelőben a /var/www/vhosts/DOMAIN/logs/ útvonalon érhetők el (jellemzően access_ssl_log néven, ha HTTPS-en fut az oldal).
• ispmanager: a WWW-domainek listájából a domain kiválasztása után a Logs gomb. Fájlszinten a /var/www/USER/data/logs/DOMAIN.access.log a szokásos hely, a régebbi napok pedig .gz kiterjesztéssel, dátummal tömörítve.
• VPS vagy dedikált szerver: nginx esetén /var/log/nginx/access.log, Apache esetén /var/log/apache2/access.log (Debian, Ubuntu) vagy /var/log/httpd/access_log (RHEL, AlmaLinux). A rotált fájlok a logrotate beállításától függően .1, .2.gz utótaggal állnak mellette.

Két buktató, amin sokan elcsúsznak. Az egyik a megőrzési idő: a legtöbb tárhely csak néhány napnyi naplót tart meg, ezért az első teendő nem az elemzés, hanem az archiválás bekapcsolása vagy egy heti automatikus mentés beállítása. A másik a CDN. Ha az oldal proxy mögött fut (például Cloudflare), a saját naplódban a proxy IP-címei jelennek meg, nem a valódi kérőé. Ilyenkor a valós IP visszaállítása (Apache alatt a mod_remoteip, nginx alatt a realip modul) nélkül a későbbi DNS-ellenőrzés értelmetlen eredményt ad, és a bot-azonosítás is félrevisz.

Mit lehet kiolvasni egyetlen naplósorból?

A szokásos „combined” formátum egy sora így néz ki:

66.249.66.1 - - [18/Aug/2026:04:12:07 +0200] "GET /szolgaltatasok/ HTTP/1.1" 200 18342 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Balról jobbra: a kérő IP-címe, két ma már ritkán használt mező, az időbélyeg időzónával együtt, a kérés metódusa és útvonala, a HTTP-státuszkód (itt 200), a visszaadott bájtok száma, a hivatkozó (referer), végül a user agent. Ebből a hat érdemi mezőből az egész bot-viselkedés összerakható: ki, mikor, mit kért, és mit kapott rá válaszul.

Ami alapból hiányzik, az a válaszidő. Hivatalosan igazolt: Apache alatt a LogFormat sorba felvett %D a kiszolgálás idejét adja mikroszekundumban, nginx alatt ugyanezt a $request_time változó szolgáltatja, másodperc-tört pontossággal. Ha hozzáférsz a szerver konfigjához, ezt még az első komoly elemzés előtt érdemes bekapcsolni, mert enélkül csak találgatod, hogy a botok lassú válaszokat kapnak-e. A mező helye a formátumban tetszőleges, csak jegyezd fel, hányadik oszlop lett, mert a későbbi awk-parancsok oszlopszámra hivatkoznak.

Milyen szűréseket futtass először a naplón?

Rövid válasz: öt parancs elég a képhez, és mind lefut egy átlagos havi naplón pár másodperc alatt. Ha tömörített fájllal dolgozol, a grep helyett zgrep, a cat helyett zcat a megfelelő eszköz, kicsomagolni nem kell.

Melyik bot mennyit kér le?

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

Ez a user agent mezőt emeli ki és gyakoriság szerint rendezi. A listán rögtön ott lesz a Googlebot, a Bingbot, az Applebot, a GPTBot, a ClaudeBot és a PerplexityBot, mellettük pedig az a néhány tucat ismeretlen ügynök, amiről addig nem is tudtál. Ha csak a botokat akarod látni, szűkíts: grep -Ei 'bot|crawler|spider' access.log, majd ugyanez a feldolgozás.

Mit kér le konkrétan a Googlebot?

grep 'Googlebot' access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

Ez a legtöbbet mondó egyetlen kimutatás az egész elemzésben. Ha az első húsz sorban paraméteres szűrő-URL-ek, belső keresőoldalak (/?s=), feed-címek, /wp-json/ végpontok, kosár- vagy rendezési paraméterek, esetleg végtelen oldalszámozott archívumok szerepelnek, akkor a feltérképezési keret jelentős része olyan tartalomra megy el, amit soha nem akartál a találatok között látni. Saját tapasztalat: WordPress- és WooCommerce-oldalakon szinte törvényszerű, hogy a szűrőparaméteres címek felkúsznak ebbe a toplistába.

Milyen státuszkódokat kapnak a botok?

grep 'Googlebot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Egészséges képnél a 200-as és a 304-es (nem módosult) válaszok dominálnak. A sok 301-es azt jelzi, hogy a bot fölöslegesen köröz átirányításokon, jellemzően elavult belső linkek vagy régi sitemap miatt. Néhány százalék 404 és 410 teljesen normális, a tömeges 5xx viszont azonnali beavatkozást kíván: az ismétlődő szerverhiba a feltérképezés ütemét is visszafoghatja.

Melyek a leggyakoribb 404-esek?

awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -rn | head -30

Ez a lista jellemzően három csoportra bomlik: elrontott belső hivatkozásokra, megszűnt régi URL-ekre, amikre még mutat külső link, és sebezhetőség-kereső próbálkozásokra (/wp-login.php variánsok, /.env, /xmlrpc.php). Az első kettőt javítani vagy átirányítani kell, a harmadik a hamis botok fejezetébe tartozik.

Hogyan alakul a feltérképezés napról napra?

grep 'Googlebot' access.log | awk '{print substr($4,2,11)}' | sort | uniq -c

Napi bontásban azonnal látszik, ha egy sitemap-frissítés, egy nagyobb tartalmi kör vagy éppen egy szerverhiba után megváltozott a feltérképezés üteme. Ez a mérés különösen akkor hasznos, ha nagyobb technikai átalakítás után szeretnéd tudni, mikor tért vissza minden a normál kerékvágásba.

Mit árul el a válaszidő és a letöltött adatmennyiség?

Rövid válasz: azt, hogy a szerver oldaláról mennyire drága kiszolgálni a botokat, és van-e olyan URL-csoport, ami aránytalanul sok erőforrást visz el.

Ha bekapcsoltad a válaszidő-mezőt, rendezd az URL-eket átlagos kiszolgálási idő szerint, és nézd meg a leglassabb húszat. Szakmai feltételezés: ha a botok rendszeresen több másodperces válaszokat kapnak, az hosszabb távon visszafoghatja a feltérképezés intenzitását, mert a keresők a szerver terhelhetőségéhez igazítják a kérésszámot. A Google dokumentációja a feltérképezési keretet valóban részben a szerver válaszkészségéhez köti, de az adott oldalra vetített pontos hatást a naplóból nem lehet bizonyítani, csak valószínűsíteni.

Az adatmennyiség hasonlóan tanulságos: awk '{s+=$10} END {print s/1024/1024" MB"}' access.log megadja a kiszolgált összes adatot, és ugyanez botra szűrve megmutatja, mekkora a bot-forgalom aránya. Ha egy agresszív, számodra értéktelen crawler viszi a sávszélesség számottevő részét, annak korlátozása közvetlen költségmegtakarítás is lehet.

Hogyan ellenőrzöd, hogy a Googlebot valóban a Google-tól jön?

Rövid válasz: kétlépcsős fordított DNS-ellenőrzéssel. A user agent szöveget bárki átírhatja a saját kérésében, az IP-cím visszafejtését viszont nem tudja meghamisítani.

Hivatalosan igazolt, a Google Search Central leírása alapján a folyamat:

1. Futtass fordított DNS-lekérdezést a naplóban szereplő IP-re: host 66.249.66.1. Az eredménynek googlebot.com, google.com vagy googleusercontent.com végződésűnek kell lennie, például crawl-66-249-66-1.googlebot.com.
2. Futtass egyenes lekérdezést a kapott hosztnévre: host crawl-66-249-66-1.googlebot.com. Ha ez pontosan ugyanazt az IP-címet adja vissza, a bot valódi. Ha bármelyik lépés nem stimmel, hamis.

Ugyanez az elv működik a Bingbotnál is. Emellett a Google, a Microsoft, az OpenAI és az Anthropic gépi olvasható JSON-fájlokban is közzéteszi a botjai IP-tartományait, így nagyobb naplónál a listás összevetés gyorsabb, mint a soronkénti DNS-lekérdezés.

A gyakorlatban így indulj el: grep 'Googlebot' access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20, majd a kapott húsz IP-t ellenőrizd egyesével. Saját tapasztalat: a valódi Googlebot-forgalom szinte mindig néhány jól felismerhető tartományból érkezik, a hamis pedig szórt, és jellemzően olyan felhőszolgáltatók címeiről jön, amik nyilvános IP-listákon nem szerepelnek.

Mit kezdj a hamis botokkal?

Rövid válasz: először mérj, aztán korlátozz, és soha ne blokkolj vaktában, puszta névegyezés alapján.

Fontos kiindulópont: hivatalosan igazolt, hogy a robots.txt csak kérés, nem műszaki tiltás. Egy tisztességes bot betartja, a hamis Googlebot pedig épp attól hamis, hogy nem tartja be. A robots.txt tehát önmagában nulla védelmet ad az álcázott forgalommal szemben, ehhez szerveroldali szabály kell.

• Sebességkorlátozás: a legkíméletesebb eszköz. Nginx alatt a limit_req, Apache alatt a mod_ratelimit vagy egy fail2ban-szabály az ismétlődő 404-ekre. Ez nem tilt ki senkit véglegesen, csak lelassítja a túl agresszív kérőt.
• WAF- vagy CDN-szabály: ha van előtted proxy, ott érdemes megfogni a forgalmat, mert így a szervered terhelése is csökken, nem csak a naplód lesz tisztább.
• Célzott blokkolás: ha egy konkrét IP-tartomány bizonyítottan hamis botot futtat, tilthatod közvetlenül. Jegyezd fel, mikor és miért tetted, mert fél év múlva már senki nem fogja tudni, mi az a sor a konfigban.
• Amit ne csinálj: ne tilts általános mintára, például minden „bot” szót tartalmazó user agentre. Ezzel a valódi keresőbotokat is kizárod, és a hiba jellemzően csak hetekkel később derül ki, amikor a látogatottság már csökkenőben van.

Szakmai feltételezés: a hamis Googlebotok többsége nem célzott támadás, hanem tartalommásoló szolgáltatás vagy automatizált sebezhetőség-kereső, amelyik azért veszi fel a Google nevét, mert sok oldal bot-szűrése alapból átengedi a Googlebotot. Ezt kutatással nem tudom alátámasztani, a naplókban visszatérően látott minta viszont ebbe az irányba mutat.

Hogyan néz ki egy havi naplóelemzési rutin 4 lépésben?

1. Adatgyűjtés (kb. 10 perc). Töltsd le az elmúlt 30 nap naplóit, és fűzd őket egy fájlba: zcat access.log.*.gz > honap.log. Ellenőrizd, hogy tényleg a teljes időszakot lefedi, mert hiányzó napokkal minden későbbi összehasonlítás félrevisz.
2. Bot-leltár (kb. 15 perc). Futtasd a user agent szerinti bontást, és írd fel egy táblázatba a tíz legaktívabb bot kérésszámát. A lényeg nem az abszolút szám, hanem az előző hónaphoz mért változás: melyik bot jelent meg újonnan, melyik tűnt el, melyik ugrott meg hirtelen.
3. Minőségi ellenőrzés (kb. 20 perc). Botonkénti státuszkód-bontás, 404-toplista, 5xx-ek, és ha van válaszidő-mező, a leglassabb URL-ek. Jelöld meg azt a három problémát, ami a legtöbb kérést érinti, a többit hagyd a következő hónapra.
4. Beavatkozás és visszamérés (a maradék idő). Javítsd a hibás belső hivatkozásokat, irányítsd át a megszűnt URL-eket, zárd ki a robots.txt-ben azt, amit valóban nem akarsz feltérképeztetni, és jegyezd fel a dátumot. Következő hónapban pontosan ugyanazokat a számokat nézed meg, így látod, hogy a beavatkozás hatott-e.

Ez a rutin nagyjából egy óra havonta. Nem garantál jobb helyezést, és önmagában nem hoz forgalmat sem, de jó eséllyel kiszűri azokat a technikai akadályokat, amiktől a jó tartalmad nehezebben jut el a keresőkig és az AI-válaszmotorokig.

Mire nem alkalmas a naplóelemzés?

Érdemes tisztán látni a határait is. A napló megmondja, hogy egy AI-bot letöltötte az oldaladat, azt viszont nem, hogy megjelentél-e egy AI-válaszban: a letöltés és az idézés két külön dolog. Nem mutatja a JavaScripttel utólag betöltött tartalmat sem, csak a szerver által kiszolgált nyers választ. CDN mögött hiányos, ha nincs valós IP-visszaállítás. És a legfontosabb: a feltérképezés nem indexelés, az indexelés pedig nem rangsor. A napló arra való, hogy a technikai zavarokat kiszűrd belőle, nem arra, hogy eredményt ígérj a számai alapján.

Források és további olvasnivalók

• Google Search Central: A Googlebot és más Google-feltérképezők ellenőrzése (fordított DNS-ellenőrzés)
• Google Search Central: Feltérképezési statisztikák jelentés a Search Console-ban
• Google Search Central: A feltérképezési keret kezelése nagy méretű webhelyeken
• Google Search Central: A Google feltérképezőinek nyilvános IP-tartományai (googlebot.json, special-crawlers.json, user-triggered-fetchers.json)
• Bing Webmaster Tools dokumentáció: Bingbot ellenőrzése
• Apache HTTP Server dokumentáció: mod_log_config, mod_remoteip
• nginx dokumentáció: ngx_http_log_module, ngx_http_realip_module
• OpenAI dokumentáció: GPTBot és a további OpenAI-ügynökök
• Anthropic dokumentáció: ClaudeBot és a Claude webes ügynökei
• IETF RFC 9309: Robots Exclusion Protocol
• cPanel, Plesk és ispmanager hivatalos dokumentáció: naplófájlok elérése és archiválása