Ochrana pred crawl storm: rate limiting a caching

Ochrana pred „crawl storm“ v technickom SEO: prečo sú rate limiting a caching kľúčové

„Crawl storm“ je stav, keď roboty (vyhľadávače, agregátory, skriptované scrapery či interné audítorské nástroje) generujú nadmerné množstvo požiadaviek v krátkom čase. Dôsledkom sú prepálené zdroje, spomalenie renderingu, zvýšená latencia, vyššie chybovosti a v krajnom prípade nedostupnosť webu. V prostredí technického SEO ide o kritický jav, pretože rýchlosť a dostupnosť priamo ovplyvňujú indexáciu, hodnotenie kvality a používateľskú skúsenosť. Dve najefektívnejšie obranné línie sú rate limiting (riadenie priepustnosti) a caching (vyrovnávacia pamäť) – vzájomne sa dopĺňajú a mali by byť implementované koordinovane.

Príznaky a dopady „crawl stormu“

Skokový nárast RPS (requests per second) z jedného alebo niekoľkých ASN/IP rozsahov alebo User-Agentov.
Výrazný pokles „cache hit ratio“ a prudký rast „origin“ zaťaženia.
Zhoršenie P95/P99 latencie, nárast 429/503/5xx a naopak 2xx klesá.
Vyčerpanie CPU/IO, zvýšený počet „worker overflow“ a resetovaných spojení.
Negatívny vplyv na SEO: spomalené načítanie kritických stránok, znížené E-E-A-T signály vyplývajúce z výkonu, redislokácia crawl budgetu na málo hodnotné URL.

Strategický rámec: prevencia, absorpcia, degradácia, zotavenie

Prevencia: identifikujte a obmedzte agresívne zdroje vopred pomocou dynamických pravidiel, robot managementu a štruktúrovaného cacheovania. Absorpcia: maximalizujte cache hit ratio (CDN/edge cache, microcache) a izolujte origin. Riadená degradácia: počas špičky dočasne znížte priepustnosť pre menej dôležité segmenty a zachovajte dostupnosť kľúčových stránok. Zotavenie: rýchla obnova normálnej prevádzky, rehydratácia cache, aktualizácia pravidiel.

Rate limiting: princípy, modely a praktiky

Ciele: chrániť origin pred preťažením, spravodlivo prideľovať priepustnosť, odradiť neštandardných crawlerov bez penalizácie legitímnych robotov (napr. Googlebot, Bingbot).

Modely:

Token Bucket: flexibilný „burst allowance“ s priemernou rýchlosťou a maximálnym výbuchom.
Leaky Bucket: stabilná výstupná rýchlosť, vhodné pre vyhladenie tokov.
Fixed Window a Sliding Window: jednoduché kvóty za časové okno; sliding window je férovejší.

Granularita: limity per IP/ASN, per User-Agent, per prefix URL (napr. /search, /wp-json/, /api/), per metóda (GET/HEAD kontra POST), per krajina alebo per „bot class“ (verified vs. unverified).

Odozvy: používajte HTTP 429 Too Many Requests s hlavičkou Retry-After. Pre dočasné technické obmedzenia môže byť vhodné 503 Service Unavailable so Retry-After, no 429 lepšie signalizuje limitáciu klientovi.

Dobrá prax: whitelisting overených vyhľadávačov (reverse DNS + následné dopredné overenie), prísnejšie limity pre neznáme UA, samostatné koše pre API a HTML, „soft“ limity s postupnou penalizáciou (napomenutie → 429 → dočasný block).

Konfigurácia rate limiting na úrovni edge/CDN a web servera

Edge/CDN: uprednostnite limity na okraji siete, aby sa útok vůbec nedostal k originu. Nastavte per-path politiky (napr. prísnejšie pre /wp-login.php, /search, /xmlrpc.php) a dynamické „bot scores“ s challenge (napr. JavaScript challenge) pre nízkonákladovú verifikáciu.

