Logfájl elemzés a gyakorlatban: Így optimalizáld a Googlebot kúszási keretét

A logfájl elemzés a technikai SEO abszolút igazságforrása, amellyel közvetlenül a szerver oldaláról láthatod, hogyan viselkedik a Googlebot a weboldaladon. Ezzel a módszerrel pontosan azonosíthatod, hol pazarolja a keresőmotor a kúszási keretet (crawl budget) felesleges átirányításokra, paraméterezett URL-ekre vagy éppen hibaoldalakra, így drága és bonyolult külső szoftverek megvásárlása nélkül, manuálisan is százezreket spórolhatsz meg a webhelyed optimalizálása során.

Mi az a logfájl elemzés, és miért ez a technikai SEO végső igazságforrása?

Amikor a keresőmotorok feltérképezik az internetet, minden egyes látogatásuk, lekérdezésük és interakciójuk nyomot hagy a szervered naplófájljaiban. A logfájl elemzés lényegében nem más, mint ezeknek a nyers szervernaplóknak a kibányászása, szűrése és értelmezése. Míg a Google Search Console (GSC) kiváló áttekintést nyújt, és a különféle külső SEO-eszközök is hasznosak, addig egyetlen harmadik féltől származó szoftver sem képes azt a valós idejű, 100%-os pontosságú adathalmazt biztosítani, amit a saját szervered rögzít.

Sokan esnek abba a hibába, hogy egy hagyományos technikai seo audit során kizárólag szimulált feltérképezésekre (például a Screaming Frog vagy a Sitebulb futtatására) támaszkodnak. Bár ezek a szoftverek szimulálják a Googlebot viselkedését, valójában nem mutatják meg, hogy a valódi Googlebot mikor, hányszor és pontosan mely weblapokat látogatta meg. A szerver loganalízis ezzel szemben feketén-fehéren megmutatja a tényeket. Nincs tippelgetés, nincs mintavételezés (sampling), csak a kőkemény valóság.

Különösen fontos ez a szintű mélység a nagyobb, több tízezer vagy akár több millió aloldallal rendelkező webhelyek esetében. Egy webáruháznál például, ahol a szűrők, a rendezési opciók és a termékvariációk virtuálisan végtelen számú URL-t generálhatnak, a Googlebot könnyen eltévedhet és feleslegesen pazarolhatja az erőforrásait. Ha nem elemzed a logfájlokat, vakon próbálod meg kitalálni, hogy miért nem indexeli a Google az újonnan feltöltött termékeidet vagy a legfrissebb blogcikkeidet.

Mi az a kúszási keret (crawl budget), és hogyan égeti el a Googlebot a pénzedet?

A Googlebot nem rendelkezik korlátlan kapacitással és idővel. Minden egyes webhely esetében meghatároz egy úgynevezett kúszási keretet (crawl budget). Ez a keret két fő összetevőből áll: a kúszási sebesség korlátjából (crawl rate limit), amely megelőzi, hogy a bot túlterhelje a szervert, valamint a kúszási igényből (crawl demand), amely azt mutatja meg, hogy a Google mennyire tartja népszerűnek és frissítésre érdemesnek a webhelyedet. Ha a Googlebot a felesleges URL-ek mászásával tölti az idejét, az értékes oldalaidra már nem marad keret.

Gondolj a kúszási keretre úgy, mint egy napi fix összegű költségvetésre. Ha van naponta 10 000 lekérdezésed a Googlebottól, és ebből 6 000 darabot olyan URL-ekre pazarol el, mint a nyomtatási nézetek, a bejelentkezési oldalak vagy a duplikált paraméteres szűrések, akkor a valódi, üzletileg fontos oldalaidnak mindössze a 40%-a kap esélyt a frissülésre vagy az indexelésre. Ez közvetetten hatalmas bevételkiesést jelent, hiszen az új termékek vagy a szezonális akciók nem jelennek meg időben a találati listán.

A webshopok esetében a hatalmas mennyiségű termékvariációk és SEO problémák szinte azonnal felemésztik a kúszási keretet, ha nincsenek megfelelően kezelve. Ha a Googlebot több ezer azonos tulajdonságú, csak színben vagy méretben eltérő termékoldalt térképez fel egymás után, akkor a valódi kategóriaoldalak és a fő termékek frissítése háttérbe szorul. A crawl budget optimalizálás célja éppen az, hogy ezt a pazarlást megszüntessük, és ráirányítsuk a keresőrobot figyelmét a konverziót hozó oldalakra.

