Co je crawl budget a proč na něm záleží

Crawl budget je zjednodušeně počet URL, které je vyhledávač ochoten a schopen na vašem webu v určitém čase projít. V praxi jde o kombinaci dvou složek: crawl capacity, tedy technické kapacity vyhledávače, a crawl demand, tedy zájmu o obsah webu. Čím větší a častěji měněný web, tím citlivější je na to, jak rychle server odpovídá.

Google opakovaně uvádí, že crawl budget není problém pro malé weby s několika stovkami URL. U rozsáhlejších webů, e-shopů s parametry, katalogů nebo zpravodajských webů ale může rozhodovat o tom, zda se nové produkty, články nebo změny v indexu objeví během hodin, nebo až po dnech. Pokud robot dostává pomalé odpovědi, jednoduše stihne projít méně adres za stejný čas.

Jak rychlost odezvy serveru ovlivňuje chování crawleru

Vyhledávací robot pracuje podobně jako běžný uživatel: čeká na odpověď serveru. Pokud je odezva pomalá, snižuje počet požadavků nebo navštěvuje web méně agresivně. U Googlebotu je tento mechanismus adaptivní, tedy průběžně se přizpůsobuje stavu webu. Při stabilně rychlém serveru může robot zvyšovat tempo procházení, při problémech ho naopak brzdí.

Nejde jen o extrémní výpadky. Význam má i TTFB neboli Time to First Byte. Pokud se TTFB pohybuje dlouhodobě nad 600–800 ms, u větších webů už to bývá signál ke kontrole. U dobře optimalizovaných webů bývá běžné držet TTFB pod 200–300 ms pro statické i často navštěvované stránky. Samotný crawling pak není jen o rychlosti jedné stránky, ale o součtu stovek a tisíců požadavků.

Praktický dopad je jednoduchý: když robot stráví na jedné URL dvě sekundy místo půl sekundy, při stejném časovém okně zvládne zhruba čtvrtinu objemu. U rozsáhlejšího webu to znamená, že se méně často dostane na hlubší stránky, nové varianty produktů nebo aktualizované články.

Které technické faktory zpomalují crawl nejčastěji

Rychlost odezvy serveru není jen otázka hostingu. Vstupuje do ní infrastruktura, aplikace i konfigurace webu. V praxi se nejčastěji objevují tyto problémy:

  • pomalej hosting nebo sdílené prostředí s vysokou zátěží,
  • neoptimalizované databázové dotazy, zejména u WordPressu a e-shopů,
  • nadměrné množství pluginů a server-side logiky,
  • chybějící cache nebo špatně nastavený reverse proxy,
  • pomalé přesměrování přes více kroků,
  • chyby 5xx, které vedou ke snížení frekvence crawlů,
  • neefektivní renderování u JavaScriptových webů, kde bot musí čekat na načtení a vykreslení obsahu.

U webů postavených na WordPressu bývá typickým problémem kombinace těžké šablony, velkého množství pluginů a absence objektové cache. U e-shopů zase zpomalují filtrování, parametry v URL a příliš složité dotazy do katalogu. U headless řešení nebo Next.js bývá problém spíše v tom, že API odpovědi jsou pomalé nebo serverless funkce mají studený start.

Jak rychlost měřit v praxi

Bez měření nelze určit, zda je crawl budget skutečně omezený serverem, nebo spíše strukturou webu. Pro první orientaci se hodí Google Search Console, zejména report Statistika procházení. Ten ukazuje počet stažených stránek za den, průměrnou dobu stahování i rozložení odpovědí serveru. Pokud se průměrná doba stahování zhoršuje a současně klesá počet crawlovaných URL, je to jasný signál k zásahu.

Další užitečné nástroje jsou:

  • PageSpeed Insights a Lighthouse pro orientační technický audit,
  • WebPageTest pro detailní rozpad TTFB, DNS, TLS a server response,
  • GTmetrix pro rychlou kontrolu waterfallu,
  • server logy pro skutečné chování botů,
  • Chrome DevTools a monitoring backendu pro odhalení pomalých endpointů.

Nejspolehlivější je kombinace Search Console a log analýzy. V logách uvidíte, kolik času robot tráví na jednotlivých sekcích webu, jak často naráží na 3xx, 4xx a 5xx odpovědi a zda neplýtvá crawl budgetem na zbytečné URL, například parametry, interní vyhledávání nebo duplicity. U velkých webů se vyplatí sledovat i average response time by bot a počet requestů na sekci za den.

Co upravit, aby se crawl budget využil lépe

Nejrychlejší efekt mívají zásahy, které zkrátí odpověď serveru bez změny obsahu. V první řadě pomáhá full-page cache nebo cache na úrovni CDN. U statičtějších částí webu může CDN snížit TTFB o desítky až stovky milisekund a zlepšit stabilitu při špičkách. U dynamických webů je vhodné oddělit obsah, který se mění často, od obsahu, který lze bezpečně cachovat déle.

Dále se vyplatí:

  • omezit počet redirectů na maximum jeden krok,
  • sloučit nebo odstranit pomalé pluginy a skripty,
  • optimalizovat databázové indexy a pomalé dotazy,
  • používat HTTP/2 nebo HTTP/3,
  • zapnout kompresi Brotli nebo gzip,
  • zmenšit počet interních variant URL, které nemají SEO hodnotu,
  • správně nastavit robots.txt a canonical tagy, aby bot neplýtval na duplicity.

U velkých e-shopů je důležité také omezit crawl nekonečných filtrů a kombinací parametrů. Pokud má kategorie deset filtrů a každý generuje novou URL, může robot trávit většinu kapacity na stránkách, které nepřinášejí žádnou přidanou hodnotu. V takovém případě je vhodné rozhodnout, které kombinace mají být indexovatelné, a ostatní blokovat, kanonizovat nebo zcela vyřadit z crawl cesty.

Jak poznat, že se problém týká právě vašeho webu

Signály bývají poměrně čitelné. Nové články nebo produkty se objevují v indexu později než dříve. V Search Console klesá počet procházených stránek, zatímco serverové chyby nebo doba odezvy rostou. Logy ukazují, že bot navštěvuje stále stejné sekce a opomíjí hlubší URL. U zpravodajských a obsahových webů se často projeví i to, že aktualizované články se nepromítají do výsledků včas, přestože jsou interně dobře propojené.

Typický příklad z praxe: e-shop s 200 tisíci URL měl průměrnou TTFB kolem 1,4 sekundy a Googlebot denně prošel asi 35 tisíc URL. Po zavedení CDN, objektové cache a úpravě databázových dotazů klesla TTFB na 350 ms a denní crawl vzrostl na 62 tisíc URL. Nešlo jen o vyšší rychlost webu pro uživatele, ale i o to, že robot se dostal častěji k novým produktům a aktualizacím cen.

Je tedy zřejmé, že rychlost odezvy serveru není jen technický detail. U webů s větším objemem obsahu rozhoduje o tom, jak efektivně vyhledávače využijí svůj čas, kolik URL projdou a jak rychle se změny promítnou do indexu. Pro SEO i správu webu platí, že největší přínos má průběžný monitoring, práce s logy a odstranění úzkých míst ještě dřív, než se projeví na viditelnosti ve vyhledávání.