Analýza logů pro pokročilé technické SEO

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

Log analýza je systematická studie surových záznamů webového serveru, CDN nebo reverzního proxy. Cílem je porozumět skutečnému chování vyhledávacího crawleru, 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ů logy zobrazují skutečnou poptávku a skutečnou odezvu – bez odhadů a vzorků 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í také cache hity/missy a bezpečnostní atributy.
Proxy/WAF logy: reverzní proxy, load balancer, firewall – důležité pro blokování/captcha.
Aplikační logy: rámcové „request logs“ s business ID, které umožňují párování s CMS.

Ideálně je slučovat zdroje (server + CDN), aby bylo možné vidět celou cestu požadavku (edge → origin) a rozlišit cache hity, omezení, 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 deployem 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 a parametrizovaných stránek.
Stavový kód (2xx/3xx/4xx/5xx) – zdraví webu a překážky indexace.
Odezvový čas (TTFB, upstream time) – výkon originu vs. edge.
Velikost odpovědi (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).
Status cache (HIT/MISS/BYPASS/STALE) – kolik servuje CDN vs. origin.
Referer – užitečné při odhalování interních smyček a redirect řetězců.

Bezpečnost a soulad: 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 podle 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ů k dotazovatelným datům

Ingest: S3/GCS jako „landing zone“, následně ETL do datového skladu (BigQuery/Snowflake/ClickHouse).
Parsing: definujte schéma polí; u JSON preferujte explicitní klíče před regexy.
Normalizace URL: lowercase cesty, odstranění trailing slash, setřídění parametrů, whitelist důležitých parametrů.
Klasifikace botů: tabulka známých UA + validace reverzním DNS a ASN; označte „suspect“ 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 vyžadujte PTR záznam končící na googlebot.com nebo google.com a následný A záznam zpět na stejnou IP.
ASN kontrola: porovnejte s danou autonomní sítí poskytovatele (např. AS15169 pro Google).
Heuristika chování: reální boti respektují robots.txt, nejsou agresivně paralelní a používají HEAD metodu.

Klíčové otázky, na které logy dávají odpověď

Které URL jsou skutečně crawlované a jak často (dle sekcí, hloubky a typu obsahu)?
Kde trá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ě přistupují na duplicity?
Jaký je skutečný dopad deployů na dostupnost a frekvenci crawlů?

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

Metrika	Popis	Proč záleží	Typický cíl
Crawl coverage	% indexovatelných URL, které bot navštívil alespoň jednou v období	Ukazuje nepokryté cluster a „siroty“	> 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 URL
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é ř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 hubách
Cache hit ratio	Podíl HIT z CDN na HTML a statických zdrojích	Snižuje tlak na origin a zlepšuje rychlost	> 80 % pro statické zdroje, selektivně pro HTML
Parametrická entropie	Počet unikátních kombinací query parametrů na cestu	Detekuje URL explozí a duplicity	Minimalizovat na whitelistované parametry

Analytické pohledy: od rychlých výher 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ě (deploy, nový obsah) boti znovu crawlují 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; upřednostňujte 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 databáze) – rychlejší TTFB = efektivnější crawl.
Opravte 404/5xx hotspoty dle sekcí; snížíte negativní signál spolehlivosti.
Omezte redirect hop-y na max. 1; po migraci konsolidujte na přímé 301.

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

Špičky zátěže dle hodin a geolokace – kapacitní plánování 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. request time – přesná lokalizace 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 správou evoluce schématu.

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 query, 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 hubách.

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

Top 100 nejčastěji crawlovaných URL a vývoj jejich statusu/TTFB.
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 žádá API, přehodnoťte server-side render (SSR) nebo hydratační strategii.
Pre-render/edge-side includes: z logů sledujte, zda HTML vzniká rychle a stabilně při mobile 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í trafficu.
Při migraci definované 1:1 mapování URL a monitoring řetězců 301.
Po deploy spuštěný „smoke test“: status mix, TTFB p95, 5xx alarmy.
Aktualizované kanonické značky 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 přehodnoceným číslům botů.
Nenormalizované URL – stejný zdroj v analýze figuruje jako více entit.
Zaměňování edge a origin časů – nesprávné závěry o výkonu aplikace.
Chybějící segmentace (mobile/desktop bot, typ stránky) – průměr skrývá problematické cluster.
Krátká retenční doba – nevidíte sezónnost 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 do wasted crawl, úklid redirectů, tunning cache-policy, monitoring p95 TTFB.
Dny 61–90: hluboká segmentace dle sekcí, audit SPA/SSR, 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 explozi, návrhy omezení filtrů.
Management: trendy dostupnosti, rizika migrací, dopad na organický výkon.

Shrnutí: logy jako zdroj pravdy

Log analýza odhaluje, 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 dopady změn. Kdo logy nečte, optimalizuje „naslepo“. Zaveďte disciplinovaný ingest, robustní normal