Crawl budget jelentése és optimalizálása

Crawl budget jelentése és optimalizálása: hogyan segítheted a Google hatékony feltérképezését?

A crawl budget azt mutatja meg, hogy a Google milyen mértékben képes és hajlandó feltérképezni a weboldalad URL-jeit egy adott időszakban. A probléma általában nem az, hogy „elfogy” egy pontosan meghatározott keret, hanem az, hogy a Googlebot túl sok felesleges URL-re fordítja a figyelmét, miközben a valóban fontos oldalak lassabban kerülnek sorra.

Ez főként nagyobb weboldalaknál, webáruházaknál és több ezer vagy tízezer URL-t tartalmazó portáloknál válhat komoly technikai SEO-kérdéssé. Egy rosszul beállított szűrőrendszer például néhány száz termékből is több ezer paraméteres URL-t hozhat létre. Ehhez jöhetnek a duplikált oldalak, átirányítások, belső keresési találatok, hibás URL-ek vagy különböző rendezési változatok.

A Googlebot ezekkel az URL-ekkel is találkozhat. Minél nagyobb és összetettebb egy webhely, annál fontosabb, hogy a keresőrobot számára egyértelmű legyen, mely oldalak érdemelnek elsősorban figyelmet.

Ugyanakkor a crawl budget körül sok tévhit él. Ha van egy 200 oldalas szolgáltatói honlapod, nem kell mindenáron „crawl budgetet növelned”. Ilyen méretnél sokkal valószínűbb, hogy az indexelési problémák hátterében hibás belső linkelés, gyenge tartalom, rossz canonical beállítás, noindex utasítás vagy más technikai probléma áll.

Egy több tízezer termékes webáruháznál viszont már egészen más a helyzet. Ha a szín, méret, ár, márka, készlet és rendezés kombinációi tömegesen hoznak létre új URL-eket, a Googlebotnak hatalmas URL-térrel kell megbirkóznia. Ilyenkor nem feltétlenül több crawlingra van szükséged, hanem hatékonyabb crawlingra.

Ebben az útmutatóban megmutatom, mit jelent pontosan a crawl budget, hogyan működik a Google feltérképezése, milyen technikai hibák pazarolhatják a feltérképezési erőforrásokat, és hogyan optimalizálhatod a weboldaladat úgy, hogy a Google könnyebben eljusson a valóban fontos tartalmaidhoz. Megnézzük többek között az XML sitemap, a robots.txt, a belső linkelés, a canonical címkék, az URL-paraméterek, a szerver teljesítménye és a Google Search Console szerepét is.

Mit jelent a crawl budget, hogyan működik a Google feltérképezése, és mikor kell optimalizálnod? Gyakorlati útmutató technikai SEO-hoz, hibákhoz és megoldásokhoz.

Tartalomjegyzék

1. Mit jelent a crawl budget?
2. Miért fontos a crawl budget SEO szempontból?
3. Hogyan működik a Google feltérképezése?
4. Miből áll össze egy weboldal crawl budgetje?
5. Minden weboldalnál fontos a crawl budget optimalizálása?
6. Hogyan állapíthatod meg, hogy crawl budget problémád van?
7. Hol ellenőrizheted, hogyan térképezi fel a Google a weboldaladat?
8. Hogyan befolyásolja a szerver teljesítménye a crawl budgetet?
9. Hogyan pazarolhatják a hibás URL-ek a feltérképezési erőforrásokat?
10. Hogyan hatnak az átirányítások és átirányítási láncok a feltérképezésre?
11. Hogyan befolyásolja a duplikált tartalom a crawl budgetet?
12. Miért okozhatnak problémát a paraméteres és szűrt URL-ek?
13. Hogyan kezeld a végtelen URL-tereket és a faceted navigationt?
14. Hogyan segíti a robots.txt a crawl budget optimalizálását?
15. Mikor használj noindexet, és mikor robots.txt tiltást?
16. Hogyan segíti az XML sitemap a fontos URL-ek feltérképezését?
17. Hogyan befolyásolja a belső linkelés a crawl budgetet?
18. Miért fontos az árva oldalak megszüntetése?
19. Hogyan hatnak a 404-es és soft 404-es oldalak a feltérképezésre?
20. Hogyan befolyásolja a JavaScript a Google feltérképezését?
21. Hogyan optimalizáld egy webáruház crawl budgetjét?
22. Hogyan optimalizáld egy nagy tartalmi weboldal crawl budgetjét?
23. Milyen crawl budget hibákat érdemes elkerülni?
24. Hogyan készíts crawl budget auditot?
25. Hogyan mérheted a crawl budget optimalizálás eredményét?
26. GYIK – gyakori kérdések a crawl budgetről

Mit jelent a crawl budget?

A crawl budget, magyarul feltérképezési keret azt írja le, hogy a Googlebot egy adott időszakban mekkora feltérképezési erőforrást fordít a weboldalad URL-jeire. Nem egy fix napi URL-számról van szó: a Google több tényező alapján dönti el, milyen intenzíven és milyen gyakran térképezi fel a webhelyedet.

Amikor a Google egy weboldalt vizsgál, a keresőrobotja, a Googlebot URL-eket fedez fel, letölti az oldalak tartalmát, követi a linkeket, majd az összegyűjtött információkat továbbítja feldolgozásra. Ezt nevezzük crawlingnak, vagyis feltérképezésnek.

Fontos különbséget tenni a feltérképezés és az indexelés között. Attól, hogy a Googlebot meglátogatott egy URL-t, az oldal még nem kerül automatikusan a Google indexébe. A feltérképezés után a Google feldolgozza a tartalmat, értékeli többek között az oldal indexelhetőségét, canonical jelzéseit és a tartalom jellemzőit, majd eldönti, hogy bekerülhet-e az indexbe.

Mit jelent a crawl budget a gyakorlatban?

Képzelj el egy nagy webáruházat 20 000 valódi termék- és kategóriaoldallal. Első látásra azt gondolhatnád, hogy a Googlebotnak ezt a 20 000 URL-t kell kezelnie.

A webáruház azonban lehetővé teszi a termékek ár, márka, méret, szín, készlet és népszerűség szerinti szűrését és rendezését. Ha ezek a beállítások külön URL-eket generálnak, a 20 000 értékes oldal mellett akár nagyságrendekkel több paraméteres URL is létrejöhet.

A Googlebot ezek egy részét szintén felfedezheti.

Így ahelyett, hogy elsősorban a fontos termékeket és kategóriákat térképezné fel, időt és erőforrást fordíthat például ilyen URL-változatokra:

/cipok/?szin=fekete&meret=39&rendezes=ar

/cipok/?meret=39&szin=fekete&rendezes=ar

Ha a két URL lényegében ugyanazt a tartalmat mutatja, SEO szempontból könnyen felesleges URL-tér keletkezhet.

A crawl budget optimalizálásának ezért nem az a célja, hogy a Googlebot egyszerűen minél több URL-t látogasson meg, hanem az, hogy a feltérképezési erőforrások minél nagyobb része a valóban fontos oldalakra jusson.

Miből áll össze a crawl budget?

A Google a crawl budget működésének magyarázatakor két különösen fontos tényezőt különít el: a crawl capacity limitet és a crawl demandet.

A crawl capacity limit leegyszerűsítve azt jelzi, hogy a Google milyen intenzíven tudja feltérképezni a webhelyet anélkül, hogy problémát okozna a szervernek. Ha a szerver gyorsan és stabilan válaszol, az kedvezőbb helyzetet teremthet. Ha viszont rendszeresen időtúllépések vagy 5xx szerverhibák jelentkeznek, a Google visszafoghatja a crawling intenzitását.

A crawl demand ezzel szemben azt fejezi ki, hogy mekkora igény van az adott URL-ek feltérképezésére vagy újbóli feltérképezésére. Nem minden oldal változik ugyanolyan gyakran, és nem minden URL egyformán fontos a kereső számára.

Egy naponta frissülő kereskedelmi oldal, egy rendszeresen bővülő SEO-portál és egy évek óta változatlan bemutatkozó oldal ezért eltérő feltérképezési mintázatot mutathat.

Fogalom	Mit jelent?
Crawling	A keresőrobot felfedezi és lekéri az URL-t
Indexing	A Google feldolgozza az oldalt, és dönthet az indexeléséről
Crawl capacity limit	Mekkora crawlingot képes elviselni a webhely
Crawl demand	Mennyire indokolt az adott URL-ek feltérképezése
Crawl budget	A webhelyre fordított tényleges feltérképezési kapacitás és igény eredője

A crawl budget nem egyenlő az indexeléssel

Ezt azért fontos hangsúlyozni, mert gyakori SEO-hiba a két folyamat összekeverése.

Ha egy oldal nincs indexelve, abból önmagában még nem következik, hogy crawl budget problémád van.

Előfordulhat például, hogy a Google már feltérképezte az oldalt, de nem választotta indexelésre. Ennek hátterében állhat duplikáció, canonical probléma, technikai indexelési korlátozás vagy az is, hogy a Google más URL-t tekint megfelelőbb reprezentációnak.

Ezért amikor indexelési problémát vizsgálsz, először azt kell kiderítened, hogy a Google nem találja meg az URL-t, nem térképezi fel megfelelően, vagy feltérképezi, de nem indexeli. Csak ezután érdemes eldönteni, hogy valóban a crawl budgettel kell-e foglalkoznod.

Miért fontos a crawl budget SEO szempontból?

A crawl budget azért fontos SEO szempontból, mert ha a Googlebot túl sok felesleges URL feltérképezésére fordít erőforrást, a fontos új vagy frissített oldalak felfedezése és újbóli feltérképezése kevésbé lehet hatékony. A cél tehát nem a minél nagyobb crawl budget, hanem az, hogy a Google elsősorban az értékes URL-ekre fordítsa a figyelmét.

A crawl budget nem közvetlen rangsorolási tényező. Attól, hogy a Googlebot gyakrabban látogat meg egy oldalt, az még nem kerül automatikusan jobb pozícióba. A feltérképezés azonban a keresőben való megjelenés egyik alapvető előfeltétele: a Google-nek először fel kell fedeznie és fel kell dolgoznia az URL-t ahhoz, hogy az oldal változásait figyelembe vehesse.

Egy kisebb, néhány száz URL-ből álló szolgáltatói weboldalon ez általában nem jelent komoly problémát. Ha például egy villanyszerelő webhelyén 80–100 szolgáltatási oldal és blogbejegyzés található, a Google számára viszonylag egyszerű a webhely bejárása.

Egy 50 000 termékes webáruháznál azonban egészen más helyzet alakulhat ki. A termékszűrők, rendezési lehetőségek, keresési találatok és URL-paraméterek miatt a ténylegesen felfedezhető URL-ek száma sokszorosa lehet a valódi termékoldalak számának.

Befolyásolja-e közvetlenül a crawl budget a Google-helyezéseket?

Nem, a crawl budget önmagában nem olyan rangsorolási faktor, amelynek növelésével jobb helyezéseket szerezhetsz. A SEO-hatása elsősorban abban jelentkezik, hogy a Google mennyire hatékonyan fedezi fel és térképezi újra a fontos tartalmaidat.

Tegyük fel, hogy egy klímákkal foglalkozó webáruházban megváltozik 500 termék ára, 100 új termék kerül fel, és több kategória tartalmát is frissíted. Fontos, hogy a Google ezeket a változásokat észszerű időn belül érzékelhesse.

Ha közben a Googlebot több tízezer értéktelen rendezési és szűrési URL-t is rendszeresen bejár, a webhely feltérképezése kevésbé hatékony lehet.

A crawl budget optimalizálás ezért valójában priorizálási feladat.

Azt szeretnéd elérni, hogy a keresőrobot könnyen megtalálja:

• az új oldalakat,
• a frissített tartalmakat,
• a fontos kategóriákat,
• a termékoldalakat,
• a stratégiai SEO landing oldalakat.

Ezzel szemben ne generálj számára szükségtelenül hatalmas mennyiségű alacsony értékű URL-t.

Mi történik, ha a Google felesleges URL-eket térképez fel?

A problémát elsősorban az jelenti, ha a webhely technikai felépítése nagyon sok olyan crawlolható URL-t hoz létre, amelyek nem képviselnek önálló keresési értéket.

Tipikus példa egy menyasszonyi ruhákat értékesítő webáruház. Tegyük fel, hogy 1500 ruhához különböző szűrők kapcsolódnak:

• fazon,
• szín,
• méret,
• kollekció,
• ár,
• anyag,
• rendezési sorrend.

Ha minden kombináció külön URL-t generál, a Googlebot számára az 1500 termék mellett rendkívül nagy URL-tér nyílhat meg.

A probléma nem az, hogy létezik szűrés. A felhasználók számára ez kifejezetten hasznos. SEO szempontból azt kell eldöntened, mely szűrt oldalak rendelkeznek önálló keresési értékkel, és melyek pusztán technikai URL-változatok.

Például a „csipkés menyasszonyi ruhák” lehet értékes kategóriaoldal, míg az ár szerint növekvő sorrendben megjelenített ugyanazon terméklista valószínűleg nem igényel külön keresőbeli jelenlétet.

Mikor válik igazán fontossá a crawl budget?

Minél nagyobb és technikailag összetettebb a webhely, annál nagyobb jelentősége lehet a crawl budget tudatos kezelésének.

Különösen érdemes foglalkoznod vele, ha több tízezer vagy még több URL-ed van, gyakran változik a tartalom, sok paraméteres URL keletkezik, vagy azt tapasztalod, hogy fontos oldalak feltérképezése rendszeresen késik.

Webhely típusa	Crawl budget jelentősége	Tipikus probléma
Kis céges honlap	Általában alacsony	Inkább indexelési vagy belső linkelési hiba
Szakmai blog	Alacsony–közepes	Címkék, archívumok, gyenge belső linkelés
Nagy tartalmi portál	Közepes–magas	Sok régi és alacsony értékű URL
Webáruház	Magas lehet	Szűrők, rendezések, paraméterek
Piactér	Nagyon magas lehet	Folyamatosan változó, hatalmas URL-készlet

A legfontosabb tehát, hogy ne önmagában a crawl budget növelését tekintsd SEO-célnak. Sokkal értékesebb, ha rendbe teszed az URL-struktúrát, a belső linkelést, az XML sitemapet, a hibás oldalakat és a szerver teljesítményét.

Egy jól optimalizált webhelyen a Googlebotnak nem kell URL-ek százezrei között keresgélnie ahhoz, hogy megtalálja azt a néhány ezer oldalt, amely valóban fontos.

SEO szempontból a jó crawl budget optimalizálás tehát nem több feltérképezést, hanem jobb feltérképezést jelent.

Hogyan működik a Google feltérképezése?

A Google feltérképezése során a Googlebot URL-eket fedez fel, lekéri az oldalak tartalmát, követi a rajtuk található linkeket, majd az összegyűjtött információkat továbbítja feldolgozásra. A Google nem minden URL-t ugyanolyan gyakran térképez fel: a crawling intenzitását és gyakoriságát több technikai és keresőoldali tényező befolyásolja.

A folyamat leegyszerűsítve három nagy szakaszra bontható: felfedezés, feltérképezés és indexelés. Ezek egymáshoz kapcsolódnak, de nem ugyanazt jelentik.

A Google-nek először tudomást kell szereznie egy URL létezéséről. Ez történhet például egy belső linken, külső linken vagy XML sitemapen keresztül. Ezután a Googlebot meglátogathatja az URL-t, letöltheti annak tartalmát, majd a Google rendszerei feldolgozhatják az oldalt.

A crawling azonban nem jelent automatikus indexelést. A Google egy feltérképezett oldal esetében is dönthet úgy, hogy azt nem veszi fel az indexbe.

Hogyan találja meg a Google az új URL-eket?

A Google elsősorban linkeken és sitemapeken keresztül fedezi fel az új URL-eket, de korábban ismert URL-eket is rendszeresen újra meglátogathat.

A belső linkelés ezért technikai SEO szempontból is fontos. Ha például közzéteszel egy új cikket a „technikai SEO audit” témájában, majd belinkeled egy erős SEO-kategóriaoldalról és több kapcsolódó cikkből, a Googlebot számára több útvonalon is felfedezhetővé teszed.

Más a helyzet egy árva oldalnál, amelyre a webhelyeden egyetlen belső link sem mutat. Ha az URL szerepel az XML sitemapben, a Google így is megtalálhatja, de az oldal nem illeszkedik megfelelően a belső webhelystruktúrába.

A Google többek között az alábbi forrásokból találhat URL-eket:

• belső linkekből,
• más webhelyek külső linkjeiből,
• XML sitemapből,
• korábban már ismert URL-ekből,
• átirányítások céloldalaiból.

Ezért nem elég egyszerűen létrehozni egy oldalt. Gondoskodnod kell arról is, hogy logikusan kapcsolódjon a webhely többi tartalmához.

Mi történik, amikor a Googlebot meglátogat egy URL-t?

A Googlebot HTTP-kérést küld a szervernek, amely egy HTTP státuszkóddal és – ha elérhető – az oldal tartalmával válaszol. A válasz típusa meghatározza, hogy a keresőrobot milyen helyzettel találkozott.

Egy megfelelően működő oldal jellemzően 200-as HTTP státuszkódot ad vissza. Egy véglegesen áthelyezett URL például 301-es átirányítást használhat, egy megszűnt oldal pedig 404-es választ adhat.

HTTP státusz	Jelentés	Googlebot szempontjából
200	Az oldal elérhető	A tartalom feldolgozható
301	Végleges átirányítás	A bot követheti az új URL-t
302	Ideiglenes átirányítás	Az átirányítás feldolgozható
404	Az oldal nem található	Az URL idővel kieshet az indexből
410	A tartalom megszűnt	Egyértelmű jelzés a megszűnésről
5xx	Szerverhiba	Tartós probléma esetén visszafoghatja a crawlingot

A szerver teljesítménye ezért közvetlenül kapcsolódik a feltérképezéshez. Ha egy nagy kereskedelmi webhely gyorsan és stabilan szolgálja ki a Googlebot kéréseit, az egészen más technikai környezetet jelent, mint amikor rendszeresen timeout vagy 5xx szerverhiba történik.

Milyen gyakran térképez fel egy oldalt a Google?

Nincs olyan általános szabály, hogy a Google minden oldalt naponta, hetente vagy havonta egyszer feltérképez. Az egyes URL-ek crawl gyakorisága jelentősen eltérhet.

Gondolj egy kertészeti webáruházra. A készleten lévő növények ára, elérhetősége és kínálata rendszeresen változhat. Ezzel szemben a „Hogyan ültesd el helyesen a levendulát?” útmutató hónapokig változatlan maradhat.

A két URL esetében ezért nincs feltétlenül szükség ugyanolyan újracrawlolási gyakoriságra.

A Google azt is figyelembe veheti, hogy egy tartalom mennyire változik, milyen szerepet tölt be a webhelyen, és mennyire indokolt az újbóli feltérképezése.

Mi történik a feltérképezés után?

A crawling után a Google feldolgozhatja az oldal tartalmát, megvizsgálhatja többek között a szöveget, a fő tartalmi elemeket, a canonical jelzéseket és más technikai információkat, majd dönthet az indexelésről.

Ez egy nagyon fontos különbség.

A folyamat leegyszerűsítve:

URL felfedezése → crawling → feldolgozás/renderelés → indexelési döntés → lehetséges megjelenés a keresési találatok között

Ha tehát egy oldal nem jelenik meg a Google-ben, először azt kell kiderítened, a folyamat melyik pontján akad el.

Lehet, hogy a Google még nem fedezte fel. Lehet, hogy ismeri az URL-t, de még nem térképezte fel. Az is előfordulhat, hogy már feltérképezte, de nem választotta indexelésre.

Ezért crawl budget problémára sem érdemes automatikusan következtetned minden indexelési hiba esetén. A hatékony technikai SEO alapja annak megértése, hogy a felfedezés, a feltérképezés és az indexelés három különálló, bár szorosan összekapcsolódó folyamat.

Miből áll össze egy weboldal crawl budgetje?

Egy weboldal crawl budgetjét alapvetően két tényező együttes hatásával érdemes megérteni: a crawl capacity limit azt befolyásolja, hogy a Googlebot mennyi feltérképezést tud végezni a webhely túlterhelése nélkül, míg a crawl demand azt, hogy a Google mennyire tartja indokoltnak az URL-ek feltérképezését. A crawl budget tehát nem egy előre kiosztott, fix napi URL-keret.

A Google nem mondja azt egy webhelyre, hogy „ma pontosan 5000 URL-t térképezhetsz fel”. A crawling dinamikusan változhat a webhely technikai állapota, mérete, frissülése és a Google által érzékelt feltérképezési igény alapján.

Mit jelent a crawl capacity limit?

A crawl capacity limit azt mutatja meg, hogy a Googlebot milyen intenzitással képes feltérképezni a webhelyet anélkül, hogy túlterhelné annak szerverét.

A Google számára nem cél, hogy a crawling miatt egy webhely lelassuljon vagy elérhetetlenné váljon. Ha a szerver gyorsan és stabilan válaszol a kérésekre, több párhuzamos kapcsolatot is képes lehet megfelelően kiszolgálni.

Ha viszont a szerver válaszideje jelentősen romlik vagy szerverhibák jelennek meg, a Googlebot visszafoghatja a crawlingot.

Itt válik fontossá például:

• a megfelelő tárhely vagy szerverkapacitás,
• a gyors adatbázis,
• a szerveroldali gyorsítótárazás,
• a stabil rendelkezésre állás,
• az 5xx hibák megszüntetése,
• a túl hosszú válaszidők csökkentése.

Képzelj el egy nagy építőanyag-webáruházat 80 000 termékoldallal. Ha a szerver normál terhelés mellett gyors, de nagy látogatottság esetén rendszeresen 503-as hibákat ad, a Googlebot számára is azt jelezheti, hogy óvatosabban kell terhelnie a rendszert.

