Ochrana před „crawl stormem“: implementace rate limitingu a inteligentního cachování

Ochrana před „crawl stormem“ v technickém SEO: proč jsou rate limiting a caching klíčové

„Crawl storm“ je stav, kdy roboti (vyhledávače, agregátory, skriptované scrapery či interní auditní nástroje) generují v krátkém čase nadměrné množství požadavků. Důsledkem je přetížení zdrojů, zpomalení renderování, zvýšená latence, vyšší chybovost a v krajním případě nedostupnost webu. V prostředí technického SEO jde o kritický jev, protože rychlost a dostupnost přímo ovlivňují indexaci, hodnocení kvality a uživatelskou zkušenost. Dvě nejúčinnější obranné linie jsou rate limiting (řízení propustnosti) a caching (ukládání do mezipaměti) – vzájemně se doplňují a měly by být implementovány koordinovaně.

Příznaky a dopady „crawl stormu“

Skokový nárůst RPS (requests per second) z jednoho nebo několika rozsahů ASN/IP nebo od některých User-Agentů.
Výrazný pokles „cache hit ratio“ a prudký nárůst zátěže „originu“.
Zhoršení latence P95/P99, nárůst počtu odpovědí 429/503/5xx a naopak pokles počtu odpovědí 2xx.
Vyčerpání CPU/IO, zvýšený počet případů „worker overflow“ a resetovaných spojení.
Negativní dopad na SEO: pomalejší načítání klíčových stránek, oslabení signálů E-E-A-T souvisejících s výkonem, přesun crawl budgetu na málo hodnotné URL.

Strategický rámec: prevence, absorpce, degradace, zotavení

Prevence: předem identifikujte a omezte agresivní zdroje pomocí dynamických pravidel, správy robotů a strukturovaného cachování. Absorpce: maximalizujte cache hit ratio (CDN/edge cache, microcache) a izolujte origin. Řízená degradace: během špičky dočasně omezte propustnost pro méně důležité segmenty a zachovejte dostupnost klíčových stránek. Zotavení: rychle obnovte běžný provoz, znovu naplňte cache a aktualizujte pravidla.

Rate limiting: principy, modely a postupy

Cíle: chránit origin před přetížením, spravedlivě přidělovat propustnost a odrazovat nestandardní crawlery, aniž by byli penalizováni legitimní roboti (např. Googlebot, Bingbot).

Modely:

Token Bucket: flexibilní „burst allowance“ s průměrnou rychlostí a maximální špičkou.
Leaky Bucket: stabilní výstupní rychlost, vhodná pro vyhlazení toků.
Fixed Window a Sliding Window: jednoduché kvóty pro časové okno; sliding window je spravedlivější.

Granularita: limity podle IP/ASN, podle User-Agentu, podle prefixu URL (např. /search, /wp-json/, /api/), podle metody (GET/HEAD oproti POST), podle země nebo podle „třídy botů“ (ověření vs. neověření).

Odpovědi: používejte HTTP 429 Too Many Requests s hlavičkou Retry-After. Při dočasných technických omezeních může být vhodná odpověď 503 Service Unavailable s hlavičkou Retry-After, ale kód 429 signalizuje klientovi omezení lépe.

Dobrá praxe: zařazení ověřených vyhledávačů na whitelist (reverzní DNS + následné dopředné ověření), přísnější limity pro neznámé UA, samostatné kvóty pro API a HTML, „měkké“ limity s postupným zpřísňováním (upozornění → 429 → dočasné zablokování).

Konfigurace rate limitingu na úrovni edge/CDN a webového serveru

Edge/CDN: upřednostněte limity na okraji sítě, aby se požadavky vůbec nedostaly k originu. Nastavte zásady pro jednotlivé cesty (např. přísnější pro /wp-login.php, /search, /xmlrpc.php) a dynamické „bot scores“ s ověřovací výzvou (např. JavaScript challenge) pro nenákladné ověření.

Reverse proxy/webový server: v Nginxu používejte kombinaci limit_req (požadavky/s) a limit_conn (souběžná spojení). V Apache aktivujte moduly pro řízení propustnosti a omezování rychlosti připojení. Vždy zaznamenávejte rejected a delayed požadavky pro následnou analýzu.

