Sześć filarów agent-readiness — praktyczna checklista dla twojej strony

Pierwszy wpis tej serii postawił tezę, że agent-readiness staje się warstwą, której warto się przyjrzeć teraz, zanim stanie się oczywistym wymogiem. Ten wpis idzie o krok dalej i rozpisuje, co konkretnie sprawdzić — w każdej z sześciu warstw, które wprowadziłem w poprzednim tekście. To nie jest jeszcze pogłębienie każdej z nich (każda dostanie swój osobny wpis). To jest checklista, po której da się przejść w jeden wieczór i wyjść z niej z obrazem, gdzie twoja strona jest już gotowa, a gdzie są luki.

Jedno zastrzeżenie na wstępie. Agent-readiness nie jest stanem zero-jedynkowym. Strona może być w pełni gotowa w jednej warstwie i w ogóle w innej, i to jest normalne. Celem tej checklisty nie jest sprawdzenie, czy dostaniesz pięć na pięć — celem jest zobaczenie, gdzie stoisz, żeby wiedzieć, w co inwestować czas w pierwszej kolejności. Jeśli po tym wpisie zobaczysz, że masz solidną semantykę, ale nie masz żadnych danych strukturalnych, to jest dla ciebie sygnał, co robić dalej.

Przechodzimy przez filary w kolejności od najbardziej fundamentalnego do najbardziej zaawansowanego. Taka kolejność ma znaczenie praktyczne — warstwy na początku działają niezależnie i ich brak psuje wszystko, co wyżej. Warstwy na końcu są dobudowywane na tym, co wcześniejsze.

Filar 1 — warstwa czytelności

To jest fundament. Bez niego nie ma sensu patrzeć dalej, bo każda kolejna warstwa zakłada, że agent w ogóle potrafi twoją stronę odczytać. Czytelność dla agenta różni się od czytelności dla wyszukiwarki w kilku punktach: agent często nie uruchamia JavaScript tak pełnie jak bot Google, częściej pracuje na czystym HTML, a semantykę traktuje dosłowniej.

Co sprawdzić w tej warstwie:

• Czy treść strony jest widoczna w HTML bez renderowania JavaScript. Najprościej sprawdzisz to wyłączając JS w przeglądarce (DevTools → Settings → Debugger → Disable JavaScript) i odświeżając stronę. Jeśli widzisz białą stronę albo szkielet bez treści, agent też prawdopodobnie zobaczy niewiele.
• Czy nagłówki mają sensowną hierarchię. Jeden h1 na stronie, potem h2 dla sekcji, h3 dla podsekcji, bez przeskoków z h1 na h4. Do audytu używam najczęściej HeadingsMap (rozszerzenie do Chrome) albo zakładki Accessibility w DevTools.
• Czy strona używa semantycznych tagów HTML zamiast samych div. <main>, <article>, <nav>, <header>, <footer> — agent rozumie te tagi wprost, bez zgadywania. Audyt ręcznie w DevTools albo przez Screaming Frog w zakładce HTML.
• Czy obrazy mają sensowne atrybuty alt. Nie pod SEO, tylko pod zrozumienie — „zdjęcie produktu X w kolorze czerwonym” jest dla agenta informacją, „IMG_4892.jpg” nie jest.
• Czy linki mają sensowne anchory. „Kliknij tutaj” nic nie mówi agentowi. „Pobierz raport kwartalny 2026″ mówi wszystko.

Znak, że ta warstwa jest w porządku: twoja strona z wyłączonym JavaScript wciąż pokazuje całą treść, a outline nagłówków (HeadingsMap) wygląda jak spis treści książki.

Filar 2 — warstwa struktury danych

Agent potrafi odczytać tekst. Ale bez dodatkowej warstwy nie wie, co ten tekst znaczy w kategoriach biznesowych. Że „99 zł” to cena, a nie numer telefonu. Że „15 marca 2026″ to data wydarzenia, a nie data publikacji wpisu. Że ta sekcja opisuje produkt, a ta recenzję tego produktu. To jest rola danych strukturalnych — przekazania agentowi nie tylko tekstu, ale też relacji między nim a światem.

Co sprawdzić w tej warstwie:

• Czy strona ma JSON-LD z odpowiednimi typami ze schema.org. Dla sklepu to będzie Product, Offer, AggregateRating. Dla usługi — Service, LocalBusiness. Dla bloga — Article, BlogPosting. Dla strony firmowej — Organization. Walidacja przez Schema.org Validator (validator.schema.org) albo Google Rich Results Test (search.google.com/test/rich-results).
• Czy dane strukturalne pokrywają to, co jest na stronie widocznie. Często zdarza się, że w JSON-LD jest cena 99 zł, a na stronie 129 zł. Agent traktuje dane strukturalne jako prawdę, więc rozbieżność to problem.
• Czy są dane strukturalne dla tych elementów, które agent najczęściej potrzebuje: cena, dostępność, godziny otwarcia, lokalizacja, autor artykułu, data publikacji. Brak Offer.availability dla sklepu to klasyczny przypadek, który sprawia, że agent „nie widzi”, że produkt jest w magazynie.
• Czy używasz właściwości specyficznych dla swojej branży, a nie tylko podstawowych. Dla restauracji — servesCuisine, acceptsReservations. Dla sklepu — shippingDetails, merchantReturnPolicy. Dla wydarzenia — location, startDate, eventStatus.
• Czy strona ma Open Graph i Twitter Cards. To nie to samo co JSON-LD, ale agent często z tego korzysta jako fallback, zwłaszcza przy pobieraniu treści w formie karty.

Znak, że ta warstwa jest w porządku: Schema.org Validator nie zgłasza błędów, Rich Results Test pokazuje, że strona kwalifikuje się do co najmniej jednego typu wyników rich, a to, co widać na stronie, jest spójne z tym, co jest w JSON-LD.

Filar 3 — warstwa sygnałów dla agentów

Tu robi się ciekawie, bo to jest warstwa, której dwa lata temu praktycznie nie było. Dziś jest w niej gęsto, ale chaotycznie — różne pliki i formaty, w różnej fazie dojrzałości, część rozpoznawana przez jeden zestaw agentów, część przez inny. Ważne: to jest warstwa, w której świadomie osłabiam rekomendacje, bo inwestowanie dużego czasu w eksperymentalne formaty może się nie zwrócić, jeśli standard nie przyjmie się na rynku.

Co sprawdzić w tej warstwie:

• Czy masz plik /llms.txt w rootcie domeny. To jest obecnie najbardziej rozpoznawalna propozycja, choć nie formalny standard. Struktura: markdown z krótkim opisem strony i listą linków do najważniejszych zasobów. Adopcja jest niejednolita — część agentów to respektuje, część nie, ale koszt dodania to pół godziny. Sprawdź przez odwiedzenie twojadomena.pl/llms.txt.
• Czy masz zaktualizowany robots.txt, który rozróżnia tradycyjne crawlery od AI-botów. Pozycje typu GPTBot, ClaudeBot, PerplexityBot, Google-Extended — możesz im jawnie pozwolić albo zabronić. Brak tej decyzji oznacza, że agenci działają domyślnie, a ty nie masz nad tym kontroli.
• Czy masz sitemap.xml z aktualną datą ostatniej modyfikacji. To klasyka SEO, ale agenci też z tego korzystają do zrozumienia, co na stronie jest ważne i kiedy było aktualizowane.
• Czy wiesz, jaki ruch z AI-botów masz już teraz. W logach serwera albo w Cloudflare (jeśli używasz) — filtruj po user-agencie GPTBot, ClaudeBot itd. To pokazuje, czy agenci już cię odwiedzają i czy mają problem z odczytem.
• Czy znasz isitagentready.com (serwis Cloudflare). Darmowy audyt agent-readiness dla strony. Nie jest kanoniczny, ale daje szybki obraz tego, co widać z zewnątrz.

Znak, że ta warstwa jest w porządku: masz llms.txt, masz świadomie skonfigurowany robots.txt (a nie domyślny), i wiesz ile agentów cię odwiedza miesięcznie.

Filar 4 — warstwa działania

To jest warstwa, w której strona przestaje być tylko dokumentem do odczytania, a zaczyna być czymś, z czym agent może coś zrobić. Jeśli w pierwszych trzech warstwach pytaliśmy „czy agent rozumie twoją stronę”, to teraz pytamy „czy agent może na niej coś wykonać, żeby pomóc użytkownikowi”. To jest warstwa, która decyduje, czy będziesz kanałem zakupowym dla agentów, czy tylko biernym źródłem informacji.

