Crawl budget 2026: multi-bot governance pre AI crawlery

Crawl budget bol dlho okrajovou témou pre veľmi veľké weby. V roku 2026 sa to zmenilo. Okrem Googlebota dnes na weby pristupuje celý rad AI crawlerov, každý s vlastnými cieľmi, vlastnou záťažou a vlastným prínosom. Crawl budget sa tak z čisto googlovskej otázky zmenil na problém multi-bot governance. Tento článok vysvetľuje, ako crawl budget technicky funguje, od kedy je v B2B prostredí regiónu DACH skutočne relevantný a ako v praxi vyzerá diferencované riadenie Googlebota, Bingbota a AI crawlerov.

Prečo je crawl budget v roku 2026 multi-bot problémom

Klasicky crawl budget opisuje, koľko stránok vyhľadávač z webu za určité obdobie načíta. Kým bol relevantný iba Googlebot, týkalo sa to takmer výlučne veľmi veľkých webov. V roku 2026 tento predpoklad nestačí, pretože spektrum crawlerov sa zásadne rozšírilo.

Nárast sa dá zmerať. Podľa medzinárodného vyhodnotenia Cloudflare tvorili AI boty v roku 2025 v ročnom priemere 4,2 percenta všetkých HTML požiadaviek, Googlebot 4,5 percenta, takže bol už len o málo väčší ako všetky AI boty dokopy. Mimoriadne dynamicky rastie AI crawlovanie iniciované používateľmi: v roku 2025 vzrástlo viac ako 15-násobne. Ide o crawlovanie, pri ktorom bot navštívi stránku v reálnom čase ako reakciu na otázku v chatbote. V rámci samotných AI crawlerov sa váha výrazne presunula k OpenAI: podiel GPTBota medzi AI crawlermi stúpol od mája 2024 do mája 2025 z 5 na 30 percent pri raste počtu požiadaviek o 305 percent, zatiaľ čo Bytespider za rovnaké obdobie klesol zo 42 na 7,2 percenta.

Pre rakúsky B2B trh síce zostáva Googlebot najdôležitejším crawlerom, pretože Google v máji 2026 s trhovým podielom 81,87 percenta pred Bingom s 9,01 percenta a DuckDuckGo s 2,75 percenta jasne dominuje. K tomu však pribúdajú AI crawlery: spotrebúvajú serverové zdroje, zaberajú kapacitu edge a CDN a otvárajú otázku, akú protihodnotu ktorý bot prináša. Práve to robí z crawl budgetu tému riadenia pre všetky zainteresované strany, nie iba pre Google.

Crawl Capacity Limit a Crawl Demand: od kedy na tom záleží

Google definuje crawl budget webu ako množstvo URL adries, ktoré Google dokáže a chce crawlovať. Skladá sa z dvoch zložiek: z Crawl Capacity Limit a z Crawl Demand.

• Crawl Capacity Limit: Horná hranica toho, čo server zvládne bez preťaženia. Ak web odpovedá rýchlo a bez chýb, limit stúpa. Ak sa spomalí alebo vracia chyby servera, Google crawlovanie obmedzí, aby web nepreťažoval.
• Crawl Demand: Potreba crawlovať danú URL adresu. Závisí od popularity stránky a od toho, ako často sa mení jej obsah. Zastarané alebo nemenné stránky sa navštevujú zriedkavejšie.

Rozhodujúca je otázka, od kedy to vôbec zohráva úlohu. Google je tu jednoznačný: jeho vlastná príručka je určená pre veľké weby s viac ako 1 miliónom jedinečných stránok a obsahom, ktorý sa mení každý týždeň, a pre stredné a väčšie weby s viac ako 10 000 jedinečnými stránkami a obsahom, ktorý sa mení veľmi často, napríklad denne. Pre typický B2B web v regióne DACH s niekoľkými stovkami stránok preto crawl budget z pohľadu samotného Googlebota zriedka býva úzkym hrdlom.

Toto upokojenie však platí iba pre Googlebota a iba pre klasické crawlovanie. Keď fazetová navigácia, URL adresy filtrov alebo veľký produktový katalóg umelo nafúknu počet URL adries, môže mať problém s crawl budgetom aj stredne veľký web. AI crawlery sa navyše riadia vlastnou logikou, ktorá s prahmi Googlu nemá nič spoločné.

