Zpoždění prohledávání (Crawl Delay)

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 botovi, nikoli na standardu.
• Nástroje správců webu: moderní trend je řídit rychlost prohledávání spíše přes rozhraní (např. nastavení v nástrojích pro webmastery), adaptivní algoritmy crawlerů a reakci 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í politeness strategie, souběžnost a backoff mechanismy.

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

• SEO (organické vyhledávání): adekvátní tempo prohledávání minimalizuje zatížení CPU/databáze, zkracuje latenci pro reálné uživatele a zlepšuje stabilitu serveru. Stabilní web = konzistentnější LCP/INP/CLS a rychlejší znovuindexace klíčových URL.
• AIO/AEO (Answer/AI Engine Optimization): asistenční a LLM poháněné systémy extrahují fakta a struktury. Pokud omezíte roboty příliš agresivně, snížíte frekvenci obnovy entit a odpovědí; pokud je pustíte nekontrolovaně, ohrozíte dostupnost a konzistenci odpovědí.
• Entity-first indexace: když se entity (produkty, autoři, lokality) mění, potřebujete, aby crawler rychle prošel pouze dotčené segmenty. Crawl delay proto doporučujeme kombinovat s cíleným odkazováním (sitemapy, „lastmod“, interní přepojování a selektivní regulací 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 omezit maximální počet souběžných spojení na hostitelské jméno nebo IP adresu. Politeness = delay × concurrency.
3. Backoff a adaptivita: kvalitní roboti zpomalí při chybách (429, 503), vysokých odezvových časech nebo při 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 s rozmyslem)

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

User-agent: ExampleBot
Crawl-delay: 2

U větších webů dávejte přednost selektivním pravidlům a rozdělte sekce podle náročnosti:

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

Upozornění: Neopírejte se pouze o Crawl-delay – berte ji jako návod, nikoli jako garanci.

Řízení crawl rychlosti 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 zpomalují.
• CDN a WAF: rate-limiting dle IP/User-Agent, ochrana náročných endpointů, špičkové tlumení pomocí prahových hodnot RPS.
• Cache strategie: statické HTML/JSON/obrázky doručujte z edge cache, aby roboti nenaráželi přímo na origin při vysoké frekvenci.
• Prioritizace tras: rozlišujte rychlé „hot paths“ (homepage, kategorie, poslední články) a „cold paths“ (archív, stránkování > 50). Různé prahy rate-limitů podle cesty.

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

Crawl budget je kombinace 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é při špičce.

Rozdíly mezi boty a praktické dopady

• Vyhledávací roboti: mají sofistikovanou politeness logiku; často ignorují univerzální delay pokyny, ale reagují na chybové kódy, latence a signály ze sitemap (lastmod).
• AI/LLM crawlery: rostoucí segment – nemají vždy dokonalou politeness. Řiďte je přes robots.txt, meta robot pokyny, rate-limity a případně vyžadujte registraci/akreditaci.
• Monitoring/scrapery: vyžadují přísnější limity. Identifikujte neznámé user-agenty a aplikujte 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 s prioritizací:

• Sitemapy s lastmod: generujte přesný datum a čas poslední změny, ideálně segmentově (produkty, blog, kategorie).
• Interní přepojová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 DB a poměr 5xx/429.
2. Definujte prahy (např. „pokud p95 > 1500 ms nebo 5xx > 2 %, zvýš delay o +1 s a sniž concurrency o 1“).
3. Nabídněte nápovědy robotům přes Retry-After a CDN hlavičky; uchovávejte 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 ve 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 došlo ke skutečné změně.

Čemu se vyhnout (anti-patterny)

• Globálně vysoký crawl-delay pro všechny: dramaticky snižuje objevování nového obsahu. Raději omezujte konkrétní 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 bezdůvodně: moderní indexování využívá rendering; zbytečné blokace mohou poškodit pochopení layoutu a kvality stránky.

Měření dopadu a observabilita

• Logy a metriky: sledujte požadavky podle user-agenta, 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 degraduje, 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í:

• Kanonalizace a rule-based 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 nechávejte mimo index.
• „Facet hygiene“: neumožňujte crawlerům volné prohledávání interního vyhledávání či 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 už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í přepojování tak, aby prioritní URL byly plytce 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é trasy.
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 pouze 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čky zpomalte, v noci povolte rychlejší prohledávání. Provádějte to však přes infrastrukturu (CDN/WAF), ne pouze přes robots.txt.

Crawl delay je jeden z nástrojů „politeness“ – sám o sobě však nestačí. Nejlepší výsledky dosáhnete kombinací: segmentované sitemapy a interní přepojování (priorita), adaptivní limity na úrovni CDN/WAF (stabilita), správné HTTP signály (řízení rychlosti) a průběžná observabilita (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.