Hogyan férhetsz hozzá a szervernaplókhoz drága szoftverek nélkül?

Sokan azért riadnak vissza a logfájl elemzéstől, mert azt hiszik, hogy ehhez méregdrága enterprise szoftverekre (mint a Botify, a Semrush Log File Analyzer vagy a Screaming Frog fizetős logelemzője) van szükség. Ez óriási tévedés. A szervernaplók nyers szöveges fájlok, amelyekhez teljesen ingyen is hozzáférhetsz, és egyszerű, mindennapi eszközökkel is elemezheted őket.

A hozzáférés módja a tárhelyed vagy szervered típusától függ. A leggyakoribb forgatókönyvek a következők:

• cPanel vagy Plesk felület: Ha hagyományos osztott tárhelyet használsz, jelentkezz be a vezérlőpultra, keresd meg a "Logs" vagy "Raw Access Logs" (Nyers hozzáférési naplók) menüpontot, és töltsd le tömörített (.gz) formátumban az adott domainhez tartozó fájlt.
• SSH hozzáférés (Nginx vagy Apache szerver): Ha saját VPS-ed vagy dedikált szervered van, SSH-n keresztül közvetlenül elérheted a naplófájlokat. Apache esetén általában a /var/log/apache2/access.log, míg Nginx esetén a /var/log/nginx/access.log útvonalon találod meg őket.
• Cloudflare vagy CDN naplók: Ha Cloudflare-t használsz a webhelyed előtt, a Logpush vagy a Cloudflare Analytics API segítségével is kinyerheted a lekérdezési adatokat, bár a teljes nyers logokhoz bizonyos esetekben prémium előfizetés szükséges.

Miután letöltötted a fájlokat, ne ijedj meg a méretüktől. Egy közepes méretű weboldal havi logfájlja is lehet több gigabájtos, de mint látni fogjuk, parancssorból vagy specifikus szűrésekkel másodpercek alatt kezelhető méretűre tudjuk őket zsugorítani anélkül, hogy egyetlen forintot is költenénk szoftverekre.

Milyen adatokat rejt egy nyers szervernapló bejegyzés? (Anatómia és dekódolás)

Ahhoz, hogy hatékonyan végezhesd a szerver loganalízis folyamatát, meg kell értened, hogyan épül fel egyetlen sor a naplófájlban. Bár a formátum kissé eltérhet az Apache és az Nginx között, a standard Common Log Format (CLF) vagy Combined Log Format szerkezet a következőképpen néz ki:

Bontsuk le ezt a sort az elemeire, hogy pontosan lásd, milyen értékes információkat hordoz:

1. IP-cím (66.249.66.1): A lekérdezést végző kliens IP-címe. A Googlebot esetében ez mindig a Google saját IP-tartományába tartozik.
2. Időbélyeg ([24/Oct/2026:14:32:10 +0200]): A kérés pontos időpontja és a szerver időzónája. Ez kritikus fontosságú a valós idejű hibák felderítésénél.
3. Metódus és URL (GET /blog/seo-audit-checklist HTTP/1.1): A kliens GET metódussal kérte le a /blog/seo-audit-checklist oldalt a HTTP/1.1-es protokoll használatával.
4. HTTP státuszkód (200): A szerver válasza. A 200-as kód azt jelenti, hogy a kérés sikeres volt, az oldal betöltődött.
5. Letöltött bájtok (45230): A szerver által visszaküldött adatmennyiség bájtban kifejezve (kb. 45 KB). Ha ez a szám hirtelen lecsökken a normálishoz képest, az üres oldalt (soft 404) jelezhet.
6. User-Agent: A kliens azonosítója. Itt láthatjuk, hogy valóban a Googlebot (Googlebot/2.1) kezdeményezte-e a lekérdezést.

Hogyan történik a Googlebot hitelesítése és a spambotok kiszűrése?

