Kiedy człowiek otwiera stronę internetową, pierwszym pytaniem, które sobie zadaje, jest zwykle coś w rodzaju „czy jestem w dobrym miejscu”. Patrzy na hero, logo, nagłówek, zdjęcia. W pół sekundy wie, czy to sklep, czy blog, czy strona firmowa. W kolejną pół sekundy wie, czego szuka — albo nie znajduje i zamyka kartę.
Agent AI też zadaje pytania, ale inne. I zadaje je w innej kolejności. Zrozumienie tej kolejności to pierwsza rzecz, którą warto zrobić, jeśli chcesz się dowiedzieć, dlaczego jedna strona dla agenta jest czytelna, a inna nie — nawet jeśli dla człowieka wyglądają tak samo.
W tym wpisie pokażę trzy pytania, które agent zadaje twojej stronie, zanim zacznie cokolwiek na niej robić. Każde z nich wskazuje inną warstwę czytelności, w której może coś pójść źle. Na końcu zobaczysz, że to nie są pytania techniczne w sensie dostępności czy semantyki HTML — choć z nimi się łączą. To są pytania poznawcze: co to jest, jak to jest zbudowane, co tu można zrobić. Trzy pytania, które decydują, czy agent w ogóle ma z twoją stroną o czym rozmawiać.
Pytanie pierwsze — „czy ja w ogóle widzę treść tej strony”
To jest pytanie, które dla człowieka brzmi absurdalnie. Oczywiście widzisz treść strony — otwierasz ją, przewijasz, widzisz tekst, obrazy, przyciski. Dla agenta to pytanie jest bardzo realne i bardzo często odpowiedź brzmi „nie”.
Przyczyn może być kilka. Najczęstsza to JavaScript. Wiele nowoczesnych stron renderuje treść po stronie klienta — czyli serwer wysyła pustą skorupę, a treść dolepia dopiero JavaScript w przeglądarce, już po wczytaniu strony. Dla człowieka to różnica w ułamku sekundy. Dla agenta — dramat. Część agentów uruchamia JavaScript, część nie. Część renderuje, ale nie czeka dość długo. Część robi tylko pierwszy pass przez HTML i kończy, zanim dynamiczna treść zdąży się pojawić.
Bot Google od lat renderuje JavaScript w większości przypadków. Ale agenty AI — ChatGPT, Claude, Perplexity, Gemini — działają bardziej heterogenicznie. Niektóre pobierają stronę tylko jako statyczny HTML. Niektóre uruchamiają własną headless przeglądarkę, ale z ograniczeniami czasowymi. Niektóre polegają na wcześniej zindeksowanych wersjach ze źródeł trzecich. W praktyce oznacza to, że jeśli twoja strona ładuje istotną treść przez JavaScript, zwykle tracisz część agentów, nawet nie wiedząc o tym.
Druga częsta przyczyna to treść zaszyta w grafikach. Napis na baner, cytat na zdjęciu, infografika z kluczowymi liczbami — dla człowieka to wygląda świetnie. Dla agenta to jest pusta przestrzeń, chyba że masz dobry alt tekst (pisałem już o alt teksie bez spamu — jak opisywać obrazy sensownie). A nawet wtedy alt tekst rzadko zawiera pełną treść, która jest na grafice — bo nie powinien, bo alt to nie transkrypcja. Jeśli ważne informacje istnieją tylko w grafice, dla agenta nie istnieją.
Trzecia przyczyna, rzadsza, ale spotykana — treść za ścianą uwierzytelnienia, za captcha, za cookie banner, który blokuje dalsze wczytywanie. Niektóre strony zbudowane w Divi lub innych builderach mają modale, które pojawiają się natychmiast i wstrzymują resztę. Dla człowieka to minuta kłopotu, potem klika „rozumiem” i czyta stronę. Dla agenta — mur.
Jak sprawdzić, czy twoja strona przechodzi to pierwsze pytanie:
- Wyłącz JavaScript w przeglądarce (DevTools → Settings → Debugger → Disable JavaScript) i odśwież stronę. To, co widzisz, to minimum tego, co widzi część agentów.
- Pobierz stronę przez
curl twojadomena.plz linii komend. To, co zobaczysz, to surowy HTML — dokładnie to, co widzi najprostsza wersja agenta. - Użyj narzędzia typu Screaming Frog w trybie bez renderowania JS i zobacz, czy treść jest w HTML.
Jeśli w każdym z tych trzech testów widzisz pełną treść strony — zdałeś to pytanie. Jeśli nie — wiesz, gdzie zacząć. Często rozwiązaniem jest server-side rendering (SSR) albo prerendering, ale czasem wystarczy przenieść kluczową treść z ładowanej przez JavaScript do statycznego HTML-a.
Pytanie drugie — „jak ta strona jest zbudowana, czyli co tu jest czym”
Załóżmy, że agent widzi treść. Surowy HTML się wczytał, tekst jest, obrazy mają alt, wszystko jest technicznie obecne. Teraz agent zadaje drugie pytanie: co to wszystko znaczy. Nie w sensie znaczenia słów — słowa rozumie. W sensie strukturalnym: co tu jest nagłówkiem, co menu, co głównym tekstem, co pobocznym, co reklamą, co stopką.
Człowiek rozwiązuje to wzrokiem w ułamku sekundy. Widzi duży tekst u góry — to tytuł. Widzi trzy słowa w rzędzie na górze — to menu. Widzi cienki tekst na dole — to stopka. Nawet nie czyta, po prostu wie. Agent nie ma takiej intuicji wizualnej. Zamiast tego ma HTML. I jeśli ten HTML jest zbudowany sensownie, agent wie, co jest czym. Jeśli nie — zgaduje.
Sensownie zbudowany HTML to taki, w którym tagi odpowiadają funkcji elementów. <main> dla głównej treści. <article>dla pojedynczego wpisu. <nav> dla nawigacji. <header> i <footer> dla nagłówka i stopki strony. <aside> dla treści pobocznej. <section> dla logicznych sekcji. Jeden <h1> dla głównego tytułu. <h2> dla sekcji głównych, <h3> dla podsekcji. Nagłówki w hierarchii, bez przeskoków z h1 na h4. To jest semantyczny HTML i pisałem już czym jest semantyka HTML i dlaczego znowu ma znaczenie.
Problem w tym, że wiele stron jest zbudowanych z <div> i tylko <div>. Każdy element to <div>, żadnych ról, żadnej hierarchii. Dla człowieka wygląda identycznie. Dla agenta — to jest stos pudełek, z których każde wygląda tak samo i wszystkie są równie ważne. Agent musi wtedy zgadywać po klasach, po atrybutach, po treści. Czasem zgadnie dobrze, czasem źle. I co ważne, agent nie informuje cię, że zgadnął źle — po prostu przetwarza stronę na podstawie błędnego modelu.
Druga warstwa tego pytania to hierarchia nagłówków. Nagłówki to dla agenta szkielet strony, tak samo jak dla czytnika ekranu. Jeśli struktura nagłówków jest poprawna, agent może sobie zbudować spis treści strony i zrozumieć, co jest sekcją, co podsekcją. Jeśli jest błędna — wszystkie nagłówki to h2, żadnej hierarchii, albo h1 powtarza się pięć razy — agent nie widzi struktury. Widzi listę równorzędnych elementów, z których każdy jest tak samo ważny. Znaczy: nic nie jest ważne.
Trzecia warstwa to linki i ich anchory. „Kliknij tutaj”, „więcej”, „zobacz” — to są linki puste informacyjnie. Agent widzi link, ale nie wie, dokąd prowadzi, póki nie podąży za nim. Linki z sensownymi anchorami („Pobierz raport kwartalny 2026″, „Zobacz ofertę pakietu Premium”) to dla agenta wskazówki, czym są kolejne kroki na stronie. Agent może wtedy zdecydować, czy warto tam iść, zanim tam pójdzie.
To pytanie łączy się bezpośrednio z tematami, które już są na WebFluxie — jak uporządkować strukturę strony, żeby była czytelna dla człowieka i maszyn, semantyka w builderach WordPressa, najczęstsze błędy semantyczne na stronach WordPress. Czytelność dla agenta to nie nowa dyscyplina — to stara dyscyplina semantyki HTML, tyle że z nowym, dodatkowym czytelnikiem. Wszystko, co było prawdą dla dostępności i SEO, jest prawdą też dla agentów. Dodatkowo doszło jeszcze kilka rzeczy, o których za chwilę.
Jak sprawdzić, czy twoja strona przechodzi to drugie pytanie:
- Otwórz DevTools, zakładka Accessibility, sekcja „Accessibility Tree”. To, co tam widzisz, to dokładnie to, co widzi agent w warstwie strukturalnej.
- Zainstaluj HeadingsMap — pokaże ci hierarchię nagłówków jako spis treści. Jeśli wygląda jak spis treści dobrej książki, jesteś w domu. Jeśli wygląda jak losowy ciąg numerków, masz pracę.
- Przejrzyj kod strony i policz
<div>vs<main>/<article>/<section>/<nav>/<header>/<footer>. Jeśli mniej niż pięć procent elementów to tagi semantyczne, mieszkasz w krainie div-ów. - Kliknij kilka linków z anchorami. Jeśli więcej niż dwa-trzy brzmią jak „kliknij tutaj”, „więcej”, „zobacz” — masz pracę w tej warstwie.
Pytanie trzecie — „co tu można zrobić, i jak”
Najciekawsze pytanie, bo to jest to, co odróżnia agenta od klasycznego bota wyszukiwarki. Bot Google odpowiada na pytania „o czym jest ta strona” i „jak ważna jest”. Agent odpowiada na trzecie: „jakie akcje mogę na niej wykonać w imieniu użytkownika”. Wysłać formularz? Dodać do koszyka? Zarezerwować termin? Zapisać się na newsletter? Poprosić o ofertę?
Żeby odpowiedzieć na to pytanie, agent potrzebuje czegoś więcej niż semantyki HTML. Potrzebuje zrozumieć, które elementy strony są interaktywne i co się stanie, jak z nimi wejdzie w interakcję. W podstawowej warstwie to są formularze i przyciski. W bardziej zaawansowanej — API, proponowane standardy typu WebMCP, dane strukturalne mówiące o dostępnych akcjach.
Na poziomie podstawowym, który jest ważny dla każdej strony, sprowadza się to do kilku rzeczy.
Formularze muszą mieć etykiety (<label>). Nie placeholdery w polach — etykiety. Jeśli pole ma tylko <input placeholder="Email">, agent musi zgadnąć, że to pole na email. Jeśli ma <label for="email">Email</label><input id="email" type="email" name="email" autocomplete="email">, agent wie: to jest pole na email, ma standardową walidację, autocomplete jest ustawiony. Między tymi dwoma przypadkami jest różnica między „agent wypełni poprawnie” a „agent zgadnie, często źle”.
Przyciski muszą być przyciskami. <button type="submit">Wyślij</button> — agent rozumie. <div onclick="submit()">Wyślij</div> — nie rozumie. To też temat, który już rozwijałem, kiedy pisałem jak nie projektować przycisków, jeśli chcesz, żeby ktoś je naprawdę kliknął — i wszystko, co jest tam prawdą dla dostępności, jest prawdą dla agentów.
Linki muszą prowadzić do sensownych URL-i. Jeśli przycisk „Zobacz ofertę” prowadzi do #section-3, agent musi zgadnąć, że section-3 to oferta. Jeśli prowadzi do /oferta-premium/ — wie od razu.
I jest nowa warstwa, której wcześniej nie było — warstwa proponowanych standardów pozwalających stronie wystawić agentowi zestaw „narzędzi” bezpośrednio. WebMCP, który Chrome udostępnił w lutym 2026 we wczesnym preview, idzie dokładnie w tym kierunku — strona deklaruje, jakie akcje agent może wykonać, i agent wywołuje je strukturalnie zamiast zgadywać po DOM-ie. To jest eksperymentalne, nie musisz tego wdrażać teraz, ale warto wiedzieć, że ta warstwa istnieje i w niej będzie się dużo działo.
Na razie podstawa: jeśli twoja strona ma sensownie zbudowane formularze z etykietami, prawdziwe przyciski zamiast div-ów z JavaScriptem, i linki prowadzące do przewidywalnych URL-i — agent sobie poradzi. Bez tego zaczyna zgadywać.
Jak sprawdzić, czy twoja strona przechodzi to trzecie pytanie:
- Otwórz formularze na stronie i sprawdź, czy każde pole ma
<label>. Nie placeholder. Label. - Sprawdź, czy pola formularzy mają atrybut
autocompletetam, gdzie ma sens (email, imię, telefon, adres). To wskazówka dla agentów równie silna, co dla przeglądarek. - Klikaj przyciski na stronie i sprawdź, czy w kodzie to faktycznie
<button>albo<input type="submit">, a nie<div>albo<a>zonclick. - Patrz na URL-e linków nawigacyjnych. Czy mówią, dokąd prowadzą, czy są puste semantycznie (
/?p=123)?
Trzy pytania razem
Jeśli twoja strona odpowiada dobrze na wszystkie trzy pytania, jesteś na bardzo dobrym poziomie w pierwszym filarze agent-readiness. Treść jest widoczna bez JavaScriptu, struktura jest semantyczna, interakcje są czytelne. To jest fundament. Bez niego żadne pliki typu llms.txt, żadne dane strukturalne JSON-LD, żadne zaawansowane protokoły nie pomogą — bo agent nie zobaczy nawet samej strony.
Najciekawsza obserwacja z tego wpisu jest moim zdaniem taka: większość rzeczy, które sprawiają, że strona jest czytelna dla agenta, jest identyczna z rzeczami, które sprawiają, że jest czytelna dla czytnika ekranu, dla bota Google, dla człowieka z wolnym internetem. Semantyczny HTML, hierarchia nagłówków, etykiety formularzy, sensowne anchory. To wszystko istniało w dostępności i SEO od dekad. Agent nie wymyślił nowej dyscypliny — dołączył jako kolejny czytelnik do dyscypliny, która już była.
To jest dobra wiadomość, bo oznacza, że jeśli robisz strony z sensem od strony dostępności i semantyki, już jesteś w dużym stopniu gotowy dla agentów. Złą wiadomością jest, że większość stron nie jest robiona z sensem od strony dostępności i semantyki. Builderzy generują warstwy div-ów. Deweloperzy obudowują wszystko Reactem i renderują po stronie klienta. Projektanci tworzą interfejsy, w których przycisk jest stylizowanym <div>-em. Pod tym wszystkim strona wygląda świetnie, a dla agenta — jest mgłą.
Co dalej
W następnym wpisie serii schodzimy do filaru drugiego — struktury danych. Czyli co zrobić, żeby agent nie tylko widział tekst, ale rozumiał, że „99 zł” to cena, a nie numer telefonu; że „15 marca 2026″ to data wydarzenia, a nie ostatnia modyfikacja wpisu; że ta sekcja opisuje produkt, a ta recenzję tego produktu. To jest warstwa JSON-LD i schema.org, i warstwa, w której polski internet ma bardzo nierówne wyniki.
Dla tych, którzy chcą od razu przejść do praktyki w kontekście WordPressa i Divi — filar pierwszy dostanie też wpis-towarzysz w dziale Divi 5, w serii „Agent-ready Divi”, z konkretnymi zrzutami ekranu, modułami, atrybutami. Tam pokażę, gdzie w Divi Builderze klikać, żeby wyjść z krainy div-ów i wejść w semantykę, i jak sprawdzić swoją stronę krok po kroku.