Analiza logów serwera pod kątem SEO

TL;DR: Google Search Console pokazuje to, co Google chce, żebyś widział. Logi serwera pokazują, co Googlebot naprawdę zrobił. Odkryłem, że Googlebot przeznaczał 73% swojego crawl budgetu na parametryczne adresy URL, o których dawno zapomnieliśmy. GSC nie sygnalizowało żadnego problemu. Oto jak skonfigurować analizę logów, czego szukać i dlaczego to najbardziej niedoceniana technika w technicznym SEO.

GSC kłamie przez pominięcie

Google Search Console to fantastyczne narzędzie. Korzystam z niego codziennie. Ale ma fundamentalny problem: pokazuje tylko to, co Google zdecydowało się ujawnić.

Statystyki crawlowania w GSC podają zagregowane liczby — łączną liczbę żądań, średni czas odpowiedzi, część kodów statusu. Czego nie powiedzą, to które konkretne adresy URL Googlebot odwiedził, w jakiej kolejności, ile trwało każde żądanie, czy Googlebot wrócił na drugi przebieg, żeby wyrenderować JavaScript, i które sekcje Twojej witryny całkowicie ignoruje.

To jest ta luka. I jest ogromna.

Logi serwera to niefiltrowana prawda. Każde żądanie Googlebota do Twojego serwera jest rejestrowane z dokładnym znacznikiem czasu, adresem URL, kodem statusu, czasem odpowiedzi i ciągiem user agent. Bez podsumowań, bez próbkowania, bez Google decydującego, co musisz wiedzieć. Surowe dane.

Powiem szczerze: ignorowałem analizę logów przez pierwsze dwa lata prowadzenia SEOJuice. Wydawało mi się, że to coś dla korporacyjnych specjalistów SEO z sześciocyfrowymi kontraktami na Botify. Myliłem się. W momencie, gdy zacząłem parsować nasze własne logi Nginx, odkryłem problemy, które GSC ukrywało przez miesiące. Marnowanie crawl budgetu na facetowane adresy URL. Błędy 5xx, które pojawiały się tylko w trakcie wzorców crawlowania Googlebota. Nowe wpisy blogowe, których Googlebot nie odwiedził od trzech tygodni.

Na podstawie tego, co widziałem na setkach witryn: z mojego doświadczenia wynika, że niemal każda witryna z ponad 500 stronami ma co najmniej jeden poważny problem z crawlowaniem, który ujawni tylko analiza logów.

Co naprawdę zawiera log serwera

Rozbierzmy to na czynniki pierwsze:

Różne serwery WWW stosują nieco odmienne formaty. „Combined Log Format” Apache’a jest niemal identyczny z formatem Nginx. IIS korzysta z formatu rozszerzonego W3C z polami oddzielonymi spacjami i nagłówkiem definiującym kolumny. Dane są te same — różni się układ.

Kluczowe pola dla SEO to: user agent (do filtrowania botów), URL (żeby widzieć, co jest crawlowane), kod statusu (do wykrywania błędów) i czas odpowiedzi (do znajdowania wąskich gardeł wydajności).

User agenci, których musisz znać

Nie każde żądanie Googlebota to ten sam crawler. Google używa różnych user agentów do różnych celów, a ich rozróżnianie ma znaczenie.

Bot renderujący jest szczególnie istotny. Kiedy Googlebot po raz pierwszy crawluje stronę, pobiera surowy HTML. Jeśli strona zawiera JavaScript, Google kolejkuje drugie żądanie przez Web Rendering Service (WRS), który korzysta z bezgłowej przeglądarki Chrome. To drugie żądanie pojawia się w Twoich logach z ciągiem user agent Chrome.

Jeśli widzisz początkowe trafienie Googlebota, ale nigdy przebieg renderowania Chrome na stronie z dużą ilością JS, Google prawdopodobnie nie widzi pełnej treści. To jest niewidoczne w GSC. Tylko analiza logów to ujawnia.

Konfiguracja logów pod analizę SEO

Większość domyślnych konfiguracji Nginx i Apache loguje wystarczająco danych do podstawowej analizy. Ale „podstawowa” to za mało. Chcesz mieć czas odpowiedzi, a większość domyślnych ustawień go nie rejestruje.

