Coraz częściej, poza ludźmi i botami wyszukiwarek, strony internetowe odwiedzają agenty AI. Chociaż na razie nie wszyscy mają na tyle zaufania, aby korzystać z podpowiedzi AI albo całkowicie oddelegowywać im robienie dla siebie zakupów, myślę, że można już stwierdzić z dużą pewnością, że AI zostanie z nami na długo i prędzej czy później każdy z nas będzie korzystał z AI do codziennych czynności (jeśli już teraz tego nie robi).
A to oznacza również konieczną zmianę w podejściu biznesowym. Już nie walczymy tylko o to, aby strona była UX-friendly, ale chcemy aby była także agent-friendly. W praktyce oznacza to stronę, którą agent AI potrafi poprawnie odczytać, zinterpretować i obsłużyć – znaleźć na niej informacje, porównać ofertę i dokończyć bezbłędnie proces, np. zakup produktu, czy rezerwację usługi.
Jak zmienia się projektowanie stron, gdy część użytkowników deleguje zadania agentom AI?
Według pomiarów Cloudflare Radar ruch generowany przez boty przekroczył już połowę całego ruchu HTTP – w jednym z tygodni 2026 roku sięgnął 57,2%. Nie każdy taki bot to stricte agent zakupowy, ale można już zauważyć tendencję, że ogólnie ruch botów rośnie i prawdopodobnie będzie rósł.
W związku z tym musimy trochę przeprogramować nasze dobre praktyki odnośnie tworzenia stron internetowych i uwzględnić w nich kilka punktów, które pozwolą odczytać wszystkie informacje ze strony botom AI. I to najlepiej przy możliwie najmniejszym zużyciu tokenów.
Semantyczny HTML, czyli dlaczego ostylowany <div> nie jest dla agenta przyciskiem?
Pod określeniem semantyczny HTML kryje się używanie znaczników zgodnie z ich prawdziwym znaczeniem, a nie tylko wyglądem, np.:
- <button> dla przycisku,
- <nav> dla nawigacji,
- <article> dla treści,
- <label> dla etykiety pola formularza,
- <h1>–<h6> dla hierarchii nagłówków.
Alternatywą są uniwersalne znaczniki <div> i <span>. Jednak pod kątem budowania stron łatwych do odczytania przez agentów AI, lepiej ich unikać. To są pojemniki, które będą utrudniały AI zrozumienie ich kontekstu.
Dla człowieka ostylowany <div> z obramowaniem, cieniem i kursorem w kształcie dłoni wygląda jak przycisk i działa jak przycisk. Natomiast dla agenta to po prostu prostokąt bez zadeklarowanej funkcji. Agent musi wtedy zgadywać na podstawie kontekstu wizualnego, co to właściwie jest. A zgadując, po pierwsze agent zużyje więcej tokenów, po drugie łatwiej się pogubi.
Accessibility tree, czyli struktura, przez którą agent naprawdę „widzi” Twoją stronę
Accessibility tree (tzw. drzewo dostępności) to uproszczona wersja struktury strony, powiązana z DOM, z której przede wszystkim korzystają technologie wspomagające, np. czytniki ekranów używane przez osoby niewidome. Drzewo dostępności pozwala określić role i zależności, np. wskazuje, który element jest linkiem, obrazem, albo przyciskiem, a który ma rolę jedynie dekoracyjną.
Obecnie agenty AI korzystają z tej technologii, ponieważ pozwala w szybki i tani sposób poznać najważniejsze informacje o stronie.
Jaki płynie z tego wniosek? Dostępność (WCAG) i agent-readiness możemy już traktować jako wzajemnie uzupełniającą się inwestycję.
Jak zadbać o poprawne drzewo dostępności?
- Stosuj semantyczny HTML
- Nadaj nazwę dostępną (tzw. accessible name) każdemu elementowi interaktywnemu
- Uzupełnij atrybuty ARIA
- Zachowaj logiczną hierarchię nagłówków
- Usuwaj zbędne elementy z drzewa (z wykorzystaniem aria-hidden)
Stabilny layout, czyli dlaczego infinite scroll i layout shift wywracają ścieżkę agenta?
Utrzymanie na stronie stabilnego layoutu oznacza, że elementy strony nie przeskakują, nie doładowują się w nieprzewidywalnym momencie i znajdują się dokładnie tam, gdzie się ich oczekuje. To nie jest nowy temat, szczególnie dla osób zaznajomionych z SEO, gdyż tzw. layout shift, czyli przesunięcie układu jest mierzone jako CLS (jeden ze wskaźników Core Web Vitals) i redukowane w ramach technicznych aktywności SEO.
Wszelkie nieoczekiwane zmiany układu utrudniają interakcję z serwisem i mogą powodować tzw. misclicki – zarówno przez człowieka jak i przez agenta. Przykładowo, uznajmy, że agent AI został „zatrudniony” do zrobienia zakupów w sklepie internetowym. Lokalizuje on przycisk „Dodaj do koszyka”, planuje kliknięcie, a w międzyczasie doładowuje się pop-up z informacją o letniej wyprzedaży i przesuwa cały układ o sto pikseli w dół. Kliknięcie agenta trafia więc w puste miejsce albo co gorsza w inny element.
Człowiek w takiej sytuacji zauważyłby zmianę i skorygował swój ruch (i pewnie trochę by się zirytował 😉 ), ale agent po prostu kliknie. Przy optymistycznym założeniu, jeśli bot będzie dobrze zaprogramowany, po prostu powtórzy on akcję i w końcu wykona ją poprawnie. Zużyje tylko wtedy nadmiarową liczbę tokenów. Ale jeśli będą luki w instrukcjach dla bota, może się to skończyć nawet nieprawidłowym zakupem.
Czego unikać, aby mieć stabilny layout strony internetowej?
- Infinite scroll – treść ładowana dopiero przy przewijaniu. Agent, który nie symuluje przewijania w sposób zgodny z oczekiwaniem skryptu, może nie zobaczyć większości oferty. Rozwiązaniem jest paginacja z dedykowanymi adresami URL działającymi równolegle do przewijania.
- Treści ukryte za pseudoklasą :hover – to informacje pojawiające się dopiero po najechaniu kursorem na dany element. Agent często nie generuje zdarzenia najechania.
- Elementy pojawiające się po opóźnieniu – mogą być to wszelkiego rodzaju pop-upy.
- Przezroczyste nakładki – niewidoczne warstwy przykrywające elementy interaktywne. Dla człowieka nie stanowią one żadnej bariery, ale agentowi mogą zablokować wykonanie akcji.
Czytelne formularze, czyli jak nie zgubić agenta na ostatnim kroku konwersji?
W przypadku formularzy, zadbanie o agent-readiness dla strony jest szczególnie istotne, ponieważ agent nie tylko czyta formularz, ale powinien móc go wypełnić. Więc jeżeli tutaj pojawi się jakaś blokada dla bota, może to kosztować firmę konwersje.
Na co zwrócić uwagę tworząc formularze?
- Etykiety <label> – każde pole potrzebuje etykiety <label> połączonej z polem atrybutem for wskazującym na id pola. Sam placeholder nie jest etykietą, ponieważ znika po rozpoczęciu wpisywania i nie buduje trwałego powiązania w drzewie dostępności.
- Opisowe atrybuty techniczne – wartości name, id oraz autocomplete powinny być opisane tak, aby agent nie miał wątpliwości czego dotyczą. Przykładowo dla pola dotyczącego e-maila, złym podejściem będzie nazwanie pola, np. „field_7”, a dobrym „email” albo „autocomplete=”email””.
- Komunikaty błędów przedstawione jako tekst. Czerwona ramka wokół pola to informacja czysto wizualna, która będzie zrozumiała dla ludzi, ale nie dla agenta. Agent nie wywnioskuje z koloru, co poszło nie tak. Błąd musi być opisany tekstowo, powiązany z odpowiednim polem i przedstawiony, np. przez przez aria-describedby lub obszar role=”alert”.
- Potwierdzenie wysłania formularza – jeśli po wysłaniu formularza, taki komunikat nie pojawi się na stronie, agent nie będzie miał pewności, że akcja się powiodła. W związku z tym występuje ryzyko, że kilkukrotnie powtórzy akcję wypełniania i wysyłki formularza, albo zgłosi użytkownikowi, że zadanie nie zostało wykonane.
Jak agent AI czyta stronę?
W przeciwieństwie do człowieka, agent AI nie ma tylko jednego sposobu na „czytanie” strony. Korzysta on z kilku kanałów jednocześnie, a nowoczesne modele coraz częściej łączą je, by uzyskać spójny obraz sytuacji. Wyróżnia się 4 najważniejsze ścieżki odczytywania strony przez agenta: DOM, zrzuty ekranu, drzewo dostępności i dane strukturalne.
| Kanał | Jak to działa? | O czym warto pamiętać? |
| Odczyt DOM – struktura dokumentu widziana przez przeglądarkę | Agent parsuje kod strony bezpośrednio i wnioskuje o hierarchii, funkcjach i relacjach między elementami. | Pozytywnie na agentów wpłyną: czysta struktura zagnieżdżeń, semantyczne znaczniki, opisowe klasy i identyfikatory. Należy unikać sytuacji, gdy DOM generowany jest nieprzewidywalnie, identyfikatory zmieniają się przy każdym renderowaniu, treść jest ukryta w niestandardowych atrybutach, warstwy <div> opakowują każdy element po kilka razy. |
| Zrzuty ekranu | Agent wykonuje zrzut ekranu i analizuje go modelem wizyjnym, lokalizując elementy tak jak człowiek | Warto pamiętać o zachowaniu kontrastu tekstu względem tła, czytelnej hierarchii wizualnej, minimalizowaniu nakładających się elementów, czy spójnym wyglądzie elementów pełniących tę samą funkcję. Strony wymagające analizy wizualnej są droższe w obsłudze. |
| Drzewo dostępności | Przeglądarka buduje „odchudzoną” wersję strony – listę funkcji: z rolą, nazwą i stanem każdego elementu, ale bez warstwy wizualnej. | To jedyny kanał przekazujący wprost funkcje elementów – sięgają po niego Chrome DevTools, Playwright oraz Lighthouse. Należy unikać elementów bez nazwy, przycisków bez czytelnej treści oraz atrybutów aria-label niezgodnych z widocznym tekstem. |
| Dane strukturalne | Dzięki danym strukturalnym schema.org strona wprost deklaruje w kodzie, czym jest dany obiekt. | Warto zadbać o kluczowe typy związane z działalnością Twojej firmy, czyli najczęściej Product, Offer, LocalBusiness, FAQPage, Organization. Sama obecność danych strukturalnych nie gwarantuje, że agent AI oceni stronę lepiej. Pomogą mu jednak zebrać kompletny obraz Twojej firmy, produktów i usług. |
Czy llms.txt naprawdę działa?
Plik llms.txt z założenia miał być odpowiednikiem robots.txt, ale dla botów AI. Taki plik powinien zawierać uporządkowane streszczenie tego, czym firma się zajmuje, oraz odnośniki do najważniejszych podstron. Ale czy faktycznie jest on egzekwowany przez roboty?
Na ten moment można jeszcze stwierdzić, że temat nie jest w pełni rozstrzygnięty. Z jednej strony jest rekomendowany m.in. przez Lighthouse, z drugiej strony w dokumentacji Google jest jasny zapis, że pliki llms.txt nie są wymagane ani używane przez wyszukiwarkę Google do generowania odpowiedzi AI.
Przeprowadzone dotychczas badania na dużych próbach stron nie wykazały jasnej korelacji między wdrożeniem llms.txt a wzrostem cytowania strony w odpowiedziach AI.
Jak więc do tego podejść? Moim zdaniem, wdrożenie llms.txt to inwestycja, która jest zarówno tania jak i łatwa do wykonania, a dodatkowo nie niesie za sobą żadnego ryzyka. W związku z tym, skłaniałabym się do wprowadzenia tego pliku na stronę chociażby w formie testów. Nawet jeśli nic się nie zmieni, to też nie przepalisz na to dużego budżetu.
Czy agenty AI „widzą” JavaScript?
Google już całkiem dobrze radzi sobie ze stronami opartymi na JavaScripcie. Pytanie jednak brzmi, czy agenty AI radzą sobie równie dobrze? Niestety, nie zawsze. Renderowanie JavaScriptu jest kosztowne obliczeniowo, więc część botów AI po prostu je pomija – treść doładowywana skryptem może dla nich w ogóle nie istnieć.
Co zrobić, jeśli duża część strony jest zakodowana w JavaScript?
- Postaw na SSR (renderowanie po stronie serwera).
- Zadbaj, aby wszystkie treści były wyświetlane na stronie nawet przy wyłączonym JavaScripcie.
- Zadbaj o to, aby informacje zawarte w infografikach, czy innych elementach graficznych znajdowały się też w tekście na stronie.
Czy warto blokować boty AI w robots.txt?
Odpowiedź brzmi: hurtowo – nie, selektywnie – czasem warto.
Jeśli chcesz, aby Twoja strona była cytowana przez modele językowe, nie możesz blokować im dostępu do swojej strony.
W określonych sytuacjach możesz jednak blokować boty selektywnie:
- tak, aby nie miały dostępu do konkretnej sekcji serwisu, do której nie chcesz wpuszczać botów i nie chcesz aby była wykorzystywana w źródłach cytowania.
- zablokować boty przeznaczone do trenowania modeli, a zachować dostęp dla botów przeszukujących sieć w poszukiwaniu odpowiedzi na zapytanie użytkownika.
Czym jest WebMCP i czy go potrzebujesz?
WebMCP to standard opracowany przez Google w ramach przeglądarki Chrome, dzięki któremu strona internetowa może udostępnić agentom AI swoje funkcje, np. wyszukiwanie produktu, dodanie do koszyka czy sprawdzenie wolnego terminu, jako gotowe do wywołania narzędzia. A więc zamiast zgadywać na podstawie zrzutów ekranu, w co kliknąć, agent dostaje wprost listę dostępnych akcji wraz z informacją, jakich danych każda z nich wymaga.
W praktyce działa to tak, że deklarujesz w kodzie strony konkretne funkcje, które agent potem wywołuje. Przykładowo, jeśli Twoja strona to wyszukiwarka lotów, dzięki WebMCP możesz zbudować taki workflow, w którym agent podaje miasto wylotu, miasta docelowe i daty podróży, a strona zwraca dostępną listę połączeń wraz z cenami.
Dla kogo jest WebMCP?
WebMCP najlepiej sprawdzi się tam, gdzie użytkownicy wykonują powtarzalne czynności:
- E-commerce – wyszukiwanie i filtrowanie produktów, dodawanie do koszyka, sprawdzanie statusu zamówienia.
- Rezerwacje i usługi – sprawdzanie wolnych terminów, umawianie wizyt, zapytania ofertowe.
- Marketplace i porównywarki – wyszukiwanie po parametrach i zestawianie ofert.
- SaaS i panele klienta – typowe operacje na danych, onboarding użytkownika.
Jeśli Twoja strona to wizytówka, blog albo serwis czysto informacyjny, nie ma potrzeby, abyś implementował WebMCP. Lepiej zainwestować w takiej sytuacji w optymalizację innych technicznych usprawnień.
Warto mieć na uwadze, że na razie WebMCP jest wciąż w fazie eksperymentalnej i nie jest sprawdzonym standardem. Natomiast zainteresowanie tym rozwiązaniem deklarują duzi gracze, tacy jak Booking.com, czy Shopify, więc choć jeszcze nie jest to powszechne, traktowałabym to jako coś więcej niż tylko ciekawostkę.
Co agentic search zmienia w e-commerce?
Najprościej mówiąc, coraz częściej zakupy w internecie będzie robił nie człowiek, a wytrenowany agent AI. Oznacza to, że dla agentic search, branża e-commerce musi przystosować swoje strony tak, aby były kompletne pod kątem informacji o swoich produktach i wyróżnikach marki. Mniej będą się liczyły czynniki oddziałujące na ludzką psychikę, a bardziej prezentacja konkretnej specyfikacji i cech, które można porównać z konkurencją. A więc informacje o cenie, ilości produktów na stanie, sposobach i kosztach wysyłki na karcie produktów to już nie tylko wskazówka UXowa, ale też AIowa.
Co więcej, sklep ecommerce dostosowany pod boty AI powinien mieć też łatwą do „przeklikania” stronę koszyka i proces finalizacji transakcji. Jeśli wypełnienie któregoś pola albo kliknięcie w przycisk będzie dla bota trudne lub niemożliwe, wybierze stronę konkurenta, która nie wymaga do tej samej akcji przepalania tokenów.
Co istotne, taka utrata klienta może być zupełnie niewidoczna w statystykach – agent, który nie może dokończyć zadania, po prostu po cichu przechodzi do konkurencji, nie zostawiając w analityce ani porzuconego koszyka, ani komunikatu o błędzie. Oczywiście, na razie AI częściej pomaga nam w wyborze produktu i porównaniu ofert, a niekoniecznie już w samym zakupie. Natomiast trzeba mieć już z tyłu głowy, że taka będzie prawdopodobnie przyszłość e-commerce.
Co może pójść nie tak w sklepie internetowym?
- Cena wyłącznie w grafice albo doładowywana skryptem po interakcji – agent może jej nie odczytać.
- Niejasny status dostępności – „ostatnie sztuki” czy „w magazynie” bez konkretnej wartości, np. „zostały 3 sztuki” – informacja ta powinna się też znaleźć w danych strukturalnych.
- Warianty produktu (rozmiar, kolor) obsługiwane niestandardowym widgetem, bez osobnych URL, bez odzwierciedlenia w danych strukturalnych.
- Koszt dostawy ujawniany dopiero w koszyku – agent porównujący całkowity koszt może odrzucić ofertę jako niekompletną.
- Brak identyfikatorów GTIN/SKU utrudniający dopasowanie tego samego produktu między różnymi sklepami.
Co agentic search zmienia w usługach?
Hotele, gabinety lekarskie, warsztaty, restauracje i usługi realizowane w umówionych terminach mają jeszcze trudniejsze zadanie, bo agent musi przejść cały wieloetapowy proces, a nie tylko odczytać stałą informację ze strony.
W ramach typowej ścieżki, żeby przygotować podsumowanie dla użytkownika, agent musi:
- sprawdzić dostępność w kalendarzu,
- wybrać termin,
- wybrać wariant usługi,
- wypełnić dane,
- wygenerować potwierdzenie.
Każdy z tych kroków bywa zaimplementowany niestandardowo, a ta niestandardowość to główny wróg agenta.
Na co zwrócić uwagę?
- Widget kalendarza zbudowany na <div> bez ról i etykiet będzie dla agenta słabo czytelny – powinien mieć poprawne role, opisy dat i stanów, np. „wolne”/”zajęte”/”niedostępne”.
- Dostępność terminów widoczna wyłącznie jako kolor komórki to informacja czysto wizualna – idealna dla człowieka, ale dla agenta potrzebny jest tekstowy odpowiednik.
- Zachowywanie progresu w wypełnianiu pól – jeśli powrót do poprzedniego kroku zresetuje formularz, agent może utknąć, albo wielokrotnie wypełnić ten sam formularz.
- Potwierdzenie rezerwacji najlepiej, aby było wyświetlane na osobnym URL-u – wtedy agent będzie miał pewność, jaki jest status akcji.
Pozyskiwanie leadów vs agentic search – co się zmienia?
W kontekście generowania leadów agent najczęściej będzie się wcielał w rolę użytkownika wypełniającego formularz kontaktowy, zapytanie ofertowe lub wniosek. Cała wartość transakcji zależy więc od sposobu zakodowania tego elementu na stronie. Tworząc swój formularz musisz więc pamiętać o tych zasadach:
- Określ funkcje pól – agent musi wiedzieć, że w polu „Firma” ma wpisać nazwę firmy, a nie, np. numer NIP.
- Zadbaj o czytelną walidację – komunikat „nieprawidłowy format” musi wskazywać, którego pola dotyczy, czego dotyczy błąd i jak go naprawić.
- Wyświetlaj potwierdzenia wypełnienia / wysłania – bez tego agent może nie zaraportować użytkownikowi, że zadanie zostało wykonane.
Jak połączyć techniczne SEO, UX, CRO i dostępność dla agentów AI w jednym audycie?
Chociaż może brzmieć to niewiarygodnie, wiele założeń, które już teraz są stosowane powszechnie podczas audytów SEO, UX, czy CRO, sprawdzą się także w analizie pod boty AI.
Przepis na audyt strony agent-friendly
- Techniczne SEO – poza standardowymi elementami technical SEO, sprawdź dostępność dla robotów w robots.txt, elementy zakodowane z użyciem JavaScript, szybkość ładowania strony i stabilność layoutu (CWV), renderowanie po stronie serwera, dane strukturalne, budowę DOM i drzewa dostępności, WebMCP;
- GEO – sprawdź, czy strona prezentuje swoje USP, tworzy treści z wykorzystaniem BLUF i FAQ, realizuje założenia E-E-A-T, pozyskuje linki zwrotne i wzmianki o marce w serwisach zewnętrznych;
- UX – sprawdź hierarchię informacji na stronie, przewidywalne wzorce interakcji;
- CRO – sprawdź, czy przyciski CTA, formularze, moduły rezerwacji czy umawiania wizyt są zakodowane z użyciem semantycznego HTML, przedstawiają tekstowo informacje o progresie i klarownie informują o powodzeniu.
Podsumowanie – co zrobić już dziś?
Strony agent-ready to przede wszystkim strony, które mają porządek od środka – czyli w kodzie. Wszystkie efektowne elementy wizualne mogą robić wrażenie na ludziach, ale agentom mogą wręcz przeszkadzać. A więc, jeśli chcesz dostosować swoją stronę pod agenty AI trzeba trochę zacząć taką pracę u podstaw.
Jeśli chcesz, szybko sprawdzić podstawy dostępności strony dla AI, zacznij od tego:
- Przejdź ścieżkę zakupową lub kontaktową wyłącznie klawiaturą – jeśli gdzieś natrafisz na bloker, agent też może się tam zatrzymać.
- Sprawdź, czy kluczowe treści są widoczne bez JavaScriptu – cena, dostawa, najważniejsze cechy produktów lub usług, dostępność, przyciski akcji.
- Przejrzyj robots.txt – sprawdź, czy nie blokujesz botów AI.
- Sprawdź i uzupełnij dane strukturalne – minimum Product/Offer, LocalBusiness, FAQPage.
- Sprawdź, czy strona spełnia WCAG i czy drzewo dostępności poprawnie odzwierciedla funkcje elementów.
