Logi serwera a SEO sklepu: czego szukać w logach

Logi serwera SEO: co naprawdę robi Googlebot w sklepie

Właściciel sklepu może mieć poprawną mapę XML, dobrze skonfigurowany robots.txt i przyzwoity wynik audytu technicznego, a mimo to nie wiedzieć, co faktycznie dzieje się podczas wizyt robotów. Logi serwera SEO pokazują bezpośrednio żądania docierające do serwera. Widzisz w nich adres, metodę HTTP, kod odpowiedzi, czas żądania, user agenta, a zależnie od konfiguracji także adres IP, referer czy czas obsługi zapytania.

To istotna różnica względem narzędzi, które analizują strukturę sklepu z perspektywy crawlowania wykonywanego przez sam audytor. Log pokazuje zdarzenie, które rzeczywiście miało miejsce na serwerze. Jeżeli Googlebot odwiedza stronę produktu, otrzymuje 200 i za chwilę ponownie pobiera adres z parametrem sortowania, zobaczysz oba żądania. Jeżeli trafia na 404, 500 albo długi ciąg przekierowań, również zostanie po tym ślad.

W praktyce analiza logów pozwala odpowiedzieć na pytania, których często nie da się rozstrzygnąć samym crawlem własnej strony: czy Googlebot odwiedza ważne strony, czy wraca przede wszystkim do filtrów, czy pobiera stare adresy, czy trafia na błędy serwera i czy część jego aktywności nie jest związana z adresami, których w ogóle nie chcesz rozwijać w indeksie.

Jeżeli chcesz połączyć dane z logów z szerszą kontrolą techniczną, przydaje się również zakres audytu technicznego sklepu, bo logi pokazują zachowanie robotów, a audyt pozwala sprawdzić przyczyny problemów w strukturze strony.

Jak analizować logi serwera pod SEO

Pierwszy krok to ustalenie, gdzie serwer zapisuje access logi. W środowisku nginx odpowiada za to między innymi dyrektywa access_log, a format danych definiuje log_format. Apache wykorzystuje przede wszystkim CustomLog i LogFormat. Dokładna lokalizacja pliku zależy od konfiguracji serwera, hostingu oraz sposobu uruchomienia konkretnej witryny.

Nie zaczynaj od ręcznego czytania całego pliku. W sklepie internetowym log może zawierać ogromną liczbę żądań, w tym obrazy, arkusze CSS, JavaScript, pliki techniczne, ruch użytkowników i boty. Przy większym sklepie takie przeglądanie szybko przestaje mieć sens.

Najpierw wyodrębnij żądania związane z Googlebotem. Następnie pogrupuj je według URL i kodu odpowiedzi. Dopiero później przechodź do parametrów, częstotliwości wizyt i poszczególnych kategorii adresów.

Prosty schemat pracy wygląda tak:

1. Pobierz access logi obejmujące interesujący okres.
2. Ustal format każdej linii logu.
3. Wyodrębnij żądania deklarujące Googlebot jako user agenta.
4. Zweryfikuj, czy ruch rzeczywiście pochodzi od Google, zamiast ufać samemu user agentowi.
5. Pogrupuj żądania według adresu URL.
6. Dodaj podział według kodów HTTP.
7. Oddziel adresy kanoniczne od parametrów, filtrów, wyszukiwania i innych wariantów.
8. Porównaj wyniki z mapą XML, robots.txt oraz listą ważnych stron sklepu.
9. Zidentyfikuj adresy odwiedzane często, ale nieprzydatne z punktu widzenia indeksowania.
10. Sprawdź, które ważne strony nie pojawiają się w logach albo pojawiają się znacznie rzadziej, niż wynikałoby to z architektury sklepu.

To podejście pozwala przejść od surowego pliku tekstowego do konkretnej listy problemów technicznych.

Co powinno znaleźć się w logu

Do analizy SEO potrzebujesz przede wszystkim informacji o żądanym adresie, czasie żądania, kodzie odpowiedzi oraz user agencie. Nginx pozwala skonfigurować format logu tak, aby zapisywać między innymi żądanie, status HTTP, ilość przesłanych danych i nagłówki związane z klientem. Apache również daje dużą swobodę w definiowaniu formatu access logu.

Jeżeli masz możliwość zmiany konfiguracji, nie ograniczaj logowania do samego adresu IP. Sam adres IP niewiele mówi o tym, dlaczego konkretne żądanie zostało wykonane. Przydatny jest pełny request, status odpowiedzi i user agent. W niektórych analizach przydaje się również czas obsługi żądania.

