Analiza logów serwera. Zanim zaczniesz myśleć o widoczności w AI

Myślisz o GEO – o tym, żeby akapit obronił się wyjęty z kontekstu, o BLUF-ie na wejściu sekcji, o encji i o tym, czy Twoja treść w ogóle trafiła do Common Crawl. To są dziś właściwe pytania, ale… zatrzymaj się na moment w tym pędzie i zejdź do fundamentów technicznego SEO, czyli logów serwera. Bo Twoja praca nad widocznością w AI ma sens pod jednym warunkiem: że bot w ogóle wszedł na stronę i mógł pobrać jej treść. I tu kłania się analiza logów serwera.

Na początku czerwca dostałam od swojego hostingodawcy informację, że zaczyna „chronić moje treści przed wykorzystaniem do uczenia sztucznej inteligencji”. Nikt mnie o zdanie nie zapytał, więc przezornie usiadłam do logów, żeby sprawdzić, co ta ochrona właściwie oznacza w praktyce.

Okazało się, że od początku dostępnego archiwum, czyli od 2 lutego, aż do połowy czerwca boty AI regularnie dostawały od serwera kod 429. W całym analizowanym okresie, do 5 sierpnia, GPTBot dostał tę odpowiedź 2615 razy, Amazonbot 1839, OAI-SearchBot 834, a ClaudeBot 400 razy.Googlebot – ani razu. Kiedy blokady zaczęły się naprawdę, nie wiem, bo wcześniejszych logów już nie ma. Wiem natomiast, że nie miałam o nich pojęcia, dopóki nie zajrzałam do własnych logów.

I to jest chyba najbardziej niewygodna część tej historii, zważywszy na moją specjalizację… Szewc bez butów chodzi. Zwłaszcza że do takiej analizy własnej popchnęła mnie także praca z klientami – ten sam wzorzec zobaczyłam u kilku z nich, zanim sprawdziłam własny serwer. Pokazuję jednak wyłącznie to, co mogę pokazać bezkompromisowo, czyli swoje logi i wyniki po to, by przekonać Cię, że sprawdzenie logów powinno być jednym z pierwszych kroków w pracy nad widocznością w AI.

Optymalizacja treści zakłada, że… AI ją pobierze

Każda technika, o której dziś mówimy pod hasłem GEO, stoi na dość oczywistym łańcuchu zdarzeń: któryś element ekosystemu musi pobrać stronę – crawler dostawcy, indeks wyszukiwarki albo partner dostarczający wyniki. Dopiero potem z treści wycinany jest pasaż (fragment tekstu, zwykle kilka zdań lub akapit), który konkuruje o miejsce w odpowiedzi. Struktura treści, nagłówki jako mapa dla algorytmu, odpowiedź postawiona na wejściu sekcji – wszystko to pracuje w ogniwie drugim i trzecim.

Ogniwo pierwsze traktujemy jako oczywiste i właśnie dlatego jest najsłabsze. Możesz mieć najlepiej ułożoną treść w swojej niszy, dopięte dane strukturalne i poukładaną encję, ale jeśli bot dostaje od Twojego serwera odpowiedź „za dużo żądań, wróć później”, to nie ma z czego zbudować pasażu i cała reszta pracy tak naprawdę nie ma jak zadziałać.

Kod 429 („Too Many Requests”) to odmowa obsługi żądania z powodu przekroczenia limitu. W zamyśle jest sygnałem, żeby klient zwolnił tempo i wrócił za chwilę. Każde żądanie zakończone kodem 429 nie dostaje treści, więc gdy takie odpowiedzi lecą systematycznie przez cztery miesiące, dostęp bota staje się nieprzewidywalny i mocno ograniczony.

Dlaczego odpowiedź znajdziesz tylko w logach?

