Log analýza: Dekódování dat a získávání klíčových SEO poznatků

Co je log analýza a proč je klíčová pro technické SEO

Log analýza je systematické studium surových záznamů webového serveru, CDN nebo reverzní proxy. Cílem je porozumět tomu, jak se reálně chová vyhledávací crawler, jaké URL navštěvuje, jakou frekvencí, jaký status kód vracíme a jaké jsou výkonnostní charakteristiky odpovědí. Na rozdíl od nástrojů třetích stran a crawlerů logy zobrazují skutečnou poptávku a skutečnou odezvu – bez odhadů a vzorkování na straně prohlížeče.

Typy logů a kde je získat

Webserver logy: Apache, Nginx, IIS (access/error logy).
CDN logy: Cloudflare, Akamai, Fastly – obsahují i cache hity/missy a bezpečnostní atributy.
Proxy/WAF logy: reverzní proxy, load balancer, firewall – důležité pro blokace/captcha.
Aplikační logy: rámcové „request logs“ s business ID, které umožní párování s CMS.

Ideálně je sloučit zdroje (server + CDN), abyste viděli celou cestu požadavku (edge → origin) a mohli rozlišit cache hity, limity, přesměrování a retry chování.

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

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

Časová značka (UTC, sekundová přesnost) – 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šování kanonických a parametrizovaných stránek.
Status kód (2xx/3xx/4xx/5xx) – zdraví webu a překážky indexace.
Odezvový čas (TTFB, upstream time) – výkon originu vs. edge.
Velikost v bytech (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).
Cache status (HIT/MISS/BYPASS/STALE) – kolik servíruje CDN vs. origin.
Referer – užitečné při odhalování interních smyček a redirect řetězců.

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

Při přenosu logů do analytických nástrojů minimalizujte osobní údaje (maskování IP, zkracování query parametrů s PII). Nastavte retenci dle firemních pravidel (např. 90–180 dní pro SEO), read-only přístup pro analytiky a verzujte parsovací schémata.

Ingest a zpracování: od surových logů po dotazovatelná data

Ingest: S3/GCS jako „landing zone“, následně ETL do datového skladu (BigQuery/Snowflake/ClickHouse).
Parsing: definujte schéma polí; pro JSON preferujte explicitní klíče před regexy.
Normalizace URL: lowercase cesty, odstranění trailing slasha, seřazení parametrů, whitelist důležitých parametrů.
Bot klasifikace: tabulka známých UA + validace reverzním DNS a ASN; označte „suspektní“ hity.
Sessionizace crawlera: seskupení podle bot-ID (IP+UA), 5minutová okna pro sekvenční analýzy.

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

Reverse DNS a forward-confirmation: pro Googlebot požadujte PTR končící na googlebot.com nebo google.com a následný A záznam zpět na tutéž IP.
Kontrola ASN: porovnejte proti známé autonomní síti poskytovatele (např. AS15169 pro Google).
Heuristika chování: reální boti respektují robots.txt, nejsou agresivně paralelní a používají HEAD.

Klíčové otázky, na které logy poskytují odpovědi

Které URL jsou reálně crawlovány a jak často (dle sekcí, hloubky a typu obsahu)?
Kde spotřebováváme crawl budget na nízkohodnotových stránkách (parametry, kalendáře, nekonečné listingy)?
Jaké překážky indexace existují (4xx, 5xx, 429, dlouhé TTFB, redirect řetězce)?
Respektují boti canonical a hreflang nebo opakovaně navštěvují duplicity?
Jaký je reálný dopad nasazení na dostupnost a frekvenci crawlů?

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 navštívil alespoň jednou za období	Ukazuje 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 na indexovatelných
Redirect depth	Průměrný počet přesměrování na požadavek	Každý hop plýtvá budgetem a zvyšuje latenci	≤ 1, žádné dlouhé řetězce
TTFB p95 (bot traffic)	95. percentil času do prvního bajtu	Výkon originu pro HTML dokumenty	< 500 ms na klíčových hubech
Cache hit ratio	Podíl HIT z CDN na HTML a statikách	Snižuje tlak na origin a zvyšuje rychlost	> 80 % pro statiky, selektivně pro HTML
Parametrická entropie	Počet unikátních kombinací query parametrů na cestu	Detekuje URL explozi a duplicity	Minimalizovat na whitelisted parametry

Analytické pohledy: od rychlých vítězství po hluboké poznatky

Mapa crawl-cesty: sekvenční analýza hitů bota od vstupní URL, odhaluje interní směrování a zacyklení.
„Wasted crawl“ report: hity na noindex, 404, nekonečné parametry, staging subdomény.
„Freshness“ profil: jak rychle po změně (nasazení, nový obsah) boti recrawlují dotčené URL.
„Heavy page“ seznam: HTML s velikostí nad prahem (např. 300 kB) nebo s p95 TTFB výrazně nad cílem.
Redirect řetězce v čase: dočasné řetězce po migraci, které nebyly odstraněny.
Mobile vs. desktop bot: rozdíly v pokrytí při Mobile-First Index; prioritizujte mobilní HTML.

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