Oddělte interní nástroje: SEO audity, monitoring a health checky směrujte na samostatné subdomény s vyššími kvótami a výslovným ověřováním, aby nedocházelo k falešně pozitivním detekcím.

Caching: vrstvy, strategie a zásady pro SEO & výkon

Vrstvy cache: cache prohlížeče → CDN/edge cache → microcache na reverse proxy → aplikační cache (např. objekty, výsledky databázových dotazů) → perzistentní cache (Redis/Memcached). Čím blíže uživateli se cache nachází, tím méně požadavků míří na origin.

Statické zdroje: důsledně verzujte (např. style.abc123.css) a nastavte dlouhé TTL (dny až měsíce) s hlavičkou Cache-Control: public, max-age=31536000, immutable.

HTML cache: nastavte krátké TTL (sekundy až minuty) prostřednictvím microcache, „stale-while-revalidate“ a „stale-if-error“, abyste zachovali dostupnost během obnovy. Pro personalizaci používejte Vary pouze tam, kde je to nezbytné (např. Vary: Accept-Encoding, nikoli plošně Vary: Cookie); jinak rozdělte cache na fragmenty.

Revalidace: používejte ETag a Last-Modified pro efektivní odpovědi 304 Not Modified. Snížíte datovou zátěž i při zvýšené rychlosti crawlování.

Normalizace cache key: odstraňte nepotřebné parametry dotazu (utm, fbclid), sjednoťte koncová lomítka, protokol a aliasy hostitele; předejdete tak „cache bustingu“ a duplicitám v indexaci.

Koordinace rate limitingu a cachingu pro maximální odolnost

Nejprve provoz „absorbuje“ cache (edge/microcache) a teprve potom zasáhne rate limiting. Omezíte tak falešné zásahy do legitimního crawl budgetu.
Pro cesty s nízkou „cacheability“ (personalizované HTML, POST/PUT) nastavte přísnější limity a vyhrazené „buckets“.
Při „warming the cache“ po nasazení dočasně uvolněte limity pro interního warm-up bota, ale izolujte ho podle IP a UA.

Specifika SEO: jak nepoškodit indexaci

Ověření legitimních botů: Googlebot a Bingbot ověřujte pomocí reverzního DNS; pro ověřené boty používejte vyšší limity a širší cache.
HTTP kódy: při dočasném omezování upřednostněte kód 429 s hlavičkou Retry-After; při údržbě použijte kód 503 s přiměřenou dobou. Dlouhodobé odpovědi 5xx poškozují crawlování a hodnocení.
Robots & crawl budget: robots.txt univerzálně nepodporuje Crawl-delay (Google ho ignoruje); propustnost raději řiďte technicky a sledujte „Crawl stats“ v nástrojích vyhledávačů.
Sitemapy a priorita: aktualizujte lastmod a zajistěte, aby byly důležité URL dostupné s vyšším TTL cache a měly při crawlování nízkou latenci.

Monitorování, metriky a upozornění

Provoz a výkon: RPS, souběžná spojení, latence P50/P95/P99, rozložení odpovědí 2xx/3xx/4xx/5xx, počty odpovědí 429/503, zátěž „origin shield“.
Cache: hit ratio podle cesty, počet revalidací (304), „miss cost“ (čas CPU/DB), velikost a rotace cache.
Informace o botech: nejčastější UA, nejčastější ASN/IP, změny v chování, anomálie (detekce špiček, změny entropie řetězců UA).
Upozornění: prahová i anomální – „RPS > baseline + Xσ“, „429 rate > Y%“, „hit ratio < Z%“.

Postup při incidentu „crawl storm“

Detekce: potvrďte zdroj (UA, ASN, cesta). Zkontrolujte, zda nejde o vlastní audit nebo legitimního bota.
Stabilizace: zpřísněte limity pro zdroj, aktivujte ověřovací výzvu, zapněte microcache s krátkým TTL a „stale-if-error“.
Stanovení priorit: chraňte klíčové šablony (homepage, PLP/PDP, checkout) pomocí zařazení na whitelist a vyšších kvót.
Komunikace: informujte SEO/Content/DevOps o dočasných změnách, využijte stavovou stránku.
Forenzní analýza: vytvořte podpis (signaturu) chování a aktualizujte trvalá pravidla.
Postmortem: vyhodnoťte dopad na výkon a indexaci pomocí metrik a navrhněte preventivní opatření.

