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 budget. 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.

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 budget 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: deep dive 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 budget — 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 budget 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% use cases. 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 budget; (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.

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.

• Rendering JavaScript pod SEO — jak rendering JS zmienia wzorce w logach.
• Crawl budget — kontekst, dlaczego log analysis jest krytyczna.
• Audyt SEO 2026 — jak log analysis wpisuje się w pełny audyt.
• SEO 2026 — przewodnik — szeroki kontekst technicznego SEO.