A crawl budget az a fogalom, amit a szakmai beszélgetésekben a leggyakrabban rosszkor vesznek elő. Ha egy 60 oldalas szolgáltatói honlap nem hoz forgalmat, annak szinte biztosan nem a bejárási keret az oka. Ha viszont egy több tízezer termékes webáruház új kategóriái hetekig nem jelennek meg a találatok között, akkor már érdemes megnézni, mire megy el a robot ideje.
Ebben a cikkben végigmegyünk azon, mikor számít egyáltalán a crawl budget, mi szívja el a leggyakrabban, hogyan hozható rendbe a sitemap és a belső linkelés, és hogyan tudod naplófájlból ellenőrizni, mi történik valójában. A szövegben külön jelölöm, mi hivatalosan igazolt információ, mi saját tapasztalat, és mi szakmai feltételezés.
Mikor számít egyáltalán a crawl budget?
Rövid válasz: ritkábban, mint gondolnád. Néhány száz vagy néhány ezer URL-es honlapnál gyakorlatilag sosem, néhány tízezer URL fölött viszont már mérhetően.
Hivatalosan igazolt: a Google Search Central dokumentációja szerint a bejárási keret két tényezőből áll össze. Az egyik a bejárási kapacitás korlátja, vagyis mennyi párhuzamos lekérést bír el a szervered anélkül, hogy lassulna. A másik a bejárási igény, vagyis mennyire tartja a Google fontosnak és frissnek a tartalmadat. A dokumentáció explicit módon kimondja, hogy a néhány ezer URL alatti webhelyek tulajdonosainak ezzel a témával általában nem kell foglalkozniuk.
A gyakorlatban ezeknél a helyzeteknél kerül elő valós problémaként:
- Webáruház sok szűrhető paraméterrel (méret, szín, ár, márka), ahol a kombinációk százezres nagyságrendű URL-t generálnak.
- Ingatlanos, álláshirdetéses vagy apróhirdetéses oldal, ahol a listázó saját URL-t kap minden szűrésre.
- Naptár- vagy eseménynézet, amely elvileg végtelen jövőbeli dátumra ad ki oldalt.
- Nagy hírarchívum, ahol a friss tartalom versenyez a több tízezer régi cikkel.
- Lassú, túlterhelt tárhely, ahol a válaszidő miatt csökken a bejárási kapacitás.
Saját tapasztalat: magyar kkv-ügyfeleknél a leggyakoribb minta nem a hatalmas oldalszám, hanem az, hogy egy amúgy 300 oldalas WordPress-honlap a címke-archívumok, a keresési találati oldalak és a paraméteres verziók miatt több ezer bejárható URL-t termel. Ilyenkor nem több bejárás kell, hanem kevesebb URL.
Első jelzés, hogy baj van: a Search Console Oldalak jelentésében sok URL kerül a Felfedezve, jelenleg nincs indexelve és a Feltérképezve, jelenleg nincs indexelve kategóriába, miközben a Feltérképezési statisztikák szerint napi több ezer lekérés történik.
Mitől szívják el a vékony és duplikált oldalak a bejárást?
Rövid válasz: mert a robot nem tudja előre, hogy egy URL értéktelen lesz. Előbb le kell töltenie, és csak utána dönt. Minden ilyen letöltés a te kapacitásodból megy el.
Hivatalosan igazolt: a Google leírása szerint a facettált navigáció, a munkamenet-azonosítók, a duplikált tartalom, a soft 404 oldalak és a végtelen tér (például naptár) mind rontja a bejárás hatékonyságát. Az is hivatalos, hogy a robots.txt-vel letiltott URL-t a Google nem tölti le, tehát a rajta lévő noindex utasítást sem látja. Ezért a robots.txt és a noindex nem egymás helyettesítői.
Egy magyar bútoripari webáruház tipikus esetében ez így néz ki. A kategórialistán négy szűrő van, mindegyikre öt érték. A rendezés (ár szerint növekvő, csökkenő, népszerűség) külön paraméter. Ez már önmagában több száz URL-változatot ad kategóriánként, negyven kategóriával pedig több tízezret. Ezek jó része szinte azonos terméklistát mutat.
A takarítás gyakorlati sorrendje:
- Gyűjtsd össze, milyen paraméterek fordulnak elő. Screaming Frog-gal vagy a naplófájlból ez fél óra munka.
- Döntsd el paraméterenként, hogy az adott nézet önálló keresési igényt szolgál-e ki. A
?szin=tolgyszűrés lehet értékes landolóoldal, a?orderby=priceszinte biztosan nem. - Az értéktelen kombinációkat tiltsd le robots.txt-ben, ha még nincsenek indexelve.
- Az egyszer már indexelt, felesleges URL-eket ne tiltsd le azonnal. Előbb tedd rájuk a noindex utasítást, hagyd, hogy a robot lássa és kiessenek, és csak utána tiltsd a bejárást.
- A hasonló, de nem azonos nézeteket kanonizáld a fő kategóriára.
Egy visszafogott robots.txt részlet, ami a leggyakoribb zajforrásokat fogja meg:
User-agent: *Disallow: /*?orderby=Disallow: /*?add-to-cart=Disallow: /kereses/Disallow: /*?s=
Szakmai feltételezés: a robots.txt mintaillesztés sok rendszerben könnyen mellélő, ezért minden szabály élesítése előtt érdemes a Search Console robots.txt tesztelőjével néhány valós, fontos URL-t leellenőrizni. Láttam már olyan szabályt, ami a teljes termékkatalógust kizárta.
Mit jelent a sitemap-fegyelem a gyakorlatban?
Rövid válasz: a sitemap nem lista mindenről, ami létezik, hanem javaslat arról, amit indexelni szeretnél.
Hivatalosan igazolt: egy sitemap fájl legfeljebb 50 000 URL-t és tömörítetlenül legfeljebb 50 MB méretet tartalmazhat, e fölött sitemap indexet kell használni. A lastmod értéket a Google akkor veszi figyelembe, ha az következetesen és pontosan tükrözi a tényleges tartalmi változást.
A fegyelmezett sitemap szabályai:
- Csak 200-as státuszkódot adó URL kerüljön bele. Átirányítás, 404 és 410 nem.
- Csak indexelhető URL. Amin noindex van, annak nincs helye a sitemapben.
- Csak önmagára kanonizált URL. Ha az oldal máshová mutat canonical taggel, akkor a cél kerüljön be, ne a forrás.
- A
lastmodlegyen valós. Ha a rendszered minden éjjel átírja az összes dátumot a mai napra, a jelzés elveszíti az értékét. - Bontsd külön fájlokra típus szerint: termékek, kategóriák, blog, statikus oldalak.
Saját tapasztalat: a típusonkénti bontás legnagyobb haszna nem a robotnál jelentkezik, hanem nálad. A Search Console-ban sitemapenként külön látod az indexelési arányt, így azonnal kiderül, ha például a termékoldalak 90 százaléka bent van, a kategóriáké viszont csak a fele. Ez egyetlen összevont sitemapnél észrevehetetlen.
Egy Székesfehérváron működő gépalkatrész-kereskedőnél például az derült ki, hogy a sitemap generátor a lejárt akciós aloldalakat is beletette, pedig azok már átirányítás mögött voltak. A robot hetekig ezeket kérdezgette újra.
Hogyan csökkentsd a belső link-mélységet?
Rövid válasz: úgy, hogy a fontos oldalak három kattintáson belül elérhetők legyenek a nyitóoldalról, és egyetlen bevételt termelő oldal se maradjon árva.
A kattintásmélység két dologra hat. Egyrészt a robot a mélyebben fekvő oldalakat ritkábban éri el, másrészt a belső linkek eloszlása jelzés arról, mit tartasz fontosnak. Szakmai feltételezés: a mélység önmagában nem rangsorolási tényező, de erős közvetett hatása van, mert a ritkábban bejárt oldal frissítései lassabban kerülnek be az indexbe.
Mit tegyél:
- Futtass teljes bejárást (Screaming Frog, Sitebulb vagy hasonló), és nézd meg a mélység szerinti eloszlást. Ha a URL-ek fele 5-ös mélységben vagy annál lejjebb van, ott dolgod van.
- Vesd össze a bejárás eredményét a sitemappal. Ami a sitemapben van, de a bejárásban nem jött elő, az árva oldal.
- Építs hub oldalakat. Egy jól felépített kategória- vagy tématerelő oldal tíz mélyen fekvő aloldalt hoz fel két kattintásnyira.
- A paginációt tartsd bejárhatónak, valódi linkekkel. A csak JavaScripttel betöltődő végtelen görgetés mögé a robot nem feltétlenül jut el.
- Használj kontextuális linkeket a szövegtörzsben. A minden oldalon megjelenő láblécmenü kevesebb megkülönböztető információt hordoz, mint egy cikkbe ágyazott, releváns link.
Mit mutat meg a naplófájl, amit a Search Console nem?
Rövid válasz: azt, hogy pontosan melyik URL-t, mikor, milyen státuszkóddal és milyen gyakran kérte le a robot. A Search Console összesített, a napló tételes.
A naplófájlt a tárhelyszolgáltatói felületen (cPanel, ispmanager, Plesk) találod nyers hozzáférési napló néven, vagy a szerveren az Nginx, illetve Apache access log fájljában. Kérj hozzáférést, ha nincs, mert enélkül csak találgatsz.
Első lépésként ellenőrizd, hogy valódi-e a bot. Hivatalosan igazolt: a Google azt javasolja, hogy fordított DNS-lekérdezéssel ellenőrizd az IP-címet, majd az így kapott hosztnevet egyenes lekérdezéssel vezesd vissza ugyanarra az IP-re. A valódi Googlebot hosztneve a googlebot.com vagy a google.com domainbe esik. Emellett a Google közzéteszi a robotok IP-tartományait is JSON formátumban.
Néhány alapparancs, amivel gyorsan képet kapsz:
- Mely URL-eket kérte a legtöbbször:
grep Googlebot access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30 - Milyen státuszkódok jöttek vissza:
grep Googlebot access.log | awk '{print $9}' | sort | uniq -c | sort -rn - Mennyi paraméteres kérés volt:
grep Googlebot access.log | grep -c '?' - Napi bontás:
grep Googlebot access.log | awk '{print $4}' | cut -d: -f1 | uniq -c
Mit keress az eredményben:
- A lekérések eloszlását könyvtárak szerint. Ha a hitek 60 százaléka a keresési vagy szűrt oldalakra megy, megvan a szűk keresztmetszet.
- A 404-es és 301-es válaszok arányát. Tartósan magas átirányítási arány azt jelenti, hogy a belső linkjeid vagy a sitemap régi URL-eket tartalmaznak.
- Az 5xx hibákat. Ezek közvetlenül csökkentik a bejárási kapacitást.
- Az átlagos válaszidőt, ha a napló formátuma tartalmazza.
- Hogy a legfontosabb húsz oldaladat mikor kérte le utoljára a robot.
Saját tapasztalat: egy Debrecenben működő szakkereskedésnél a napló alapján az derült ki, hogy a bejárások jelentős része egy régen kikapcsolt, de linkelve maradt szűrőrendszerre ment. A belső linkek javítása után a friss termékoldalak érezhetően gyorsabban jelentek meg az indexben, bár ez önmagában nem garantál jobb helyezést.
Hogyan érinti mindez az AI-botokat?
Hivatalosan igazolt: az OpenAI, az Anthropic és több más szolgáltató saját, dokumentált user agent nevekkel dolgozik (például GPTBot, ClaudeBot, PerplexityBot), és mindegyik a robots.txt szabályait követi a saját dokumentációja szerint. A Google külön Google-Extended tokent ad, amellyel a generatív felhasználás szabályozható a normál keresési bejárás érintése nélkül.
Szakmai feltételezés: ezek a botok jelenleg kevésbé kifinomultan kezelik a kanonizálást és a paraméteres URL-eket, mint a Googlebot, ezért a rendetlen URL-szerkezet náluk még nagyobb pazarlást okozhat. Ha a naplóban azt látod, hogy egy AI-bot aránytalanul sok lekérést csinál, a robots.txt-ben megadható lassítás vagy célzott tiltás reális eszköz, de a következményét (kevesebb megjelenés az AI-válaszokban) mérlegelni kell.
Milyen sorrendben nyúlj hozzá?
- Nézd meg a Search Console Feltérképezési statisztikák és Oldalak jelentését, és állapítsd meg, van-e egyáltalán valós probléma.
- Futtass teljes bejárást saját eszközzel, és számold meg, hány URL létezik ténylegesen.
- Kérj naplófájlt legalább 30 napra, és ellenőrizd, mire megy el a lekérések többsége.
- Takarítsd a paraméteres és vékony URL-eket: előbb noindex, később robots.txt tiltás.
- Tisztítsd a sitemapot, bontsd típusonként, javítsd a lastmod logikát.
- Csökkentsd a kattintásmélységet, szüntesd meg az árva oldalakat.
- Négy-hat hét múlva ismételd meg a napló-ellenőrzést, és hasonlítsd össze az eloszlást.
A crawl budget kezelése nem varázslat, hanem karbantartás. Nem garantál jobb pozíciókat, de jó eséllyel elősegíti, hogy amit fontosnak tartasz, azt a robot is időben lássa.
Források és további olvasnivalók
- Google Search Central: Large site owner's guide to managing your crawl budget
- Google Search Central: Verifying Googlebot and other Google crawlers
- Google Search Central: Build and submit a sitemap
- Google Search Central: Introduction to robots.txt
- Google Search Central: Google crawlers and fetchers overview (Google-Extended)
- sitemaps.org protokoll-specifikáció
- OpenAI dokumentáció: GPTBot
- Anthropic dokumentáció: ClaudeBot és crawler-irányelvek
- Schema.org szótár
- W3C: HTTP státuszkódok és webes szabványok
- A crawl budget jellemzően tízezres URL-szám fölött, illetve gyorsan változó nagy készleteknél válik valós korláttá.
- A paraméteres, szűrt és duplikált URL-ek a bejárási kapacitás nagy részét elvihetik anélkül, hogy egyetlen új értékes oldal is bekerülne az indexbe.
- A sitemap csak 200-as státuszú, indexelhető, önmagára kanonizált URL-eket tartalmazzon, valós lastmod értékkel.
- A fontos oldalak ideális esetben három kattintáson belül elérhetők a nyitóoldalról, és nem maradnak árva oldalak a rendszerben.
- A szerver naplófájlja mutatja meg egyedül hitelesen, hogy a robot ténylegesen mit járt be, mikor és milyen státuszkóddal.
Gyakori kérdések
Hány oldal fölött kell foglalkozni a crawl budgettel?
A Google hivatalos útmutatója szerint néhány ezer URL alatt általában nincs vele teendő. A gyakorlatban akkor válik érdemi kérdéssé, ha az oldalad tízezres nagyságrendű bejárható URL-t termel, vagy ha nagy készleted naponta változik. Fontos, hogy a bejárható URL-ek száma sokszor jóval nagyobb, mint a valódi tartalmi oldalaké.
Elég, ha robots.txt-ben letiltom a felesleges oldalakat?
Nem mindig. Ha egy URL már indexelve van, a robots.txt tiltás után a Google nem tudja letölteni, így a noindex utasítást sem látja, és az URL bent maradhat az indexben tartalom nélkül. A helyes sorrend: előbb noindex, várj, amíg kiesik, és csak utána tiltsd a bejárást.
Honnan szerzem meg a naplófájlt, ha nem én üzemeltetem a szervert?
Kérd a tárhelyszolgáltatótól vagy a fejlesztőtől nyers hozzáférési napló (raw access log) néven. A legtöbb magyar tárhelyen a cPanel, ispmanager vagy Plesk felületen letölthető. Elég heti vagy havi bontásban, legalább 30 nap adata, hogy értelmes mintát láss.
Segít-e a crawl budget rendbetétele az AI-keresőkben való megjelenésben?
Közvetlen bizonyíték erre nincs, ez inkább szakmai feltételezés. Az viszont logikus, hogy ha a fontos oldalaid gyorsabban és megbízhatóbban bejárhatók, akkor a tartalmuk nagyobb eséllyel friss és pontos formában áll rendelkezésre bármely rendszer számára. Garanciát ez sem ad.
Mit jelent, ha a Search Console szerint sok az oldal a Felfedezve, jelenleg nincs indexelve kategóriában?
Ez azt jelenti, hogy a Google tud az URL-ről, de még nem töltötte le. Nagy oldalaknál ez gyakran bejárási kapacitás vagy alacsony észlelt érték kérdése. Ilyenkor érdemes megnézni, hogy nem felesleges, generált URL-ekről van-e szó, illetve hogy elég erős-e a belső linkelés az érintett oldalakra.
Hány URL legyen egy sitemap fájlban?
Legfeljebb 50 000 URL és tömörítetlenül legfeljebb 50 MB. E fölött sitemap indexet kell használni, amely több sitemap fájlra mutat. A gyakorlatban érdemes ennél kisebb, típus szerint bontott fájlokat használni, mert így a Search Console-ban külön látod az egyes tartalomtípusok indexelési arányát.
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.