Co sprawdzić w tej warstwie:

• Czy formularze na twojej stronie mają sensowne label, name i autocomplete. Agent, który ma wypełnić formularz kontaktowy w imieniu użytkownika, musi wiedzieć, że to pole to email, to pole to imię, to pole to treść wiadomości. Brak etykiet = agent zgaduje.
• Czy masz API, które dubluje funkcje strony. Najlepszy scenariusz dla agenta to nie wypełnianie formularza, tylko wywołanie API. Jeśli jesteś sklepem, masz REST API? Jeśli jesteś platformą rezerwacyjną, masz endpoint do rezerwacji? Jeśli tak — udokumentuj to, najlepiej w OpenAPI.
• Czy masz jakiekolwiek zabezpieczenia, które blokują agentów nie wiedząc o tym, że to robisz. CAPTCHA przy każdym kliknięciu, Cloudflare Bot Fight Mode na maksymalnym poziomie, rate limiting, który blokuje przy drugim żądaniu. To bywa potrzebne, ale warto wiedzieć, że to odcina agentów — a potem świadomie zdecydować, czy chcesz ich odciąć.
• Czy wiesz, czym jest WebMCP i czy rozważałeś, co moglibyś przez niego wystawić. To jest obecnie w early preview w Chrome (od lutego 2026), nie jest produkcyjnie gotowe dla wszystkich. Ale myślenie o tym, jakie akcje chciałbyś wystawić agentowi w przyszłości, to już teraz wartościowe ćwiczenie — bo każe ci zdefiniować, co jest na twojej stronie „akcją”, a co tylko „treścią”.
• Czy masz stronę kontaktową, która jest czymś więcej niż formularzem. Adres, godziny otwarcia, linki do komunikatorów, numery telefonów z protokołami tel: — to wszystko pomaga agentowi zrozumieć, jak nawiązać kontakt w imieniu użytkownika.

Znak, że ta warstwa jest w porządku: jeśli użytkownik powie swojemu agentowi „umów mi spotkanie na twojastrona.pl”, agent ma albo jasny formularz z etykietami, albo API, albo jakąś trzecią drogę — ale nie napotyka muru.

Filar 5 — warstwa tożsamości i zaufania

Ta warstwa odpowiada na pytanie, które jeszcze pięć lat temu nie miało sensu: kto właściwie działa na mojej stronie? Człowiek? Bot? Agent działający w imieniu człowieka? A jeśli agent — to jaki, z jakiego klienta, czy ma upoważnienie? To jest warstwa, która staje się ważna w momencie, gdy zaczynają pojawiać się działania z konsekwencjami — płatności, rezerwacje, zmiany w koncie. I to jest warstwa, w której na razie żadne standardy nie są w pełni ustalone, więc mówimy o dobrych praktykach, a nie twardych wymogach.

Co sprawdzić w tej warstwie:

• Czy wiesz, jak rozróżnisz ruch z różnych typów agentów. ChatGPT ma swój user-agent, Claude ma swój, Perplexity swój. Jeśli wszyscy są dla ciebie jednym „botem”, nie masz kontroli nad tym, kto co może.
• Czy twoje procesy wrażliwe — zakup, zmiana danych, płatność — mają jakąś warstwę potwierdzenia, która wymaga obecności człowieka. To może być 2FA, może być ekran potwierdzenia z opóźnieniem, może być email confirmation. Agent potrafi przejść przez niektóre z tych warstw, ale dobre praktyki wokół agent-authorization dopiero się kształtują i warto nie zostawać z systemem, który można w pełni zautomatyzować bez udziału użytkownika.
• Czy masz świadomie dobraną politykę dla ruchu nieautoryzowanego. Jeśli ktoś odwiedza cię z user-agentem, którego nie rozpoznajesz, co się dzieje? Dostęp, blokada, rate limit? Domyślna odpowiedź „nic, bo nie sprawdzałem” to nie jest świadomy wybór.
• Czy twoje dane kontaktowe i dane o firmie są zweryfikowalne z wielu źródeł. Agent, który ocenia zaufanie do strony, patrzy nie tylko na samą stronę, ale na to, czy jest ona spójna z wpisami w Google Business Profile, Yelp, LinkedIn, GitHub (zależnie od branży). Spójność = wyższe zaufanie.
• Czy masz gdzieś jawnie opisane, jakim agentom dajesz zgodę na działanie, a jakim nie. To jeszcze nie jest standard, ale zaczyna się pojawiać jako dobra praktyka — coś w rodzaju polityki prywatności, ale dla agentów.

