Technologie

Ochrana před přetížením crawlery v technickém SEO

Frederik 0

Ochrana před „crawl storm“ 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í auditorské nástroje) generují nadměrné množství požadavků v krátkém čase. Důsledkem jsou přetížené zdroje, zpomalení renderingu, 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ů nebo User-Agentů.
  • Výrazný pokles „cache hit ratio“ a prudký nárůst zátěže „origin“ serveru.
  • Zhoršení P95/P99 latence, nárůst kódů 429/503/5xx a naopak pokles 2xx odpovědí.
  • Vyčerpání CPU/IO, zvýšený počet „worker overflow“ a resetovaných spojení.
  • Negativní dopad na SEO: zpomalené načítání kritických stránek, snížené E-E-A-T signály vyplývající z výkonu, přesun crawl budgetu na málo hodnotné URL.

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

Prevence: identifikujte a omezte agresivní zdroje předem pomocí dynamických pravidel, robot managementu a strukturovaného cacheování. Absorpce: maximalizujte cache hit ratio (CDN/edge cache, microcache) a izolujte origin. Ří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 per IP/ASN, per User-Agent, per prefix URL (např. /search, /wp-json/, /api/), per metoda (GET/HEAD oproti POST), per země nebo per „bot class“ (verified vs. unverified).

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 se Retry-After, ale 429 lépe signalizuje omezení klientovi.

Dobrá praxe: whitelistování ověřených vyhledávačů (reverse DNS + následné předběžné ověření), přísnější limity pro neznámé UA, samostatná pravidla 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: preferujte 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 výzvami (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 (současná 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: prohlížečová cache → 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 dlouhé 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, nikoli plošně Vary: Cookie), jinak fragmentujte cache.

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

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

Koordinace rate limiting a caching pro maximální odolnost

  • Nejprve „absorbuje“ cache (edge/microcache), až následně zasahuje rate limiting. Tím omezíte falešné zasažení legitimního crawl budgetu.
  • Pro cesty s nízkou „cacheability“ (personalizované HTML, POST/PUT) nastavte přísnější limity a dedikované segmenty („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; pro ověřené boty používejte vyšší limity a širší cache.
  • HTTP kódy: upřednostněte 429 s Retry-After při dočasném throttlingu; při údržbě 503 se smysluplným časem. Dlouhodobé 5xx negativně ovlivňují crawl a ranking.
  • Robots & crawl budget: robots.txt nepodporuje univerzální Crawl-delay (Google jej ignoruje); raději řiďte propustnost technicky a sledujte „Crawl stats“ v nástrojích vyhledávačů.
  • Sitemapy a priorita: aktualizujte lastmod a nechte důležité URL dostupné s vyšší TTL cache, aby měly nízkou latenci při crawlu.

Monitorování, metriky a alertování

  • Traffic a výkon: RPS, současná spojení, P50/P95/P99 latence, rozklad 2xx/3xx/4xx/5xx, počty 429/503, zátěž „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 (burst detection, 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). Ověřte, zda se nejedná o vlastní audit nebo legitimní bota.
  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, použ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ýznamně pomáhá pohlcovat š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 filtrování: na cesty jako /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: verified search bots (vyšší limity), legitimní nástroje (střední), neznámé/skriptované (nízké + challenge).
  • Adaptivní pravidla: při anomáliích 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ží SLA/SLO.
  • Syntetické testy: rozlišujte profily (bot vs. user), používejte 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í módy 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á pravidla 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

  • Hromadné 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 místo 304.
  • Limity pouze na IP bez zohlednění ASN a rotujících proxy serverů.
  • Neexistence „stale-if-error“, což vede k výpadkům místo slušné degradace.

„Crawl storm“ není jen bezpečnostní nebo infra 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é o kvalitní monitorování, incident playbook a pravidelné testování 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.

Frederik

Website:

Related Story