Analýza logů: čtení serverových logů pro získání SEO poznatků

Analýza logů: propojení serverových logů se SEO, AIO/AEO a optimalizací pro LLM

Analýza logů je systematické vyhodnocování „surových“ záznamů o návštěvách a požadavcích na server (HTTP(S) požadavky a odpovědi). V moderním SEO a AIO/AEO (Answer/AI Engine Optimization) představují logy nejpřesnější zdroj informací o tom, co prohledávač (Googlebot, Bingbot, jiní boti, crawleři LLM) skutečně viděl, jak často se k obsahu vrací, které soubory si vyžádal, jaké stavové kódy obdržel a jak rychle mu server odpověděl. Na rozdíl od analytiky měřené pomocí JavaScriptu (kterou boti obvykle nespouštějí) logy zachycují každý požadavek – včetně požadavků na zdroje a API i na chráněné či blokované cesty. Proto jsou klíčem k efektivnímu řízení crawl budgetu, diagnostice problémů s indexací a zlepšování kvality odpovědí generovaných systémy AI.

Co přesně je „serverový log“ a kde vzniká

• Webový server a reverzní proxy: Apache, Nginx, IIS nebo HAProxy/Envoy zaznamenávají příchozí HTTP požadavky ještě předtím, než dorazí do aplikace.
• Logy CDN/WAF edge: Cloudové hraniční uzly (CDN, WAF) obsahují dodatečná metadata (zásah/nezásah cache, geolokace, zmírňující opatření).
• Aplikační logy: frameworky (např. PHP/Nette, Node.js, Python) doplňují korelační ID, latenci, výjimky a interní přesměrování.
• Databázové/vyhledávací logy: pro SEO jsou relevantní méně často, ale hodí se ke korelaci výkonu.

Formáty a pole: co potřebujeme vidět pro SEO

Nejčastěji se setkáte s Common Log Format (CLF), Combined Log Format (přidává referrer, user-agent) a stále častěji s logy ve formátu JSON. Klíčová pole pro SEO:

• Čas (časové razítko, časové pásmo) – nezbytný pro frekvenci procházení a četnost opětovných návštěv crawlerů.
• Metoda (GET, HEAD) – požadavky HEAD od botů jsou běžné při ověřování.
• URL (cesta + dotazovací řetězec) – včetně parametrů; umožňuje identifikovat nekonečné prostory a duplicity.
• Stavový kód (2xx, 3xx, 4xx, 5xx) – ukazuje technický stav a signály pro indexaci.
• Velikost odpovědi v bajtech (response bytes) – může naznačovat „soft 404“ nebo chyby blokující vykreslování.
• Latence/TTFB – rychlost odpovědi pro boty a uživatele.
• Referrer – odkazy z webu, SERP nebo žádný referrer (u botů často „-“).
• User-Agent – klíč k identifikaci botů (a podvržení jejich identity).
• Edge pole (např. cache_status, tls_version, http_version) – souvisí s výkonem a dostupností.

Identifikace botů: víc než jen User-Agent

Samotný User-Agent lze snadno podvrhnout. Před zásadními rozhodnutími (např. úpravou rychlosti procházení) vždy ověřte reverzní DNS IP adresy a proveďte validaci pomocí dopředného DNS pro oficiální rozsahy (tzv. „double DNS check“). Vytvořte si kategorie:

• Googlebot (smartphone/desktop, obrázky, AdsBot) – zásadní pro indexaci.
• Bingbot, Applebot, Yandex/Semrush/MJ12 a další – důležití podle trhu.
• Procházení LLM/AI – nové kategorie botů shromažďujících data pro odpovědi AI; zvažte pravidla a přínos jejich procházení.
• Neznámí/škodliví – omezení rychlosti, seznam blokovaných adres, monitorování honeypotů.

Crawl budget: jak ho měřit a řídit pomocí logů

• Rozložení požadavků podle hloubky URL (např. počet lomítek nebo interní metrika „depth“) – nadměrné procházení hlubokých, nepodstatných stránek je signálem k úpravě navigace, souboru robots.txt nebo zpracování parametrů.
• Frekvence opětovného procházení (medián/průměr počtu dní mezi požadavky) – u hlavních stránek by měl být interval kratší.
• Podíl odpovědí 2xx vůči 3xx/4xx/5xx u botů – chybové kódy vyčerpávají budget a zpomalují indexaci.
• Požadavky botů na statické zdroje (CSS/JS) – odpovědi 4xx/403 zde často znamenají neúplné vykreslení a nedostatečné pochopení obsahu.

Diagnostika problémů s indexací pomocí logů