Oto format logów Nginx, którego używam. Dodaj go do bloku http w nginx.conf:

log_format seo_analysis '$remote_addr - $remote_user [$time_local] '
                        '"$request" $status $body_bytes_sent '
                        '"$http_referer" "$http_user_agent" '
                        '$request_time $upstream_response_time';

access_log /var/log/nginx/access.log seo_analysis;

Dwa kluczowe dodatki: $request_time (łączny czas od żądania do odpowiedzi) i $upstream_response_time (jak długo Twój serwer aplikacji przetwarzał żądanie, bez narzutu Nginx). Różnica między tymi dwiema wartościami mówi, czy wąskim gardłem jest Twoja aplikacja, czy warstwa proxy.

Dla Apache dodaj %D (czas żądania w mikrosekundach) do dyrektywy LogFormat:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D" seo_combined
CustomLog /var/log/apache2/access.log seo_combined

Problem z CDN

Tu robi się irytująco. Jeśli stoisz za Cloudflare, Bunny CDN, Fastly lub innym CDN, logi Twojego serwera źródłowego pokazują tylko żądania, które przeszły przez cache. Idealnie zcachowana strona może być crawlowana przez Googlebota 50 razy, a Twój serwer źródłowy widzi zero tych żądań.

Potrzebujesz logów na poziomie CDN:

• Cloudflare: Plan Enterprise zawiera pełny Logpush do S3, R2 lub Datadog. Plany Business i Pro dają próbkowane logi przez dashboard. Plan darmowy — nie masz szczęścia.
• Bunny CDN: Surowe logi dostępne na wszystkich planach. Pobieranie przez API lub dashboard. To jeden z powodów, dla których lubię Bunny.
• Fastly: Strumieniowanie logów w czasie rzeczywistym do Twojego własnego endpointu. Elastyczne, ale wymaga konfiguracji.
• AWS CloudFront: Logi standardowe i w czasie rzeczywistym do S3. Łatwe do włączenia.

Jeśli Twój CDN nie oferuje logowania na poziomie botów w Twoim planie, możesz ustawić regułę, która pomija cache dla znanych user agentów botów. Zmusza to żądania botów do trafienia na serwer źródłowy, gdzie możesz je logować. Kompromis to nieco wyższe obciążenie serwera źródłowego podczas crawlowania.

Nie jestem do końca pewien, czy ten kompromis opłaca się dla mniejszych witryn. Jeśli dostajesz 200 żądań Googlebota dziennie, dodatkowe obciążenie serwera źródłowego z pominięcia cache jest znikome. Jeśli dostajesz 200 000, dobrze przemyśl swoją infrastrukturę, zanim klikniesz ten przełącznik.

Rotacja i przechowywanie logów

Logi rosną szybko. Witryna z 10 000 wizyt dziennie generuje mniej więcej 2-5 MB logów dostępowych dziennie. W skali roku to 700 MB do 1,8 GB nieskompresowanych. Po zgzipowaniu może 50-100 MB.

Do analizy SEO potrzebujesz minimum 90 dni logów. Idealnie 6 miesięcy, żebyś mógł zobaczyć sezonowe wzorce crawlowania i skorelować je z aktualizacjami algorytmu. Skonfiguruj logrotate (Linux) lub cron joba do kompresji i archiwizacji logów co tydzień. Usuwaj wszystko starsze niż 6 miesięcy, chyba że masz konkretny powód, żeby to trzymać.

Parsowanie logów Pythonem: praktyczny przewodnik

Chcę poświęcić tę sekcję pamięci nieżyjącego Hamleta Batisty, który był pionierem użycia Pythona do analizy logów SEO i automatyzacji. Hamlet odszedł w 2020 roku, ale jego praca — szczególnie jego teksty o wykorzystaniu Pythona i notebooków Jupyter w technicznym SEO — fundamentalnie zmieniła podejście naszej branży do problemów z danymi. Wiele z tego, co poniżej, opiera się na wzorcach, których nauczył społeczność SEO.

Oto prosty skrypt w Pythonie, który filtruje logi Nginx pod kątem żądań Googlebota i generuje metryki, które naprawdę mają znaczenie dla SEO. Jest zbliżony do tego, co uruchomiłem na logach SEOJuice.com.

