Zpoždění požadavků bota (crawl delay) a jeho dopad na webové prohledávání

Co je „crawl delay“ a proč na něm záleží

Crawl delay (zpoždění mezi požadavky bota) je časový interval, který si crawler (prohledávací robot) ponechá mezi dvěma po sobě jdoucími HTTP požadavky na stejný web. Hlavním cílem je politeness – chránit server před nadměrným zatížením, předcházet výpadkům a zároveň umožnit vyhledávačům efektivně objevovat a aktualizovat obsah. Korektně nastavené tempo prohledávání přímo ovlivňuje crawl budget, stabilitu Core Web Vitals (když se server nedostává do stresového režimu) a frekvenci aktualizace obsahu ve výsledcích vyhledávání.

Historický kontext a podpora v ekosystému

• robots.txt direktiva „Crawl-delay“: některé vyhledávače ji interpretují jako počet sekund mezi požadavky na konkrétní web. Implementace jsou však nejednotné a nejsou univerzálně podporované. Význam proto závisí na konkrétním botu, nikoliv na standardu.
• Nástroje správců webu: moderním trendem je řídit rychlost prohledávání spíše přes rozhraní (např. nastavení v nástrojích pro webmastery), adaptivní algoritmy crawlerů a reakce serveru (HTTP hlavičky, chybové kódy, Retry-After) než přes statickou direktivu.
• Nerovnoměrné chování: různí roboti (vyhledávače, nástroje třetích stran, LLM/AI prohledávače, monitorovací roboti) uplatňují vlastní politiku slušnosti, stratégie paralelismu a zpomalování.

Vliv na SEO, AIO/AEO a moderní vyhledávání

• SEO (organické vyhledávání): přiměřené tempo prohledávání minimalizuje vytížení CPU/databáze, zkracuje latenci pro reálné uživatele a zlepšuje stabilitu serveru. Stabilní web znamená konzistentnější LCP/INP/CLS a rychlejší reindexaci klíčových URL.
• AIO/AEO (Answer/AI Engine Optimization): asistované a LLM poháněné systémy extrahují fakta a struktury. Příliš agresivní omezení robotů sníží frekvenci aktualizace entit a odpovědí; nekontrolované povolení zase ohrozí dostupnost a konzistenci odpovědí.
• Entity-first indexace: pokud se entity (produkty, autoři, lokality) mění, je potřeba, aby crawler rychle prošel pouze dotčené segmenty. Crawl delay je proto nutné kombinovat s cíleným odkazováním (sitemapy, „lastmod“, interní prolinkování a selektivním řízením rychlosti).

Mechanika: co reálně řídí tempo prohledávání

1. Interval mezi požadavky: statické zpoždění (např. 2 s) je nejjednodušší model, ale nereflektuje skutečné zatížení.
2. Paralelismus (concurrency): i při nulovém delay může robot omezovat maximální počet současných spojení na jedno hostitelské jméno nebo IP adresu. Politeness = delay × concurrency.
3. Backoff a adaptivita: kvalitní roboti zpomalí při chybách (429, 503), vysokých odezvách nebo signálech z WAF/CDN.
4. Rozlišování sekcí: citlivé endpointy (vyhledávání, filtrování, náročné JSON API) vyžadují jiné tempo než statické HTML/obrázky.

Konfigurace v robots.txt (prakticky, ale rozumně)

Pokud se rozhodnete použít direktivu, uplatněte ji cíleně pro konkrétní user-agenty a uvědomte si, že ne každý bot ji respektuje:

User-agent: ExampleBot
Crawl-delay: 2

U větších webů upřednostňujte selektivní pravidla a rozdělte sekce podle náročnosti:

User-agent: ExampleBot
Disallow: /interni-vyhledavac
Crawl-delay: 1

Upozornění: Nespoléhejte se pouze na Crawl-delay – berte ji jako nápovědu, nikoli záruku.

Řízení rychlosti crawl přes server a infrastrukturu

• HTTP kódy a hlavičky: pro dočasné přetížení vraťte 429 Too Many Requests nebo 503 Service Unavailable a přidejte Retry-After: 120. Kvalitní roboti zpomalí.
• CDN a WAF: rate-limiting na základě IP/User-Agent, ochrana náročných endpointů, špičkové omezení pomocí prahových hodnot RPS.
• Cache strategie: statické HTML/JSON/obrázky doručujte z edge cache, aby roboti nenaráželi při vysoké frekvenci přímo na origin server.
• Prioritizace cest: rozlišujte rychlé „hot paths“ (domovská stránka, kategorie, poslední články) a „cold paths“ (archivy, stránkování přes 50). Různé prahy rate-limitů podle cesty.

Crawl delay a „crawl budget“: jak najít rovnováhu

Crawl budget je kombinací capability (kolik robot dokáže projít) a demand (kolik robot chce projít). Příliš vysoký delay snižuje capability – robot navštíví méně URL a pomaleji. Příliš nízký delay naopak zvyšuje chybovost a zpomaluje web pro uživatele. Cílem je elastické tempo: rychlé při nízké zátěži, opatrné během špiček.

Rozdíly mezi boty a praktické důsledky

• Vyhledávací roboti: mají sofistikovanou politiku slušnosti; často ignorují univerzální delay pokyny, ale reagují na chybové kódy, latence a signály ze sitemap (lastmod).
• AI/LLM crawlery: rostoucí segment – ne vždy mají ideální slušnost. Řiďte je přes robots.txt, meta robot příkazy, rate-limity a případně požadujte registraci či akreditaci.
• Monitoring/scrapery: potřebují přísnější omezení. Identifikujte neznámé user-agenty a uplatňujte progressive throttling.

Signály důležitosti a plánování prohledávání

Tempo prohledávání by mělo respektovat prioritu URL. Pomozte robotům prioritizovat:

• Sitemapy s lastmod: generujte přesný datum a čas poslední změny, ideálně segmentovaně (produkty, blog, kategorie).
• Interní prolinkování: důležité stránky mají nízkou hloubku kliků a smysluplné navigační vazby (BreadcrumbList, související články).
• Strukturovaná data: entitní značení (Organization, Product, Article) signalizuje typ a relevanci obsahu – usnadňuje selektivní prohledávání.

Modelování „politeness“: delay × concurrency × dynamika

Doporučený přístup je adaptivní throttling:

1. Monitorujte p95 TTFB, využití CPU, latenci databáze a poměr 5xx/429.
2. Definujte prahy (např. „pokud p95 > 1500 ms nebo 5xx > 2 %, zvyšte delay o +1 s a snižte concurrency o 1“).
3. Nabídněte hints robotům přes Retry-After a CDN hlavičky; udržujte přístupové logy pro audit.

Příklady konfigurace a vzory

Minimalistický robots.txt pro neznámé boty:

User-agent: *
Disallow: /vyhledavani
Crawl-delay: 1

Ochrana náročných API:

# Rate-limit na úrovni WAF/CDN (mimo robots.txt):
/api/filter → max 2 RPS na IP, burst 5; při překročení 429 + Retry-After: 60

Selektivní priorita v sitemapách: častěji aktualizované sekce rozdělte do samostatných sitemap souborů (např. sitemap-posts.xml, sitemap-products.xml) a aktualizujte lastmod pouze tam, kde se skutečně něco změnilo.

Čemu se vyhnout (anti-patterny)

• Globálně vysoký crawl-delay pro všechny: výrazně sníží objevování nového obsahu. Raději omezujte specifické boty nebo náročné sekce.
• Ignorování serverových signálů: pokud vracíte 429/503 bez Retry-After, robot neví, kdy má zkusit znovu.
• Jedna velká sitemap bez segmentace: ztěžuje plánování prohledávání a zvyšuje pravděpodobnost neefektivních návštěv.
• Blokování CSS/JS bez důvodu: moderní indexování využívá rendering; zbytečné blokování může poškodit pochopení rozložení a kvality stránky.

Měření dopadu a observabilita

• Logy a metriky: sledujte požadavky podle user-agent, RPS, latenci, chyby a cache hit ratio na CDN.
• „Freshness“ indikátory: porovnávejte čas poslední změny (lastmod) s časem poslední návštěvy bota; pro kritické entity definujte SLO (např. „90 % produktů znovu navštívených do 24 hodin“).
• Core Web Vitals pod zátěží: monitorujte LCP/INP/CLS během špiček pro crawl – pokud se zhorší, zpřísněte limity pro bota nebo posilte cache/infrastrukturu.

Crawl delay v kontextu velkých katalogů a JS-heavy webů

U tisíců URL a dynamických filtrací je klíčovým problémem kombinatorická exploze. Řešení:

• Kanoniikalizace a pravidly řízená indexace: indexujte pouze reprezentativní kombinace; ostatní vraťte 404/410 nebo noindex, follow.
• Render budget: pokud používáte SSR/ISR, omezujte náročné renderování pro dlouhý ocas; robotům servírujte statické snímky a méně důležité parametry nechte mimo index.
• „Facet hygiene“: neumožňujte crawlerům volné prohledávání interního vyhledávání nebo nekonečných stránkování; kombinujte Disallow a rate limits.

Integrace s politikou přístupnosti pro AI/LLM roboty

Pokud publikujete obsah pro LLM indexy (AIO), vytvořte AI crawling policy stránku, kde definujete podmínky použití, identifikaci user-agentů, kontaktní kanál a požadavek na respektování rate-limitů. Přizpůsobte crawl delay podle licenčních podmínek a obchodních priorit.

Praktický postup zavedení

1. Audit: zmapujte sekce webu podle náročnosti (HTML, API, obrázky, vyhledávání).
2. Segmentace: rozdělte sitemapy a nastavte interní prolinkování tak, aby prioritní URL byly mělké ve struktuře.
3. Politeness politika: definujte prahy RPS, delay a concurrency pro jednotlivé sekce a user-agenty (alespoň pro top 5 botů).
4. Technická opatření: nastavte 429/503 + Retry-After, aktivujte CDN cache, zapněte WAF rate-limit pro náročné cesty.
5. Monitorování a ladění: průběžně dolaďujte prahy podle reálných metrik a sezónnosti.

FAQ (často kladené otázky)

Pomůže vysoký crawl-delay snížit náklady?
Krátkodobě ano (méně požadavků na origin), ale dlouhodobě můžete přijít o rychlé aktualizace ve vyhledávání. Optimalizujte spíše CDN/cache a omezujte jen náročné sekce.

Je „Crawl-delay“ spolehlivý signál?
Není univerzální. Respektují ho pouze někteří roboti. Vždy kombinujte s Retry-After, rate-limity a sitemapami.

Má smysl dynamicky měnit delay podle denní doby?
Ano – během špiček zpomalte, v noci povolte rychlejší prohledávání. Dělejte to však přes infrastrukturu (CDN/WAF), ne pouze přes robots.txt.

Crawl delay je jedním z nástrojů „politeness“ – sám o sobě však nestačí. Nejlepší výsledky dosáhnete kombinací: segmentovaných sitemap a interního propojení (priorita), adaptivních limitů na úrovni CDN/WAF (stabilita), správných HTTP signálů (řízení rychlosti) a průběžné observability (důkaz o dopadu). Takto udržíte rovnováhu mezi dostupností, čerstvostí indexu a výkonem pro reálné uživatele i AI/LLM systémy.