Pamiętaj też, że logi mogą zawierać dane techniczne, których nie powinno się udostępniać publicznie. Przed przekazaniem pliku osobie z zewnątrz usuń dane, które nie są potrzebne do analizy.

Czego szukać w logach Googlebot

Najbardziej użyteczna analiza zaczyna się od pytania: czego szukać w logach Googlebot, a nie od samego liczenia wizyt.

Pierwszym obszarem są adresy, które robot pobiera najczęściej. Jeżeli w sklepie znajduje się kilka tysięcy produktów, a Googlebot bardzo często odwiedza adresy z parametrami filtrowania, sortowania lub paginacji, trzeba sprawdzić, czy taki ruch jest uzasadniony. Nie każdy request jest problemem, ale powtarzalny wzorzec może pokazać, że robot poświęca uwagę dużej liczbie wariantów tego samego zbioru produktów.

Przykład:

/kategoria/buty
/kategoria/buty?page=2
/kategoria/buty?sort=price-asc
/kategoria/buty?size=42
/kategoria/buty?size=42&sort=price-asc

Jeżeli wszystkie takie warianty są masowo odwiedzane, sprawdź, czy są potrzebne w wyszukiwaniu organicznym. W sklepie WooCommerce lub PrestaShop parametry mogą być generowane przez filtry, sortowanie, moduły nawigacji warstwowej albo funkcję wyszukiwania.

Drugi obszar to stare URL. Po migracji sklepu albo zmianie struktury kategorii robot może przez dłuższy czas wracać do dawnych adresów. W logach zobaczysz, czy stare URL nadal otrzymują żądania i jakie odpowiedzi zwracają. Jeżeli adres został trwale przeniesiony, sprawdź, czy odpowiedź jest zgodna z założeniem. Jeżeli produkt został usunięty bez zamiennika, sprawdź, czy serwer zwraca odpowiedni status zamiast generować przypadkową stronę.

Trzeci obszar to strony, które powinny być istotne dla biznesu, ale praktycznie nie pojawiają się w logach. Jeżeli najważniejsze kategorie i produkty nie są odwiedzane, a robot spędza czas na technicznych wariantach adresów, trzeba przeanalizować architekturę linkowania wewnętrznego, mapę XML, dostępność adresów oraz dyrektywy indeksowania.

W tym miejscu przydatne jest również sprawdzenie poprawnej struktury ścieżek nawigacyjnych, ponieważ log mówi, jakie URL są pobierane, ale nie pokazuje całej logiki nawigacji prowadzącej do tych adresów.

Czy Googlebot odwiedza ważne strony

To jedno z praktycznych pytań, na które logi serwera dają dobrą odpowiedź: czy Googlebot odwiedza ważne strony.

Najpierw przygotuj listę URL, które są istotne dla sprzedaży i widoczności organicznej. Mogą to być strony kategorii, produkty z największym potencjałem, strony marek oraz wybrane treści poradnikowe. Następnie sprawdź, czy te adresy pojawiają się w logach i z jakimi kodami odpowiedzi.

Nie interpretuj samej obecności requestu jako dowodu indeksowania. Crawlowanie i indeksowanie to różne procesy. Fakt, że Googlebot pobrał stronę z kodem 200, oznacza, że otrzymał odpowiedź, ale nie gwarantuje obecności URL w wynikach wyszukiwania.

Jeżeli ważny produkt jest regularnie odwiedzany i zwraca 200, a inny produkt o podobnym znaczeniu nie pojawia się w analizowanym okresie, masz sygnał do dalszego sprawdzenia. Następnie porównaj te adresy z Search Console, sitemapą i linkami wewnętrznymi.

Kody HTTP w logach a SEO sklepu

Sam URL nie wystarczy. Każde żądanie trzeba zestawić z odpowiedzią HTTP.

Kod HTTP	Co widzisz w logu	Co sprawdzić w sklepie
200	Strona została zwrócona poprawnie	Czy adres jest właściwy i czy powinien być crawlowany
301	Stałe przekierowanie	Czy przekierowanie prowadzi do właściwego odpowiednika
302	Przekierowanie tymczasowe	Czy tymczasowy status jest rzeczywiście zamierzony
304	Treść nie została zmieniona	Czy mechanizm cache i nagłówki działają prawidłowo
404	Adres nie został znaleziony	Czy URL jest stary, błędny lub powinien zostać przekierowany
410	Zasób został usunięty	Czy świadomie używasz tego statusu dla usuniętych adresów
429	Zbyt wiele żądań	Czy ograniczenia serwera nie utrudniają crawlowania
500	Błąd aplikacji lub serwera	Co powoduje błąd i czy dotyczy ważnych URL
502	Problem z komunikacją między usługami	Czy problem dotyczy proxy, backendu lub serwera aplikacji
503	Usługa chwilowo niedostępna	Czy awarie lub przeciążenia powtarzają się podczas wizyt robotów

