Dziesięć lat temu dostępność była tematem, który pojawiał się w rozmowach o stronach raczej incydentalnie. Kiedy klient prowadził instytucję publiczną, kiedy ktoś z zespołu interesował się tym prywatnie, kiedy akurat zrobiło się głośno o jakimś pozwie. Przez większość czasu był to temat, który istniał, ale nie decydował o niczym. Strony powstawały, działały, były kupowane i sprzedawane — a pytanie o dostępność pojawiało się na końcu, albo wcale.
Kilka lat później ten sam temat zaczął wyglądać inaczej. Weszły dyrektywy, weszły wymagania dla sektora publicznego, zaczęły się audyty. Dostępność przestała być opcjonalna w dużej części webu. Nie dlatego, że zmienił się nagle sposób myślenia — ale dlatego, że zmieniła się otaczająca sieć infrastruktura: prawo, narzędzia, oczekiwania.
Teraz dzieje się coś podobnego, tyle że nie z dostępnością, a z innym rodzajem „czytelności” strony. Tym razem chodzi o to, czy strona jest zrozumiała i użyteczna nie dla człowieka — ale dla agenta AI, który odwiedza ją w imieniu człowieka. To jest warstwa, której jeszcze nie ma w rozmowach o projektowaniu stron. Jeszcze. Ale zaczyna się pojawiać, i prawdopodobnie za chwilę będzie tym, czym była dostępność dekadę temu — tematem z marginesu, który nagle przestaje być marginesem.
Co to jest agent-readiness
Agent-readiness to pojęcie, które w ostatnich miesiącach zaczęło pojawiać się równocześnie w kilku kontekstach — w dokumentacji Cloudflare, w standardach Google wokół WebMCP, w pierwszych audytach robionych przez zewnętrzne serwisy. Nie jest to jeszcze pojęcie precyzyjnie zdefiniowane, raczej parasol, pod który wpada kilka różnych pytań o tę samą rzecz.
Najkrótsza definicja, jaką da się sformułować, brzmi tak: agent-readiness to zestaw cech strony, który decyduje o tym, czy agent AI potrafi ją skutecznie odczytać, zrozumieć i — jeśli taka jest intencja użytkownika — wykonać na niej działanie.
Trzy rzeczy w tej definicji są ważne i warto je rozpisać osobno.
Odczytać. Agent czyta stronę inaczej niż człowiek i inaczej niż klasyczny bot wyszukiwarki. Nie widzi layoutu. Nie czeka na JavaScript w taki sam sposób. Nie scrolluje. Nie patrzy na hero z dużym zdjęciem i przyciskiem. Wczytuje HTML, czasem markdown, czasem dane strukturalne — i na tej podstawie rekonstruuje sobie, czym w ogóle jest ta strona. Jeśli HTML jest zbudowany semantycznie, agent wie co jest nagłówkiem, co menu, co głównym contentem, co stopką. Jeśli nie — agent zgaduje. I czasem zgadnie źle.
Zrozumieć. Czytanie to za mało. Agent musi jeszcze zrozumieć ofertę, logikę, relacje między elementami. Jaki produkt co robi. Która cena dotyczy czego. Co jest opcją, a co wymogiem. Jakie są warunki dostawy. Co się dzieje po kliknięciu „zamów”. To warstwa, która wymaga czegoś więcej niż czystego HTML — wymaga sensownej informacji, opisów, relacji, często danych strukturalnych w formacie JSON-LD, czasem specjalnych plików typu llms.txt.
Wykonać. I tu wchodzi warstwa, której jeszcze kilka lat temu w ogóle nie było. Agent nie tylko czyta i rozumie — on coraz częściej wykonuje. Zamawia. Rezerwuje. Wysyła formularz. Loguje się. Płaci. I tu pojawia się pytanie, czy strona jest gotowa na to, żeby agent mógł to zrobić bezpiecznie, przewidywalnie, bez przeszkód. Czy formularze są zrozumiałe. Czy nie ma blokad typu captcha dla każdego ruchu. Czy API jest dostępne, czy agent musi naśladować kliknięcia w UI. Czy autoryzacja działa.
Te trzy warstwy — odczytać, zrozumieć, wykonać — to trzy różne rzeczy, które często są mylone. Strona może być świetnie czytelna dla agenta, ale nie pozwalać na żadne działanie. Inna może pozwalać na działanie, ale być tak chaotyczna, że agent nie rozumie oferty. Jeszcze inna może być zrozumiała i operowalna — ale niemożliwa do odczytania, bo cała treść jest za JavaScriptem, który się nie renderuje bez wywołania przeglądarki.
Agent-readiness to stan, w którym wszystkie trzy warstwy działają.
Dlaczego teraz, a nie za trzy lata
Najczęstsza pierwsza reakcja na ten temat brzmi: „spoko, ale to wszystko jest jeszcze w fazie koncepcyjnej, agentów praktycznie nikt nie używa, zajmiemy się tym jak będzie potrzeba”. Rozumiem tę reakcję — sam jeszcze rok temu bym tak myślał. Problem polega na tym, że rzeczywistość z ostatnich miesięcy idzie znacznie szybciej niż narracja o agentach w polskim internecie.
Kilka rzeczy, które wydarzyły się między październikiem 2025 a kwietniem 2026:
OpenAI wspólnie ze Stripe’em ogłosiło Agentic Commerce Protocol i Instant Checkout w ChatGPT. Agent robi zakup bezpośrednio w rozmowie, nie odsyłając użytkownika do sklepu. Google razem z Shopify, Walmartem i dziesiątkami partnerów płatniczych ogłosił Universal Commerce Protocol. Microsoft uruchomił Copilot Checkout, dziś dostępny w USA. Chrome w lutym 2026 udostępnił WebMCP we wczesnym preview — proponowany standard, który pozwala stronie wystawiać agentowi zestaw „narzędzi”, czyli akcji, które agent może wykonać bezpośrednio, bez zgadywania po DOM-ie. Cloudflare wprowadził Markdown for Agents, który ma redukować ruch zużywany przez agenty na odczyt stron nawet o osiemdziesiąt procent.
To już nie są wyłącznie zapowiedzi. Część tych rozwiązań działa dziś produkcyjnie (Markdown for Agents, Copilot Checkout w USA), część jest dostępna w programach wczesnego dostępu lub pierwszych wdrożeniach (WebMCP, UCP u partnerów Google), część jest w fazie, w której platformy dopiero zaczynają dodawać wsparcie (WooCommerce pracuje nad własnym MCP dla zarządzania sklepem, natywne wsparcie UCP to wciąż przedmiot dyskusji w community). Równolegle pojawił się pierwszy Agent Readiness Score od Cloudflare (isitagentready.com), który audytuje stronę pod kątem gotowości dla agentów. Istnieją też narzędzia typu Factory.ai Agent Readiness — ale warto pamiętać, że te akurat oceniają gotowość repozytorium kodu dla asystentów programistycznych, a nie gotowość strony internetowej dla agentów działających w imieniu użytkownika. To są dwa różne „readiness”, które czasem mylnie wrzuca się do jednego worka.
Druga rzecz, która zmienia perspektywę czasową, to adopcja przez użytkowników. ChatGPT ma dziś funkcję zakupów. Claude ma oficjalną wtyczkę do Chrome’a. Perplexity ma własną przeglądarkę Comet. ChatGPT Atlas od OpenAI powstał właśnie po to, żeby agent mógł działać na stronach. To są narzędzia, z których ludzie już teraz korzystają — nie w ogromnej skali, ale w rosnącej.
I tu wchodzi najważniejsza rzecz: okno, w którym opłaca się przygotować stronę, jest otwarte teraz, a nie wtedy, kiedy wszyscy będą już gotowi. Z dostępnością stało się dokładnie to samo. Strony, które zrobiły ten krok wcześnie, były gotowe kiedy weszła regulacja. Strony, które czekały, musiały nadrabiać w pośpiechu, często gorzej i drożej.
W przypadku agent-readiness nie chodzi o regulację (jeszcze). Chodzi o to, że w momencie, kiedy agent zaczyna stawać się realnym kanałem wejścia na strony — a pierwsze oznaki tego widzimy już teraz — strona nieprzygotowana jest stroną niewidoczną. Nie chodzi o pozycję w Google. Chodzi o to, że użytkownik prosi swojego agenta „zamów mi to”, a agent wybiera tę stronę, która jest czytelna, nie tę, która jest ładniejsza.
Dlaczego dostępność to dobra analogia (i dlaczego tylko częściowo)
Porównanie do dostępności sprzed dekady ma sens, ale też ma swoje granice. Warto je wyłożyć, bo to pokazuje, co się w najbliższych latach będzie działo.
Punkty wspólne są trzy. Pierwszy — obie rzeczy polegają na uczynieniu strony czytelną dla czegoś innego niż standardowy, widzący, klikający użytkownik. Dostępność robi to dla osób korzystających z czytników ekranu, sterowania głosem, nawigacji klawiaturą. Agent-readiness — dla oprogramowania, które działa w imieniu człowieka. Oba wymagają tego samego fundamentu: sensownego HTML-a, opisanych obrazów, logicznej struktury, formularzy z etykietami.
Drugi punkt wspólny — oba tematy są początkowo ignorowane, potem nagle ważne. I oba nagradzają tych, którzy weszli wcześnie, a karają tych, którzy czekali. W dostępności karą były pozwy, straty kontraktów publicznych, dramatyczne audyty. W agent-readiness karą będzie niewidzialność — dla agenta, dla ChatGPT, dla wyszukiwań generatywnych.
Trzeci — oba tematy bardzo ładnie się składają. Dostępność nie jest oderwana od SEO. SEO nie jest oderwane od agent-readiness. Dobra semantyka HTML jest pierwszym krokiem do wszystkich trzech. Oznacza to, że jeśli robisz jedną rzecz porządnie, pomagasz sobie w pozostałych dwóch — nawet bez świadomej intencji.
Gdzie jest granica analogii. Dostępność opierała się głównie na HTML i atrybutach ARIA — warstwa semantyczna i nawigacyjna. Agent-readiness to warstwa szersza. Obejmuje HTML, ale też dane strukturalne, specjalne pliki konfiguracyjne (llms.txt, agents.json, agent-permissions.json), czasem API, czasem wystawione narzędzia WebMCP, czasem zupełnie osobny endpoint markdown. Obejmuje też warstwy, których w dostępności nie było: tożsamość agenta, zaufanie, monetyzacja ruchu agentowego, zgoda na działanie w imieniu użytkownika.
Inaczej mówiąc — agent-readiness jest większy niż dostępność. Wymaga decyzji, których wcześniej nie musieliśmy podejmować. Kto ma prawo robić zakup przez agenta. Jakim agentom dajesz dostęp, a którym nie. Czy pozwalasz na crawlowanie za darmo, czy uruchamiasz pay-per-crawl. Jak sprawdzasz, że agent jest tym, za kogo się podaje. To są pytania spoza klasycznego SEO i klasycznej dostępności.
Z czego składa się agent-readiness — szkic filarów
W kolejnych wpisach rozpiszę każdy filar osobno. Tutaj podaję tylko mapę, żebyś miał widok z lotu ptaka.
Warstwa czytelności — czy strona renderuje się bez JavaScript, czy HTML jest semantyczny, czy nagłówki mają hierarchię, czy treść jest w czystym tekście, a nie zaszyta w grafikach. To fundament. Bez tego nic dalej nie działa.
Warstwa struktury danych — JSON-LD, schema.org, dane o produktach, cenach, wydarzeniach, artykułach. Bez tego agent widzi tekst, ale nie wie, co to znaczy. „To słowo to cena, ta liczba to waga, ten akapit to opis produktu” — tego się agent dowiaduje z danych strukturalnych.
Warstwa sygnałów dla agentów — mieszanka różnych propozycji, eksperymentów i rozwijanych mechanizmów, w bardzo różnej fazie dojrzałości. Od względnie rozpoznawalnych propozycji jak llms.txt, przez robocze manifesty badawcze typu agent-permissions.json, po oficjalniej rozwijane mechanizmy odkrywania narzędzi w WebMCP. To warstwa, w której dwa lata temu było pusto. Dziś jest w niej gęsto, ale też chaotycznie — i jedną z decyzji, które będziesz musiał podjąć, jest to, na które z tych sygnałów stawiać, a których poczekać aż się ustatkują.
Warstwa działania — formularze, które agent potrafi wypełnić, API dostępne dla klienta programistycznego, ewentualnie narzędzia WebMCP wystawione bezpośrednio w przeglądarce. To warstwa, w której strona przestaje być tylko dokumentem, a staje się aplikacją dla agenta.
Warstwa tożsamości i zaufania — kto stoi za tym ruchem, czy to jest agent użytkownika X, czy to jest bot napastnika, czy agent ma upoważnienie do zakupu. Rozpisywałem to już w innym wpisie, ale tu wraca jako element audytu.
Warstwa monetyzacji i kontroli — pay-per-crawl, rate limiting specyficzny dla agentów, decyzje o tym, co jest darmowe a co płatne, których agentów dopuszczasz. Warstwa biznesowa, nie techniczna.
Sześć warstw. Każdą da się zaudytować osobno. Razem dają obraz tego, jak bardzo strona jest gotowa dla webu, który właśnie powstaje.
Co z tym zrobić teraz
Pierwsza rzecz — nie wpadać w panikę i nie próbować naraz naprawić wszystkiego. Agent-readiness nie jest stanem zero-jedynkowym, jest skalą. Strona, która ma dobrą semantykę i JSON-LD, ale nie ma jeszcze llms.txt, jest już w większym stopniu gotowa niż strona pozbawiona obu. W praktyce prawie każda strona zaczyna na jakimś poziomie — nie od zera.
Druga rzecz — zorientować się, gdzie się jest. Niektóre warstwy są banalne do sprawdzenia (czy masz llms.txt — wejdź na /llms.txt; to jest dziś propozycja, nie obowiązujący standard, ale pliku da się spojrzeć w pół sekundy). Inne wymagają narzędzi (audyt semantyki, audyt danych strukturalnych, test przez isitagentready.com). Jeszcze inne wymagają decyzji biznesowej (czy chcesz wystawić API, czy chcesz pay-per-crawl). W następnym wpisie serii rozpiszę checklistę, którą da się przejść samodzielnie i zobaczyć, na jakim poziomie się jest w każdej z sześciu warstw.
Trzecia rzecz — zacząć od warstw, które dają najwięcej za najmniej pracy. Dobra semantyka i JSON-LD to są rzeczy, które prawdopodobnie i tak robisz (albo powinieneś) ze względu na SEO i dostępność. Wystawienie llms.txt to pół godziny pracy. WebMCP czy pay-per-crawl to dłuższa inwestycja — warto ją zaplanować, ale nie musi być pierwsza.
Czwarta rzecz — nie traktować tego jako jednorazowego projektu. Agent-readiness to proces, bo standardy wciąż się zmieniają. Coś, co dziś jest state of the art, za pół roku będzie bazą. Coś, co dziś jest eksperymentalne, za rok będzie wymogiem.
Co będzie dalej w tej serii
Następny wpis rozpisuje sześć filarów agent-readiness w formie konkretnej checklisty — co sprawdzić, jakim narzędziem, co uznać za „zrobione”. Kolejne wpisy rozpiszą każdy filar osobno, z praktycznymi wdrożeniami dla WordPressa i Divi tam, gdzie to ma sens.
Celem serii nie jest przekonanie kogoś, że agent-readiness jest ważne — to się przekona samo, kiedy pierwszy poważny klient powie „moja strona nie pojawia się w ChatGPT, zrób coś”. Celem jest zrobienie mapy, po której da się poruszać wtedy, kiedy ten moment przyjdzie. A on przyjdzie prędzej niż się wydaje.