Příklady hlaviček a zásad konfigurace

Cache-Control pro HTML: Cache-Control: public, max-age=60, stale-while-revalidate=30, stale-if-error=300
Revalidace: ETag: "W/xyz", Last-Modified: Tue, 21 Oct 2025 10:00:00 GMT
Statické soubory s verzováním: Cache-Control: public, max-age=31536000, immutable
Odpověď při rate limitingu: HTTP/1.1 429 Too Many Requests, Retry-After: 120
Minimalistické použití Vary: Vary: Accept-Encoding a podle potřeby selektivně Vary: Accept-Language.

Specifika pro e-commerce a dynamické stránky

Microcache HTML: 15–60 s pro PLP a PDP výrazně pomáhá absorbovat špičky i při častých změnách skladových zásob.
Fragment cache/ESI: personalizované bloky (např. košík) vykreslujte odděleně s krátkým TTL, zbytek stránky ukládejte do cache na delší dobu.
Vyhledávání a filtrování: pro cesty typu /search použijte přísnější limity a normalizaci parametrů, abyste předešli „parametrické explozi“ URL.

Správa a ověřování botů

Ověření User-Agentů: kombinujte deklarovaný UA s reverzním DNS a případným ověřením přes HTTP (např. přístupem ke koncovému bodu „/bot-verification“).
Zásady podle tříd: ověření vyhledávací roboti (vyšší limity), legitimní nástroje (střední), neznámé/skriptované nástroje (nízké limity + ověřovací výzva).
Adaptivní pravidla: při anomálii snižujte limity podle ASN a prodlužujte TTL microcache.

Testování, simulace zátěže a cvičení „chaos“

Přehrání logů: simulujte historické špičky a ověřte, že cache a limity dodržují SLO.
Syntetické testy: rozlišujte profily (bot vs. uživatel), používejte různé UA a parametry a sledujte odpovědi 429/503 i latenci.
Chaos scénáře: vypněte vrstvu cache v testovacím prostředí a ověřte režimy degradace a automatické přepínače.

Kontrolní seznam implementace

Edge/CDN microcache pro HTML s „stale-while-revalidate“ a „stale-if-error“.
Normalizace URL a parametrického prostoru, odstraňování sledovacích parametrů.
Rate limiting podle cesty, UA, IP/ASN; samostatné kvóty pro API a HTML.
Zařazení ověřených vyhledávačů na whitelist; reverzní ověřování a pravidelné revize.
Hlavičky: přiměřené Cache-Control, ETag, Last-Modified, minimální Vary.
Monitoring: RPS, latence, 429/503, cache hit ratio, zátěž originu, nejčastější UA/ASN.
Postup při incidentu a proces postmortem; pravidelné testy a školení.

Nejčastější chyby a jak se jim vyhnout

Plošné blokování Googlebotu či jiných legitimních botů bez ověření.
Nadměrné používání Vary: Cookie a zbytečné fragmentování cache.
Ignorování revalidace (ETag/Last-Modified) a zbytečné používání odpovědi 200 místo 304.
Limity založené pouze na IP bez zohlednění ASN a rotujících proxy sítí.
Chybějící „stale-if-error“, který vede k výpadkům místo řádné degradace.

„Crawl storm“ není jen bezpečnostní nebo infrastrukturní problém – je to také problém technického SEO a výkonu. Nejlepší obrana kombinuje inteligentní rate limiting (spravedlivá propustnost, přesné škálování a ověřování botů) s robustním cachingem (edge/microcache, verzování, revalidace, normalizace). Spolu s kvalitním monitoringem, postupem při incidentech a pravidelným testováním vytvářejí systém, který zvládne prudké špičky bez ztráty dostupnosti a bez negativního dopadu na indexaci a uživatelskou zkušenost.