A modern interneten rengeteg olyan kártékony bot és szoftver kering, amely hamisítja a User-Agent azonosítóját. Sokan állítják magukról, hogy ők a "Googlebot", miközben valójában versenytársak kaparószoftverei (scrapers), biztonsági réseket kereső robotok vagy spambotok. Ha ezeket az adatokat nem szűröd ki, a googlebot követése teljesen téves eredményeket fog hozni.

A Googlebot valós kilétének ellenőrzéséhez (spoofing kiszűrése) egy kétlépcsős folyamatra van szükség, amelyet fordított DNS-keresésnek (Reverse DNS lookup) nevezünk. Ezt manuálisan is elvégezheted a parancssorból egy-egy gyanús IP-cím esetében, de automatizált szkriptekkel is integrálhatod a logfájl elemzés során:

1. Futtass le egy fordított DNS-keresést a naplófájlban talált IP-címre a parancssorban (pl. host 66.249.66.1). A válasznak egy .google.com vagy .googlebot.com végződésű hosztnévnek kell lennie.
2. Ezután futtass egy előre irányuló DNS-keresést (Forward DNS lookup) a kapott hosztnévre (pl. host crash-66-249-66-1.googlebot.com). Ennek vissza kell adnia az eredeti IP-címet. Ha a két lépés egyezik, a bot garantáltan hiteles.

Miért fontos ez? Mert a kártékony és felesleges robotok blokkolásával közvetlenül tehermentesíted a szervert. Ha a szerverednek nem kell másodpercenként több tucat hamis bot kiszolgálásával foglalkoznia, sokkal gyorsabban fog válaszolni a valódi Googlebotnak, ami közvetlenül növeli a kúszási sebesség korlátját, és javítja a felhasználói élményt és a betöltési sebességet is.

Melyek a leggyakoribb crawl budget pazarló hibák, és hogyan javítsd őket?

A szerver loganalízis során szinte mindig ugyanazok a strukturális és technikai hibák bukkannak fel a legnagyobb kúszásikeret-gyilkosként. Nézzük meg a top 3 leggyakoribb problémát, és azt, hogy miként kezelheted őket hatékonyan.

1. Átirányítási láncok (Redirect chains)

Amikor a Googlebot találkozik egy 301-es átirányítással, követi azt az új URL-re. Ha az új URL-en egy újabb átirányítás fogadja, és így tovább, a bot értékes időt és lekérdezési egységet pazarol el. A logfájlokban azonnal látható, ha ugyanaz a bot-látogatás egymás után több 301 vagy 302 státuszkódot generál. Javítás: mindegyik régi URL-t közvetlenül a végső, aktív céloldalra irányítsd át, kiiktatva a láncszemeket.

2. Paraméterezett és duplikált URL-ek

A szűrők, rendezések, követőkódok (UTM paraméterek) és munkamenet-azonosítók miatt ugyanaz a tartalom akár több száz különböző URL-en is elérhetővé válhat. Ha a logban azt látod, hogy a Googlebot folyamatosan olyan URL-eket tölt le, mint a /termekek?color=piros&sort=price_asc, azonnal lépned kell. Használj robots.txt tiltást a felesleges paraméterekre, vagy állítsd be helyesen a kanonikus (canonical) tageket, de a leghatékonyabb, ha a Google Search Console URL-paraméter kezelő eszközét (ahol még elérhető) vagy a robots.txt-t használod a bot távoltartására.

3. Hibaoldalak (404-es és 5xx státuszkódok)

Ha a Googlebot olyan oldalakra téved, amelyek már nem léteznek (404 Not Found), vagy ahol a szerver hibát dob (500 Internal Server Error), az a kúszási keret tiszta pazarlása. Egy alapos technikai seo audit során ezeket a hibákat azonnal fel kell számolni. A 404-es oldalakat irányítsd át a leginkább releváns kategóriaoldalra (de csak ha van valódi egyezés, egyébként hagyd meg 404-nek, de távolítsd el a rájuk mutató belső linkeket), az 5xx hibákat pedig a szerver szintjén, a fejlesztőddel közösen javítsd.

Hogyan építs fel egy saját logfájl elemző munkafolyamatot ingyen vagy fillérekből?

