Crawl budget: teljes útmutató

A crawl budget, magyarul feltérképezési keret, az a mennyiség, amennyi URL-t a Googlebot egy adott időszakban hajlandó és képes lekérni egy webhelyről. Két tényező határozza meg: a szerver terhelhetősége és a kereső érdeklődése a tartalom iránt. Főleg nagy vagy gyorsan változó webhelyeken számít, ahol a felesleges URL-ek elvonják a keretet a fontos oldalaktól.

Alapfogalmak

A kereső nem tud minden URL-t folyamatosan lekérni. Minden webhelynél mérlegel: mennyit bír el a szerver anélkül, hogy lelassulna, és mennyire érdemes a webhely oldalait gyakran felkeresni. A kettő együtt adja azt, amit a szakma crawl budgetnek nevez. A kifejezés nem egy számot jelöl, amelyet a Google kiosztana, hanem egy viselkedést: a kereső a webhelyen töltött idejét és kéréseit korlátozott erőforrásként kezeli.

A Google saját leírásában a feltérképezési keret két összetevőből áll. Az egyik a feltérképezési kapacitás korlátja: hány párhuzamos kapcsolatot nyithat a Googlebot, és mennyit várjon a kérések között, hogy ne terhelje túl a szervert. A másik a feltérképezési igény: mennyire akarja a kereső az adott URL-eket lekérni, attól függően, mennyire népszerűek, mennyire frissek, és mennyire tűnnek elavultnak az indexben tárolt változatok.

A legfontosabb fogalmak

Fogalom	Jelentés	Mitől függ
Feltérképezési kapacitás	Mennyi kérést bír el a szerver a kereső felől	Válaszidő, szerverhibák aránya, a webhely technikai állapota
Feltérképezési igény	Mennyire érdemes a kereső szerint az URL-eket lekérni	Népszerűség, frissülés, a webhely mérete és minősége
Crawl budget	A kettő együttes eredménye	Mindkét tényező
Felesleges URL-ek	Értéktelen vagy ismétlődő címek, amelyeket a kereső mégis lekér	Paraméterek, szűrők, végtelen terek, duplikátumok
Feltérképezés és indexelés	Két külön lépés: a lekérés még nem jelent indexelést	A tartalom minősége és az indexelési jelzések

Kinek számít a crawl budget?

A legtöbb webhelynek nem kell a crawl budget miatt aggódnia. Egy néhány száz vagy néhány ezer oldalas webhelyet a Google általában gond nélkül bejár. A Google maga is azt írja, hogy a téma elsősorban a nagyon nagy webhelyeket érinti, valamint azokat, amelyek tartalma nagyon gyakran változik. Kisebb webhelynél is érdemes a témával foglalkozni, ha a Search Console-ban sok olyan URL szerepel, amelyet a kereső felfedezett, de még nem térképezett fel, vagy ha a webhely technikai okokból rengeteg felesleges URL-t gyárt.

Mi nem crawl budget probléma?

Ha az oldal fel van térképezve, de nincs indexelve. Az indexelési döntés a tartalom minőségén és a jelzéseken múlik, nem a kereten.
Ha az oldal indexelve van, de rosszul rangsorol. A crawl budget nem rangsorolási tényező.
Ha egy új oldal pár nap alatt nem jelenik meg. Ez a normál működés része, nem feltétlenül keretprobléma.

A feltérképezés és az indexelés különbsége

A crawl budget körüli félreértések nagy része abból fakad, hogy a feltérképezést és az indexelést egy lépésnek tekintik. A feltérképezés azt jelenti, hogy a kereső lekéri az URL-t. Az indexelés azt, hogy a letöltött tartalmat feldolgozza, és eldönti, bekerüljön-e a találatok közé. Egy oldal feltérképezhető, de nem indexelhető, ha noindex van rajta, vagy ha a kereső értéktelennek ítéli. A crawl budget csak az első lépésre hat. Ha egy oldal le van töltve, de nem került be az indexbe, a keret bővítése nem segít, a tartalmon vagy a jelzéseken kell dolgozni.

Hogyan működik?

A Googlebot a webhelyről ismert URL-ek listájából dolgozik. Ezek a címek belső és külső linkekből, sitemapokból és korábbi feltérképezésekből származnak. A kereső rangsorolja a listát: melyik URL-t kérje le először, melyiket gyakrabban, melyiket ritkábban. Közben figyeli a szerver válaszait. Ha a válaszok gyorsak és hibamentesek, a kapacitás korlátja feljebb mehet. Ha a szerver lassul, vagy 5xx hibákat ad, a Googlebot visszafogja a tempót.

A kapacitás oldal