• Osamocené stránky: URL s požadavky botů, které chybějí v interním prolinkování nebo navigaci – často se vyskytují pouze v sitemapě nebo v externích odkazech.
• Zombie stránky: nízká návštěvnost uživatelů, vysoká aktivita crawlerů – kandidáti na konsolidaci/kanonikalizaci.
• Soft 404: opakované odpovědi 200 s velmi malým počtem bajtů nebo jednotnou „prázdnou“ šablonou – bot plýtvá budgetem bez užitku.
• Řetězce přesměrování a smyčky: několik po sobě jdoucích odpovědí 3xx – zbytečná latence a riziko ztráty signálu.
• Nesoulad pravidel robots.txt se skutečností: bot opakovaně zkouší zakázané cesty (4xx/403) – zvažte, proč jsou pro něj atraktivní.
• Anomálie v canonical/hreflang: pokud bot často navštěvuje varianty s parametry, kanonikalizace nemusí být respektována nebo se uplatňuje až po vykreslení.

Pracovní postup: od sběru k poznatkům

1. Sběr: zajistěte přístup ke všem relevantním logům (edge + origin), včetně noční rotace a komprese (gzip).
2. Normalizace: sjednoťte časová pásma (upřednostněte UTC), formát URL (velikost písmen, koncové lomítko), rozbalte gzip, deduplikujte podle ID požadavku a ošetřete chybějící pole.
3. Obohacení: přidejte interní metadata (typ stránky, kategorie, šablona, zahrnutí do sitemapy, počet interních odkazů, priorita).
4. Uložení: sloupcové datové úložiště (např. BigQuery/ClickHouse/Redshift) pro levné prohledávání, nebo ELK stack pro rychlé ad hoc dotazy.
5. Analýza: připravte standardní dotazy a dashboardy (viz níže).
6. Akce: navrhněte změny (navigace, interní odkazy, robots, změna uspořádání sitemapy, konsolidace parametrů, zásady cachování) a poté měřte jejich dopad.

Standardní dotazy (pseudokód) pro SEO týmy

• Nejčastěji navštěvované stránky s odpovědí 404 při procházení Googlebotem (posledních 30 dní): SELECT url, COUNT(*) AS hits FROM logs WHERE bot='googlebot' AND status BETWEEN 400 AND 499 AND ts >= NOW()-30d GROUP BY url ORDER BY hits DESC
• Stránky bez požadavků botů: SELECT url FROM sitemap LEFT JOIN (SELECT DISTINCT url FROM logs WHERE bot) USING(url) WHERE logs.url IS NULL
• Řetězce přesměrování: SELECT req_id, ARRAY_AGG(CONCAT(status,'→',location)) FROM logs WHERE status BETWEEN 300 AND 399 GROUP BY req_id HAVING COUNT(*) > 1
• Kandidáti na soft 404: SELECT url FROM logs WHERE status=200 GROUP BY url HAVING AVG(bytes) <= 2k AND COUNT(*) >= 10
• Interval opětovného procházení: SELECT url, PERCENTILE_DIFF('day', LAG(ts) OVER(PARTITION BY url ORDER BY ts), ts) AS p50 FROM logs WHERE bot
• Zdroje blokující vykreslování: SELECT resource_url FROM logs WHERE bot AND resource_type IN ('css','js') AND status IN (403,404,5xx)

Metodika měření: KPI a prahové hodnoty

Praktické využití v AIO/AEO a pro LLM

• Odpovědi asistentů: logy odhalí, zda boti LLM získávají přístup ke strukturovaným datům (FAQ/HowTo/JSON-LD) a statickým prostředkům potřebným k pochopení rozvržení a jazykové verze.
• Kontrola pravidel robots: zakázáním kritických cest (např. /cdn/, /api/content) riskujete, že systémy AI neporozumějí obsahu v plném rozsahu.
• Verzování obsahu: sledujte, zda se po aktualizaci zrychlilo opětovné procházení (důkaz, že změny byly „zaznamenány“).

Parametry a nekonečné prostory

Parametry typu ?sort=, ?page=, ?utm= nebo nekonečné generátory URL (kombinace filtrů) jsou častým zdrojem plýtvání crawl budgetem. Z logů zjistíte:

• Které parametry bot navštěvuje nejčastěji a s jakými kódy.
• Zda parametry vedou na kanonické, indexovatelné verze.
• Zda je potřeba nastavit zpracování parametrů, prolinkování nebo blokování vybraných parametrů.

Mobilní a desktopoví boti a vykreslování

Indexace mobile-first znamená, že rozhodující je smartphone bot. Porovnávejte stejné URL u mobilního a desktopového bota: rozdíly v odpovědích 4xx/403 u CSS/JS/fontů odhalí, proč není obsah správně rozpoznán nebo je považován za „obsah s nízkou hodnotou“. Sledujte také využití HTTP/2/3 a prioritu zdrojů, které mohou zlepšit latenci.

