Dlaczego logi serwera są niedocenianym „rentgenem” SEO

Większość zespołów SEO pracuje na dwóch zestawach danych: analityce (GA4, Matomo) i Search Console. To świetne narzędzia, ale mają wspólną wadę: pokazują efekty i wycinki, a nie pełny obraz zachowania robotów. Logi serwera działają inaczej. To surowy zapis tego, co faktycznie weszło na Twoją stronę: kto, kiedy, co pobrał, z jakim kodem odpowiedzi i jak długo czekał na odpowiedź.

Jeżeli kiedykolwiek miałeś sytuację typu „strona niby jest, ale nie rośnie”, „GSC pokazuje dziwne skoki”, „po wdrożeniu coś siadło, ale nie wiemy co”, to logi często dają najszybszą, najbardziej zero-jedynkową odpowiedź. Nie trzeba zgadywać, czy Googlebot widzi nowy URL. W logach widać, czy go odwiedził, jak często wracał, czy wpadł w pętle przekierowań, czy wali w parametry, czy dostaje 5xx, czy marnuje czas na zasoby, których i tak nie chcesz indeksować.

Czym są logi i co realnie znajdziesz w jednym wpisie

Najczęściej analizuje się logi dostępu (access logs) z serwera WWW, reverse proxy lub CDN. Pojedynczy wpis potrafi zawierać m.in. adres IP klienta, datę i godzinę żądania, metodę (GET/HEAD), URL, kod HTTP (np. 200/301/404/500), rozmiar odpowiedzi, referer i user-agent. W praktyce oznacza to, że możesz odtworzyć ścieżki poruszania się botów i użytkowników oraz zidentyfikować problemy techniczne, które nie zawsze widać w raportach.

Ważna uwaga: user-agent da się podszyć. Dlatego w przypadku decyzji o blokowaniu botów nie opieraj się wyłącznie na tym polu. Logi traktuj jako punkt startu, a weryfikację rób metodami zalecanymi przez Google (o tym niżej).

Skąd wziąć logi (i dlaczego czasem ich „nie ma”)

W zależności od architektury możesz mieć logi w kilku miejscach:

• Serwer aplikacji (Apache/Nginx) – klasyczne access_log.
• Reverse proxy / load balancer – czasem to on widzi prawdziwy ruch, a serwer backendowy już nie.
• CDN/WAF (np. warstwa ochrony) – potrafi odfiltrować sporo ruchu zanim dotrze do serwera, więc logi „origin” nie pokażą pełnego obrazu.

Jeżeli dostawca hostingu mówi „nie udostępniamy logów”, to w praktyce oznacza, że nie udostępnia ich w panelu, a nie że one nie istnieją. Warto poprosić konkretnie o: logi dostępu z ostatnich 7–30 dni, najlepiej z rozdzieleniem na domeny/vhosty, z zachowaniem user-agent i czasu odpowiedzi. Bez czasu odpowiedzi da się zrobić dużo, ale tracisz klucz do diagnostyki wydajnościowej.

Co w logach jest najważniejsze dla SEO (priorytety zamiast „wszystkiego naraz”)

Żeby analiza nie zamieniła się w dłubanie w milionach wierszy, ustaw priorytety. W większości serwisów najszybciej zwraca się przegląd pięciu obszarów:

• Jak często i co dokładnie crawluje Googlebot oraz czy nie „przepala” czasu na śmieci.
• Skala błędów 4xx i 5xx, w tym powtarzalne 404/410 oraz niestabilne 5xx.
• Przekierowania: łańcuchy, pętle, masowe 302 zamiast 301, przekierowania do strony głównej.
• Parametry i filtrowanie (faceted navigation): czy bot nie wpada w nieskończone kombinacje URL-i.
• Wydajność: czy kluczowe typy stron nie mają powolnych odpowiedzi (to wpływa na crawl i doświadczenie użytkownika).

Jak rozpoznać Googlebota i nie dać się nabrać na podszywanie

W logach zobaczysz mnóstwo wpisów z user-agentem zawierającym słowo „Googlebot”. Problem w tym, że każdy crawler może to sobie wpisać. Jeżeli planujesz blokady, limity lub chcesz wyciągać wnioski o zachowaniu Google, stosuj weryfikację zalecaną przez Google: reverse DNS dla IP, sprawdzenie domeny (np. googlebot.com), a potem forward lookup, czy ta nazwa rozwiązuje się z powrotem do tego samego IP.

