Technologie

Ochrana před přetížením crawlery: řízení propustnosti a cachování

Driver 0

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

„Crawl storm“ je stav, kdy roboty (vyhledávače, agregátory, skriptované scrapery či interní auditorské nástroje) generují nadměrné množství požadavků v krátkém čase. Důsledkem jsou přetížené zdroje, 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ě nejefektivnější obranné linie jsou rate limiting (řízení propustnosti) a caching (vyrovnávací paměť) – 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 ASN/IP rozsahů či User-Agentů.
  • Výrazný pokles „cache hit ratio“ a prudký růst zatížení origin serveru.
  • Zhoršení P95/P99 latence, nárůst kódů 429/503/5xx a naopak pokles 2xx odpovědí.
  • Využití CPU/IO do maxima, zvýšený počet „worker overflow“ a resetovaných spojení.
  • Negativní dopad na SEO: zpomalené načtení klíčových stránek, snížené E-E-A-T signály vyplývající z výkonu, redistribuce crawl budgetu na méně hodnotné URL.

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

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

Rate limiting: principy, modely a praktiky

Cíle: chránit origin před přetížením, spravedlivě přidělovat propustnost, odradit nestandardní crawlery bez penalizace legitimních robotů (např. Googlebot, Bingbot).

Modely:

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

Granularita: limity na IP/ASN, podle User-Agenta, podle prefixu URL (např. /search, /wp-json/, /api/), podle metody (GET/HEAD versus POST), podle země nebo podle „bot class“ (ověřený vs. neověřený).

Odezvy: používejte HTTP 429 Too Many Requests s hlavičkou Retry-After. Pro dočasná technická omezení může být vhodný 503 Service Unavailable s Retry-After, ale 429 lépe signalizuje limitaci klientovi.

Dobrá praxe: whitelistování ověřených vyhledávačů (reverse DNS + následné dopředné ověření), přísnější limity pro neznámé UA, samostatné kvóty pro API a HTML, „soft“ limity s postupnou penalizací (upozornění → 429 → dočasný blok).

Konfigurace rate limiting na úrovni edge/CDN a web serveru

Edge/CDN: upřednostněte limity na okraji sítě, aby se útok vůbec nedostal k originu. Nastavte per-path politiky (např. přísnější pro /wp-login.php, /search, /xmlrpc.php) a dynamické „bot scores“ s challenge (např. JavaScript challenge) pro nízkonákladovou verifikaci.

Reverse proxy/web server: na Nginx používejte kombinaci limit_req (požadavky/s) a limit_conn (souběžná spojení). Na Apache aktivujte moduly pro propustnost a connection throttling. Vždy logujte 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 explicitní autentifikací, aby nedocházelo k falešným pozitivům.

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

Vrstvy cache: cache v prohlížeči → CDN/edge cache → microcache na reverse proxy → aplikační cache (např. objekty, výsledky DB) → perzistentní cache (Redis/Memcached). Čím blíže uživateli, tím větší odklon od originu.

Statické zdroje: agresivně verzované (style.abc123.css) a s dlouhým TTL (dny až měsíce) s Cache-Control: public, max-age=31536000, immutable.

HTML cache: krátká TTL (sekundy až minuty) přes microcache, „stale-while-revalidate“ a „stale-if-error“ pro zachování dostupnosti během obnovy. Pro personalizaci používejte Vary pouze tam, kde je nezbytné (např. Vary: Accept-Encoding, ne plošně Vary: Cookie), jinak cache fragmentujte.

Revalidace: používejte ETag a Last-Modified pro efektivní 304 Not Modified. Snížíte datovou zátěž i při zvýšeném crawl rate.

Normalizace cache key: odstraňte zbytečné query parametry (utm, fbclid), sjednoťte trailing slash, protokol a host aliasy; předejdete „cache bustingu“ a duplicitám v indexaci.

Koordinace rate limiting a caching pro maximální odolnost

  • Nejprve „absorbuje“ cache (edge/microcache), až poté zasahuje rate limiting. Tím omezíte falešné zásahy do legitimního crawl budgetu.
  • U cest s nízkou „cacheability“ (personalizované HTML, POST/PUT) nastavte přísnější limity a dedikované „buckets“.
  • Při „warming the cache“ po deployi dočasně uvolněte limity pro interní warm-up bota, ale izolujte ho na IP a UA.

