Dlaczego Search Console to za mało
Search Console jest potrzebne, ale pokazuje obraz po czasie i w agregacie. Dowiesz się, ile stron jest zaindeksowanych i jakie klasy błędów występują. Nie zobaczysz jednak pojedynczej wizyty robota ani trasy, jaką przeszedł po serwisie. Raport statystyk crawlowania daje sumy i trendy, ale nie odpowie na pytanie: na jakie konkretne adresy Googlebot zużywa większość odwiedzin?
A to właśnie tam najczęściej kryje się problem. W dużym serwisie robot potrafi tygodniami wracać po sparametryzowane warianty list produktów, łańcuchy przekierowań albo strony zwracające 404, zamiast odwiedzać świeżo opublikowaną treść. Search Console pokaże co najwyżej, że indeksacja idzie wolno. Dopiero logi pokażą, że połowa wycieka na adresy, które nigdy nie powinny przyciągać uwagi robota.
Skąd wziąć logi, gdy stoisz za Cloudflare
Jeśli serwis stoi za Cloudflare, cały ruch — łącznie z Googlebotem — przechodzi przez brzeg ich sieci. Idealne miejsce do zbierania danych o crawlowaniu. Jest tylko jeden haczyk.
Pełne, surowe logi brzegowe udostępnia , a ten jest częścią planu Enterprise. Plany Free i Pro nie eksponują pełnych logów pojedynczych żądań — dostajesz analitykę zagregowaną, dobrą do obserwowania trendów, ale bezużyteczną, gdy chcesz prześledzić konkretną trasę Googlebota. Jeśli nie masz Enterprise, alternatywą jest analiza logów z serwera origin, czyli tych żądań, które przeszły przez cache i dotarły do backendu.
Praktycznie konfiguracja Logpush sprowadza się do wskazania miejsca docelowego — Cloudflare R2, zasobnika S3 albo systemu SIEM — i wyboru zestawu pól logu. Dla analizy crawlowania interesują Cię przede wszystkim adres żądania, kod odpowiedzi, user-agent, źródłowe IP, czas odpowiedzi oraz informacja o trafieniu w cache.
Weryfikacja Googlebota — bez tego analiza jest fałszywa
Zanim policzysz cokolwiek, musisz oddzielić prawdziwego Googlebota od podszywaczy, bo user-agent to napis, który każdy może sobie wpisać. Sporo ruchu z nagłówkiem Googlebota pochodzi od scraperów i botów udających robota Google. Gdybyś analizował logi bez tego filtra, Twoje wnioski o crawl budżecie byłyby zwyczajnie nieprawdziwe.
Google podaje dwie wiarygodne metody weryfikacji. Pierwsza to : dla źródłowego IP wykonujesz zapytanie wsteczne i sprawdzasz, czy zwrócony host kończy się na googlebot.com lub google.com. Następnie potwierdzasz to zapytaniem w drugą stronę — forward DNS tej nazwy musi wskazywać z powrotem na wyjściowe IP. Dopiero przejście obu testów oznacza prawdziwego robota.
Druga metoda, wygodniejsza przy masowej analizie, to porównanie IP z oficjalną listą zakresów, którą Google publikuje i regularnie aktualizuje:
Każde żądanie z user-agentem Googlebota, którego IP nie mieści się w tych zakresach, to fałszywka — odfiltruj je przed jakąkolwiek analizą. Dopiero na tak oczyszczonym zbiorze liczby zaczynają cokolwiek znaczyć.
Co właściwie liczyć — wzorce marnowanego crawl budgetu
Mając zweryfikowane logi prawdziwego Googlebota, szukasz miejsc, w których robot zużywa wizyty bez pożytku. Kilka wzorców powtarza się w niemal każdym dużym serwisie.
Pierwszy to sparametryzowane adresy URL — warianty tej samej strony różniące się parametrami sortowania, filtrowania czy śledzenia. Jeśli widzisz, że Googlebot pochłania tysiące żądań na adresy w stylu ?sort=price&color=red&page=3, to znak, że crawl budget wycieka na duplikaty, które i tak nie powinny się indeksować.
Drugi to łańcuchy i pętle przekierowań. Robot trafiający na adres, który przekierowuje na kolejny, a ten na następny, zużywa wizytę na samą nawigację zamiast na treść. W logach poznasz to po seriach odpowiedzi 301/302 prowadzących jedna do drugiej.
Trzeci to strony zwracające 404 i 5xx, po które robot wciąż wraca. Każda taka wizyta to zmarnowane żądanie, a powtarzające się błędy serwera dodatkowo zniechęcają Googlebota do częstszego odwiedzania serwisu.
Czwarty, najbardziej zdradliwy, to strony osierocone — adresy, które robot crawluje, choć nie prowadzi do nich żaden link wewnętrzny. Ich obecność w logach często ujawnia stare URL-e, wycieki z sitemapy albo problemy w architekturze, których z poziomu samego serwisu nie widać.
Kiedy już wiesz, czego szukasz, zostaje pytanie o narzędzie. Dla zbiorów do kilkudziesięciu milionów linii w zupełności wystarczy Screaming Frog Log File Analyser — wczyta logi, zweryfikuje Googlebota przez DNS i od ręki pokaże częstotliwość crawlowania, rozkład kodów odpowiedzi i strony osierocone. Przy większej skali kieruj logi do hurtowni danych i analizuj zapytaniami SQL. Zyskujesz pełną swobodę w drążeniu i łączeniu ich z innymi źródłami — to też naturalny pomost do wykrywania anomalii SEO z BigQuery, jeśli chcesz pójść o krok dalej.