A gyors szerver tehát nem azért fontos, mert önmagában „SEO-pontokat” ad a crawl budgethez, hanem azért, mert nagyobb és stabilabb technikai kapacitást biztosít a Googlebot kiszolgálásához.

Mit jelent a crawl demand?

A crawl demand azt fejezi ki, hogy a Google mekkora igényt lát egy webhely URL-jeinek feltérképezésére vagy újbóli feltérképezésére. Attól, hogy a szerver technikailag hatalmas terhelést tudna kezelni, még nem következik, hogy a Googlebotnak szüksége is van ennyi crawlingra.

Ez a crawl budget egyik gyakran félreértett része.

Tegyük fel, hogy egy weboldal szervere akár napi több százezer Googlebot-kérést is problémamentesen kiszolgálna. Ha azonban az oldalon 3000, évek óta alig változó tartalom található, nincs feltétlenül értelme annak, hogy a Google folyamatosan újra lekérje mindegyiket.

Ezzel szemben egy nagy kereskedelmi oldal termékkészlete, árai és kategóriái rendszeresen változhatnak. Ilyenkor jóval több URL-nél lehet indokolt az újbóli crawling.

A crawl demandet többek között befolyásolhatja:

• az URL-ek érzékelt jelentősége,
• a tartalmak változásának gyakorisága,
• a korábban ismert URL-ek állapota,
• a webhelyen végrehajtott nagyobb változás.

Miért nem használja ki mindig a Google a teljes crawl kapacitást?

A magas crawl capacity nem jelenti azt, hogy a Googlebot automatikusan ki is használja a rendelkezésre álló kapacitást. Ehhez megfelelő crawl demandre is szükség van.

Egyszerűen megfogalmazva:

crawl capacity = mennyit tud biztonságosan crawlolni

crawl demand = mennyit érdemes crawlolni

A kettőt együtt kell vizsgálnod.

Tényező	Mit jelent?	Példa
Crawl capacity limit	Mekkora crawlingot képes biztonságosan kiszolgálni a webhely	Stabil, gyors szerver
Crawl demand	Mennyire indokolt az URL-ek crawlolása	Gyakran változó termékoldalak
Szerverválasz	Befolyásolhatja a crawl kapacitást	200 vagy 5xx válaszok
Tartalomfrissítés	Befolyásolhatja az újracrawlolás igényét	Naponta változó készlet
URL-készlet	Meghatározza, mennyi URL-lel találkozhat a bot	Termékek, kategóriák, paraméterek

Befolyásolja-e a webhely mérete a crawl budgetet?

A webhely mérete önmagában nem határozza meg a crawl budgetet, de minél több URL található egy webhelyen, annál fontosabbá válhat a feltérképezési erőforrások hatékony felhasználása.

Egy 150 oldalas klímaszerelői webhely és egy 300 000 URL-t tartalmazó webáruház technikai SEO-helyzete teljesen eltérő.

A kis webhelyen a Googlebotnak viszonylag kevés URL közül kell kiválasztania a fontos tartalmakat. A nagy webáruháznál viszont a valódi termék- és kategóriaoldalak mellett megjelenhetnek:

• szűrt URL-ek,
• rendezési URL-ek,
• belső keresési találatok,
• tracking paraméterek,
• lapozások,
• megszűnt termékek,
• duplikált URL-változatok.

Ilyenkor már nemcsak az számít, hogy hány értékes oldalad van, hanem az is, hány felesleges URL-t tud felfedezni a Googlebot.

Változhat-e a crawl budget idővel?

Igen. A crawl budget dinamikus, ezért a Googlebot feltérképezési aktivitása idővel növekedhet vagy csökkenhet.

Egy webhely teljes átalakítása vagy domainköltözése például jelentős változást hozhat az URL-készletben. Egy webáruházban több ezer új termék kerülhet fel néhány nap alatt, míg egy szezonális oldal az év bizonyos időszakaiban sokkal intenzívebben frissülhet.

A szerver állapota szintén változhat. Ha korábban rendszeresen hibákat adott, majd egy tárhelyváltás és technikai optimalizálás után stabilabbá válik, a Googlebot számára is megváltozik a feltérképezési környezet.

Ezért a crawl budgetet nem érdemes egyetlen számmal jellemezni vagy egyszer beállítandó SEO-paraméterként kezelni.

A legfontosabb feladatod az, hogy stabil technikai környezetet biztosíts, megszüntesd a feleslegesen generált URL-eket, és egyértelművé tedd, mely tartalmak fontosak. Így nem egyszerűen „nagyobb” crawl budgetet próbálsz elérni, hanem hatékonyabbá teszed a rendelkezésre álló feltérképezési erőforrások felhasználását.

Minden weboldalnál fontos a crawl budget optimalizálása?

Nem, a crawl budget optimalizálása nem minden weboldalnál kiemelt SEO-feladat. Egy kisebb, néhány száz vagy néhány ezer jól strukturált URL-ből álló honlapnál általában fontosabb az indexelhetőség, a tartalom minősége, a belső linkelés és a technikai hibák javítása.

A crawl budget főként akkor válik komoly kérdéssé, amikor a Googlebotnak nagyon sok URL közül kell megtalálnia a valóban értékes oldalakat. Ez különösen nagy webáruházaknál, piactereknél, apróhirdetési oldalakon és több tíz- vagy százezer URL-t tartalmazó portáloknál fordulhat elő.

Mikor nem kell különösebben foglalkoznod a crawl budgettel?

Ha viszonylag kevés indexelhető oldalad van, azok megfelelően belső linkeltek, a szerver stabil, és a Google rendszeresen megtalálja az új tartalmaidat, valószínűleg nincs szükséged külön crawl budget projektre.

Vegyünk például egy helyi villanyszerelő weboldalát, amelyen 15 szolgáltatási oldal, 20 települési landing oldal és 150 szakmai cikk található. Ez összesen kevesebb mint 200 értékes URL.

Ha ezek logikus menüből, kategóriákból és belső linkeken keresztül elérhetők, a Googlebot számára nem jelent különösebb kihívást a webhely feltérképezése.

Ebben az esetben sokkal fontosabb lehet például:

• a gyenge vagy egymással versengő tartalmak javítása,
• az árva oldalak megszüntetése,
• a hibás belső linkek javítása,
• az XML sitemap ellenőrzése,
• a megfelelő canonical beállítás,
• az indexelési problémák feltárása.

Gyakori hiba, hogy egy kis weboldal indexelési problémáját automatikusan crawl budget problémának tekintik. Ha a Google már feltérképezte az oldalt, de nem indexeli, akkor a crawl budget növelése önmagában nem fogja megoldani a helyzetet.

Milyen weboldalaknál válhat fontossá a crawl budget?

Elsősorban azoknál a webhelyeknél érdemes komolyan vizsgálni, ahol nagyon nagy vagy gyorsan változó URL-készletet kell a Google-nek feldolgoznia.

Tipikus példa egy nagy webáruház.

Tegyük fel, hogy egy kertészeti webshopban 40 000 termék található. A termékeket lehet növénytípus, szín, magasság, fényigény, ár, márka és készlet alapján szűrni.

Ha minden szűrési kombináció külön crawlolható URL-t hoz létre, a Googlebot nem 40 000 URL-lel, hanem akár ennek sokszorosával találkozhat.

Hasonló helyzet alakulhat ki:

• nagy ingatlanportálokon,
• álláskereső oldalakon,
• apróhirdetési webhelyeken,
• több százezer termékes webshopokban,
• nagy híroldalakon,
• fórumokon,
• nagy tudásbázisokon,
• dinamikusan generált adatbázis-oldalakon.

Webhely típusa	Crawl budget jelentősége	Mire figyelj?
50–200 oldalas céges honlap	Alacsony	Indexelhetőség, belső linkek
500–3000 oldalas blog	Általában alacsony	Kategóriák, címkék, archívumok
10 000+ oldalas portál	Közepes lehet	URL-struktúra, árva oldalak
Nagy webáruház	Magas lehet	Szűrők, paraméterek, termékváltozatok
Piactér, apróhirdetési oldal	Magas	Folyamatosan változó URL-készlet
Több százezer URL-es oldal	Kiemelten vizsgálandó	Crawl logok, hibák, URL-priorizálás

A táblázatban szereplő URL-számokat nem merev Google-határértékként, hanem gyakorlati támpontként érdemes kezelni. Egy rosszul felépített 5000 URL-es webhelyen is kialakulhat komoly technikai probléma, míg egy jól strukturált, jóval nagyobb oldalt a Google hatékonyan feltérképezhet.

Honnan tudhatod, hogy neked érdemes-e optimalizálnod?

Ne kizárólag az oldalaid számából indulj ki. A fontos kérdés az, hogy a Googlebot milyen URL-eket térképez fel, és közben megfelelően eljut-e a keresési szempontból értékes tartalmaidhoz.

Ha rendszeresen publikálsz új SEO-cikkeket, és azok gyorsan megjelennek a Google rendszerében, miközben nincs több tízezer technikai URL-ed, valószínűleg nincs komoly crawl budget problémád.

Más a helyzet, ha egy kereskedelmi oldalon azt látod, hogy a Googlebot folyamatosan különböző paraméteres, rendezési és szűrési URL-eket jár be, miközben új termékoldalak vagy fontos kategóriák feltérképezése késik.

Ilyenkor már érdemes megvizsgálni:

mit crawlol a Google, milyen gyakran crawlolja, és valóban azokat az URL-eket látogatja-e, amelyek SEO és üzleti szempontból fontosak.

Lehet káros a crawl budget túlzott optimalizálása?

Igen. Ha olyan webhelyen kezdesz agresszívan URL-eket blokkolni, ahol valójában nincs crawl budget probléma, könnyen többet árthatsz, mint amennyit javítasz.

Például egy hibás robots.txt szabállyal fontos kategóriák feltérképezését is megakadályozhatod. Ugyanez igaz akkor, ha automatikusan noindexre állítasz olyan oldalakat, amelyek valójában értékes organikus forgalmat hozhatnának.

Ezért nem az legyen az első kérdésed, hogy „hogyan csökkenthetem a Googlebot crawlingját?”, hanem az, hogy „van-e egyáltalán feltérképezési problémám?”

Ha egy kisebb honlapod van, a válasz gyakran az lesz, hogy nincs. Ha viszont több tízezer vagy százezer felfedezhető URL-lel dolgozol, akkor a crawl budget vizsgálata már a technikai SEO audit fontos része lehet.

A crawl budget optimalizálása tehát nem kötelező feladat minden weboldalon: ott válik igazán értékessé, ahol a webhely mérete vagy technikai működése miatt a Googlebotnak már komoly URL-mennyiséget kell hatékonyan kezelnie.

Hogyan állapíthatod meg, hogy crawl budget problémád van?

Akkor gyanakodhatsz crawl budget problémára, ha egy nagy vagy technikailag összetett webhelyen a Googlebot jelentős mennyiségű alacsony értékű URL-t térképez fel, miközben fontos új vagy frissített oldalak rendszeresen lassan kerülnek sorra. Egy-két nem indexelt oldal önmagában még nem bizonyít crawl budget problémát.

Az első feladat ezért annak elkülönítése, hogy feltérképezési vagy indexelési problémával állsz-e szemben. Ha a Google már meglátogatta az URL-t, de nem indexeli, akkor nem feltétlenül a crawl budgetnél kell keresned a hibát.

Milyen jelek utalhatnak crawl budget problémára?

A legfontosabb figyelmeztető jel, ha a Googlebot aktivitása és a webhely SEO-prioritásai látványosan eltérnek egymástól.

Például egy 100 000 termékes webáruházban azt tapasztalod, hogy az új termékoldalak feltérképezése lassú, miközben a szerverlogokban rengeteg ilyen URL jelenik meg:

?sort=price

?color=black

?view=grid

?page=

?utm_source=

Ez arra utalhat, hogy a webhely túl nagy felesleges URL-teret tesz elérhetővé a Googlebot számára.

További figyelmeztető jelek lehetnek:

• fontos új oldalak tartósan lassú felfedezése;
• frissített oldalak ritka újracrawlolása;
• nagyszámú paraméteres URL crawlolása;
• tömeges 3xx, 4xx vagy 5xx válaszok;
• rengeteg duplikált URL-változat;
• belső keresési oldalak intenzív crawlingja;
• hosszú átirányítási láncok;
• a Googlebot aktivitásának jelentős része üzletileg értéktelen URL-ekre jut.

Egyetlen jelből azonban ne vonj le messzemenő következtetést. A crawl budget problémát több adat együttes vizsgálatával érdemes azonosítani.

Mit nézz meg először a Google Search Console-ban?

A Google Search Console Feltérképezési statisztikák jelentése jó kiindulópont, mert megmutatja, hogyan változik a Googlebot aktivitása, milyen válaszokat kap a szervertől, és mennyi idő alatt tölti le az erőforrásokat.

Érdemes figyelned többek között:

Vizsgált adat	Mire utalhat?
Összes crawl-kérés	A Googlebot aktivitásának változására
Átlagos válaszidő	Szerveroldali teljesítményproblémára
5xx válaszok	Szerverhibára vagy túlterhelésre
404 válaszok	Hibás vagy megszűnt URL-ek crawlingjára
Átirányítások	Felesleges redirectekre vagy URL-változásokra
Crawl célja	Felfedezés és frissítés mintázatára
Googlebot típusa	Milyen crawler végzi a kéréseket

Ne kizárólag az összes crawl-kérés számát figyeld. A több crawling nem automatikusan jobb, a kevesebb pedig nem automatikusan rossz.

Ha például technikai tisztítás után jelentősen csökken a paraméteres URL-ek száma, az összes crawl-kérés is csökkenhet, miközben a fontos oldalak feltérképezése hatékonyabbá válik. Ez pozitív eredmény lehet.

Miért érdemes szerverlogokat is vizsgálnod?

Nagy webhely esetén a szerverlogok mutatják meg igazán pontosan, hogy a Googlebot milyen URL-eket kér le, milyen gyakran tér vissza hozzájuk, és milyen HTTP-választ kap.

Tegyük fel, hogy egy építőanyag-webáruházban 60 000 értékes termék- és kategóriaoldal található. A logelemzésből azonban kiderül, hogy a Googlebot kéréseinek jelentős része szűrési, rendezési és régi paraméteres URL-ekre érkezik.

Ez sokkal erősebb jelzés, mint pusztán az, hogy „kevésnek tűnik a crawl-kérések száma”.

A logok segítségével többek között azt vizsgálhatod:

• mely URL-eket crawlolja leggyakrabban a Googlebot;
• mely könyvtárak kapják a legtöbb botkérést;
• milyen HTTP státuszkódokat kap;
• milyen fontos oldalakra tér vissza ritkán;
• mennyi crawling jut paraméteres URL-ekre;
• vannak-e olyan URL-ek, amelyeket a Google folyamatosan újra próbál elérni.

Hogyan különböztesd meg a crawl és az indexelési problémát?

Ha a Google ismeri és feltérképezte az URL-t, de nem indexeli, akkor önmagában nem crawl budget problémáról beszélünk.

Például publikálsz egy új cikket a klíma karbantartásáról. A Search Console URL-ellenőrzése alapján a Google már feltérképezte, mégsem jelenik meg az indexben.

Ebben az esetben érdemes inkább megvizsgálni a tartalom egyediségét, a canonical beállítást, az indexelési utasításokat és az oldal általános minőségét.

Más a helyzet, ha egy nagy webáruház több ezer új termékoldalának jelentős részét a Google hosszú időn keresztül még fel sem térképezi, miközben hatalmas mennyiségű technikai URL-t jár be.

Ez már sokkal inkább indokolja a crawl budget és a teljes URL-struktúra részletes elemzését.

Milyen kérdések alapján dönthetsz?

Egy gyors ellenőrzéshez tedd fel magadnak a következő kérdéseket:

• Nagy, több tízezer URL-es webhelyem van?
• Rengeteg paraméteres vagy szűrt URL keletkezik?
• A Googlebot rendszeresen crawlol értéktelen URL-eket?
• Fontos új oldalak feltérképezése rendszeresen késik?
• Sok 5xx szerverhiba jelenik meg?
• Jelentős számú hibás belső link vagy redirectlánc található?
• A sitemap és a ténylegesen indexelhető URL-készlet jelentősen eltér egymástól?
• A logok alapján a Googlebot crawl aktivitása rosszul oszlik el?

Ha ezek közül több problémát egyszerre tapasztalsz, érdemes részletes crawl budget auditot végezned.

A lényeg azonban nem az, hogy megtalálj egy képzeletbeli „crawl budget számot”. Sokkal fontosabb annak megállapítása, hogy a Googlebot a rendelkezésére álló feltérképezési erőforrásokat a webhelyed valóban értékes URL-jeire fordítja-e.

Ha igen, valószínűleg nincs komoly crawl budget problémád. Ha viszont a crawling jelentős része technikai zajra, duplikációkra és értéktelen URL-változatokra megy el, miközben a fontos oldalak háttérbe szorulnak, akkor már indokolt az optimalizálás.

Hol ellenőrizheted, hogyan térképezi fel a Google a weboldaladat?

A Google feltérképezési aktivitását elsősorban a Google Search Console Feltérképezési statisztikák jelentésében ellenőrizheted, nagyobb webhelyeknél pedig érdemes szerverlog-elemzéssel kiegészíteni az adatokat. A kettő együtt mutatja meg igazán jól, hogy mennyit crawlol a Google, milyen válaszokat kap, és pontosan mely URL-ekre fordítja a figyelmét.

Mit mutat a Google Search Console Feltérképezési statisztikák jelentése?

A Feltérképezési statisztikák – Crawl Stats – segítségével áttekintheted a Googlebot webhelyeden végzett tevékenységét és a szerver válaszainak főbb jellemzőit.

A Search Console-ban többek között ellenőrizheted:

• az összes crawl-kérés számát;
• a letöltött adatmennyiséget;
• az átlagos válaszidőt;
• a HTTP-válaszkódok megoszlását;
• a fájltípusokat;
• a Googlebot típusát;
• a feltérképezés célját.

Az adatokat mindig összefüggéseikben vizsgáld. Ha például egyik napról a másikra csökken a crawl-kérések száma, az önmagában még nem jelent problémát.

Lehetséges, hogy előtte megszüntettél több ezer felesleges paraméteres URL-t, ezért a Googlebotnak egyszerűen kevesebb értéktelen URL-t kell bejárnia.

Miért fontos az átlagos válaszidő?

Az átlagos válaszidő megmutatja, milyen gyorsan reagál a szerver a Googlebot kéréseire, ezért jelentős technikai jelzőszám lehet a crawling vizsgálatakor.

Ha például egy nagy kereskedelmi webhely szervere normál esetben gyorsan válaszol, majd egy technikai probléma miatt jelentősen megnő a válaszidő, érdemes megvizsgálni a tárhelyet, az adatbázist, a cache működését és az esetleges túlterhelést.

Különösen figyelj arra, ha a magas válaszidővel együtt 5xx szerverhibák is megjelennek.

Search Console adat	Mit érdemes vizsgálnod?
Összes crawl-kérés	Jelentős növekedés vagy visszaesés
Letöltött adatmennyiség	Szokatlan változások
Átlagos válaszidő	Lassulás, szerverterhelés
200-as válaszok	Sikeresen elért erőforrások
3xx válaszok	Átirányítások mennyisége
404-es válaszok	Megszűnt vagy hibás URL-ek
5xx válaszok	Szerveroldali problémák
Crawl célja	Felfedezés vagy frissítés

Mit jelent a feltérképezés célja?

A Search Console azt is megmutathatja, hogy a Googlebot új URL-ek felfedezése vagy már ismert URL-ek frissítése miatt végzett crawlingot.

Ez különösen hasznos lehet egy gyorsan változó weboldalnál.

Ha például egy webáruházba rendszeresen több száz új termék kerül fel, fontos lehet megfigyelni, hogy a Google megfelelően felfedezi-e ezeket. Egy régebbi, stabil szakmai blognál ezzel szemben természetes lehet, hogy a crawling jelentős része már ismert oldalak újbóli ellenőrzéséhez kapcsolódik.

Mit tudsz ellenőrizni az URL-ellenőrző eszközzel?

Ha nem az egész webhely crawlingját, hanem egy konkrét oldal állapotát szeretnéd megvizsgálni, a Search Console URL-ellenőrző eszköze az egyik leghasznosabb kiindulópont.

Itt többek között ellenőrizheted, hogy a Google ismeri-e az URL-t, történt-e feltérképezés, melyik canonical URL-t kezeli a Google, illetve milyen indexelési állapotot lát.

Ez segít elkülöníteni két teljesen különböző problémát:

„A Google még nem térképezte fel az oldalt.”

és

„A Google feltérképezte, de nem indexelte az oldalt.”

A második esetben nem érdemes automatikusan crawl budget problémára következtetned.

Miért érdemes szerverlogokat elemezni?

A szerverlogokból URL-szinten láthatod, milyen kérések érkeznek a szerverhez, ezért nagy webhelyeken sokkal részletesebben elemezheted a Googlebot tényleges crawlingját.

Tegyük fel, hogy egy 80 000 termékes webáruház Search Console adatai alapján naponta jelentős Googlebot-aktivitást látsz.

Ez első pillantásra jól hangzik.

A logelemzés azonban megmutathatja, hogy a kérések nagy része nem a fontos termék- és kategóriaoldalakra érkezik, hanem például:

?sort=price

?orderby=newest

?filter_color=black

?page=

típusú URL-ekre.

Ebben az esetben nem feltétlenül kevés a crawling, hanem rosszul oszlik el.

A szerverlogok segítségével megvizsgálhatod:

