Analiza logów serwera strony internetowej - poradnik

Co widać w logach, a czego nie widać w innych narzędziach

• Pełna aktywność Googlebota. Search Console pokazuje statystyki indeksowania w uproszczeniu i z opóźnieniem. W logach widzę każdy pobrany adres, kod odpowiedzi i czas.
• Boty, które nie uruchamiają JavaScriptu. Narzędzia analityczne oparte na skryptach w ogóle ich nie widzą, a potrafią generować większość ruchu na serwerze.
• Błędy, które widzą tylko roboty. Przekierowania, błędy 5xx przy dużym obciążeniu czy blokady zapory często dotyczą ruchu, którego nikt w firmie nie obserwuje.
• Próby ataków. Skanowanie plików konfiguracyjnych, zgadywanie haseł i nietypowe żądania widać w logach, zanim zrobią szkodę.

Skąd biorę logi i jak je czytam

Na własnym serwerze logi dostępu są zwykle w /var/log/nginx/access.log lub /var/log/apache2/access.log. Na hostingu współdzielonym pobieram je z panelu, gdzie często są dostępne tylko z ostatnich dni, więc przy dłuższej analizie proszę o włączenie archiwizacji. Jeśli strona stoi za CDN, pamiętam, że część żądań obsługuje pamięć podręczna CDN i nigdy nie trafiają one do serwera. Pełny obraz dają wtedy dopiero logi z CDN.

Standardowy wpis w formacie Combined wygląda tak:

66.249.66.1 - - [03/Nov/2025:12:41:33 +0100] "GET /blog/wpis/ HTTP/1.1" 200 5324 "-" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) ... (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Do szybkiej analizy wystarcza mi terminal, przy większych zbiorach używam Screaming Frog Log File Analyser albo GoAccess, a przy stałym monitoringu przesyłam logi do Grafany lub Kibany.

Roboty wyszukiwarek i boty AI

Boty, które najczęściej spotykam w logach

Ruch dzielę według nazwy w nagłówku User-Agent. Te nazwy rozpoznaję najczęściej i każdą grupę analizuję osobno:

Dwie nazwy, o które często pytają klienci, w logach w ogóle się nie pojawią. Google-Extended i Applebot-Extended to wyłącznie oznaczenia do robots.txt, którymi decyduję, czy treści mogą być wykorzystane do trenowania modeli AI. Samo pobieranie stron wykonują wtedy zwykły Googlebot i Applebot. Pamiętam też, że nazwę dowolnego bota może wpisać każdy, więc tabela służy do podziału ruchu, a nie do weryfikacji.

Weryfikacja, czy Googlebot jest prawdziwy

Nazwę Googlebota w nagłówku User-Agent może wpisać każdy, a w logach dużych serwisów spora część „Googlebotów” to scrapery. Zanim wyciągnę jakiekolwiek wnioski, sprawdzam adres IP odwrotnym zapytaniem DNS, a potem zapytaniem w przód:

host 66.249.66.1
# crawl-66-249-66-1.googlebot.com
host crawl-66-249-66-1.googlebot.com
# 66.249.66.1

Prawdziwy Googlebot ma nazwę w domenie googlebot.com lub google.com, a zapytanie w przód zwraca ten sam adres IP. Przy dużych logach zamiast pojedynczych zapytań porównuję adresy z listami zakresów IP, które Google i Bing publikują w swojej dokumentacji.

Co sprawdzam w ruchu Googlebota

• które sekcje serwisu robot odwiedza najczęściej, a które pomija mimo ich wartości,
• ile żądań trafia w adresy z parametrami, filtry, sortowanie i wyniki wyszukiwania wewnętrznego,
• ile żądań kończy się przekierowaniem lub błędem, szczególnie błędem 404 i 5xx,
• czy ważne podstrony są w ogóle odwiedzane i jak szybko robot trafia na nowe treści,
• adresy obecne w logach, ale nieobecne w crawlu serwisu, czyli strony bez linków wewnętrznych.

Na dużych serwisach te dane są podstawą decyzji, od których zależy optymalizacja crawl budgetu dużej strony.

Boty AI

Ruch botów takich jak GPTBot, ClaudeBot czy PerplexityBot wyodrębniam osobno. Sprawdzam, które treści pobierają, jak często i czy nie obciążają serwera. Decyzję, czy je wpuszczać, podejmuję razem z klientem: blokada w robots.txt chroni treści przed wykorzystaniem, ale może ograniczyć obecność marki w odpowiedziach asystentów AI. Reguły dla poszczególnych botów ustawiam tak samo jak przy każdej konfiguracji robots.txt. Boty, które ignorują robots.txt, blokuję w zaporze lub CDN.

Logi a bezpieczeństwo strony

W logach szukam kilku powtarzalnych wzorców:

• seria żądań POST do wp-login.php, xmlrpc.php lub endpointu logowania API z kodami 401 i 403,
• próby pobrania plików, których nie powinno być publicznie, np. .env, .git/config, kopii bazy danych,
• skanowanie paneli, np. /phpmyadmin/, oraz adresów znanych podatnych wtyczek,
• nagły wzrost liczby żądań z jednego adresu lub od jednego nietypowego klienta, np. python-requests.

# adresy IP z największą liczbą prób logowania
grep "POST /wp-login.php" access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

# próby dostępu do plików konfiguracyjnych
grep -E "\.env|\.git/|\.sql" access.log | awk '{print $1, $7, $9}' | head -n 30

Pojedyncze skanowania są codziennością każdej strony w internecie. Działam, gdy któreś żądanie zwróciło kod 200 tam, gdzie powinno być 403 lub 404, albo gdy ruch zaczyna obciążać serwer. Wtedy łączę dane z logów z limitami prób logowania i regułami zapory, które stosuję w ramach ochrony przed atakami brute force.

Najczęstsze błędy w analizie logów

• Traktowanie każdego „Googlebota” jako prawdziwego. Bez weryfikacji adresów IP wnioski o indeksowaniu bywają całkowicie błędne.
• Mylenie wizyty robota z indeksowaniem. Log pokazuje, że robot pobrał adres, a nie że strona trafiła do indeksu.
• Analiza zbyt krótkiego okresu. Kilka dni logów nie pokaże rzadko odwiedzanych sekcji. Przy audytach biorę co najmniej miesiąc.
• Pomijanie logów z CDN. Gdy większość ruchu obsługuje pamięć podręczna CDN, logi serwera pokazują tylko jego część.
• Mieszanie ruchu. Ludzi, roboty wyszukiwarek, boty AI i narzędzia analizuję osobno, inaczej średnie nic nie mówią.

Jak organizuję analizę logów w projektach

1. Ustalam z hostingiem lub administratorem, gdzie są logi, jak długo są przechowywane i czy obejmują ruch z CDN.
2. Przy audycie pobieram co najmniej miesiąc logów i dzielę ruch na grupy.
3. Weryfikuję roboty wyszukiwarek po adresach IP.
4. Zestawiam dane z crawlem serwisu i raportami Search Console, bo dopiero porównanie trzech źródeł pokazuje problemy.
5. Przy stałej opiece ustawiam alerty na skoki błędów 5xx i liczby żądań, żeby o problemie dowiedzieć się przed klientem.

Logi zawierają adresy IP, które są danymi osobowymi. Przechowuję je tylko tak długo, jak to potrzebne, a przy przekazywaniu do analizy zewnętrznym narzędziom sprawdzam, gdzie trafiają dane. Wyniki analizy logów dołączam do każdego audytu technicznego SEO dużego serwisu.