Jak sprawdzić w logach, czy boty AI czytają stronę

Wyobraź sobie, że przez pół roku dopieszczasz treści pod ChatGPT. Piszesz odpowiedzi na pytania klientów, dodajesz dane strukturalne, czekasz. A bot OpenAI ani razu nie wszedł na Twoją stronę. Nie chodzi o to, że AI Cię nie lubi. AI Cię nie zna, bo nie miało z czego.

Logi serwera rozstrzygają to w kilka minut. Zanim zaczniesz cokolwiek optymalizować, sprawdź rzecz najprostszą: czy boty w ogóle Cię odwiedzają. To pytanie o dostęp, nie o jakość treści, i tylko logi odpowiadają na nie twardym faktem, a nie domysłem.

Dlaczego logi serwera to twardy dowód, a nie domysł?

Logi serwera nie zgadują. Zapisują każde wejście na stronę: adres IP, godzinę, adres URL, którego ktoś zażądał, oraz kod odpowiedzi serwera. Przy każdej linii widnieje też user-agent, czyli podpis, którym przedstawia się odwiedzający.

Boty AI podpisują się własnymi nazwami. Zamiast więc zgadywać, czy ChatGPT ma skąd Cię znać, sprawdzasz konkretną rzecz: czy bot OpenAI fizycznie wszedł na Twoją stronę i co dostał w odpowiedzi. To różnica między prognozą pogody a wyjrzeniem przez okno.

Logika jest bezlitosna w jedną stronę. Jeśli GPTBot nigdy nie wszedł, Twoja treść nie miała jak trafić do treningu modelu. Jeśli bot wyszukiwania nie przeczytał strony, nie ma jej z czego zacytować na żywo. Dostęp to warunek konieczny widoczności w AI, choć sam w sobie niczego nie gwarantuje. Brak dostępu za to gwarantuje nieobecność.

Jakich botów AI szukać w logach?

W logach szukasz kilku nazw. Każda należy do innego asystenta i robi co innego, więc warto je rozróżniać.

• GPTBot - crawler OpenAI, który zbiera treści do trenowania modeli. To on decyduje, czy w przyszłości ChatGPT będzie „znał” Twoją firmę z pamięci.
• OAI-SearchBot oraz ChatGPT-User - powierzchnia wyszukiwania ChatGPT. Pierwszy indeksuje strony pod odpowiedzi z sieci, drugi wchodzi na żywo, gdy użytkownik poprosi ChatGPT o coś z konkretnego adresu.
• Google-Extended - tu uwaga: to nie jest osobny bot, którego zobaczysz w logach, tylko token w pliku robots.txt sterujący tym, czy Google użyje Twojej treści w Gemini. Samo pobieranie strony robi zwykły Googlebot.
• PerplexityBot - crawler Perplexity, który zasila jego odpowiedzi i cytowania.
• ClaudeBot - bot Anthropic. Claude jest poza piątką silników, którą mierzy CiteLyzer (ChatGPT, Gemini, Perplexity, AI Overviews i AI Mode), ale jego bot i tak zbiera treści z sieci.

Na co patrzeć w logach poza samą nazwą bota?

Sama obecność bota to dopiero początek. Z każdej linii logu wyczytasz trzy rzeczy, które mówią więcej niż samo „był tu”.

• Częstotliwość. Bot, który zagląda regularnie, widzi Twoje zmiany. Ten, który był raz pół roku temu, pamięta nieaktualną wersję strony.
• Odwiedzane strony. Sprawdź, czy bot dociera tam, gdzie Ci zależy - do strony z ofertą, cennikiem, opisem usług - czy krąży tylko po stronie głównej.
• Kod odpowiedzi. To on mówi, czy wizyta się udała. Kod 200 znaczy, że bot dostał treść. Kod 403 lub 401 - że został odbity od progu. Kod 404 - że strona, o którą prosił, nie istnieje. Kody z rodziny 5xx albo 429 - że serwer nie wyrobił lub uciął go limitem.

Jak dostać się do logów, gdy nie jesteś techniczny?

Nie musisz być programistą, żeby te dane zobaczyć. Prowadzi do nich kilka dróg, zależnie od tego, na czym stoi Twoja strona.

• Panel hostingu. Większość paneli (cPanel, DirectAdmin, Plesk) ma sekcję „logi dostępu” albo „access logs” do pobrania.
• Cloudflare lub inne CDN. Jeśli ruch idzie przez taką warstwę, znajdziesz w niej analitykę botów i zdarzenia zapory, często z gotowym rozbiciem na zweryfikowane crawlery.
• Wtyczki. Na WordPressie są dodatki, które logują wejścia botów i pokazują je w panelu, bez zaglądania w surowe pliki.

Jakie sygnały ostrzegawcze zobaczysz i co z nimi zrobić?

Jeśli nic z powyższego nie brzmi znajomo, napisz do hostingu albo administratora jedno zdanie: „Poproszę logi dostępu z ostatnich 30 dni, przefiltrowane po user-agent zawierającym GPTBot, OAI-SearchBot, PerplexityBot i ClaudeBot”. To wystarczy, żeby dostać gotową listę wizyt. Trzy obrazy w takiej liście powinny zapalić lampkę.

• Bot dostaje błędy. Regularne 403, 404 albo 5xx przy jego wizytach znaczą, że chce wejść, a serwer go odbija. To zwykle robota zapory, blokady po user-agent albo błędnego wpisu w robots.txt.
• Bota w ogóle nie ma. Żadnej linii z jego nazwą przez wiele tygodni to najprostszy powód nieobecności w AI: bot nie wie, że istniejesz.
• Bot widzi co innego niż człowiek. Zamiast treści dostaje stronę-zaporę („sprawdzamy Twoją przeglądarkę”), captchę albo pustą stronę, której treść dokleja się dopiero skryptem w przeglądarce. To przypadkowy cloaking: człowiek widzi stronę, bot pustkę.

Co zrobić z tą wiedzą?

Reakcja zależy od obrazu w logach. Przy błędach sprawdź robots.txt pod kątem wpisów „Disallow” dla tych botów i przejrzyj zaporę, czy nie tnie ruchu po nazwie bota lub adresie IP. Przy pustej stronie zadbaj, żeby najważniejsza treść była w kodzie HTML, a nie dostarczana wyłącznie skryptem, bo część botów nie uruchamia JavaScriptu.

Trzymaj przy tym proporcje. Odblokowanie dostępu nie sprawi samo z siebie, że AI zacznie Cię polecać. Usuwa za to przeszkodę, przez którą wcześniej nie miałeś nawet szansy się pojawić.

Podsumowanie

Logi i pomiar odpowiadają na dwa różne pytania. Logi mówią o dostępie: czy boty AI mają skąd Cię znać. Pomiar widoczności w AI mówi o efekcie: czy asystenci faktycznie wymieniają i cytują Twoją firmę w odpowiedziach. Jedno bez drugiego daje połowiczny obraz.

Kolejność jest naturalna. Najpierw upewnij się, że boty w ogóle wchodzą i dostają treść, bo bez tego optymalizacja jest strzelaniem w ciemno. Potem mierz, czy ta obecność zamienia się we wzmianki i cytowania. Darmowy audyt techniczny CiteLyzera sprawdza część sygnałów dostępu, które inaczej musiałbyś wyłuskiwać z surowych logów samodzielnie. To dobry punkt startu, zanim wejdziesz głębiej.