• mely URL-eket látogatja leggyakrabban a Googlebot;
• milyen gyakran tér vissza egy-egy oldalra;
• mely könyvtárak kapják a legtöbb crawl-kérést;
• mennyi kérés jut paraméteres URL-ekre;
• milyen HTTP státuszkódokat kap a Googlebot;
• vannak-e fontos URL-ek, amelyeket ritkán térképez fel.

Mire figyelj az adatok értelmezésekor?

Ne azt keresd, hogyan tudnád mindenáron növelni a crawl-kérések számát. A jó eredmény az, ha a Googlebot a webhelyed értékes részeit hatékonyan térképezi fel.

Egy technikai optimalizálás után például akár csökkenhet is az összes crawl-kérés.

Ha korábban a Googlebot naponta rengeteg rendezési, keresési és paraméteres URL-t látogatott, majd ezek jelentős részét megfelelően kezeled, kevesebb kérés mellett is jobb lehet a crawl hatékonysága.

Éppen ezért a Google Search Console adatait nagy webhelyek esetén érdemes URL-struktúrával és szerverlogokkal együtt értelmezni.

A legfontosabb kérdés nem az, hogy „hányszor járt nálam ma a Googlebot?”, hanem az, hogy a Googlebot azokat az oldalakat térképezi-e fel rendszeresen, amelyek valóban fontosak a keresőből érkező forgalom és a webhelyed üzleti céljai szempontjából.

Hogyan befolyásolja a szerver teljesítménye a crawl budgetet?

A szerver teljesítménye elsősorban a Google által biztonságosan végrehajtható feltérképezés kapacitását befolyásolja. Ha a webhely gyorsan és stabilan válaszol, a Googlebot hatékonyabban tudja lekérni az URL-eket; ha viszont lassulást, időtúllépést vagy szerverhibákat érzékel, visszafoghatja a crawling intenzitását.

A Google célja nem az, hogy a feltérképezéssel túlterhelje a webhelyedet. A Googlebot ezért alkalmazkodhat ahhoz, hogyan reagál a szerver a kéréseire. Ez különösen nagy, több tízezer vagy százezer URL-ből álló webhelyeknél fontos.

Egy kisebb szolgáltatói honlapnál néhány lassabban betöltődő oldal miatt általában nem a crawl budget lesz a legnagyobb SEO-probléma. Egy 200 000 termékes webáruháznál azonban már egészen más helyzet alakulhat ki, ha a szerver rendszeresen nehezen szolgálja ki a botkéréseket.

Mi történik, ha a szerver túl lassan válaszol?

Ha a Google azt érzékeli, hogy a szerver nehezen kezeli a kéréseket, csökkentheti a feltérképezés intenzitását, hogy ne terhelje tovább a rendszert.

Képzelj el egy építőanyag-webáruházat 120 000 termékkel. A termékoldalak megjelenítéséhez minden kérésnél több összetett adatbázis-lekérdezés fut le. Normál terhelés mellett még megfelelő a működés, csúcsidőben azonban a szerver válaszideje jelentősen megnő.

Ha a Googlebot is ebben az időszakban próbál nagyobb mennyiségű URL-t lekérni, a szerver egyre lassabban reagálhat.

A probléma ráadásul nem kizárólag SEO-s. A lassú szerver a felhasználók számára is rosszabb élményt és üzleti veszteséget okozhat.

Miért problémásak az 5xx szerverhibák?

Az 5xx HTTP státuszkódok azt jelzik, hogy a szerver nem tudta megfelelően teljesíteni a kérést. Ha ezek rendszeresen vagy nagy mennyiségben jelentkeznek, az a Googlebot számára is szerveroldali problémát jelez.

Ilyen válasz lehet például:

• 500 – belső szerverhiba;
• 502 – hibás átjáró;
• 503 – a szolgáltatás átmenetileg nem érhető el;
• 504 – átjáró-időtúllépés.

Egy-egy rövid ideig tartó technikai hiba természetesen előfordulhat. Sokkal nagyobb gond, ha a Googlebot rendszeresen 5xx válaszokkal találkozik.

Ilyenkor a Google csökkentheti a crawl intenzitását, hiszen nem akar további terhelést okozni egy láthatóan problémákkal küzdő szervernek.

Szerverállapot	Lehetséges hatás a crawlingra	Teendő
Gyors és stabil	Hatékony URL-lekérés	Állapot fenntartása
Növekvő válaszidő	Lassabb feltérképezés	Teljesítmény vizsgálata
Gyakori 500-as hibák	Crawl kapacitás romolhat	Szerverhiba javítása
Gyakori 503-as hibák	A bot visszafoghatja a kéréseket	Terhelési probléma feltárása
Timeout	Sikertelen URL-lekérés	Szerver és alkalmazás optimalizálása
Időszakos leállás	URL-ek elérhetetlenné válhatnak	Stabilitás javítása

Mitől lehet lassú a szerver?

A lassú szerverválasz mögött nem feltétlenül maga a tárhely áll: az adatbázis, a CMS, a bővítmények és a dinamikus lekérdezések is okozhatnak teljesítményproblémát.

Egy WordPress webhelyen például problémát jelenthet egy rosszul optimalizált bővítmény, túlméretezett adatbázis vagy hibás cache-beállítás.

Egy webáruháznál további terhelést okozhatnak a dinamikus szűrők, készletlekérdezések és termékváltozatok.

Érdemes ezért megvizsgálnod:

• a szerver válaszidejét;
• a CPU- és memóriahasználatot;
• az adatbázis teljesítményét;
• a cache működését;
• a PHP és a CMS állapotát;
• az időtúllépéseket;
• az 5xx hibákat;
• a Googlebot kéréseinek kiszolgálását.

A gyorsabb tárhely automatikusan növeli a crawl budgetet?

Nem. Egy gyorsabb szerver javíthatja a crawl capacityt, de ettől a Google nem feltétlenül kezd el automatikusan sokkal több URL-t feltérképezni.

Ehhez kapcsolódik a crawl demand fogalma.

Hiába képes egy nagy teljesítményű szerver rendkívül sok kérést kiszolgálni, ha a Google szerint nincs szükség további URL-ek gyakori feltérképezésére.

Egy 300 oldalas, ritkán változó klímaszerelői honlapot például nem fog a Googlebot szükségszerűen sokszor gyakrabban crawlolni csak azért, mert a webhelyet egy erősebb szerverre költöztetted.

A technikai kapacitás és a Google feltérképezési igénye két külön tényező.

Hogyan javíthatod a szerver oldaláról a crawl hatékonyságát?

Elsősorban gyors, stabil és kiszámítható kiszolgálásra törekedj, ne pedig arra, hogy mesterségesen több Googlebot-kérést generálj.

Nagy webhely esetén érdemes rendszeresen ellenőrizni a Google Search Console Crawl Stats adatait és szükség esetén a szerverlogokat is.

Ha azt látod, hogy nő az átlagos válaszidő, gyakoribbak az 5xx hibák, és ezzel párhuzamosan megváltozik a Googlebot aktivitása, már van konkrét technikai probléma, amelyet érdemes kivizsgálni.

A szerveroptimalizálás célja tehát nem egy mesterségesen magas crawl budget elérése. A cél az, hogy amikor a Googlebot fontos URL-eket szeretne feltérképezni, a webhelyed gyorsan, stabilan és hibamentesen ki tudja szolgálni ezeket a kéréseket.

Hogyan pazarolhatják a hibás URL-ek a feltérképezési erőforrásokat?

A hibás, felesleges vagy értéktelen URL-ek akkor pazarolhatják a feltérképezési erőforrásokat, ha a Googlebot nagy mennyiségben fedezi fel és újra meg újra ellenőrzi őket. Különösen nagy webhelyeken okozhat problémát, ha a fontos oldalak mellett több tízezer technikai, paraméteres, duplikált vagy nem létező URL is bejárható.

Nem minden hibás URL jelent crawl budget problémát. Egy weboldalon természetes módon is keletkezhetnek megszűnt oldalak és 404-es válaszok. A gond akkor kezdődik, amikor a webhely saját struktúrája folyamatosan új felesleges URL-eket termel, vagy belső linkeken keresztül továbbra is elérhetővé teszi őket.

Milyen URL-ek okozhatnak felesleges crawlingot?

Leggyakrabban a paraméterek, belső keresések, hibás linkek, technikai URL-változatok és kontrollálatlanul generált szűrőoldalak növelik meg szükségtelenül a Googlebot számára elérhető URL-teret.

Egy webáruházban például ugyanaz a terméklista többféle URL-en is megjelenhet:

/cipok/

/cipok/?sort=price

/cipok/?sort=name

/cipok/?view=grid

/cipok/?utm_source=newsletter

Felhasználói szempontból ezek közül néhány funkció hasznos lehet, de ettől még nem biztos, hogy mindegyik URL-nek önálló keresési értéke van.

Különösen érdemes megvizsgálnod:

• belső keresési találatok URL-jeit;
• rendezési paramétereket;
• szűrési kombinációkat;
• tracking paramétereket;
• session ID-t tartalmazó URL-eket;
• hibásan generált útvonalakat;
• régi, már nem használt URL-eket;
• duplikált URL-változatokat.

Hogyan válhat néhány szűrőből több ezer URL?

A kombinálható szűrők azért veszélyesek, mert az URL-ek száma sokkal gyorsabban növekedhet, mint a webhely valódi tartalmainak száma.

Képzelj el egy menyasszonyi ruhákat kínáló webáruházat 2000 termékkel. A látogató szűrhet fazon, méret, szín, anyag, ár és kollekció szerint.

Önmagában ez kiváló felhasználói funkció.

Ha azonban minden kombináció külön crawlolható URL-t generál, a Googlebot például ilyen oldalakat is felfedezhet:

/menyasszonyi-ruha/?szin=feher&meret=38

/menyasszonyi-ruha/?meret=38&szin=feher

/menyasszonyi-ruha/?szin=feher&meret=38&sort=price

A technikai megvalósítástól függően akár a paraméterek eltérő sorrendje is további URL-változatokat eredményezhet.

Így egy néhány ezer termékes webáruház crawlolható URL-készlete nagyságrendekkel nagyobbra nőhet a valódi tartalmi készleténél.

URL-típus	Keresési érték	Crawl szempontból
Fontos termékoldal	Magas	Értékes
Fő kategória	Magas	Értékes
SEO-célú alkategória	Magas lehet	Értékes
Rendezési URL	Általában alacsony	Gyakran felesleges
Tracking URL	Nincs önálló értéke	Felesleges lehet
Session URL	Nincs önálló értéke	Felesleges
Belső keresési URL	Többnyire alacsony	Vizsgálandó
Véletlenszerű szűrőkombináció	Többnyire alacsony	Vizsgálandó

Miért problémásak a hibás belső linkek?

Ha a webhelyed belső linkjei nem létező URL-ekre mutatnak, a Googlebot ugyanúgy követheti ezeket a linkeket, majd 404-es választ kap.

Tegyük fel, hogy egy kertészeti portálon átalakítod a növénybetegségekkel foglalkozó kategóriát, de 300 régi cikk továbbra is a megszüntetett URL-ekre hivatkozik.

A Googlebot ezekkel újra és újra találkozhat a crawling során.

Egy-két ilyen hivatkozás nem jelent komoly problémát. Több ezer hibás belső link viszont már felesleges technikai zajt és rosszabb webhelystruktúrát eredményez.

Ezért a 404-es URL-ek vizsgálatakor ne csak azt kérdezd, hogy léteznek-e, hanem azt is:

„Miért találja meg még mindig ezeket a Google?”

Ha belső link, sitemap vagy más technikai elem folyamatosan újra jelzi őket, érdemes megszüntetni a kiváltó okot.

Miért problémásak a végtelen URL-terek?

A legsúlyosabb esetekben egy hibás technikai rendszer gyakorlatilag korlátlan számú URL-t képes előállítani.

Ilyen problémát okozhat például egy hibás naptár, amelyben a „következő hónap” link korlátlanul követhető. A Googlebot így elméletileg évekkel vagy évtizedekkel későbbi dátumokhoz tartozó URL-eket is felfedezhet.

Hasonló problémát okozhat:

• végtelen lapozás hibás URL-generálással;
• korlátlan szűrőkombináció;
• automatikusan változó paraméter;
• session azonosító;
• dinamikusan generált keresési URL.

Ezeknél a Googlebot számára nincs egyértelmű végpont, ezért rendkívül nagy URL-tér alakulhat ki.

Hogyan csökkentheted a felesleges URL-ek crawlingját?

Először azt kell feltárnod, honnan származnak a felesleges URL-ek, majd a probléma forrását kell megszüntetned. Nem elég egyesével kezelni több tízezer hibás URL-t, ha a rendszer közben folyamatosan újakat generál.

Érdemes ellenőrizned:

• a belső linkeket;
• a navigációt;
• a szűrőrendszert;
• az URL-paramétereket;
• az XML sitemapet;
• a canonical beállításokat;
• a robots.txt szabályokat;
• a szerverlogokat;
• a Search Console feltérképezési adatait.

Ha például egy webáruházban a rendezési paraméterek generálnak több tízezer értéktelen URL-t, akkor nem a Googlebotot kell „hibáztatnod”. Az URL-struktúrát kell úgy kialakítanod, hogy a keresőrobot számára ne nyíljon meg szükségtelenül hatalmas crawlolható tér.

A crawl budget optimalizálás egyik legfontosabb alapelve ezért egyszerű: minél kevesebb felesleges útvonalat adsz a Googlebotnak, annál könnyebben koncentrálhat azokra az URL-ekre, amelyek valóban értéket képviselnek a keresőben.

Hogyan hatnak az átirányítások és átirányítási láncok a feltérképezésre?

Az átirányítások önmagukban nem jelentenek SEO-hibát, de minden felesleges átirányítás egy további URL és HTTP-kérés, amelyet a Googlebotnak fel kell dolgoznia. Nagy webhelyeken a tömeges redirectek és hosszú átirányítási láncok ezért ronthatják a feltérképezés hatékonyságát.

A 301-es és más átirányítások teljesen természetes részei egy weboldal működésének. Szükség lehet rájuk például URL-struktúra módosításakor, HTTPS-re váltáskor, domainköltözésnél, termékek megszüntetésekor vagy több hasonló tartalom összevonásakor.

A probléma akkor kezdődik, amikor a Googlebotnak rendszeresen több köztes URL-en keresztül kell eljutnia a tényleges céloldalhoz.

Mi az az átirányítási lánc?

Átirányítási láncról akkor beszélünk, amikor egy URL nem közvetlenül a végleges céloldalra irányít, hanem egy vagy több köztes URL-en keresztül jutunk el oda.

Például:

A URL → 301 → B URL → 301 → C URL → 301 → D URL

Ahelyett, hogy:

A URL → 301 → D URL

Ez gyakran akkor alakul ki, amikor egy webhely URL-struktúráját többször módosítják.

Tegyük fel, hogy egy villanyszerelői weboldalon eredetileg ez az URL szerepelt:

/szolgaltatasok/villanyszereles.html

Később átkerült ide:

/villanyszereles/

Majd néhány év múlva újabb struktúraváltás történik:

/szolgaltatas/villanyszereles/

Ha minden költözésnél egyszerűen az előző céloldalt irányítod tovább, könnyen kialakulhat:

régi URL → köztes URL → új URL

Technikailag működhet, de jobb megoldás, ha a régi URL-ek közvetlenül az aktuális végleges URL-re mutatnak.

Miért rontják a hosszú redirectláncok a crawling hatékonyságát?

Minden átirányítás feldolgozása újabb kérés és újabb URL ellenőrzését igényli, ezért sok ezer redirect esetén jelentős mennyiségű felesleges crawling keletkezhet.

Egyetlen háromlépcsős átirányítás miatt még nem kell crawl budget válságra gondolnod. Más a helyzet egy 300 000 URL-es webáruháznál, ahol több korábbi URL-migráció miatt tömegesen maradtak hosszú láncok.

URL-helyzet	Hatékonyság	Javaslat
A → B	Jó	Általában rendben
A → B → C	Kevésbé hatékony	A → C legyen
A → B → C → D	Felesleges lánc	A → D legyen
A → B → A	Redirect loop	Azonnal javítandó
Belső link → redirect → céloldal	Felesleges kérés	A belső link közvetlenül a célra mutasson

A cél nem az, hogy minden átirányítást eltávolíts. A szükséges redirect maradjon, a szükségtelen köztes lépések viszont tűnjenek el.

Miért fontos a belső linkeket is frissíteni?

Ha a saját webhelyed továbbra is régi, átirányított URL-ekre linkel, a Googlebotnak minden egyes alkalommal követnie kell a redirectet ahelyett, hogy közvetlenül a végleges oldalra jutna.

Képzelj el egy SEO-portált, ahol egy fontos útmutató URL-je megváltozik.

A régi cím:

/seo-tippek/technikai-seo/

Az új:

/technikai-seo/

Beállítod a 301-es átirányítást, ami helyes. Viszont 80 korábbi cikk továbbra is a régi URL-re hivatkozik.

A felhasználó eljut a megfelelő oldalra, ezért első látásra minden működik. Technikai szempontból azonban jobb, ha ezt a 80 belső linket is közvetlenül az új URL-re módosítod.

A 301-es átirányítás ekkor biztonsági háló marad a régi külső linkekhez és korábban ismert URL-ekhez, miközben a saját webhelyed már a végleges struktúrát használja.

Mi az a redirect loop?

Redirect loop esetén az átirányítások körbe vezetik a felhasználót és a keresőrobotot, ezért a végleges oldal nem érhető el. Ez már nem egyszerű hatékonysági kérdés, hanem komoly technikai hiba.

Például:

A → B → C → A

vagy egyszerűbben:

A → B → A

Ilyenkor nincs végleges céloldal.

Redirect loop kialakulhat például:

• hibás HTTPS-beállítás miatt;
• www és non-www szabályok ütközésekor;
• WordPress URL-beállítási hibánál;
• CDN és szerveroldali redirect szabályok ütközésekor;
• hibás .htaccess szabályok miatt.

Ezeket érdemes magas prioritású technikai hibaként kezelni.

Mi történik weboldal- vagy domainköltözéskor?

Webhelymigrációnál az átirányítások nélkülözhetetlenek, de különösen fontos, hogy a régi URL lehetőleg közvetlenül az új megfelelőjére mutasson.

Ha például egy webáruház domainje megváltozik, miközben az URL-struktúrát is átalakítod, könnyen kialakulhat:

HTTP régi domain → HTTPS régi domain → HTTPS új domain → új URL

Jobb megoldás lehet:

régi URL → végleges új URL

A migráció után ellenőrizd a belső linkeket, canonical URL-eket és az XML sitemapet is. Az új sitemapben már a végleges URL-ek szerepeljenek, ne az átirányított változatok.

Minden régi redirectet törölni kell?

Nem. Egy megfelelően működő 301-es átirányítás hosszú távon is indokolt lehet, különösen akkor, ha a régi URL-re még külső linkek mutatnak vagy azt a felhasználók továbbra is használhatják.

A crawl optimalizálás célja tehát nem az átirányítások teljes megszüntetése.

Sokkal fontosabb:

• a redirectláncok rövidítése;
• a redirect loopok megszüntetése;
• a belső linkek frissítése;
• a sitemap megtisztítása;
• a canonicalok végleges URL-re állítása;
• a szükségtelen átirányítások eltávolítása.

A jó URL-struktúrában a Googlebot a lehető legrövidebb úton jut el a végleges, indexelhető tartalomhoz. Minél kevesebb felesleges köztes URL-t kell feldolgoznia, annál tisztább és hatékonyabb lesz a webhely feltérképezése.

Hogyan befolyásolja a duplikált tartalom a crawl budgetet?

A duplikált tartalom akkor befolyásolhatja kedvezőtlenül a crawl budgetet, ha ugyanaz vagy nagyon hasonló tartalom nagy mennyiségű különböző URL-en válik elérhetővé. Ilyenkor a Googlebot olyan URL-változatok felfedezésére és feltérképezésére is erőforrást fordíthat, amelyek nem képviselnek önálló keresési értéket.

Fontos, hogy itt elsősorban technikai duplikációról beszélünk. Nem az okozza a legnagyobb crawl problémát, ha két cikked néhány hasonló mondatot tartalmaz, hanem például az, ha ugyanaz a terméklista vagy termékoldal több száz különböző URL-en érhető el.

Egy kisebb honlapnál néhány duplikált URL általában nem okoz komoly crawl budget problémát. Több tíz- vagy százezer URL-es webhelyen viszont már jelentős lehet a hatása.

Hogyan keletkezhet technikai duplikált tartalom?

Technikai duplikáció akkor jön létre, amikor különböző URL-ek lényegében ugyanazt vagy nagyon hasonló tartalmat szolgálják ki. Ennek hátterében gyakran URL-paraméterek, szűrők, rendezések vagy hibás webhelybeállítások állnak.

Tipikus példa lehet:

/novenyek/

/novenyek/?sort=price

/novenyek/?sort=name

/novenyek/?utm_source=newsletter

Ha mindegyik URL lényegében ugyanazt a növénylistát jeleníti meg, a Google számára több külön URL létezik egy nagyon hasonló tartalomhoz.

További gyakori források:

• HTTP és HTTPS változatok;
• www és non-www verziók;
• URL-paraméterek;
• rendezési oldalak;
• nyomtatási változatok;
• session ID-k;
• termékváltozatok;
• kis- és nagybetűvel eltérő URL-ek;
• több kategóriaútvonalon elérhető azonos termék.

Miért lehet ez crawl budget probléma?

A Googlebot URL-eket térképez fel, ezért technikai szempontból az számít, hogy hány különböző URL-t tud felfedezni, nem pusztán az, hogy hány valóban egyedi tartalmad van.

Tegyük fel, hogy egy webáruházban 30 000 valódi termékoldal található.

Ha a technikai rendszer minden termékhez több különböző URL-változatot generál, a Googlebot számára a felfedezhető URL-készlet ennél jóval nagyobb lehet.

