Mapa standardów agentic web — stan na czerwiec 2026. Nie kolejny przegląd „co to jest llms.txt”, tylko werdykty: co wdrożyć na swojej stronie dziś, co potraktować jako tani zakład, a co spokojnie pominąć.
Jeśli prowadzisz stronę albo sklep i próbujesz nadążyć za agentic web, znasz to uczucie: co kilka miesięcy pojawia się nowy plik albo protokół „dla agentów AI”. Każdy ma własny format, własną stronę i własny manifest. Uczysz się jednego — pojawia się następny, który rozwiązuje, o ile da się to ocenić, ten sam problem. Trochę po swojemu, trochę z kawałków pożyczonych od poprzedników.
Ten tekst nie jest dziewiątym opisem dziewięciu standardów. Jest decyzją. Teza brzmi: z dziewięciu mechanizmów adresowanych dziś do agentów realnie żyją cztery, dwa są zakładem na przyszłość, a trzy możesz zignorować bez żadnych konsekwencji. Poniżej werdykt dla każdego — z uzasadnieniem, ze wskazaniem, kto to faktycznie konsumuje, i z konkretem: co zrobić na typowej stronie opartej o WordPressa.
Jedno kryterium porządkuje całość i warto je poznać przed werdyktami, bo przyda Ci się też przy każdym następnym standardzie, który wypłynie po publikacji tego tekstu: standard żyje wtedy, gdy ma konsumenta z działającym oprogramowaniem po drugiej stronie — a nie wtedy, gdy ma specyfikację i stronę internetową. Dlaczego to kryterium działa i co przewiduje na najbliższe lata, opisuję szerzej w eseju na Senteri (EN). Tutaj — praktyka.
Skąd ten bałagan
Krótko, bo to tło, nie temat. Te dziewięć mechanizmów pochodzi z czterech rodowodów, które nigdy się ze sobą nie umawiały:
z ery crawlerów (robots.txt — 1994, sitemap.xml — 2005), pisanej dla sieci, której jedynym nie-ludzkim czytelnikiem była wyszukiwarka; z resztek semantic webu (schema.org — 2011), które przetrwały, bo Google przez dekadę płacił za nie czynsz w postaci rich snippets; ze świata API (OpenAPI), budowanego dla integracji maszyna–maszyna na długo zanim ktokolwiek powiedział „agent”; i z łat ery LLM 2023–2025 (llms.txt, MCP, NLWeb, agent.json), pisanych przez ludzi, którzy potrzebowali czegoś teraz, a nie po pięciu latach prac grupy roboczej W3C.
Każda nowa warstwa cytuje stare („inspired by robots.txt” pojawia się niemal w każdej propozycji), ale cytowanie to kurtuazja, nie integracja. Stąd wrażenie rozlazłości: dziewięć artefaktów, dziewięć formatów — i jak zaraz zobaczysz, tylko trzy pytania.
Trzy pytania zamiast dziewięciu plików
Połóż te mechanizmy na stole i zapytaj, na jakie pytanie każdy odpowiada:
| Pytanie | Standardy | Natura warstwy |
|---|---|---|
| Kto pyta? — tożsamość i dostęp | robots.txt → (nadchodzące: Web Bot Auth) | jedyna warstwa, która realnie ewoluuje — bo ma model biznesowy: kontrolę ruchu |
| Co czytać? — discovery i treść | sitemap.xml, schema.org, llms.txt | tu wszystko sprowadza się do „podaj tekst w md/json”; konsolidacja nastąpi przez wymarcie słabszych |
| Jak działać? — akcje | OpenAPI/MCP, NLWeb (+ nadchodzące: x402, A2A) | tu plik nie wystarczy: akcja wymaga tożsamości, sesji, autoryzacji, czasem płatności |
Z tej tabeli wynika najważniejsza obserwacja strukturalna tego tekstu. Ścieżka odczytu faktycznie redukuje się do pliku tekstowego — czytanie jest bezstanowe i bezpieczne, więc statyczny plik w katalogu głównym wystarcza. Dlatego połowa „standardów agentic web” to dosłownie pliki .txt. Ścieżka akcji do pliku nie zredukuje się nigdy — bo akcji nie da się wykonać bez tożsamości i sesji, a pliku Markdown nie podpiszesz w transakcji. Pliki konkurują o uwagę crawlerów; protokoły konkurują o zdolności. To różne rynki, z różną śmiertelnością — i stąd różne werdykty poniżej.
Jest jeszcze czwarte pytanie, którego w czerwcu nie było widać: kto wykonuje? Nie dotyczy ono tego, co publikujesz na swojej stronie, tylko tego, co importujesz do własnego orkiestratora agentów — i dlatego nie mieści się w tej tabeli. Opisuję je w aktualizacji z sierpnia na końcu tekstu.[dop. 7.08.2026]
Werdykty — standard po standardzie
Format każdego werdyktu: status → kto to konsumuje → co zrobić na WordPressie.
1. robots.txt — ŻYJE, ale zmienia sens
Kto konsumuje: każdy crawler, jaki kiedykolwiek powstał — trzydzieści lat konsumentów. Ale uwaga: dla agentów AI robots.txt przestaje być polityką dostępu, a staje się deklaracją intencji, którą część botów respektuje, część negocjuje, a część ignoruje. To temat na osobny tekst — po angielsku opisany na Senteri.
Co zrobić na WP: mieć, utrzymywać i — to nowość względem starego SEO — prowadzić sekcje per-bot: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot. Decyzja „kogo wpuszczam do treningu, kogo do odpowiedzi, kogo wcale” to dziś decyzja biznesowa, nie techniczna. → Generator robots.txt na iFox, wpis w słowniku.
2. sitemap.xml — ŻYJE, nudny, bezdyskusyjny
Kto konsumuje: wszystkie wyszukiwarki, większość crawlerów AI.
Co zrobić na WP: nic ponad to, co już masz — generuje go każdy plugin SEO. Jedna rzecz do sprawdzenia: czy sitemap obejmuje wszystko, co agent powinien przeczytać (typowy grzech: wykluczone taksonomie albo strony ofertowe poza mapą).
3. schema.org — ŻYJE i awansuje
Kto konsumuje: Google od dekady; coraz częściej — agenci, dla których markup staje się podstawowym kanałem danych, ważniejszym niż widoczna treść. Dla sklepu Product/Offer to dziś być albo nie być: agent zakupowy, który nie znajdzie ustrukturyzowanej ceny i dostępności, po prostu pominie ofertę.
Co zrobić na WP: nie „dodać schema”, tylko zaudytować to, co już wysyłasz. Większość markupu na WordPressie generują automatycznie pluginy i motywy — i częściowo jest on przypadkowy lub nieaktualny, co pokazał świeży dataset Google (pisałem o tym tutaj). Sprawdź zwłaszcza: czy ceny i dostępność w markupie zgadzają się z widoczną treścią. → Generator schema na iFox.
4. OpenAPI / MCP — ŻYJE; jedyny standard z realną grawitacją
Kto konsumuje: po stronie MCP — klienci, którzy faktycznie działają (Claude i rosnący ekosystem), oraz tysiące serwerów; po stronie OpenAPI — cały świat integracji API, który istniał przed agentami. MCP nie wygrał elegancją, wygrał matematyką ekosystemu: każdy nowy klient czyni serwery cenniejszymi i odwrotnie.
Co zrobić na WP: zależy, kim jesteś. Strona firmowa/blog: to jeszcze nie Twój problem — Twoją warstwą akcji są na razie formularze i czytelny HTML. Sklep lub SaaS: to jest warstwa, na której rozegra się Twoja obecność w agentic commerce — zacznij od zrozumienia, co mógłbyś wystawić jako narzędzie. → MCP na części pierwsze.
5. llms.txt — ROKUJE, z dużą gwiazdką
To najciekawszy przypadek na liście, bo ma wszystko oprócz tego konsumenta, dla którego ludzie go wdrażają.
Stan danych (czerwiec 2026): adopcja 10,13% w badaniu SE Ranking na ~300 tys. domen — i to jest pomiar najłaskawszy; węższe crawle (top 10 tys. domen Tranco, 105 tys. stron hotelowych) dają 6–7%. Efekt na cytowania w AI: brak. Z 50 najczęściej cytowanych przez AI domen plik miała jedna; usunięcie zmiennej llms.txt z modelu predykcyjnego SE Ranking poprawiło jego dokładność; w 90-dniowym eksperymencie logowym Otterly.AI tylko ~0,1% wizyt botów AI w ogóle dotknęło pliku. Żaden duży crawler AI oficjalnie nie potwierdził konsumpcji.
Ale: llms.txt ma konsumenta — tylko innego. Czytają go narzędzia deweloperskie i frameworki RAG (Cursor, Continue, Aider). Plik żyje dokładnie w tej niszy, w której ktoś go faktycznie pobiera, i jest martwy wszędzie indziej.
Status w narzędziach Google: audyt „Agentic Browsing” sprawdzający m.in. llms.txt wszedł do domyślnej konfiguracji Lighthouse (od wersji 13.3, maj 2026) — ale uwaga: w samym Chrome zobaczysz go na razie tylko w buildach Canary, nie w stabilnym DevTools. Obecność w audycie to sygnał zainteresowania Google, nie potwierdzenie konsumpcji.
Werdykt i co zrobić na WP: tani hedge. Wdrożenie to kwadrans (generator na iFox), szkody zero, więc warto mieć — zwłaszcza jeśli Twoja treść to dokumentacja, oferta B2B albo cokolwiek, co czytają narzędzia deweloperskie. Ale: nie traktuj go jako zależności, nie raportuj nikomu jako „działania AI SEO” i nie płać żadnej agencji za „optymalizację llms.txt” — dane nie dają na to żadnego pokrycia.
6. NLWeb — ROKUJE, jako most, nie konkurent
Kto konsumuje: ekosystem Microsoftu; adopcja wczesna.
Czym to jest naprawdę: nie nową warstwą, tylko mostem między dwoma ocalałymi — bierze dane schema.org, które już publikujesz, i zamienia je w endpoint, który agent może odpytywać naturalnym językiem (z MCP pod spodem). Mosty to uczciwa infrastruktura, ale żyją dokładnie tak długo, jak oba brzegi — los NLWeb nie jest w rękach NLWeb.
Co zrobić na WP: obserwować. Wdrażać tylko, jeśli masz już dopracowane, rozbudowane schema.org i zależy Ci na ekosystemie Microsoftu. Dla typowej strony: za wcześnie.
7. agent.json — IGNORUJ (na razie)
Propozycja pliku deklarującego agentom „skrzynkę” i intencje strony. Pomysł sensowny, konsument — żaden. Specyfikacja ze stroną internetową, bez działającego oprogramowania, które by ją czytało. Wróci do tego tekstu w aktualizacji, jeśli to się zmieni.
8. agents.txt — IGNORUJ (na razie)
Manifest/polityka wobec agentów — eksperyment bardziej polityczny niż techniczny. Gestykuluje w stronę warstwy, której sieć faktycznie będzie potrzebować (zasady, nie tylko allow/disallow), ale dziś nie czyta go nic. Tę realną potrzebę zagospodaruje raczej linia Web Bot Auth (niżej) niż kolejny plik tekstowy.
9. Web Verbs — IGNORUJ
Akademicka próba nazwania i staksonomizowania akcji, które agent może wykonać na stronie. Intelektualnie ciekawa, wdrożeniowo pusta: brak konsumenta, brak narzędzi, brak presji rynkowej. Jeśli kiedyś warstwa akcji doczeka się wspólnego słownika czasowników, prędzej wyrośnie on z praktyki MCP niż z tej propozycji.
Aktualizacja, sierpień 2026: dziesiąty standard nie mieści się w tabeli
Napisałem w czerwcu, że dziesiąty standard się pojawi i że warto przyłożyć do niego to samo kryterium. Pojawił się szybciej, niż zakładałem — i przy pierwszym podejściu okazało się, że kryterium działa, ale tabela nie.
Agent Companies to standard ogłoszony 17 marca 2026 wraz z narzędziem companies.sh. Definiuje przenośną organizację agentów: org chart, role, zależności, umiejętności, reguły nadzoru — całość do zaimportowania i wyeksportowania jedną komendą. Rozszerza wcześniejszy standard Agent Skills (skills.sh), opisujący pojedyncze umiejętności agenta.
Przyłóżmy kryterium. Czy ma konsumenta z działającym oprogramowaniem po drugiej stronie? Ma, i to nie jednego: orkiestrator Paperclip z ponad 75 tysiącami gwiazdek, oficjalny katalog firm na GitHubie, społecznościowy rejestr wtyczek raportujący 182 tysiące pobrań npm tygodniowo oraz komercyjny sklep z 248 produktami. To nie jest specyfikacja ze stroną internetową. To działa i ma dystrybucję na czterech niezależnych kanałach.
Według kryterium z tego tekstu: ŻYJE.
A jednak nie znajdziesz go w tabeli powyżej — i powód jest ciekawszy od samego werdyktu.
Czwarte pytanie: kto wykonuje
Trzy pytania porządkujące ten tekst — kto pyta, co czytać, jak działać — dotyczą tego, co publikujesz na swojej stronie, żeby agent ją zrozumiał. Jesteś stroną odwiedzaną.
Agent Companies odpowiada na pytanie z drugiej strony lustra: co importujesz do swojego orkiestratora, żeby agent zaczął pracować. Jesteś stroną, która agenta uruchamia.
To nie jest niuans terminologiczny, bo z tej różnicy wynika odwrotny profil ryzyka.
Standardy strony przenoszą dane do odczytu. Czytanie jest bezstanowe i bezpieczne, dlatego połowa z nich to dosłownie pliki tekstowe w katalogu głównym — najgorsze, co może się stać przy błędzie w llms.txt, to że agent przeczyta nieaktualny opis.
Standardy agenta przenoszą kod do wykonania. Opisywaliśmy na cyberflux.pl, że w tych systemach plik opisujący agenta nie jest konfiguracją, tylko programem — może wskazać adapter procesu i podać dowolną komendę wraz z argumentami. Import konfiguracji jest wykonaniem.
Dlatego ten standard dostaje jedyny werdykt na całej liście, który brzmi inaczej niż „wdrażaj / obserwuj / ignoruj”.
Werdykt: ŻYJE — ale to nie jest standard dla Twojej strony
Kto konsumuje: orkiestratory agentów, przede wszystkim Paperclip; pośrednio wszystkie narzędzia czytające standard Agent Skills, na którym Agent Companies się opiera.
Co zrobić na WordPressie: nic. Serio nic. To nie jest warstwa, którą publikujesz — nie ma tu pliku do wystawienia ani markupu do poprawienia. Jeśli prowadzisz stronę albo sklep, ten standard Cię nie dotyczy.
Kogo dotyczy: Ciebie, jeśli sam uruchamiasz agenty. I wtedy dotyczy poważnie.
Co zrobić, jeśli uruchamiasz: traktować pobrane konfiguracje jak kod z nieznanego repozytorium, a nie jak ustawienia. Przegląd przed importem. Ewidencja źródła, wersji i osoby zatwierdzającej. Świadomość, że opis agenta zwykle zawiera wskazanie, co ten agent może uruchomić — i że jeden z opublikowanych pakietów w oficjalnym katalogu zawiera 167 agentów.
Warto przy tym wiedzieć, jak wygląda kontrola na poszczególnych kanałach dystrybucji. Katalog oficjalny przyjmuje zgłoszenia społeczności. Rejestr społecznościowy deklaruje wprost, że jest w pełni otwarty i indeksuje nocą każdą paczkę npm z odpowiednim tagiem, bez kolejki przeglądu. Sklep komercyjny sam zaznacza brak powiązania z projektem. Pełną analizę tej warstwy opisaliśmy na cyberflux.pl.
Co to zmienia w mapie
Taksonomia z czerwca była poprawna dla świata, w którym agent jest gościem, a Ty publikujesz. Ten świat nie zniknął — cztery żyjące standardy z tabeli wyżej działają dalej i nadal są tym, co masz wdrożyć na swojej stronie.
Ale obok wyrosła druga rodzina standardów, opisująca sam agentowy warsztat pracy. Dziś to jeszcze dwa artefakty i jeden dominujący konsument. Jeśli kategoria urośnie — a wszystko na to wskazuje, bo orkiestratorów jest już co najmniej sześciu — będzie wymagała własnej mapy, z własnym kryterium.
Bo kryterium „ma konsumenta z działającym oprogramowaniem” wystarcza, kiedy pytamy, czy warto coś opublikować. Kiedy pytamy, czy warto coś uruchomić, dochodzi drugie: kto sprawdził, co jest w środku.
Sekcja dodana 7 sierpnia 2026. Dane o ekosystemie odczytane tego dnia z repozytoriów projektu i stron dystrybutorów. Nie zweryfikowałem, jak szeroko poza opisanym ekosystemem wdrożony jest sam standard Agent Skills (skills.sh) ani czy ma formalną specyfikację niezależną od implementacji.
Czego nie ma w tej tabeli (a będzie głośne)
Cztery rzeczy, które nie są jeszcze „standardami do wdrożenia”, ale wyznaczają kierunek — każda dostanie na webfluxie własny tekst:
Web Bot Auth — kryptograficzne podpisy HTTP identyfikujące agenta, pchane przez graczy infrastrukturalnych (Cloudflare) i procedowane w IETF. To przyszłość pytania „kto pyta” — i jedyna warstwa z modelem biznesowym (kontrola ruchu), więc skonsoliduje się najszybciej.
x402 / płatności agentowe — przyszłość pytania „jak działać” tam, gdzie akcja kosztuje. Bez warstwy płatności agentic commerce pozostaje demem.
A2A — komunikacja agent–agent. Dla właściciela strony na razie abstrakcja; dla architektury rynku — nie.
WebMCP — interakcja agenta ze stroną od środka przeglądarki; opisany już osobno.
Anty-checklista
To, co z całego tekstu warto wynieść, mieści się w czterech linijkach:
- Dziś: robots.txt z sekcjami per-bot · sitemap.xml (sprawdź pokrycie) · audyt istniejącego schema.org (zgodność markupu z treścią).
- Tani hedge (15 minut, zero szkód, zero obietnic): llms.txt.
- Jeśli masz sklep lub SaaS: zaplanuj warstwę akcji (MCP); obserwuj NLWeb i x402.
- Ignoruj do odwołania: agent.json, agents.txt, Web Verbs.
Agent-readiness to praktyka, nie kolekcjonowanie plików. Wdrażaj to, co ma konsumenta z działającym oprogramowaniem po drugiej stronie; resztę obserwuj — a kiedy pojawi się dziesiąty standard (pojawi się), przyłóż do niego to samo kryterium, zanim cokolwiek wdrożysz.
Werdykty w tym tekście noszą datę: czerwiec 2026. Będą aktualizowane — zmiany znajdziesz w changelogu na dole strony.
→ Sprawdź techniczne przygotowanie swojej strony: checker agent-readiness na iFox.pl · Pojęcia z tego tekstu: Słownik Agentic Web
7 sierpnia 2026 — dodana sekcja o standardzie Agent Companies (marzec 2026). Werdykt: ŻYJE, ale poza tabelą — to pierwszy standard opisujący nie stronę odwiedzaną, lecz agenta wykonującego, przez co ma odwrotny profil ryzyka niż pozostałe dziewięć. Numeracja i tytuł bez zmian: doszła kategoria, nie pozycja na liście.
