Crawl delay

Čo je „crawl delay“ a prečo na ňom záleží

Crawl delay (oneskorenie medzi požiadavkami bota) je časový interval, ktorý si crawler (prehliadací robot) ponechá medzi dvoma po sebe idúcimi HTTP požiadavkami na ten istý web. Hlavným cieľom je politeness – chrániť server pred nadmerným zaťažením, predchádzať výpadkom a zároveň umožniť vyhľadávačom efektívne objavovať a aktualizovať obsah. Korektne nastavené tempo prehľadávania priamo ovplyvňuje crawl budget, stabilitu Core Web Vitals (keď sa server neprepína do stresu) a frekvenciu aktualizácie obsahu vo výsledkoch vyhľadávania.

Historický kontext a podpora v ekosystéme

• robots.txt direktíva „Crawl-delay“: niektoré vyhľadávače ju interpretujú ako počet sekúnd medzi požiadavkami na konkrétny web. Implementácie sú však nejednotné a nie univerzálne podporované. Význam preto závisí od bota, nie od štandardu.
• Nástroje správcov webu: moderný trend je riadiť rýchlosť prehľadávania skôr cez rozhrania (napr. nastavenia v webmaster nástrojoch), adaptívne algoritmy crawlerov a reakciu servera (HTTP hlavičky, chybové kódy, Retry-After), než cez statickú direktívu.
• Nerovnomerné správanie: rôzni roboti (vyhľadávače, nástroje tretích strán, LLM/AI prehľadávače, monitorovacie roboty) uplatňujú vlastné politeness politiky, concurrency a backoff stratégie.

Vplyv na SEO, AIO/AEO a moderné vyhľadávanie

• SEO (organické vyhľadávanie): primerané tempo prehľadávania minimalizuje vyťaženie CPU/DB, skracuje latenciu pre reálnych používateľov a zlepšuje stabilitu servera. Stabilný web = konzistentnejšie LCP/INP/CLS a rýchlejšie znovuindeksovanie kľúčových URL.
• AIO/AEO (Answer/AI Engine Optimization): asistenčné a LLM poháňané systémy extrahujú fakty a štruktúry. Ak obmedzíte robotov príliš agresívne, znížite frekvenciu osvieženia entít a odpovedí; ak ich pustíte nekontrolovane, ohrozíte dostupnosť a konzistentnosť odpovedí.
• Entity-first indexácia: keď sa entity (produkty, autori, lokality) menia, potrebujete, aby crawler rýchlo prešiel len dotknuté segmenty. Crawl delay preto treba kombinovať s cieleným odkazovaním (sitemapy, „lastmod“, interné prelinkovanie a selektívne prahovanie rýchlosti).

Mechanika: čo reálne riadi tempo prehľadávania

1. Interval medzi požiadavkami: statické oneskorenie (napr. 2 s) je najjednoduchší model, no neodráža skutočné zaťaženie.
2. Paralelizmus (concurrency): aj pri nulovom delay môže robot limitovať maximálny počet súbežných spojení na hostiteľské meno alebo IP. Politeness = delay × concurrency.
3. Backoff a adaptivita: kvalitní roboti spomalia pri chybách (429, 503), vysokých časoch odozvy alebo pri signáloch z WAF/CDN.
4. Rozlišovanie sekcií: citlivé endpointy (vyhľadávanie, filtrácia, ťažké JSON API) potrebujú iné tempo než statické HTML/obrázky.

Konfigurácia v robots.txt (praktické, ale s rozumom)

Ak sa rozhodnete použiť direktívu, uplatnite ju cielene pre konkrétneho user-agenta a zohľadnite, že nie každý bot ju rešpektuje:

User-agent: ExampleBot
Crawl-delay: 2

Pri väčších weboch dávajte prednosť selektívnym pravidlám a rozdeľte sekcie podľa náročnosti:

User-agent: ExampleBot
Disallow: /interny-vyhladavac
Crawl-delay: 1