Żadne narzędzie zewnętrzne nie odpowie na pytanie, czy GPTBot wszedł wczoraj na Twoją stronę i co dostał w odpowiedzi. Narzędzia do monitoringu widoczności w AI odpytują modele i sprawdzają, czy pojawiasz się w wygenerowanej odpowiedzi, co jest zupełnie innym pytaniem, zadanym na przeciwnym końcu procesu. Log dostępowy notuje każde żądanie osobno: adres IP, datę, żądany URL, kod odpowiedzi i user-agenta. Odpowiedzi szukasz na tej warstwie, na której zapada decyzja – w logu serwera, a jeśli blokada następuje wcześniej, w logach CDN-u albo w panelu WAF-a.

Zanim przejdziemy dalej: czym jest WAF?

Ruch może być filtrowany w kilku miejscach naraz i nie w każdym z nich to Ty decydujesz o regułach:

• Po stronie hostingu

  Reguły domyślnie włączone w konfiguracji serwera, zwykle jako element usługi, o którym nikt Ci osobno nie mówi.

• Na CDN-ie

  Cloudflare od 1 lipca 2026 daje wszystkim klientom, także w planie Free, osobne ustawienia dla botów Search, Agent i Training. Od 15 września 2026 dla wszystkich nowych domen ma domyślnie blokować Agent i Training na podstronach z reklamami, zostawiając Search dozwolone.

• We wtyczce

  Wordfence, iThemes Security i inne rozwiązania bezpieczeństwa dla WordPressa, opisywane w poradnikach jako „ustaw i zapomnij”.

• W pliku .htaccess

  To nie jest WAF, tylko plik konfiguracyjny serwera, w którym można zapisać własne reguły blokowania i limitowania ruchu. Jedyne miejsce, o którym zwykle wiesz, że istnieje.

Reguła, która odrzuca boty, nie jest sama w sobie błędem. Pytanie brzmi tylko, czy realizuje Twoje cele.

Co znalazłam w swoich logach?

Wzięłam wszystko, co miałam w archiwum, czyli okres od 2 lutego do 5 sierpnia 2026: ponad 1,8 miliona żądań w logu dostępowym i 119 794 wpisy w logu błędów. W tym oknie blokady rosły z miesiąca na miesiąc: w lutym boty AI dostały 752 odpowiedzi 429, w maju już 2020, a rekordowy okazał się 12 czerwca, kiedy w ciągu jednej doby odbiło się od serwera ponad czterysta żądań.

Odpowiedzi 429 dla botów AI, dzień po dniu. Zaznaczone pasmo to 13–15 czerwca, kiedy wyłączałam kolejne reguły.

Reguły odpowiedzialne za te blokady były wystawione osobno dla poszczególnych botów, z nazwą bota wpisaną w środek reguły, co samo w sobie mówi o tym, że nie powstały przypadkiem.

Dlaczego nie tak łatwo się zorientować?

Bo odwiedzamy Search Console, monitorujemy widoczność i Googlebot zazwyczaj przechodzi. W 119 794 liniach logu błędów jego nazwa nie pada ani razu – zero blokad, zero limitów, zero reguł napisanych pod niego. To zresztą ma swoją logikę, bo zablokowanie Googlebota przez hostingodawcę byłoby strzałem w kolano: klienci zauważyliby spadki w ciągu tygodnia, skoro z Google nadal przychodzi zdecydowana większość ruchu z wyszukiwania. Obrywają więc pozostałe boty, czasem całkiem słusznie, bo część z nich rzeczywiście zachowuje się agresywnie, a czasem zupełnie niesłusznie.

Efekt praktyczny jest taki, że wszystkie klasyczne wskaźniki wyglądają dobrze: ruch organiczny bez zmian, indeksacja w porządku, w Search Console cisza. Sygnał ostrzegawczy nie pojawia się nigdzie. Poza logami.

Analiza logów serwera i diagnoza: boty AI mają problem z dostępem do strony – co dalej?

