Log file analysis dla SEO — tutorial

Log file analysis dla SEO to jedyna metoda, która pokazuje co faktycznie robi Googlebot na Twojej stronie — nie co powinien, nie co deklaruje Search Console, ale realny strumień requestów zapisany przez serwer. Bez logów marketer SEO pracuje na domniemaniach; z logami podejmuje decyzje oparte na faktach.

Ten tutorial prowadzi krok po kroku przez proces analizy logów: od zebrania plików, przez narzędzia, aż po praktyczne wnioski. W polskich projektach e-commerce log analysis odpala się 2–4 razy w roku – przy audycie, po migracji, przy problemach z crawl budżet. Szerszy kontekst w przewodniku SEO 2026.

Po co robić log file analysis

Search Console pokazuje zagregowane metryki — ile requestów dziennie, średni response time, breakdown po typach. Nie pokazuje, które konkretne URL-e Googlebot odwiedza, jak często, kiedy i w jakiej kolejności. Log analysis daje dokładnie to — więcej w artykule SEO 2026 – przewodnik.

Pytania, na które odpowiada log analysis

• Które URL-e Googlebot odwiedza najczęściej? Czy to ważne strony?
• Które URL-e z sitemap Googlebot pomija?
• Ile % crawl budżet pochłaniają parameter URLs?
• Jak szybko Googlebot odwiedza nowe strony po publikacji?
• Czy serwer odpowiada szybko na requesty Googlebota?
• Ile 5xx / 404 widzi Googlebot?
• Czy AI crawlery (GPTBot, ClaudeBot) zajmują znaczną część bandwidth?
• Jak Googlebot zachowuje się po migracji domeny / redesignie?

Kiedy warto odpalić pełną analizę

1. Rutyna: co 6 miesięcy dla e-commerce 50 000+ URL-i.
2. Po migracji domeny lub CMS — sprawdzenie, czy Google przeadaptował strukturę.
3. Gdy Search Console pokazuje spadek crawl requestów > 30%.
4. Gdy nowe strony indeksują się > 72h.
5. Przy audycie SEO – jako core komponent.
6. Po update algorytmu Google – sprawdzenie zmian w priorytetach crawla.

Zbieranie logów — gdzie je znaleźć

Apache

• Lokalizacja: /var/log/apache2/access.log lub /var/log/httpd/access_log.
• Format: Combined Log Format – IP, time, method, URL, status, size, referrer, user-agent.
• Rotacja: zwykle daily z logrotate; stare pliki gzipped.
• Wymagany dostęp SSH lub panel admina z log viewer.

Nginx

• Lokalizacja: /var/log/nginx/access.log.
• Format: Main (IP, time, request, status, body_bytes, referrer, user_agent, upstream).
• Konfigurowalny w nginx.conf – log_format directive.
• Zalecane dodanie request_time dla analizy wydajności.

Cloudflare / CDN

• Cloudflare Logs (wymaga Enterprise plan dla raw logs).
• Cloudflare Logpush – eksport do S3 / GCS / Azure.
• AWS CloudFront – S3 bucket logs.
• Fastly – Logging Endpoints do S3 / Syslog.

WordPress + hosting managed

• Większość hostów (OVH, cyber_Folks, home.pl) udostępnia logi przez panel lub FTP.
• WP Engine, Kinsta – dedykowany log viewer w panelu.
• Niektóre plugins (Redirection, Wordfence) też zapisują access logs.
• Jeśli brak dostępu – poproś hostingowego supportu o dostęp do raw logs.

Weryfikacja Googlebota – reverse DNS

40–60% requestów deklarujących user-agent „Googlebot” to fałszywy ruch (scrapers, competitive intelligence tools, security scanners). Każdy realny request z Googlebota musi przejść reverse DNS test.

Proces weryfikacji

1. Weź IP z logów.
2. Reverse DNS (host IP lub dig -x IP) – wynik powinien kończyć się na .googlebot.com lub .google.com.
3. Forward DNS (host nazwa_hosta) – wynik musi zwracać oryginalny IP.
4. Tylko przy zgodności obu DNS to realny Googlebot.

Automatyzacja weryfikacji