Reverse proxy/web server: na Nginx používať kombináciu limit_req (požiadavky/s) a limit_conn (súbežné spojenia). Na Apache aktivovať moduly pre priepustnosť a connection throttling. Vždy logujte rejected a delayed požiadavky pre následnú analýzu.

Oddeľte interné nástroje: SEO audity, monitoring a health-checky smerujte na samostatné subdomény s vyššími kvótami a explicitnou autentifikáciou, aby nedochádzalo k falošným pozitívam.

Caching: vrstvy, stratégie a zásady pre SEO & výkon

Vrstvy cache: prehliadačová cache → CDN/edge cache → microcache na reverse proxy → aplikačná cache (napr. objekty, výsledky DB) → perzistentná cache (Redis/Memcached). Čím bližšie k používateľovi, tým väčší odklon od originu.

Statické zdroje: agresívne verzované (style.abc123.css) a dlhé TTL (dni až mesiace) s Cache-Control: public, max-age=31536000, immutable.

HTML cache: krátke TTL (sekundy až minúty) cez microcache, „stale-while-revalidate“ a „stale-if-error“ na zachovanie dostupnosti počas obnovy. Pre personalizáciu používajte Vary iba tam, kde je nevyhnutné (napr. Vary: Accept-Encoding, nie Vary: Cookie plošne), inak fragmentujte cache.

Revalidácia: používajte ETag a Last-Modified pre efektívne 304 Not Modified. Znížite dátovú záťaž aj pri zvýšenom crawl rate.

Normalizácia cache key: odstráňte zbytočné query parametre (utm, fbclid), zjednoťte trailing slash, protokol a host aliasy; predídete „cache bustingu“ a duplicitám v indexácii.

Koordinácia rate limiting a caching pre maximálnu odolnosť

Najprv „absorbuje“ cache (edge/microcache), až potom zasahuje rate limiting. Tým obmedzíte falošné zásahy do legitímneho crawl budgetu.
Pre cesty s nízkou „cacheability“ (personalizované HTML, POST/PUT) nastavte prísnejšie limity a dedikované „buckets“.
Pri „warming the cache“ po deployi dočasne uvoľnite limity pre interného warm-up bota, ale izolujte ho na IP a UA.

SEO špecifiká: ako nepoškodiť indexáciu

Overenie legitímnych botov: Googlebot a Bingbot validujte cez reverse DNS; pre overených botov používajte vyššie limity a širšiu cache.
HTTP kódy: uprednostnite 429 s Retry-After pri dočasnom škrtení; pri údržbe 503 so zmysluplným časom. Dlhodobé 5xx poškodzujú crawl a ranking.
Robots & crawl budget: robots.txt nepodporuje univerzálne Crawl-delay (Google ho ignoruje); radšej riadte priepustnosť technicky a monitorujte „Crawl stats“ v nástrojoch vyhľadávačov.
Sitemapy a priorita: aktualizujte lastmod a nechajte dôležité URL dostupné s vyšším TTL cache, aby mali nízku latenciu pri crawli.

Monitorovanie, metriky a alerting

Traffic a výkon: RPS, súbežné spojenia, P50/P95/P99 latencia, 2xx/3xx/4xx/5xx rozklad, 429/503 počty, „origin shield“ zaťaženie.
Cache: hit ratio per path, počet revalidácií (304), „miss cost“ (CPU/DB čas), veľkosť a rotácia cache.
Bot intel: top UA, top ASN/IP, zmeny v správaní, anomálie (burst detection, zmena entropie UA reťazcov).
Alerty: prahové aj anomálne – „RPS > baseline + Xσ“, „429 rate > Y%“, „hit ratio < Z%“.

Incident playbook pri „crawl storme“

Detekcia: potvrďte zdroj (UA, ASN, path). Skontrolujte, či nejde o vlastný audit alebo legitímny bot.
Stabilizácia: sprísnite limity pre zdroj, aktivujte challenge, zapnite microcache s krátkym TTL a „stale-if-error“.
Prioritizácia: chráňte kľúčové šablóny (homepage, PLP/PDP, checkout) cez whitelisting a vyššie kvóty.
Komunikácia: informujte SEO/Content/DevOps o dočasných zmenách, použite status page.
Forenzná analýza: vytvorte podpis (signatúru) správania a aktualizujte trvalé pravidlá.
Postmortem: metricky vyhodnoťte dopad na výkon a indexáciu, navrhnite preventívne opatrenia.

