W klasycznym SEO discovery jest proste. Google crawluje sieć, indeksuje strony, użytkownik wpisuje zapytanie, algorytm rankingowy decyduje co pokazać. Strona która chce być odkryta optymalizuje pod ten algorytm — treść, linki, szybkość, technikalia.
Agent discovery działa inaczej. Agent który ma wykonać zadanie w imieniu użytkownika nie czeka na wynik wyszukiwania. Aktywnie eksploruje możliwości stron które odwiedza. Pyta: co tu mogę zrobić? Jakie dane są dostępne? Jak mogę się połączyć?
Strona która potrafi na te pytania odpowiedzieć — jest odkrywalna dla agenta. Strona która nie potrafi — jest dla agenta nieprzejrzysta nawet jeśli jest pięknie zoptymalizowana pod klasyczne SEO.
Czym jest agent discovery
Agent discovery to zdolność strony do bycia znalezioną i zrozumianą przez agentów AI — obejmuje pliki llms.txt, dane strukturalne, .well-known endpoints i inne mechanizmy aktywnego informowania agentów o zawartości i możliwościach witryny.
Kluczowe słowo: aktywnego. Agent discovery to nie pasywne bycie indeksowanym — to proaktywne deklarowanie swoich możliwości w miejscach i formatach które agenty rozumieją.
Cztery mechanizmy agent discovery
Mechanizm pierwszy — llms.txt
Najprostszy punkt wejścia dla agentów. Plik Markdown w katalogu głównym który mówi: oto czym jest ten serwis, oto najważniejsze sekcje, oto gdzie szukać konkretnych treści.
Agent który trafi na webflux.pl i sprawdzi webflux.pl/llms.txt dostaje mapę całego serwisu bez konieczności crawlowania każdej strony osobno. To jest discovery na poziomie serwisu.
Mechanizm drugi — .well-known endpoints
Discovery na poziomie możliwości. Agent który sprawdzi /.well-known/ucp wie czy sklep obsługuje agentowy checkout. Agent który sprawdzi /.well-known/agent-skills/index.json wie jakie narzędzia może wywołać. Agent który sprawdzi /.well-known/mcp.json wie jak podłączyć się do MCP servera.
.well-known to przewidywalne miejsce gdzie agent szuka nie treści — ale możliwości. Jaka jest różnica między llms.txt a .well-known? llms.txt mówi „oto co mam”. .well-known mówi „oto co możesz ze mną zrobić”.
Mechanizm trzeci — dane strukturalne i JSON-LD
Discovery na poziomie znaczenia. Strona która ma kompletne Schema.org jest odkrywalna semantycznie — agent który ją odwiedza rozumie natychmiast czym są poszczególne elementy. Produkt z ceną i dostępnością. Artykuł z autorem i datą. Pojęcie z definicją i wariantami nazwy.
Dane strukturalne to nie tylko SEO signal — to mapa znaczeń dla agenta który chce zrozumieć stronę bez długiego parsowania.
Mechanizm czwarty — endpointy API i MCP
Discovery na poziomie danych. Agent który może odpytać webflux.pl/wp-json/webflux/v1/slownik dostaje cały słownik w JSON — 44 pojęcia z definicjami, polskimi nazwami, wariantami i klastrami — w jednym zapytaniu. Agent który podłączy się do MCP servera webflux.pl może wywołać search_term, get_term, list_clusters — jak funkcje, nie jak crawlowanie.
To jest discovery na poziomie infrastruktury — strona wystawia maszynowo czytelne interfejsy które agent może użyć bezpośrednio.
Hierarchia — od prostego do zaawansowanego
Warto myśleć o agent discovery jako o hierarchii warstw które można wdrażać stopniowo.
Poziom 1 — treść dostępna bez JavaScript. Podstawa. Jeśli agent nie może odczytać strony bez renderowania JS — discovery na wyższych poziomach nie ma znaczenia. To jest filar 1 — czytelność.
Poziom 2 — llms.txt. Tygodniowa praca, zero kosztu. Plik tekstowy który daje agentowi mapę serwisu. Każdy serwis powinien to mieć.
Poziom 3 — dane strukturalne. Schema.org, JSON-LD, kompletne Product dla sklepów, DefinedTerm dla słowników, Articledla artykułów. To jest filar 2 — struktura danych.
Poziom 4 — .well-known endpoints. Dla serwisów które mają coś konkretnego do zaoferowania agentom — checkout przez UCP, narzędzia przez Agent Skills, API przez MCP info.
Poziom 5 — MCP server lub REST API. Dla serwisów które chcą być odpytywane bezpośrednio przez agentów — jak webflux.pl ze słownikiem. Agent może wyszukiwać, pobierać definicje, listować klastry — przez standardowy interfejs.
Webflux.pl ma dziś poziomy 1-5. To jest rzadkość w polskim internecie i właśnie dlatego ten serwis jest wzorcowym przykładem agent-readiness który opisuje.
Agent discovery a klasyczne SEO discovery — co się różni
W klasycznym SEO discovery jest jednostronne. Googlebot crawluje, indeksuje, Google decyduje co pokazać. Właściciel strony optymalizuje żeby być wyżej w rankingu — ale nie ma bezpośredniego kanału komunikacji z algorytmem.
Agent discovery jest dwustronne. Strona aktywnie deklaruje swoje możliwości. Agent aktywnie pyta o nie. To jest negocjacja możliwości — jak opisuje artykuł o UCP, agent i sklep porównują swoje profile i ustalają co mogą razem zrobić.
Ta dwustronność zmienia logikę optymalizacji. W SEO optymalizujesz pod algorytm którego nie kontrolujesz i nie możesz zapytać. W agent discovery deklarujesz możliwości w standardowych miejscach i czekasz aż agenty je znajdą i wykorzystają.
Praktyczny test agent discovery dla każdej strony
Cztery pytania które dają szybki obraz:
1. Czy masz llms.txt? Sprawdź twojastrona.pl/llms.txt. Jeśli 404 — brakuje podstawowego punktu wejścia dla agentów.
2. Czy masz dane strukturalne? Wklej URL w Rich Results Test. Jeśli zero rich results — agent nie ma danych strukturalnych do przetworzenia.
3. Czy masz coś pod .well-known? Sprawdź twojastrona.pl/.well-known/. Jeśli 404 lub pusty katalog — nie deklarujesz żadnych możliwości dla agentów.
4. Czy masz API lub endpoint JSON? Jeśli tak — czy jest udokumentowany i czy jest w llms.txt lub .well-known?
Każde „nie” to luka w agent discovery — i potencjalnie niewidoczność dla agentów którzy szukają możliwości przed działaniem.
Pojęcia powiązane w słowniku: llms.txt, .well-known, Agent Skills, Dane strukturalne, MCP, Filar 3 — odkrywalność, Agent-readiness, AI crawler
Powiązane artykuły na webflux.pl: Sygnały dla agentów — filar trzeci, Sześć filarów agent-readiness, Jak agent AI robi zakupy — mechanika UCP