Multi-bot governance: diferencovaná stratégia pre robots.txt

Prvou pákou je robots.txt. V roku 2026 už neslúži len na jednoduché povolenie alebo zákaz. Je to riadiaca tabuľka pre rôzne triedy botov. V medzinárodnom meradle sa robots.txt už dávno stal dejiskom správy AI crawlerov. Podľa Web Almanac 2025 sa v ňom najdôležitejšie AI user agenty už cielene adresujú: 4,5 percenta desktopových súborov robots.txt uvádza GPTBot, 3,6 percenta ClaudeBot, 3,5 percenta CCBot a 3,4 percenta Google-Extended, pričom GPTBot sa oproti roku 2024 takmer zdvojnásobil. Zďaleka najčastejšou direktívou zostáva zástupný znak: catch-all user agent, teda hviezdička (*), sa v roku 2025 objavil v 77 percentách súborov.

Premyslená stratégia rozlišuje boty podľa ich účelu:

• Crawlery vyhľadávačov (Googlebot, Bingbot): Plný prístup. Prinášajú organickú návštevnosť a v regióne DACH tvoria základ biznisu. Tu sa nikdy neblokuje plošne, iba sa cielene predchádza plytvaniu crawl budgetom.
• AI vyhľadávacie crawlery (OAI-SearchBot, PerplexityBot): Obsluhujú odpovede v reálnom čase s uvedením zdroja a potenciálnym referral trafficom. Kto chce byť viditeľný v AI odpovediach, spravidla ich povolí.
• AI tréningové crawlery (GPTBot, ClaudeBot, CCBot, Meta-ExternalAgent): Zbierajú dáta na trénovanie modelov. Tu treba vedome zvažovať, pretože spotrebe zdrojov často nezodpovedá žiadna priama protihodnota.

Dôležité je čisté oddelenie user agentov. Google-Extended pritom nie je samostatný crawler. Podľa Googlu nemá vlastný reťazec user agenta, je to iba riadiaci token pre robots.txt. Obsah sťahujú bežné crawlery Googlu. Token určuje len to, či Google smie obsah použiť na trénovanie modelov Gemini a na grounding. Grounding znamená, že Gemini pri odpovedi na dopyt čerpá ako zdroj obsah z indexu Googlu. Na zaradenie do vyhľadávania Google a na ranking token nevplýva. Kto zablokuje Google-Extended, zachová si teda viditeľnosť v Googli a vylúči iba použitie pre Gemini. Toto rozlíšenie je jadrom multi-bot governance.

Rozlišovanie typov záťaže AI crawlerov: tréning, vyhľadávanie, reálny čas

Plošné blokovanie alebo povolenie prehliada, že AI crawlery plnia tri úplne odlišné úlohy. Medzinárodná analýza dát Cloudflare tento pomer jasne vyčísľuje: tréning dnes poháňa takmer 80 percent aktivity AI botov, 18 percent pripadá na vyhľadávanie a len 2 percentá na akcie iniciované používateľmi.

• Tréningové crawlovanie: Boty ako GPTBot, ClaudeBot alebo CCBot sťahujú obsah na trénovanie modelov. Tento prístup vytvára záťaž, no zriedka vedie k priamo pripísateľnej návštevnosti. Je to typ záťaže s najslabšou bezprostrednou protihodnotou.
• Vyhľadávacie crawlovanie: AI vyhľadávacie systémy načítavajú obsah, aby ho citovali v odpovediach. Tu je šanca na referral traffic a viditeľnosť značky, podobne ako pri klasickom vyhľadávaní.
• Crawlovanie v reálnom čase iniciované používateľmi: Boty ako ChatGPT-User navštívia stránku naživo, pretože používateľ položil v chate otázku. Tento typ záťaže má malý objem, signalizuje však konkrétny záujem používateľa práve o tento obsah v momente dopytu.

Praktický dôsledok: kto chce znížiť náklady na server bez straty viditeľnosti, najprv obmedzí tréningové crawlovanie a ponechá vyhľadávacie crawlovanie aj crawlovanie v reálnom čase. Plošný zákaz všetkých AI botov by naopak odrezal aj potenciálne hodnotné prístupy.

Odstránenie plytvania crawl budgetom