import re
import csv
from collections import Counter, defaultdict
from datetime import datetime

LOG_PATTERN = re.compile(
    r'(?P<ip>\S+) \S+ \S+ '
    r'\[(?P<timestamp>[^\]]+)\] '
    r'"(?P<method>\S+) (?P<url>\S+) \S+" '
    r'(?P<status>\d{3}) (?P<size>\d+) '
    r'"[^"]*" "(?P<ua>[^"]*)" '
    r'(?P<response_time>[\d.]+)?'
)

GOOGLEBOT_PATTERN = re.compile(r'Googlebot|Google-InspectionTool', re.IGNORECASE)

def parse_log(filepath):
    """Parse Nginx log, return only Googlebot requests."""
    results = []
    with open(filepath, 'r') as f:
        for line in f:
            match = LOG_PATTERN.match(line)
            if not match:
                continue
            if not GOOGLEBOT_PATTERN.search(match.group('ua')):
                continue
            results.append({
                'ip': match.group('ip'),
                'timestamp': match.group('timestamp'),
                'url': match.group('url'),
                'status': int(match.group('status')),
                'size': int(match.group('size')),
                'ua': match.group('ua'),
                'response_time': float(match.group('response_time') or 0),
            })
    return results

def analyze(requests):
    """Generate SEO-relevant metrics from Googlebot requests."""
    url_counts = Counter(r['url'] for r in requests)
    status_counts = Counter(r['status'] for r in requests)
    slow_urls = [
        (r['url'], r['response_time'])
        for r in requests if r['response_time'] > 1.0
    ]

    # Section-level crawl distribution
    section_counts = Counter()
    for r in requests:
        parts = r['url'].strip('/').split('/')
        section = parts[0] if parts and parts[0] else '(root)'
        section_counts[section] += 1

    print(f"Total Googlebot requests: {len(requests)}")
    print(f"\n--- Status Code Distribution ---")
    for code, count in status_counts.most_common():
        pct = (count / len(requests)) * 100
        print(f"  {code}: {count} ({pct:.1f}%)")

    print(f"\n--- Top 20 Most Crawled URLs ---")
    for url, count in url_counts.most_common(20):
        print(f"  {count:>5}x  {url}")

    print(f"\n--- Crawl Distribution by Section ---")
    total = len(requests)
    for section, count in section_counts.most_common(10):
        pct = (count / total) * 100
        print(f"  /{section}/: {count} ({pct:.1f}%)")

    print(f"\n--- Slow Responses (>1s) ---")
    for url, time in sorted(slow_urls, key=lambda x: -x[1])[:10]:
        print(f"  {time:.2f}s  {url}")

if __name__ == '__main__':
    requests = parse_log('/var/log/nginx/access.log')
    analyze(requests)

To jakieś 60 linii kodu. Napisałem to w 20 minut. A wynik natychmiast pokazał, że Googlebot bombardował naszą sekcję /tools/ (73% wszystkich żądań crawlowania), jednocześnie ledwo dotykając nowych wpisów na blogu. Co wyjaśniało, dlaczego nasze nowe treści nie były indeksowane tygodniami.

Dla większych witryn lub ciągłego monitorowania potrzebujesz czegoś bardziej solidnego. Stos ELK (Elasticsearch, Logstash, Kibana) to standard branżowy do agregacji logów na dużą skalę. Logstash wczytuje i parsuje logi, Elasticsearch je indeksuje pod szybkie zapytania, a Kibana daje dashboardy. Jest potężny, ale niebanalny w konfiguracji — zarezerwuj dzień lub dwa na początkowe ustawienie.

Sześć metryk, które naprawdę się liczą

Sekcja /tools/ miała dziesiątki kombinacji parametrów (filtry, opcje sortowania, paginacja) generujących tysiące crawlowalnych adresów URL. Googlebot sumiennie crawlował je wszystkie. Tymczasem nasz blog — sekcja, która faktycznie napędza ruch organiczny — otrzymywał 11% uwagi crawlera.

