GPTBot, ClaudeBot, PerplexityBot – co naprawdę widzą boty AI i jak im pomóc

W 2026 roku internet jest indeksowany przez kilkanaście różnych botów AI, z których każdy ma własne zasady, własnego user-agenta i własne implikacje dla widoczności Twojej strony. Decyzja, którego bota dopuszczać, którego blokować, a którego po prostu ignorować, ma bezpośrednie konsekwencje dla tego, czy Twoja firma pojawi się w odpowiedziach ChatGPT, Claude czy Perplexity. Większość zespołów technicznych w ogóle nie wie, ile botów AI ma na swojej stronie – i to jest dziś krytyczna luka informacyjna.

Trzynaście botów AI, które warto znać

Na rynku jest ponad 30 botów oznaczonych jako „AI crawlers”, ale 13 z nich realnie wpływa na widoczność marki w najpopularniejszych modelach LLM. Reszta to specjalistyczne narzędzia, agregatory danych albo projekty open-source.

Poza tą listą zostawiamy boty, które nie decydują o widoczności w odpowiedziach AI. OpenAI ma nowego OAI-AdsBot, który sprawdza bezpieczeństwo stron docelowych reklam w ChatGPT (zebrane dane nie trafiają do treningu), a Google opisuje fetcher Google-Agent, używany przez agentów działających na infrastrukturze Google. Aktualne wersje user-agentów OpenAI to GPTBot/1.4, OAI-SearchBot/1.4 i ChatGPT-User/1.0.

Częsty błąd: blokowanie tylko niektórych botów OpenAI lub Anthropic. Jeśli blokujesz GPTBota, ale dopuszczasz OAI-SearchBota, sygnał jest mieszany – Twoja strona nie trafi do treningu, ale może być cytowana w czasie rzeczywistym. To może być świadoma decyzja, ale częściej wynika z niewiedzy.

Konfiguracja robots.txt – działający szablon

Standardowa praktyka to dopuszczenie wszystkich oficjalnych botów AI, chyba że masz konkretny powód do blokady (ochrona własności intelektualnej, treści za paywallem). Przykład solidnego robots.txt dla strony chcącej być widoczną we wszystkich najpopularniejszych modelach LLM:

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: Claude-User
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Perplexity-User
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: GoogleOther
Allow: /

User-agent: CCBot
Allow: /

User-agent: Applebot-Extended
Allow: /

Sitemap: https://twojadomena.pl/sitemap.xml

Pamiętaj, że robots.txt nie zatrzyma wszystkich. Fetchery działające na żądanie użytkownika – ChatGPT-User, Perplexity-User czy Google-GeminiNotebook – według dokumentacji ich właścicieli mogą nie stosować się do reguł z tego pliku, bo pobranie strony zlecił człowiek.

Druga pułapka: blokowanie ścieżek dynamicznych (/search/, /cart/). Boty AI, podobnie jak Googlebot, nie powinny indeksować adresów URL z parametrami koszyka, sesji, filtrowania. Standardowe wyłączenia /api/, /admin/, /cart/, /checkout/, /search/?q= nadal działają.

Trzecia pułapka dotyczy Google. Token Google-Extended nie wyłącza Twojej strony z AI Overviews ani AI Mode – steruje tylko trenowaniem i uziemianiem modeli Gemini. Od 31 sierpnia 2026 roku do rezygnacji z funkcji generatywnych wyszukiwarki służy przełącznik Search generative AI control w Google Search Console. Wyłączenie nie wpływa na ranking w zwykłych wynikach, ale oznacza zero wyświetleń i ruchu z AI Overviews, AI Mode i funkcji AI w Discover.

Czy llms.txt ma sens?

llms.txt to propozycja standardu z 2024 roku (autor: Jeremy Howard), podobna do robots.txt, ale przeznaczona stricte dla modeli LLM. Plik leży w katalogu głównym domeny i zawiera hierarchiczną mapę najważniejszych zasobów na stronie z opisami w naturalnym języku. Idea: zamiast pozwalać modelowi LLM przeczesywać całą stronę, dajesz mu kuratorską listę treści, którą chcesz, żeby model znał najlepiej.

Ważne zastrzeżenie. llms.txt nie jest dziś główną wytyczną technicznej optymalizacji GEO. Branża jest podzielona, a stopień wdrożenia niejednoznaczny. Zastosuj go jako uzupełnienie podstaw – nie jako pierwszy krok i nie kosztem schema.org, SSR czy robots.txt.

Poziom adaptacji w 2026 roku:

• OpenAI i Anthropic – brak oficjalnego potwierdzenia, że ich crawlery uwzględniają llms.txt przy pobieraniu treści
• Google nie zaimplementowało standardu – w przewodniku po optymalizacji pod funkcje AI w wyszukiwarce uznaje llms.txt za zbędny, bo wystarcza mu klasyczny crawl
• Perplexity – brak oficjalnej deklaracji, że silnik korzysta z llms.txt; publicznie dostępne analizy logów nie pokazują, by boty AI regularnie pobierały ten plik
• W praktyce efekt wdrożenia jest trudny do wyizolowania – nikt nie widział twardego testu A/B pokazującego mierzalny wzrost cytowalności wyłącznie dzięki llms.txt

Praktyczna rekomendacja: tak, możesz wdrożyć llms.txt jako dodatek, ale nie kosztem prawidłowej struktury technicznej strony (SSR, schema.org, poprawny plik robots.txt). Plik powinien zawierać 5–15 najważniejszych zasobów, opisanych zwięźle w naturalnym języku. Kolejność priorytetów: robots.txt → schema.org → SSR/SSG → dopiero potem llms.txt.

Przykład dla agencji SEO:

