Jak ustawić sygnały dla agentów AI w WordPressie i Divi 5 — robots.txt, llms.txt i monitoring ruchu

W poprzednim wpisie koncepcyjnym pokazałem, że filar trzeci agent-readiness przestał być pytaniem „jak być znalezionym przez agenta”, a stał się pytaniem „kogo wpuścić i jak sprawdzić kto tu jest”. Ten wpis pokazuje jak to pytanie zamienić w konkretną konfigurację na twojej stronie — w WordPressie, z Divi 5 jako builderem, niezależnie od tego, czy masz sklep WooCommerce, czy blog z treściami autorskimi.

Trzy obszary, które pokrywam. Pierwszy — robots.txt z user-agentami AI, bo to jest jedyny sygnał, który naprawdę działa u wszystkich. Drugi — llms.txt, bo to jest propozycja z rosnącą adopcją i niskim kosztem wdrożenia. Trzeci — monitoring ruchu agentowego, bo bez tego wszystkie inne decyzje są w ciemno. Każdy z tych obszarów ma własne pułapki w środowisku WordPressa, i każdy mogę pokryć tylko dlatego, że wcześniejsze serie na WebFluxie (o semantyce, dostępności, Divi) ustawiły kontekst, w którym to ma sens.

Obszar pierwszy — robots.txt dla botów AI w WordPressie

WordPress ma z robots.txt nietypową relację. Domyślnie żaden fizyczny plik robots.txt nie istnieje w rootcie instalacji. Zamiast tego WordPress generuje go dynamicznie za każdym razem, kiedy ktoś (albo jakiś bot) odwiedza twojadomena.pl/robots.txt. To jest tzw. virtualny robots.txt, i wrzucany jest do niego minimalny zestaw reguł plus to, co dodadzą wtyczki i motyw.

Oznacza to dwie rzeczy. Po pierwsze — nie znajdziesz tego pliku przez FTP. Po drugie — jeśli chcesz go zmienić, masz trzy drogi: przez filtr w kodzie (motyw dziecka lub własna wtyczka), przez wtyczkę SEO (Yoast, Rank Math), albo przez fizyczne nadpisanie (jeśli plik fizyczny istnieje, WordPress przestaje generować wirtualny).

Najpierw — zestaw user-agentów AI, które warto znać. To nie jest lista wyczerpująca, ale pokrywa głównych graczy:

• GPTBot — crawler OpenAI zbierający dane do trenowania modeli.
• ChatGPT-User — agent ChatGPT-a wywoływany na żądanie użytkownika, żeby pobrać konkretną stronę do odpowiedzi.
• OAI-SearchBot — crawler stojący za funkcją wyszukiwania w ChatGPT.
• ClaudeBot — crawler Anthropica.
• Claude-User i Claude-SearchBot — analogicznie jak u OpenAI, dla konkretnych funkcji Claude.
• PerplexityBot — główny crawler Perplexity.
• Google-Extended — sygnał dla Google: „nie trenuj Gemini na mojej treści” (ten sam bot Googlebot wciąż ma dostęp do indeksowania).
• Bytespider — crawler ByteDance (w tym TikTok, Doubao).
• Amazonbot — crawler Amazona używany między innymi do treningu Alexy i Rufusa.
• Meta-ExternalAgent i FacebookBot — crawlery Meta.

Ważne rozróżnienie: niektóre firmy rozdzielają user-agent dla treningu modelu od user-agenta dla agenta działającego na żądanie użytkownika. OpenAI ma GPTBot (trening) i ChatGPT-User (agent). Anthropic ma ClaudeBot(trening) i Claude-User (agent). To rozróżnienie jest kluczowe: możesz zablokować trening, a wpuścić agenta na żądanie. Albo odwrotnie. Większość blokad „jak leci” łapie oba, a to bywa niepotrzebne.

Przykładowa konfiguracja robots.txt dla strony, która chce zablokować trening modeli, ale wpuścić agentów działających na żądanie użytkownika:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: ChatGPT-User
Allow: /

User-agent: Claude-User
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

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