Rozwiązaniem była kombinacja tagów canonical, reguł robots.txt i noindex na wariantach parametrycznych. Zrestrukturyzowaliśmy też linkowanie wewnętrzne, żeby lepiej odzwierciedlało nasze silosy treści. W ciągu dwóch tygodni częstotliwość crawlowania bloga podwoiła się. Nowe posty zaczęły być indeksowane w ciągu dni zamiast tygodni.

Tego nie zobaczysz w GSC. GSC podaje łączną liczbę żądań crawlowania. Nie rozbija ich na sekcje ani nie pokazuje problemu z dystrybucją.

2. Rozkład kodów statusu

Zagreguj kody statusu ze wszystkich żądań Googlebota. Oto jak wygląda zdrowy rozkład:

• 200 (OK): Powinno stanowić 85-95% wszystkich żądań
• 301/302 (Przekierowania): Poniżej 10%. Jeśli więcej, masz łańcuchy przekierowań lub stare adresy URL wciąż crawlowane
• 304 (Nie zmodyfikowano): Normalne, oznacza, że Googlebot sprawdził i strona się nie zmieniła
• 404 (Nie znaleziono): Poniżej 5%. Jeśli więcej, marnujesz crawl budget na martwe strony
• 500/503 (Błędy serwera): Powinno być bliskie zeru. Jakikolwiek skok to sytuacja awaryjna

Widziałem kiedyś witrynę, gdzie 22% żądań Googlebota zwracało 404. Poprzedni deweloper usunął kategorię produktów bez przekierowania. Googlebot miał te adresy URL w swojej kolejce crawlowania i ciągle próbował je pobierać. Dwadzieścia dwa procent crawl budgetu, spalone na stronach, które nie istniały. Przez osiem miesięcy.

3. Czas odpowiedzi per URL

Google wielokrotnie powtarzał, że szybkość strony jest czynnikiem rankingowym. Ale Core Web Vitals (które raportuje GSC) mierzą wydajność po stronie klienta. Czas odpowiedzi serwera — jak długo Twój serwer generuje i wysyła HTML — to inna sprawa, i pojawia się tylko w logach.

Czego szukasz: każdy URL, gdzie czas odpowiedzi konsekwentnie przekracza 500 ms. Powyżej 1 sekundy to problem. Powyżej 2 sekund i Googlebot może całkowicie porzucić żądanie.

Posortuj żądania Googlebota po czasie odpowiedzi, malejąco. Najwolniejsze adresy URL zwykle wpadają w kilka kategorii: strony obciążone bazą danych (listy produktów ze złożonymi filtrami), strony wykonujące zewnętrzne wywołania API podczas renderowania lub strony generujące duże odpowiedzi (mapy witryn, feedy).

4. Wzorce głębokości crawlowania

Ile kliknięć od strony głównej potrzebuje Googlebot, żeby dotrzeć do strony? Tego nie ma bezpośrednio w danych logów, ale możesz to wywnioskować, patrząc na znaczniki czasu i wzorce odsyłaczy.

Jeśli Googlebot trafia na Twoją stronę główną o 09:00, na główne strony kategorii o 09:01 i na głęboką stronę produktu o 09:14 — ta 14-minutowa przerwa sugeruje, że strona jest głęboko zagnieżdżona. Strony, które Googlebot odkrywa późno w sesji crawlowania, dostają mniej uwagi.

Prostsze podejście: porównaj zbiór adresów URL, które Googlebot zcrawlował, z pełną mapą witryny. Każdy URL w mapie witryny, którego Googlebot nie odwiedził przez ponad 30 dni, jest z perspektywy Google faktycznie osierocony, niezależnie od tego, co mówi Twoje linkowanie wewnętrzne.

5. Proporcje ruchu botów do ludzi

To jest metryka bezpieczeństwa i wydajności w takim samym stopniu, jak metryka SEO. Przefiltruj logi po user agencie i oblicz, jaki procent wszystkich żądań pochodzi od botów, a jaki od prawdziwych użytkowników.

Na większości witryn boty odpowiadają za 30-50% wszystkich żądań. Jeśli boty stanowią ponad 80%, prawdopodobnie ktoś Cię scrapuje lub jesteś atakowany przez złośliwe boty marnujące zasoby serwera. Jeśli konkretnie Googlebot stanowi mniej niż 5% Twojego ruchu botowego, coś innego pochłania pojemność Twojego serwera i potencjalnie spowalnia zdolność Google do crawlowania Ciebie.

