Każde techniczne dochodzenie SEO w końcu uderza w ścianę. Analityka po prostu przestaje odpowiadać. Widzisz, że sesje z organica spadły, że wyświetlenia się wypłaszczyły, że jakiś szablon po cichu przestał zbierać kliknięcia - ale nie widzisz, dlaczego trzy tygodnie wcześniej crawler odpuścił sobie połowę twojego katalogu. Logi serwera zasypują tę lukę. To jedyny zapis tego, co faktycznie dotarło do twojej infrastruktury, żądanie po żądaniu, zanim jakikolwiek skrypt, tag czy warstwa renderująca zdążyła to zinterpretować. Jeśli twoja strona jest na tyle duża, że ma ograniczenia crawlowania, analiza logów nie jest żadnym zaawansowanym luksusem. To podstawa, dzięki której cała reszta zaczyna mieć sens.
Dlaczego analityka ukrywa połowę historii crawlowania
Analityka po stronie klienta odpala się na wyrenderowanym JavaScripcie. Boty, które nigdy tego JavaScriptu nie wykonują albo rezygnują, zanim strona się poskłada, po prostu nie istnieją w twoich raportach. Ta jedna mechanika wymazuje z mapy większość ruchu crawlerów. Search Console trochę pomaga, ale dostajesz próbkowane, zagregowane i opóźnione liczby bez żadnej szczegółowości na poziomie pojedynczego żądania. Dowiadujesz się, że średni czas odpowiedzi wzrósł. Nie dowiadujesz się, przez które dwanaście tysięcy URL-i z parametrami.
Logi nie mają żadnego z tych ograniczeń. Trafia tam każde żądanie, które dotknęło origin, łącznie z tymi, które wysypały się z błędem 500, zanim jakikolwiek tag zdążył się załadować. A ta ślepa plamka robi się jeszcze gorsza na dużych serwisach, sklepach z filtrowaniem fasetowym i przy migracjach, gdzie marnowanie crawlu pozostaje niewidoczne, dopóki pozycje wyraźnie nie zjadą. Traktuj logi jak swoje jedyne własne źródło informacji o tym, czego crawler naprawdę doświadczył.
Co tak naprawdę zawiera linia loga
Format combined upycha w jednej linii zaskakująco dużo: IP klienta, znacznik czasu, metodę żądania, żądaną ścieżkę, wersję protokołu, status odpowiedzi, liczbę przesłanych bajtów, referrer i user agent. Każde pole odpowiada na własne pytanie.
- Adres IP - czy ten crawler jest prawdziwy i które centrum danych go obsłużyło?
- Znacznik czasu - kiedy aktywność skoczyła, stanęła albo skupiła się w oknach awarii?
- Ścieżka - które szablony, katalogi i parametry pochłaniają uwagę?
- Kod statusu - czy żądanie się udało, przekierowało, zwróciło błąd, czy zostało zdławione?
- Przesłane bajty - jak ciężka jest odpowiedź, którą bot faktycznie dostał?
- User agent - który wariant crawlera wysłał żądanie?
Bogatsze stacki dają więcej. Nginx potrafi logować czas odpowiedzi upstreamu, a CDN-y zapisują trafienie lub pudło w cache na brzegu sieci. Pliki zwykle leżą w access_log Apache’a, access.log Nginksa, plus osobne strumienie z CDN-a i load balancera. Pole z IP klienta niesie też informację geograficzną, co ma znaczenie, jeśli korzystasz z nordyckich pul adresów IP i musisz potwierdzić, z którego centrum danych przyszedł crawler.
Wskazówka: Ustaw własny format loga z czasem odpowiedzi i statusem cache już teraz, zanim coś się wydarzy. Nie da się dorobić pól wstecz do historii. Próbowałem.
Sprawdzanie, czy Googlebot to naprawdę Googlebot
Ciągi user agent podrabia się banalnie łatwo. Scrapery przez cały dzień przedstawiają się jako Googlebot, żeby prześlizgnąć się przez prymitywne reguły blokujące, więc filtrowanie wyłącznie po tym ciągu zatruwa zbiór danych i zawyża każdy wniosek o budżecie crawlowania. Weryfikacja jest obowiązkowa. Nie opcjonalna.
Standardowa metoda: odwrotne zapytanie DNS na IP wysyłającym żądanie, potwierdzenie, że rozwiązuje się do prawidłowej nazwy hosta crawlera, a potem zapytanie w przód, które musi zwrócić pierwotny adres. Przy pracy hurtowej na milionach linii publikowane pliki z zakresami IP crawlerów są dużo szybsze i dają identyczny wynik przy dużej skali.
Potem segmentuj. Googlebot Smartphone, Googlebot Desktop i wyspecjalizowane boty (crawlery obrazków, AdsBot) zachowują się inaczej i zasługują na osobną analizę.
Wskazówka: Trzymaj zweryfikowany i niezweryfikowany ruch botów jako osobne widoki, żeby szum ze scraperów nigdy nie rozwalił ci wyliczeń budżetu crawlowania.
Marnowany budżet crawlowania: gdzie boty spędzają czas
Surowa liczba żądań nie mówi prawie nic. Prawdziwą robotę robi grupowanie: podziel żądania na kubełki według katalogu, typu szablonu i wzorca parametrów, a potem popatrz na rozkład. Marnotrawstwo zbiera się w przewidywalnych miejscach - filtry fasetowe mnożące się w kombinatoryczne zbiory URL-i, identyfikatory sesji, parametry sortowania, paginacja kalendarza maszerująca aż do 2049 roku i strony wyników wyszukiwarki wewnętrznej, które generują nieskończoną liczbę wariantów z niczego.
Teraz porównaj ten rozkład z URL-ami ważnymi komercyjnie. Rozjazd między jednym a drugim to właśnie twoje znalezisko. Logi ujawniają też sieroce URL-e, których nie ma w żadnej mapie strony i które nie dostają linków wewnętrznych, a mimo to zjadają moce przerobowe.
- Który katalog pochłania największą część zweryfikowanych żądań crawlerów?
- Jaki odsetek trafień ma parametry w zapytaniu?
- Jak często faktycznie pobierane są szablony kluczowe dla przychodu?
- Których crawlowanych ścieżek nie ma nigdzie w mapie strony?
- Czy wartościowe strony są crawlowane rzadziej niż te mało wartościowe?
Wzorce kodów statusu, które wskazują na problemy strukturalne
Kody statusu odsłaniają wady strukturalne, które audyty na poziomie pojedynczych stron rutynowo przegapiają. Klasykiem są miękkie 404: strony zwracające 200, choć nie pokazują nic użytecznego, spalają moce crawlowania i nie wnoszą żadnej wartości do indeksu. Łańcuchy i pętle przekierowań widać jak na dłoni jako kolejne trafienia 301 i 302 w obrębie jednej sesji crawlowania, gdzie każdy przeskok zjada budżet, który powinien gdzieś wylądować.
Błędy serwera trzeba czytać w czasie. Kiedy odpowiedzi 5xx skupiają się gęsto w konkretnych oknach, zamiast rozkładać się równomiernie, zwykle patrzysz na wyczerpanie zasobów pod obciążeniem, a nie na błąd w kodzie. Z kolei odpowiedzi 429 i 503 wprost mówią crawlerom, żeby zwolniły, po cichu tłumiąc odkrywanie treści przez kolejne dni.
Wskazówka: Rysuj wykres kodów statusu w ujęciu godzinowym, nie dziennym. Dziewięćdziesięciominutowa awaria całkowicie znika w dziennej średniej, a razem z nią znika twoje wyjaśnienie.
Czas odpowiedzi, rozmiar odpowiedzi i tempo crawlowania
Tempo crawlowania idzie za wydajnością serwera. Kiedy odpowiedzi dla botów zwalniają, liczba żądań spada - nawet wtedy, gdy żywi użytkownicy mają idealnie płynne doświadczenie, bo im zwykle serwowany jest ciepły cache, a crawlery trafiają na zimne ścieżki, których nikt wcześniej nie rozgrzał.
Warto zmierzyć tę różnicę wprost. Porównaj czasy odpowiedzi dla botów z czasami dla użytkowników; wyraźny rozjazd wskazuje prosto na niecache’owane ścieżki crawlerów. Współczynnik pudeł w cache dla ruchu botów to jedna z najbardziej niedocenianych diagnostyk w tej robocie. Rzadko oglądana, często rozstrzygająca.
Obserwuj też trendy w rozmiarze odpowiedzi. Rosnące rozmiary zdradzają rozdęte szablony albo pełne renderowanie serwowane przez przypadek tam, gdzie wystarczyłoby coś lżejszego.
Wskazówka: Weź próbkę najwolniej crawlowanych URL-i i sprawdź, co je łączy - wspólny szablon, konkretny parametr zapytania albo jedno kosztowne zapytanie do bazy siedzące za nimi wszystkimi.
Budowanie powtarzalnego procesu analizy logów
Jednorazowe dochodzenia dają wgląd. Powtarzalne procesy dają poprawę. Zacznij od zbierania danych: scentralizuj strumienie z originu, CDN-a i load balancera oraz pilnuj, żeby żądania nie były ani liczone podwójnie, ani po cichu gubione, gdy pochłania je brzeg sieci. Trzymaj tyle historii, żeby móc porównać zachowanie crawlerów przed i po każdym większym wdrożeniu, bo bez takiego punktu odniesienia nie przypiszesz zmiany do przyczyny.
Narzędzia dobierasz do potrzeb. Grep i awk z wiersza poleceń załatwiają szybkie pytania, tabele przestawne w arkuszu spokojnie wystarczą do miesięcznych przeglądów, a dedykowane analizatory logów i dashboardy BI robią ciągły monitoring. Połączenie danych z logów z eksportem z crawlera i listą z mapy strony pozwala zaklasyfikować każdy URL jako scrawlowany, zaindeksowany, sierocy albo zmarnowany, i tu praca z logami łączy się z szerszymi podstawami technicznego audytu SEO.
- Wyciągnij pełny miesiąc zweryfikowanych żądań botów
- Powtórz grupowanie po katalogach i parametrach
- Przejrzyj rozkład kodów statusu w ujęciu godzinowym
- Oznacz nowe sieroce URL-e na tle aktualnej mapy strony
- Porównaj czasy odpowiedzi z poprzednim okresem
Jak zamienić wnioski z logów w poprawki
Podział jest czysty: logi opisują, co zdarzyło się na serwerze, analityka opisuje, co zdarzyło się w przeglądarce. Potrzebujesz obu. Ale tylko jedno z nich widzi crawlery uczciwie.
Działaj według priorytetów. Najpierw zatrzymaj marnotrawstwo, bo blokowanie albo konsolidacja mało wartościowych wzorców URL od razu uwalnia moce przerobowe. Drugie w kolejce są błędy - łańcuchy przekierowań, miękkie 404, awarie serwera. Szybkość idzie trzecia, kiedy już wiesz, które ścieżki naprawdę zasługują na wysiłek inżynierski.
I ustaw oczekiwania po stronie interesariuszy, zanim zaczniesz. Zachowanie crawlerów zmienia się stopniowo, w miarę jak wyszukiwarki odbudowują swój obraz twojej strony, więc mierz w skali tygodni, nie dni. Zaplanuj pierwsze wyciągnięcie logów jeszcze w tym miesiącu, zamiast czekać, aż spadek ruchu wymusi tę rozmowę. Jeśli analiza przerośnie to, co twój zespół udźwignie u siebie, to jest moment, żeby sięgnąć po dedykowane wsparcie technicznego SEO.