Upozornenie: Neopierajte sa iba o Crawl-delay – berte ho ako hint, nie ako garanciu.

Riadenie crawl rýchlosti cez server a infra

• HTTP kódy a hlavičky: pre dočasné preťaženie vráťte 429 Too Many Requests alebo 503 Service Unavailable a pridajte Retry-After: 120. Kvalitní roboti spomalia.
• CDN a WAF: rate-limiting podľa IP/User-Agent, ochrana nákladných endpointov, špičkové tlmenie cez prahové hodnoty RPS.
• Cache stratégie: statické HTML/JSON/obrázky doručujte z edge cache, aby sa roboti netrafili priamo do originu pri vysokej frekvencii.
• Prioritizácia trás: rozlíšte rýchle „hot paths“ (home, kategórie, posledné články) a „cold paths“ (archív, stránkovanie > 50). Rôzne prahy rate-limitov podľa cesty.

Crawl delay a „crawl budget“: ako nájsť rovnováhu

Crawl budget je kombinácia capability (koľko robot vie prejsť) a demand (koľko robot chce prejsť). Príliš vysoký delay znižuje capability – robot navštívi menej URL a pomalšie. Príliš nízky delay zasa zvýši chybovosť a spomalí web pre ľudí. Cieľom je elastické tempo: rýchle pri nízkej záťaži, opatrné pri špičke.

Rozdiely medzi botmi a praktické dôsledky

• Vyhľadávacie roboty: majú sofistikovanú politeness logiku; často ignorujú univerzálne delay pokyny, ale reagujú na chybové kódy, latencie a sitemap signály (lastmod).
• AI/LLM crawlery: rastúci segment – nie vždy majú perfektnú politeness. Riaďte ich cez robots.txt, meta robot pokyny, rate-limity a prípadne požadujte registráciu/akreditáciu.
• Monitoring/scrapery: potrebujú tvrdšie limity. Identifikujte neznámych user-agentov a uplatnite progressive throttling.

Signály dôležitosti a plánovanie prehľadávania

Tempo prehľadávania by malo rešpektovať prioritu URL. Pomôžte robotom prioritizovať:

• Sitemapy s lastmod: generujte presný dátum a čas poslednej zmeny, ideálne segmentovo (produkty, blog, kategórie).
• Interné prelinkovanie: dôležité stránky majú nízku hĺbku klikov a zmysluplné navigačné väzby (BreadcrumbList, súvisiace články).
• Štruktúrované dáta: entitné značenie (Organization, Product, Article) signalizuje typ a relevanciu obsahu – uľahčuje selektívne prehľadávanie.

Modelovanie „politeness“: delay × concurrency × dynamika

Odporúčaný prístup je adaptívny throttling:

1. Monitorujte p95 TTFB, využitie CPU, latenciu DB a pomer 5xx/429.
2. Definujte prahy (napr. „ak p95 > 1500 ms alebo 5xx > 2 %, zvýš delay o +1 s a zníž concurrency o 1“).
3. Ponúknite hints robotom cez Retry-After a cdns hlavičky; udržiavajte prístupové logy pre audit.

Príklady konfigurácie a vzory

Minimalistický robots.txt pre neznámych botov:

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; pri prekročení 429 + Retry-After: 60

Selektívna priorita v sitemapách: častejšie aktualizované sekcie rozdeľte do samostatných sitemap súborov (napr. sitemap-posts.xml, sitemap-products.xml) a aktualizujte lastmod iba tam, kde sa skutočne zmenilo.

Čomu sa vyhnúť (anti-patterny)

• Globálne vysoké crawl-delay pre všetkých: dramaticky zníži objavenosť nového obsahu. Radšej limitujte špecifických botov alebo náročné sekcie.
• Ignorovanie serverových signálov: ak vraciate 429/503 bez Retry-After, robot nevie, kedy skúsiť znova.
• Jedna veľká sitemap bez segmentácie: sťažuje plánovanie prehľadávania a zvyšuje pravdepodobnosť neefektívnych návštev.
• Blokovanie CSS/JS bez dôvodu: moderné indexovanie používa rendering; zbytočné blokovania môžu poškodiť pochopenie layoutu a kvality stránky.