6. Strony osierocone — co Googlebot nigdy nie odwiedza

To może być najcenniejsza analiza, jaką możesz przeprowadzić. Weź listę adresów URL ze swojej mapy witryny lub CMS. Porównaj ją z listą adresów URL, które Googlebot odwiedził w ciągu ostatnich 90 dni. Każdy URL, którego Googlebot nie tknął, jest funkcjonalnie niewidoczny.

Typowe przyczyny: strona nie ma żadnych linków wewnętrznych prowadzących do niej (prawdziwa strona osierocona), strona jest zbyt głęboko w architekturze witryny lub strona jest zablokowana przez zapomnianą regułę w robots.txt.

Naprawdę nie rozumiem, dlaczego więcej specjalistów SEO nie robi tej analizy regularnie. Zajmuje 10 minut z powyższym skryptem w Pythonie i listą Twoich adresów URL. Za każdym razem, gdy przeprowadzałem ją dla klienta, znajdowaliśmy strony, które miały być ważne, ale nie były crawlowane od miesięcy.

Prawdziwe wzorce, które powinny Cię zaniepokoić

Teoria jest miła. Oto faktyczne problemy, które znalazłem dzięki analizie logów, na prawdziwych witrynach, a które w innym wypadku pozostałyby niewykryte.

Pułapka parametrycznych adresów URL

Już wspominałem o naszym doświadczeniu. Ale warto to podkreślić: facetowana nawigacja, parametry wyszukiwania, opcje sortowania i paginacja tworzą wykładniczą liczbę crawlowalnych adresów URL. Katalog produktów z 500 produktami, 8 kategoriami filtrów i 3 opcjami sortowania może wygenerować dziesiątki tysięcy adresów URL. Googlebot będzie próbował crawlować je wszystkie.

Według opublikowanych badań Botify dotyczących crawl budgetu (2023), na dużych witrynach e-commerce nawet 80% crawl budgetu Googlebota może być pochłaniane przez parametryczne adresy URL, które dostarczają niemal identyczną treść — choć dokładna liczba różni się znacząco w zależności od typu witryny i architektury. Ich CTO, Adrien Menard, pisał obszernie na ten temat: problem crawl budgetu na dużych witrynach nie polega na tym, żeby Google crawlował więcej — polega na tym, żeby powstrzymać Google przed marnowaniem crawli na niskowartościowe adresy URL.

Cichy problem 5xx

Jeden klient miał sporadyczne błędy 503, które pojawiały się tylko podczas serii crawlowania Googlebota. Jego monitoring (Pingdom, UptimeRobot) pokazywał 99,9% uptime, bo te narzędzia sprawdzają raz na minutę z jednej lokalizacji. Googlebot uderza w 10-50 stron szybko po sobie. Serwer nie wytrzymywał skoków, zwracał błędy 503 dla około 15% żądań Googlebota i dochodził do siebie w ciągu sekund.

Statystyki crawlowania w GSC pokazywały nieco podwyższony wskaźnik błędów. Logi pokazywały pełny obraz: codziennie między 2:00 a 3:00 UTC (kiedy Googlebot najczęściej odwiedzał tę konkretną witrynę), serwer nie dawał rady pod obciążeniem. Naprawa wymagała dostrojenia liczby workerów PHP-FPM i connection poolingu bazy danych. Łączny koszt: dwie godziny pracy DevOpsa. Poprawa pozycji pojawiła się w ciągu trzech tygodni.

Nowe treści pozostające niezauważone

Opublikowaliśmy szczegółowy poradnik. Trzy tygodnie później wciąż nie był zaindeksowany. GSC pokazywało URL jako „Wykryto — aktualnie nie zaindeksowano”. Bardzo pomocne.

Logi opowiedziały prawdziwą historię: Googlebot nigdy nie wysłał żądania na ten URL. Ani razu. Strona była linkowana z archiwalnej strony tagów, która sama była crawlowana tylko dwa razy w 60 dni. Googlebot po prostu jeszcze nie podążył za linkiem.