Blokujte nízkohodnotové vzory (robots.txt/HTTP 410/pravidla) pro nekonečné filtry a interní vyhledávání.
Stabilizujte kanonickou hierarchii (jedna indexovatelná cesta), přesměrujte „duplicitní“ varianty.
Zrychlete HTML dokumenty (cache na edge, pre-render, optimalizace DB) – rychlejší TTFB = efektivnější crawl.
Opravte 404/5xx hotspoty podle sekcí; snížíte negativní signál spolehlivosti.
Omezte počet redirect hopů na max. 1; po migraci konsolidujte na přímé 301.

Výkon a infrastruktura: co z logů zjistíte pro DevOps

Špičky zatížení dle hodin a geolokace – plánování kapacity a autoscaling.
Adopce HTTP/2/3 – ovlivňuje paralelismus a latenci, zejména na CDN edge.
Cache-kontrola (Cache-Control, ETag, Last-Modified) – ověřte, zda CDN může efektivně cachovat.
Upstream time vs. total request time – přesné lokalizování latencí (aplikace vs. síť).

Nástrojový ekosystém: od desktopu po datové sklady

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

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

Hypotéza: „Bot míjí budget na parametrických listingech“.
Důkaz z logů: vysoká frekvence GET s různými parametry, nízká návštěvnost HTML bez indexační hodnoty.
Zásah: pravidla robots.txt pro konkrétní parametry + interní odkazy směrovat na kanonické URL.
Měření: do 7–14 dní pokles hitů na nehodnotné URL, růst pokrytí na hubech.

Reporty, které by neměly chybět na měsíční bázi

Top 100 nejčastěji crawlovaných URL a jejich status/TTFB vývoj.
URL bez návštěv od bota > 60 dní z indexovatelné sitemap.
Wasted crawl (noindex, 404, 5xx, duplicitní parametry) a trend po zásazích.
Redirect řetězce nad 1 hop; TOP vstupní a výstupní uzly.
CDN cache ratio a původ latencí (edge vs. origin).

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

HTML vs. JSON/API hity: pokud crawler často požaduje API, zvažte server-side rendering (SSR) nebo hydratační strategii.
Pre-render/edge-side includes: z logů sledujte, zda HTML vzniká rychle a stabilně u mobilních UA.
Sitemapy a jejich čtení: bot by měl pravidelně požadovat sitemap.xml; pokud ne, zkontrolujte odkaz v robots.txt.

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

Validované pravidla robots.txt na stagingu, simulace přes HEAD/GET a porovnání provozu.
Při migraci definované 1:1 mapování URL a monitor řetězců 301.
Po nasazení spuštěný „smoke test“: status mix, TTFB p95, 5xx alarmy.
Aktualizované kanonické tagy a interní odkazy směřující na finální URL.

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

Spoléhání se pouze na UA řetězec bez DNS/ASN verifikace – vede k nafouknutým číslům botů.
Nenormalizované URL – stejný zdroj ve výsledcích figuruje jako více entit.
Zaměňování edge a origin časů – chybné závěry o výkonu aplikace.
Chybějící segmentace (mobile/desktop bot, typ stránky) – průměr skrývá problémové clustery.
Krátká retenční doba – nevidíte sezonnost ani dlouhé recrawl cykly.

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

Dny 1–30: přístup k logům, schéma, normalizace URL, ověření botů, základní reporty (status mix, coverage).
Dny 31–60: zásahy proti wasted crawl, úklid redirectů, ladění cache politiky, monitoring p95 TTFB.
Dny 61–90: hluboká segmentace dle sekcí, SPA/SSR audit, automatizace dashboardů a alertů.

Výstupy pro stakeholdery: co komu ukázat

SEO tým: coverage, wasted crawl, re-crawl po změnách obsahu.
DevOps: p95 TTFB dle služby, cache ratio, špičky a 5xx korelace s releasy.
Produkt: parametry/listingy generující URL explozí, návrh omezení filtrů.
Management: trend dostupnosti, rizika migrací, dopad na organický výkon.

Shrnutí: logy jako zdroj pravdy

Log analýza odkrývá, jak opravdu procházejí boti váš web a co je zpomaluje. Umožňuje šetřit crawl budget, zrychlit HTML, konsolidovat URL při migracích a přesně měřit dopad změn. Kdo logy nečte, optimalizuje „naslepo“. Zavádějte disciplinovaný ingest, robustní normalizaci a pravideln