Helyzet	Valódi tartalom	Felfedezhető URL-ek
Tiszta URL-struktúra	30 000	kb. 30 000
2 változat/oldal	30 000	akár 60 000
5 változat/oldal	30 000	akár 150 000
Sok kombinálható paraméter	30 000	akár nagyságrendekkel több

Ezek szemléltető példák, nem általános Google-határértékek. A tényleges URL-szám mindig a webhely technikai felépítésétől függ.

A lényeg azonban jól látható: 30 000 értékes oldal kezelése és több százezer, nagyrészt duplikált URL kezelése nem ugyanaz a feladat a keresőrobot számára.

Megoldja a canonical a duplikált URL-ek problémáját?

A canonical fontos jelzés arra, hogy több hasonló URL közül melyiket tekinted elsődlegesnek, de nem feltétlenül akadályozza meg a duplikált URL-ek feltérképezését.

Ez crawl budget szempontból különösen fontos.

Ha például:

/menyasszonyi-ruhak/?sort=price

canonical címkéje erre mutat:

/menyasszonyi-ruhak/

azzal jelzed a Google-nek, hogy az alap kategóriaoldalt tartod preferált változatnak.

A Googlebotnak azonban előbb fel kell fedeznie és adott esetben fel kell térképeznie a paraméteres URL-t, hogy a canonical jelzést feldolgozhassa.

Ezért nagy webhelyen nem elég azt mondani, hogy „minden duplikált URL-re teszünk canonicalt, és kész”.

Érdemes magát az URL-generálást és a belső linkelést is megvizsgálni.

Hogyan csökkentheted a duplikált URL-ek számát?

A leghatékonyabb megoldás az, ha már a webhely technikai felépítésében csökkented a szükségtelen URL-változatok létrejöttét és felfedezhetőségét.

Vizsgáld meg például:

• szükség van-e minden paraméterre;
• generál-e külön URL-t a rendezés;
• belső linkek mutatnak-e duplikált változatokra;
• megfelelőek-e a canonical jelzések;
• csak canonical URL-ek szerepelnek-e a sitemapben;
• egységes-e a HTTP/HTTPS és www/non-www kezelés;
• létrejönnek-e ugyanahhoz a tartalomhoz eltérő URL-útvonalak.

Egy kereskedelmi webhelyen például érdemes egyértelműen meghatározni, mely kategória- és szűrőoldalak rendelkeznek valós keresési szándékkal.

A „női fekete futócipő” lehet olyan kombináció, amelyre külön optimalizált landing oldal indokolt. A „női fekete futócipő ár szerint csökkenő sorrendben, 48 termék oldalanként” viszont valószínűleg nem igényel önálló SEO-oldalt.

A duplikált tartalom mindig crawl budget probléma?

Nem. Néhány duplikált URL miatt egy kisebb webhelyen általában nincs szükség külön crawl budget optimalizálásra. A probléma elsősorban akkor válik jelentőssé, amikor a duplikáció nagy léptékű és folyamatosan növeli a crawlolható URL-készletet.

Ezért mindig az arányokat és a webhely méretét nézd.

Ha 300 tartalmi oldal mellett találsz tíz technikai duplikációt, valószínűleg nem ez lesz a legfontosabb SEO-problémád. Ha viszont 50 000 valódi oldal mellett 800 000 paraméteres és duplikált URL-t fedezhet fel a Googlebot, már teljesen más a helyzet.

Crawl budget szempontból tehát nem önmagában a hasonló tartalom a legnagyobb veszély, hanem a szükségtelenül megsokszorozódó URL-készlet. Minél egyértelműbben jelzed és technikailag is biztosítod, melyek a webhely valódi, értékes URL-jei, annál hatékonyabban tudja a Google feltérképezni a fontos tartalmaidat.

Miért okozhatnak problémát a paraméteres és szűrt URL-ek?

A paraméteres és szűrt URL-ek azért okozhatnak crawl budget problémát, mert néhány alapoldalból akár több ezer vagy nagyságrendekkel több külön URL-t hozhatnak létre. Ha a Googlebot ezeket mind felfedezheti és követheti, jelentős feltérképezési erőforrás mehet el olyan oldalakra, amelyek nem képviselnek önálló keresési értéket.

Paraméteres URL akkor keletkezik, amikor az alap URL-hez különböző változók kapcsolódnak. Ezek teljesen természetesek lehetnek egy webhely működésében, különösen webáruházaknál.

Például:

/futocipok/?szin=fekete

/futocipok/?meret=39

/futocipok/?szin=fekete&meret=39

/futocipok/?szin=fekete&meret=39&sort=price

A felhasználó számára ezek a szűrők hasznosak. SEO szempontból azonban nem biztos, hogy minden lehetséges kombinációnak külön crawlolható és indexelhető URL-re van szüksége.

Hogyan alakulhat ki URL-robbanás?

Az URL-robbanás akkor következik be, amikor több egymással kombinálható szűrő minden variációja külön URL-t generál. Az URL-ek száma ilyenkor sokkal gyorsabban növekedhet, mint a valódi termékek vagy tartalmak száma.

Képzelj el egy menyasszonyi ruhákat kínáló webáruházat, ahol a ruhákat az alábbi tulajdonságok szerint lehet szűrni:

• fazon;
• méret;
• szín;
• anyag;
• kollekció;
• árkategória.

Ha mindegyik szűrőből több lehetőség választható, és ezek szabadon kombinálhatók, néhány ezer termék mellett rendkívül nagy URL-készlet keletkezhet.

Ráadásul ehhez további paraméterek társulhatnak:

?sort=price

?order=asc

?page=2

?view=grid

Így ugyanaz vagy nagyon hasonló terméklista sok különböző URL-en jelenhet meg.

A Googlebot URL-eket fedez fel, ezért technikai szempontból nem az számít, hogy hány terméked van, hanem az is, hogy hány külön URL-en teszed elérhetővé őket.

Minden szűrt URL értéktelen SEO szempontból?

Nem. Egyes szűrt oldalak kifejezetten értékes SEO landing oldalak lehetnek, ha önálló keresési szándékot szolgálnak ki és megfelelő tartalommal rendelkeznek.

Ez fontos különbség.

Egy cipő-webáruházban például az alábbi kategóriák mögött lehet valódi keresési igény:

• női futócipő;
• fekete női futócipő;
• vízálló túracipő;
• férfi téli bakancs.

Ezekből érdemes lehet önálló, indexelhető kategóriaoldalakat kialakítani.

Más a helyzet például ezzel:

/noi-futocipo/?szin=fekete&sort=price_desc&view=48

Az ár szerinti rendezés és az oldalanként megjelenített termékek száma általában nem hoz létre olyan új keresési szándékot, amely miatt külön SEO-oldalra lenne szükség.

URL-típus	Lehetséges SEO-érték	Kezelés
Fő termékkategória	Magas	Indexelhető
Keresett alkategória	Magas	Indexelhető lehet
Tudatos SEO-szűrőoldal	Magas lehet	Egyedileg vizsgálandó
Ár szerinti rendezés	Alacsony	Általában nem kell külön indexelni
Grid/lista nézet	Nincs önálló értéke	Felesleges URL-változat
Tracking paraméter	Nincs	Ne legyen SEO-célú URL
Véletlenszerű szűrőkombináció	Többnyire alacsony	Korlátozandó lehet

Miért problémás a paraméterek eltérő sorrendje?

Egy rosszul kialakított rendszer ugyanazt a tartalmat akár a paraméterek eltérő sorrendjével is több URL-en teheti elérhetővé.

Például:

?szin=fekete&meret=38

és:

?meret=38&szin=fekete

A felhasználó számára a két oldal teljesen azonos lehet, technikailag azonban két külön URL-ről beszélünk.

Ha ehhez öt-hat paraméter és több érték társul, a lehetséges URL-változatok száma rendkívül gyorsan növekedhet.

Ezért nagy webáruházaknál az URL-paraméterek kezelése nem egyszerűen esztétikai kérdés, hanem a technikai SEO és a crawl hatékonyság egyik fontos része.

Mi a helyzet a tracking paraméterekkel?

A kampány- és mérési paraméterek önmagukban hasznosak lehetnek, de nem célszerű, hogy szükségtelenül külön crawlolható URL-készletet hozzanak létre.

Ilyen lehet például:

?utm_source=facebook

?utm_source=newsletter

?utm_campaign=summer

Ha ugyanaz a termékoldal sok különböző kampányparaméterrel válik felfedezhetővé, a Google több URL-változattal találkozhat ugyanahhoz a tartalomhoz.

A canonical beállítások itt segíthetnek az elsődleges URL jelzésében, de a canonical nem azonos a crawling megakadályozásával.

Hogyan döntsd el, mely paraméteres URL-eket érdemes megtartani?

A döntést elsősorban a keresési szándék és az oldal önálló értéke alapján hozd meg, ne pusztán technikai szempontból.

Tedd fel az alábbi kérdéseket:

• Van erre a kombinációra valós keresési igény?
• Jelentősen eltérő termékkészletet mutat?
• Érdemes önálló landing oldalként optimalizálni?
• Van saját címe, tartalma és belső linkelése?
• A felhasználónak önálló értéket ad?
• Szeretném, hogy ez az URL megjelenjen a Google-ben?

Ha a válasz többnyire igen, érdemes lehet tudatos SEO-oldalt kialakítani belőle.

Ha az URL pusztán azt változtatja meg, hogy ár szerint növekvő vagy csökkenő sorrendben jelenjenek meg ugyanazok a termékek, akkor valószínűleg nincs szükség külön keresőbeli jelenlétre.

A cél tehát nem az összes paraméteres URL megszüntetése. A hasznos szűrés maradjon használható a látogatóknak, miközben a Googlebot számára kontrollált és egyértelmű URL-struktúrát alakítasz ki.

Így elkerülheted, hogy néhány ezer valódi termékből több százezer vagy akár még nagyobb mennyiségű, SEO szempontból alacsony értékű URL-tér jöjjön létre.

Hogyan kezeld a végtelen URL-tereket és a faceted navigationt?

A végtelen URL-tereket úgy kezeld, hogy a felhasználóknak hasznos szűrési lehetőségeket megtartod, de a Googlebot számára nem teszel korlátlanul felfedezhetővé minden lehetséges szűrő-, rendezési és paraméterkombinációt. A cél az, hogy csak a valódi keresési értékkel rendelkező URL-ek váljanak a SEO-struktúra részévé.

A faceted navigation, vagyis szűrőalapú navigáció leginkább webáruházaknál és nagy adatbázis-alapú oldalakon jellemző. A látogató több tulajdonság alapján szűkítheti a találatokat, például ár, márka, méret, szín, teljesítmény vagy készlet szerint.

Ez felhasználói szempontból kifejezetten hasznos. Technikai SEO szempontból azonban komoly problémává válhat, ha minden szűrés és minden szűrőkombináció külön, crawlolható URL-t hoz létre.

Mit jelent a végtelen URL-tér?

Végtelen URL-térnek azt a helyzetet nevezzük, amikor a webhely technikai működése rendkívül nagy vagy gyakorlatilag korlátlan számú különböző URL felfedezését teszi lehetővé.

Egy klímákat értékesítő webáruházban például lehet szűrni:

• gyártóra;
• teljesítményre;
• energiaosztályra;
• árra;
• helyiségméretre;
• Wi-Fi funkcióra;
• készletállapotra.

Ha ezek szabadon kombinálhatók, majd további rendezési és lapozási paraméterek is hozzájuk kapcsolódnak, ugyanahhoz a termékkészlethez rengeteg URL jöhet létre.

Például:

/klimak/?marka=x&teljesitmeny=35

/klimak/?teljesitmeny=35&marka=x

/klimak/?marka=x&teljesitmeny=35&sort=price

/klimak/?marka=x&teljesitmeny=35&sort=price&page=2

A Googlebot ezeket külön URL-ként fedezheti fel.

Mely szűrőoldalakat érdemes megtartani SEO-célra?

Azokat a szűrt oldalakat érdemes önálló SEO landing oldalként kezelni, amelyek mögött egyértelmű keresési szándék van, megfelelő termékkínálattal rendelkeznek, és hosszú távon is értékes céloldalt alkotnak.

Egy kertészeti webáruházban például lehet valós keresési értéke ezeknek:

• árnyéktűrő növények;
• télálló balkon növények;
• szárazságtűrő évelők;
• gyorsan növő sövénynövények.

Ezek technikailag akár szűrés eredményeként is létrejöhetnének, SEO szempontból azonban jobb lehet stabil, tudatosan optimalizált landing oldalként kezelni őket.

Kaphatnak saját:

• SEO-barát URL-t;
• title-t;
• H1 címet;
• kategórialeírást;
• belső linkeket;
• canonical URL-t.

Ezzel szemben a „szárazságtűrő évelők ár szerint csökkenő sorrendben, 48 termék oldalanként” már nem feltétlenül képvisel új keresési szándékot.

Mely URL-eket érdemes korlátozni?

Azokat a kombinációkat érdemes elsősorban kontrollálni, amelyek csak a megjelenítés módját változtatják, duplikálják a tartalmat, vagy nincs mögöttük önálló keresési igény.

URL-típus	SEO-érték	Javasolt megközelítés
Fő kategória	Magas	Indexelhető
Keresett alkategória	Magas	Indexelhető
Tudatos SEO-szűrőoldal	Magas lehet	Egyedileg optimalizálandó
Ár szerinti rendezés	Alacsony	Ne legyen külön SEO-oldal
Lista/grid nézet	Nincs	Ne hozzon létre SEO-oldalt
Tracking paraméter	Nincs	Ne legyen indexelési cél
Nulltalálatos szűrés	Nincs	Ne legyen SEO landing oldal
Többszörös véletlenszerű szűrés	Többnyire alacsony	Crawl kontroll szükséges lehet

Hogyan akadályozd meg, hogy a Google minden kombinációt felfedezzen?

A legjobb megoldás nem egyetlen SEO-címke használata, hanem az URL-generálás, a belső linkelés, a canonicalizáció és szükség esetén a crawling szabályozásának összehangolása.

Elsőként azt érdemes megvizsgálnod, hogy a webhelynek valóban szüksége van-e minden kombinációhoz külön URL-re.

Ha nincs, technikailag is csökkentheted a létrejövő URL-változatok számát.

Ezután ellenőrizd, hogy a navigáció milyen linkeket generál. Ha a Googlebot minden egyes szűrőkombinációhoz hagyományos követhető linket kap, rendkívül nagy URL-teret fedezhet fel.

A megoldás webhelyenként eltérhet, ezért nem érdemes automatikusan minden szűrt URL-t robots.txt-ben letiltani vagy noindexre állítani. Előbb meg kell határoznod, mely kombinációk értékesek.

Miért nem oldja meg önmagában a canonical a problémát?

A canonical segít jelezni az elsődleges URL-t, de önmagában nem akadályozza meg, hogy a Googlebot felfedezze és feltérképezze a paraméteres változatokat.

Ha 100 000 szűrt URL mind ugyanarra a kategóriára canonicalizál, a Google-nek ettől még találkoznia kellhet ezekkel az URL-ekkel ahhoz, hogy a jelzéseket feldolgozza.

Crawl budget szempontból ezért jobb lehet már a felesleges URL-ek felfedezhetőségét és generálását is csökkenteni, nem pusztán utólag canonicalizálni őket.

Milyen más rendszer hozhat létre végtelen URL-teret?

Nem csak a webáruházi szűrők okozhatnak problémát: hibás naptárak, belső keresések, lapozások és dinamikus paraméterek is gyakorlatilag korlátlan URL-készletet generálhatnak.

Jó példa egy eseményoldal naptára, ahol minden hónaphoz létezik „következő hónap” link.

Ha nincs technikai korlátozás, a Googlebot eljuthat:

/esemenyek/2027/01/

/esemenyek/2030/01/

/esemenyek/2040/01/

típusú oldalakhoz is, miközben ezeken nincs értékes tartalom.

Hasonló problémát okozhat egy belső kereső, amely tetszőleges keresési kifejezésből külön URL-t készít.

Mi a jó faceted navigation SEO-stratégia?

A jó stratégia kettéválasztja a felhasználói szűrést és a kereső számára értékes landing oldalakat. Nem minden felhasználói szűrőnek kell Google-ben indexelhető SEO-oldallá válnia.

Én három csoportra bontanám az URL-eket:

1. SEO szempontból fontos oldalak: legyenek crawlolhatók, indexelhetők, belső linkeltek és optimalizáltak.

2. Felhasználóknak hasznos, de keresési értékkel nem rendelkező kombinációk: maradjanak használhatók, de ne építs belőlük szükségtelenül hatalmas SEO URL-készletet.

3. Teljesen technikai URL-ek: ahol lehet, már a generálásukat vagy felfedezhetőségüket is érdemes korlátozni.

Így egy 30 000 termékes webáruházból nem szükségszerűen lesz több millió URL-ből álló feltérképezési labirintus.

A faceted navigation optimalizálásának lényege tehát nem a szűrők megszüntetése, hanem annak eldöntése, mely kombinációk szolgálják a felhasználót, melyek szolgálják a keresési szándékot, és melyek jelentenek pusztán technikai zajt a Googlebot számára.

Hogyan segíti a robots.txt a crawl budget optimalizálását?

A robots.txt segítségével megakadályozhatod, hogy a Googlebot bizonyos, SEO szempontból felesleges URL-területeket feltérképezzen, így nagy webhelyeken csökkentheted a szükségtelen crawlingot. A robots.txt azonban a feltérképezést szabályozza, nem az indexelést, ezért csak átgondoltan érdemes crawl budget optimalizálására használni.

A robots.txt egy, a webhely gyökérkönyvtárában elhelyezett fájl, amelyben megadhatod, hogy a keresőrobotok mely útvonalakat kérhetik le, illetve melyeket ne térképezzék fel.

Crawl budget szempontból elsősorban akkor lehet hasznos, ha egy nagy webhelyen nagyszámú olyan URL érhető el, amelyet a Googlebotnak nincs értelme rendszeresen bejárnia.

Milyen URL-ek crawlingját lehet érdemes korlátozni?

Elsősorban azokat a technikai URL-területeket érdemes megvizsgálni, amelyek nagy mennyiségben keletkeznek, és biztosan nincs szükség arra, hogy a Googlebot lekérje a tartalmukat.

Ilyenek lehetnek például bizonyos:

• belső keresési URL-ek;
• technikai útvonalak;
• végtelen URL-terek;
• egyes paraméteres URL-minták;
• felhasználói funkciókhoz tartozó oldalak;
• olyan szűrési területek, amelyeknek nincs keresési értékük.

Tegyük fel, hogy egy nagy kereskedelmi webhely belső keresője minden keresésből külön URL-t hoz létre:

/kereses/?q=fekete+cipő

/kereses/?q=piros+cipő

/kereses/?q=38-as+fekete+cipő

Ha ezekből rendkívül sok URL válik felfedezhetővé, érdemes lehet technikailag megakadályozni, hogy a keresőrobot korlátlanul járja őket.

Hogyan működik a robots.txt crawl budget szempontból?

Ha a Googlebot számára egy URL crawlingja robots.txt-ben tiltott, a bot általában nem tölti le annak tartalmát. Ez csökkentheti az adott URL-terület lekérésére fordított szerver- és feltérképezési erőforrást.

Ez különbözik például a canonical működésétől.

Canonical esetén a Googlebotnak általában hozzá kell férnie az oldalhoz ahhoz, hogy lássa a canonical jelzést. Ha viszont egy URL crawlingját megfelelő robots.txt szabály tiltja, a Googlebot nem tölti le az oldal tartalmát.

Ezért nagy URL-terek esetében a robots.txt valódi crawl kontrollt jelenthet.

Megoldás	Crawlingot korlátozza?	Indexelést szabályozza?	Fő cél
robots.txt	Igen	Nem közvetlenül	Feltérképezés szabályozása
noindex	Nem	Igen	Indexelés megakadályozása
canonical	Nem	Jelzés az elsődleges URL-ről	Duplikáció kezelése
301 redirect	A régi URL-ről továbbirányít	A cél URL felé terel	URL-áthelyezés
XML sitemap	Nem	Nem	Fontos URL-ek felfedezésének segítése

Miért nem használható a robots.txt az indexelés biztos megakadályozására?

A robots.txt nem indexelési utasítás. Egy robots.txt-ben blokkolt URL bizonyos esetekben továbbra is megjelenhet a Google indexében, ha a kereső más forrásból ismeri az URL-t.

Ez az egyik legfontosabb különbség a robots.txt és a noindex között.

Ha például külső webhelyek linkelnek egy blokkolt URL-re, a Google tudhat annak létezéséről akkor is, ha magát a tartalmat nem crawlolhatja.

Ezért ha a célod kifejezetten az, hogy egy oldal ne kerüljön a Google indexébe, nem szabad automatikusan robots.txt tiltással megoldani a problémát.

Miért lehet problémás a robots.txt és a noindex együttes használata?

Ha robots.txt-ben blokkolod az URL crawlingját, a Googlebot nem feltétlenül tudja lekérni az oldalt, így az oldalon található noindex utasítást sem tudja feldolgozni.

Ez elsőre ellentmondásosnak tűnhet:

szeretnéd, hogy a Google ne indexelje az oldalt → noindexet teszel rá → majd robots.txt-ben megtiltod a crawlingját.

Ezzel azonban éppen azt akadályozhatod meg, hogy a Googlebot elolvassa a noindex utasítást.

Ha tehát egy URL-t ki szeretnél venni az indexből, először gondoskodnod kell arról, hogy a Google hozzáférhessen a noindex jelzéshez.

Milyen hibákat érdemes elkerülni?

A robots.txt hibás használatával fontos oldalakat és erőforrásokat is kizárhatsz a crawlingból, ezért ne alkalmazz széles körű tiltásokat anélkül, hogy pontosan tudnád, milyen URL-eket érintenek.