Narzędzie	Auto weryfikacja
Screaming Frog Log Analyzer	Tak (built-in)
JetOctopus	Tak
Oncrawl Log Analyzer	Tak
Botify	Tak
Python + IP range	Ręczne z publicznej listy IP Google

Lista user-agentów Google 2026

• Googlebot (desktop): „Mozilla/5.0 … Googlebot/2.1 …”.
• Googlebot Smartphone: „Mozilla/5.0 (Linux; Android 6.0.1 …) Googlebot/2.1”.
• Googlebot Image, Video, News – oddzielne UA.
• Google-InspectionTool – używany przez URL Inspection i Test Live URL.
• Google-Site-Verification – weryfikacja własności.

Narzędzia do analizy logów

Screaming Frog Log File Analyzer

• Cena: ~150 EUR / rok (free do 1 000 linii).
• Desktop app (Windows / Mac / Linux).
• Importuje Apache / Nginx / IIS logs.
• Wizualizacja: requests per day, status codes, URL frequency, user-agents.
• Integracja: eksport do CSV, join z crawl data ze Screaming Frog SEO Spider.
• Świetny dla średnich projektów (do 10M linii logów).

JetOctopus

• Cena: od ~100 USD / mies.
• Cloud-based, real-time monitoring.
• Dedykowane SEO analytics na logach.
• Alerty na zmiany w zachowaniu Googlebota.
• Dobrze skaluje do ogromnych serwisów.

Oncrawl

• Cena: od ~150 EUR / mies.
• Łączy crawl i log data w jednym miejscu.
• Zaawansowane raporty (orphaned pages, crawl waste, category analysis).
• Integracja z GA4 i Search Console.

Botify

• Enterprise tool, cena indywidualna (~1 500 USD+ / mies.).
• Dla dużych serwisów (marketplace, media, enterprise).
• ML-based recommendations.
• Dedicated customer success team.

Python + pandas (DIY)

• Koszt: 0 PLN.
• Pełna kontrola, ale wymaga programowania.
• Dla projektów niestandardowych lub jednorazowych analiz.
• Librarie: pandas, regex, requests (dla reverse DNS).

Proces analizy — krok po kroku

Krok 1: zebranie logów

1. Pobierz logi serwera za ostatnie 30 dni (lub 90 dla pełnej analizy).
2. Sprawdź format (Combined, Common, custom) — większość narzędzi wspiera Combined.
3. Kompresuj gzip, jeśli pliki > 1 GB.
4. Upload do narzędzia (Screaming Frog, JetOctopus).

Krok 2: weryfikacja Googlebota

1. Włącz auto-verification przez reverse DNS w narzędziu.
2. Odrzuć fake Googlebots (zwykle 40–60% claimed requests).
3. Zapisz listę confirmed Googlebot IPs do future reference.

Krok 3: analiza agregatów

• Requests per day – trend rosnący / spadający.
• Status codes breakdown — % 200, 301, 302, 404, 410, 5xx.
• Average response time – < 500 ms = ok.
• Top 100 URLs by Googlebot frequency.
• Bottom 100 URLs with zero visits from Googlebot (orphaned in sitemap).

Krok 4: pogłębiona analiza w problematyczne obszary

1. Jeśli 5xx > 1% – alarm; sprawdź timing i URL patterns.
2. Jeśli 404 > 5% — sprawdź, czy są intentional (deleted content) czy broken (misconfigured links).
3. Jeśli parameter URLs > 30% crawl budżet – robots.txt fix urgent.
4. Jeśli response time > 1 s — performance audit.
5. Jeśli ważne URL-e z sitemap nie są w logach – internal linking problem.

Krok 5: reporting i rekomendacje

• Executive summary: 3–5 najważniejszych findingów.
• Prioritized recommendations: high / medium / low impact.
• Szacunkowy impact: ile extra stron scrawlowanych / mies. po fix.
• Plan wdrożenia: co, kiedy, kto.

Kluczowe metryki w log analysis

Crawl frequency per URL

Typ strony	Normalna częstotliwość
Homepage	1–5× dziennie
Top kategorie	2–10× tygodniowo
Strony produktowe (aktywne)	1–4× miesięcznie
Blog posts (świeże)	1–3× tygodniowo pierwszy miesiąc
Blog posts (> 12 mies)	1–2× na 2 miesiące
Zduplikowane / thin content	0–1× na 3 miesiące