Szczególnie dokładnie sprawdzaj kody 5xx. Jeżeli Googlebot regularnie otrzymuje błędy serwera dla ważnych stron, problem nie jest wyłącznie kwestią SEO. Trzeba znaleźć przyczynę na poziomie hostingu, konfiguracji serwera, aplikacji, bazy danych lub zewnętrznych usług.

Kody 4xx również wymagają kontekstu. Kilka 404 dla nieistniejących, przypadkowych adresów nie musi oznaczać poważnego problemu. Zupełnie inaczej wygląda sytuacja, gdy Googlebot regularnie pobiera URL produktów, które powinny istnieć, ale serwer odpowiada 404.

Jeżeli sklep przeszedł migrację, przy okazji sprawdź także co obejmuje audyt techniczny sklepu, bo analiza logów może wtedy ujawnić błędy, które powstały po zmianie adresów, przekierowań albo struktury serwisu.

Crawl budget i marnowanie wizyt robota

Termin crawl budget bywa używany zbyt szeroko. W praktyce chodzi o zasoby, które Google przeznacza na crawlowanie konkretnej witryny, przy uwzględnieniu między innymi jej wielkości, jakości, popularności oraz możliwości technicznych serwera.

Logi pozwalają zobaczyć, gdzie te wizyty faktycznie trafiają.

W sklepie problemem może być bardzo duża liczba adresów generowanych przez filtry. Inny przykład to wyszukiwarka wewnętrzna, która tworzy wiele wariantów URL. Kolejny to parametry kampanii, sortowanie, widoki produktów, niepotrzebne kombinacje filtrów lub stare adresy pozostawione po zmianie platformy.

Nie zakładaj jednak automatycznie, że każdy parametr trzeba zablokować. Najpierw ustal, czy dany URL ma wartość dla wyszukiwania, czy jest dostępny z linków wewnętrznych, czy występuje w sitemapie oraz jaki kod odpowiedzi otrzymuje Googlebot.

Przykładowo, jeżeli log pokazuje dużą liczbę żądań do /szukaj?q=, sprawdź, czy robot może odkrywać te adresy przez linki na stronie. Jeśli tak, usuń niepotrzebne źródło linkowania albo ogranicz możliwość tworzenia takich URL. Jeżeli problem dotyczy filtrów, przeanalizuj reguły generowania adresów i to, które kombinacje powinny być dostępne dla robotów.

Google wskazuje również na znaczenie obsługi cache. Jeżeli zawartość nie zmieniła się od poprzedniego pobrania, odpowiedź 304 może pozwolić na wykorzystanie wcześniej pobranej wersji bez przesyłania całej treści. W logach możesz więc sprawdzić, czy takie odpowiedzi występują i dla jakich zasobów.

Parametry URL, filtry i strony techniczne

W sklepach internetowych właśnie tutaj często pojawia się najwięcej interesujących danych.

Zgrupuj adresy według części znajdującej się po znaku ?. Następnie wypisz najczęściej występujące parametry. Szukaj między innymi page, sort, order, filter, price, size, color, brand, q oraz parametrów charakterystycznych dla konkretnej platformy lub modułu.

Nie chodzi o stworzenie uniwersalnej czarnej listy parametrów. Każdy sklep ma inną architekturę. Jeden parametr może prowadzić do wartościowej strony docelowej, inny tylko tworzyć duplikat kategorii.

Dobrym sposobem jest stworzenie zestawienia:

parametr       liczba żądań       typ adresu              decyzja
page            wysoka            paginacja               analiza
sort            wysoka            sortowanie              ograniczenie
color           wysoka            filtr                   analiza
q               średnia           wyszukiwarka            ograniczenie

Następnie sprawdź przykładowe adresy z każdej grupy. Nie podejmuj decyzji wyłącznie na podstawie liczby requestów.

Jeżeli logi pokazują setki wariantów jednej kategorii, a tylko niewielka część tych URL ma sens biznesowy lub wyszukiwawczy, masz konkretny obszar do uporządkowania. W przypadku dużego sklepu taka analiza może być bardziej użyteczna niż ręczne przeglądanie pojedynczych adresów.