Rozwiązaniem było dodanie linku wewnętrznego z często crawlowanej strony (sidebar strony głównej). Googlebot trafił na nową stronę w ciągu 48 godzin. Zaindeksowana w ciągu tygodnia. To jest dokładnie taki problem, który checklista SEO po publikacji powinna wyłapać, zanim stanie się problemem.

Marnowanie budżetu renderowania

Klient SaaS miał stronę marketingową zbudowaną w Next.js. SSR było włączone — dobrze. Ale logi pokazywały coś dziwnego: bot renderujący Chrome Googlebota robił drugi przebieg na każdej stronie, w tym na prostych statycznych stronach bez dynamicznej treści po stronie klienta.

Problemem był skrypt analityczny po stronie klienta, który modyfikował DOM po załadowaniu strony. Googlebot widział początkowy HTML, a potem wracał, żeby wyrenderować JS i widział inną treść (elementy wstrzyknięte przez analitykę). Więc ciągle renderował ponownie, żeby upewnić się, że ma finalną wersję. To pochłaniało budżet renderowania na stronach, które tego nie potrzebowały.

Rozwiązanie: przeniesienie skryptu analitycznego, żeby ładował się po zdarzeniu DOMContentLoaded z atrybutem defer, i upewnienie się, że nie modyfikuje widocznych elementów DOM. Żądania renderowania spadły o 60%.

Narzędzia do analizy logów

Botify — Klasa enterprise. Wczytuje logi na dużą skalę, koreluje je z danymi crawlowania i Search Console, automatycznie buduje dashboardy. Jeśli zarządzasz witryną z milionami stron, prawdopodobnie warto zainwestować. Dla witryn poniżej 100 tys. stron to przerost formy. Cennik był w zakresie kilkuset dolarów miesięcznie, kiedy ostatnio sprawdzałem (stan na połowę 2025), choć ich dokładny cennik jest nieprzejrzysty i mam mieszane uczucia na ten temat.

JetOctopus — Solidny środek. Chmurowa analiza logów z dobrą wizualizacją. Obsługuje duże pliki logów, integruje się z GSC i kosztuje znacznie mniej niż Botify. Polecałem to agencjom zarządzającym wieloma średniej wielkości witrynami.

Własny Python + ELK — Jeśli jesteś techniczny i chcesz pełnej kontroli, powyższy skrypt to punkt wyjścia. Do ciągłego monitorowania przekieruj logi do stosu ELK (Elasticsearch, Logstash, Kibana). Logstash parsuje logi wzorcami grok, Elasticsearch przechowuje i indeksuje, Kibana daje dashboardy w czasie rzeczywistym. Konfiguracja zajmuje dzień. Bieżący koszt to tylko serwer — jakieś 20-50 dolarów miesięcznie na małym VPS.

GoAccess — Lekki, terminalowy analizator logów, który generuje raporty HTML. Nie jest dedykowany SEO, ale zaskakująco przydatny do szybkiego przeglądu aktywności botów i rozkładu kodów statusu. Darmowy, szybki, działa na każdym serwerze. Dobry na „chcę tylko szybko coś sprawdzić”.

Czego się nauczyłem, analizując logi SEOJuice.com

Chwila transparentności. Oto co znalazłem, kiedy po raz pierwszy przeprowadziłem porządną analizę logów na naszej własnej witrynie pod koniec 2025 roku.

Wniosek 1: Marnowanie crawl budgetu na stronach narzędzi. Nasze darmowe narzędzia SEO (audyt witryny, sprawdzanie autorytetu domeny, ekstraktor słów kluczowych itd.) generują unikalne adresy URL dla każdej analizy. Każdy wynik narzędzia miał unikalny URL. Googlebot crawlował tysiące z nich. To były w większości cienkie, efemeryczne strony, które nie musiały być w indeksie. Dodaliśmy noindex do stron wyników narzędzi i w ciągu dwóch tygodni zaobserwowaliśmy wzrost częstotliwości crawlowania bloga.

Wniosek 2: Wolne strony zależne od API. Nasza strona cennikowa wykonywała zapytanie do API Paddle w czasie rzeczywistym, żeby pobrać aktualne ceny. Mediana czasu odpowiedzi: 1,8 sekundy. Googlebot na to czekał. Przeszliśmy na cachowanie danych cenowych z TTL 1 godzina. Czas odpowiedzi spadł do 90 ms.

