Analýza logů: dekódování dat a získávání klíčových SEO poznatků

Co je analýza logů a proč je kritická pro technické SEO

Analýza logů je systematické studium surových záznamů webového serveru, CDN nebo reverzní proxy. Cílem je pochopit, jak se vyhledávací crawler skutečně chová, jaké URL navštěvuje, s jakou frekvencí, jaký stavový kód vracíme a jaké jsou výkonnostní charakteristiky odpovědí. Na rozdíl od nástrojů třetích stran a crawlerů zobrazují logy skutečné požadavky a skutečné odpovědi – bez odhadů a vzorků na straně prohlížeče.

Typy logů a kde je získat

Logy webového serveru: Apache, Nginx, IIS (access/error logy).
Logy CDN: Cloudflare, Akamai, Fastly – obsahují také informace o cache hitech/missech a bezpečnostních atributech.
Logy proxy/WAF: reverzní proxy, load balancer, firewall – důležité pro blokování a CAPTCHA.
Aplikační logy: obecné „request logs“ s business ID, které umožňují párování s CMS.

Ideální je sloučit zdroje (server + CDN), abyste viděli celou cestu požadavku (edge → origin) a dokázali rozlišit cache hity, omezení, přesměrování a chování při opakovaných pokusech.

Formáty a pole: co potřebujete vidět v každém řádku

Nejčastěji se setkáte s formátem Combined/Custom Log Format nebo JSON. Klíčová pole pro SEO a výkon:

Časové razítko (UTC, přesnost na sekundy) – korelace s nasazením a anomáliemi.
Metoda (GET/HEAD) a verze protokolu (HTTP/2, HTTP/3) – dopad na paralelismus a latenci.
URL (úplná cesta + query string) – rozlišení kanonických stránek a stránek s parametry.
Stavový kód (2xx/3xx/4xx/5xx) – stav webu a překážky indexace.
Doba odezvy (TTFB, upstream time) – výkon originu oproti edge.
Velikost v bajtech (response size) – dopad na crawl, přenosy a spotřebu zdrojů.
User-Agent – identifikace crawlerů a prohlížečů.
IP/ASN – ověření pravosti botů (např. Googlebot z AS15169).
Stav cache (HIT/MISS/BYPASS/STALE) – jaký podíl obsahu obsluhuje CDN oproti originu.
Referer – užitečný při odhalování interních smyček a řetězců přesměrování.

Bezpečnost a soulad: anonymizace, retenční politika, přístupová práva

Při přenosu logů do analytických nástrojů minimalizujte množství osobních údajů (maskování IP adres, zkracování query parametrů obsahujících PII). Nastavte dobu uchovávání podle firemních pravidel (např. 90–180 dní pro SEO), analytikům udělte přístup pouze pro čtení a verzujte schémata parsování.

Ingest a zpracování: od surových logů po data, nad kterými lze zadávat dotazy

Ingest: S3/GCS jako „landing zone“, následně ETL do datového skladu (BigQuery/Snowflake/ClickHouse).
Parsování: definujte schéma polí; u JSON upřednostňujte explicitní klíče před regulárními výrazy.
Normalizace URL: převod cest na malá písmena, odstranění koncového lomítka, seřazení parametrů, seznam povolených důležitých parametrů.
Klasifikace botů: tabulka známých UA + validace pomocí reverzního DNS a ASN; hity označte jako „podezřelé“.
Vytváření relací crawlera: seskupení podle ID bota (IP+UA), 5minutová okna pro sekvenční analýzy.

Ověření pravosti botů: jak analýzu nedeformovat falešnými UA

Reverzní DNS a dopředné potvrzení: u Googlebotu vyžadujte PTR končící na googlebot.com nebo google.com a následný záznam A ukazující zpět na stejnou IP adresu.
Kontrola ASN: porovnejte sítě se známou autonomní sítí poskytovatele (např. AS15169 pro Google).
Heuristika chování: skuteční boti respektují robots.txt, nepracují agresivně paralelně a používají HEAD.