Znak, że ta warstwa jest w porządku: potrafisz powiedzieć, jacy agenci są na twojej stronie i co im wolno, a twoje wrażliwe procesy mają punkty potwierdzenia, których w pełni zautomatyzowany agent nie przejdzie bez udziału człowieka.

Filar 6 — warstwa monetyzacji i kontroli

Ostatnia warstwa jest biznesowa, nie techniczna. Dotyczy decyzji, nie implementacji. I jest tą, która będzie się najbardziej zmieniać w najbliższych dwóch latach, bo tu pojawiają się nowe modele biznesowe — pay-per-crawl, licencjonowanie treści dla modeli, selektywny dostęp dla różnych klas agentów. Większość tych rzeczy jest dziś na etapie pierwszych wdrożeń, nie ustalonego rynku.

Co sprawdzić w tej warstwie:

• Czy masz zdanie na temat pay-per-crawl. Cloudflare wprowadził to jako funkcję — możesz zażyczyć sobie mikropłatności od AI-crawlerów za dostęp do twojej treści. Dla większości stron to się nie opłaca, dla wydawców i baz treści — potencjalnie tak. Nie musisz tego wdrażać, ale powinieneś wiedzieć, że ta opcja istnieje.
• Czy wiesz, co dzieje się z twoją treścią, kiedy agent ją pobiera. Szkoli modele? Jest cytowana? Jest odtwarzana? Dla każdego z tych scenariuszy masz inną strategię. Brak świadomości to domyślny scenariusz „wszystko, co najgorsze dla mnie” — treść trafia do szkolenia, nie dostaję atrybucji, nie dostaję ruchu.
• Czy twoje warunki użytkowania mówią coś o użyciu przez AI. Obowiązujące w większości stron regulaminy były pisane w epoce, w której nie istniały agenty. Aktualizacja TOS-a, która jasno mówi, co wolno a czego nie, jest dziś dobrą praktyką.
• Czy masz strategię rozróżnienia między ruchem, który przynosi wartość (cytowanie, ruch do strony, konwersja) a ruchem, który tylko konsumuje zasoby (scraping bez atrybucji). Pierwszy chcesz wspierać, drugi ograniczać — i to są różne polityki dla różnych user-agentów.
• Czy wiesz, ile kosztuje cię miesięcznie ruch z AI-botów. Serwery, bandwidth, rate limiting. Dla małych stron to pomijalne. Dla większych — zaczyna być pozycją w budżecie, o której warto wiedzieć.

Znak, że ta warstwa jest w porządku: masz świadomie dobraną politykę względem agentów, a nie domyślną „cokolwiek się dzieje, to się dzieje”.

Co zrobić z tą checklistą

Zaproponowałbym prosty sposób pracy. Przejdź przez wszystkie sześć filarów i dla każdego daj sobie ocenę na skali od zera do pięciu. Zero — nie robisz nic w tej warstwie. Pięć — robisz wszystko, co jest możliwe na obecnym etapie dojrzałości standardów. Zsumuj.

Jeśli wyjdzie ci poniżej dziesięciu na trzydzieści, masz przed sobą dużo pracy, ale wiesz od czego zacząć — od warstw z najniższymi ocenami, idąc od filaru 1 w górę, bo każda warstwa wyżej zakłada, że niższe działają. Jeśli wyjdzie dwadzieścia i więcej, jesteś w dobrym miejscu, i warto skupić się na ulepszaniu tych dwóch-trzech warstw, które są najsłabsze, zamiast rozbudowywać tam, gdzie już jest mocno.

Każdy z sześciu filarów dostanie swój osobny wpis w tej serii, z pogłębioną analizą i praktycznymi wdrożeniami — tam, gdzie to ma sens, w ekosystemie WordPress i Divi. Następny wpis rozpisuje filar pierwszy — czytelność — bo bez niego reszta nie działa.