Google Search Console pokazuje wycinek prawdy. Jeśli chcesz wiedzieć, co Googlebot naprawdę robi na Twojej stronie – które adresy odwiedza, jak często, z jakim skutkiem – musisz zajrzeć do logów serwerowych. To jedyne źródło stuprocentowej informacji o zachowaniu robota, a zarazem jedno z najrzadziej wykorzystywanych narzędzi technicznego SEO.
Artykuł należy do klastra zaawansowanej optymalizacji technicznej SEO – po szerszy kontekst sięgnij do huba.
Czym są logi serwerowe i dlaczego są krytyczne dla zaawansowanego SEO?
Logi serwerowe to zapis każdego żądania trafiającego na serwer – w tym wizyt Googlebota. Dla SEO są źródłem twardych danych o tym, które adresy robot realnie odwiedza, jak często i z jakim kodem odpowiedzi. W odróżnieniu od raportów opartych na próbkowaniu, logi pokazują 100% ruchu robota, bez szacunków.
To jest właśnie ich przewaga. Większość narzędzi SEO opiera się na próbkowaniu albo symulacji crawlowania. Logi nie szacują – rejestrują. Każde wejście robota, każdy pobrany plik, każdy błąd serwera. Dla dużych serwisów to różnica między „wydaje nam się, że Google indeksuje” a „wiemy, co Google robi”.
Logi serwera a Google Search Console – dlaczego same dane z GSC nie wystarczą?
Google Search Console jest niezastąpione, ale pokazuje tylko część obrazu: zagregowane statystyki i wybrane błędy, często z opóźnieniem i w próbce. Logi ujawniają pełną listę zapytań robota – łącznie z adresami, których GSC w ogóle nie raportuje. Dopiero zestawienie obu źródeł daje pełny obraz: GSC mówi „co Google zaindeksował”, logi mówią „gdzie Google realnie był i ile go to kosztowało”.
Jest też pułapka, o której trzeba pamiętać: nie każdy „Googlebot” w logach to faktycznie Google. Część botów podszywa się pod Googlebota (spoofing), zaburzając statystyki. Dlatego przy poważnej analizie weryfikujemy autentyczność robota przez odwrotne zapytanie DNS (reverse DNS lookup) – to oddziela prawdziwe wizyty Google od fałszywych. Google opisuje tę procedurę w dokumentacji.
Kluczowe metryki w analizie logów: częstotliwość, kody odpowiedzi i User Agents
Z surowych logów wyciągamy kilka decydujących sygnałów: częstotliwość odwiedzin per adres i sekcja (które strony Google ceni, a o których zapomniał), kody odpowiedzi (czy robot dostaje 200, czy uderza w błędy) oraz User Agents (Googlebot na komórkę vs desktop, inne roboty). Szczególnie cenna jest korelacja, którą widać tylko w logach: im niższy czas odpowiedzi serwera (TTFB), tym głębiej i częściej robot crawluje. Wolny serwer dosłownie zniechęca Google do odwiedzin – dlatego wydajność backendu to nie tylko Core Web Vitals, ale i crawl budget.
Jak zidentyfikować marnowanie crawl budgetu dzięki analizie logów?
Logi są najlepszym narzędziem do wykrycia, gdzie Google traci czas. Jeśli robot setki razy odwiedza warianty filtrów, parametry sortowania czy paginację, a rzadko zagląda do ważnych podstron – masz marnowanie crawl budgetu jak na dłoni. To bezpośrednio łączy się z tematem crawl budget i indeksowania: logi pokazują problem, a optymalizacja architektury i robots.txt go rozwiązuje.
Wykrywanie stron osieroconych (Orphan Pages)
Strona osierocona to taka, do której nie prowadzi żaden link wewnętrzny – użytkownik jej nie znajdzie przez nawigację, ale robot może na nią trafić (np. ze starej mapy witryny czy linku zewnętrznego). Zestawiając adresy z logów z mapą linkowania z crawla, wyłapujemy strony, które Google odwiedza, choć nie ma do nich ścieżki w serwisie. To częste źródło marnowanego budżetu i sygnał do uporządkowania architektury.
Analiza kodów błędów: 4xx, 5xx i pętle przekierowań 3xx
Logi to najszybsza diagnoza problemów, które tłumią pozycje: błędy 4xx (np. 404 – robot trafia w nieistniejące adresy i marnuje budżet), błędy 5xx (serwer nie odpowiada – krytyczne, bo Google obniża wtedy tempo crawlowania) oraz pętle i łańcuchy przekierowań 3xx (robot skacze przez kolejne redirecty, tracąc zasoby i sygnały). Analiza kodów błędów jest szczególnie istotna przy migracjach – to logi potwierdzają, czy przekierowania działają tak, jak zaplanowano, czy generują pętle.
Spider Traps – pułapki na roboty w e-commerce
Osobny, podstępny problem dużych sklepów. Źle skonfigurowane filtry potrafią generować nieskończoną liczbę adresów (każda kombinacja filtra to nowy URL) – to tzw. spider trap, pułapka, w której robot grzęźnie zamiast docierać do produktów. Standardowy audyt frontendowy tego nie wychwyci, bo problem ujawnia się dopiero w skali zachowania robota. W logach widać go natychmiast: tysiące wejść w parametryzowane adresy o zerowej wartości.
Narzędzia do analizy logów
Trzy poziomy zaawansowania, zależnie od wielkości serwisu:
- Screaming Frog Log File Analyser – dedykowane narzędzie desktopowe, idealne dla większości stron; importuje logi i krzyżuje je z danymi crawla.
- ELK Stack (Elasticsearch, Logstash, Kibana) – rozwiązanie dla bardzo dużych serwisów, z analizą w czasie rzeczywistym.
- Rozwiązania chmurowe – gdy logi liczy się w gigabajtach i potrzebna jest ciągła obserwacja.
Przykład: jak analiza logów ujawnia problem z renderowaniem JavaScript
Logi pomagają też zdiagnozować problemy, które na pierwszy rzut oka nie wyglądają na „logowe”. Jeśli widzisz, że Googlebot pobiera HTML strony, ale nie pobiera kluczowych plików JavaScript albo robi to z dużym opóźnieniem, masz sygnał, że treść zależna od JS może nie zostać poprawnie zrenderowana i zaindeksowana. To naturalny pomost do tematu JavaScript SEO (SSR vs CSR) – logi pokazują, czy robot w ogóle sięga po zasoby potrzebne do zbudowania strony. Taką analizę wpinamy w pełny audyt SEO.
FAQ – analiza logów serwerowych
Jak pobrać logi serwera do analizy SEO?
Logi udostępnia hosting lub administrator serwera – najczęściej przez panel hostingowy, FTP/SSH albo serwer aplikacyjny (np. logi Apache/Nginx). Do analizy potrzebujesz okresu obejmującego co najmniej kilka tygodni, by zobaczyć wzorce zachowania robota.
Czym różni się wizyta Googlebota w logach od danych w GSC?
Logi rejestrują 100% rzeczywistych zapytań robota, GSC pokazuje zagregowaną, częściowo próbkowaną część obrazu, często z opóźnieniem. Logi mówią „gdzie Google realnie był”, GSC – „co Google zaindeksował i jakie widzi problemy”. Pełną diagnozę daje połączenie obu.
Jakie narzędzia są najlepsze do analizy logów serwerowych?
Dla większości serwisów wystarczy Screaming Frog Log File Analyser. Bardzo duże strony korzystają z ELK Stack lub rozwiązań chmurowych z analizą w czasie rzeczywistym. Wybór zależy od skali logów i potrzeby ciągłego monitoringu.
Dlaczego Googlebot nie odwiedza moich nowych podstron?
Najczęstsze przyczyny to słabe linkowanie wewnętrzne (strona osierocona), wyczerpany crawl budget marnowany na parametry i błędy, wolny serwer (wysoki TTFB) lub niski popyt na indeksację przy cienkiej treści. Logi pokazują, czy robot w ogóle do nich dociera – to pierwszy krok diagnozy.
Podsumowanie
Analiza logów serwerowych to przejście od domysłów do faktów. Tylko logi pokazują, jak Googlebot naprawdę porusza się po serwisie – które adresy odwiedza, jak często, z jakim skutkiem i ile budżetu marnuje. Pozwalają wykryć strony osierocone, błędy 4xx/5xx, pętle przekierowań i pułapki na roboty, których nie widać w standardowym audycie. Pamiętaj o weryfikacji autentyczności robota (reverse DNS) i o tym, że szybki serwer jest crawlowany głębiej.
Chcesz wiedzieć, co Googlebot naprawdę robi na Twojej stronie? W SEONIM analizujemy logi w ramach optymalizacji technicznej – fundamentu skutecznego pozycjonowania stron. Napisz do nas, zajrzymy robotowi przez ramię bez zobowiązań.