Klíčové otázky, na které logy odpovídají

Které URL se skutečně procházejí a jak často (podle sekcí, hloubky a typu obsahu)?
Kde plýtváme crawl budgetem na stránkách s nízkou hodnotou (parametry, kalendáře, nekonečné výpisy)?
Jaké překážky indexace existují (4xx, 5xx, 429, dlouhé TTFB, řetězce přesměrování)?
Respektují boti canonical a hreflang, nebo opakovaně navštěvují duplicity?
Jaký je skutečný dopad nasazení na dostupnost a frekvenci procházení?

SEO metriky z logů: co měřit a jak interpretovat

Metrika	Popis	Proč je důležitá	Typický cíl
Crawl coverage	% indexovatelných URL, které bot v daném období navštívil alespoň jednou	Odhaluje nepokryté clustery a „sirotky“	> 90 % pro klíčové huby
Crawl frequency	Počet hitů na URL/sekci za den/týden	Signalizuje důležitost v očích vyhledávače	Stabilní nebo rostoucí
Status mix	Podíl 2xx/3xx/4xx/5xx/429	Odhaluje technické překážky	< 1 % 5xx, < 2 % 4xx u indexovatelných stránek
Redirect depth	Průměrný počet přesměrování na požadavek	Každý krok plýtvá budgetem a zvyšuje latenci	≤ 1, žádné řetězce
TTFB p95 (bot traffic)	95. percentil doby do prvního bajtu	Výkon originu u HTML dokumentů	< 500 ms u klíčových hubů
Cache hit ratio	Podíl odpovědí HIT z CDN u HTML a statického obsahu	Nižší zátěž originu a vyšší rychlost	> 80 % u statického obsahu, selektivně u HTML
Parametrická entropie	Počet unikátních kombinací query parametrů pro jednu cestu	Odhaluje explozi URL a duplicity	Omezit na minimum pomocí seznamu povolených parametrů

Analytické pohledy: od rychlých výher po hlubší zjištění

Mapa cesty crawlera: sekvenční analýza hitů bota od vstupní URL, odhaluje interní směrování a smyčky.
Report „Wasted crawl“: hity na stránky s noindex, 404, nekonečné parametry a stagingové subdomény.
Profil „Freshness“: jak rychle boti po změně (nasazení, nový obsah) znovu procházejí dotčené URL.
Seznam „Heavy page“: HTML s velikostí nad stanoveným limitem (např. 300 kB) nebo s p95 TTFB výrazně nad cílovou hodnotou.
Řetězce přesměrování v čase: dočasné řetězce po migraci, které nebyly odstraněny.
Mobilní vs. desktopový bot: rozdíly v pokrytí při Mobile-First Index; upřednostněte mobilní HTML.

Vliv na indexaci a crawl budget: praktické zásahy

Blokujte vzory s nízkou hodnotou (robots.txt/HTTP 410/pravidla) pro nekonečné filtry a interní vyhledávání.
Stabilizujte kanonickou hierarchii (jedna indexovatelná cesta), varianty „duplicitních“ URL přesměrujte.
Zrychlete HTML dokumenty (cachování na edge, předrenderování, optimalizace DB) – rychlejší TTFB znamená efektivnější crawl.
Opravte problematická místa s chybami 404/5xx podle sekcí; snížíte negativní signál spolehlivosti.
Omezte počet přesměrování na maximálně 1; po migraci sjednoťte přesměrování do přímých 301.

Výkon a infrastruktura: co z logů vyčtete pro DevOps

Špičky zátěže podle hodin a geolokace – plánování kapacity a automatické škálování.
Adopce HTTP/2/3 – ovlivňuje paralelismus a latenci, zejména na edge CDN.
Kontrola cache (Cache-Control, ETag, Last-Modified) – ověřte, zda CDN může efektivně cachovat.
Upstream time oproti request time – přesná lokalizace latencí (aplikace vs. síť).

Ekosystém nástrojů: od desktopu po datové sklady