A kapacitás a szerver egészségén múlik. Egy gyors, stabil szerver több kérést bír el, ezért a kereső is többet küldhet. A lassú válaszidő és a gyakori szerverhiba az ellenkező irányba hat. A Google ezt automatikusan szabályozza: nem kell külön beállítás ahhoz, hogy a kereső lassítson, ha a szerver nehezen bírja. Fontos tudni, hogy a Google a robots.txt crawl-delay utasítását nem veszi figyelembe, ezért a tempót nem ezzel lehet befolyásolni.

Az igény oldal

Az igény a tartalomtól függ. A népszerű, sok linkkel rendelkező oldalakat a kereső gyakrabban keresi fel. A gyakran frissülő tartalmat is sűrűbben ellenőrzi, hogy az index ne legyen elavult. A felesleges URL-ek az igény oldalon okoznak kárt: ha a webhely ezerszámra kínál ismétlődő vagy értéktelen címeket, a kereső ezekre is kéréseket fordít, és a fontos oldalakra kevesebb jut.

Mi pazarolja a keretet?

Szűrős navigáció. Szín, méret, ár és márka szerinti szűrők kombinációi, amelyek mindegyike külön URL-t kap.
URL-paraméterek. Követőkódok, munkamenet-azonosítók, rendezési paraméterek, amelyek ugyanazt a tartalmat több címen teszik elérhetővé.
Végtelen terek. Naptárak, amelyek a végtelenségig lapozhatók, vagy relatív linkek, amelyek egyre hosszabb URL-eket generálnak.
Soft 404 és hibás oldalak. A kereső csak letöltés után tudja meg, hogy értéktelenek.
Átirányítási láncok. Minden közbenső lépés egy újabb kérés.
Duplikált tartalom. Ugyanaz az oldal több formában, például http és https, perjellel és anélkül.

Kidolgozott példa: a szűrőkombinációk ára

Egy ruházati webáruház kategóriaoldalán öt szűrő volt, mindegyik több értékkel, és minden kombináció külön, linkelt URL-t kapott. A szűrők tetszőleges sorrendben is követhették egymást, így ugyanaz a tartalom több címen is elérhető lett. A Search Console feltérképezési statisztikái szerint a Googlebot kéréseinek nagy része ezekre a szűrőoldalakra ment, miközben az új termékek oldalai lassan jelentek meg a keresőben. A csapat eldöntötte, mely szűrőknek van keresési értéke, például márka és kategória együtt, és ezeket indexelhető, statikus URL-en hagyta. A többi kombinációt robots.txt-vel kizárta a feltérképezésből, és a linkjeiket úgy alakította át, hogy ne generáljanak új, feltérképezhető címeket.

A JavaScript és a renderelés költsége

A JavaScripttel megjelenített oldalak külön terhet jelentenek. A kereső ilyenkor nemcsak a HTML-t kéri le, hanem a szkripteket és az adatokat szolgáltató végpontokat is, és ezek mind kérések. Ha egy oldal tartalma sok külön erőforrásból áll össze, egyetlen oldal megjelenítése is több lekéréssel jár. A szerveroldali vagy előre renderelt HTML ezt csökkenti, mert a lényegi tartalom már az első válaszban benne van.

Fő módszerek

A crawl budget optimalizálása két irányban halad: több kapacitás és kevesebb pazarlás. A gyakorlatban a pazarlás csökkentése hozza a nagyobb eredményt, mert a legtöbb nagy webhelyen a probléma nem az, hogy a kereső keveset kér le, hanem hogy rossz URL-eket kér le.

1. A felesleges URL-ek kizárása

Ami nem kell a keresőnek, azt ne is kérje le. A robots.txt a feltérképezést tiltja, ezért a keret szempontjából ez a leghatékonyabb eszköz. Fontos különbség: a noindex nem takarít meg feltérképezést, hiszen a kereső csak úgy látja a noindexet, ha lekéri az oldalt. A canonical sem tiltja a lekérést, csak jelzi, melyik változat az elsődleges. A keret szempontjából tehát a robots.txt és a linkek átalakítása a hatékony, a noindex és a canonical az indexelést szabályozza.

2. A szerver gyorsítása

A gyorsabb válaszidő több kérést tesz lehetővé ugyanakkora terhelés mellett. A gyorsítótárazás, a lassú lekérdezések javítása és a szerverhibák megszüntetése mind a kapacitást növeli. Ha a Googlebot kéréseire 5xx hibák érkeznek, a kereső automatikusan lassít, ezért ezek megszüntetése a keret szempontjából is elsődleges.

3. Tiszta belső linkelés