Meranie dopadu a observabilita

• Logy a metriky: sledujte požiadavky podľa user-agent, RPS, latenciu, chyby a cache hit ratio na CDN.
• „Freshness“ indikátory: porovnávajte čas poslednej zmeny (lastmod) s časom poslednej návštevy bota; pre kritické entity definujte SLO (napr. „90 % produktov znovu navštívených do 24 h“).
• Core Web Vitals pod záťažou: monitorujte LCP/INP/CLS počas špičiek pre crawl – ak degradujú, sprísnite limity pre bota alebo posilnite cache/infra.

Crawl delay v kontexte veľkých katalógov a JS-heavy webov

Pri tisícoch URL a dynamických filtráciách je key problém kombinatorická explózia. Riešenia:

• Kanoniikalizácia a rule-based indexácia: indexujte len reprezentatívne kombinácie; ostatné 404/410 alebo noindex, follow.
• Render budget: ak používate SSR/ISR, obmedzujte nákladné renderovanie pre dlhý chvost; robotom servírujte statické snímky a menej dôležité parametre nechajte mimo indexu.
• „Facet hygiene“: nepovoľte crawlerom voľné prehľadávanie interného vyhľadávača či nekonečných stránkovaní; kombinujte Disallow a rate limits.

Integrácia s politikou prístupnosti pre AI/LLM roboty

Ak publikujete obsah pre LLM indexy (AIO), vytvorte AI crawling policy stránku, kde definujete podmienky použitia, identifikáciu user-agentov, kontaktný kanál a požiadavku na rešpektovanie rate-limitov. Prispôsobte crawl delay podľa licenčných podmienok a obchodných priorít.

Praktický postup zavedenia

1. Audit: zmapujte sekcie webu podľa náročnosti (HTML, API, obrázky, vyhľadávanie).
2. Segmentácia: rozdeľte sitemapy a nastavte interné prelinkovanie tak, aby prioritné URL boli plytko v štruktúre.
3. Politeness politika: definujte prahy RPS, delay a concurrency per sekcia a per user-agent (aspoň pre top 5 botov).
4. Technické opatrenia: nastavte 429/503 + Retry-After, aktivujte CDN cache, zapnite WAF rate-limit pre náročné trasy.
5. Monitorovanie a tuning: priebežne dolaďujte prahy podľa reálnych metrík a sezónnosti.

FAQ (často kladené otázky)

Pomôže vysoký crawl-delay znížiť náklady?
Krátkodobo áno (menej požiadaviek na origin), ale dlhodobo môžete prísť o rýchle aktualizácie vo vyhľadávaní. Optimalizujte skôr CDN/cache a obmedzte len náročné sekcie.

Je „Crawl-delay“ spoľahlivý signál?
Nie je univerzálny. Rešpektujú ho len niektorí roboti. Vždy kombinujte s Retry-After, rate-limitmi a sitemapami.

Má zmysel dynamicky meniť delay podľa dennej doby?
Áno – počas špičky spomaľte, v noci povoľte rýchlejšie prehľadávanie. Robte to však cez infra (CDN/WAF), nie iba cez robots.txt.

Crawl delay je jeden z nástrojov „politeness“ – sám osebe však nestačí. Najlepšie výsledky dosiahnete kombináciou: segmentované sitemapy a interné prelinkovanie (priorita), adaptívne limity na úrovni CDN/WAF (stabilita), správne HTTP signály (riadenie rýchlosti) a priebežná observabilita (dôkaz o dopade). Takto udržíte rovnováhu medzi dostupnosťou, čerstvosťou indexu a výkonom pre reálnych používateľov aj AI/LLM systémy.