Különösen veszélyes lehet egy túl általános szabály.

Például egy paraméter tiltásakor előfordulhat, hogy nemcsak értéktelen rendezési URL-eket, hanem fontos SEO landing oldalakat is érintesz.

Mielőtt módosítasz, ellenőrizd:

• milyen URL-ek illeszkednek a szabályra;
• van-e köztük organikus forgalmat hozó oldal;
• szerepelnek-e fontos URL-ek a sitemapben;
• vannak-e ezekre mutató belső linkek;
• szükséges-e a Google-nek hozzáférnie az oldalhoz canonical vagy noindex feldolgozásához.

Mikor érdemes robots.txt-et használni crawl budget optimalizálására?

Elsősorban nagy webhelyeken érdemes megfontolni, amikor egy jól azonosítható technikai URL-terület jelentős mennyiségű felesleges crawlingot generál.

Egy 150 oldalas szolgáltatói honlapnál valószínűleg nincs szükséged bonyolult robots.txt stratégiára csak azért, hogy „spórolj a crawl budgettel”.

Egy több százezer URL-t előállító webáruháznál viszont már komoly különbséget jelenthet, ha a Googlebot nem jár be korlátlanul értéktelen keresési, szűrési vagy technikai útvonalakat.

A robots.txt tehát nem általános SEO-takarítóeszköz, hanem precíz crawl szabályozási lehetőség. Akkor használod jól, ha előtte pontosan feltérképezed az URL-struktúrát, meghatározod, mely területek értéktelenek a kereső számára, és csak ezután korlátozod a Googlebot hozzáférését.

Crawl budget optimalizálásnál a cél nem az, hogy minél több URL-t tilts le, hanem az, hogy a Googlebot ne pazarolja a feltérképezési kapacitást olyan területekre, amelyeket valóban nincs értelme crawlolnia.

Mikor használj noindexet, és mikor robots.txt tiltást?

Noindexet akkor használj, ha azt szeretnéd, hogy egy oldal ne szerepeljen a Google keresési indexében, de a keresőrobot hozzáférhessen és feldolgozhassa. Robots.txt tiltást akkor érdemes használni, ha magát a feltérképezést szeretnéd korlátozni egy olyan URL-en vagy URL-csoporton, amelyet a Googlebotnak nem szükséges lekérnie.

A két megoldást gyakran összekeverik, pedig teljesen más feladatot látnak el. A noindex az indexelést, a robots.txt a crawlingot szabályozza.

Ez crawl budget optimalizálásnál különösen fontos, mert rossz választással akár az ellenkezőjét érheted el annak, amit szeretnél.

Mikor használj noindexet?

Noindexet olyan oldalakon használj, amelyeket a Google feltérképezhet, de nem szeretnéd, hogy önálló találatként megjelenjenek a keresőben.

A noindex utasítás általában az oldal HTML-kódjában található robots meta tagként, vagy bizonyos esetekben HTTP-fejlécben adható meg.

Tipikus példák lehetnek:

• egyes vékony vagy segédjellegű oldalak;
• olyan archívumok, amelyeket nem szeretnél indexeltetni;
• bizonyos felhasználói vagy funkcionális oldalak;
• olyan tartalmak, amelyeknek nincs önálló keresési értékük.

A lényeg, hogy a Googlebot hozzáférhessen az oldalhoz, mert így tudja felismerni a noindex utasítást.

Mikor használj robots.txt tiltást?

Robots.txt tiltás akkor indokolt, ha egy URL-terület tartalmát a Googlebotnak nincs szüksége lekérnie, és elsősorban a crawlingot szeretnéd megakadályozni.

Ez nagy webhelyek crawl budget optimalizálásánál lehet különösen hasznos.

Tegyük fel, hogy egy kereskedelmi rendszer olyan technikai URL-ek tízezreit generálja, amelyek semmilyen keresési értékkel nem rendelkeznek, de a Googlebot rendszeresen bejárja őket.

Ha ezek egyértelmű URL-minta alapján elkülöníthetők, a robots.txt segítségével korlátozható lehet a crawlingjuk.

Cél	Noindex	robots.txt
Ne jelenjen meg az oldal a Google-ben	Igen	Nem erre való
Ne crawlolja a Googlebot	Nem	Igen
A Google lássa a canonicalt	Igen	Blokkolás esetén nem feltétlenül
A Google lássa a noindexet	Igen	Blokkolás esetén nem
Crawl budget csökkentése nagy URL-térnél	Korlátozottan	Hasznos lehet
Indexből való eltávolítás	Alkalmas lehet	Önmagában nem megfelelő

Miért problémás egyszerre noindexet és robots.txt tiltást használni?

Ha robots.txt-ben megtiltod egy URL feltérképezését, a Googlebot nem tudja lekérni az oldalt, ezért az azon található noindex utasítást sem feltétlenül látja.

Tegyük fel, hogy van egy oldalad:

/belsokereses/?q=menyasszonyi+ruha

Elhelyezel rajta egy noindex utasítást, majd robots.txt-ben is letiltod a teljes /belsokereses/ könyvtárat.

A Googlebot innentől nem tudja lekérni az oldalt, így a noindex utasítás feldolgozása is akadályba ütközhet.

Ez különösen problémás lehet, ha az URL korábban már bekerült az indexbe.

Ha azt szeretnéd, hogy egy korábban indexelt oldal noindex hatására kikerüljön a Google-ből, a keresőrobotnak előbb újra hozzá kell férnie az oldalhoz, hogy észlelhesse az utasítást.

A noindex megspórolja a crawl budgetet?

Nem közvetlenül. Egy noindex oldal továbbra is crawlolható, ezért a Googlebot időnként meglátogathatja annak ellenőrzésére, hogy továbbra is érvényes-e az indexelési utasítás.

Ezért nagy webáruházaknál nem feltétlenül jó stratégia több százezer felesleges paraméteres URL-t egyszerűen noindexre állítani, majd ezzel lezártnak tekinteni a crawl budget problémát.

A Googlebotnak továbbra is fel kell dolgoznia ezeket az URL-eket.

Ha a valódi probléma az, hogy a webhely szükségtelenül hatalmas URL-teret generál, akkor érdemes magát az URL-generálást, a belső linkelést és a crawlolhatóságot is megvizsgálni.

Használhatsz robots.txt-et már indexelt URL eltávolítására?

A robots.txt önmagában nem megbízható módszer egy URL Google-indexből történő eltávolítására. A crawling blokkolása és az indexelés megakadályozása két külön feladat.

Ha a Google más forrásból – például külső vagy belső linkből – ismeri az URL-t, bizonyos esetekben akkor is tudhat a létezéséről, ha annak tartalmát nem crawlolhatja.

Ezért ne abból indulj ki, hogy:

„Ha robots.txt-ben letiltom, akkor biztosan eltűnik a Google-ből.”

Ez nem így működik.

Hogyan döntsd el, melyiket használd?

Mindig abból indulj ki, hogy a crawlingot vagy az indexelést szeretnéd-e szabályozni.

Ha azt mondod:

„A Google elolvashatja ezt az oldalt, de nem szeretném a keresési találatok között látni.”

→ noindex.

Ha azt mondod:

„A Googlebotnak egyáltalán nincs szüksége arra, hogy ezt a hatalmas technikai URL-területet lekérje.”

→ robots.txt tiltás megfontolható.

Ha pedig azt mondod:

„Ugyanez a tartalom több URL-en található, és szeretném jelezni az elsődleges változatot.”

→ valószínűleg nem a noindex és nem is a robots.txt az elsődleges megoldás, hanem a canonicalizáció és az URL-struktúra rendezése.

A technikai SEO-ban ezért nincs univerzális „tiltsuk le” megoldás. Először határozd meg pontosan, mit szeretnél elérni: crawlingot korlátozni, indexelést megakadályozni vagy duplikációt kezelni. Ha ezt tisztázod, sokkal könnyebb kiválasztani a megfelelő eszközt, és elkerülheted, hogy a crawl budget optimalizálása közben fontos oldalakat zárj el a Google elől.

Hogyan segíti az XML sitemap a fontos URL-ek feltérképezését?

Az XML sitemap abban segíti a Google-t, hogy könnyebben felfedezze a weboldalad fontos URL-jeit, különösen nagy, gyakran frissülő vagy összetett webhelyek esetén. A sitemap beküldése azonban nem garantálja sem az URL feltérképezését, sem az indexelését.

Az XML sitemap lényegében egy gépek számára készített URL-lista. Segítségével egyértelműen jelezheted a keresőnek, mely oldalakat tartod a webhelyed fontos, kereső számára elérhető tartalmainak.

Crawl budget szempontból azért hasznos, mert a Googlebotnak nem kizárólag belső és külső linkek követésével kell felfedeznie az URL-eket. Ez különösen akkor jelenthet előnyt, ha egy webhely több tízezer terméket, cikket vagy más tartalmat tartalmaz.

Milyen URL-ek kerüljenek az XML sitemapbe?

Az XML sitemapben elsősorban olyan URL-ek szerepeljenek, amelyeket indexelhetőnek és a Google keresési találatai szempontjából értékesnek tartasz.

Ideális esetben egy sitemapben szereplő URL:

• 200-as HTTP státuszkódot ad;
• indexelhető;
• nincs robots.txt-ben blokkolva;
• saját magára mutató canonical jelzéssel rendelkezik, ha canonicalt használsz;
• valódi tartalmat tartalmaz;
• a webhely aktív struktúrájának része.

Ha például egy SEO-portálon 2500 szakmai cikk található, amelyek mindegyikét szeretnéd indexeltetni, ezeknek logikus helyük van az XML sitemapben.

Más a helyzet egy belső keresési eredménnyel, egy technikai szűrési URL-lel vagy egy átirányított oldallal.

Milyen URL-eket ne tegyél a sitemapbe?

Ne küldj egymásnak ellentmondó technikai jelzéseket a Google számára: ha egy URL-t nem szeretnél indexeltetni, általában ne szerepeltesd olyan sitemapben, amelyben az indexelésre szánt URL-jeidet jelzed.

Tipikus problémák:

URL állapota	Sitemapben legyen?	Miért?
200 + indexelhető + canonical	Igen	Ez az ideális állapot
301/302 redirect	Nem	A végleges cél URL kerüljön bele
404/410	Nem	Az oldal már nem létezik
Noindex	Nem	Ellentmondásos jelzés
Robots.txt-ben blokkolt	Általában nem	Nem tudod megfelelően crawloltatni
Paraméteres duplikáció	Általában nem	A canonical változatot add meg
Fontos kategóriaoldal	Igen	Segíti a felfedezését
Aktív termékoldal	Igen	Fontos keresési céloldal lehet

Egy tiszta sitemap tehát nem egyszerűen „minden URL listája”.

Inkább azoknak az URL-eknek a listájaként kezeld, amelyekkel kapcsolatban egyértelműen azt jelzed: ezeket tekintem a webhely fontos, canonical és indexelhető oldalainak.

Garantálja-e a sitemap az indexelést?

Nem. Az XML sitemap egy jelzés és felfedezési segítség, nem utasítás arra, hogy a Google köteles feltérképezni vagy indexelni az URL-t.

Ez különösen fontos akkor, amikor indexelési problémát próbálsz megoldani.

Ha egy oldal:

• gyenge vagy alig tartalmaz önálló tartalmat;
• nagyon hasonló más oldalakhoz;
• hibás canonical beállítással rendelkezik;
• technikailag nem indexelhető;

akkor attól még nem fog automatikusan bekerülni az indexbe, hogy hozzáadod a sitemaphez.

A sitemap tehát nem javítja ki az oldal SEO-problémáit.

Miért fontos a lastmod adat?

A lastmod mezővel jelezheted, mikor történt érdemi módosítás az adott URL tartalmában, és a Google ezt felhasználhatja az újracrawlolás megtervezéséhez.

A hangsúly az érdemi módosításon van.

Ha egy villanyszerelési útmutatót jelentősen kibővítesz, új táblázatot, új fejezeteket és friss információkat adsz hozzá, indokolt a módosítás dátumának frissítése.

Nem jó gyakorlat viszont minden URL lastmod értékét naponta automatikusan az aktuális dátumra állítani úgy, hogy a tartalom valójában nem változott.

A megbízható sitemap jelzései értékesebbek, mint a mesterséges frissességi jelzések.

Hogyan segíthet a sitemap egy nagy webáruháznál?

Nagy webhelyen az XML sitemap különösen hasznos lehet az URL-készlet rendszerezésére és az új vagy módosított oldalak felfedezésének támogatására.

Egy 200 000 termékes webáruháznál például külön sitemapek készülhetnek:

• termékoldalakhoz;
• kategóriaoldalakhoz;
• tartalmi oldalakhoz;
• blogbejegyzésekhez.

Ez nemcsak a Google számára hasznos. Neked is sokkal könnyebb ellenőrizni, hogy az egyes tartalomtípusokkal mi történik.

Ha például 150 000 aktív termék URL-jét küldöd be, de a Search Console adataiból az látszik, hogy jelentős részük indexelésével probléma van, célzottabban kezdheted meg a vizsgálatot.

Helyettesítheti-e a sitemap a jó belső linkelést?

Nem. Az XML sitemap segítheti az URL-ek felfedezését, de nem helyettesíti a logikus webhelystruktúrát és a megfelelő belső linkelést.

Ha van egy fontos „hőszivattyú karbantartás” szolgáltatási oldalad, de a webhely egyetlen másik oldaláról sem mutat rá belső link, attól még nem lesz ideális a struktúra, hogy az URL szerepel a sitemapben.

Az igazán fontos oldalakat a Googlebotnak természetes belső navigáción keresztül is meg kell tudnia találni.

A sitemapet ezért inkább kiegészítő felfedezési eszköznek tekintsd.

Hogyan használd az XML sitemapet crawl budget optimalizálásnál?

Tartsd tisztán, naprakészen és következetesen a sitemapet: csak olyan URL-eket adj meg, amelyeket valóban fontosnak és indexelhetőnek tartasz.

Rendszeresen ellenőrizd:

• vannak-e benne 404-es URL-ek;
• szerepelnek-e átirányítások;
• kerültek-e bele noindex oldalak;
• tartalmaz-e paraméteres duplikációkat;
• hiányoznak-e fontos új URL-ek;
• helyes-e a lastmod;
• csak végleges canonical URL-eket tartalmaz-e.

Crawl budget szempontból tehát az XML sitemap nem növeli varázsütésre a rendelkezésedre álló feltérképezési keretet. Abban segít, hogy a Google könnyebben azonosítsa a webhely azon URL-jeit, amelyeket te fontosnak tartasz.

A jó sitemap, a tiszta URL-struktúra és az erős belső linkelés együtt sokkal egyértelműbb környezetet teremt a Googlebot számára: kevesebb technikai zaj, könnyebben felfedezhető fontos oldalak és következetesebb feltérképezési jelzések.

Hogyan befolyásolja a belső linkelés a crawl budgetet?

A belső linkelés segít a Googlebotnak felfedezni a weboldalad URL-jeit, megérteni az oldalak közötti kapcsolatokat, és könnyebben eljutni a fontos tartalmakhoz. A jó belső linkstruktúra nem egyszerűen „megnöveli” a crawl budgetet, hanem hatékonyabbá teszi a rendelkezésre álló feltérképezési erőforrások felhasználását.

Amikor a Googlebot meglátogat egy oldalt, az ott található követhető linkeken keresztül további URL-eket fedezhet fel. Emiatt nem mindegy, hogy a fontos tartalmaid néhány logikus lépésből elérhetők-e, vagy mélyen el vannak rejtve a webhely struktúrájában.

Miért fontos, hogy a lényeges oldalak könnyen elérhetők legyenek?

Minél egyértelműbb útvonal vezet egy fontos oldalhoz, annál könnyebben fedezheti fel és térképezheti újra a Googlebot.

Egy SEO-val foglalkozó webhelyen például kialakíthatsz ilyen struktúrát:

Főoldal → SEO tudástár → Technikai SEO → Crawl budget

A crawl budgetről szóló cikkből pedig tovább linkelhetsz a kapcsolódó témákra:

• robots.txt;
• XML sitemap;
• indexelés;
• canonical;
• belső linkelés;
• technikai SEO audit.

Így nem elszigetelt cikkeket hozol létre, hanem összefüggő témaklasztert, amelyben a keresőrobot több logikus útvonalon is mozoghat.

Mit jelent a crawl depth?

A crawl depth azt mutatja meg, hogy hány linklépésre található egy URL egy kiindulóponttól, gyakran például a főoldaltól. A túl mélyen elhelyezett fontos tartalmak felfedezése nehezebb lehet.

Tegyük fel, hogy egy fontos szolgáltatási oldal eléréséhez ezt az útvonalat kell követni:

Főoldal → Szolgáltatások → Kategória → Alkategória → Régió → Település → Szolgáltatás

Ez már hat linklépés.

Ha ugyanez az oldal egy releváns fő kategóriából, szolgáltatási összefoglalóból és kapcsolódó tartalmakból is közvetlen linket kap, sokkal jobban beilleszkedik a webhely struktúrájába.

Nem szükséges minden fontos oldalnak közvetlenül a főoldalról linket adnod. A cél egy logikus, laposabb hierarchia kialakítása, nem pedig az, hogy több ezer linket zsúfolj a főoldalra.

Hogyan segít a belső linkelés az új tartalmak felfedezésében?

Egy új oldal gyorsabban bekerülhet a Google által ismert URL-készletbe, ha már feltérképezett, releváns oldalakról belső linkeket kap.

Tegyük fel, hogy megírsz egy új cikket:

„Hogyan optimalizáld az XML sitemapet?”

Ha csak publikálod, de se kategóriából, se másik cikkből nem linkeled, a Google elsősorban például a sitemapből szerezhet tudomást róla.

Ha viszont belinkeled:

• a technikai SEO kategóriából;
• a crawl budget cikkből;
• az indexelésről szóló útmutatóból;
• egy sitemap témájú összefoglalóból;

akkor több felfedezési útvonalat biztosítasz.

Hogyan pazarolhatja a rossz belső linkelés a crawlingot?

A belső linkelés nemcsak segítheti, hanem rossz kialakítás esetén feleslegesen növelheti is a Googlebot számára felfedezhető URL-ek számát.

Ez gyakori probléma webáruházaknál.

Képzelj el egy kereskedelmi oldalt, ahol minden kategóriaoldalon követhető linkek vezetnek:

• minden szűrési kombinációhoz;
• minden rendezési változathoz;
• tracking paraméteres URL-ekhez;
• üres találati oldalakhoz;
• technikai nézetekhez.

A Googlebot ezeknek a linkeknek a követésével hatalmas URL-teret fedezhet fel.

Belső link típusa	Crawl szempontból
Fontos kategóriára mutató link	Hasznos
Kapcsolódó cikkre mutató link	Hasznos
Fontos termékoldal linkje	Hasznos
Breadcrumb link	Hasznos
301-re mutató belső link	Felesleges köztes lépés
404-re mutató link	Hibás
Véletlenszerű paraméteres URL	Felesleges crawlingot okozhat
Árva fontos oldal	Nehezebben felfedezhető

Miért érdemes a redirectelő belső linkeket javítani?

A belső linkek lehetőleg közvetlenül a végleges 200-as URL-re mutassanak, ne egy átirányításon keresztül érjék el azt.

Például:

Cikk → régi URL → 301 → új URL

helyett:

Cikk → új URL

A 301-es átirányítást nem feltétlenül kell megszüntetni, hiszen régi külső linkek vagy könyvjelzők miatt továbbra is szükség lehet rá. A saját belső linkjeidet azonban érdemes frissíteni.

Nagy webhelyen több tízezer ilyen felesleges redirectes belső link megszüntetése már a crawling hatékonyságán is javíthat.

Hogyan építs crawlbarát belső linkstruktúrát?

A crawlbarát belső linkelés lényege, hogy a fontos tartalmak logikus hierarchiában, releváns kontextusból és lehetőleg közvetlen URL-ekkel legyenek elérhetők.

Jól működhet például:

Főoldal → fő kategória → alkategória → konkrét tartalom

Ezt kiegészítheted:

• breadcrumb navigációval;
• kapcsolódó cikkekkel;
• kategóriaoldalakkal;
• tematikus hubokkal;
• kontextuális szöveges linkekkel.

Egy nagy kertészeti portálon például a „levendula metszése” cikk kaphat linket a levenduláról szóló fő útmutatóból, a metszési tudástárból és más mediterrán növények gondozásáról szóló tartalmakból.

Ez egyszerre segíti a látogatót és a keresőrobotot.

A több belső link mindig jobb?

Nem. A cél nem a lehető legtöbb belső link létrehozása, hanem a releváns, logikus és technikailag tiszta linkstruktúra kialakítása.

Ha minden cikkből automatikusan 50–100 irreleváns oldalra linkelsz, attól nem lesz jobb a crawling.

Sokkal hasznosabb, ha világosan megmutatod:

• melyek a fő témák;
• melyek az alkategóriák;
• mely tartalmak kapcsolódnak egymáshoz;
• mely URL-ek a webhely fontos céloldalai.

A belső linkelés crawl budget szempontból tehát elsősorban irányítási eszköz. Segítségével nem egy nagyobb „Googlebot-keretet” vásárolsz magadnak, hanem olyan webhelystruktúrát alakítasz ki, amelyben a keresőrobot kevesebb felesleges útvonalon, könnyebben jut el a valóban értékes tartalmakhoz.

Miért fontos az árva oldalak megszüntetése?

Az árva oldal olyan URL, amelyre a webhelyeden belül egyetlen követhető belső link sem mutat. Az ilyen oldalakat a Google más forrásból – például XML sitemapből vagy külső linkből – még megtalálhatja, de a belső linkek hiánya megnehezítheti a felfedezésüket, újrafeltérképezésüket és a webhely struktúrájában betöltött szerepük értelmezését.