To jest polityka „nie bierz mojej treści do trenowania modeli, ale pozwól agentowi odpowiadać na pytania użytkowników”. Inne strony wybiorą inne polityki. Kluczowe jest, żeby była to decyzja, a nie domyślne ustawienie.

Jak to wdrożyć w WordPressie:

• Yoast SEO ma edytor robots.txt w Yoast SEO → Tools → File editor. Edytujesz i zapisujesz. Yoast podpowie, jeśli coś jest nie tak składniowo.
• Rank Math ma analogiczny edytor w Rank Math → General Settings → Edit robots.txt.
• Bez wtyczki SEO możesz stworzyć fizyczny plik robots.txt w rootcie instalacji (przez FTP albo Menedżer plików w hostingu). Wtedy WordPress przestaje generować wirtualny i używa tego, który postawiłeś.

Dwie pułapki, które warto znać:

Pierwsza — niektóre hosty i wtyczki cache’ujące zamrażają robots.txt w cache. Kiedy coś zmieniasz, a potem sprawdzasz twojadomena.pl/robots.txt i widzisz starą wersję, to nie błąd — to cache. Wyczyść cache wtyczki, cache serwera, czasem cache CDN-a (Cloudflare), i sprawdź ponownie.

Druga — zmiana robots.txt nie jest retroaktywna. Jeśli przez pół roku twoja strona była otwarta dla GPTBot, zmiana na blokadę dziś nie usuwa treści, która już została pobrana i zasilała trening. Blokada działa na przyszłość, nie na to, co już się wydarzyło.

Obszar drugi — llms.txt w WordPressie i Divi

llms.txt to plik markdown, który trafia do rootu strony pod adresem twojadomena.pl/llms.txt. Jego strukturę wymyślił Jeremy Howard z Answer.AI w 2024. Idea jest prosta: zamiast pozwalać agentowi zgadywać, co na twojej stronie jest ważne, dajesz mu krótki, ustrukturyzowany przewodnik. Coś pośredniego między sitemapą a streszczeniem strony w jednym dokumencie.

Format jest luźny, ale zwyczajowo wygląda mniej więcej tak:

# Nazwa strony

> Jedno-dwa zdania opisu strony, kim jest autor, o czym pisze.

## O projekcie