A belső linkek mutatják meg a keresőnek, mely oldalak fontosak. Ha a fontos oldalak kevés kattintásra vannak a főoldaltól, és sok belső link mutat rájuk, a kereső gyakrabban keresi fel őket. A belső linkek közvetlenül a végső, 200-as kódú URL-re mutassanak, ne átirányításra vagy hibaoldalra.

4. Pontos sitemap

Az XML sitemap csak indexelhető, 200-as kódú, elsődleges URL-eket tartalmazzon. A lastmod mező akkor hasznos, ha valódi tartalmi változást jelez. Ha minden URL-nél folyamatosan frissül a dátum, a kereső idővel figyelmen kívül hagyhatja.

5. Megszűnt oldalak helyes kódja

A megszűnt tartalom 404-et vagy 410-et adjon, esetleg 301-et egy releváns utódra. A soft 404 és a hosszú átirányítási lánc mind extra kéréseket jelent.

Döntési szabály: melyik eszköz mire való?

Cél	Eszköz	Takarít meg feltérképezést?
Az URL-t a kereső ne kérje le	robots.txt Disallow	Igen
Az URL ne kerüljön az indexbe	noindex	Nem, a kereső lekéri, hogy lássa
Duplikátumok közül az egyik legyen elsődleges	canonical	Közvetlenül nem
Az URL ne is jöjjön létre	A linkek és a sablon átalakítása	Igen, a leghatékonyabb
A megszűnt oldal kikerüljön	404 vagy 410	Idővel ritkul a lekérés

Kidolgozott példa: prioritási sorrend egy nagy webhelyen

Egy nagy tartalmi webhely csapata korlátozott fejlesztői idővel dolgozott, ezért sorrendet kellett felállítania. Az első lépés a szerverhibák megszüntetése volt, mert ezek a kapacitást csökkentik, és a kereső automatikusan lassít tőlük. A második a legnagyobb pazarlási forrás, egy végtelenül lapozható archívumnaptár kizárása. A harmadik a belső linkek javítása, hogy ne átirányításokra mutassanak. A negyedik a sitemap tisztítása. A sorrend alapja az volt, hogy melyik lépés érinti a legtöbb kérést a legkisebb munkával. Minden lépés után megnézték a feltérképezési statisztikákat, hogy lássák a hatást, és csak utána léptek tovább.

Gyakori hibák

A crawl budget körüli hibák egy része abból fakad, hogy a témát túlbecsülik, a másik része abból, hogy rossz eszközt választanak. Kis webhelyen fölösleges vele sok időt tölteni, nagy webhelyen pedig a legnagyobb kárt a rossz eszközválasztás okozza.

Tipikus hibák

A robots.txt és a noindex együttes használata. Ha egy URL tiltva van a robots.txt-ben, a kereső nem látja rajta a noindexet. Ha a cél az indexből való eltávolítás, először a noindexnek kell hatnia, és csak utána jöhet a tiltás.
Fontos erőforrások tiltása. Ha a CSS- és JavaScript-fájlok tiltva vannak, a kereső nem tudja helyesen renderelni az oldalt.
A crawl-delay használata a Google lassítására. A Google ezt nem veszi figyelembe.
Minden szűrő indexelhetővé tétele. A szűrőkombinációk száma gyorsan nő, és a legtöbbnek nincs keresési értéke.
Hibás lastmod a sitemapban. Ha minden nap minden URL frissnek látszik, a jelzés elveszíti az értékét.
Kis webhelyen crawl budgetre fogni mindent. Ha egy kisebb webhely oldala nem indexelődik, az ok általában a tartalomban vagy az indexelési jelzésekben van.

Tévhit: több feltérképezés, jobb helyezés

A feltérképezés gyakorisága nem rangsorolási tényező. Ha a kereső többször kér le egy oldalt, attól nem kerül előrébb. A több feltérképezés annyit jelent, hogy a kereső hamarabb észreveszi a változásokat. Ez fontos lehet egy hírportálnak vagy egy nagy webáruháznak, de önmagában nem javítja a helyezést.

Ellenpélda: amikor a tiltás árt

Egy webhely a crawl budget javítása érdekében a robots.txt-ben tiltotta az összes paraméteres URL-t. Csakhogy a lapozás is paraméterrel működött, így a kereső nem jutott el a kategóriák második és további oldalain található termékekhez. Az eredmény az lett, hogy a mélyebb termékek ritkábban kerültek feltérképezésre. A tiltást szűkíteni kellett: csak a rendezési és követő paraméterek maradtak tiltva, a lapozás nem.

Tévhit: a noindex megspórolja a feltérképezést