Praktycznie: najpierw wyłapujesz podejrzanie intensywny ruch „udający Google”, a dopiero potem weryfikujesz IP-y. Dzięki temu nie blokujesz czegoś, co tylko wygląda jak bot, a w rzeczywistości jest losowym scraperem.

„Crawl budget” w praktyce: kiedy ma znaczenie, a kiedy to tylko modne hasło

W małych serwisach temat crawl budgetu bywa przeceniany. Jeżeli masz kilkaset stron i czysty serwis bez parametrów, Google zwykle ogarnie temat. Crawl budget zaczyna realnie boleć, gdy:

• Masz tysiące lub setki tysięcy URL-i (e-commerce, ogłoszenia, katalogi, media).
• Tworzysz kombinacje parametrów, filtrów, sortowań, paginacji.
• Serwer jest wolny albo niestabilny (bot ogranicza tempo, bo widzi problemy).
• Masz dużo przekierowań, błędów i duplikatów – bot „marnuje” żądania.

Logi odpowiadają na proste pytanie: czy bot wydaje swoje wejścia na to, co chcesz indeksować i pozycjonować, czy na rzeczy przypadkowe. Jeżeli widzisz, że duża część crawl to parametry, strony wyszukiwania wewnętrznego, koszyk, panel, duplikaty, stare ścieżki po migracjach – to nie jest teoria. To konkretny koszt w postaci wolniejszego odkrywania i aktualizowania właściwych treści.

Najczęstsze wzorce problemów, które w logach widać od razu

W praktyce powtarza się kilka scenariuszy. Warto znać je „po objawach”, bo skracają diagnostykę:

1) Pętle i łańcuchy przekierowań. Bot trafia na stary URL, dostaje 301, potem kolejne 301, czasem wraca do punktu wyjścia. W logach zobaczysz to jako powtarzalne żądania tych samych adresów i kody 3xx. Skutek: strata crawl i często gorsze przeniesienie sygnałów.

2) Masowe 404 na adresach, które kiedyś istniały. Zwykle po zmianie struktury URL, wdrożeniu filtrów albo „porządkach” w treściach. Jeżeli 404 dotyczy stron z linkami zewnętrznymi lub istotnych ścieżek wewnętrznych, to proszenie się o spadki.

3) Parametry generujące „nieskończony katalog”. Typowe w sklepach: sortowania, filtry, kombinacje cech, UTM-y. W logach wyjdzie to jako tysiące unikalnych URL-i o podobnym wzorcu, intensywnie crawlowanych, często bez wartości.

4) Bot częściej odwiedza zasoby, które nie zmieniają się od miesięcy, niż treści świeże. To bywa efekt złej architektury linkowania wewnętrznego lub blokad/utrudnień w odkrywaniu nowych URL-i (np. nowe treści są „schowane” głęboko, bez linków, zależne od JS).

5) Skoki 5xx lub długie czasy odpowiedzi. Nawet jeśli użytkownicy „tego nie czują”, bot potrafi spowolnić crawl, bo widzi niestabilność. Logi z czasem odpowiedzi są tu bezlitosne: widać, które endpointy są najcięższe.

Indeksacja a crawl: jak nie pomylić jednego z drugim

To częsty błąd w interpretacji danych. Crawl oznacza: bot odwiedził URL. Indeksacja oznacza: Google uznał, że warto mieć tę stronę w indeksie (i utrzymywać ją). Logi nie powiedzą Ci wprost „to jest w indeksie”, ale powiedzą Ci coś równie ważnego: czy Google w ogóle ma szansę zobaczyć stronę regularnie i czy dostaje poprawne odpowiedzi.

W praktyce świetnie działa zestawienie trzech list:

• URL-e z sitemap (co mówisz Google, że jest ważne).
• URL-e crawlowane przez Googlebota (co Google realnie odwiedza).
• URL-e z raportów pokrycia/indeksowania w Search Console (jak Google to kwalifikuje).

Jeżeli ważne strony są w sitemap, ale prawie nie ma ich w logach – problemem może być odkrywanie, architektura linków, blokady, wydajność albo ogromny szum w parametrach. Jeżeli są w logach, ale nie w indeksie – wtedy patrzysz na jakość, duplikację, kanonikalizację i sygnały E-E-A-T.

Prosty workflow: analiza logów w 60–90 minut (bez enterprise’owych narzędzi)

Da się zrobić sensowną analizę nawet bez drogich platform. Klucz to nie „perfekcyjny pipeline”, tylko dobre pytania i szybkie filtrowanie:

• Weź logi z 7–14 dni (w dużych serwisach nawet 2–3 dni potrafią wystarczyć, bo ruch botów jest intensywny).
• Odfiltruj ruch użytkowników, skup się na botach (Google, Bing), ale pamiętaj o weryfikacji IP, gdy wchodzisz w blokady.
• Zrób listę TOP URL-i po liczbie wejść bota – i sprawdź, czy to w ogóle są strony, które chcesz promować.
• Wypisz najczęstsze kody odpowiedzi (2xx, 3xx, 4xx, 5xx) i znajdź powtarzalne wzorce: te same ścieżki, te same parametry, te same błędy.
• Sprawdź, czy bot odwiedza nowe treści oraz czy wraca do kluczowych URL-i (huby, kategorie, top artykuły).
• Jeśli masz czas odpowiedzi: znajdź strony z najdłuższym czasem i zobacz, czy są to typy stron ważne biznesowo (np. listing produktów) czy śmieciowe endpointy.

Najważniejsze: po tej godzinie masz mieć 3–5 konkretnych wniosków do wdrożenia, a nie „ładny raport”. Logi są narzędziem decyzyjnym, nie ozdobą.

Co zazwyczaj działa jako szybkie poprawki po analizie logów

Gdy już wiesz, gdzie bot marnuje czas albo gdzie dostaje problemy, zwykle wygrywają działania porządkujące. Najczęstsze szybkie wygrane to:

• Naprawa łańcuchów i pętli przekierowań, doprowadzenie do pojedynczego skoku 301 tam, gdzie to ma sens.
• Ucywilizowanie parametrów: jasne reguły kanonikalizacji, blokowanie indeksacji śmieciowych kombinacji, ograniczenie linkowania do nieistotnych filtrów.
• Podniesienie jakości linkowania wewnętrznego do stron, które chcesz, żeby były częściej crawlowane (bot podąża za linkami).
• Uszczelnienie błędów 404/410 na adresach, które nadal mają ruch lub linki zewnętrzne (albo przywrócenie strony, albo sensowne przekierowanie do najbliższego odpowiednika).
• Wydajność krytycznych szablonów: jeśli listingi i artykuły mają długie czasy odpowiedzi, bot też to odczuwa, a crawl bywa ograniczany.

Po wdrożeniach wróć do logów po 7–14 dniach i sprawdź, czy profil crawl się zmienił. To jest jedna z najfajniejszych rzeczy w pracy z logami: widać, czy zmiana realnie wpłynęła na zachowanie botów, a nie tylko „powinna” wpłynąć.

Kiedy analiza logów powinna być obowiązkowa

Są sytuacje, w których logi nie są „miłym dodatkiem”, tylko elementem bezpieczeństwa projektu:

• Migracja (domena, CMS, struktura URL, redesign) – logi pokażą, czy bot trafia na 301, czy pojawiają się czarne dziury i czy crawl idzie w nowe adresy.
• Duży e-commerce z filtrami – bez logów łatwo przegapić, że bot przetacza się przez parametry zamiast produktów i kategorii.
• Serwis z problemami indeksacji „bez powodu” – logi często ujawniają niestabilne 5xx, timeouty albo nieoczywiste przekierowania.
• Spadki po wdrożeniach – logi pozwalają odróżnić problem treści/algorytmów od problemu czysto technicznego.

Źródła

• https://developers.google.com/search/docs/crawling-indexing/googlebot – Dokumentacja Google Search Central o Googlebocie, w tym wskazówki dotyczące weryfikacji i bezpiecznego rozpoznawania robota.
• https://developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests – Oficjalny opis Google, jak weryfikować żądania od crawlerów (reverse DNS i inne metody), żeby nie blokować „fałszywych Googlebotów”.
• https://developers.google.com/search/docs/crawling-indexing – Przegląd tematów Google o crawlowaniu i indeksowaniu: jak Google znajduje, pobiera i interpretuje treści.
• https://httpd.apache.org/docs/2.4/logs.html – Dokumentacja Apache o logach, w tym opis Combined Log Format i podstawy konfiguracji zapisu logów.
• https://www.iana.org/assignments/http-status-codes – Rejestr kodów statusu HTTP utrzymywany przez IANA (odniesienia do RFC i znaczenie kodów).
• https://web.dev/vitals/ – Core Web Vitals: metryki wydajności i progi jakości, które często korelują z problemami widocznymi w logach (powolne odpowiedzi, obciążone szablony).