[Link do strony o projekcie](https://twojadomena.pl/o-projekcie/)

## Najważniejsze treści

- [Tytuł wpisu 1](https://twojadomena.pl/wpis-1/): krótki opis
- [Tytuł wpisu 2](https://twojadomena.pl/wpis-2/): krótki opis

## Kontakt

[email/formularz kontaktowy]

Nie ma tu sztywnej składni. Agent, który to czyta, i tak użyje swojego modelu językowego, żeby zrozumieć tekst. Więc nie jest to format typu „schema.org” z wymogami pól. Jest to kurowana mapa strony przygotowana pod agentów, z priorytetem jakości nad kompletnością.

Kilka zasad, które warto zachować:

• Maksymalnie 10-20 linków, nie 200. Jeśli wrzucisz 200, agent dostanie listę podobną do sitemap.xml i wartość dodana spada. Wybierz najważniejsze.
• Krótki opis każdego linku. Jedno zdanie. Agent nie musi klikać, żeby wiedzieć, co tam znajdzie.
• Aktualizacja przy każdej istotnej zmianie treści. llms.txt, który jest z 2024 roku, szybko przestaje opisywać aktualną stronę.
• Ton dopasowany do agenta, nie do Google. To nie jest miejsce na słowa kluczowe. To miejsce na czystą informację, którą agent przekaże użytkownikowi.

Dodatkowo istnieje konwencja llms-full.txt — większy plik z pełniejszą treścią, nie tylko z linkami. To druga warstwa, opcjonalna, dla tych którzy chcą dać agentowi wszystko „do przeczytania” w jednym pliku. Większość stron na razie nie potrzebuje tego, zaczyna się od llms.txt.

Jak wdrożyć w WordPressie:

Opcje wdrożenia llms.txt w WordPressie:

Dedykowana wtyczka „Website LLMs.txt” — generuje plik automatycznie na podstawie struktury strony, z możliwością manualnej edycji. Prosta, specjalizowana.

Yoast SEO — w nowszych wersjach (od jesieni 2024) ma opcję automatycznego generowania llms.txt na podstawie ustawień SEO i wybranych stron. Jeśli już używasz Yoasta, to jest najmniejszy krok.

Rank Math — podobnie jak Yoast, w nowszych wersjach obsługuje llms.txt. Pozwala też na bardziej precyzyjne sterowanie, które typy postów mają się pojawiać.

Motyw dziecka + ręczny kod — najbardziej elastyczny, ale wymaga PHP. Kilkadziesiąt linii w functions.phpgenerujących plik na żądanie, albo statyczny plik wrzucony przez FTP.

Statyczny plik w rootcie — najprostsza droga jeśli masz mało zmian. Stwórz llms.txt, wrzuć przez FTP do rootu, aktualizuj ręcznie co kilka miesięcy. Bez wtyczki, bez narzędzi, bez zależności.

Moja osobista rekomendacja dla początkujących: zacznij od statycznego pliku. Kiedy się wdrożysz i będziesz mieć jasność, co powinno w nim być, rozważ wtyczkę. Automatyczne generowanie przez wtyczkę zachęca do wrzucania tam wszystkiego jak leci — a jakość pliku bierze się z kuracji, nie z kompletności.

Jak to weryfikuje się po stronie agenta:

Wejdź na twojadomena.pl/llms.txt w przeglądarce. Powinieneś zobaczyć plik tekstowy (markdown, ale wyświetla się jako plain text). Jeśli widzisz 404 — plik nie istnieje albo serwer go blokuje. Jeśli widzisz stronę WordPressa z komunikatem „404″ — WordPress nie rozumie, że chcesz plik, i próbuje pokazać post. To zazwyczaj znak, że reguły rewritów w .htaccess potrzebują doprecyzowania, albo że używasz dynamicznego generowania przez wtyczkę i coś poszło nie tak.

Jedna rzecz, która w Divi 5 może psuć llms.txt: jeśli masz włączoną globalną ochronę treści (np. przez wtyczkę typu „coming soon” albo ochronę hasłem dla niektórych stron), może ona blokować też dostęp do pliku llms.txt. Agent dostaje 403 zamiast markdown, i zakłada, że pliku nie masz. Sprawdź w konfiguracji takich wtyczek, czy nie obejmują katalogu rootowego.

Obszar trzeci — monitoring ruchu agentowego

Dwa pierwsze obszary to decyzje polityki. Trzeci to pytanie: czy ta polityka odnosi się do rzeczywistego ruchu, czy do teoretycznego. Bo możesz zablokować GPTBot w robots.txt z wielkim zamachem, ale jeśli żaden GPTBot nigdy cię nie odwiedził, niczego tym nie zmieniłeś. Odwrotnie — możesz być przekonany, że żaden agent AI cię nie odwiedza, podczas gdy w logach serwera siedzi miesięcznie kilkanaście tysięcy wizyt Bytespidera albo ClaudeBota.

Dowiedzieć się, kto naprawdę odwiedza twoją stronę, można na trzy sposoby, zależnie od tego, co masz.

Pierwszy sposób — logi serwera WWW. Każdy hosting, nawet najprostszy, zapisuje logi dostępu (access logs). Linia w logu wygląda mniej więcej tak:

66.249.72.1 - - [15/Apr/2026:10:23:45 +0200] "GET /wpis/agent-ready/ HTTP/1.1" 200 28471 "-" "Mozilla/5.0 AppleWebKit (compatible; GPTBot/1.2; +https://openai.com/gptbot)"

Ostatnia część (user-agent) mówi ci, kto przyszedł. W panelu hostingu (cPanel, DirectAdmin, własny panel u dhostingu albo cyber_Folks) powinieneś znaleźć sekcję „Raw logs” albo „Access logs”. Pobierz plik za ostatni miesiąc i użyj narzędzia typu grep albo edytora tekstu, żeby wyszukać konkretne user-agenty:

grep -i "gptbot" access.log | wc -l
grep -i "claudebot" access.log | wc -l
grep -i "perplexitybot" access.log | wc -l

Każda komenda zwraca liczbę wizyt konkretnego bota. Jeśli nie masz dostępu do linii komend, alternatywnie Ctrl+F w edytorze tekstu też załatwi sprawę.

Drugi sposób — Cloudflare. Jeśli twoja strona jest za Cloudflare, masz to dużo wygodniej. W panelu Cloudflare wejdź w Analytics & Logs → Traffic → Bot traffic. Cloudflare rozróżnia boty na klasy — wyszukiwarki, AI, feed readers, malicious — i pokazuje statystyki per klasa. W nowszych panelach (od końca 2025) jest też oddzielna sekcja „AI Crawlers” z rozbiciem per dostawca: ile razy odwiedził cię OpenAI, ile razy Anthropic, ile razy Perplexity.

Cloudflare dodatkowo ma funkcję „AI Crawl Control”, która pozwala zablokować całe klasy botów jednym klikiem, niezależnie od tego, co masz w robots.txt. To jest warstwa operatorska, niezależna od tego, co deklaratywnie napisałeś. Bo robots.txt to prośba, a blokada Cloudflare to ściana.

Trzeci sposób — wtyczki analityczne z rozpoznawaniem botów. Wtyczki typu Wordfence (jeśli masz, głównie dla bezpieczeństwa), Burst Statistics (alternatywa dla Google Analytics), Koko Analytics — niektóre z nich rozpoznają popularne user-agenty AI i pokazują je osobno. To jest najprostszy sposób dla tych, którzy nie chcą grzebać w logach serwera ani nie używają Cloudflare. Minus — każda wtyczka ma swoje ograniczenia, i żadna nie jest tak dokładna jak surowe logi.

Co z tych danych wynika w praktyce:

Jeśli sprawdzisz logi z ostatnich 30 dni i zobaczysz, że:

• Głównie odwiedza cię Googlebot i masz minimum ruchu od agentów AI — nie inwestuj dużo w llms.txt i zaawansowaną konfigurację robots.txt. Zrób podstawy, wróć do tematu za kwartał.
• Masz znaczący ruch od GPTBot, ClaudeBot, PerplexityBot — warto zainwestować w świadome robots.txt, llms.txt, i monitoring. To już jest realny kanał, który możesz kształtować.
• Masz bardzo duży ruch od jednego konkretnego bota (np. tysiące wizyt Bytespidera dziennie) i to cię obciąża — rozważ blokadę albo rate limiting przez hosting/Cloudflare, bo to może być po prostu za dużo jak na twój plan hostingowy.
• Widzisz w logach user-agenty, których nie rozpoznajesz — warto sprawdzić, czy to nie jest ruch podszywający się pod przeglądarkę. Perplexity w sporze z Amazonem pokazało, że niektóre agenty maskują się jako zwykły Chrome.

Co dalej

Filar trzeci w wymiarze Divi-owym jest w dużej mierze niezależny od samego buildera — robots.txt, llms.txt i monitoring to WordPress i hosting, a nie Divi jako takie. Ale w kolejnych filarach to się zmienia. Następny koncepcyjny wpis w serii to filar czwarty — warstwa działania. Czyli to, co agent może zrobić na twojej stronie, kiedy już go wpuściłeś. Tam Divi wraca mocno, bo formularze, przyciski i struktura interakcji to właśnie warstwa, w której builder decyduje o dużej części tego, co widzi agent.

Zasada, która z tego wpisu wynika, jest prosta. Warstwa sygnałów to nie rakietowa nauka. To kilka plików, parę decyzji, godzina-dwie pracy. Ale większość stron dziś ma to w trybie domyślnym — i to oznacza, że polityka wobec agentów jest przypadkiem. W kontekście filaru trzeciego, który jak pokazałem w poprzednim wpisie, staje się warstwą kontroli, a nie tylko widoczności, przypadek jest najdroższą opcją.