Błędy serwera, których nie widać podczas zwykłego audytu

Automatyczny crawler może przejść przez sklep poprawnie w momencie wykonywania audytu, a logi z dłuższego okresu mogą pokazać coś zupełnie innego.

Przykładem są okresowe błędy 500 występujące tylko przy określonych produktach. Mogą pojawiać się przy dużym obciążeniu, połączeniu z zewnętrzną usługą, zapytaniu do bazy danych albo uruchomieniu konkretnego modułu.

Podobnie może wyglądać problem z 502 lub 503. Jeżeli występuje sporadycznie, pojedynczy crawl może go nie złapać. Jeżeli przeanalizujesz logi z dłuższego okresu, możesz zauważyć powtarzalność związana z określoną godziną, konkretną kategorią albo konkretnym typem URL.

Zwróć też uwagę na czas obsługi żądania, jeśli konfiguracja serwera go zapisuje. Nie jest to bezpośredni sygnał rankingowy. Jest jednak bardzo użyteczny przy szukaniu miejsc, w których serwer długo odpowiada. Jeżeli Googlebot regularnie trafia na wolno obsługiwane żądania, sprawdź obciążenie, zapytania do bazy, cache i konfigurację aplikacji.

W przypadku sklepu WooCommerce może to oznaczać analizę wtyczek, zapytań do bazy i mechanizmów cache. W PrestaShop trzeba sprawdzić między innymi moduły, generowanie stron oraz obciążenie bazy. W każdym przypadku log pokazuje objaw, a nie automatycznie przyczynę.

Jak połączyć logi z Search Console i sitemapą

Najlepsza analiza nie kończy się na pliku access log. Połącz trzy źródła danych: logi serwera, sitemapę XML oraz Search Console.

Log odpowiada na pytanie, co zostało pobrane przez robota. Sitemap pokazuje, jakie adresy świadomie przekazujesz wyszukiwarce. Search Console pokazuje natomiast informacje związane z indeksowaniem i stanem adresów w systemach Google.

Jeżeli URL znajduje się w sitemapie, ale przez analizowany okres nie pojawia się w logach, sprawdź go dokładniej. Nie oznacza to automatycznie błędu. Google nie musi pobierać każdej strony z taką samą częstotliwością. Jest to jednak dobry punkt do dalszej diagnostyki.

Jeżeli URL nie znajduje się w sitemapie, ale Googlebot regularnie go odwiedza, sprawdź, skąd robot go odkrywa. Często źródłem są linki wewnętrzne, stare adresy, filtry albo inne warianty URL.

Jeszcze ciekawszy przypadek pojawia się wtedy, gdy adres zwraca 200, jest często odwiedzany, ale nie jest widoczny w oczekiwany sposób w wynikach. Wtedy trzeba przejść poza sam log i sprawdzić indeksowanie, canonical, robots meta, zawartość strony oraz inne sygnały.

Jak rozpoznać prawdziwego Googlebota

Nie filtruj logów wyłącznie po tekście Googlebot w user agencie. Ten nagłówek może zostać podszyty przez innego robota.

Google zaleca weryfikowanie takich żądań na podstawie reverse DNS albo opublikowanych zakresów adresów IP. Przy analizie ręcznej możesz wybrać adres IP z logu, wykonać odwrotne wyszukiwanie DNS, a następnie sprawdzić wynikowe nazwy i potwierdzić adres przez wyszukiwanie DNS w drugą stronę.

Dopiero po takiej weryfikacji możesz mieć większą pewność, że analizowany ruch rzeczywiście pochodzi od Google. Ma to znaczenie szczególnie wtedy, gdy logi pokazują nietypowo intensywne crawlowanie.

Jeżeli widzisz ogromną liczbę żądań przypisanych do Googlebota, nie zaczynaj od blokowania ruchu. Najpierw ustal, jakie URL są pobierane, jakie kody odpowiedzi występują i czy problem dotyczy przeciążenia serwera. Google opisuje również mechanizmy ograniczania crawlowania w sytuacjach, gdy serwer jest przeciążony.

Prosta analiza logów dla małego sklepu

Jeżeli prowadzisz mały lub średni sklep i nie chcesz budować całego systemu analitycznego, zacznij od prostego raportu.

Potrzebujesz listy URL Googlebota, liczby żądań dla każdego adresu oraz rozkładu kodów HTTP. Następnie oznacz adresy jako: produkt, kategoria, marka, wpis, filtr, parametr, wyszukiwarka, stary URL albo adres techniczny.