Crawl waste ratio

• Crawl waste = requests do URL-i, które nie chcesz indeksować.
• Kalkulacja: waste_requests / total_googlebot_requests × 100%.
• Healthy: < 15%.
• Problem: 15–40%.
• Krytyczne: > 40% – natychmiastowa optymalizacja.

Coverage gap

• Coverage gap = URL-e w sitemap, których Googlebot nie odwiedził w 30 dni.
• Kalkulacja: uncrawled_sitemap_urls / total_sitemap_urls × 100%.
• Healthy: < 5%.
• Problem: 5–25%.
• Krytyczne: > 25% — internal linking issue lub quality filter.

Time to first crawl

• Od publikacji do pierwszego request Googlebota.
• Dla ugruntowanych serwisów: 1–24h.
• Dla niszowych domen: 3–14 dni.
• Trend > 48h rośnie – sygnał problemu.

Case study – analiza logów e-commerce 300 000 URL-i

Sklep modowy z 300 000 URL-i (produkty, kategorie, filtracje, blog). Budżet SEO 25 000 PLN / mies. Problem: nowe produkty indeksują się 5–10 dni zamiast 24h.

Zbieranie danych

• 90 dni logów z Nginx (4,2 GB gzipped).
• Narzędzie: JetOctopus + Screaming Frog Log File Analyzer dla spot checks.
• Verified Googlebot requests: 62% claimed UA (38% fake).

Kluczowe findings

1. 42% crawl budżet szło na parameter URLs (filtracje) – Google tracił czas.
2. 18% na search results pages (site.com/szukaj?q=…).
3. Średni response time dla Googlebot: 680 ms (za wolno).
4. Ważne kategorie crawlowane 2× / tydzień (oczekiwane 5–10×).
5. 20 000 URL-i z sitemap nie crawlowane w 90 dni (orphaned lub quality).

Wdrożone zmiany