Skôr ako začneš riešiť správu botov, mal by si odstrániť plytvanie, ktoré si web spôsobuje sám. V praxi je to najväčší problém a týka sa všetkých crawlerov rovnako. Ako dramaticky sa pomer môže prevrátiť, ukazuje medzinárodná prípadová štúdia Botify: 97 percent z približne 1 milióna crawlovaných stránok tam bolo nekanonických, pričom indexovateľných URL adries bolo len asi 25 000 a Google z nich mesačne crawloval iba o niečo viac ako polovicu. Podľa toho istého zdroja Google na neoptimalizovaných weboch v celom odvetví crawluje mesačne v priemere iba 40 percent strategických URL adries, 60 percent zostáva necrawlovaných.

Typické zdroje plytvania sa dajú cielene uzavrieť:

• Fazetová navigácia a parametrické URL adresy: Kombinácie filtrov a triedenia vytvárajú takmer neobmedzené množstvo URL adries s takmer rovnakým obsahom. Riešenie: canonical tagy, cielený noindex alebo zablokovanie celých parametrických ciest v robots.txt.
• Duplicitný obsah: Viacero URL adries s identickým obsahom, napríklad pre veľké a malé písmená, koncové lomky (trailing slash) alebo session ID. Dôsledná canonical stratégia sústredí signály na jednu preferovanú URL adresu.
• Soft 404: Stránky bez skutočného obsahu, ktoré namiesto 404 alebo 410 chybne vracajú stavový kód 200. Viažu crawl budget na obsah bez hodnoty.
• Nekonečné crawl cesty: Kalendáre, stránkovanie bez konca alebo vnorené filtre, ktoré vedú crawlery do stále nových hĺbok.

Zásada znie: crawlery majú svoj obmedzený čas tráviť na stránkach, ktoré majú rankovať alebo byť citované, nie na technickom balaste.

Aktívne riadenie indexácie: sitemapy a IndexNow

Namiesto toho, aby si sa iba vyhýbal plytvaniu, môžeš crawlery aktívne nasmerovať na správne URL adresy. Na to máš k dispozícii dva komplementárne nástroje.

• XML sitemapy: Uvádzajú kanonické URL adresy vhodné na indexáciu aj s dátumom aktualizácie. Udržiavaná sitemapa pomáha vyhľadávačom efektívne nájsť nové a zmenené stránky bez toho, aby museli prejsť celý web. Je základom každého šetrenia crawl budgetu.
• IndexNow: Push protokol, ktorým web aktívne informuje vyhľadávače o nových alebo zmenených URL adresách namiesto čakania na ďalší crawl. Rozšírenie je značné: podľa Bingu sa cez IndexNow denne odošle viac ako 3,5 miliardy URL adries a 18 percent všetkých nových URL adries, na ktoré používatelia klikli vo výsledkoch webového vyhľadávania, pochádza odtiaľ.

Rozhodujúca výhrada pre región DACH: IndexNow podporujú Bing, Yandex a ďalšie vyhľadávače, Google však nie. Keďže v Rakúsku trhu dominuje Google, je IndexNow tu užitočným doplnkom pre viditeľnosť v Bingu, nenahrádza však čistú stratégiu sitemap a crawlovania pre Google. Oba nástroje sa dopĺňajú: sitemapy pre Google, IndexNow navyše pre vyhľadávače zapojené do IndexNow.

Správa botov na úrovni edge, CDN a servera

Súbor robots.txt je prosba, nie príkaz. Seriózne crawlery ho rešpektujú, iné nie. Kto chce technicky zabrániť preťaženiu crawlovaním alebo spoľahlivo zastaviť nežiaduce boty, potrebuje riadenie na úrovni edge, CDN a servera.

• Overovanie legitímnych botov: Skutočné crawlery sa dajú overiť cez ich oficiálne zverejnené rozsahy IP adries alebo cez reverzné DNS. Tak odlíšiš skutočného Googlebota od botov, ktoré sa zaňho iba vydávajú.
• Rate limiting: Obmedzuje frekvenciu požiadaviek na bota alebo rozsah IP adries. Chráni tak pôvodný server pred špičkami záťaže bez toho, aby legitímne crawlery úplne zablokoval.
• Selektívne blokovanie a povoľovanie: Na úrovni CDN sa dajú AI tréningové boty cielene blokovať, zatiaľ čo vyhľadávacie boty a boty pracujúce v reálnom čase prejdú. Je to presnejšie a lepšie vynútiteľné ako samotný robots.txt.
• Ochrana cache: AI crawlery často pristupujú k zriedka navštevovanému long-tail obsahu, ktorý nie je v edge cache. Takéto prístupy idú priamo na pôvodný server a súperia s ľudskou návštevnosťou o zdroje. Tu pomáha rate limiting a cielené smerovanie.