Desktopové/komerční: Screaming Frog Log File Analyser, Botify/Oncrawl/ContentKing (konektory pro logy).
Open-source stack: Logstash/Fluentd → ClickHouse/BigQuery → Metabase/Superset/Grafana.
Cloudové logy CDN: export do S3/GCS s rotační politikou a vývojem schématu.

Postup práce: rámec hypotéza → důkaz → zásah → měření

Hypotéza: „Bot plýtvá budgetem na výpisech s parametry“.
Důkaz z logů: vysoká frekvence požadavků GET s různými query, nízká návštěvnost HTML bez indexační hodnoty.
Zásah: pravidla robots.txt pro konkrétní parametry + interní odkazy směřovat na kanonické URL.
Měření: do 7–14 dní pokles hitů na URL bez hodnoty, růst pokrytí u hubů.

Reporty, které by neměly chybět v měsíčních výstupech

Top 100 nejčastěji procházených URL a vývoj jejich stavových kódů/TTFB.
URL z indexovatelné sitemap, které bot nenavštívil déle než 60 dní.
Wasted crawl (noindex, 404, 5xx, duplicitní parametry) a trend po zásazích.
Řetězce přesměrování delší než 1 krok; TOP vstupní a výstupní uzly.
Poměr cache CDN a zdroj latencí (edge vs. origin).

Speciální případy: vykreslování JS, SPA a dynamické stránky

Hity HTML vs. JSON/API: pokud crawler často požaduje API, zvažte server-side render (SSR) nebo strategii hydratace.
Předrenderování/edge-side includes: z logů sledujte, zda HTML vzniká rychle a stabilně při mobilním UA.
Sitemapy a jejich načítání: bot by měl pravidelně požadovat sitemap.xml; pokud tomu tak není, zkontrolujte odkaz v robots.txt.

Kontrolní seznam před nasazením změn

Pravidla robots.txt ověřená na stagingu, simulace pomocí HEAD/GET a porovnání provozu.
Při migraci definované mapování URL 1:1 a monitorování řetězců 301.
Po nasazení spuštěný „smoke test“: poměr stavových kódů, TTFB p95, upozornění na 5xx.
Aktualizované kanonické značky a interní odkazy směřující na finální URL.

Nejčastější chyby při analýze logů

Spoléhání se pouze na řetězec UA bez ověření DNS/ASN – vede k nadhodnoceným počtům botů.
Neznormalizované URL – stejný zdroj se v analýze objevuje jako více entit.
Zaměňování časů edge a originu – nesprávné závěry o výkonu aplikace.
Chybějící segmentace (mobilní/desktopový bot, typ stránky) – průměr skrývá problémové clustery.
Krátká doba uchovávání – neuvidíte sezónnost ani dlouhé cykly opětovného procházení.

Implementační plán na 30–60–90 dní

Dny 1–30: přístup k logům, schéma, normalizace URL, ověřování botů, základní reporty (poměr stavových kódů, pokrytí).
Dny 31–60: zásahy proti wasted crawl, čištění přesměrování, ladění politiky cache, monitorování p95 TTFB.
Dny 61–90: hlubší segmentace podle sekcí, audit SPA/SSR, automatizace dashboardů a upozornění.

Výstupy pro stakeholdery: co komu ukázat

SEO tým: pokrytí, wasted crawl, opětovné procházení po změnách obsahu.
DevOps: p95 TTFB podle služby, poměr cache, špičky a korelace chyb 5xx s vydáními.
Produkt: parametry/výpisy generující explozi URL, návrh omezení filtrů.
Management: trend dostupnosti, rizika migrací, dopad na organický výkon.

Shrnutí: logy jako zdroj pravdy

Analýza logů odhaluje, jak boti vaším webem skutečně procházejí a co je brzdí. Umožňuje šetřit crawl budget, zrychlit HTML, sjednotit URL při migracích a přesně měřit dopad změn. Kdo logy nečte, optimalizuje „naslepo“. Zaveďte disciplinovaný ingest, robustní normalizaci a pravidelný reporting – a proměňte logy v konkurenční výhodu v technickém SEO i výkonu.