Propojení logů s interní mapou webu

• Rozdíly v sitemapě: URL v sitemapě bez požadavků botů = kandidát na doplnění interních odkazů nebo kontrolu signálů indexace.
• Interní odkazy: porovnejte počet interních odkazů s frekvencí požadavků botů – nízká síla odkazů často znamená méně časté opětovné procházení.
• Kategorie/šablony: skupinová analýza podle typů stránek odhalí problematické sekce (např. archivy, parametry, duplicitní štítky).

Edge a CDN: cache a dostupnost pro boty

• Poměr zásahů cache: vysoký poměr zásahů u opakovaně procházených zdrojů (CSS/JS) šetří TTFB a kapacitu originu.
• Zmírňující opatření proti HTTP 429/5xx: při agresivním zásahu WAF může bot dostat odpověď 403/429 – zbytečně tak přijdete o procházení.
• Geografické rozložení a PoP: vysoká latence z vybraných lokalit může ovlivnit hodnocení rychlosti.

Bezpečnost, soukromí a compliance

• Anonymizace IP: při dlouhodobém uchovávání uživatelských logů dodržujte GDPR (maskování, zkracování IP).
• Zásady uchovávání: uchovávejte je jen po nezbytně dlouhou dobu; pro SEO často stačí 90–180 dní podrobných údajů a souhrnné statistiky.
• Princip nejmenších oprávnění: k surovým logům mají přístup pouze pověřené osoby; u exportů veďte auditní stopu.

Nástroje a technický stack

• Rychlá explorace: grep/awk, GoAccess pro základní přehledy.
• Vizualizace a ad hoc dotazy: ELK stack (Elasticsearch, Logstash, Kibana), Grafana.
• Big data/SQL: BigQuery, Snowflake, ClickHouse pro levné agregace na terabajtech dat.
• Programová analýza: Python/R pro statistiky a detekci problémů (soft 404, řetězce přesměrování, intervaly opětovného procházení).

Časté chyby při analýze logů pro SEO

1. Nesoulad časových pásem: kombinování UTC a místního času vede k mylným závěrům o sezónních trendech.
2. Vzorkování: analýza na vzorku bez rovnoměrného rozložení zkresluje frekvenci opětovného procházení.
3. Ignorování logů CDN: mnoho požadavků se na origin nikdy nedostane; chybí vám polovina obrazu.
4. Neověřená identita botů: spoléhání se pouze na User-Agent.
5. Normalizace URL: rozdíly v koncovém lomítku, velikosti písmen či kódování vedou k duplicitám.
6. Běžné omyly: zapomenutá interní přesměrování 301/302 po migraci, která celé měsíce plýtvají crawl budgetem.

Migrace a logy: jak snížit riziko

• Před spuštěním: nasimulujte procházení (staging) a připravte mapu starých → nových URL; otestujte přesměrování.
• Po spuštění: denně kontrolujte odpovědi 404 a délku řetězců 3xx; sledujte rychlost opětovného procházení klíčových sekcí.
• Sitemapy: průběžně je aktualizujte a rozdělte podle sekcí pro lepší sledování.

„Mini“ případové scénáře a akční kroky

• Bot tráví 40 % času na stránkách /filter/ → upravit interní prolinkování, nastavit kanonickou URL, zvážit zákaz vybraných parametrů, změnit uspořádání sitemapy.
• Nárůst odpovědí 5xx u statických zdrojů → prodloužit TTL cache na edge, rozložit provoz, opravit generování prostředků.
• Vysoký podíl odpovědí 302 → nahradit trvalými přesměrováními 301, zkrátit řetězce a aktualizovat interní odkazy tak, aby směřovaly na konečné URL.
• Smartphone bot dostává odpověď 403 na /assets/ → povolit Googlebotu přístup ke statickým souborům, zkontrolovat pravidla WAF.

Reporting: co by měl vidět stakeholder

• Trend bot 2xx%, počet 404, TTFB (p50/p95) a interval opětovného procházení pro hlavní sekce.
• Nejproblematičtější URL (404/soft 404/řetězce přesměrování) s přiřazenou prioritou a doporučeným řešením.
• Mapa procházení vs. indexace (pokud máte data z konzolí) a prolinkování.

Shrnutí

Analýza logů je zásadním nástrojem pro SEO, AIO/AEO a optimalizaci pro LLM: odhaluje, co se na webu skutečně děje z pohledu crawlerů. Správným sběrem, normalizací a analýzou logů můžete řídit crawl budget, omezovat chyby, zkracovat přesměrování, odhalovat osamocené/zombie stránky a urychlovat opětovné procházení po změnách. Přímo tak zvyšujete spolehlivost indexace, kvalitu odpovědí v asistentech AI a celkovou organickou viditelnost.