Táto úroveň je dôležitá najmä pre B2B weby citlivé na zdroje, pri ktorých má kapacita servera a stabilná doba odozvy pre platiacich zákazníkov prednosť pred nekontrolovaným prístupom botov.

Analýza log súborov ako nástroj riadenia

Bez merania je každé riadenie crawlovania letom naslepo. Štandardná webová analytika ako GA4 AI crawlery prakticky nezachytí, pretože nespúšťajú JavaScript a nenastavujú cookies. Jediným spoľahlivým zdrojom dát je serverový log súbor. Ukazuje, ktorý bot kedy načítal ktorú URL adresu a s akým stavovým kódom.

Z logov sa dajú odvodiť rozhodujúce riadiace veličiny:

• Frekvencia crawlovania podľa bota: Ako často navštevuje web Googlebot, GPTBot alebo ClaudeBot a ktoré časti webu? Tak zistíš, či budget neodteká na bezcenné stránky.
• Pomer crawl-to-refer: Vzťah medzi počtom crawlovaných stránok a skutočne privedenými návštevníkmi hodnotí protihodnotu bota. Medzinárodné hodnoty Cloudflare za júl 2025 ukazujú obrovský rozptyl: Anthropic crawloval približne 38 065 stránok na jedného privedeného návštevníka, OpenAI približne 1 091 a Google iba 5,4. Čím vyššia hodnota, tým horší pomer záťaže a úžitku.
• Rozdelenie stavových kódov: Ak sa v návštevnosti botov hromadia kódy 404 alebo 5xx, naznačuje to plytvanie crawl budgetom alebo problémy servera, ktoré znižujú Crawl Capacity Limit.

Na základe týchto dát sa dá budget cielene presmerovať: boty so zlým pomerom crawl-to-refer obmedziť, hodnotné crawlery nasmerovať na strategické URL adresy. Analýza log súborov je tak ústredným meracím nástrojom multi-bot governance.

Next.js a JavaScript SEO: mysli aj na render budget

Crawl budget má druhý, často prehliadaný rozmer: render budget. Kto skladá obsah až na strane klienta cez JavaScript, vyžaduje od crawlera druhý, nákladný krok. Google musí stránku crawlovať a vykresliť, aby obsah videl. To spotrebúva ďalšie zdroje a oneskoruje indexáciu.

Pre modernú architektúru Next.js z toho vyplýva jasné poradie stratégií renderovania:

• SSG (Static Site Generation): Stránky sa vopred vykreslia pri builde a doručia sa ako hotové HTML. Najefektívnejší prístup z hľadiska crawlovania aj renderovania, ideálny pre stabilný obsah, ako sú odborné články alebo stránky služieb.
• ISR (Incremental Static Regeneration): Statické stránky sa na pozadí pravidelne generujú nanovo. Spája efektivitu SSG s aktuálnosťou, vhodné pre obsah, ktorý sa mení často, ale nie každú sekundu.
• SSR (Server-Side Rendering): HTML sa generuje na serveri pri každej požiadavke. Crawler dostane kompletné HTML bez toho, aby musel sám renderovať. Vhodné pre personalizované alebo vysoko dynamické stránky.
• CSR (Client-Side Rendering): Obsah vzniká až v prehliadači. Pre SEO najnevýhodnejší prípad, pretože dvojnásobne zaťažuje crawl budget aj render budget a najmä AI crawlery, ktoré JavaScript často vôbec nespúšťajú, odchádzajú naprázdno.

Základné pravidlo pre B2B weby v regióne DACH, ktoré majú byť efektívne pre crawlery: obsah relevantný pre indexáciu poskytuj na strane servera alebo staticky, aby každý crawler našiel kompletný obsah priamo v HTML. Šetrí to render budget a sprístupňuje obsah aj AI crawlerom, ktoré JavaScript nespúšťajú.

