Crawlery AI pod kontrolą. Nie tylko llms.txt

Jeśli publikujesz treści w 2026 roku, nie decydujesz już po prostu, czy "wpuszczać AI", czy nie. Duże platformy rozdzieliły boty do różnych zadań: jedne służą do treningu modeli, inne do wyników wyszukiwania, a jeszcze inne pobierają strony na żądanie użytkownika. To zmienia praktyczną decyzję wydawcy. Nie wystarczy dodać `llms.txt` i uznać temat za zamknięty. Trzeba osobno ustalić, komu dajesz dostęp dla zasięgu, komu go odcinasz dla ochrony treści i jak później sprawdzasz, czy te reguły naprawdę działają.

To ważna zmiana dla redakcji, content managera i właściciela serwisu. Kontrola nad crawlerami AI schodzi dziś z poziomu czysto technicznego pliku na poziom polityki wydawcy: co ma pracować na widoczność, a co nie powinno zasilać cudzych modeli bez zwrotu.

Dlaczego llms.txt nie rozwiązuje problemu dostępu

`llms.txt` pomaga modelom zrozumieć strukturę serwisu, ale nie służy do blokowania dostępu. Specyfikacja opisuje go jako plik, który ma dostarczać informacji przy korzystaniu z witryny "at inference time", a nie jako mechanizm kontroli crawlowania.

To podstawowa różnica, którą wiele tekstów w Polsce wciąż miesza. `llms.txt` porządkuje kontekst dla modelu. `robots.txt` mówi botowi, czy i gdzie może wejść. Oba pliki mogą się uzupełniać, ale nie robią tego samego.

Dlatego serwis może mieć poprawne `llms.txt` i jednocześnie nie mieć żadnej realnej kontroli nad tym, kto pobiera treść do treningu, kto do wyszukiwania, a kto na żądanie użytkownika.

Co naprawdę się zmieniło: boty są dziś rozdzielone według funkcji

Nowość nie polega na samym istnieniu crawlerów AI, tylko na tym, że duże platformy coraz wyraźniej rozdzielają ich role. To daje wydawcy bardziej granularną decyzję niż proste "AI tak albo nie".

OpenAI rozróżnia dziś `GPTBot` do treningu modeli i `OAI-SearchBot` do wyników wyszukiwania w ChatGPT. W praktyce możesz dopuścić widoczność w ChatGPT Search, a jednocześnie zablokować wykorzystanie treści do treningu. Anthropic opisuje podobny podział na `ClaudeBot`, `Claude-SearchBot` i `Claude-User`. Perplexity rozdziela `PerplexityBot`, który zasila wyniki wyszukiwania, od `Perplexity-User`, który pobiera stronę na żądanie użytkownika.

Google działa jeszcze inaczej. `Google-Extended` nie jest osobnym crawlerem HTTP, tylko tokenem w `robots.txt`, który pozwala określić, czy treść zebrana przez Google może być używana do przyszłych generacji modeli Gemini i do grounding. Apple z kolei rozdziela `Applebot` od `Applebot-Extended`, przy czym ten drugi nie crawluje stron samodzielnie, tylko steruje tym, jak Apple może użyć już zebranych danych.

To oznacza jedną rzecz: w 2026 roku kontrola nad crawlerami AI nie sprowadza się do jednej listy botów. Trzeba rozumieć, który bot odpowiada za trening, który za widoczność w odpowiedziach, a który działa na żądanie użytkownika.

Gdzie ustawić kontrolę: robots.txt, meta tagi i logi

Pierwszą warstwą kontroli pozostaje `robots.txt`. To tam ustawiasz dostęp dla botów takich jak `GPTBot`, `OAI-SearchBot`, `ClaudeBot` czy `PerplexityBot`.

Prosty przykład dla treningu OpenAI wygląda tak:

User-agent: GPTBot
Disallow: /

Jeśli chcesz dopuścić widoczność w wyszukiwaniu ChatGPT, ale bez treningu, rozdzielasz reguły:

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

To jednak nie zamyka całego tematu. Część platform ma też fetchery uruchamiane przez użytkownika. OpenAI zaznacza, że przy `ChatGPT-User` reguły `robots.txt` mogą nie mieć zastosowania, bo takie pobranie wynika z działania użytkownika. Perplexity pisze podobnie o `Perplexity-User`. Apple dodaje jeszcze warstwę `nosnippet`, która może wyłączyć użycie treści jako dodatkowego kontekstu w odpowiedziach generowanych przez ich systemy.