SEO specifika: jak nepoškodit indexaci

  • Ověření legitimních botů: Googlebot a Bingbot validujte přes reverse DNS; u ověřených botů používejte vyšší limity a širší cache.
  • HTTP kódy: preferujte 429 s Retry-After při dočasném škrtení; při údržbě použijte 503 s vypovídajícím časem. Dlouhodobé 5xx poškozují crawl a ranking.
  • Robots & crawl budget: robots.txt nepodporuje univerzální Crawl-delay (Google ho ignoruje); raději řiďte propustnost technicky a monitorujte „Crawl stats“ v nástrojích vyhledávačů.
  • Sitemapy a priorita: aktualizujte lastmod a nechte důležité URL dostupné s vyšším TTL cache, aby měly nízkou latenci při crawlování.

Monitorování, metriky a alerting

  • Traffic a výkon: RPS, souběžná spojení, P50/P95/P99 latence, rozklad 2xx/3xx/4xx/5xx, počty 429/503, zatížení „origin shield“.
  • Cache: hit ratio per path, počet revalidací (304), „miss cost“ (CPU/DB čas), velikost a rotace cache.
  • Bot intel: top UA, top ASN/IP, změny v chování, anomálie (detekce burstů, změna entropie UA řetězců).
  • Alerty: prahové i anomální – „RPS > baseline + Xσ“, „429 rate > Y%“, „hit ratio < Z%“.

Incident playbook při „crawl stormu“

  1. Detekce: potvrďte zdroj (UA, ASN, path). Zkontrolujte, zda nejde o vlastní audit nebo legitimní bot.
  2. Stabilizace: zpřísněte limity pro zdroj, aktivujte challenge, zapněte microcache s krátkým TTL a „stale-if-error“.
  3. Prioritizace: chraňte klíčové šablony (homepage, PLP/PDP, checkout) přes whitelistování a vyšší kvóty.
  4. Komunikace: informujte SEO/Content/DevOps o dočasných změnách, využijte status page.
  5. Forenzní analýza: vytvořte podpis (signaturu) chování a aktualizujte trvalá pravidla.
  6. Postmortem: metricky vyhodnoťte dopad na výkon a indexaci, 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
  • Statika s verzováním: Cache-Control: public, max-age=31536000, immutable
  • Rate limiting odpověď: HTTP/1.1 429 Too Many Requests, Retry-After: 120
  • Vary minimalismus: Vary: Accept-Encoding a selektivně Vary: Accept-Language podle potřeby.

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 skladovosti.
  • Fragment cache/ESI: personalizované bloky (např. košík) renderujte odděleně s krátkým TTL, zbytek stránky cacheujte déle.
  • Search a filtrace: na cesty typu /search aplikujte přísnější limity a normalizaci parametrů, abyste předešli „parametrickému výbuchu“ URL.

Bot management a verifikace

  • Ověření User-Agentů: kombinujte deklarovaný UA s reverse DNS a případnou HTTP verifikací (např. pro přístup k „/bot-verification“ endpointu).
  • Policy podle tříd: ověření vyhledávací boti (vyšší limity), legitimní nástroje (střední), neznámé/skriptované (nízké + challenge).
  • Adaptivní pravidla: při anomálii snižujte limity per ASN a zvyšujte TTL microcache.

Testování, load simulace a „chaos“ cvičení

  • Replay logů: simulujte historické bursty a ověřte, že cache + limity drží SLO.
  • Syntetické testy: rozlište profily (bot vs. uživatel), použijte různé UA a parametry, sledujte 429/503 a latenci.
  • Chaos scénáře: vypněte cache vrstvu v testovacím prostředí a ověřte degradační režimy a automatické přepínače.

Checklist implementace

  • Edge/CDN microcache pro HTML s „stale-while-revalidate“ a „stale-if-error“.
  • Normalizace URL a parametrického prostoru, odstraňování tracking parametrů.
  • Rate limiting per path, per UA, per IP/ASN; samostatné kategorie pro API a HTML.
  • Whitelistování ověřených vyhledávačů; reverzní verifikace a pravidelné revize.
  • Hlavičky: rozumné Cache-Control, ETag, Last-Modified, minimální Vary.
  • Monitoring: RPS, latence, 429/503, cache hit ratio, origin load, top UA/ASN.
  • Incident playbook a postmortem proces; pravidelné testy a školení.

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

  • Masové 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é 200 odpovědi místo 304.
  • Limity pouze na IP bez zohlednění ASN a rotujících proxy sítí.
  • Neexistence „stale-if-error“, což vede k výpadkům místo adekvátní degradace.

„Crawl storm“ není pouze 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 verifikace botů) s robustním cachingem (edge/microcache, verzování, revalidace, normalizace). Doplněné kvalitním monitoringem, incident playbookem a pravidelným testováním vytváří systém, který zvládne prudké špičky bez ztráty dostupnosti a negativního dopadu na indexaci a uživatelskou zkušenost.

Driver

Website:

Related Story