Príklady hlavičiek a zásad konfigurácie

Cache-Control pre HTML: Cache-Control: public, max-age=60, stale-while-revalidate=30, stale-if-error=300
Revalidácia: ETag: "W/xyz", Last-Modified: Tue, 21 Oct 2025 10:00:00 GMT
Statika s verziovaním: Cache-Control: public, max-age=31536000, immutable
Rate limiting odozva: HTTP/1.1 429 Too Many Requests, Retry-After: 120
Vary minimalizmus: Vary: Accept-Encoding a selektívne Vary: Accept-Language podľa potreby.

Špecifiká pre e-commerce a dynamické stránky

Microcache HTML: 15–60 s pre PLP a PDP výrazne pomáha absorbovať špičky aj pri častých zmenách skladovosti.
Fragment cache/ESI: personalizované bloky (napr. košík) renderujte oddelene s krátkym TTL, zvyšok stránky cacheujte dlhšie.
Search a filtrácia: na cesty typu /search aplikujte prísnejšie limity a normalizáciu parametrov, aby ste predišli „parametrickému výbuchu“ URL.

Bot manažment a verifikácia

Overenie User-Agentov: kombinujte deklarovaný UA s reverse DNS a prípadnou HTTP verifikáciou (napr. pre prístup k „/bot-verification“ endpointu).
Policy podľa tried: verified search bots (vyššie limity), legitímne nástroje (stredné), neznáme/skriptované (nízke + challenge).
Adaptívne pravidlá: pri anomálii znižujte limity per ASN a zvyšujte TTL microcache.

Testovanie, load simulácia a „chaos“ cvičenia

Replay logov: simulujte historické bursty a overte, že cache + limity držia SLO.
Syntetické testy: rozlíšte profily (bot vs. user), použite rôzne UA a parametre, sledujte 429/503 a latenciu.
Chaos scenáre: vypnite cache vrstvu v testovacom prostredí a overte degradačné módy a automatické prepínače.

Checklist implementácie

Edge/CDN microcache pre HTML s „stale-while-revalidate“ a „stale-if-error“.
Normalizácia URL a parametrického priestoru, odstraňovanie tracking parametrov.
Rate limiting per path, per UA, per IP/ASN; samostatné koše pre API a HTML.
Whitelisting overených vyhľadávačov; reverzná verifikácia a pravidelné revízie.
Hlavičky: rozumné Cache-Control, ETag, Last-Modified, minimálny Vary.
Monitoring: RPS, latencia, 429/503, cache hit ratio, origin load, top UA/ASN.
Incident playbook a postmortem proces; pravidelné testy a školenia.

Najčastejšie chyby a ako sa im vyhnúť

Plošné blokovanie Googlebotu či iných legitímnych botov bez verifikácie.
Nadmerné používanie Vary: Cookie a zbytočné fragmentovanie cache.
Ignorovanie revalidácie (ETag/Last-Modified) a zbytočné 200 namiesto 304.
Limity iba na IP bez zohľadnenia ASN a rotujúcich proxynetov.
Neexistencia „stale-if-error“, čo vedie k výpadkom namiesto slušnej degradácie.

„Crawl storm“ nie je len bezpečnostný alebo infra problém – je to aj problém technického SEO a výkonu. Najlepšia obrana kombinuje inteligentné rate limiting (spravodlivá priepustnosť, presné škálovanie a verifikácia botov) s robustným cachingom (edge/microcache, verziovanie, revalidácia, normalizácia). Doplnené o kvalitné monitorovanie, incident playbook a pravidelné testovanie vytvárajú systém, ktorý zvládne prudké špičky bez straty dostupnosti a bez negatívneho dopadu na indexáciu a používateľskú skúsenosť.