Dlatego sama edycja `robots.txt` nie wystarcza. Potrzebujesz jeszcze logów serwera albo reguł w WAF, żeby sprawdzić, które boty faktycznie odwiedzają serwis, z jaką częstotliwością i które sekcje pobierają. Raporty Google nie zastąpią tu pełnej analizy, bo nie pokażą ci osobno ruchu od GPTBot czy PerplexityBot.

Nie każdy bot daje ten sam zwrot

Najgorsza decyzja to wrzucić wszystkie crawlery AI do jednego worka. Dla wydawcy liczy się nie sama etykieta "AI", tylko funkcja konkretnego bota.

Bot treningowy zbiera treść po to, by poprawiać model. Taki ruch nie daje ci bezpośrednio widoczności w odpowiedzi ani odwiedzin. Bot wyszukiwawczy ma inny cel: ma znaleźć i przywołać źródło w odpowiedzi użytkownika. To nadal nie gwarantuje kliknięcia, ale przynajmniej daje szansę na cytowanie i wejście. Bot uruchamiany przez użytkownika to jeszcze inny przypadek, bo pobiera stronę wtedy, gdy ktoś już zadał pytanie i system chce sprawdzić źródło.

Dla content managera oznacza to prostą zasadę. Nie pytaj "czy blokować AI". Pytaj: który bot ma pracować na zasięg, który na cytowanie, a który tylko pobiera treść bez jasnego zwrotu dla serwisu.

Jak podjąć decyzję jako wydawca

Dobra polityka nie zaczyna się od pliku, tylko od celu biznesowego serwisu. Dopiero potem wybierasz reguły techniczne.

Jeśli utrzymujesz serwis z reklam lub leadów, możesz chcieć dopuścić boty wyszukiwawcze i pilnować, czy pojawia się z tego ruch lub cytowania. Jeśli chronisz treści premium, raporty, płatne archiwum albo własne analizy, argument za blokowaniem botów treningowych jest mocniejszy. Jeśli nie mierzysz żadnego zwrotu z AI search, decyzja o pełnym otwarciu zwykle jest bardziej zgadywaniem niż strategią.

W praktyce warto zacząć od trzech pytań:

• Czy ten bot wspiera wyszukiwalność i cytowanie, czy tylko trening modelu?
• Czy dana sekcja serwisu ma wartość archiwalną, leadową albo płatną?
• Czy mam sposób, by później sprawdzić w logach lub analityce, czy dostęp cokolwiek mi zwrócił?

Dopiero po takiej odpowiedzi `robots.txt` przestaje być techniczną formalnością, a staje się zapisanym wyborem wydawcy.

Co to oznacza dziś w Polsce

Polski wydawca nie potrzebuje dziś idealnego standardu rynkowego, żeby zacząć działać. Potrzebuje prostej polityki dostępu i regularnej kontroli logów.

Najrozsądniejszy pierwszy ruch wygląda tak: uporządkuj `robots.txt`, rozdziel boty treningowe od wyszukiwawczych, sprawdź, czy w serwisie są sekcje wymagające mocniejszej ochrony, a potem raz w miesiącu przeglądaj logi lub reguły WAF. To mniej efektowne niż dyskusja o `llms.txt`, ale właśnie tu zaczyna się realna kontrola.

`llms.txt` dalej ma sens jako warstwa porządkująca. Nie zastępuje jednak decyzji o dostępie. W 2026 roku ważniejsze pytanie brzmi nie "czy mamy ten plik", tylko "którym botom naprawdę chcemy otworzyć drzwi".

Źródła

• OpenAI, "Overview of OpenAI Crawlers": https://developers.openai.com/api/docs/bots
• Anthropic, "Does Anthropic crawl data from the web, and how can site owners block the crawler?": https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler
• Google Search Central, "Google’s common crawlers" (`Google-Extended`): https://developers.google.com/crawling/docs/crawlers-fetchers/google-common-crawlers
• Apple, "About Applebot": https://support.apple.com/en-us/119829
• Perplexity, "Perplexity Crawlers": https://docs.perplexity.ai/docs/resources/perplexity-crawlers
• llmstxt.org, "The /llms.txt file": https://llmstxt.org/

Czytaj też: Jak pisać treści B2B dla agentów AI