Między 13 a 15 czerwca siedziałam nad kolejnymi porcjami logów i wyłączałam reguły w .htaccess, bot po bocie, sprawdzając po każdej zmianie, czy blokady faktycznie ustają. Zaczęłam od botów powiązanych z ekosystemem generatywnym, choć pełniących różne funkcje: od crawlerów treningowych, takich jak GPTBot i ClaudeBot, po roboty budujące indeksy wyszukiwania, takie jak OAI-SearchBot i PerplexityBot.

To rozróżnienie ma znaczenie, bo odblokowanie GPTBota nie jest tym samym co umożliwienie pojawiania się w bieżących wynikach ChatGPT Search – za tę drugą funkcję odpowiada u OpenAI przede wszystkim OAI-SearchBot. Przy każdym patrzyłam nie tylko na to, czy blokady znikają, ale też czy bot nie zaczyna zjadać serwera, bo pierwotna reguła nie wzięła się przecież znikąd.

Co mi to dało?

Blokady botów AI spadły z 1920 miesięcznie w czerwcu do 33 w lipcu. Udane wejścia botów AI w treść wzrosły z 1852 w maju do 2446 w lipcu.

Naprawa nastąpiła 13–15 czerwca, więc lipiec to pierwszy pełny miesiąc bez reguł. Źródło: logi dostępowe podrez.pl.

Celowo liczę tu wyłącznie boty AI. Gdyby wliczyć cały ruch botów, weszłyby do zestawienia narzędzia SEO – sam audytor Ahrefs robi u mnie ponad dwadzieścia tysięcy żądań miesięcznie – a wzrost wyszedłby pewnie efektowniej, ale i nie mówiłby o niczym.

To ważne: nie każda blokada jest błędem

Druga warstwa reguł, ta odrzucająca ruch kodem 406, działa u mnie do dziś i przez chwilę wyglądała na kolejny problem, bo w lipcu i sierpniu odbiły się od niej żądania podpisane jako GPTBot, ClaudeBot, OAI-SearchBot, PerplexityBot, CCBot, ChatGPT-User i Google-Extended. Wystarczyło sprawdzić, o jakie adresy prosiły.

Prosiły o /.env, /.env.bak, /config/.env.php, /wp-config.php i podobne pliki, w których trzyma się hasła do bazy danych. Żaden prawdziwy crawler AI takich adresów nie szuka, a do tego niemal wszystkie te żądania przyszły z jednego adresu IP, który tylko zmieniał user-agenta.

Prawdziwe crawlery AI od lipca nie dostają u mnie 406 na treści. Wyjątkiem jest jeden crawler, który wciąż odbija się od reguł, głównie na plikach PDF, i to zostaje na mojej liście do zamknięcia. Wcześniej, między lutym a majem, ta sama warstwa 267 razy nie pozwoliła ClaudeBotowi pobrać pliku robots.txt, czyli dokumentu, który miał mu powiedzieć, co wolno mu czytać.

Liczba wizyt bota nie jest miarą sukcesu

Spodziewałam się prostej historii: odblokowuję, boty wracają tłumnie, wykres idzie w górę. No…nie tak to wyszło i w sumie ma to sens. GPTBot po odblokowaniu przychodzi rzadziej – w czerwcu zaliczył 1066 udanych żądań, w lipcu 538 – a OAI-SearchBot spada systematycznie od lutego, całkowicie niezależnie od tego, czy był blokowany, czy nie. Rosną za to ClaudeBot i Amazonbot, więc sam wolumen crawlu okazał się bezużyteczny jako samodzielna miara widoczności w AI. Do oceny obciążenia serwera nadal się jednak przydaje.

Znacznie ciekawsze jest to, po co te boty przychodzą. Policzyłam, jaka część ich udanych żądań trafia w podstronę z treścią, a jaka w pliki CSS, obrazki, sitemapy i końcówki API.

