Dlaczego Google Search Console nie wystarcza do analizy crawl budgetu
Search Console jest potrzebne i nie warto go pomijać. Pamiętaj jednak, że pokazuje obraz po czasie i w agregacie: dowiesz się, ile stron jest zaindeksowanych i jakie klasy błędów występują. Raport statystyk crawlowania daje sumy, trendy, podział po kodach odpowiedzi czy typach plików, a nawet przykładowe adresy. Tyle tylko, że to ograniczona próbka, a nie pełen strumień żądań. Nie zobaczysz pojedynczej wizyty robota ani trasy, jaką przeszedł po serwisie, więc raport nie odpowie na rysujące się pytanie: na jakie konkretne adresy Googlebot zużywa większość odwiedzin?
A to właśnie tam najczęściej jest ukryty 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 ogólny trend, że indeksacja idzie wolno, ale bez logów trudno wyciągnąć właściwe wnioski. Dopiero logi pokażą, że połowa wycieka na adresy, które nigdy nie powinny przyciągać uwagi robota.
Skąd wziąć Cloudflare Logs do analizy Googlebota
Jeśli serwis stoi za Cloudflare, cały ruch — łącznie z Googlebotem — przechodzi przez brzeg ich sieci, a jest to idealne miejsce do zbierania danych o crawlowaniu. Jest tylko jeden, malutki problem.
Mianowicie, surowe logi brzegowe udostępnia , a ten jest częścią planu Enterprise. Niestety, plany niższe — Free, Pro i Business — nie eksponują pełnych logów pojedynczych żądań. Dostajesz analitykę zagregowaną, dobrą do obserwowania trendów, ale bezużyteczną, jeśli 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.
Jest jeszcze trzecia droga, czyli Cloudflare Workers. Jeśli przepuścisz ruch domeny przez Workera, możesz z jego poziomu samodzielnie zapisywać żądania z user-agentem Googlebota (np. do R2). Selektywnie, dokładnie te pola, których potrzebujesz do analizy crawlowania. Plan Workers Paid udostępnia też Logpush dla Workers Trace Events, bez Enterprise. To nie są pełne logi całego ruchu, ale do śledzenia robota w zupełności wystarczą.
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 w Cloudflare Logs
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, więc 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:
Uwaga na adres, ponieważ do niedawna lista żyła pod nazwą googlebot.json, ale stary URL zwraca dziś tylko komunikat o przeniesieniu. Jeśli masz go w skryptach, zaktualizuj na common-crawlers.json. Google publikuje też osobne pliki dla pozostałych swoich botów (np. special-crawlers.json obejmujący AdsBota), więc żądanie spoza zakresów Googlebota nie zawsze jest fałszywką, po prostu może to być robot Google.
Każde żądanie z user-agentem Googlebota, którego IP nie mieści się w tych zakresach, to podszywacz, więc odfiltruj je przed jakąkolwiek analizą. Dopiero na tak oczyszczonym zbiorze liczby zaczynają cokolwiek znaczyć. A jeśli korzystasz z Cloudflare z Bot Managementem, część tej pracy dostajesz w pakiecie. Dlaczego? Cloudflare sam utrzymuje listę zweryfikowanych botów (w regułach dostępną jako cf.client.bot, w logach w polach bot managementu), więc podszywaczy możesz odsiać już na brzegu, bez własnego reverse DNS.
Co liczyć w logach Cloudflare, żeby znaleźć marnowany crawl budget
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.
-
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ć. -
Ł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.
-
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.
-
Strony osierocone. To najbardziej zdradliwy wzorzec: robot crawluje adresy, 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. Zwróć uwagę tylko, że Logpush eksportuje NDJSON, a klasyczne analizatory logów są przyzwyczajone do formatów Apache/Nginx czy W3C — przed importem sprawdź wsparcie dla JSON-a albo przemapuj pola do klasycznego układu. 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.
Co zrobić ze znalezionym marnotrawstwem
Masz diagnozę, więc pora na konkretne poprawki. Zacznij od tego, że sparametryzowane duplikaty blokujesz w robots.txt (Disallow dla parametrów sortowania i śledzenia) i porządkujesz linkami kanonicznymi, żeby robot dostał jasny sygnał, która wersja jest poprawna. Łańcuchy przekierowań skracasz do jednego skoku, więc 301 prosto do celu. Adresy usunięte na stałe powinny zwracać 410 zamiast wiecznego 404, bo to szybciej wygasza powroty robota. A sitemap ma zawierać wyłącznie funkcjonujące i kanoniczne URL-e, ponieważ to właśnie z niej biorą się strony osierocone w logach. Po wdrożeniu poprawek wróć do logów i sprawdź, czy rozkład wizyt faktycznie przesunął się na najistotniejszą dla Ciebie treść.