Wniosek 3: Łańcuchy przekierowań 301. Po restrukturyzacji adresów URL mieliśmy łańcuchy typu /stary-url → /sredni-url → /finalny-url. Dwanaście procent żądań Googlebota podążało za przekierowaniami. Każdy skok to zmarnowane żądanie. Spłaszczyliśmy wszystkie łańcuchy do jednoskokowych przekierowań w konfiguracji Nginx.

Wniosek 4: Crawlowanie CSS i JS. To mnie zaskoczyło. Mniej więcej 30% żądań Googlebota dotyczyło zasobów statycznych — plików CSS, bundli JavaScript, czcionek. Są niezbędne do renderowania, ale to oznaczało, że tylko 70% naszego crawl budgetu szło na faktyczne strony z treścią. Nie mogliśmy tego wyeliminować (Google potrzebuje tych plików do renderowania stron), ale zmieniło to nasze myślenie o łącznym crawl budgecie.

Efekt netto: po rozwiązaniu wniosków 1-3 nasze treści blogowe były indeksowane 3-4 razy szybciej. Nowe posty przeszły z „wykryty, ale nie zaindeksowany przez 2-3 tygodnie” do „zaindeksowany w ciągu 3-5 dni”. Wszystko dzięki analizie logów, które GSC nigdy nie ujawniło.

Jak pomaga analityka crawlerów SEOJuice

Zbudowałem funkcję analityki crawlerów w SEOJuice właśnie dlatego, że miałem dość parsowania surowych logów. Daje te same wnioski bez pracy w wierszu poleceń.

Analityka crawlerów SEOJuice monitoruje aktywność Googlebota na Twojej witrynie i prezentuje:

• Częstotliwość crawlowania wg strony i sekcji — zobacz dokładnie, na co Google przeznacza swój crawl budget
• Rozkład kodów statusu w czasie — wyłap skoki błędów, zanim wpłyną na pozycje
• Trendy czasu odpowiedzi — zidentyfikuj strony, które spowalniają Googlebota
• Niecrawlowane strony — strony w Twojej mapie witryny, których Googlebot nie odwiedził
• Aktywność renderowania — które strony wywołują drugi przebieg WRS Google

Nie zastępuje surowej analizy logów w każdym przypadku. Jeśli musisz debugować konkretną konfigurację Nginx lub zbadać zachowanie botów na poziomie IP, wciąż potrzebujesz surowych logów. Ale w 90% przypadków, kiedy chcesz po prostu wiedzieć „czy Googlebot crawluje to, co powinien?” — to jest dużo szybsze niż pisanie skryptów w Pythonie.

Wypróbuj SEOJuice za darmo i podłącz swoją witrynę, żeby zobaczyć analitykę crawlerów w akcji. Bez karty kredytowej.

Prosty miesięczny audyt logów

Nie musisz wpatrywać się w logi codziennie. Oto miesięczna rutyna, którą stosuję:

1. Pobierz lub odpytaj logi z ostatnich 30 dni (lub sprawdź dashboard narzędzia do analizy logów).
2. Sprawdź rozkład kodów statusu. Wzrost 4xx lub 5xx? Zbadaj natychmiast.
3. Porównaj dystrybucję crawlowania z dystrybucją treści. Czy Google crawluje sekcje, na których Ci zależy, proporcjonalnie?
4. Znajdź niecrawlowane adresy URL. Porównaj mapę witryny z crawlowanymi adresami. Cokolwiek niecrawlowanego przez ponad 30 dni dostaje link wewnętrzny z często crawlowanej strony.
5. Sprawdź czasy odpowiedzi. Jakieś nowe strony w przedziale powyżej 1 s? Napraw je, zanim staną się problemem rankingowym.
6. Przejrzyj żądania renderowania. Jeśli żądania renderowania rosną bez nowych stron opartych na JS, coś się zmieniło w Twoim kodzie frontendowym.

Łączny czas: 30-45 minut. Zwrot z inwestycji jest nieproporcjonalnie wysoki.

Najczęściej zadawane pytania

Jak duża musi być moja witryna, żeby analiza logów miała sens?