Gyakran hallani, hogy a felesleges oldalakat elég noindexszel ellátni, és a kereső többé nem pazarol rájuk időt. Ez csak részben igaz. A noindexes oldalt a kereső idővel ritkábban kéri le, de ahhoz, hogy a noindexet egyáltalán lássa, le kell töltenie. Ha a cél a feltérképezés csökkentése, a robots.txt, a linkek átalakítása vagy az URL-ek megszüntetése a hatékonyabb út. A noindex az indexet tisztítja, nem a keretet.

Tévhit: a sitemap garantálja a feltérképezést

A sitemap segít a keresőnek felfedezni az URL-eket, de nem kötelezi arra, hogy mindet lekérje. Ha a webhely tele van felesleges URL-ekkel, vagy a szerver lassú, a sitemapban szereplő oldalak is várhatnak. A sitemap a jó belső linkelés és a tiszta URL-szerkezet kiegészítője, nem pótléka.

Mérés

A crawl budget mérése nem egyetlen számról szól, hanem arról, hová megy a kereső figyelme. A kérdés mindig az: a Googlebot a fontos oldalakra fordítja-e a kéréseit, és a változások időben eljutnak-e az indexbe.

Search Console feltérképezési statisztikák

A Search Console beállításai között elérhető feltérképezési statisztikák jelentés mutatja a kérések számát, a letöltött adatmennyiséget és az átlagos válaszidőt. A kéréseket válaszkód, fájltípus, cél és Googlebot-típus szerint is bontja. Innen kiderül, milyen arányban kap a kereső 200-as, átirányító vagy hibás választ, és hogy a gazdagép állapota rendben van-e. Az oldal-indexelési jelentésben a felfedezett, de még fel nem térképezett URL-ek sora is fontos jelzés.

Szervernaplók

A leghitelesebb forrás a szerver hozzáférési naplója. Ebből pontosan látszik, mely URL-eket kérte le a Googlebot, milyen gyakran, és milyen kódot kapott. A naplóelemzéssel kideríthető, hogy a kérések mekkora része megy felesleges URL-ekre, és mely fontos oldalakat nem keresett fel a kereső hosszabb ideje. A Googlebot kéréseit érdemes ellenőrizni, mert a felhasználói ügynököt más robotok is utánozhatják.

Ellenőrzőlista

Ellenőrzés	Mit nézel	Jó jel
Kérések megoszlása	Válaszkódok aránya a feltérképezési statisztikákban	A kérések többsége 200-as oldalra megy
Válaszidő	Átlagos válaszidő alakulása	Stabil, nem romló
Gazdagép állapota	robots.txt, DNS, szerverkapcsolat	Nincs jelentős probléma
Naplóelemzés	Felesleges URL-ek aránya a Googlebot kéréseiben	Kicsi, és csökken
Fontos oldalak	Mikor kérte le őket utoljára a kereső	Rendszeresen
Indexelési jelentés	Felfedezett, de nem feltérképezett URL-ek	Nem nő tartósan

Kidolgozott példa: naplóelemzés egy hirdetési portálon

Egy hirdetési portál azt tapasztalta, hogy az új hirdetések lassan jelennek meg a keresőben. A naplóelemzés megmutatta, hogy a Googlebot kéréseinek jelentős része régi, lejárt hirdetésekre ment, amelyek 200-as kóddal „a hirdetés lejárt" szöveget mutattak, valamint rendezési paraméterekkel ellátott listaoldalakra. A lejárt hirdetések 410-et kaptak, a rendezési paramétereket a robots.txt kizárta, az új hirdetések pedig bekerültek egy külön, gyakran frissülő sitemapba. A következő hetekben a feltérképezési statisztikákban a 200-as válaszok aránya nőtt, és a naplóban az új hirdetések hamarabb jelentek meg a Googlebot kérései között.

Mérési ritmus és küszöbök

A crawl budget mérésének nincs általános küszöbszáma, mert minden webhely más méretű és más ütemben változik. A viszonyítási alap a saját webhely korábbi állapota. Rögzítsd a kiinduló helyzetet: a kérések számát, a válaszkódok megoszlását, az átlagos válaszidőt és a felesleges URL-ek arányát a naplóban. Minden nagyobb változtatás után hasonlítsd össze ezekkel. Nagy webhelyen havonta, kisebben negyedévente elég átnézni a feltérképezési statisztikákat, változtatás után viszont néhány hétig sűrűbben érdemes figyelni.

Ha a mérés azt mutatja, hogy a kereső a fontos oldalakat rendszeresen felkeresi, az új tartalom időben megjelenik, és a kérések többsége értékes URL-re megy, akkor a crawl budget nem szűk keresztmetszet. Ilyenkor a figyelmet érdemes a tartalomra és az indexelési jelzésekre fordítani.