AI crawlery, GEO a monetizácia: llms.txt a pay-per-crawl

So záťažou od AI crawlerov prichádza strategická otázka protihodnoty. V roku 2026 tu vznikajú nové mechanizmy, ktoré sú ešte mladé a nejednotné.

• llms.txt: Navrhovaný súbor, ktorý AI systémom ponúka kurátorsky vybraný, dobre štruktúrovaný obsah na jednom mieste. Rozšírenie je však zatiaľ malé: podľa Web Almanac 2025 poskytuje platný súbor llms.txt iba 2,13 percenta desktopových webov, z toho 39,6 percenta je vygenerovaných pluginom All in One SEO. Záväzný štandard z toho zatiaľ nevznikol.
• Prístupy pay-per-crawl: Modely, pri ktorých AI poskytovatelia platia za prístup k obsahu namiesto toho, aby ho crawlovali zadarmo. Riešia presne nerovnováhu medzi vysokou záťažou z crawlovania a nízkym referral trafficom, ktorú odhaľujú hodnoty crawl-to-refer.

V jadre ide o zváženie: na jednej strane viditeľnosť v AI odpovediach (GEO), na druhej náklady na server a kontrola nad vlastným obsahom. Pre B2B firmy v regióne DACH, pre ktoré je odborný obsah kľúčovým aktívom, sa oplatí rozhodnúť o každej triede crawlerov zvlášť a vedome, namiesto toho, aby všetko bez rozdielu povolili alebo zablokovali.

GDPR, výhrada TDM a právny rozmer

V regióne DACH má zaobchádzanie s AI crawlermi aj právnu rovinu. Pre rakúske firmy je dôležitá, pretože presahuje samotné technické riadenie.

• Opt-out z AI tréningu: Direktívami, ako je zablokovanie Google-Extended alebo GPTBota v robots.txt, web signalizuje, že jeho obsah sa nemá používať na AI tréning. Je to technická realizácia výhrady použitia.
• Výhrada TDM (text and data mining): Autorské právo EÚ umožňuje nositeľom práv strojovo čitateľnou formou zakázať použitie ich diel na komerčné vyťažovanie textov a dát. Výhrada uložená v robots.txt alebo ako strojovo čitateľné vyhlásenie je základom na to, aby bol AI tréning právne vylúčený.
• Súvislosť s GDPR: Ak verejné stránky obsahujú osobné údaje, ich zaradenie do tréningových korpusov otvára otázky ochrany osobných údajov. Vedomé riadenie crawlerov je tak súčasťou dôsledného dodržiavania predpisov.

Podstatné je tu prepojenie technického a právneho riadenia: robots.txt slúži na riadenie crawlovania a zároveň dokumentuje vôľu nositeľa práv. V záujme súladu s GDPR v rakúskom kontexte by toto riadenie malo prebiehať vedome a preukázateľne, ideálne v súčinnosti s právnym oddelením.

Ďalšie zdroje a záver

Crawl budget už v roku 2026 nie je téma iba pre veľké weby. Je to multi-bot problém, ktorý treba aktívne riadiť. Z pohľadu samotného Googlebota zostávajú prahy vysoké, no množstvo AI crawlerov, ich rozdielna záťaž a veľmi kolísavá protihodnota robia diferencovanú governance zmysluplnou aj pre stredne veľké B2B weby v regióne DACH.

Priority v praxi sú jasné: po prvé odstrániť plytvanie crawl budgetom, ktoré si web spôsobuje sám, cez hygienu canonical tagov, noindex a robots.txt; po druhé nastaviť diferencovaný robots.txt, ktorý inak zaobchádza s vyhľadávačmi, AI vyhľadávacími crawlermi a AI tréningovými crawlermi; po tretie vyhodnocovať serverové logy, merať frekvenciu crawlovania a hodnoty crawl-to-refer a presmerovať budget; po štvrté zvoliť architektúru renderovania tak, aby bol obsah dostupný bez nákladov na renderovanie. Kto prepojí tieto štyri úrovne a myslí aj na právny rozmer, udrží si kontrolu nad vlastným serverom a vedome rozhoduje, ktorý obsah je otvorený ktorému botovi. Tému si môžeš prehĺbiť v súvisiacich článkoch o robots.txt, XML sitemapách, canonical tagoch a správe AI crawlerov.