Nie testowałem tego wyczerpująco w każdej niszy, ale nie ma sztywnego minimum — korzyść rośnie wraz z rozmiarem witryny. Poniżej 100 stron Googlebot crawluje wszystko niezależnie od okoliczności i prawdopodobnie nie masz problemów z crawl budgetem. Między 500 a 5000 stron zaczyna to mieć wartość. Powyżej 10 000 stron jest to niezbędne — marnowanie crawl budgetu jest prawie gwarantowane na witrynach tej wielkości. Powiedziawszy to, nawet witryna z 200 stronami może skorzystać, jeśli widzisz opóźnienia w indeksowaniu lub tajemnicze spadki pozycji.

Czy mogę zweryfikować, że żądanie naprawdę pochodzi od Googlebota?

Tak. Google publikuje swoje zakresy IP i możesz wykonać odwrotne zapytanie DNS na adresie IP żądania. Prawdziwe adresy IP Googlebota rozwiązują się do *.googlebot.com lub *.google.com. W Pythonie: import socket; socket.gethostbyaddr('66.249.79.45'). Każdy IP, który nie rozwiązuje się do domeny Google, to fałszywy Googlebot — prawdopodobnie scraper korzystający z ciągu user agent Googlebota. Oficjalna dokumentacja Google zaleca tę metodę weryfikacji.

Jak często Googlebot crawluje typową witrynę?

Różni się to ogromnie. Serwis informacyjny o wysokim autorytecie może widzieć tysiące żądań Googlebota na godzinę. Mała witryna firmowa może widzieć 50-200 dziennie. Częstotliwość zależy od postrzeganej ważności witryny, od tego jak często zmieniasz treści, od szybkości odpowiedzi serwera i od świeżości mapy witryny XML. Według analizy częstotliwości crawlowania JetOctopus z 2024 roku na bazie ich klientów, mediana częstotliwości crawlowania dla witryny z 5000 stron to mniej więcej 300-800 żądań Googlebota dziennie.

Czy powinienem blokować złośliwe boty na podstawie logów?

Blokuj złośliwe boty na poziomie serwera (reguły deny w Nginx lub fail2ban), nie tylko w robots.txt. Robots.txt to sugestia — złośliwe boty go ignorują. Ale bądź ostrożny: nie zablokuj przypadkiem prawdziwych crawlerów. Widziałem witryny, które blokowały wszystkie boty z „bot” w ciągu user agent, co łapało też Googlebota. Zawsze dodaj wyjątki dla Google, Bing i innych wyszukiwarek, na których Ci zależy, zanim wdrożysz szerokie reguły blokowania botów.

Jaka jest zależność między analizą logów a crawl budgetem?

Analiza logów to sposób na mierzenie crawl budgetu. Google definiuje crawl budget jako połączenie limitu szybkości crawlowania (jak szybko Google może crawlować bez przeciążania Twojego serwera) i zapotrzebowania na crawlowanie (jak bardzo Google chce crawlować na podstawie postrzeganej wartości). Nie możesz bezpośrednio kontrolować żadnego z nich, ale możesz na nie wpływać: szybsze czasy odpowiedzi zwiększają limit szybkości crawlowania, a usunięcie niskowartościowych stron z kolejki crawlowania Google zwiększa udział crawl budgetu przeznaczany na strony, które mają znaczenie. Logi pokazują obie strony tego równania.

Analiza logów nie jest efektowna. To grep, regex i przepuszczanie plików tekstowych przez skrypty. Nie ma ładnych dashboardów (chyba że je zbudujesz). Ale to najbliższe, co dostaniesz, żeby zobaczyć swoją witrynę oczami Google. GSC pokazuje wyselekcjonowane podsumowanie. Logi pokazują surową prawdę.

Jeśli zarządzasz witryną z więcej niż kilkuset stronami i nigdy nie zajrzałeś do logów serwera, masz problemy z crawlowaniem, o których nie wiesz. Założyłbym się o pieniądze.

Dodatkowe materiały z serii technicznego SEO:

• SEO dla SPA: jak sprawić, żeby aplikacje jednostronicowe były crawlowalne
• Silosy treści w SEO: budowanie autorytetu tematycznego
• Strony osierocone w SEO i jak je naprawić
• Checklista SEO po publikacji: nie zapomnij o tych krokach
• Narzędzia SEO open-source: kompletna lista