# Twoja Marka

> Agencja SEO i AI Search Optimization z Warszawy, 15 lat doświadczenia.

## Główne usługi

- [Audyt widoczności AI](/audyt-ai/): pełny raport widoczności marki w ChatGPT, Claude, Gemini, Perplexity, plan działania na 90 dni
- [Pozycjonowanie](/seo/): klasyczne SEO dla branży e-commerce i SaaS
- [Content marketing](/content/): produkcja treści zoptymalizowanych pod GEO

## Wiedza

- [Co to jest GEO](/geo/czym-jest-geo/): definicja, różnice względem SEO
- [Query fan-out w trybie Google AI](/geo/query-fan-out/): jak działa pobieranie danych w AI Mode

## Kontakt

- [Bezpłatna konsultacja](/kontakt/): 30-minutowa rozmowa, bez zobowiązań

Zawartość świadomie krótka, w naturalnym języku, z linkami do najważniejszych zasobów. Model LLM, który czyta ten plik, dostaje kompletną mapę firmy w 30 sekund.

Treści renderowane przez JavaScript – cichy zabójca widoczności w AI

Najczęstsza techniczna przyczyna, dla której strony nie pojawiają się w odpowiedziach LLM, mimo poprawnego robots.txt, to treści renderowane przez JavaScript (JavaScript-rendered content). Boty AI, w przeciwieństwie do współczesnego Googlebota, nie wykonują JavaScriptu. Lub wykonują go bardzo słabo, zwykle z dużym limitem czasu (timeoutem).

Konsekwencja: jeśli Twoja strona jest zbudowana w React/Vue/Angular bez SSR (renderowania po stronie serwera), to większość treści, którą widzi użytkownik w przeglądarce, jest niewidoczna dla bota AI. Bot dostaje pusty <div id="root"> i nic więcej.

Test, który wykonujemy w pierwszej fazie audytu:

curl -A "GPTBot" https://twojadomena.pl/blog/jakistitle

Sprawdzasz, czy w odpowiedzi jest faktyczny tekst artykułu, czy szkielet aplikacji. Jeśli szkielet, masz problem.

Trzy standardowe rozwiązania:

• Renderowanie po stronie serwera (SSR) – najczystsze podejście. Next.js, Nuxt, SvelteKit, Astro, Remix generują pełen HTML po stronie serwera. Bot dostaje gotowy tekst, JavaScript jest tylko warstwą interaktywności
• Generowanie statycznych stron (SSG) – dla treści, które rzadko się zmieniają. Blog, dokumentacja, strony marketingowe – generujesz statyczne pliki HTML przy budowie, bot dostaje pełny tekst bez dynamiki
• Renderowanie wstępne / dynamiczne (pre-rendering) – dla aplikacji SPA, których nie da się zrefaktoryzować. Usługa pre-renderingu albo własny middleware rozpoznaje bota po user-agencie i serwuje mu wyrenderowany HTML, a użytkownik z przeglądarką dostaje klasyczne SPA

Schema.org dla modeli LLM – cztery typy, które dają wzrost

Modele LLM czytają dane strukturalne (JSON-LD) i używają ich jako szybkiego sposobu na zrozumienie kontekstu strony. Cztery typy, które w naszych testach dają mierzalny wzrost cytowalności:

Modele LLM bardzo lubią FAQPage – każde pytanie z parą Question + Answer to gotowy fragment Q&A, który można podzielić na czyste podzapytania.

Plan implementacji w 30 dni

Praktyczny harmonogram wdrożenia pełnej obsługi botów AI dla średniej strony korporacyjnej. Każdy tydzień ma konkretny rezultat.

1. Tydzień 1: audyt obecnego stanu – test curl -A "GPTBot" na 10–15 najważniejszych adresach URL, sprawdzenie obecnego robots.txt, identyfikacja ścieżek z treściami renderowanymi w JS
2. Tydzień 2: konfiguracja robots.txt i llms.txt – dopuszczenie wszystkich oficjalnych botów, stworzenie llms.txt z 8–15 najważniejszymi zasobami
3. Tydzień 3: wdrożenie schema.org – Article, Person, Organization, FAQPage. Walidacja przez Google Rich Results Test i Schema.org Validator
4. Tydzień 4: rozwiązanie problemu JavaScript (jeśli istnieje) – migracja na SSR (jeśli realna) lub konfiguracja pre-renderingu

Po 30 dniach robisz re-test: curl -A "GPTBot" zwraca pełny tekst, schema.org przechodzi walidację na wszystkich podstronach, llms.txt zawiera ponad 10 adresów URL. Trzy miesiące później widzisz wzrost wskaźnika cytowań (Citation Rate) w 4 silnikach AI.

Co warto sprawdzić w pierwszej kolejności?

Konfiguracja botów AI to zadanie, które najlepiej wykonać raz a dobrze. Większość problemów technicznej widoczności w AI sprowadza się do prostych list kontrolnych: które boty dopuszczam, czy mam SSR, czy mam wdrożone dane strukturalne. Zaniedbanie tych podstaw oznacza, że nawet najlepsza strategia contentowa nie zadziała – bo model LLM po prostu Twojej strony nie widzi.

W audycie technicznym widoczności AI w ICEA pierwsza godzina to weryfikacja, czy boty AI fizycznie dostają tekst. Jeśli nie, cała reszta jest budowaniem na piasku. Jeśli chcesz sprawdzić, czy boty AI mają dostęp do Twojej strony, Dostęp botów AI odpyta robots.txt o 14 botów AI (13 z tej listy plus OAI-AdsBot) i da Ci tabelę allowed/disallowed plus listę najważniejszych zmian do wdrożenia – w 30 sekund, bez logowania.