Co log serwera potwierdza, a czego nie dowodzi?
Pojedynczy wpis potwierdza, że określona warstwa infrastruktury obsłużyła żądanie danego klienta i zwróciła zapisaną odpowiedź. Seria wpisów staje się analizą SEO dopiero po zweryfikowaniu robota, normalizacji URL-i i porównaniu ich z listą stron, które powinny być odwiedzane.
Log nie potwierdza indeksowania, oceny treści, wybranego canonicala ani pozycji. Brak wpisu jest miarodajny tylko wtedy, gdy zbiór obejmuje właściwy host, warstwę i cały badany okres.
Czym access log różni się od GSC, crawlera i analityki?
Access log rejestruje żądanie HTTP i odpowiedź serwera, natomiast pozostałe narzędzia opisują inne warstwy rzeczywistości. Nie należy nazywać logów „całą prawdą”, dopóki nie wiadomo, gdzie powstają i jakiego ruchu nie obejmują.
| Źródło | Na jakie pytanie odpowiada? | Czego nie potwierdza? |
|---|---|---|
| Access log | Czy dany klient zażądał konkretnego zasobu, kiedy to zrobił i jaką odpowiedź otrzymał? | Indeksowania, oceny treści, pozycji ani źródła, z którego Google poznało URL. |
| Crawl Stats w GSC | Jaki jest trend żądań Google, rozmiar pobrań, średni czas odpowiedzi i kondycja hosta? | Pełnej listy wszystkich żądań; pokazane URL-e są przykładami. |
| Crawler SEO | Co narzędzie może znaleźć, idąc po linkach, i jaki stan techniczny widzi w chwili audytu? | Że Googlebot rzeczywiście odwiedził te same URL-e. |
| Analityka użytkowników | Jak ludzie korzystają z witryny, jeśli pomiar został uruchomiony i nie został zablokowany? | Pełnego ruchu robotów ani odpowiedzi serwera przed wykonaniem skryptów analitycznych. |
| Error log / APM | Dlaczego aplikacja, reverse proxy lub serwer nie obsłużyły żądania poprawnie? | Kompletnego rozkładu udanych żądań bez połączenia z access logiem. |
Jak zdobyć kompletne logi do analizy SEO?
O logi poproś administratora hostingu, DevOps albo właściciela infrastruktury, wskazując hosty, okres, warstwy i wymagane pola. Ogólna prośba o „logi serwera” może zwrócić tylko pliki z originu, mimo że część odpowiedzi zakończyła się wcześniej na CDN lub WAF.
- access logi, nie tylko error logi, dla wszystkich analizowanych hostów;
- ruch z CDN/WAF, load balancera, reverse proxy i originu - zależnie od drogi żądania;
- ciągły zakres dat wraz z plikami po rotacji, również skompresowanymi;
- jednoznaczna strefa czasu oraz opis formatu, pól i ich jednostek;
- adres klienta zachowany za proxy, pełny user-agent, host, metoda, ścieżka, query string, status, bajty i czas odpowiedzi;
- status cache, status i czas originu oraz request ID, jeśli infrastruktura je udostępnia;
- informacja o brakujących dniach, próbkowaniu, filtrach i okresie retencji;
- bezpieczny sposób przekazania po usunięciu pól i identyfikatorów zbędnych dla celu SEO.
Po odebraniu danych odtwórz drogę żądania. Brak wpisu na originie nie oznacza braku wizyty, jeśli odpowiedź zwrócił cache CDN albo ruch zatrzymał WAF. Log CDN może natomiast nie wyjaśnić błędu powstałego wewnątrz aplikacji.
CDN / WAF
Żądania zakończone na brzegu sieci, blokady, cache hit/miss i odpowiedzi bez kontaktu z originem.
Martwe poleSzczegóły działania aplikacji oraz czas pracy originu, jeśli nie trafiają do osobnych pól.
Load balancer / reverse proxy
Ruch przekazany do usług, routing po hostach i instancjach oraz często czasy upstream.
Martwe poleŻądania odrzucone wcześniej przez CDN i błędy powstałe wewnątrz aplikacji.
Serwer origin
Żądania, które dotarły do Apache, Nginx lub IIS, wraz z odpowiedzią tej warstwy.
Martwe poleOdpowiedzi z cache CDN oraz ruch zatrzymany przed originem.
Aplikacja / APM
Trasę żądania, zapytania do usług, wyjątki i koszt generowania odpowiedzi dynamicznej.
Martwe poleRuch obsłużony przez cache lub serwer bez uruchomienia aplikacji.
- spisz wszystkie hosty, protokoły i warstwy, które mogą obsłużyć żądanie;
- ustal, gdzie zapisują się cache hit, blokady WAF, 429 i błędy połączenia;
- potwierdź zakres dat, strefę czasu, rotację, retencję oraz brakujące pliki;
- sprawdź, czy za proxy zapisuje się adres klienta, a nie wyłącznie pośrednika;
- porównaj sumy żądań między warstwami i wyjaśnij różnice przed agregacją;
- zachowaj informację o źródle rekordu, jeśli łączysz kilka strumieni.
Jakie pola powinien zawierać log przydatny w SEO?
Minimalny rekord musi identyfikować klienta, cel, czas i wynik żądania. Dla diagnozy wydajności warto dodać cache, upstream i identyfikator żądania. Nazwy oraz jednostki pól sprawdź w dokumentacji własnego stosu serwerowego.
| Grupa | Pola | Zastosowanie |
|---|---|---|
| Czas i strefa | timestamp z offsetem albo jednoznacznie zadeklarowane UTC | kolejność zdarzeń i porównanie z wdrożeniami |
| Klient | adres IP oraz pełny user-agent | weryfikacja robota i rozdzielenie crawlerów |
| Cel | host, metoda, ścieżka i osobno query string | rozróżnienie domen, zasobów i parametrów |
| Odpowiedź | status HTTP i liczba wysłanych bajtów | błędy, przekierowania i nietypowe odpowiedzi |
| Wydajność | łączny czas żądania oraz - jeśli możliwe - czas upstream | oddzielenie opóźnienia aplikacji od proxy |
| Trasa | cache status, upstream, instancja lub request ID | wykrycie różnic między CDN, originem i węzłami |
| Kontekst | referer, jeśli jest potrzebny i zapisywany | pomocnicza analiza, lecz nie dowód źródła odkrycia URL-a |
66.249.66.1 [17/Aug/2026:10:42:13 +0200] GET /kategoria?sort=price 200 18432 Googlebot rt=0.184 urt=0.162 cache=MISS
To przykład, nie uniwersalny standard. Pole rt może obejmować inny odcinek obsługi niż time-taken w IIS. Nie łącz wartości z różnych systemów bez sprawdzenia definicji i jednostek.
Jak sprawdzić, czy żądanie naprawdę pochodzi od Googlebota?
Prawdziwego Googlebota identyfikuje się na podstawie adresu IP, a nie samego user-agenta. Google opisuje dwukierunkową weryfikację DNS dla pojedynczych adresów oraz dopasowanie do publikowanych zakresów CIDR przy analizie masowej.
- Wykonaj reverse DNS dla IP z logu.Odczytaj nazwę hosta przypisaną do adresu klienta.
- Sprawdź zakończenie domeny.Dla odpowiednich typów żądań musi to być
googlebot.com,google.comalbogoogleusercontent.com. - Wykonaj forward DNS otrzymanej nazwy.Wynik musi prowadzić z powrotem do pierwotnego adresu IP.
- Przy dużej skali użyj oficjalnych list IP.Pobieraj aktualne pliki JSON Google i dopasowuj IP do zakresów CIDR właściwej kategorii.
Oddziel popularne roboty, roboty specjalne i moduły pobierania uruchamiane przez użytkownika. Nie każda aktywność innego modułu Google opisuje automatyczny crawl wyszukiwarki.
Jak przejść od surowych żądań do kohort URL-i?
Surowy log jest listą zdarzeń, nie raportem SEO. Najpierw zachowaj rekord źródłowy, oczyść format i przypisz adresy do typów stron. Dopiero wtedy odróżnisz częsty crawl wartościowej kategorii od tysięcy wariantów tej samej ścieżki.
- ujednolić host, protokół i wielkość liter tylko tam, gdzie architektura uznaje je za równoważne;
- rozbić ścieżkę i query string, a parametry sklasyfikować jako funkcjonalne, filtrujące, śledzące lub losowe;
- odkodować adres w kontrolowany sposób, bez przypadkowego scalenia dwóch różnych URL-i;
- oddzielić dokumenty HTML od obrazów, CSS, JavaScriptu, fontów i wywołań API;
- przypisać każdy URL do typu strony, np. kategoria, produkt, artykuł, filtr, paginacja lub zasób;
- zachować zarówno surowy URL, jak i wersję znormalizowaną, aby agregacja nie usuwała śladu dowodowego.
- usługi, kategorie, produkty aktywne i wycofane;
- nowe publikacje, treści aktualizowane i dokumenty niezmieniane;
- URL-e z sitemapy, poza sitemapą, podlinkowane i osierocone;
- adresy kanoniczne, przekierowane, błędne oraz z parametrami;
- dokumenty HTML, zasoby renderujące i wywołania API;
- hosty, wersje językowe, rynki oraz szablony aplikacji.
Reguły kohort powinny pochodzić z architektury serwisu, nie tylko z prefiksu katalogu. Jeśli dwa typy stron mają ten sam wzorzec URL, dołącz identyfikator szablonu albo dane z CMS.
Jakie metryki z logów mają znaczenie dla SEO?
Metryka jest użyteczna dopiero wtedy, gdy ma mianownik, kohortę i okres. Sama liczba żądań Googlebota nie określa jakości crawlu: może rosnąć, bo robot częściej pobiera błędy, parametry albo te same zasoby.
| Metryka | Jak ją segmentować? | Co pozwala sprawdzić? |
|---|---|---|
| Żądania i unikalne URL-e | osobno dla robota, hosta, zasobu i kohorty | Czy wzrost pobrań oznacza większe pokrycie, czy tylko wizyty na tych samych adresach? |
| First seen / last seen / dni z wizytą | w tym samym, kompletnym oknie retencji | Jak szybko robot dociera do nowych URL-i i czy wraca do aktualizowanych stron? |
| Udział 2xx, 3xx, 4xx, 5xx i 429 | żądania danej kohorty, nie cały ruch serwera | Które typy stron generują przekierowania, braki, awarie lub ograniczanie ruchu? |
| Czas odpowiedzi p50, p75 i p95 | ten sam typ URL-a, warstwa i status cache | Czy problem dotyczy typowego żądania, czy wolnego ogona i konkretnego szablonu? |
| Udział parametrów i zasobów | wszystkie zweryfikowane żądania danego robota | Jaka część aktywności trafia do dokumentów priorytetowych, a jaka do alternatywnej przestrzeni URL-i? |
| Pokrycie URL-i priorytetowych | aktualny inwentarz stron, które mają być crawlable | Których ważnych adresów nie ma w logach mimo pełnego okresu obserwacji? |
Jak zamienić wzorzec w logach na właściwe działanie?
Log pokazuje objaw na poziomie żądania. Aby wybrać naprawę, trzeba dołączyć źródło opisujące architekturę, rolę URL-a albo błąd aplikacji. Macierz oddziela dowód od hipotezy i działania.
| Wzorzec | Co potwierdzają logi? | Co sprawdzić dalej? | Działanie |
|---|---|---|---|
| URL-e priorytetowe nie pojawiają się w logach | Kompletny okres i właściwa warstwa, a w kohorcie brakuje żądań zweryfikowanego Googlebota. | Porównaj inwentarz z linkami, sitemapą, crawl depth i stanem hosta w GSC. | Napraw ścieżkę odkrycia lub priorytet grupy; sam brak żądania nie wskazuje jednej przyczyny. |
| Dużo żądań do filtrów, sortowań i parametrów | Znaczna część żądań trafia do powtarzalnych kombinacji poza listą docelowych stron. | Sprawdź, gdzie powstają linki, które parametry zmieniają treść i czy kombinacje mają rolę w wyszukiwarce. | Ogranicz generowanie zbędnych ścieżek; zachowaj filtry z realnym popytem i funkcją. |
| Googlebot często trafia na 3xx lub stare adresy | Powtarzają się żądania do URL-i źródłowych zamiast bezpośrednich wejść na cel. | Połącz źródłowe URL-e z mapą przekierowań, linkami wewnętrznymi i sitemapami. | Aktualizuj sygnały do finalnego adresu i skracaj łańcuchy, zamiast oceniać sam udział 3xx. |
| Nagły wzrost 404 lub 5xx | Zmiana zaczyna się w określonej godzinie, na konkretnym hoście, instancji albo typie strony. | Skoreluj request ID i czas z wdrożeniem, error logiem, APM, CDN oraz monitoringiem. | Napraw przyczynę w warstwie, która zwróciła odpowiedź, a potem potwierdź zanik wzorca. |
| Ważna kohorta ma wolny ogon odpowiedzi | Mediana pozostaje stabilna, lecz p95 rośnie dla jednego szablonu, upstreamu lub cache miss. | Rozdziel status cache, czas proxy, czas aplikacji i wielkość odpowiedzi. | Optymalizuj źródło opóźnienia i oceniaj zmianę względem własnej linii bazowej. |
| Crawler i Googlebot widzą różne zbiory URL-i | Są adresy tylko w crawlu własnym oraz takie, które występują wyłącznie w logach robota. | Zbadaj orphan pages, stare sitemapy, linki zewnętrzne, historyczne adresy i parametry. | Zdecyduj: włączyć URL do architektury, przekierować, zwrócić 404/410 albo ograniczyć źródło. |
Jak połączyć logi z crawlami, sitemapą, GSC i CMS?
Największa wartość powstaje po złączeniu zdarzeń z oczekiwanym zbiorem stron. Log powie, co się wydarzyło. Inwentarz, crawler i mapa witryny pokażą, co miało się wydarzyć oraz jak robot mógł dotrzeć do adresu.
| Połączenie | Obserwacja | Wniosek do sprawdzenia |
|---|---|---|
| Log + inwentarz CMS | strona istnieje i ma rolę, ale nie ma żądania | luka pokrycia crawlem |
| Log + crawl po linkach | Googlebot zna URL, którego crawler nie znalazł | orphan page, stary link lub alternatywna przestrzeń URL-i |
| Log + sitemap | adres w mapie otrzymuje 3xx, 4xx lub nie pojawia się w okresie obejmującym typowy cykl powrotów robota | niespójność deklaracji z rzeczywistą obsługą |
| Log + GSC | zmiana aktywności zbiega się z błędami hosta lub statusem indeksowania | korelacja do weryfikacji, nie automatyczna przyczynowość |
| Log + mapa przekierowań | robot nadal pobiera stare URL-e po migracji | niezaktualizowane źródła lub wygaszanie znanych adresów |
| Log + APM / error log | żądanie kończy się 5xx lub wysokim czasem | konkretna usługa, wyjątek albo wąskie gardło |
Przykład - od wpisu w logu do decyzji po migracji
- Zbierz i zweryfikuj zdarzeniaW modelowym, kompletnym eksporcie z 14 dni znajduje się 120 żądań zweryfikowanego Googlebota do /stara-kategoria. Warstwa edge zwraca 301 do /nowa-kategoria.
- Znormalizuj i przypisz kohortęZdarzenia trafiają do grupy „stare adresy po migracji”. Ruch użytkowników, zasoby i inne roboty nie wchodzą do mianownika tej kohorty.
- Połącz dane o źródłach URL-aCrawl własny i eksport z CMS pokazują, że stary adres nadal występuje w breadcrumbach, a sitemap zawiera go zamiast finalnego URL-a.
- Oddziel dowód od interpretacjiLogi potwierdzają powtarzalne żądania i odpowiedź 301. Crawl oraz sitemap potwierdzają dwa kontrolowane przez serwis źródła starego adresu, lecz nie dowodzą, że Google nie zna go także z historii lub linków zewnętrznych.
- Wdróż zmianę i zmierz wynikZmień linki i sitemapę na finalny URL. Po wdrożeniu mierz spadek żądań do starej ścieżki oraz wzrost bezpośrednich wejść robota na nową; nie oczekuj natychmiastowego wyzerowania ruchu historycznego.
Ogólny mechanizm odkrywania URL-i, crawlability i crawl budgetu ma osobny zakres w przewodniku po crawlingu w SEO. Tutaj istotne jest to, jak potwierdzić zachowanie robota i odróżnić brak obserwacji od błędu zbierania danych.
Jak użyć logów przy migracji i stałym monitoringu SEO?
Przy migracji albo dużym wdrożeniu logi tworzą pomiar przed i po zmianie. Porównuj te same kohorty i zachowaj moment wdrożenia, aby nie pomylić sezonowości lub zwykłego cyklu crawlu z efektem nowej architektury.
- zapisz linię bazową dla tych samych typów stron, hostów i dni tygodnia, które porównasz po zmianie;
- oznacz dokładny moment wdrożenia i rozdziel ruch na stare oraz nowe adresy;
- mierz, czy Googlebot przechodzi ze starych URL-i na finalne, nie tylko czy rośnie łączna liczba żądań;
- sprawdzaj łańcuchy, pętle, 404, 5xx, hosty i protokoły pominięte w planie migracji;
- porównuj kohorty publikowane lub przenoszone razem, zamiast wybierać kilka wygodnych przykładów;
- utrzymaj obserwację dostatecznie długo, aby objąć zwykły cykl powrotów robota do danej sekcji.
Jak dobrać narzędzie do skali?
Jednorazowy, mały wycinek
Arkusz, terminal lub Screaming Frog Log File AnalyserDane mają ograniczony rozmiar, a wynik nie musi odświeżać się automatycznie. Analizator desktopowy ułatwia import kilku formatów, weryfikację botów i połączenie zdarzeń z listą URL-i.
Powtarzalna analiza wielu plików
BigQuery albo inna hurtownia SQLPotrzebujesz tych samych kohort, połączeń źródeł i porównań okres do okresu. Ładowanie wsadowe pasuje do plików dostarczanych cyklicznie, a nie do monitoringu w czasie rzeczywistym.
Stały monitoring dużego serwisu
Elastic/ELK, Splunk albo platforma obserwowalnościLiczą się retencja, kontrola dostępu, alerty, duży wolumen i ciągłe zasilanie danymi z CDN, proxy, serwera oraz aplikacji.
- zanik żądań zweryfikowanego Googlebota na ważnym hoście lub szablonie;
- wzrost 5xx, 429 albo 404 w konkretnej kohorcie;
- odchylenie p95 czasu odpowiedzi przy stabilnej liczbie żądań;
- nowy wzorzec parametrów lub szybko rosnąca przestrzeń URL-i;
- spadek pokrycia nowych i aktualizowanych stron;
- powrót starych hostów lub ścieżek po migracji.
Jak chronić dane i nie wyciągać z logów zbyt mocnych wniosków?
Logi mogą zawierać adresy IP użytkowników, identyfikatory w query stringach, ścieżki konta i referery, których analiza SEO nie potrzebuje. Zakres zbierania, dostęp, retencję i przekazanie do zewnętrznego narzędzia uzgodnij z właścicielem infrastruktury oraz osobą odpowiedzialną za bezpieczeństwo i ochronę danych.
Minimalizacja
Zachowuj tylko potrzebne pola, maskuj dane użytkowników i usuń sekrety lub identyfikatory przed eksportem.
Dostęp i transfer
Ogranicz uprawnienia, szyfruj pliki i unikaj wysyłania surowych logów do przypadkowych usług oraz modeli AI.
Retencja
Ustal okres wystarczający do porównań SEO, lecz nie przechowuj danych bezterminowo tylko dlatego, że mogą się kiedyś przydać.
Powtarzalność
Zapisz źródła, zakres dat, filtry, wersję list IP, strefę czasu i reguły kohort, aby wynik dało się odtworzyć.
FAQ - analiza logów serwera w SEO
01Co to jest analiza logów serwera w SEO?
To filtrowanie i łączenie zapisów żądań HTTP, aby sprawdzić, które zasoby rzeczywiście pobierały zweryfikowane roboty wyszukiwarek, jak często to robiły oraz jakie statusy i czasy odpowiedzi otrzymywały. Wyniki analizuje się według typów URL-i i zestawia z inwentarzem strony, crawlami, sitemapami oraz GSC.
02Skąd pobrać logi serwera do analizy SEO?
Poproś hosting, administratora lub zespół DevOps o access logi dla analizowanych hostów i ciągłego zakresu dat. Ustal wcześniej, czy żądania może kończyć CDN lub WAF; wtedy sam log originu będzie niepełny. Eksport powinien zawierać co najmniej czas ze strefą, IP klienta, user-agent, host, metodę, ścieżkę, query string, status i czas odpowiedzi.
03Czy logi serwera pokazują, że strona jest zaindeksowana?
Nie. Log potwierdza żądanie i odpowiedź w określonym czasie oraz warstwie infrastruktury. Nie pokazuje, czy Google przetworzyło treść, wybrało adres kanoniczny, dodało dokument do indeksu lub przyznało mu pozycję.
04Jak rozpoznać prawdziwego Googlebota w logach?
Nie wystarczy tekst Googlebot w user-agencie. Dla pojedynczego IP wykonaj reverse DNS, sprawdź właściwą domenę Google, a potem forward DNS, który musi zwrócić pierwotne IP. Przy analizie masowej dopasuj adresy do aktualnych zakresów IP publikowanych przez Google.
05Z jakiego okresu analizować logi?
Okres musi obejmować naturalny cykl odwiedzin badanej sekcji i być kompletny na wszystkich istotnych warstwach. Migrację porównuj na równoważnych okresach przed i po zmianie, uwzględniając dni tygodnia i sezonowość.
06Czy brak URL-a w logach oznacza, że Googlebot go nie odwiedził?
Tylko jeśli masz kompletne logi z właściwego hosta i warstwy, obejmujące cały badany okres, oraz poprawnie zweryfikowałeś robota. CDN może obsłużyć żądanie bez originu, rotacja usunąć plik, a błąd strefy czasu lub parsera ukryć wpis.
07Jak często wykonywać analizę logów?
Jednorazowo przy audycie można zbudować linię bazową, ale duży lub często zmieniany serwis wymaga stałego monitoringu. Alerty oprzyj na odchyleniu od własnego wzorca, a nie na uniwersalnym progu dla wszystkich witryn.
08Jakie narzędzie do analizy logów wybrać?
Wybór zależy od wolumenu, częstotliwości i polityki bezpieczeństwa. Mały plik można zbadać w arkuszu albo analizatorze desktopowym. Powtarzalne analizy lepiej przenieść do SQL lub hurtowni, a ciągły monitoring do systemu log management z retencją, kontrolą dostępu i alertami.
Masz logi, ale nie wiesz, które wzorce naprawdę wymagają działania?
Połączymy żądania zweryfikowanych botów z inwentarzem URL-i, crawlami, sitemapami i GSC. Otrzymasz diagnozę, priorytety wdrożenia i mierniki efektu.
Źródła techniczne
- Google - weryfikacja żądań przez DNS i zakresy IP
- Google Search Console - zakres raportu Statystyki indeksowania
- Google - crawl capacity, crawl demand i optymalizacja crawlowania
- Nginx - konfiguracja access logu
- Apache HTTP Server - access log i error log
- Microsoft IIS - pola, formaty, czas i rotacja logów
- Cloudflare Logs - pola żądania, odpowiedź edge i odpowiedź originu
- Screaming Frog Log File Analyser - formaty importu, weryfikacja botów i łączenie danych URL-i
- Google Cloud BigQuery - wsadowe i ciągłe ładowanie danych
- Elastic Logstash - ciągłe odczytywanie zdarzeń z plików
- cPanel - pobieranie i archiwizowanie surowych logów dostępu
- EUR-Lex - RODO i identyfikatory internetowe