Analiza logów serwera dla SEO - jak monitorować crawlowanie

Logi serwera to jedyne źródło, które pokazuje każdą realną wizytę Googlebota na Twojej stronie - nie próbkę, nie agregat, tylko surowy zapis request po requeście. Search Console raportuje statystyki crawlowania w postaci uśrednionych wykresów, ale ukrywa szczegóły, które decydują o tym, czy ważne podstrony w ogóle trafiają do indeksu.

W logach zobaczysz, które dokładnie adresy bot odwiedza, w jakich godzinach, jaki status code zwraca serwer (200, 301, 404, 500) i jak długo trwa odpowiedź. Ten poziom granularności pozwala odpowiedzieć na pytania, na które raport Statystyki indeksowania nie odpowie: dlaczego Google traci czas na parametry filtrów zamiast crawlować nowe produkty, albo czemu kluczowa kategoria nie była odwiedzona od trzech miesięcy.

Jeśli masz problem z indeksacją na większym serwisie, logi są pierwszym miejscem, w którym szukasz przyczyny - nie domyślasz się, tylko widzisz fakty.

Crawl budget to liczba adresów, które Google jest skłonny pobrać z Twojej domeny w danym czasie. Składa się z dwóch elementów: crawl rate limit (ile bot może pobrać bez przeciążania serwera) oraz crawl demand (jak bardzo Google chce te treści crawlować, w oparciu o popularność i świeżość).

Dla małych stron budżet praktycznie nie istnieje jako problem - Google bez trudu odwiedza wszystkie podstrony. Kłopot zaczyna się powyżej kilku tysięcy adresów, gdzie bot musi wybierać, co odwiedzić. Wtedy każdy request zmarnowany na duplikat, parametr sortowania czy stronę 404 to request, którego zabraknie na realnej treści.

Logi pokazują podział budżetu w liczbach bezwzględnych. Możesz policzyć, jaki procent wizyt Googlebota trafia na wartościowe, indeksowalne strony, a jaki na śmieci. To metryka, która w naszych projektach najczęściej decyduje o tym, gdzie najpierw przyłożyć rękę. Profesjonalne podejście do crawl budgetu to stały element pozycjonowania SEO dużych serwisów.

Dwa najczęstsze wzorce, które wychodzą z logów, to strony pomijane (niedocrawlowane) oraz strony przecrawlowane (marnujące budżet). Oba są kosztowne, ale w odwrotny sposób: pierwsze nie trafiają do indeksu, drugie odbierają zasoby tym, które powinny.

Strony pomijane to często wartościowe podstrony głęboko w strukturze, do których prowadzi za mało linków wewnętrznych, albo nowe treści, które bot odkrywa z dużym opóźnieniem. Strony przecrawlowane to zwykle warianty z parametrami URL, filtry sklepowe, kalendarze, wewnętrzne wyszukiwarki i łańcuchy przekierowań.

Poniższa tabela pokazuje typowe sygnały z logów i ich interpretacje.

Logi pobierzesz z serwera lub warstwy pośredniczącej. Najczęstsze źródła to Raw Access Logs w cPanel/Plesk, pliki Apache (/var/log/apache2/access.log), Nginx (/var/log/nginx/access.log) oraz logi CDN. Cloudflare udostępnia pełne logi dopiero w planie Enterprise lub przez Workers, co przy mniejszych wdrożeniach bywa barierą - wtedy lepiej sięgnąć po logi z origin servera.

Standardowy Combined Log Format wygląda tak:

66.249.66.1 - - [10/Jan/2026:12:00:00 +0000] "GET /produkt.html HTTP/1.1" 200 5432 "-" "Googlebot/2.1"

Krytyczny krok to weryfikacja prawdziwego Googlebota. Spamerzy podszywają się pod jego user-agent, dlatego sprawdzaj reverse DNS - autentyczny bot rozwiązuje się do domeny googlebot.com lub google.com. Dla sensownych wniosków potrzebujesz minimum 30 dni danych, a optymalnie 3-6 miesięcy.

Nie analizuj wszystkiego naraz - zacznij od kilku metryk, które dają największy zwrot. Częstotliwość crawlowania per URL pokazuje, czy ważnym stronom poświęcana jest uwaga proporcjonalna do ich roli. Rozkład status codes ujawnia błędy 4xx/5xx i nadmiar przekierowań. Response time poniżej kilkuset milisekund utrzymuje wysoki crawl rate; wolny serwer dławi budżet.

Osobno warto zmierzyć crawl budget waste, czyli procent wizyt na stronach noindex, przekierowaniach i 404. Druga ważna metryka to czas od publikacji do pierwszego crawla - mówi, jak szybko Google odkrywa świeże treści. Przy indeksie mobile-first sprawdzasz też, czy dominuje Googlebot Smartphone.

Dla większości wdrożeń wystarczy Screaming Frog Log File Analyser - aplikacja desktopowa, która importuje logi, weryfikuje boty i łączy dane z crawlem. Pozwala porównać, które zaindeksowane URL Googlebot pomija, oraz wykryć strony osierocone (orphan pages), do których nie prowadzi żaden link wewnętrzny. To pierwsze narzędzie, które polecamy zespołom in-house.

Dla dużych serwisów z setkami tysięcy URL sprawdzają się rozwiązania chmurowe: Oncrawl i JetOctopus łączą logi z crawlem i danymi z Search Console, dodają segmentację i historyczne porównania. Botify celuje w mega-serwisy z analizą w czasie zbliżonym do rzeczywistego. Zespoły z kompetencjami inżynierskimi często budują własny pipeline - ELK Stack, Python z pandas albo BigQuery dla naprawdę dużych wolumenów.

Wybór narzędzia nie jest celem samym w sobie. Liczy się, czy odpowiada na pięć pytań: które strony nigdy nie są crawlowane, które są przecrawlowane, gdzie są błędy 4xx/5xx, jakie są łańcuchy przekierowań i gdzie występują skoki response time.

Im większy serwis, tym mocniej logi zamieniają się z ciekawostki w narzędzie decyzyjne. Przy 10 tysiącach i więcej adresów nie da się na oko ocenić, gdzie Google traci czas - potrzeba twardych liczb z segmentacją po katalogach.

Największy zysk daje grupowanie URL w segmenty (np. /produkt/, /kategoria/, /blog/, parametry) i porównanie ich udziału w crawl budżecie z wartością biznesową. Często okazuje się, że sekcja generująca przychód dostaje ułamek uwagi bota, podczas gdy filtry i sortowania pochłaniają większość. Wtedy reakcja to canonical, blokady w robots.txt, czyszczenie łańcuchów przekierowań i wzmocnienie linkowania wewnętrznego do priorytetowych sekcji.

Migracje to drugi moment, gdy logi są bezcenne. Po przeniesieniu domeny lub redesignie monitorujesz w nich, czy Google poprawnie przechodzi przez mapę przekierowań i jak szybko adoptuje nowe URL.

Nie chcesz sprawdzać tego ręcznie? Zobacz ile kosztuje profesjonalny audyt strony i co dokładnie obejmuje.