Podział jest czytelny. Boty uruchamiane w związku z działaniem użytkownika częściej trafiają bezpośrednio w treść: ChatGPT-User w niemalże siedemdziesięciu czterech procentach, Claude-User w sześćdziesięciu. Wysoki wynik CCBota, osiemdziesiąt dwa procent, ma inne źródło – to crawler Common Crawl, który buduje otwartą bazę stron i nie przychodzi w reakcji na czyjeś pytanie. Nie oceniałabym więc tych grup jedną miarą, podobnie jak nie ma sensu mierzyć budżetu indeksowania liczbą pobranych favikon.

Efekty pośrednie

Równolegle mierzę widoczność w systemach generatywnych, czyli narzędzia odpytują modele stałym zestawem promptów i sprawdzają, czy w odpowiedzi pada moje nazwisko oraz jaką część tej odpowiedzi zajmuję na tle konkurencji. Zestaw pytań zmieniał się w czasie, więc pokazuję dwie wersje tej samej miary: na wszystkich pytaniach i na dwunastu obecnych przez cały okres. Ta druga jest wersją ostrożną i pilnuje, żeby zmiana zestawu nie udawała zmiany widoczności.

Wszystkie trzy linie idą w tę samą stronę. Średni share of voice na sondę trzymał się w maju i na początku czerwca w okolicach jednego procenta, a od przełomu czerwca i lipca ustawił się między siedmioma a ośmioma procentami. Mediana pozycji, liczona tak samo jak w narzędziu i wyłącznie na odpowiedziach, w których w ogóle padam, spadła z pięciu w drugiej połowie maja do dwóch w ostatnim tygodniu. W typowej odpowiedzi, która mnie wymienia, jestem dziś na drugim miejscu.

Linia przerywana to ta sama miara na dwunastu pytaniach obecnych przez cały okres. Rośnie wolniej, z około jednego procenta do trzech, i zostawiam ją celowo: w czerwcu doszły do zestawu pytania bliższe temu, czym się zajmuję, więc część wzrostu na pełnym zestawie bierze się z lepszego dopasowania pytań. Prawda leży między tymi liniami i w obu przypadkach jest to wzrost.

Dziewiąte miejsce wśród stu pięćdziesięciu nazwisk

Najbardziej przekonuje mnie jednak porównanie z konkurencją. Share of voice w obrębie jednej odpowiedzi sumuje się do stu procent, więc każdy punkt procentowy, który zyskuję, ktoś inny traci. W odpowiedziach na te dwanaście pytań pojawia się co miesiąc około stu pięćdziesięciu nazwisk polskich i zagranicznych specjalistów.

W maju byłam szesnasta i odpowiadałam za 1,3 procent całej przestrzeni, jaką modele poświęcały na wymienianie ekspertów. W czerwcu awansowałam na dziesiąte miejsce z 2,1 procent, a w lipcu na dziewiąte z czterema procentami, czyli mój udział potroił się w ciągu dwóch miesięcy.

Do tego jedna informacja wprost z Analyticsa, która moim zdaniem robi największe wrażenie: 23 czerwca 2026 na podrez.pl wszedł pierwszy użytkownik przypisany do kanału „AI assistant” w całym analizowanym okresie. Ruch jest wciąż niewielki, ale da się go już policzyć.

Jak sprawdzić to u siebie?

Potrzebujesz dostępu do logów i odrobiny czasu. Na serwerze szukaj katalogu logs: znajdziesz w nim log dostępowy, zwykle jako access.log albo domena.pl.log, oraz osobno error.log, w którym zapisuje się powód odrzucenia żądania. Starsze dni są zwykle spakowane w archiwa .gz albo .tar.gz, po jednym na dobę lub tydzień, więc do analizy całego okresu trzeba je najpierw rozpakować i scalić. Na części hostingów logi trzeba najpierw włączyć w panelu, a czasem poprosić o nie wsparcie techniczne.

Do samej analizy masz kilka dróg, w kolejności od najprostszej:

• Pobranie z katalogu logs

  Tak zrobiłam u siebie: ściągnęłam całą zawartość katalogu i dopiero potem rozpakowałam oraz scaliłam archiwa. Mając dostęp do konsoli, możesz zamiast tego przejrzeć logi na miejscu – log z pół roku potrafi ważyć kilkaset megabajtów.

• Screaming Frog Log File Analyser

  Wrzucasz plik, dostajesz rozbicie na boty, kody odpowiedzi i adresy. Wersja darmowa obsługuje tysiąc zdarzeń, co wystarczy na pierwsze rozeznanie.

• Model językowy z dostępem do plików

  Swoje logi scaliłam i przeanalizowałam całościowo. Przy setkach tysięcy linii oszczędza to godziny pracy.

Na co patrzeć w wyniku:

• 1

  Powtarzające się kody 4xx i 5xx

  Nie tylko 429, bo u mnie druga warstwa blokad zwracała 406, a spotyka się też 403 i 503. Pojedyncze 301 czy 302 są zwykle w porządku – niepokoją dopiero długie łańcuchy przekierowań.

• 2

  Bot, którego nie ma wcale

  Zero linii dla GPTBota przy sprawnie działającym Googlebocie to jasny sygnał do dalszej weryfikacji.

• 3

  Proporcje między botami

  Jeśli Googlebot przechodzi gładko, a wszystkie pozostałe zbierają odmowy? Masz odpowiedź, zanim jeszcze zajrzysz do samych reguł.

• 4

  Powód odrzucenia

  Zależnie od konfiguracji wskaże go log błędów, log audytowy WAF-a albo panel CDN-u. Stamtąd dowiesz się, czy reguła pochodzi od Ciebie, czy od dostawcy.

• 5

  Żądany adres

  Jeśli „bot AI” prosi o pliki konfiguracyjne, blokada jest jak najbardziej na miejscu.

Dwie uwagi na koniec:

• Jeśli korzystasz za CDN-a, część decyzji zapada, zanim ruch dotrze do Twojego serwera, więc tych blokad w logu nie zobaczysz i trzeba ich szukać w panelu dostawcy.
• User-agenta da się łatwo podrobić, dlatego weryfikuj źródłowy adres IP na podstawie zakresów publikowanych przez operatora. W przypadku Google możesz dodatkowo wykonać odwrotne, a następnie ponowne bezpośrednie sprawdzenie DNS.

Co z tym dalej zrobić?

1. 1Sprawdź, czy w ogóle masz problem

   Kwadrans z logami często odpowiada na to pytanie bez zgadywania. Jeśli ruch zatrzymuje się wcześniej, trzeba dodatkowo sprawdzić panel CDN-u albo WAF-a.

2. 2Ustal, kto postawił regułę

   Twój .htaccess, wtyczka, CDN czy domyślna konfiguracja hostingu – każde z tych miejsc odblokowuje się inaczej i w każdym rozmawiasz z kimś innym.

3. 3Zdecyduj świadomie, kogo wpuszczasz

   Blokowanie crawlerów AI bywa uzasadnioną decyzją biznesową, zwłaszcza przy treści, z której się żyje. Chodzi o to, żeby to była Twoja decyzja i żebyś znała jej cenę.

4. 4Wyłączaj po kolei i patrz w logi

   Reguły limitujące ruch powstały z jakiegoś powodu, więc jeśli po odblokowaniu serwer zaczyna się dusić, potrzebujesz limitu, a nie bana.

5. 5Wróć do logów po miesiącu

   Reguły potrafią wrócić przy aktualizacji konfiguracji po stronie dostawcy, o czym też nikt Cię nie poinformuje.

I dopiero wtedy wracaj do pasaży, BLUF-a i encji, bo one naprawdę mają znaczenie.

Z książki

Warstwa techniczna nie buduje marki, ale potrafi ją skutecznie unieważnić. O tym, co składa się na widoczność w systemach generatywnych i w jakiej kolejności to układać, piszę szerzej w książce.

Marka osobista w czasach AI

Często zadawane pytania