Az árva oldalak problémája tehát nem egyszerűen az, hogy „a Google nem látja őket”. Ez nem feltétlenül igaz. Sokkal fontosabb, hogy ezek az URL-ek elszakadnak a webhely természetes navigációs és tartalmi struktúrájától.

Mit jelent pontosan az árva oldal?

Árva oldalról akkor beszélünk, ha az URL létezik és elérhető, de a webhely más oldalairól nem vezet hozzá belső link.

Tegyük fel, hogy van egy SEO-val foglalkozó webhelyed, ahol elkészítesz egy részletes útmutatót a canonical címke használatáról.

Az oldal elérhető ezen az URL-en:

/canonical-cimke-hasznalata/

Viszont nem kerül be a technikai SEO kategóriába, nincs a menüben, és egyetlen kapcsolódó cikkből sem linkeled.

Ha az URL szerepel az XML sitemapben, a Google megtalálhatja. Ettől azonban az oldal még árva marad a belső linkstruktúrában.

Ideális esetben például így kapcsolódhatna:

Technikai SEO → Indexelés → Canonical címke használata

és további releváns cikkekből is kaphatna kontextuális belső linkeket.

Miért nehezebb a Google számára az árva oldalak felfedezése?

A Googlebot jelentős részben linkek követésével fedezi fel és térképezi újra az URL-eket, ezért egy belső linkek nélküli oldal kevesebb természetes felfedezési útvonallal rendelkezik.

Egy jól belinkelt cikket a Googlebot több irányból is megtalálhat:

• kategóriaoldalról;
• kapcsolódó cikkből;
• breadcrumb navigációból;
• tematikus hub oldalról;
• más releváns tartalomból.

Egy árva oldalnál ezek az útvonalak hiányoznak.

Ez különösen akkor okozhat problémát, ha az URL az XML sitemapből is kimarad. Ebben az esetben előfordulhat, hogy a Google csak egy külső hivatkozásból vagy más korábbi forrásból szerez tudomást róla.

Hogyan kapcsolódnak az árva oldalak a crawl budgethez?

Crawl budget szempontból az árva oldalak elsősorban azért problémásak, mert egy rendezetlen URL-készletre és hiányos belső struktúrára utalhatnak. Nagy webhelyen több ezer árva URL már jelentősen megnehezítheti annak biztosítását, hogy a Googlebot a megfelelő oldalakat találja meg és térképezze újra.

Képzelj el egy nagy építőipari webáruházat, ahol 70 000 termékoldal található.

Egy kategória-átszervezés után 8000 termék kikerül a belső kategórialinkekből. Az oldalak továbbra is működnek, 200-as státuszkódot adnak, és egy részük még az XML sitemapben is szerepel.

Technikailag tehát léteznek.

A belső navigációból azonban eltűntek.

Ez már nem egyszerűen egy-egy rosszul belinkelt oldal problémája, hanem webhelyszintű strukturális hiba, amelyet érdemes feltárni.

Oldal állapota	Belső link	Sitemap	Helyzet
Fontos aktív oldal	Van	Van	Ideális
Fontos oldal	Nincs	Van	Árva oldal
Fontos oldal	Nincs	Nincs	Különösen nehezen felfedezhető
Megszűnt oldal	Nincs	Nincs	Lehet teljesen helyes
Technikai URL	Nincs	Nincs	Nem feltétlenül probléma

Minden árva oldalt vissza kell linkelni?

Nem. Az árva oldalak feltárása után először azt kell eldöntened, hogy az adott URL-nek egyáltalán van-e még helye a webhely aktív struktúrájában.

Ez nagyon fontos.

Találhatsz például egy három évvel ezelőtti kampányhoz készült landing oldalt, amelynek már nincs keresési vagy üzleti értéke. Ilyenkor nem az a megoldás, hogy gyorsan belinkeled tíz másik oldalról.

Más esetben viszont egy értékes, részletes szakmai cikk maradhatott ki véletlenül a kategóriából. Ezt már érdemes visszakapcsolni a webhely tartalmi hálózatába.

Az árva URL-eket ezért érdemes legalább három csoportra osztani:

Megtartandó: értékes oldal, amelynek belső linkeket kell adni.

Összevonandó vagy átirányítandó: van értéke, de egy másik oldal jobban lefedi ugyanazt a témát.

Megszüntethető: nincs már felhasználói, üzleti vagy keresési értéke.

Hogyan találhatod meg az árva oldalakat?

Az árva oldalak azonosításához érdemes több adatforrást összehasonlítani, mert egy hagyományos webhely-crawler önmagában éppen azokat az URL-eket nem feltétlenül találja meg, amelyekre nincs belső link.

Hasznos lehet összevetni:

• a crawler által megtalált URL-eket;
• az XML sitemap URL-jeit;
• a Google Search Console-ban ismert oldalakat;
• az analitikai rendszer landing oldalait;
• szükség esetén a szerverlogok URL-jeit.

Ha például az XML sitemapben 5000 URL szerepel, de a belső linkeket követő crawler csak 4500-at talál, érdemes megvizsgálnod a különbséget.

A hiányzó 500 oldal között lehetnek árva URL-ek.

Hogyan javítsd az értékes árva oldalakat?

Az értékes árva oldalakat ne véletlenszerű linkekkel „mentsd meg”, hanem helyezd vissza a webhely logikus információs struktúrájába.

Egy kertészeti portálon például a „Mikor kell metszeni a málnát?” cikk bekerülhet a:

Kertészkedés → Gyümölcsök → Málna

struktúrába.

Emellett releváns belső linket kaphat a málna ültetéséről, gondozásáról és betegségeiről szóló tartalmakból.

Ezzel egyszerre segíted:

• a Googlebot felfedezését;
• a tartalmi kapcsolatok megértését;
• a felhasználói navigációt;
• a tematikus struktúra kialakítását.

Az árva oldalak megszüntetésének tehát nem az a célja, hogy minden létező URL-re erőltetetten belső linket adj. Először döntsd el, mely oldalak értékesek, majd ezeket logikusan illeszd vissza a webhely struktúrájába.

Crawl budget szempontból is ez a lényeg: ne egy rendezetlen URL-halmazt adj a Googlebotnak, hanem egy olyan következetes webhelystruktúrát, amelyben a fontos oldalak világosan kapcsolódnak egymáshoz, a felesleges URL-ek pedig nem vonják el szükségtelenül a feltérképezési figyelmet.

Hogyan hatnak a 404-es és soft 404-es oldalak a feltérképezésre?

A 404-es oldalak önmagukban nem jelentenek crawl budget problémát: teljesen természetes, hogy egy webhelyen idővel megszűnnek URL-ek. A gond akkor kezdődik, ha a webhely tömegesen generál hibás URL-eket, belső linkekkel folyamatosan ezekre irányítja a Googlebotot, vagy olyan soft 404 oldalakat szolgál ki, amelyek technikailag sikeres választ adnak, miközben valójában nincs rajtuk érdemi tartalom.

Crawl budget szempontból ezért nem az a cél, hogy nullára csökkentsd a 404-es URL-ek számát. Sokkal fontosabb annak kiderítése, hogy miért találkozik velük a Googlebot, és a webhelyed továbbra is aktívan jelzi-e ezeket az URL-eket.

Mit jelent a valódi 404-es oldal?

A 404-es HTTP státuszkód azt jelzi a böngészőnek és a keresőrobotnak, hogy a kért URL-en nem található az adott tartalom. Ha egy oldal valóban megszűnt és nincs megfelelő helyettesítője, a 404 teljesen szabályos válasz lehet.

Képzelj el egy webáruházat, ahol végleg megszűnik egy olyan termék, amelyet már soha nem fognak forgalmazni.

Ha nincs olyan új termék vagy oldal, amely valóban megfelelne a régi URL tartalmának, nem feltétlenül kell mesterségesen átirányítani valahová.

A Google idővel újra ellenőrizheti az URL-t, majd a megfelelő jelzések alapján kezelheti a megszűnt oldalt.

A 404 tehát nem automatikusan technikai SEO-hiba.

Mikor válhatnak problémává a 404-es URL-ek?

A 404-ek akkor igényelnek komolyabb figyelmet, ha nagy mennyiségben keletkeznek, és a webhelyed belső linkjei, sitemapje vagy technikai rendszere továbbra is folyamatosan a megszűnt URL-ek felé vezeti a Googlebotot.

Tegyük fel, hogy egy kertészeti portálon megváltoztatod 3000 növény adatlapjának URL-struktúráját.

A régi:

/noveny/adatlap/levendula/

Az új:

/novenyek/levendula/

Az új oldalak megfelelően működnek, de több ezer régi belső link továbbra is az előző URL-ekre mutat, amelyek már 404-es választ adnak.

Ebben az esetben nem maga a 404 a fő probléma.

A hibás belső linkstruktúra az, ami újra és újra a nem létező URL-ekhez vezeti a Googlebotot.

Érdemes ezért megkeresned és kijavítanod a hibás belső hivatkozásokat.

Mi az a soft 404?

Soft 404-ről akkor beszélünk, amikor egy URL technikailag nem megfelelő „nem található” választ ad – gyakran 200-as sikeres HTTP státuszt –, miközben a Google az oldal tartalma alapján úgy érzékeli, hogy valójában nincs rajta érdemi vagy létező tartalom.

Például egy megszűnt termék URL-jén ezt látja a látogató:

„A keresett termék nem található.”

A szerver azonban:

HTTP 200 OK

választ ad.

Ez technikailag azt közli, hogy az oldal rendben betöltődött, miközben tartalmilag azt mutatja, hogy a keresett erőforrás nem létezik.

Ez ellentmondásos jelzés a kereső számára.

Helyzet	HTTP válasz	Mit jelent?
Aktív oldal	200	A tartalom elérhető
Végleg megszűnt URL	404	Nem található
Tudatosan eltávolított tartalom	410	Megszűnt
Végleg új helyre költözött oldal	301	Új URL-re irányít
Nem létező tartalom 200-as válasszal	200	Soft 404 gyanú
Szerverhiba	5xx	Szerveroldali probléma

Miért problémás a soft 404 crawl szempontból?

A soft 404 megnehezítheti a webhely állapotának egyértelmű értelmezését, mert a HTTP válasz azt sugallja, hogy létező oldalról van szó, miközben a tartalom ennek ellentmond.

Nagy webhelyen ez különösen kellemetlen.

Képzelj el egy kereskedelmi rendszert, ahol 50 000 korábban megszűnt termék URL-je továbbra is 200-as választ ad egy szinte üres „Nincs ilyen termék” sablonnal.

A Google-nek ezeket az URL-eket is fel kell dolgoznia ahhoz, hogy felismerje, valójában nem értékes tartalmi oldalakról van szó.

Sokkal tisztább technikai környezetet teremtesz, ha a szerver válasza megfelel az URL tényleges állapotának.

Mikor használj 301-et, és mikor 404-et?

301-es átirányítást akkor használj, ha a megszűnt oldalnak van valóban megfelelő új megfelelője. Ha nincs releváns helyettesítő tartalom, a 404 vagy adott esetben 410 természetesebb megoldás lehet.

Tegyük fel, hogy egy klímával foglalkozó oldalon megváltoztatod egy útmutató URL-jét:

/regi-klima-karbantartas/

helyett:

/klima-karbantartas/

A tartalom lényegében ugyanaz, csak az URL változott.

Itt a 301 logikus.

Más a helyzet, ha megszüntetsz egy konkrét, régi terméket, amelynek nincs megfelelő utódja.

Ilyenkor nem jó gyakorlat automatikusan a főoldalra irányítani:

megszűnt termék → 301 → főoldal

A céloldalnak releváns helyettesítőnek kell lennie, nem egyszerűen egy működő URL-nek.

Mi a helyzet a 410-es státuszkóddal?

A 410 Gone azt jelzi, hogy az adott erőforrást szándékosan eltávolították, és már nem érhető el. Bizonyos esetekben használható olyan URL-eknél, amelyekről egyértelműen tudod, hogy végleg megszűntek.

Nem szükséges azonban minden megszűnt URL-t 410-re állítanod.

A normál 404 is megfelelő lehet, ha az oldal már nem létezik.

A legfontosabb a következetes és valós technikai állapot közlése.

Hogyan előzd meg, hogy a 404-ek feleslegesen terheljék a crawlingot?

Ne magukat a természetes 404-eket próbáld mindenáron eltüntetni, hanem szüntesd meg azokat a webhelyen belüli jelzéseket, amelyek folyamatosan visszavezetik a Googlebotot a hibás URL-ekhez.

Ellenőrizd például:

• mutatnak-e belső linkek 404-es URL-re;
• szerepelnek-e 404-ek az XML sitemapben;
• hibásan generál-e URL-eket valamelyik sablon vagy bővítmény;
• vannak-e végtelenül keletkező hibás paraméteres URL-ek;
• megfelelően működnek-e a korábbi URL-migrációk;
• valódi 404 helyett 200-as soft 404 válaszok keletkeznek-e.

Ha egy 404-es URL már nincs a sitemapben, nem mutat rá belső link, és a webhely sem generálja újra, akkor nem szükséges csak a crawl budget miatt mesterségesen átirányítanod.

A lényeg tehát nem az, hogy egy weboldalon soha ne legyen 404. Egy természetesen fejlődő webhelyen ez irreális cél lenne.

Crawl budget szempontból az a fontos, hogy a Googlebot ne egy hibás URL-generáló rendszerben bolyongjon. A megszűnt tartalom kapjon megfelelő HTTP-választ, a hibás belső linkeket javítsd, a sitemapből távolítsd el a nem létező URL-eket, és a valóban értékes oldalakhoz biztosíts tiszta feltérképezési útvonalat.

Hogyan befolyásolja a JavaScript a Google feltérképezését?

A JavaScript önmagában nem akadályozza meg a Google feltérképezését, de összetettebbé teheti a tartalom és a linkek feldolgozását. Ha a fontos szövegek, termékadatok vagy navigációs linkek csak JavaScript futtatása után jelennek meg, a Google-nek a kezdeti HTML lekérése mellett renderelnie is kell az oldalt.

A modern weboldalak jelentős része használ JavaScriptet menükhöz, szűrőkhöz, interaktív elemekhez, terméklistákhoz vagy dinamikusan betöltődő tartalmakhoz. Ettől egy webhely még lehet jól feltérképezhető és indexelhető. Technikai SEO-probléma akkor alakulhat ki, ha a kereső számára fontos tartalom kizárólag olyan JavaScript-folyamaton keresztül válik elérhetővé, amelyet a Google nehezen vagy hibásan tud feldolgozni.

Hogyan dolgozza fel a Google a JavaScript-oldalakat?

A Google először lekéri az URL-t és annak HTML-válaszát, majd a JavaScriptet igénylő oldalaknál renderelésre is szükség lehet ahhoz, hogy a végleges tartalom megfelelően feldolgozható legyen.

Egyszerűsítve a folyamat:

URL felfedezése → crawling → HTML feldolgozása → szükséges erőforrások feldolgozása → renderelés → indexelési feldolgozás

Egy hagyományos HTML-oldalon a fontos cím, szöveg és linkek már az első szerverválaszban megtalálhatók.

Egy erősen kliensoldali JavaScriptre épülő webalkalmazásnál viszont a kezdeti HTML akár kevés érdemi tartalmat is tartalmazhat, a tényleges információk pedig csak a böngészőben futó JavaScript után jelennek meg.

Minél több kritikus tartalom függ a rendereléstől, annál összetettebbé válik a kereső általi feldolgozás.

Miért fontos, hogy a belső linkeket a Google is felismerje?

A Googlebot számára a belső linkek fontos felfedezési útvonalak, ezért a lényeges navigációs elemeket érdemes szabványos, crawlolható HTML-linkekként megvalósítani.

Egy webáruházban például a látogató rákattint a „Fekete női cipők” szűrőre, mire JavaScript betölti az új terméklistát.

Ha azonban a művelet mögött nincs megfelelően felfedezhető URL és linkstruktúra, a Googlebot nem feltétlenül ugyanúgy találja meg a kapcsolódó oldalt, ahogyan egy ember.

Különösen fontos ez:

• kategóriaoldalaknál;
• lapozásnál;
• terméklistáknál;
• kapcsolódó termékeknél;
• cikkajánlóknál;
• fő navigációs elemeknél.

Ha egy oldal SEO szempontból fontos, ne csak egy JavaScript eseményen keresztül legyen elérhető.

Hogyan okozhat problémát a JavaScript-alapú végtelen görgetés?

A végtelen görgetés akkor lehet SEO-probléma, ha az új tartalmak kizárólag görgetés vagy felhasználói interakció hatására jelennek meg, és nincs hozzájuk külön, crawlolható URL-struktúra.

Képzelj el egy kertészeti webáruházat 2000 növénnyel.

Az első kategóriaoldalon 30 termék jelenik meg. Ahogy a látogató lefelé görget, JavaScript automatikusan betölti a következő 30-at, majd újabb 30-at.

A felhasználónak ez kényelmes.

SEO szempontból azonban biztosítani kell, hogy a később megjelenő termékekhez a Googlebot is megbízható felfedezési útvonalon juthasson el, ne kizárólag a görgetési eseménytől függjön.

Milyen JavaScript-hibák ronthatják a feltérképezhetőséget?

A legnagyobb kockázatot azok a JavaScript-megoldások jelentik, amelyek miatt a Google nem fér hozzá a kritikus tartalomhoz, navigációhoz vagy erőforrásokhoz.

Probléma	Lehetséges következmény
Tartalom csak JS után jelenik meg	Renderelés szükséges
Fontos link nem szabványos link	URL felfedezése nehezebb lehet
JavaScript-hiba	Tartalom nem töltődik be megfelelően
Blokkolt JS-erőforrás	A renderelt oldal eltérhet
Hibás lazy loading	Kép vagy tartalom kimaradhat
Csak interakcióra betöltődő tartalom	A Google nem feltétlenül éri el
Hibás kliensoldali routing	URL-kezelési és indexelési problémák

Mi a helyzet a lazy loadinggal?

A lazy loading önmagában nem SEO-hiba, és megfelelő megvalósítás mellett kifejezetten hasznos teljesítményoptimalizálási technika. Arra kell figyelned, hogy a fontos tartalom ne kizárólag olyan felhasználói művelet után töltődjön be, amelyet a keresőrobot nem hajt végre.

Képeknél például a lazy loading csökkentheti a kezdeti oldalbetöltéshez szükséges adatforgalmat.

Más a helyzet, ha egy hosszú szakmai cikk utolsó fejezetei csak akkor kerülnek a DOM-ba, amikor az olvasó egy gombra kattint.

Ilyenkor érdemes ellenőrizni, hogy a Google a renderelt változatban ténylegesen hozzáfér-e a teljes tartalomhoz.

Hogyan kapcsolódik mindez a crawl budgethez?

A JavaScript crawl budget szempontból főként azért fontos, mert a crawling mellett renderelési és feldolgozási erőforrásokat is igényelhet. A cél ezért nem a JavaScript eltávolítása, hanem a felesleges technikai komplexitás csökkentése és a kritikus SEO-elemek megbízható elérhetővé tétele.

Egy kisebb vállalkozói WordPress-weboldalon ez általában nem központi crawl budget kérdés.

Egy több százezer URL-es, JavaScriptre erősen építő kereskedelmi platformnál viszont már érdemes részletesen megvizsgálni:

• mit tartalmaz az eredeti HTML;
• mit lát a Google renderelés után;
• felfedezhetők-e a fontos linkek;
• megfelelően működik-e a kliensoldali navigáció;
• keletkeznek-e felesleges URL-ek;
• vannak-e blokkolt erőforrások;
• milyen szerverterhelést okoznak az API-kérések.

Szükséges-e szerveroldali renderelést használni?

Nem minden JavaScript-webhelynek van szüksége külön szerveroldali renderelési megoldásra. A technológiát az oldal működése és a Google számára ténylegesen elérhető tartalom alapján érdemes megválasztani.

Az SSR, statikus generálás vagy más renderelési megoldás bizonyos projektekben előnyös lehet, de nem univerzális SEO-követelmény.

A fontos kérdés inkább ez:

„A Google ugyanazt a lényeges tartalmat és navigációt megbízhatóan eléri-e, amelyet a felhasználó?”

Ezt például a Google Search Console URL-ellenőrzési lehetőségeivel és technikai crawlerrel is érdemes tesztelni.

JavaScript használatakor tehát nem az a cél, hogy mindent visszaalakíts egyszerű HTML-oldallá. Sokkal fontosabb, hogy a kritikus tartalom, a belső linkek és a fontos URL-ek ne függjenek szükségtelenül bonyolult kliensoldali folyamatoktól. Így a modern felhasználói élmény megtartása mellett a Google számára is tiszta és hatékonyan feldolgozható webhelyet alakíthatsz ki.

Hogyan optimalizáld egy webáruház crawl budgetjét?

Egy webáruház crawl budgetjének optimalizálásakor az a legfontosabb, hogy a Googlebot elsősorban az értékes termék-, kategória- és SEO landing oldalakat térképezze fel, ne pedig szűrők, rendezések, belső keresések és más technikai paraméterek miatt létrejövő URL-ek tömegét. A cél nem a több crawling, hanem a fontos URL-ek hatékonyabb feltérképezése.

A webáruházak különösen hajlamosak az úgynevezett URL-robbanásra. Egy 20 000 termékes webshop technikailag könnyen létrehozhat ennél sokszor több URL-t, ha minden szűrés, rendezés, termékváltozat és paraméter külön címen érhető el.

Mely URL-eket tekintsd elsődlegesnek?

Először határozd meg, mely oldalak rendelkeznek valódi keresési és üzleti értékkel. Ezeknek kell a webáruház crawlolható és indexelhető struktúrájának középpontjában állniuk.

Általában ilyenek:

• fő termékkategóriák;
• fontos alkategóriák;
• aktív termékoldalak;
• keresési szándékra épített szűrt landing oldalak;
• márkaoldalak, ha önálló keresési értékük van;
• vásárlási útmutatók és szakmai tartalmak.

Egy menyasszonyi ruhákat értékesítő webáruházban például a „minimalista menyasszonyi ruhák” vagy az „A-vonalú menyasszonyi ruhák” önálló SEO landing oldalként is értékes lehet.

Az viszont, hogy ugyanazokat a ruhákat ár szerint csökkenő sorrendben mutatod, önmagában nem indokol új indexelhető SEO-oldalt.

Hogyan kezeld a szűrőket és rendezési URL-eket?

Ne engedd, hogy minden lehetséges felhasználói beállítás automatikusan külön SEO-célú URL-lé váljon. A szűrés maradhat kényelmes a vásárlónak anélkül, hogy minden kombinációt a Google számára is értékes oldalként kezelnél.

Külön vizsgáld meg:

URL-típus	SEO-érték	Prioritás
Fő kategória	Magas	Nagyon magas
Fontos alkategória	Magas	Nagyon magas
Aktív termék	Magas	Magas
Keresett szűrőkombináció	Magas lehet	Egyedileg vizsgálandó
Ár szerinti rendezés	Alacsony	Alacsony
Grid/lista nézet	Nincs önálló értéke	Nagyon alacsony
Tracking paraméter	Nincs önálló értéke	Nagyon alacsony
Belső keresési URL	Többnyire alacsony	Korlátozandó lehet
Nulltalálatos szűrés	Nincs	Ne legyen SEO landing oldal

A technikai megoldás webáruházanként eltérhet. A lényeg, hogy ne több százezer véletlenszerű kombinációból álljon a Google számára felfedezhető URL-tér.

Hogyan kezeld a termékváltozatokat?

A szín-, méret- vagy más termékváltozatok URL-kezelését annak alapján alakítsd ki, hogy az adott változat rendelkezik-e önálló keresési értékkel és érdemben különböző tartalommal.

Egy póló 12 különböző mérete általában nem igényel 12 önálló indexelhető oldalt.

Más lehet a helyzet, ha egy termékváltozat mögött önálló keresési szándék áll, eltérő termékinformációval és egyedi felhasználói értékkel.

A cél itt is az, hogy ne sokszorozd meg szükségtelenül a crawlolható URL-ek számát.

Mit tegyél a belső keresési oldalakkal?

A webáruház saját keresési találatai elsősorban a felhasználókat szolgálják, és általában nem érdemes korlátlanul SEO landing oldalakként kezelni őket.

Ha minden keresés külön URL-t generál:

/kereses/?q=fekete+ruha

/kereses/?q=fekete+ruha+38

/kereses/?q=olcso+fekete+ruha

akkor gyakorlatilag korlátlan URL-tér alakulhat ki.

Különösen problémás, ha ezeket más oldalak belső linkekkel is felfedezhetővé teszik.

Hogyan kezeld a megszűnt termékeket?

Ne irányíts automatikusan minden megszűnt termékoldalt a főoldalra. A megfelelő kezelés attól függ, hogy a termék ideiglenesen nem kapható, végleg megszűnt, vagy van-e valóban releváns helyettesítője.

Ha a termék várhatóan újra elérhető lesz, sok esetben érdemes megtartani az oldalt, és világosan jelezni a készletállapotot.

Ha végleg megszűnt, de van közvetlen utódja, releváns 301-es átirányítás indokolt lehet.

Ha nincs megfelelő helyettesítő, a 404 vagy adott esetben 410 természetes megoldás lehet.

Ezzel elkerülheted, hogy több tízezer értelmetlen redirect maradjon a rendszerben.

Hogyan optimalizáld az XML sitemapet?

A sitemapbe elsősorban a canonical, indexelhető és valóban fontos URL-ek kerüljenek, ne a webáruház teljes technikai URL-készlete.

Nagy webshopnál érdemes külön sitemapeket használni például:

• termékekhez;
• kategóriákhoz;
• márkaoldalakhoz;
• tartalmi oldalakhoz.

Így könnyebben ellenőrizheted az egyes URL-csoportokat a Google Search Console-ban is.

Ha egy termék megszűnik és már nem indexelhető, ne maradjon hosszú távon automatikusan a sitemapben.

Hogyan javítsd a belső linkelést?

A fontos termékek és kategóriák legyenek logikusan elérhetők a webáruház belső linkstruktúráján keresztül, miközben a technikai URL-ek ne kapjanak szükségtelenül tömeges követhető linkeket.

Egy jól felépített struktúra például:

Főoldal → Női cipők → Futócipők → konkrét termék

Ezt kiegészítheti:

• breadcrumb;
• kapcsolódó termékek;
• kapcsolódó kategóriák;
• vásárlási útmutatók;
• releváns blogcikkek.

Közben ellenőrizd, hogy a belső linkek közvetlenül 200-as végleges URL-ekre mutatnak-e, és nem régi redirecteken keresztül.

Miért fontos a szerver teljesítménye?

Nagy webáruháznál a szerver stabilitása különösen fontos, mert a Googlebot mellett valódi vásárlók és számos háttérfolyamat is folyamatosan terhelheti a rendszert.

Figyeld:

• az átlagos válaszidőt;
• az 5xx hibákat;
• az adatbázis terhelését;
• a cache működését;
• az időtúllépéseket.

Egy jól strukturált URL-rendszer sem működik optimálisan, ha a Googlebot rendszeresen 503-as vagy 504-es válaszokat kap.

Milyen sorrendben optimalizálj?

Először a legnagyobb URL-pazarlást okozó problémákat javítsd, és csak ezután foglalkozz az apró technikai részletekkel.

Én ezt a sorrendet követném:

1. Térképezd fel a teljes URL-készletet.
2. Azonosítsd a szűrt és paraméteres URL-eket.
3. Vizsgáld meg a belső keresési oldalakat.
4. Ellenőrizd a canonical beállításokat.
5. Tisztítsd meg az XML sitemapet.
6. Javítsd a hibás és redirectelő belső linkeket.
7. Vizsgáld felül a megszűnt termékek kezelését.
8. Ellenőrizd a szerverhibákat és válaszidőket.
9. Elemezd a Googlebot tényleges aktivitását szerverlogokból.
10. Hasonlítsd össze a crawl aktivitást az üzletileg fontos URL-ekkel.

Egy nagy webáruháznál különösen értékes lehet a logelemzés. Ebből kiderülhet, hogy a Googlebot kéréseinek mekkora része jut valódi termékekre és kategóriákra, illetve mennyi megy el paraméteres vagy technikai URL-ekre.

A jól optimalizált webáruház nem attól jó, hogy a Googlebot minél több URL-t crawlol. Attól jó, hogy a több tízezer vagy százezer lehetséges URL közül a keresőrobot könnyen felismeri és rendszeresen eléri azokat, amelyek valódi keresési, felhasználói és üzleti értéket képviselnek.

Hogyan optimalizáld egy nagy tartalmi weboldal crawl budgetjét?

Egy nagy tartalmi weboldal crawl budgetjét úgy optimalizáld, hogy a Googlebot könnyen megtalálja a fontos, friss és értékes cikkeket, miközben csökkented a duplikált, elavult, technikai és alacsony értékű URL-ek felesleges feltérképezését. Több tízezer cikk esetén már nemcsak a tartalom minősége, hanem az URL-struktúra, a belső linkelés, a sitemap és a szerver teljesítménye is meghatározó.

Egy nagy magazin, híroldal, tudástár vagy több témakört lefedő szakmai portál crawl szempontból más problémákkal találkozik, mint egy webáruház. Itt általában nem a termékszűrők jelentik a legnagyobb veszélyt, hanem a címkeoldalak, szerzői archívumok, dátumarchívumok, lapozások, régi cikkek és egymást átfedő kategóriák.

Mely oldalakat tekintsd a legfontosabbnak?

Elsősorban azokat az URL-eket tedd könnyen feltérképezhetővé, amelyek egyedi, keresési szándékot kielégítő tartalmat kínálnak, vagy fontos szerepet töltenek be a webhely információs struktúrájában.

Egy nagy tartalmi portálnál ezek lehetnek:

• részletes szakmai cikkek;
• friss bejegyzések;
• pillar oldalak;
• fontos kategóriaoldalak;
• tematikus gyűjtőoldalak;
• evergreen útmutatók;
• kalkulátorok és más önálló eszközök.

Ha például egy kutyás portálon több ezer cikk található, a „Kutya betegségek” fő témából logikusan elérhető lehet a cukorbetegség, epilepszia, zöldhályog és más betegségek részletes útmutatója.

Így nem elszigetelt URL-ek halmazát, hanem követhető tartalmi hierarchiát alakítasz ki.

Mit kezdj a címke- és archívumoldalakkal?

Vizsgáld meg, hogy a címkék és archívumok valódi felhasználói vagy keresési értéket képviselnek-e, mert egy kontrollálatlan címkerendszer rengeteg gyenge URL-t hozhat létre.

Tipikus probléma, amikor egy 10 000 cikkes portálhoz 15 000 címke tartozik, és sok címke alatt mindössze egyetlen bejegyzés található.

Például:

/cimke/kutya/

/cimke/kutyak/

/cimke/kutyatartas/

/cimke/kutya-tartasa/

Ezek jelentős tartalmi átfedést okozhatnak.

Nem kell automatikusan minden címkeoldalt megszüntetned. Ha például egy jól felépített címkeoldal 40 releváns cikket rendszerez egy valódi keresési téma köré, akár értékes landing oldal is lehet.

Hogyan kezeld a régi tartalmakat?

Ne törölj egy cikket pusztán azért, mert régi. Inkább azt vizsgáld meg, hogy továbbra is pontos, hasznos, keresett és egyedi-e.

Egy 2019-ben publikált „Hogyan kell levendulát metszeni?” útmutató 2026-ban is értékes lehet, ha a tartalma szakmailag helyes és naprakész.

Más a helyzet egy olyan cikkel, amely elavult információkat tartalmaz, nincs organikus forgalma, nincs értékes backlinkje, és egy újabb tartalom már sokkal jobban lefedi ugyanazt a keresési szándékot.

Ilyenkor több lehetőséged van:

• tartalomfrissítés;
• összevonás egy erősebb cikkel;
• releváns 301-es átirányítás;
• indokolt esetben eltávolítás.

A cél nem a régi URL-ek mechanikus törlése, hanem az alacsony értékű tartalmi készlet tudatos kezelése.

Hogyan segítsd az új cikkek gyors felfedezését?

Az új tartalmakat már publikáláskor illeszd be a webhely belső linkstruktúrájába, és gondoskodj arról, hogy az XML sitemap is megfelelően tartalmazza őket.

Ha publikálsz egy új cikket a „Milyen gyakran kell tisztítani a klímát?” témában, ne maradjon magára.

Kaphat belső linket például:

Klíma → Klíma karbantartás → Klímatisztítás

struktúrából, valamint kapcsolódó cikkekből is.

Ezzel a Googlebot több természetes útvonalon találkozhat az új URL-lel.

Hogyan kezeld a lapozást?

A többoldalas kategóriák és archívumok lapozását úgy alakítsd ki, hogy a Googlebot a mélyebben található cikkekhez is el tudjon jutni.

Egy 5000 cikket tartalmazó kategóriánál problémás lehet, ha az első oldalról csak a legújabb 20 tartalom érhető el, a régebbi cikkek pedig nehezen felfedezhető struktúrába kerülnek.

A tematikus alkategóriák, hub oldalak és kontextuális belső linkek sokkal hatékonyabbá tehetik a struktúrát.

Ne kizárólag a kronologikus archívumra bízd a régi tartalmak felfedezését.

Miért fontosak a pillar és cluster oldalak?

A pillar–cluster struktúra segíthet abban, hogy a nagy tartalmi készlet logikus témacsoportokra bomoljon, amelyek között a Googlebot és a felhasználó is könnyebben navigálhat.

Egy SEO-portálon például létrejöhet:

Technikai SEO

→ crawl budget
→ robots.txt
→ XML sitemap
→ canonical
→ indexelés
→ JavaScript SEO
→ belső linkelés

A fő témát egy erős pillar oldal fogja össze, a részletes cikkek pedig oda-vissza kapcsolódnak hozzá és egymáshoz.

Ez crawl szempontból is sokkal rendezettebb, mint több ezer egymástól elszigetelt bejegyzés.

Mit tegyél az árva cikkekkel?

Rendszeresen keresd meg azokat az értékes cikkeket, amelyekre már nem mutat belső link, és helyezd vissza őket a megfelelő tematikus struktúrába.

Nagy portálokon ez könnyen előfordulhat kategóriák átalakítása, menük cseréje vagy több éves tartalomgyártás után.

Egy fontos cikk lehet az XML sitemapben és akár organikus forgalmat is kaphat, miközben belső linkstruktúra szempontjából árva.

Az ilyen URL-eket érdemes összekapcsolni:

• kategóriaoldalakkal;
• pillar tartalmakkal;
• kapcsolódó cikkekkel;
• tematikus gyűjtőoldalakkal.

Hogyan használd az XML sitemapet?

Nagy tartalmi portálnál csak a valóban indexelhető, canonical és értékes URL-eket szerepeltesd a sitemapekben, és szükség esetén bontsd őket logikus csoportokra.

Használhatsz például külön sitemapet:

• cikkekhez;
• kategóriákhoz;
• statikus oldalakhoz;
• más fontos tartalomtípusokhoz.

Ne kerüljenek bele feleslegesen 404-es, átirányított, noindex vagy technikai URL-ek.

Hogyan mérd, hogy javult-e a feltérképezés?

Ne pusztán azt nézd, hogy nőtt-e a Googlebot kéréseinek száma, hanem azt, hogy a fontos tartalmak gyorsabban és következetesebben kerülnek-e feltérképezésre.

Érdemes összevetni a Google Search Console Crawl Stats adatait, az indexelési információkat, az XML sitemapeket és nagy webhely esetén a szerverlogokat.

Figyelheted például:

• milyen gyorsan fedezi fel a Google az új cikkeket;
• milyen gyakran crawlolja a fontos evergreen oldalakat;
• mennyi crawling jut alacsony értékű archívumokra;
• vannak-e tömeges 404 vagy 5xx válaszok;
• találhatók-e árva tartalmak;
• mennyi technikai vagy duplikált URL-t crawlol a Googlebot.

Egy nagy tartalmi oldal crawl budget optimalizálásának végső célja nem az, hogy minden URL ugyanolyan gyakran kapjon Googlebot-látogatást. Éppen ellenkezőleg: olyan világos tartalmi hierarchiát érdemes kialakítanod, amelyben az új, frissített és SEO szempontból fontos oldalak könnyen elérhetők, miközben a technikai zaj, a felesleges archívumok és az értéktelen URL-ek nem vonják el a feltérképezési erőforrásokat.

Milyen crawl budget hibákat érdemes elkerülni?

A leggyakoribb crawl budget hibák közé tartozik a felesleges URL-ek tömeges generálása, a fontos oldalak véletlen blokkolása, a hibás robots.txt és noindex használat, a redirectláncok, a rendezetlen sitemap, valamint az a tévhit, hogy minden webhelynek agresszíven optimalizálnia kell a crawl budgetjét. A cél nem a Googlebot minél erősebb korlátozása, hanem a feltérképezés hatékonyabbá tétele.

Egy rosszul átgondolt technikai módosítás ugyanis nagyobb SEO-kárt okozhat, mint maga a feltételezett crawl budget probléma. Különösen igaz ez akkor, ha robots.txt szabályokat, canonical címkéket vagy indexelési utasításokat tömegesen módosítasz.

Miért hiba mindenáron csökkenteni a Googlebot crawlingját?

Ne abból indulj ki, hogy minél kevesebb oldalt crawlol a Google, annál jobb a crawl budget. A fontos URL-ek rendszeres feltérképezésére szükséged van.

Ha egy 400 oldalas villanyszerelői webhelyen nincs URL-robbanás, a szerver megfelelően működik, és a fontos oldalak rendszeresen feltérképezhetők, valószínűleg nincs szükséged komoly crawl budget beavatkozásra.

A túlzott optimalizálással viszont véletlenül megnehezítheted a Google dolgát.

Mindig azt vizsgáld:

„Van tényleges feltérképezési problémám, vagy csak optimalizálni próbálok egy olyan mutatót, amely jelenleg nem korlátozza a webhelyemet?”

Miért veszélyes túl sok mindent blokkolni a robots.txt-ben?

Egy túl általános robots.txt szabállyal fontos kategóriákat, termékeket vagy akár a rendereléshez szükséges erőforrásokat is elzárhatod a Googlebot elől.

Például észreveszed, hogy rengeteg URL tartalmaz egy bizonyos paramétert, ezért egyetlen szabállyal letiltod az összes ilyen útvonalat.

Csakhogy később kiderül, hogy a minta olyan szűrt kategóriaoldalakat is érintett, amelyek organikus forgalmat hoztak.

Ezért minden nagyobb robots.txt módosítás előtt ellenőrizd pontosan, milyen URL-készletet érint a szabály.

Miért hiba a noindex és robots.txt összekeverése?

A noindex az indexelést, a robots.txt pedig a feltérképezést szabályozza. Ha ezt a két funkciót összekevered, könnyen egymásnak ellentmondó technikai jelzéseket hozhatsz létre.

Különösen problémás lehet, ha egy URL-re noindexet helyezel, majd robots.txt-ben megakadályozod, hogy a Googlebot lekérje az oldalt.

A bot így nem feltétlenül tudja feldolgozni a noindex utasítást.

Miért hiba azt hinni, hogy a canonical megakadályozza a crawlingot?

A canonical nem crawl blokkoló eszköz. A Googlebotnak fel kell fedeznie és adott esetben fel kell térképeznie a duplikált URL-t ahhoz, hogy annak canonical jelzését feldolgozza.

Tegyük fel, hogy egy webáruházban 500 000 szűrt URL canonicalja a fő kategóriaoldalra mutat.

Ez segíthet az elsődleges URL azonosításában, de attól még nem feltétlenül oldottad meg azt a problémát, hogy a Googlebot több százezer paraméteres URL-t találhat.

Ha a crawl pazarlás jelentős, magát az URL-generálást és a felfedezhetőséget is vizsgálnod kell.

Miért hiba minden 404-es URL-t átirányítani?

A 404 természetes HTTP-válasz egy valóban megszűnt, megfelelő helyettesítővel nem rendelkező URL esetén. Nem kell minden hibás vagy megszűnt oldalt automatikusan a főoldalra irányítanod.

Egy régi menyasszonyi ruha termékoldalának megszűnésekor például lehet értelme 301-es átirányításnak, ha ugyanannak a modellnek van egyértelmű új URL-je.

Ha nincs releváns helyettesítő, a főoldalra történő automatikus redirect nem lesz jobb csak azért, mert megszünteti a 404-et.

A cél mindig a valós tartalmi állapot megfelelő technikai kommunikációja legyen.

Miért hiba elhanyagolni a sitemapet?

A rendezetlen XML sitemap ellentmondásos jelzéseket küldhet arról, mely URL-eket tekinted fontosnak és indexelhetőnek.

Gyakori probléma, hogy a sitemapben hosszú időn keresztül bent maradnak:

• 404-es URL-ek;
• 301-es URL-ek;
• noindex oldalak;
• paraméteres duplikációk;
• már megszűnt termékek;
• nem canonical URL-ek.

Egy nagy webhelyen ezt érdemes rendszeresen automatizáltan is ellenőrizni.

Miért hiba figyelmen kívül hagyni a belső linkeket?

Hiába tiszta a sitemap, ha a webhely belső linkrendszere közben tömegesen hibás, átirányított vagy értéktelen URL-eket kínál fel a Googlebotnak.

Egy nagy építőipari portálon például több ezer cikkből vezethetnek régi URL-ekre mutató linkek.

Ha az URL-ek 301-en keresztül továbbítanak a megfelelő új oldalra, a felhasználó talán észre sem veszi a problémát.

Technikailag mégis jobb:

cikk → végleges URL

mint:

cikk → régi URL → 301 → végleges URL.

A belső linkeket ezért URL-migráció után is érdemes frissíteni.

Miért hiba csak a crawl-kérések számát figyelni?

A magas crawl-kérésszám önmagában nem siker, az alacsony pedig nem feltétlenül probléma. A crawling minősége és eloszlása fontosabb a puszta mennyiségnél.

Tegyük fel, hogy technikai optimalizálás előtt a Googlebot naponta nagy mennyiségű paraméteres URL-t crawlol.

A javítás után a crawl-kérések száma visszaesik, de közben az új termékeket gyorsabban fedezi fel, és a fontos kategóriákat rendszeresen újracrawlolja.

Ez kifejezetten jó eredmény lehet.

Miért hiba egyszerre mindent megváltoztatni?

Nagy webhelyen a crawl szabályok tömeges, egyszerre történő módosítása megnehezíti a hibák felismerését, és komoly indexelési problémát is okozhat.

Ha egyszerre változtatod meg:

• a robots.txt fájlt;
• a canonicalokat;
• a noindex szabályokat;
• az URL-struktúrát;
• a sitemapet;
• a belső linkelést;

akkor egy későbbi forgalom- vagy indexelési visszaesésnél nehéz lesz megállapítani, melyik változtatás okozta a problémát.

Nagyobb beavatkozásoknál ezért priorizálj, dokumentálj, tesztelj és mérd az eredményt.

Mi a legnagyobb crawl budget hiba?

A legnagyobb hiba az, ha a crawl budgetet önálló SEO-célként kezeled ahelyett, hogy a webhely feltérképezhetőségének egyik technikai részterületeként tekintenél rá.

Nem az a cél, hogy elérj egy bizonyos napi crawl-számot.

A valódi kérdés inkább ez:

„A Googlebot könnyen megtalálja és rendszeresen fel tudja térképezni azokat az URL-eket, amelyek számomra valóban fontosak?”

Ha igen, miközben kevés erőforrás megy el végtelen URL-terekre, duplikációkra, hibás linkekre és technikai zajra, akkor jó irányba haladsz.

A crawl budget optimalizálás lényege végső soron nem a Googlebot korlátozása, hanem egy tiszta, gyors és logikus webhely kialakítása, amelyben a keresőnek nem kell több százezer felesleges URL között keresnie az értékes tartalmaidat.

Hogyan készíts crawl budget auditot?

A crawl budget audit során azt vizsgálod meg, hogy a Googlebot milyen URL-eket térképez fel, mire fordít felesleges erőforrást, és mennyire könnyen jut el a SEO szempontból fontos oldalakhoz. Egy jó audit nem egyetlen crawl-számot keres, hanem összeveti a Search Console, a szerverlogok, az XML sitemap, a belső linkstruktúra és a technikai crawl adatait.

Nagy webhely esetén én az auditot mindig URL-csoportok alapján végezném. Külön kezelném például a termékeket, kategóriákat, cikkeket, címkéket, szűrőket, paraméteres URL-eket és hibás oldalakat. Így nemcsak azt látod, hogy mit crawlol a Google, hanem azt is, hogy a crawling megfelelő helyre koncentrálódik-e.

Milyen adatokra van szükséged a crawl budget audithoz?

Legalább a Google Search Console adatait, az XML sitemapet és a webhely teljes technikai crawl eredményét érdemes megvizsgálnod; nagyobb webhelyeknél pedig a szerverlogok elemzése adja a legpontosabb képet a Googlebot tényleges aktivitásáról.

Hasznos adatforrások:

• Google Search Console Crawl Stats;
• Search Console indexelési adatok;
• XML sitemapek;
• teljes webhelycrawl;
• szerver access logok;
• belső linkadatok;
• HTTP státuszkódok;
• canonical és robots utasítások.

A különböző források más kérdésre válaszolnak. A crawler például megmutathatja, milyen URL-ek érhetők el a belső linkeken keresztül, míg a szerverlogból kiderülhet, hogy a Googlebot ténylegesen mely URL-eket kérte le.

Hogyan térképezd fel a webhely teljes URL-készletét?

Az audit egyik legfontosabb lépése annak meghatározása, hogy hány valódi tartalmad van, és ehhez képest hány különböző URL-t tud felfedezni a Google.

Ez a két szám jelentősen eltérhet.

Egy webáruházban például lehet:

• 25 000 termék;
• 800 kategória;
• 300 tartalmi oldal;

miközben a szűrők, rendezések és paraméterek miatt több százezer különböző URL válik elérhetővé.

Ez azonnal felvet egy fontos kérdést:

Miért létezik ennyi URL, ha a valódi indexelésre szánt tartalmak száma ennek csak töredéke?

Csoportosítsd az URL-eket típus szerint, mert így sokkal könnyebben megtalálhatod a problémás mintákat.

Hogyan vizsgáld meg a Googlebot tényleges aktivitását?

Nagy webhelyen szerverlogokból érdemes megvizsgálnod, hogy a Googlebot mely URL-csoportokat milyen gyakran kéri le, és milyen HTTP-válaszokat kap.

Például azt találod, hogy egy 100 000 URL-es kereskedelmi oldal Googlebot-kérései jelentős részben ilyen címekre érkeznek:

?sort=price

?view=grid

?filter_color=black

?session=

Ez már konkrét bizonyíték arra, hogy a Googlebot technikai URL-ekre is jelentős figyelmet fordít.

Ezzel szemben, ha a crawling túlnyomó része fontos termék-, kategória- és tartalmi URL-ekre jut, sokkal kedvezőbb a helyzet.

Hogyan ellenőrizd a HTTP státuszkódokat?

Az audit során különítsd el a sikeres 200-as URL-eket, az átirányításokat, a 404/410 oldalakat és az 5xx szerverhibákat.

Különösen keresd:

• tömeges 404-eket;
• soft 404-eket;
• redirectláncokat;
• redirect loopokat;
• 500-as hibákat;
• 503-as és 504-es válaszokat.

Egy-egy 404 nem probléma. Ha viszont több tízezer hibás URL-t továbbra is belső linkek vagy sitemapek kínálnak fel a Googlebotnak, már érdemes beavatkozni.

Az 5xx hibákat magas prioritással kezeld, mert ezek a szerver megbízhatóságát és a feltérképezési kapacitást is érinthetik.

Hogyan ellenőrizd az XML sitemapet?

Hasonlítsd össze a sitemap URL-jeit a webhely tényleges technikai állapotával, és keresd az egymásnak ellentmondó jelzéseket.

Ellenőrizd, található-e benne:

• 404-es URL;
• redirectelő URL;
• noindex oldal;
• robots.txt-ben blokkolt oldal;
• nem canonical URL;
• szükségtelen paraméteres URL.

Ezután fordítsd meg a vizsgálatot.

Vannak fontos, indexelhető URL-ek, amelyek hiányoznak a sitemapből?

Így nemcsak a felesleges elemeket találod meg, hanem a hiányosságokat is.

Hogyan auditáld a belső linkelést?

Keresd meg azokat a fontos oldalakat, amelyek túl mélyen helyezkednek el, kevés belső linket kapnak vagy teljesen árva URL-ek.

Vizsgáld:

• a crawl depth értékeket;
• az árva oldalakat;
• a 404-re mutató belső linkeket;
• a redirectelő belső linkeket;
• a túl sok technikai URL-re vezető linket;
• a fontos oldalak belső linkjeinek számát.

Egy 5000 cikkes szakmai portálnál például gyanús lehet, ha egy értékes evergreen útmutató kizárólag a sitemapből érhető el, miközben egy jelentéktelen címkeoldal több száz belső linket kap.

Hogyan vizsgáld a duplikált és paraméteres URL-eket?

Keress URL-mintákat, ne egyenként próbáld javítani a problémás oldalakat. Több százezer hibás URL mögött gyakran mindössze néhány technikai szabály áll.

Például:

?sort=

?filter=

?view=

?session=

Ha egyetlen rendezési funkció 80 000 felesleges URL-t hoz létre, sokkal hatékonyabb a kiváltó technikai okot megszüntetni, mint URL-enként kezelni a következményt.

Ugyanez vonatkozik a címkékre, dátumarchívumokra, belső keresésekre és hibás lapozásra is.

Hogyan állíts fel prioritási sorrendet?

A hibákat a várható SEO-hatás és az érintett URL-ek mennyisége alapján rangsorold, ne egyszerűen a talált problémák darabszáma alapján.

Én például így priorizálnék:

Ezzel elkerülheted, hogy több órát tölts tíz jelentéktelen 404-es URL javításával, miközben a Googlebot százezres nagyságrendű felesleges szűrőoldalt jár be.

Hogyan mérd az audit utáni eredményeket?

A crawl budget audit nem ér véget a hibák kijavításával: utána azt kell ellenőrizned, hogy a Googlebot viselkedése valóban kedvező irányba változott-e.

A változtatások után figyeld:

• a fontos URL-ek crawl gyakoriságát;
• az új oldalak felfedezési sebességét;
• a felesleges URL-ekre jutó crawlingot;
• az 5xx hibákat;
• a szerver válaszidejét;
• az indexelésre szánt URL-ek állapotát.

Ne várd, hogy minden változás azonnal megjelenjen. A Google-nek időre lehet szüksége az URL-struktúra újbóli feldolgozásához.

Egy jó crawl budget audit végén pontosan meg kell tudnod mondani, mely URL-eket szeretnéd a Google-lel rendszeresen feltérképeztetni, mely URL-csoportok okoznak felesleges crawlingot, mi generálja ezeket, és milyen technikai módosítással lehet megszüntetni a problémát.

A legjobb eredmény nem feltétlenül a több Googlebot-kérés. Az audit akkor sikeres, ha a Google feltérképezési aktivitása jobban összpontosul azokra az oldalakra, amelyek valóban fontosak a keresési láthatóságod szempontjából.

Hogyan mérheted a crawl budget optimalizálás eredményét?

A crawl budget optimalizálás eredményét nem az összes Googlebot-kérés növekedésével érdemes mérned, hanem azzal, hogy a Google hatékonyabban térképezi-e fel a fontos URL-eket. Akkor jó az eredmény, ha csökken a felesleges crawling, gyorsabban fedezi fel az új és frissített tartalmakat, mérséklődnek a technikai hibák, és a feltérképezési aktivitás nagyobb része jut az értékes oldalakra.

Ezért nincs egyetlen olyan KPI, amelyből kijelentheted, hogy a crawl budget optimalizálása sikeres volt. Több adatot kell egymással összevetned, lehetőleg a módosítások előtti és utáni időszakból.

Milyen mutatókat érdemes figyelned?

Elsősorban a fontos URL-ek feltérképezési gyakoriságát, az új tartalmak felfedezésének idejét, a hibás URL-ekre jutó kéréseket, a szerver válaszidejét és az alacsony értékű URL-ek crawlingját érdemes összehasonlítanod.

Használhatsz egy egyszerű mérési keretrendszert:

A hangsúly az arányokon és a crawling minőségén legyen.

Hogyan használd a Google Search Console Crawl Stats adatait?

A Crawl Stats jelentésből megfigyelheted a Googlebot aktivitásának alakulását, a szerver válaszidejét és a különböző HTTP-válaszok megoszlását.

Ne csak azt nézd, hogy korábban például napi 20 000, később pedig 15 000 crawl-kérés történt.

A csökkenés önmagában nem negatív.

Tegyük fel, hogy egy webáruház technikai tisztítása előtt a Googlebot nagy mennyiségben crawlolta a rendezési és szűrési URL-eket. Ezek megfelelő kezelése után az összes crawl-kérés száma visszaesik.

Közben viszont:

• az új termékek gyorsan felfedezhetők;
• a fontos kategóriák rendszeresen crawlolódnak;
• kevesebb 404 jelenik meg;
• csökken a szerver terhelése.

Ebben az esetben a kevesebb crawl-kérés jobb eredményt jelenthet.

Hogyan mérd az új oldalak felfedezésének sebességét?

Figyeld meg, mennyi idő telik el egy fontos új URL publikálása és a Google első feltérképezése között. Ez különösen hasznos mutató gyakran frissülő webhelyeknél.

Egy nagy híroldalon, állásportálon vagy webáruházban ez sokkal fontosabb lehet, mint egy 100 oldalas, évente néhányszor frissülő céges honlapnál.

Például mérheted:

publikálás időpontja → első Googlebot-kérés időpontja

Ha korábban az új termékek vagy cikkek jelentős részének felfedezése rendszeresen hosszú időt vett igénybe, majd a belső linkstruktúra és sitemap javítása után ez következetesen gyorsul, az kedvező jel.

Hogyan mérd a frissített tartalmak újracrawlolását?

Nemcsak az új URL-ek felfedezése számít: egy gyakran frissített webhelyen az is fontos, hogy a Google ésszerű időn belül visszatérjen a módosított, fontos oldalakhoz.

Tegyük fel, hogy egy SEO-portálon jelentősen frissítesz egy fontos útmutatót. Új fejezeteket, példákat és technikai információkat adsz hozzá.

Megfigyelheted:

frissítés dátuma → következő Googlebot-látogatás

Ezt nagyobb mennyiségben már szerverlogok segítségével érdemes elemezni.

Nem szükséges azonban minden oldalnak azonos crawl gyakoriságot elérnie. Egy naponta változó terméklista és egy ötéves, változatlan fogalommagyarázó oldal természetesen eltérő crawlingot kaphat.

Mit mutathat meg a szerverlog-elemzés?

A szerverlogok segítségével URL-szinten mérheted, hogy a Googlebot kéréseinek mekkora része jut értékes és mekkora része felesleges URL-ekre.

Ez nagy webhelyeknél az egyik leghasznosabb mérési módszer.

Például kialakíthatsz URL-csoportokat:

• termékoldalak;
• kategóriaoldalak;
• cikkek;
• paraméteres URL-ek;
• belső keresések;
• 404-ek;
• redirectek.

Ezután összehasonlíthatod az optimalizálás előtti és utáni állapotot.

Egy szemléltető példa:

Ezek nem elérendő iparági benchmarkok, csak azt szemléltetik, hogyan mérheted a crawling eloszlásának változását.

Érdemes az indexelt oldalak számát is figyelni?

Igen, de az indexelt URL-ek száma önmagában nem megfelelő crawl budget KPI, mert a crawling és az indexelés két külön folyamat.

Ha egy 50 000 oldalas webhelyből csak 30 000 URL indexelt, abból még nem következik, hogy kevés a crawl budget.

Lehet például:

• duplikált tartalom;
• canonical probléma;
• gyenge tartalom;
• noindex utasítás;
• technikai indexelési probléma.

Ezért először azt vizsgáld meg, hogy a Google feltérképezte-e az URL-t.

Ha igen, de nem indexelte, akkor valószínűleg nem pusztán crawl budget problémával állsz szemben.

Mennyi idő után érdemes eredményt mérni?

A crawl budget optimalizálás hatását ne néhány óra vagy egyetlen nap alapján értékeld, mert a Google-nek időre lehet szüksége az új URL-struktúra és technikai jelzések feldolgozásához.

A mérési időszak függ:

• a webhely méretétől;
• a Googlebot korábbi aktivitásától;
• a módosítás nagyságától;
• az URL-ek számától;
• a tartalom frissítési gyakoriságától.

Érdemes ezért azonos hosszúságú időszakokat összehasonlítani, és figyelembe venni a szezonális vagy technikai kiugrásokat is.

Egyetlen rendkívüli crawl napból ne vonj le messzemenő következtetést.

Mi számít valódi sikernek?

A crawl budget optimalizálás akkor sikeres, ha a Googlebot feltérképezési aktivitása jobban igazodik a webhelyed SEO-prioritásaihoz.

Egy jól optimalizált állapotban például:

• az új fontos oldalak könnyen felfedezhetők;
• a frissített tartalmakhoz a Google visszatér;
• az értékes kategóriák és termékek megfelelő figyelmet kapnak;
• kevesebb crawling jut technikai URL-ekre;
• csökkennek a felesleges redirectek;
• mérséklődnek a szerverhibák;
• az árva oldalak száma csökken;
• a sitemap tisztábbá válik;
• a szerver stabilan kiszolgálja a Googlebotot.

Ne egy mesterségesen magas crawl-számot tekints célnak. Sokkal értékesebb, ha 100 000 Googlebot-kérésből nagyobb arány jut a valóban fontos tartalmakra, mint ha 300 000 kérés jelentős része paraméteres, duplikált vagy hibás URL-eket jár be.

A legjobb mérőszám ezért végső soron a crawl hatékonysága: a Google a rendelkezésére álló feltérképezési kapacitásból mennyit fordít azokra az URL-ekre, amelyeket valóban szeretnél megtaláltatni, frissen tartani és a keresőben láthatóvá tenni.

GYIK – gyakori kérdések a crawl budgetről

Mi az a crawl budget egyszerűen?

A crawl budget azt írja le, hogy a Google milyen mértékben tudja és akarja feltérképezni a webhelyed URL-jeit egy adott időszakban. Nagy webhelyeken azért különösen fontos, mert nem mindegy, hogy a Googlebot értékes tartalmakat vagy felesleges URL-változatokat jár be.

Van minden weboldalnak crawl budgetje?

A Google minden webhely feltérképezését valamilyen módon szabályozza, de külön crawl budget optimalizálással elsősorban nagy vagy technikailag összetett webhelyeknél érdemes foglalkoznod.

Befolyásolja a crawl budget a Google-helyezést?

Nem közvetlen rangsorolási faktor. Közvetetten azonban problémát jelenthet, ha fontos oldalaidat a Google nem vagy csak ritkán térképezi fel.

Hogyan növelhetem a crawl budgetet?

Ne önmagában a crawl budget növelése legyen a cél, hanem a Googlebot erőforrásainak hatékonyabb felhasználása. Javítsd a szerver stabilitását, szüntesd meg a felesleges URL-eket, és építs egyértelmű belső linkstruktúrát.

Segít az XML sitemap a crawl budget optimalizálásában?

Igen, közvetetten segíthet a fontos URL-ek felfedezésében, de nem garantál crawlingot vagy indexelést. A sitemapben elsősorban canonical, indexelhető és értékes URL-ek szerepeljenek.

A noindex megspórolja a crawl budgetet?

Nem feltétlenül, mert a Googlebotnak crawlolnia kell az URL-t ahhoz, hogy felismerje a noindex utasítást. Ezért a noindexet nem érdemes egyszerű crawl-blokkoló eszközként kezelni.

A robots.txt javíthatja a crawl budgetet?

Bizonyos esetekben igen, mert megakadályozhatod vele teljesen felesleges URL-területek crawlingját. Hibás használata ugyanakkor fontos oldalak feltérképezését is megakadályozhatja.

Sok 404-es oldal elpazarolja a crawl budgetet?

Néhány 404 teljesen természetes, és önmagában nem probléma. Tömegesen generált hibás URL-ek vagy 404-re mutató belső linkek azonban már felesleges crawlingot okozhatnak.

Miért fontosak a belső linkek a crawling szempontjából?

A belső linkek segítségével fedezi fel a Googlebot a webhelyed jelentős részét, és ezek a linkek a webhely struktúrájáról is információt adnak. A fontos oldalaknak ezért jól elérhető helyen kell lenniük.

Mekkora weboldalnál kell komolyan foglalkozni a crawl budgettel?

Nincs univerzális URL-határ, amely fölött automatikusan crawl budget problémád lesz. A webhely mérete mellett az URL-generálás, a változások gyakorisága, a szerver teljesítménye és az oldalstruktúra is számít.

Hogyan ellenőrizhetem a crawl budgetet?

Kezdd a Google Search Console Feltérképezési statisztikák jelentésével, nagyobb webhely esetén pedig egészítsd ki szerverlog-elemzéssel. Így nemcsak azt látod, mennyit crawlol a Google, hanem azt is, hogy milyen URL-ekre fordítja az erőforrásait.

Mennyi idő alatt látható a crawl budget optimalizálás eredménye?

Nincs fix időtartam. A Googlebotnak először újra fel kell térképeznie a módosított URL-struktúrát, ezért a változás sebessége függ a webhely méretétől, crawl aktivitásától és az elvégzett módosításoktól.

Miért érdemes befektetni egy jó SEO – AI szakértőbe?

A SEO ma már jóval többről szól, mint néhány kulcsszó optimalizálásáról. Az AI Overviews, a GEO (Generative Engine Optimization), a szemantikus SEO, az entitásalapú keresés és a topical authority korában azok a weboldalak kerülnek előnybe, amelyek valódi szakértői tudásközpontként jelennek meg a Google és az AI-alapú keresők számára.

Egy profi SEO szakértő nemcsak a jobb helyezések elérésében segít, hanem olyan hosszú távú stratégiát épít, amely növeli a weboldalad láthatóságát, erősíti a márkádat, és releváns érdeklődőket hoz az oldaladra. A megfelelően felépített SEO nem egyszeri költség, hanem olyan befektetés, amely hónapokon és éveken keresztül képes folyamatos forgalmat és új ügyfeleket generálni.

A keresési környezet folyamatosan változik. A Google algoritmusai, az AI-alapú találatok és a felhasználói szokások is egyre gyorsabban alakulnak. Egy tapasztalt SEO szakember segít alkalmazkodni ezekhez a változásokhoz, kiépíteni a szükséges topical authorityt, valamint olyan tartalomstratégiát kialakítani, amely nemcsak ma, hanem a jövő keresőiben is versenyképes marad. Egy rosszul kivitelezett SEO munka viszont könnyen idő-, pénz- és forgalomveszteséget okozhat, ezért különösen fontos, hogy a weboldalad optimalizálását valódi szakértőre bízd.

Miért érdemes választani a HonlapSEO-t?

Több éve foglalkozom keresőoptimalizálással, és munkám során nemcsak a hagyományos SEO-ra, hanem a modern keresési trendekre, az AI-alapú keresésekre és a GEO (Generative Engine Optimization) stratégiákra is kiemelt figyelmet fordítok. Segítek abban, hogy weboldalad ne csupán jobb helyezéseket érjen el a Google találati listáján, hanem az AI-alapú rendszerek, például a ChatGPT, a Google AI Overviews vagy a Perplexity számára is hiteles és könnyen feldolgozható forrássá váljon.

Szolgáltatásaim közé tartozik a SEO audit, a technikai optimalizálás, a kulcsszókutatás, a SEO szövegírás, a topical authority építés, a tartalomstratégia kialakítása, valamint a belső linkrendszer és a szemantikus SEO fejlesztése. Minden projekt során hosszú távú gondolkodásra törekszem, hiszen a cél nem csupán a rövid távú helyezésjavulás, hanem egy stabil, folyamatosan növekvő organikus jelenlét kialakítása. Ehhez a havidíjas SEO-t ajánlom.

Ha szeretnéd, hogy weboldalad valódi szakértői státuszt építsen ki a saját piacán, növelje a látogatottságát és felkészüljön az AI-alapú keresések jövőjére, szívesen segítek a megfelelő SEO és GEO stratégia kialakításában.

Keresőoptimalizáláshoz profi Seo szakembert keresel? Azonnal használható, gyors megoldások a Google irányelvei alapján. Megjelennél a a Google AI Overviews találataiban?

Elérhetőségeim:

Burai Barbi SEO szakember, SEO szakértő,

 AI-GEO mentor

Telefon: +36-30-242-9494

E-mail: info(kukac)honlapseo.hu

Web: HonlapSEO   SEO alapok

Eredményes keresőoptimalizáláshoz profi SEO szakembert keresel?

Vedd fel Velem a kapcsolatot az alábbi űrlap kitöltésével: