Crawl delay: prodleva mezi požadavky robota

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

Crawl delay (prodleva mezi požadavky robota) je časový interval, který crawler (prohledávací robot) ponechá mezi dvěma po sobě jdoucími HTTP požadavky na tentýž web. Hlavním cílem je ohleduplnost – chránit server před nadměrnou zátěží, předcházet výpadkům a zároveň umožnit vyhledávačům efektivně objevovat a aktualizovat obsah. Správně nastavené tempo procházení přímo ovlivňuje crawl budget, stabilitu Core Web Vitals (když se server nedostává do stresu) a frekvenci aktualizace obsahu ve výsledcích vyhledávání.

Historický kontext a podpora v ekosystému

Direktiva „Crawl-delay“ v souboru robots.txt: některé vyhledávače ji interpretují jako počet sekund mezi požadavky na konkrétní web. Implementace se však liší a direktiva není univerzálně podporována. Její význam proto závisí na robotovi, nikoli na standardu.
Nástroje pro webmastery: moderním trendem je řídit rychlost procházení spíše prostřednictvím rozhraní (např. nastavení v nástrojích pro webmastery), adaptivních algoritmů crawlerů a reakce serveru (HTTP hlavičky, chybové kódy, Retry-After) než pomocí statické direktivy.
Rozdílné chování: různí roboti (vyhledávače, nástroje třetích stran, LLM/AI crawlery, monitorovací roboti) používají vlastní zásady ohleduplného procházení, souběžné zpracování a strategie postupného zpomalování.

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

SEO (organické vyhledávání): přiměřené tempo procházení minimalizuje vytížení CPU/DB, snižuje latenci pro skutečné uživatele a zlepšuje stabilitu serveru. Stabilní web = konzistentnější LCP/INP/CLS a rychlejší opětovná indexace klíčových URL.
AIO/AEO (optimalizace pro odpovědi a AI vyhledávače): asistenti a systémy využívající LLM extrahují fakta a struktury. Pokud roboty omezíte příliš agresivně, snížíte frekvenci aktualizace entit a odpovědí; pokud je necháte pracovat bez kontroly, ohrozíte dostupnost a konzistentnost odpovědí.
Indexace zaměřená na entity: když se entity (produkty, autoři, lokality) mění, je třeba, aby crawler rychle prošel pouze dotčené části. Crawl delay je proto třeba kombinovat s cíleným odkazováním (sitemapy, „lastmod“, interní prolinkování a selektivní omezování rychlosti).

Mechanika: co skutečně řídí tempo procházení

Interval mezi požadavky: statická prodleva (např. 2 s) je nejjednodušší model, ale neodráží skutečné zatížení.
Souběžnost (concurrency): i při nulové prodlevě může robot omezit maximální počet souběžných spojení na název hostitele nebo IP adresu. Ohleduplnost = prodleva × souběžnost.
Postupné zpomalování a adaptivita: kvalitní roboti zpomalí při chybách (429, 503), dlouhé době odezvy nebo signálech z WAF/CDN.
Rozlišování sekcí: citlivé koncové body (vyhledávání, filtrování, náročné JSON API) vyžadují jiné tempo než statické HTML/obrázky.

Konfigurace v robots.txt (praktické řešení, ale s rozvahou)

Pokud se rozhodnete direktivu použít, uplatněte ji cíleně pro konkrétního user-agenta a počítejte s tím, že ji ne každý bot 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: /interny-vyhladavac Crawl-delay: 1

Upozornění: Nespoléhejte se pouze na Crawl-delay – berte jej jako vodítko, nikoli jako záruku.

Řízení rychlosti procházení prostřednictvím serveru a infrastruktury

HTTP kódy a hlavičky: při dočasném 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: omezování rychlosti podle IP/User-Agent, ochrana nákladných koncových bodů, tlumení špiček pomocí prahových hodnot RPS.
Strategie ukládání do mezipaměti: statické HTML/JSON/obrázky doručujte z edge cache, aby roboti při vysoké frekvenci nepřistupovali přímo k origin serveru.
Prioritizace cest: rozlišujte rychlé „hot paths“ (domovská stránka, kategorie, nejnovější články) a „cold paths“ (archiv, stránkování > 50). Pro jednotlivé cesty nastavte různé prahové hodnoty omezování rychlosti.

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

Crawl budget je kombinací kapacity (kolik toho robot může projít) a poptávky (kolik toho robot chce projít). Příliš dlouhá prodleva snižuje kapacitu – robot navštíví méně URL a postupuje pomaleji. Příliš krátká prodleva naopak zvýší chybovost a zpomalí web pro lidi. Cílem je pružné tempo: rychlé při nízké zátěži, opatrné ve špičce.

Rozdíly mezi boty a praktické důsledky

Vyhledávací roboti: mají sofistikovanou logiku ohleduplného procházení; často ignorují univerzální pokyny k prodlevě, ale reagují na chybové kódy, latenci a signály ze sitemap (lastmod).
AI/LLM crawlery: jde o rychle rostoucí segment, který ne vždy dodržuje zásady ohleduplného procházení. Řiďte jej prostřednictvím robots.txt, pokynů meta robots, omezení rychlosti a případně požadavku na registraci/akreditaci.
Monitorovací roboti/nástroje pro scrapování: potřebují přísnější limity. Identifikujte neznámé user-agenty a uplatněte postupné omezování rychlosti.

Signály důležitosti a plánování procházení

Tempo procházení by mělo zohledňovat prioritu URL. Pomozte robotům určit priority:

Sitemapy s lastmod: generujte přesné datum a čas poslední změny, ideálně odděleně podle segmentů (produkty, blog, kategorie).
Interní prolinkování: důležité stránky mají malou hloubku prokliku a smysluplné navigační vazby (BreadcrumbList, související články).
Strukturovaná data: značení entit (Organization, Product, Article) signalizuje typ a relevanci obsahu – usnadňuje selektivní procházení.

Modelování „ohleduplnosti“: prodleva × souběžnost × dynamika

Doporučeným přístupem je adaptivní omezování rychlosti:

Monitorujte p95 TTFB, využití CPU, latenci DB a poměr 5xx/429.
Definujte prahové hodnoty (např. „pokud p95 > 1500 ms nebo 5xx > 2 %, prodlužte prodlevu o +1 s a snižte souběžnost o 1“).
Nabídněte robotům vodítka prostřednictvím Retry-After a hlaviček CDN; uchovávejte přístupové logy pro audit.

Příklady konfigurace a vzory

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

User-agent: * Disallow: /vyhladavanie 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: sekce aktualizované častěji rozdělte do samostatných souborů sitemap (např. sitemap-posts.xml, sitemap-products.xml) a aktualizujte lastmod pouze tam, kde skutečně došlo ke změně.

Čemu se vyhnout (anti-patterny)

Globálně dlouhý crawl delay pro všechny: dramaticky sníží objevitelnost nového obsahu. Raději omezte konkrétní boty nebo náročné sekce.
Ignorování signálů serveru: pokud vracíte 429/503 bez Retry-After, robot neví, kdy to zkusit znovu.
Jedna velká sitemap bez segmentace: ztěžuje plánování procházení a zvyšuje pravděpodobnost neefektivních návštěv.
Blokování CSS/JS bez důvodu: moderní indexace využívá vykreslování; zbytečné blokování může zhoršit pochopení rozvržení a kvality stránky.

Měření dopadu a observabilita

Logy a metriky: sledujte požadavky podle user-agent, RPS, latenci, chyby a poměr zásahů do mezipaměti na CDN.
Ukazatele „čerstvosti“: porovnávejte čas poslední změny (lastmod) s časem poslední návštěvy robota; pro kritické entity definujte SLO (např. „90 % produktů znovu navštíveno do 24 h“).
Core Web Vitals při zátěži: během špiček způsobených procházením monitorujte LCP/INP/CLS – pokud se zhorší, zpřísněte limity pro bota nebo posilte cache/infrastrukturu.

Crawl delay v kontextu rozsáhlých katalogů a webů s velkým podílem JavaScriptu

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

Kanonizace a indexace založená na pravidlech: indexujte pouze reprezentativní kombinace; u ostatních použijte 404/410 nebo noindex, follow.
Rozpočet na vykreslování: pokud používáte SSR/ISR, omezujte nákladné vykreslování pro dlouhý chvost; robotům servírujte statické snímky a méně důležité parametry vynechte z indexu.
„Hygiena faset“: nedovolte crawlerům volně procházet interní vyhledávač či nekonečné stránkování; kombinujte Disallow a omezení rychlosti.

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

Pokud publikujete obsah pro indexy LLM (AIO), vytvořte stránku s politikou procházení AI, na níž definujete podmínky použití, identifikaci user-agentů, kontaktní kanál a požadavek na respektování limitů rychlosti. Přizpůsobte crawl delay licenčním podmínkám a obchodním prioritám.

Praktický postup zavedení

Audit: zmapujte sekce webu podle náročnosti (HTML, API, obrázky, vyhledávání).
Segmentace: rozdělte sitemapy a nastavte interní prolinkování tak, aby prioritní URL byly v hierarchii co nejvýše.
Politika ohleduplného procházení: definujte prahové hodnoty RPS, prodlevu a souběžnost pro jednotlivé sekce a user-agenty (alespoň pro 5 nejvýznamnějších botů).
Technická opatření: nastavte 429/503 + Retry-After, aktivujte CDN cache a zapněte omezování rychlosti ve WAF pro náročné cesty.
Monitorování a ladění: průběžně dolaďujte prahové hodnoty podle skutečných metrik a sezónnosti.

FAQ (často kladené otázky)

Pomůže dlouhý crawl delay snížit náklady?
Krátkodobě ano (méně požadavků na origin server), dlouhodobě však můžete přijít o rychlé aktualizace ve vyhledávání. Optimalizujte raději CDN/cache a omezte pouze náročné sekce.

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

Má smysl dynamicky měnit prodlevu podle denní doby?
Ano – ve špičce zpomalte, v noci povolte rychlejší procházení. Dělejte to však prostřednictvím infrastruktury (CDN/WAF), nikoli pouze přes robots.txt.

Crawl delay je jedním z nástrojů pro ohleduplné procházení – sám o sobě však nestačí. Nejlepších výsledků dosáhnete kombinací segmentovaných sitemap a interního prolinkování (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í, aktuálností indexu a výkonem pro skutečné uživatele i systémy AI/LLM.