1. Robots.txt: Disallow: /*?color=, Disallow: /*?size=, Disallow: /szukaj/.
2. Noindex na paginacji > page=10 dla kategorii.
3. Optymalizacja response time: dodano redis cache, CDN dla static assets → 280 ms avg.
4. Internal linking: dodano breadcrumbs na wszystkie produkty, related products widget.
5. Sitemap split: /sitemap-products.xml, /sitemap-categories.xml, /sitemap-blog.xml.

Wyniki po 60 dniach

• Crawl waste: 60% → 18%.
• Ważne kategorie crawlowane 8× / tydzień (poprawa 4×).
• Nowe produkty indexed w 18h średnio.
• Orphaned pages z sitemap: 20 000 → 3 000.
• Response time: 280 ms (stabilny).

Typowe błędy w log analysis

Błędy techniczne

• Brak weryfikacji reverse DNS — analizuje się fake Googlebots razem z realnymi.
• Za mało logów (7 dni zamiast 30+) – dane niestabilne.
• Ignorowanie mobile Googlebot vs. desktop — różnice w zachowaniu.
• Brak timezone normalization – logi w UTC, raport w local time.

Błędy interpretacyjne

• „Googlebot mało crawluje = mam problem” – może crawluje tyle, ile potrzeba.
• „Dużo 404 = problem” — 404 dla usuniętych stron jest ok.
• „Parameter URLs zasypują logi = SEO killer” – jeśli są w robots.txt Disallow, Google też widzi Disallow i nie powinien, ale czasami widzi z zewnętrznych linków.
• „Response time 500 ms to ok” – nie dla dużego serwisu; celuj w < 200 ms.

Błędy procesowe

• Jednorazowa analiza bez follow-up — problem wraca po 3 miesiącach.
• Analiza w izolacji od Search Console i crawl data.
• Brak ownera findingów — raport ląduje w szufladzie.
• Nie dzielenie po segmentach (produkty vs. kategorie vs. blog) – agregat ukrywa problemy.

AI crawlery w logach – co z nimi robić

W 2026 AI crawlery generują 15–35% ruchu botów na polskich sklepach. GPTBot, ClaudeBot, PerplexityBot, CCBot, Bytespider (TikTok), Applebot-Extended. Każdy z nich ma inne intencje i różny wpływ na infrastrukturę.

Trzy strategie obsługi AI crawlerów

1. Pełne zezwolenie – wszystkie AI crawlery dostają dostęp. Maksymalna widoczność w AIO (ChatGPT, Perplexity, Claude), ale zjada bandwidth.
2. Selektywne zezwolenie – GPTBot, ClaudeBot, PerplexityBot tak; CCBot, Bytespider nie. Balans między visibility a ochroną infra.
3. Pełna blokada – robots.txt Disallow dla wszystkich AI bots. Stracisz AIO widoczność, oszczędzisz bandwidth. Nie rekomendowane dla nowoczesnego marketingu.

Rate limiting per user-agent (Nginx example)

Dla ochrony infra bez totalnej blokady: Nginx limit_req_zone per user-agent pozwala zadać max requests / sec dla konkretnych botów. AI crawlery dostają 2 req/s (wystarczająco żeby scrapować, za mało żeby zatopić serwer), Googlebot bez limitu.

FAQ – najczęstsze pytania o log file analysis

Ile logów potrzeba do sensownej analizy?

Minimum 30 dni, ideał 90 dni. 30 dni wyłapuje typowe wzorce crawla i problem, 90 dni pokazuje sezonowość i wpływ update’ów algorytmu. Dla e-commerce > 100 000 URL-i zalecane 180 dni – pozwala wyłapać kategorie crawlowane raz na kwartał. Pod względem rozmiaru: typowy polski sklep generuje 2–10 GB logów za 90 dni po gzipowaniu. Narzędzia (Screaming Frog, JetOctopus) przyjmują skompresowane pliki bez problemu.

Czy analiza logów wymaga programisty?

Nie, jeśli używasz narzędzi (Screaming Frog Log Analyzer, JetOctopus, Oncrawl). Wymaga programisty, jeśli robisz DIY w Python / awk / grep. Rekomendacja dla in-house SEO: Screaming Frog Log Analyzer (150 EUR / rok) wystarczy dla 90% przypadki użycia. Dla in-house w enterprise: JetOctopus ze wsparciem real-time monitoring. DIY w Pythonie ma sens dla jednorazowych analiz specyficznych pytań (np. „jak rozkład crawla zmienił się przed i po migracji”).

Jak często warto powtarzać log analysis?

Dla stabilnego serwisu: co 6 miesięcy jako rutyna + doraźnie przy problemach. Dla dużych e-commerce z częstymi zmianami: co 3 miesiące. Dla serwisów news / content-heavy z dziesiątkami publikacji dziennie: continuous monitoring (JetOctopus alerts). Kluczowe momenty: po migracji, po redesignie, po update algorytmu Google. Po każdej z tych zmian nowa analiza w ciągu 30 dni pokazuje, jak Google zaadaptował się do nowej struktury.

Jakie są najczęstsze findings z log analysis?

Pięć top issues w polskich projektach Q1 2026: (1) parameter URLs zjadają 30–50% crawl budżet; (2) search / filter pages nie w robots.txt; (3) response time Googlebot > 500 ms; (4) orphaned sitemap URLs (submitted ale bez internal links); (5) AI crawlery generują 20–30% bandwidth bez ROI. Każdy z tych findingów rozwiązuje się w 1–5 dni pracy technicznej; łączny impact: 30–60% więcej relevant crawl na ważnych stronach.

Czy fake Googlebots są szkodliwe?

Same w sobie nie wpływają na SEO – Google ich nie widzi, ich logi nie idą do Search Console. Ale są problemem z innych powodów: (1) zużywają bandwidth serwera; (2) scrapują treść (konkurencja lub AI training); (3) zaburzają statystyki jeśli nie są filtrowane w GA4 / adobe; (4) część z nich to spamerzy lub vulnerability scanners. Rekomendacja: rate limiting per UA lub blokada na poziomie firewalla / Cloudflare dla confirmed bad actors. W analizie logów zawsze verify reverse DNS.

Czy Cloudflare ukrywa logi przed log analysis?

Cloudflare domyślnie dostarcza aggregated stats, nie raw logs. Raw logs są dostępne w Enterprise plan ($200+/mies.) przez Cloudflare Logpush → S3/GCS/Splunk. Alternatywa dla tańszych planów: Cloudflare Workers, które zapisują subset requests do KV / R2 storage. Dla typowego polskiego e-commerce: albo przejście na Enterprise (zbyt drogie), albo przeniesienie logowania na origin server (Nginx loguje to, co dostaje po Cloudflare). Drugi wariant jest standardowy i działa – Cloudflare przepuszcza requesty do origin, origin loguje normalnie.

Czy warto monitorować logi real-time?

Dla serwisów z dużym ruchem (100 000+ pageviews / dzień) i krytycznym SEO — tak. Real-time alerting wyłapie spike 5xx w 5 minut zamiast 24h. Narzędzia: JetOctopus, Datadog z custom SEO dashboards, New Relic APM. Koszt: 200–2 000 USD / mies. Dla średnich projektów (< 50 000 pageviews / dzień) nightly batch analysis wystarczy – alerty na anomalie w porannym raporcie. Dla małych projektów comiesięczna manualna analiza robocza.

Budżet log file analysis – SME vs enterprise

Log analysis skaluje się ze skalą serwisu. Trzy poziomy inwestycji.

SME (< 50k URL)

• Narzędzie: Screaming Frog Log File Analyser (99 GBP/rok).
• Czas: 2–4h/mies. manualnej analizy.
• Osoba: Technical SEO (wewnętrzna lub freelance).
• Koszt roczny total: 5–15 tys. PLN.
• ROI: typowo znajduje 3–5 fixów wartych 20–80 tys. PLN/rok.

Mid-market (50k–1 mln URL)

• Narzędzie: Semrush Log Analyzer lub JetOctopus (300–1 200 USD/mies.).
• Czas: 8–16h/mies., częściowo automated.
• Osoba: dedicated Technical SEO 0,3 FTE.
• Koszt roczny: 60–150 tys. PLN.
• ROI: 3–8× przy dobrze ustawionych KPI.

Enterprise (1 mln+ URL)

• Narzędzie: Botify lub custom ELK stack.
• Real-time monitoring, alerting, dashboards.
• Team: 2–3 FTE (Technical SEO + Data Engineer + SRE support).
• Koszt roczny: 400 tys.–1,5 mln PLN.
• ROI: trudno liczony, ale dla site z przychód 50+ mln PLN/rok – krytyczny.

Quick wins w pierwszym audycie

• Export 30 dni logów dla Googlebot, filter top 100 crawled URLs.
• Porównaj z listą top 100 traffic z GA4 – zauważysz mismatch w 15–30%.
• Sprawdź top 50 4xx/5xx errors – najczęściej łatwe fixy do 80% impact.
• Zweryfikuj, czy ważne kategorie (product, service pages) mają min. 1 crawl/tydz.
• Oczyść logi z fake Googlebot – spoofed user-agent, wymagają reverse DNS lookup.

Typowe oszczędności roczne

• Fix redirect chains: oszczędność 5–15% crawl budżet, equivalence 10–40 tys. PLN traffic gain.
• Fix 5xx: immediate ranking recovery 5–25% na affected URLs.
• Robots.txt cleanup (unnecessary allow/disallow): crawl budżet redirection do przychód URLs.
• Fix canonical issues: eliminacja duplicate crawling, 10–20% oszczędności budżet.

Compliance i retencja logów

• RODO – adresy IP to PII, logi z IP wymagają retencji zgodnej z polityką.
• Typowe retention: 30 dni dla surowych logów, 1 rok dla agregatów bez IP.
• Anonimizacja IP przed długotrwałym storage (hashing ostatniego octetu).
• Uzasadnienie biznesowe: security audit, SEO analysis, debugging.
• Audit log dostępu do logów (kto pobiera, kiedy, po co).

Narzędziowe rozszerzenia do analizy

• GeoIP enrichment (MaxMind GeoLite2) — pokazuje regiony, z których przychodzi crawling.
• DNS reverse lookup dla weryfikacji Googlebot vs spoof.
• URL categorization (product, category, blog, static) dla segmentowej analizy.
• Bot classification (known SEO tools: Ahrefs, Semrush, Sistrix) – osobna kategoria do wykluczenia z crawl budżet analysis.
• JavaScript rendering confirmation – sprawdź, czy Googlebot Smartphone faktycznie renderuje JS i co z tego widzi.
• Mobile-first index verification – czy większość crawl trafia na mobile user-agent.
• Correlation z deployment events — czy spike 5xx zbiegał się z deployem (root cause analysis).
• Caching analysis – jaki procent requestów od Googlebota trafia na cache, a ile do origin (cel: > 80%).
• TLS/HTTP version audit – czy Googlebot crawluje przez HTTP/2 i TLS 1.3 (lepsza wydajność crawl).
• Mobile-friendly re-check dla URL crawlowanych często – czy wersje mobile rendują się w pełni.
• AMP usage audit – czy Googlebot dalej crawluje AMP, czy wyłącznie kanoniczne HTML.

KPI log analysis – co mierzyć

Analiza logów to nie tylko „co znaleźliśmy”, ale continuous monitoring. Cztery osie metryk:

Crawl metrics

• Crawl frequency per URL category (product, category, blog, home).
• Crawl ratio – % total crawls przypisanych do important URLs.
• Deep crawl ratio — ile % crawl dociera do URL-i głębszych niż 3 kliknięcia.
• AI bot crawl share — jaki % total crawl to Googlebot vs AI bots vs inne.

Health metrics

• 5xx rate – cel < 0,5%.
• 4xx rate (excluding 404) – cel < 0,3%.
• 404 rate – cel < 1% dla legacy URL-i, 0% dla aktywnych.
• Response time p95 dla Googlebot — cel < 2s.

Coverage metrics

• % important URLs crawled last 30 days.
• % new URLs crawled within 7 days.
• Orphaned URLs — crawled, ale bez internal links.
• Uncrawled in sitemap – URL w sitemapie, ale nigdy crawled.

Business correlation

• Przychód pages crawl correlation — czy crawl rate koreluje z biznes value.
• Seasonal patterns – peak commerce vs peak crawl.
• New content TTI (time to index) – ile czasu od publikacji do pierwszego crawl.

Typowe wzorce problemów w logach – co szukać

20 najczęstszych wzorców, które wyłapują log analysis, uporządkowane od największego impactu.

Problemy z crawl budżet

• Infinite crawl spaces – faceted search generujące setki tysięcy combinations.
• Session ID w URL — każda wizyta = nowy URL, Googlebot crawluje duplikaty.
• Paginacja bez ograniczenia – blog archives z 500 stron paginacji.
• Kalendarz eventów — każdy dzień/miesiąc jako oddzielny URL.
• Tag cloud overuse – 10 000 tags z pojedynczymi postami.

Problemy z response codes

• 5xx spikes — overloaded backend, DB issues, memory leaks.
• Soft 404 – strona zwraca 200 z „Brak wyników”, Google traktuje jako 404.
• Redirect chains – wielokrotne hop’y zjadają crawl budżet.
• Mixed HTTPS/HTTP – Google crawluje oba, 2x budżet.
• www vs non-www – jeden z nich 301, ale inconsistent.

Problemy z indexowalnością

• Crawled, not indexed – Google uznaje za low quality.
• Discovered, not crawled — Google znalazł URL, ale w kolejce od dawna.
• Orphaned pages – indexed, ale brak internal links.
• Zombie URLs – stare URL ciągle crawled, mimo że nie są w sitemapie.

Problemy z content

• Thin content pages crawled often – marnotrawstwo budgetu.
• Thick content crawled rarely — Google nie docenia.
• Duplicate content — canonicals nieobserwowane, crawl obu.
• Translated content crawled as English – hreflang issues.

Problemy z AI crawlers

• GPTBot crawls everything — niekontrolowane, może zawiesić serwer.
• AI crawlers blocked in error — robots.txt default blokuje, tracisz AI visibility.
• Asymmetry – Googlebot crawluje dużo, AI bots nie w ogóle, albo odwrotnie.

Narzędzia log file analysis — porównanie 2026

Wybór narzędzia zależy od skali i budżetu. Trzy poziomy dojrzałości.

Budżet tier – Screaming Frog Log File Analyser

• Koszt: 99 GBP/rok.
• Max size: 10 mln lines/project.
• Zalety: dobra UI, import bezpośrednio z apache/nginx, link do main Screaming Frog.
• Wady: desktop only, brak real-time, trudny share z teamem.
• Idealny dla: SME, agencje 1–5 projektów, solo consultant.

Mid tier – Semrush Log Analyzer, SEO Log File Analyser

• Koszt: 119–300 USD/mies. (w ramach planu Semrush).
• Cloud-based, multi-team access.
• Integracja z innymi modułami Semrush.
• Dashboards, historical comparisons.

Enterprise — JetOctopus, Lumar, Botify

• JetOctopus: 200–3000 USD/mies., specialized in log + crawl correlation.
• Lumar (ex-DeepCrawl): 500–5000 USD/mies., enterprise features.
• Botify: 2000–10000+ USD/mies., Fortune 500 SEO platform.
• Zalety: real-time ingest, custom dashboards, API, alerting.
• Wady: ceny, wymaga dedykowanego teamu.

DIY z ELK stack

• Elasticsearch + Logstash + Kibana, self-hosted.
• Koszt: infrastruktura od 200 USD/mies., większość pracy to setup.
• Dla teamów z engineering capability, custom dashboards.
• Kombinacja: logi SEO w tym samym stack co logi app/ops.

Integracje – logi + GSC + GA4

Izolowana analiza logów daje 40% wartości. Pełen obraz powstaje, gdy łączysz logi z innymi źródłami danych.

Log + GSC Coverage

• URL z dużo crawl, ale z GSC „Crawled – currently not indexed” – sygnał problemu z quality.
• URL indeksowane, ale rzadko crawlowane — potencjał na traffic boost.
• URL z 404 w logach, których nie ma w GSC Coverage – ukryte problemy ze old URLs.

Log + GA4

• URL z crawl priority high, ale zero GA4 sessions – content orphan.
• URL z GA4 traffic, ale crawl rare – Google nie nadąża za zaangażowanie.
• URL z spike crawl + GA4 drop – sygnał algorithmic shift.

Log + business data

• Product pages high-przychód crawl rate vs low-przychód – czy Google prioritizuje rentowne strony.
• Seasonal crawl patterns vs konwersja peaks — czy Google crawluje przed peakiem czy po.
• CTR GSC + log crawl = realistyczna ocena cost-per-crawl per page.

Data ciąg procesów – jak zorganizować flow logów

Surowy log file to pierwsza warstwa. Żeby analiza była skalowana, potrzebujesz ciąg procesów z 4 warstw.

Warstwa 1: Ingestion

• Apache/nginx logi z serwera (access.log, error.log).
• Cloudflare Logs Push do S3 lub log storage.
• Load balancer logs (AWS ALB, GCP LB).
• CDN edge logs (Fastly, BunnyCDN).
• Rotacja logów co 24h, compression gz.

Warstwa 2: Parsing

• Logstash, Fluentd, lub custom parsers.
• Struktura: timestamp, IP, method, URL, status, bytes, user-agent, referrer.
• Enrichment: geo-ip, bot classification (Googlebot, Bingbot, AI bots).
• Wynik: structured JSON dla dalszego processing.

Warstwa 3: Storage

• Elasticsearch dla search-heavy workload.
• BigQuery dla analityczny query.
• ClickHouse dla real-time dashboards (dla large scale).
• Retention: 90 dni hot, 1 rok cold.

Warstwa 4: Analytics

• Kibana dashboards dla Elasticsearch.
• Looker Studio dla BigQuery.
• Metabase dla self-service exploration.
• Alerting przez Slack, PagerDuty.

Automatyzacja analizy logów w n8n + Python

Manualna analiza logów 1-2h tygodniowo dla średniej skali. Automatyzacja redukuje to do 15 min plus alerty.

Proces „Daily log summary”

• Cron 6:00 — pobiera logi z ostatnich 24h (SFTP/S3).
• Filter bots Googlebot, Bingbot, AI crawlers.
• Agreguje: top 20 URL crawled, top errors, top 404.
• Slack message do #seo-alerts z summary + link do dashboardu.

Proces „Anomaly alerts”

• Compare dzisiejsze wolumeny z 7-day average.
• Alert jeśli: crawl spike > 200%, 5xx rate > 1%, nowe 404 > 20/dzień.
• PagerDuty dla critical, Slack dla warning.

Proces „Weekly pogłębiona analiza”

• Niedziela wieczór – pobiera dane z całego tygodnia.
• Python notebook generuje raport PDF.
• Wysyłka do head of SEO + CEO.

AI bots w logach – nowe wyzwania 2026

Od 2023 pojawiła się nowa kategoria crawlerów — AI bots (GPTBot, ClaudeBot, PerplexityBot, CCBot). W 2026 stanowią 10–25% total crawl traffic dla typowych serwisów.

Identyfikacja

• GPTBot — OpenAI training.
• ChatGPT-User – live browsing ChatGPT.
• OAI-SearchBot – SearchGPT indexer.
• ClaudeBot / Claude-SearchBot — Anthropic.
• PerplexityBot / Perplexity-User – Perplexity.
• Google-Extended – Google Bard training opt-in.
• CCBot — Common Crawl (używa wiele LLM-ów).
• Meta-ExternalAgent – Llama training.

Co analizować dla AI bots

• Czy AI bots crawlują ważne URL (blog, docs, product pages).
• Czy są blokowane w robots.txt (świadomie czy przez błąd).
• Rate limit – niektóre AI bots generują 1000+ req/godz.
• Correlation z cytacjami — monitor w Otterly/Profound równolegle z logami.

Strategia dla AI bots

• Open access dla content marketing — max visibility w AI search.
• Rate limiting WAF – Cloudflare rule dla nadmiernych AI bots.
• Separate sitemaps dla AI (opcjonalnie).
• Monitoring cytacji jako final KPI (logi + cytacje = pełen obraz).

Team i role — kto robi log analysis

• Technical SEO: 12–18 tys. PLN B2B. Główny analityk logów, identifies actionable wnioski.
• Data Engineer (SEO): 14–22 tys. PLN. Automatyzacja, integracje, ciągi procesów.
• DevOps / SRE: 18–26 tys. PLN. Zapewnia access do logów, retention, ingestion.
• SEO Manager: 16–24 tys. PLN. Prioryzuje wnioski, przekłada na roadmap.

Case: enterprise e-commerce, 2 mln URL, log analysis ratuje indexowanie

Klient: Marketplace e-commerce z 2 mln URL (produkty + filtry + kategorie), dip traffic -24% w 8 tygodni, niewyjaśniony.

Diagnoza z log analysis

• Googlebot crawluje 80% budgetu na filtered URL (combinations facets).
• Core product URLs – crawl rate spadł z 3/mies. do 0,8/mies.
• 5xx rate na product URLs wzrosł z 0,2% do 2,1% (overloaded DB).
• 404 od removed products bez 301 – 340 tys. URL w 404 loop.

Fixy

• robots.txt disallow dla filter combinations (obsługiwane przez internal search zamiast URLs).
• 410 dla removed products zamiast 404 – szybsza de-indexacja.
• DB optymalizacja dla product pages (query caching, index fixes).
• Sitemaps split (products, categories, blog) dla crawl priority hints.

Wyniki po 12 tyg.

• Googlebot crawl na product pages: 0,8/mies. → 4,2/mies. (+425%).
• 5xx rate: 2,1% → 0,3%.
• Traffic recovery: -24% → +8% vs baseline.
• Rev impact: +420 tys. PLN/mies. w kwartale po fixach.

Co dalej

Log file analysis to nie jednorazowa akcja — to rytm. Zacznij od audytu z 30 dni logów, zidentyfikuj top 5 problemów, napraw, po 60 dniach zrób follow-up. Większość polskich serwisów SEO nigdy nie zajrzała w logi; to daje tym, którzy zaczną, 15–30% przewagi crawl efficiency.

Jeśli chcesz pogłębić temat, sprawdź Rendering JavaScript pod SEO. Warto również zapoznać się z Crawl budżet.