Most, hogy ismered az elméletet, nézzük meg lépésről lépésre, hogyan végezheted el a teljes folyamatot anélkül, hogy drága célszoftvereket vásárolnál. Szükséged lesz egy parancssorra (Linux/macOS Terminal, vagy Windows alatt Git Bash / WSL) és egy táblázatkezelőre (Google Táblázatok vagy Microsoft Excel).

1. Logfájl letöltése és tömörítése: Töltsd le a szerver hozzáférési naplóját (pl. access.log). Ha a fájl nagyon nagy, érdemes csak az elmúlt 14 vagy 30 nap adatait megtartani.
2. Szűrés a Googlebotra: Futtasd le a következő parancsot a terminálban, hogy kiszűrd a Googlebot összes lekérdezését egy külön fájlba:

   grep "Googlebot" access.log > googlebot_raw.log

3. A felesleges statikus elemek kizárása: A keresőoptimalizálás szempontjából a képek, CSS, JS és betűtípusok lekérdezései torzíthatják a képet (bár fontosak a rendereléshez, első körben a HTML oldalak a legfontosabbak). Zárd ki őket:

   grep -v -E "\.jpg|\.jpeg|\.png|\.gif|\.css|\.js|\.woff|\.svg" googlebot_raw.log > googlebot_html.log

4. Adatok exportálása CSV formátumba: Alakítsd át a nyers sorokat egy egyszerűen olvasható, vesszővel vagy tabulátorral tagolt formátumba. Az awk parancs segítségével kinyerhetjük a dátumot, az URL-t és a státuszkódot:

   awk '{print $4 ";" $7 ";" $9}' googlebot_html.log > googlebot_final.csv

5. Importálás és elemzés: Nyisd meg a googlebot_final.csv fájlt Excelben vagy Google Táblázatokban. Hozz létre egy pivot táblát (kimutatást), ahol a sorok az URL-ek vagy a státuszkódok, az értékek pedig a lekérdezések száma.

Ezzel a végtelenül egyszerű, de bivalyerős módszerrel azonnal látni fogod, hogy melyek a leggyakrabban lekérdezett URL-ek, mely oldalak adnak hibaüzenetet, és hol pazarolja el a Googlebot a legtöbb időt a webhelyeden. Nem volt szükség drága havidíjas licencekre, csupán a beépített technológia okos használatára.

Hogyan hat a Mobile-First Indexelés a Googlebot tevékenységére?

A modern keresőoptimalizálásban már elengedhetetlen, hogy különbséget tegyünk a Googlebot mobil és asztali (desktop) verziója között. Különösen igaz ez, hiszen a Google Mobile-First Indexelés korszakában a Google elsődlegesen a webhelyed mobil verzióját használja az indexeléshez és a rangsoroláshoz.

A szerver loganalízis során ezt könnyen ellenőrizheted a User-Agent fejléc vizsgálatával. A mobil Googlebot azonosítója általában tartalmazza az "Android" vagy "iPhone" szavakat, míg az asztali verzióé nem. Ha elemzed a logfájljaidat, látni fogod, hogy az összes Googlebot lekérdezés jelentős része (általában 80-90%-a) a mobil botoktól származik.

Ha azt veszed észre, hogy az asztali Googlebot még mindig szokatlanul gyakran látogatja az oldaladat, az technikai problémára utalhat. Ez jelentheti azt, hogy a Google nem találja elég konzisztensnek a mobil és az asztali verziód közötti struktúrát vagy tartalmat, vagy esetleg dinamikus kiszolgálási hibát (dynamic serving issue) észlel. A két bot-típus arányának és viselkedésének monitorozása kritikus része a professzionális crawl budget optimalizálás folyamatának.

Hogyan mutatkoznak meg a hreflang hibák és a nemzetközi SEO nehézségek a szervernaplókban?

Amikor egy vállalkozás szintet lép, és a nemzetközi SEO rögös útjára lép, a technikai komplexitás exponenciálisan növekszik. A többnyelvű oldalak koordinálása, a különböző nyelvi verziók összekapcsolása folyamatos kihívást jelent mind a fejlesztők, mind a SEO szakemberek számára. A leggyakoribb hibaforrás itt egyértelműen a hreflang címkézés.

