A technikai SEO-ban van egy pont, ahol minden külső eszköz elhallgat. Hogy a Googlebot, a GPTBot vagy a PerplexityBot pontosan mikor, milyen URL-t, milyen státuszkóddal és mekkora válaszidővel kapott meg a szerveredről, azt egyetlen helyen látod teljes bizonyossággal, a szerver hozzáférési naplójában. A Search Console összesít és késik, a crawler-szimulátorok azt mutatják, mit látnának, a napló viszont azt rögzíti, ami tényleg megtörtént.
Miért a naplóhozzáférés a technikai SEO legdrágább vakfoltja?
Rövid válasz. Mert a napló nélkül minden crawl-megállapítás feltételezés marad, és a hiányzó hozzáférés pótlása pont akkor tart napokig, amikor a leggyorsabban kellene válaszolni.
Saját tapasztalat. A legtöbb elakadt technikai SEO-munkában nem a tudás hiányzik, hanem az adat. Az ügyfél azt látja, hogy egy aloldal-csoport eltűnt az indexből, a Search Console jelentése pedig már csak összesített számokat mutat a rossz időszakról. Ha a napló megvan, tizenöt perc alatt kiderül, hogy a bot mit kapott azokon a napokon, 200-at, 301-et, 403-at vagy 503-at. Ha nincs meg, hetekig találgatunk, közben újratelepítünk, cache-t ürítünk, és a valódi ok, például egy biztonsági modul bot-tiltása, végig ott áll a naplóban, csak senki nem nyitotta meg.
Az AI-korszakban ez még többet nyom. Az AI-crawlerek viselkedéséről nincs Search Console-szerű felületünk. Nincs olyan panel, ahol megnézhető, mit vitt el a ClaudeBot vagy a GPTBot. Hivatalosan igazolt, hogy az OpenAI és az Anthropic dokumentálja a botjai user agent sztringjét és IP-tartományát, tehát azonosíthatók, de kizárólag a naplóból. Ez a hozzáférés ma nem kényelmi kérdés, hanem a mérés alapja.
Mi van pontosan egy naplósorban?
Rövid válasz. A legtöbb magyar tárhelyen a kombinált napló-formátum fut, amely soronként megadja a kérő IP-jét, a kérés idejét, a kért útvonalat, a státuszkódot, a válasz méretét, a hivatkozót és a user agentet.
Hivatalosan igazolt. Az Apache ezt a mod_log_config combined formátumában írja, az Nginx az ngx_http_log_module alapértelmezett combined formátumában. A kettő lényegében ugyanaz, ezért a legtöbb parancs mindkettőn működik. Egy tipikus sor a kérő IP-vel indul, majd két kötőjel, szögletes zárójelben a dátum és az időzóna-eltolás, idézőjelben a kérés metódusa és útvonala, végül a státuszkód, a byte-méret, a hivatkozó és a böngésző vagy bot azonosítója.
Fontos csapda. Ha az oldal CDN vagy proxy mögött van, az első mező nem a valódi látogató IP-je, hanem a proxy címe. Ilyenkor a valódi IP külön fejlécből kerül a naplóba, és ezt a webszerveren külön be kell állítani. Ha ez nincs meg, a bot-ellenőrzés esélytelen, mert minden kérés ugyanarról a néhány címről érkezik.
Hol találod meg a naplót a négy leggyakoribb felületen?
Rövid válasz. cPanelben a Mérőszámok csoport Nyers hozzáférés pontja, Pleskben a Weboldalak és domainek alatti Naplók panel, ispmanagerben a WWW-domainek listából nyíló Naplók, VPS-en pedig a /var/log könyvtár megfelelő alkönyvtára.
cPanel
A Mérőszámok (Metrics) csoportban két hasznos pont van. A Nyers hozzáférés letölti a domain aktuális és archivált naplóit gzip-tömörítve, a Nyers napló megtekintés pedig a legutóbbi bejegyzéseket mutatja. SSH- vagy fájlkezelő-hozzáféréssel a naplók általában a fiók saját könyvtárában, egy access-logs vagy logs nevű mappában állnak. Fontos, hogy a Nyers hozzáférés lapon van egy jelölőmező az archiválásra. Ha az nincs bekapcsolva, a rendszer a statisztikák feldolgozása után törli a naplót, tehát pár nap múlva már nincs mit letölteni. Ezt szinte mindig ki kell pipálni első körben.
Plesk
A Weboldalak és domainek nézetben a domain alatt van egy Naplók elem, amely élő nézetben pörgeti a bejegyzéseket, és szűrhető státuszkód szerint. A letöltés a Fájlkezelőből vagy SSH-val megy, a vhost könyvtárának logs alkönyvtárából. Itt a gyakori zavar, hogy több naplófájl áll egymás mellett, külön a titkosított és a titkosítatlan forgalomra, és külön a proxy-rétegre. Az Nginx proxy mögött futó Apache esetén a bot-kérések a proxy naplójában látszanak először, ezért érdemes mindkettőt átnézni. A megőrzést a Naplóforgatás beállításban tudod hosszabbítani, ha van rá jogosultságod.
ispmanager
Magyar szolgáltatóknál ez a panel elég gyakori. A WWW-domainek listában kijelölöd a domaint, és a felső eszközsorban a Naplók ikon nyitja a hozzáférési és a hibanaplót. Fájlszinten a felhasználó könyvtárában egy data/logs mappában találod, domainenként külön .access.log és .error.log fájllal, mellette a forgatott, tömörített példányokkal. A panel beépített megtekintője nagy naplónál lassú, ezért ha egy hónap forgalmát akarod elemezni, inkább töltsd le.
Saját VPS vagy dedikált szerver
Itt nincs kérdés, minden a tiéd. Debian és Ubuntu alatt az Nginx naplója a /var/log/nginx/access.log, az Apache-é a /var/log/apache2/access.log, RHEL-alapú rendszereken az Apache /var/log/httpd/access_log néven írja. A forgatást a logrotate végzi, a beállítása az /etc/logrotate.d alatti fájlban van. Saját tapasztalat. VPS-en a leggyakoribb hiba nem a hozzáférés, hanem hogy a virtuális hoszt konfigurációja egyetlen közös naplóba ír minden domaint, így a bot-forgalom domainenkénti szétválasztása utólag nehézkes. Új szerver beállításánál ezt öt perc alatt rendbe teheted, később sokkal drágább.
Meddig őrzik meg a naplót a szolgáltatók?
Rövid válasz. Osztott tárhelyen tipikusan néhány naptól négy hétig, és a forgatás után a régi napló véglegesen eltűnik, ha nincs archiválás.
Hivatalosan igazolt. A Debian-alapú rendszerek gyári logrotate-beállítása napi forgatással kb. két hetet tart meg, a cPanel pedig a statisztikák feldolgozása után törli a nyers naplót, ha az archiválás nincs bekapcsolva. Szakmai feltételezés, de sok magyar szolgáltatónál így viselkedik a rendszer, hogy a panelben látható napló csak az aktuális napot vagy hetet mutatja, miközben a szolgáltató a saját üzemeltetési célú másolatát ennél hosszabb ideig tartja, csak nem teszi ki a felületre. Ezért érdemes külön rákérdezni, nem csak a panelt nézni.
A gyakorlati következtetés egyszerű. Ha a naplóra a munkád során szükséged lehet, ne arra rendezkedj be, hogy majd baj esetén visszakérdezel. Állítsd be az archiválást, vagy szervezz heti letöltést. Egy közepes weboldal havi naplója tömörítve általában néhány tíz megabyte, ennek a tárolása nem probléma.
Mit kérj az ügyfélszolgálattól, ha nincs kitéve a felületre?
Rövid válasz. Ne naplót kérj, hanem konkrétan megnevezett fájlt, megnevezett időszakra, megnevezett formátumban, és mondd meg, mire használod.
Saját tapasztalat. A pontatlan kérés az, ami elveszi az időt. A „kérem a naplókat” típusú levélre gyakran a látogatói statisztika HTML-riportja jön vissza, ami elemzésre használhatatlan. Az alábbi levéltörzs viszont egy körben szokott célt érni.
Kedves Ügyfélszolgálat!
A [domain] weboldal technikai átvizsgálásán dolgozom a tárhely előfizetőjének megbízásából. A weboldal nyers hozzáférési naplójára (access log) lenne szükségem, nem a feldolgozott látogatói statisztikára. Négy kérdésem van.
- Elérhető-e a nyers napló a vezérlőpulton, és ha igen, melyik menüpontban?
- Meddig visszamenőleg érhető el, és mennyi idő után törli a rendszer?
- Be tudjuk-e kapcsolni az archiválást vagy hosszabb megőrzést, hogy a következő hónapok naplója megmaradjon?
- Ha a felületen nem érhető el, le tudják-e generálni a [kezdő dátum] és [záró dátum] közötti időszakot, kombinált (combined) formátumban, csonkítatlan user agent mezővel?
A naplót kizárólag a keresőrobotok és AI-crawlerek viselkedésének vizsgálatára használjuk. Ha adatvédelmi okból a látogatói IP-címeket anonimizálni szükséges, kérem jelezzék, milyen módon teszik, hogy az elemzésnél ezt figyelembe vegyük.
Az utolsó bekezdés azért van benne, mert megnyugtatja a szolgáltatót, és egyben kiszedi belőle azt az információt, amire a következő szakaszban szükség lesz.
Milyen ellenőrzőlistán menj végig, amikor megkapod a naplót?
Rövid válasz. Négy dolgot kell tisztázni, mielőtt bármit állítasz az adatból, a formátumot, az időzónát, az IP-kezelést és a letöltés gyakoriságát.
- Formátum. Kombinált formátum-e, benne van-e a hivatkozó és a user agent. Ha a user agent hiányzik, a napló bot-elemzésre alkalmatlan, és ezt azonnal vissza kell jelezni. Ha a szolgáltató extra mezőket szúr a sor elejére, a mezőszámok elcsúsznak, tehát a parancsokat át kell írni.
- Időzóna. A naplósor időpontja szerverhelyi idő vagy UTC. Hivatalosan igazolt, hogy a Search Console jelentései csendes-óceáni idő szerint készülnek, tehát ha a kettőt egymás mellé teszed, az eltérés akár egy naptári napot is elmozdíthat. A combined formátum szerencsére kiírja az eltolást, azt olvasd ki, ne tippelj.
- IP-anonimizálás. Kérdezd meg, csonkolják-e az utolsó oktettet. Ha igen, a látogatói elemzéshez ez rendben van, viszont a keresőrobot-ellenőrzés elveszik, mert az csak teljes IP-ből működik visszafejtéssel. Ilyen esetben a user agent alapú szűrés marad, ami hamisítható, tehát az eredményt óvatosabban kell kezelni.
- Letöltési gyakoriság. Döntsd el, hetente vagy havonta hozod le, és hova. A forgatott állományok tömörítve állnak, ezért a letöltés tárolása olcsó, a pótlás viszont lehetetlen.
Milyen grep-parancsokkal nézd át először a naplót?
Rövid válasz. Három parancs elég ahhoz, hogy pár perc alatt lásd, kik jönnek, mit kérnek és hol kapnak hibát.
Először azt nézd meg, melyik botok járnak egyáltalán az oldalon, és milyen arányban.
grep -ioE 'Googlebot|bingbot|GPTBot|ClaudeBot|PerplexityBot|Applebot' access.log | sort | uniq -c | sort -rn
Ez soronként kiemeli a bot nevét, majd megszámolja. Hivatalosan igazolt részlet, amit sokan félreértenek, hogy a Google-Extended nem crawler és nem jelenik meg a naplóban, az csak egy robots.txt-ben használható vezérlő jelölés, tehát ne keresd. A Googlebot viszont ott lesz.
Másodszor azt, hogy egy adott bot mit kért a leggyakrabban.
grep -i 'GPTBot' access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
A hetedik mező a kért útvonal a kombinált formátumban. Ha a lista tetején paraméteres szűrő-URL-ek, kosár- vagy keresőoldalak állnak, akkor a crawl-költségvetés olyan helyre folyik el, ahonnan érdemi tartalom nem kerül a válaszokba.
Harmadszor a hibákat.
awk '$9 == 404 || $9 == 410 {print $9, $7}' access.log | sort | uniq -c | sort -rn | head -30
A kilencedik mező a státuszkód. Ugyanezzel a logikával az $9 == 503 vagy $9 == 403 szűrés árulja el, ha egy biztonsági modul vagy tűzfal-szabály ad vissza tiltást a botoknak, ami az egyik leggyakoribb rejtett indexelési hiba. A tömörített, forgatott állományokra ugyanezek működnek zgrep és zcat párossal, tehát a hónapokkal korábbi napló is vizsgálható kibontás nélkül.
Egy figyelmeztetés a számokhoz. A user agent hamisítható, ezért a nagy forgalmú találatokat érdemes IP-visszafejtéssel ellenőrizni, ahol ez a naplóból még lehetséges. Enélkül az eredmény jelzés értékű, nem bizonyíték.
Miért érdemes a naplóhozzáférést már a szerződéskötéskor kikérni?
Rövid válasz. Mert ez az egyetlen technikai erőforrás, amit utólag nem lehet visszamenőleg előállítani, és a megszerzése nem rajtad múlik.
Egy FTP-jelszó, egy Search Console-meghívó vagy egy analitikai hozzáférés bármikor pótolható, és az adat attól nem lesz kevesebb. A napló más. Ha a forgatás megtörtént és nem volt archiválás, az az időszak megszűnt létezni. Ezért a naplóhozzáférés kérdése a munka elején való, együtt a tárhely-belépéssel, és nem akkor, amikor már keresünk valamit.
Szakmai feltételezés, de a mi gyakorlatunkban rendre beigazolódik, hogy azoknál a weboldalaknál, ahol az első hónapban beállt a heti napló-letöltés, a későbbi technikai problémák felderítése nagyságrenddel rövidebb. Ez nem garantál jobb helyezést, viszont megszünteti azt az állapotot, amikor a döntéseket sejtésre hozzuk. Az AI-válaszmotorok terjedésével pedig a napló lesz az egyetlen mérőeszközünk arra, mit visznek el a tartalmunkból, ezért érdemes úgy tekinteni rá, mint a mérés alapinfrastruktúrájára.
Források és további olvasnivalók
- Google Search Central, Googlebot ellenőrzése és a Feltérképezési statisztikák jelentés dokumentációja
- Apache HTTP Server Documentation, mod_log_config és a Log Files fejezet
- Nginx dokumentáció, ngx_http_log_module és ngx_http_realip_module
- OpenAI dokumentáció, GPTBot és az OpenAI crawlerek azonosítása
- Anthropic dokumentáció, ClaudeBot és a crawler-hozzáférés kezelése
- cPanel dokumentáció, Raw Access Logs
- Plesk dokumentáció, Website Logs és Log Rotation
- ispmanager dokumentáció, WWW-domain naplók
- logrotate kézikönyvlap (man logrotate)
- Európai adatvédelmi rendelet (GDPR) és a NAIH iránymutatásai a naplóadatok kezeléséről
- A napló az egyetlen forrás, amely megmutatja a bot tényleges kéréseit, státuszkódjait és időpontjait, a Search Console ehhez képest összesít és késik.
- cPanelben a Nyers hozzáférés menüpont, Pleskben a Naplók panel, ispmanagerben a domain Naplók nézete, VPS-en a /var/log alatti fájl a kiindulás.
- A megőrzési idő a legfontosabb kérdés, mert forgatás után a régi napló véglegesen eltűnik, ha nincs archiválás bekapcsolva.
- Az IP csonkolása és a hiányzó időzóna-jelölés utólag ellenőrizhetetlenné teszi a bot-azonosítást, ezért ezt átvételkor tisztázd.
- A naplóhozzáférést a szerződéskötésnél érdemes kikérni, mert utólag ez a leglassabban megszerezhető technikai erőforrás.
Gyakori kérdések
Elég-e a Search Console Feltérképezési statisztikák jelentése a napló helyett?
Kiindulásnak jó, de nem elég. A jelentés összesített, késik, és csak a Google botjairól szól. Az AI-crawlerekről semmit nem mond, és egyedi URL-szintű hibakeresésre sem alkalmas, mert nem látod benne az adott kérés pontos időpontját és státuszkódját.
Mit tegyek, ha a szolgáltató csak anonimizált, csonkolt IP-ket ad?
Az elemzés nagy része így is elvégezhető, a kért URL-ek, a státuszkódok és a user agent alapú bot-azonosítás megmarad. Ami elveszik, az a keresőrobot hitelesítése IP-visszafejtéssel, ezért a user agent alapú találatokat jelzésként és nem bizonyítékként kezeld.
Mennyi naplót érdemes megtartani?
Legalább tizenkét hónapot, ha van rá hely, mert így az évszakos ingadozás és a hosszabb crawl-trendek is láthatók. Tömörítve ez a legtöbb kis és közepes weboldalnál néhány száz megabyte, tehát a tárolás nem szűk keresztmetszet.
Cloudflare vagy más CDN mögött miért egyforma minden IP a naplóban?
Mert a webszerver a proxy IP-jét látja kérőként. A valódi cím a CDN által küldött fejlécben jön, és a webszerveren be kell állítani, hogy azt írja a naplóba. Enélkül a bot-ellenőrzés nem működik, és a földrajzi elemzés is félrevisz.
Kérhetem a naplót akkor is, ha nem én vagyok a tárhely előfizetője?
A kérést az előfizetőnek kell indítania vagy írásban jóváhagynia, a szolgáltató jogosan nem ad ki adatot harmadik félnek. A gyakorlatban a legegyszerűbb, ha az ügyfél továbbítja a levelet, vagy megjelöl a fiókjában kapcsolattartóként.
Van értelme naplóelemzésnek kis, néhány száz oldalas weboldalon is?
Igen, mert a leggyakoribb hibák (bot-tiltás, ismétlődő 404-ek, paraméteres URL-ek felszívása) mérettől függetlenül előfordulnak. Kis oldalon ráadásul a napló is kicsi, tehát az átnézés pár perc munka.
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.