Po takim podziale zobaczysz, gdzie skupia się aktywność robota.

Przykładowo, jeżeli większość requestów dotyczy produktów i kategorii, a niewielka część parametrów, sytuacja jest łatwiejsza do interpretacji. Jeżeli natomiast bardzo dużo żądań trafia do kombinacji filtrów, starych URL i stron wyszukiwania, analiza powinna pójść w stronę ograniczenia zbędnych ścieżek crawlowania.

Nie musisz od razu instalować specjalistycznego systemu. Przy mniejszym sklepie wystarczy eksport logów, filtrowanie tekstowe, arkusz kalkulacyjny albo prosty skrypt. Przy dużym serwisie wygodniejsze będzie automatyczne parsowanie i agregowanie danych.

Jeżeli równolegle analizujesz strukturę treści, sprawdź też jak budować strony hubowe i treści filarowe, ponieważ logi mogą później pokazać, czy nowe sekcje serwisu rzeczywiście są odwiedzane przez roboty.

Co zrobić po znalezieniu problemu w logach

Sam raport nie naprawia sklepu. Po znalezieniu wzorca trzeba ustalić jego źródło.

Jeżeli problemem są parametry, sprawdź generowanie linków, filtry, sortowanie i wewnętrzną wyszukiwarkę. Jeżeli widzisz dużo 404, sprawdź linki wewnętrzne, stare adresy i historię migracji. Przy 301 przeanalizuj łańcuchy oraz docelowe URL. Przy 5xx przejdź do logów błędów aplikacji i serwera, zamiast poprawiać samą stronę w CMS.

Jeżeli Googlebot odwiedza nieistotne adresy, sprawdź, skąd je odkrywa. Jeżeli nie odwiedza ważnych stron, przeanalizuj ich dostępność, linkowanie wewnętrzne, sitemapę i konfigurację indeksowania.

W przypadku problemów z linkami wychodzącymi przydatna może być również analiza zepsutych linków wychodzących, ponieważ część problemów wykrytych podczas crawlowania ma źródło nie w samych logach, ale w strukturze odnośników.

Nie wprowadzaj zmian tylko dlatego, że dana grupa URL pojawia się często. Najpierw określ, czy ruch jest niepotrzebny i jaki mechanizm go powoduje. Dopiero potem wybierz rozwiązanie.

Logi serwera jako stały element kontroli technicznej

Analiza logów nie musi być zadaniem wykonywanym codziennie. Przy małym sklepie można traktować ją jako okresową kontrolę, a przy większym serwisie automatyzować najważniejsze raporty.

Największą wartość daje porównywanie okresów. Jeżeli po zmianie filtrów, migracji albo przebudowie kategorii zmienia się struktura requestów Googlebota, log pokaże ten efekt na poziomie serwera. Możesz wtedy sprawdzić, czy robot zaczął pobierać nowe warianty adresów, czy pojawiły się błędy albo czy zmieniła się częstotliwość odwiedzin konkretnych grup URL.

To również dobre uzupełnienie standardowego audytu. Crawler pokazuje stan, który sam potrafi wywołać. Logi pokazują rzeczywisty ruch robotów i użytkowników zapisany przez serwer. Połączenie obu perspektyw pozwala szybciej odróżnić problem strukturalny od problemu występującego tylko w określonych warunkach.

Jeżeli analiza logów ujawnia wiele różnych problemów technicznych, audyt SEO i techniczny sklepu internetowego może być kolejnym krokiem do uporządkowania ich według wpływu na działanie sklepu i crawlowanie.

Podsumowanie

Logi serwera dają dostęp do danych, których nie zobaczysz podczas zwykłego przeglądania sklepu. Możesz sprawdzić, jakie adresy pobiera Googlebot, jak często do nich wraca, jakie parametry generują requesty oraz jakie kody HTTP otrzymuje.

Najwięcej informacji uzyskasz wtedy, gdy nie analizujesz pojedynczych linii, lecz szukasz powtarzających się wzorców. Duża liczba żądań do parametrów, stare URL, błędy 404, okresowe 5xx, niepotrzebne przekierowania albo brak wizyt na ważnych stronach mogą wskazać miejsca wymagające dalszej diagnostyki.

Dobrze przeprowadzona analiza logów odpowiada więc nie tylko na pytanie, czy Googlebot odwiedza sklep. Pokazuje także, gdzie spędza czas i jakie odpowiedzi dostaje od serwera. To właśnie te informacje pozwalają przejść od ogólnego audytu do konkretnej diagnozy technicznej.