A nemzetközi webáruházak működtetőinek a hreflang implementáció is komoly fejtörést okozhat, de szerencsére a logfájl elemzés itt is tiszta vizet önt a pohárba. Ha a hreflang beállítások hibásak (például oda-vissza hivatkozások hiánya, hibás nyelv- és országkódok), a Googlebot elkezdhet hektikusan és feleslegesen ugrálni a nyelvi verziók között.

A logfájlokban keresd meg azokat a mintákat, ahol a Googlebot külföldi IP-címekről (például az Egyesült Államokból vagy az európai adatközpontokból) szokatlan ugrásokkal pásztázza a különböző nyelvű aloldalakat egymás után. Ha a különböző nyelvi verziók nincsenek megfelelően elszeparálva és kanonizálva, a Googlebot elpazarolja a kúszási keretet a tartalom felesleges kereszt-feltérképezésére, miközben a helyi felhasználóknak szánt releváns oldalak háttérbe szorulnak.

Mire figyelj a mérőszámok értékelése során? (Összehasonlító táblázat)

A szerver loganalízis során kapott adatok mit sem érnek, ha nem tudod, milyen státuszkódok mit jelentenek a Googlebot számára, és milyen azonnali beavatkozást igényelnek. Az alábbi táblázat összefoglalja a leggyakoribb státuszkódokat, azok SEO-hatásait és a szükséges gyakorlati lépéseket.

Ne feledd, hogy a 304-es státuszkód megléte kifejezetten jó jel az ismételt látogatásoknál, mert ez azt mutatja a Googlebotnak, hogy az oldal tartalma a legutóbbi látogatás óta nem változott. Ezzel a Googlebot időt spórol, és gyorsabban tud továbbhaladni a webhely valóban frissült részei felé.

Esettanulmány: Hogyan nyertünk vissza 42% elvesztegetett kúszási keretet egy 50.000 termékes webáruháznál?

Hogy lásd a logfájl elemzés valódi erejét, álljon itt egy konkrét, hazai példa. Egyik ügyfelünk egy divatcikkeket értékesítő webáruházzal keresett meg minket, ahol az új termékek indexelése átlagosan 10-14 napba telt. Ez a szezonalitás miatti gyors forgási sebesség mellett vállalhatatlan volt commercial szempontból.

A technikai audit során elindítottuk a szerver loganalízis folyamatát, és egy hónapnyi adatot dolgoztunk fel. Az eredmények megdöbbentőek voltak: a Googlebot napi 15 000 lekérdezésének több mint 42%-a olyan URL-ekre irányult, amelyek az intelligens szűrőrendszer (szín, méret, anyag, ár szerinti kombinációk) által generált, végtelenített variációk voltak. Ezek az oldalak ráadásul nem is voltak indexelhetőek, hiszen csupán duplikátumok voltak canonical címkével ellátva.

A javítás során a következő lépéseket hajtottuk végre:

• A robots.txt fájlon keresztül megtiltottuk a Googlebotnak, hogy hozzáférjen a szűrőparamétereket (pl. ?color=, ?price=) tartalmazó URL-ekhez.
• Megszüntettük az összes olyan belső linket, amely elavult, 404-es vagy már átirányított aloldalakra mutatott.
• Közvetlen belső linkelési struktúrát építettünk ki az új termékek gyors elérésére a főoldalról és a főbb kategóriákból.

Az eredmények szinte azonnal jelentkeztek. A beállítások élesítése utáni héten a felesleges lekérdezések aránya 42%-ról 3% alá esett vissza. A felszabadult kúszási keretnek köszönhetően a Googlebot végre az új és fontos termékoldalakra koncentrálhatott: az újonnan feltöltött termékek indexelési ideje a korábbi 10-14 napról átlagosan mindössze 4 órára csökkent. Ez a organikus forgalom azonnali, 24%-os növekedését eredményezte már az első hónapban.

A logfájl elemzés és a crawl budget optimalizálás nem varázslat, hanem precíz, mérnöki pontosságú technikai SEO munka. Ha szeretnéd, hogy weboldalad vagy webáruházad a maximális sebességgel és hatékonysággal működjön a Google szemében, és ne pazarolj százezreket felesleges szoftverekre, vedd kezedbe a szervernaplók irányítását. Amennyiben ehhez professzionális segítségre lenne szükséged, az automataseo.hu csapata készséggel segít kiaknázni a webhelyedben rejlő maximális organikus potenciált.