Czyj to bug? Gdy klientem jest agent AI

Klientka prosi asystenta AI o buty w rozmiarze 23 dla dziecka. Asystent przeszukuje sieć, porównuje kilkanaście sklepów i wraca z konkretem: model, cena 199 zł, link. Klientka wchodzi, wybiera rozmiar 23 i dowiaduje się tego, czego asystent nie ustalił: tego rozmiaru nie ma na stanie. Kafelek jest nieaktywny, tyle że wynika to wyłącznie z jego wyglądu.

Zatrzymajmy się na moment przy jednym pytaniu, bo od odpowiedzi na nie zależy cała reszta.

Czyj to jest bug?

Odruchowa odpowiedź brzmi: AI się pomyliło. Halucynacja, zawodny model, kolejny powód, żeby podchodzić do tego z rezerwą. Odpowiedź wygodna, bo zdejmuje problem z nas. Model jest cudzy, więc i wina cudza. Zgłoszenie zamykamy jako nie nasz komponent.

Tyle że zanim przypiszemy winę modelowi, warto zajrzeć w kod strony. W typowym sklepie kafelek rozmiaru okaże się zwykłym <div> ze zmienionym kolorem tła, bez atrybutu disabled, bez słowa "niedostępny", bez danych strukturalnych. Nic w takiej stronie nie zapisuje stanu biznesowego w sposób możliwy do odczytania inaczej niż przez interpretację wyglądu.

Warto zauważyć, kogo jeszcze taka strona zawodzi. Informacja zakodowana wyłącznie w kolorze jest niedostępna nie tylko dla agenta, ale też dla czytnika ekranu, trybu wysokiego kontrastu i dla każdego, kto korzysta z serwisu inaczej niż przez uważne oglądanie siatki kafelków. Problem nie należy do gatunku nowych, a raczej do gatunku tych, który właśnie zyskał nową grupę poszkodowanych.

To nie jest prognoza na 2030 rok

W marcu 2026 InPost zapowiedział Von Halsky’ego, asystenta robiącego zakupy w imieniu użytkownika. Rafał Brzoska ujął to tak: "To nie jest kolejny chatbot. To prawdziwy asystent, który przejmuje żmudne scrollowanie filtrów i porównywarek. (…) Kończymy erę przeglądania, zaczynamy erę inteligentnych agentów". Sam zresztą studził emocje na konferencji wynikowej: "Nie jesteśmy przekonani, że to będzie sukces (…) To jest kolejny wielki bet InPostu".

Miesiąc wcześniej OpenAI uruchomiło zakupy w ChatGPT z ponad milionem sklepów Shopify. W marcu Shopify włączyło witryny obsługujące agentów. Google i Stripe rozwijają protokoły opisujące, jak agent ma legitymizować zakup w imieniu człowieka. Morgan Stanley prognozuje, że do 2030 roku w Stanach Zjednoczonych z agentów zakupowych będzie korzystać około 126 milionów osób. Szacunki wydatków rozjeżdżają się przy tym zależnie od wariantu raportu, więc trzeba traktować je raczej jako rząd wielkości niż liczbę, którą można wkleić w prezentację dla zarządu.

Polska branża zauważyła to szybko. Diagnozę, i to trafną, postawiły u nas przede wszystkim zespoły SEO:

"Do tej pory strony internetowe i ich treści były starannie przygotowane pod użytkownika, np. za pomocą strategii SEO czy UX. Te działania jednak niekoniecznie muszą odpowiadać sztucznej inteligencji." powiedział Robert Smalarz z Delante w sierpniu 2026 roku. 

"Na agenta nie działa piękny layout, storytelling ani perswazja wizualna. Liczy się jakość, kompletność i struktura danych produktowych." twierdzi Julianna Janusz z Selly.  

Zgadzam się z obiema wypowiedziami i nie zamierzam z nimi polemizować. Różnica leży w pytaniu, które stawiamy dalej. SEO i AI visibility koncentrują się na tym, żeby serwis i jego dane były możliwe do znalezienia, zrozumienia i wykorzystania przez system wyszukujący lub rekomendujący: to pytanie o widoczność i zrozumiałość. Tester może postawić inne pytanie: czy agent, który już nas znalazł i zrozumiał, dostał dość informacji, żeby ocenić stan oferty poprawnie, i co zrobić, kiedy tych informacji nie dostał. To pytanie o zgodność ze stanem faktycznym, czyli o rzecz, którą umiemy zgłosić, przypisać i naprawić. Widoczność i zrozumiałość bez poprawnych danych oznaczają tylko skuteczniejsze rozpowszechnianie nieprawdy.

Warto przy okazji znać jedno pojęcie, które bywa używane w tym kontekście i oszczędza tłumaczenia: agentability. To miara tego, na ile interfejs jest zrozumiały i operowalny dla agenta; odpowiednik użyteczności i dostępności, tylko dla użytkownika maszynowego. Nie proponuję własnej nazwy zamiast niej; mnożenie skrótów niczego by nie poprawiło. Warto natomiast zauważyć, że pisze się o niej głównie po stronie projektowej, jako o postulacie w rodzaju "testujmy agentability obok użyteczności". Rzadziej pada odpowiedź, jak to zrobić, tzn. jak wygląda przypadek testowy, co jest wynikiem oczekiwanym, kto dostaje zgłoszenie i jak je uzasadnić.

Brakuje więc nie tyle pojęć, ile dojrzałej, powszechnie przyjętej praktyki testowej. Pojedyncze inicjatywy, jak przywoływane dalej badanie a14y czy akademickie benchmarki agentów, dopiero się kształtują. I dokładnie w tym miejscu tester ma coś do powiedzenia.

Dług projektowy, o którym nie wiedzieliśmy, że go zaciągamy

Przez dwie dekady projektowaliśmy interfejsy przy jednym niepisanym założeniu: że po drugiej stronie jest człowiek, który sam uzupełni brakujące informacje. Jeśli czegoś nie będzie wiedział, domyśli się z układu strony, z przyzwyczajenia lub z doświadczenia zakupowego. Z takiego założenia wyrasta cały język e-commerce. Przekreślona cena znaczy "promocja". Wyszarzony kafelek znaczy "niedostępne". Czerwona ramka znaczy "błąd w formularzu". Ikonka koszyka w rogu znaczy dokładnie to, co znaczy i nikt nie musi tego tłumaczyć.

Ten proces działał, dopóki po drugiej stronie ktoś rzeczywiście domyślał się reszty. Problem polega na tym, że cały ten sens siedzi w warstwie prezentacji, a nie w danych. I dopiero teraz zaczyna to kosztować.

*Doprecyzowanie co do ostatniej liczby: badanie A11y-CUA zostało formalnie opublikowane na CHI 2026 (zespół z UC Berkeley i University of Michigan). Cytowane wyżej wyniki dotyczą modelu Claude Sonnet 4.5. Drugi testowany w tym badaniu model wypadł w tych samych warunkach zauważalnie gorzej. Link do oryginału w źródłach na końcu.

Z tych liczb płynie wniosek praktyczny, choć trzeba go dobrze wyważyć. Wynik a14y w dużym stopniu mierzy co innego niż dostępność, czyli sitemapy, robots.txt, nagłówki odpowiedzi, obecność danych strukturalnych, czyli infrastrukturę, po której w ogóle porusza się agent. Ale jedna z trzech grup kontroli w tym badaniu dotyczy wprost semantyki strony: etykiet przycisków, właściwych elementów formularzy zamiast klikalnych <div>, komunikatów o stanie w treści, a nie w samym stylu, oraz poprawnych atrybutów ARIA. I to właśnie ta część pokrywa się z WCAG, które od lat wymaga tego samego i to w sposób, który daje się odczytać maszynowo. Jeśli w Twoim zespole ktoś już tego pilnuje, część pracy nad agentability jest zrobiona, tyle że nikt jej tak nie nazwał.

Nie oznacza to, że oba tematy się pokrywają. WCAG zajmuje się też rzeczami, które agentowi są obojętne, jak kontrast czy zachowanie układu przy powiększeniu. W drugą stronę działa to podobnie: dane strukturalne o cenie i dostępności nie mają wpływu na dostępność dla ludzi. Wspólna jest natomiast zasada: jeśli informacja istnieje wyłącznie jako efekt wizualny, to nie istnieje dla nikogo, kto nie ogląda strony w domyślny sposób.

Jeżeli dostępność w Twojej organizacji od lat leży na dnie backlogu, właśnie pojawił się dla niej dodatkowy argument. Do tej pory uzasadnieniem była zgodność z przepisami i grupa użytkowników, którą część firm po cichu uznawała za marginalną. Teraz do tej samej listy dochodzi ruch, który przychodzi z zamiarem zakupu i nie sfinalizuje transakcji, jeśli nie zdoła odczytać ze strony informacji o tym, co jest dostępne i za ile. Ten sam nakład pracy zaczyna się bronić dwoma niezależnymi uzasadnieniami naraz, a jedno z nich mówi językiem, którym posługuje się dział finansowy.

Trzy pytania zamiast jednego

Kiedy pytamy "czy nasza strona działa dla AI", zwykle mieszamy ze sobą trzy różne rzeczy. Rozdzielenie ich zmienia to, co wpisujemy do zgłoszenia.

Czy agent nas znajdzie? 

To pytanie jest najbliższe temu, co znamy z SEO, i temu poświęcono już najwięcej uwagi.

Czy agent poprawnie odczyta to, co znalazł? 

Czy rozpozna, że ten ciąg znaków to cena, tamten to rozmiar, a ten przycisk dodaje do koszyka?

Czy agent dostał dość informacji, żeby wybrać właściwie? 

Jest to pytanie o kompletność danych i jest sednem sprawy, a mówi się o nim najmniej.

Wróćmy do buta. Agent znalazł produkt, więc na pierwsze pytanie uzyskaliśmy odpowiedź twierdzącą. Agent odczytał nazwę, cenę i rozmiar, więc odpowiedź na drugie również mamy. A mimo to wybrał źle, bo informacji o dostępności nie było nigdzie w formie, którą mógłby przetworzyć. Zawiodło dopiero trzecie ogniwo, jako jedyne. 

Niech jako analogia posłuży różnica między <div class="btn-disabled"> a <button disabled>. Wyglądają identycznie, ale w pierwszym przypadku informacja "ten element jest nieaktywny" istnieje wyłącznie jako reguła CSS, a w drugim, czy to przez atrybut disabled, czy przez aria-disabled="true", jest zapisana w strukturze dokumentu, więc każde narzędzie może ją odczytać niezależnie od tego, czy stronę ogląda, czy parsuje.

Mało kto powie dziś: "użytkownik czytnika ekranu powinien się domyślić, że ten przycisk jest nieaktywny". Zwykle uznajemy to za defekt i naprawiamy. Ale wciąż zdarza nam się myśleć: "AI powinno wiedzieć, że tego rozmiaru nie ma". Warto sprawdzić, z czego właściwie miałoby to wiedzieć.

Nie ma głupich pytań

Czy to nie jest po prostu SEO pod AI, tylko nazwane inaczej? 

Nie, i to różnica warta pilnowania. SEO i AI visibility odpowiadają na pytanie "jak sprawić, żeby serwis i jego dane dało się znaleźć, zrozumieć i wykorzystać". Tutaj pytanie brzmi "czy agent, który już nas znalazł, dostał dość informacji, żeby ocenić stan oferty poprawnie". Te cele czasem się pokrywają, ale kiedy się rozjeżdżają, SEO każe informację wyeksponować, a nam każe ją doprecyzować. Efektem SEO jest pozycja, a efektem tej pracy jest zgłoszenie defektu.

Skoro agent i tak czyta HTML, to po co jeszcze dane strukturalne?

Bo HTML mówi, że w danym miejscu jest jakiś tekst i jaką pełni rolę w strukturze strony, ale niekoniecznie mówi wprost, co ten tekst znaczy biznesowo; dane strukturalne dopowiadają to znaczenie w jednoznacznym, uzgodnionym formacie. Z HTML-a wynika, że w elemencie jest tekst "199 zł". Z obiektu Offer wynika, że to cena tego konkretnego wariantu, w tej walucie, przy tym stanie magazynowym. Agent może dojść do tego samego z samego HTML-a, ale wtedy zgaduje. A zgadywanie czasem wychodzi mu źle i wracamy do buta w rozmiarze 23.

Czy nie testuję w ten sposób cudzego modelu, na który nie mam wpływu?

Nie, jeśli poprawnie ustawisz obiekt testu. W tym konkretnym teście agent jest przede wszystkim przyrządem pomiarowym, a nie badanym systemem, tak samo jak czytnik ekranu w testach dostępności. Nie oceniasz, czy jeden model jest lepszy od drugiego. Sprawdzasz, czy Twoja strona dostarcza informacji, których model potrzebuje. Jeśli nie dostarcza, defekt jest Twój niezależnie od tego, którego agenta użyłeś do jego wykrycia.

Zanim wpiszesz "wina AI"

Oto fragment, z którego skorzystasz najszybciej. Rozwiązany jest tu konkretny problem organizacyjny: ucięta dyskusja, która bez ustalonych konkretów zawsze zmierza w tę samą stronę. 

Obie strony mówią wtedy o czymś innym i obie mają rację we własnym układzie odniesienia. Zamiast rozstrzygać, kto zawinił, prościej przejść po kolei przez cztery pytania. Pierwsze, na które padnie odpowiedź przecząca, wskaże nam miejsce do naprawy.

Czy system źródłowy zna prawidłowy stan?

Sprawdzamy API albo bazę. Jeśli tam też jest "dostępny", dalsza analiza nie ma sensu, gdyż jest to zwykły błąd danych i naprawiamy go tak, jak każdy inny. Zaskakująco często sprawa kończy się już tutaj.

Czy strona w ogóle pokazuje tę informację?

Backend wie, że produktu nie ma, ale na liście wyników widnieje sama cena. Wtedy rzecz rozstrzyga się na poziomie decyzji projektowej, nie kodu. Ktoś kiedyś uznał, że ta informacja nie musi być widoczna na tym ekranie, i wtedy miał rację.

Czy da się ją odczytać bez interpretowania wyglądu?

Informacja jest, ale przedstawiona jest za pomocą koloru, przekreślenia albo ikony bez etykiety. Brakuje wtedy semantyki lub danych strukturalnych. To ten sam defekt, który zgłosiłby audyt dostępności.

Wszystko powyżej działa, a wynik i tak jest zły?

Strona podała stan jednoznacznie, również w danych strukturalnych, a mimo to rekomendacja jest błędna. Dopiero tutaj ograniczenie leży po stronie narzędzia, a jeśli mówimy o niezależnym agencie zewnętrznym, na jego zachowanie zespół serwisu nie ma bezpośredniej kontroli. Uczciwą reakcją jest odnotowanie tego faktu, a nie próba naprawiania cudzego modelu.

Nie jest to propozycja stworzenia nowej taksonomii ani branżowego standardu, tylko wyznaczona kolejność sprawdzania, dzięki której rozmowa staje się bardziej uporządkowana. Jej zaletą jest to, że zdejmuje z dyskusji ton oskarżenia i dzięki temu, zamiast ustalać, kto zawinił, ustalamy, na którym etapie informacja przestała istnieć.

Podejrzewam, że najczęściej rozmowa zatrzyma się na pytaniu drugim. Tam kryje się pewna ironia, która bywa najskuteczniejszym argumentem w dyskusji z biznesem. Dostępność ukryto zwykle po to, żeby nie psuć konwersji. Tymczasem klient, który przyszedł z polecenia asystenta po konkretny produkt i zastał pustą półkę, nie kupuje niczego innego, tylko po prostu wychodzi. Nie zobaczył wcześniej alternatywy, bo agent zaproponował mu jedną ofertę, a nie listę do przejrzenia. Sesja kończy się bez transakcji, koszt pozyskania został poniesiony, a rozczarowanie zapisuje się na koncie marki, nie modelu.

To nie jest problem jednego buta

Dostępność rozmiaru jest wygodnym przykładem, bo każdy ją rozumie, ale ten sam mechanizm, warunek istniejący w biznesie i nieobecny w danych, powtarza się w wielu miejscach i branżach. Poniżej kilka innych przypadków, które warto sprawdzić na własnym produkcie:

Przykład 1

Branża: Handel 

Problem: Cena wariantowa

Na liście widnieje informacja "od 149 zł", bo tyle kosztuje najmniejsze opakowanie. Agent zapisuje 149 i podaje tę kwotę klientowi. Klient wchodzi po wariant, którego naprawdę chciał, i widzi 289 zł. Formalnie nikt nie skłamał, praktycznie klient dostał złą informację. Ten sam mechanizm działa wszędzie tam, gdzie cena zależy od kombinacji parametrów: przy rezerwacji pokoju czy wycieczki widoczna liczba dotyczy zwykle najtańszego zestawu terminu, liczby osób i wyżywienia.

Brak informacji na stronie

Przykład 2

Branża: Handel 

Problem: Cena, która się nie zgadza

Agent podaje klientowi cenę 229 zł. Klient klika link i widzi 279 zł. Powodów bywa kilka: promocja wygasła między jedną wizytą a drugą, cena w danych strukturalnych nie nadąża za tą w koszyku, feed produktowy aktualizuje się raz na dobę, albo cena zależy od zalogowania czy regionu. Z perspektywy klienta wszystkie te przyczyny wyglądają identycznie i nazywają się "oszukali mnie".

Błąd danych albo braki w reprezentacji

Przykład 3

Branża: Handel 

Problem: Koszt dostawy

Cena produktu znajduje się w danych strukturalnych, koszt dostawy pojawia się dopiero w koszyku, po wybraniu metody dostawy. Agent porównuje ofertę z konkurencją, licząc samą cenę produktu. Wyższa cena produktu z darmową dostawą zawsze przegra w prostym zestawieniu. Takie porównanie od początku nie było uczciwe.

Brak informacji na stronie

Przykład 4

Branża: Usługi

Problem: Termin realizacji 

Baner na karcie produktu obiecuje wysyłkę w 24 godziny. Jest to grafika, część szablonu kategorii. Ten konkretny produkt jest sprowadzany na zamówienie i czeka się na niego dwa tygodnie, co widać dopiero w rozwijanej sekcji ładowanej po kliknięciu.

Informacja tylko w warstwie wizualnej

Przykład 5

Branża: Finanse i ubezpieczenia 

Oprocentowanie "od 6,9%" zależy od oceny zdolności kredytowej, a konkretne warunki dostępne są w podlinkowanym PDF-ie, opisanym drobnym drukiem. Agent podaje najniższą liczbę jako ofertę. Tu stawką nie jest już nietrafiona rekomendacja, tylko potencjalne wprowadzenie klienta w błąd co do warunków umowy.

Braki w reprezentacji, ryzyko regulacyjne

Przykład 6

Branża: Każda

Problem: Promocja czasowa 

Licznik odlicza "jeszcze 4 godziny" w komponencie JavaScript. W danych strukturalnych nie ma daty końca obowiązywania ceny. Agent, który odwiedził stronę wczoraj i zapamiętał cenę promocyjną, poleci ją jutro jako aktualną.

Informacja widoczna tylko w warstwie wizualnej

Osobnej uwagi wymaga sytuacja, w której klient nie weryfikuje niczego przed zamówieniem. Ufa on asystentowi i finalizuje zakup, a rozbieżność wychodzi na jaw dopiero przy odbiorze: laptop ma połowę deklarowanej pamięci, bo agent odczytał parametry innego wariantu z tej samej karty; mebel nie mieści się we wnęce, bo podane wymiary dotyczyły opakowania; zestaw przyszedł bez elementu, który w opisie brzmiał jak część kompletu. Klient staje przed wyborem: rezygnacja i zwrot albo dopłata i korekta zamówienia.

Działa tu mechanizm, który w testowaniu znamy od dawna: koszt defektu rośnie wraz z etapem, na którym zostaje wykryty. Ta sama rozbieżność w specyfikacji wychwycona na etapie przeglądu wymagań kosztuje kilka minut rozmowy, a wychwycona przez klienta stojącego nad rozpakowanym kartonem kosztuje zwrot, obsługę reklamacji, logistykę i pracę zespołu wsparcia.

Delegowanie zakupu asystentowi przesuwa punkt wykrycia jeszcze dalej niż zwykle. Klient, który sam przegląda kartę produktu, zwykle po drodze sam zweryfikuje dodatkowe informacje: sprawdzi wymiary, upewni się, że wariant się zgadza. Klient, który powiedział "zamów mi to", tej kontroli nie wykonuje, bo po to delegował zadanie. Sprawdzenie, które kiedyś odbywało się mimochodem, nie odbywa się już nigdzie.

Konsekwencje wykraczają poza pojedynczą transakcję. Klient rzadko rozlicza z pomyłki model językowy, którego nazwy zwykle nawet nie kojarzy w tym kontekście. Rozlicza sklep, w którym złożył zamówienie. A ponieważ nie ma jak stwierdzić, czy zawinił asystent, czy sprzedawca, domyślnie przyjmuje wersję prostszą: że dane były nierzetelne. Kolejnym razem może już nie wrócić, może nie polecić, może nie zaufać przy większym zamówieniu. Dla firm działających w modelu powtarzalnej współpracy (B2B, abonamenty, zaopatrzenie) taki koszt jest znacznie dotkliwszy niż jeden nieudany koszyk.

Jak może wyglądać taki audyt

Poniżej pięć kroków, które składają się na jedno możliwe podejście. Nie jest to certyfikowana metodyka ani procedura do wdrożenia w całości, a raczej szkic. Przeanalizowanie jednej ścieżki zakupowej zajmie jedno popołudnie, a całość bez problemu można dostosować do własnego kontekstu.

Cel zamiast kroków

Klasyczny przypadek testowy opisuje ścieżkę: wejdź, kliknij, wpisz, sprawdź. Tutaj przydaje się co innego: intencja klienta zapisana w takim języku, w jakim klient naprawdę mówi.

Zamiast: "Znajdź dostępne oferty butów marki X w rozmiarze 23, filtrując po dostępności, sortując rosnąco po cenie", można spróbować: "Znajdź mi tanie buty w rozmiarze 23".

To rozróżnienie ma znacznie większe znaczenie niż mogłoby się wydawać na pierwszy rzut oka. Realni użytkownicy nie piszą precyzyjnych zapytań z parametrami. Piszą krótko i niedbale, a resztę zakładają za oczywistą, w tym to, że oferta ma być możliwa do kupienia. Jeżeli przetestujesz serwis rozbudowanym poleceniem, w którym sam podpowiesz agentowi, żeby sprawdził dostępność, przetestujesz własną umiejętność formułowania poleceń, a nie swój produkt.

Uwaga na przemilczenia

Uruchamiasz zadanie i sprawdzasz nie tylko wynik, ale też to, co agent po drodze ustalił. Jakie atrybuty produktu wymienił? Skąd wziął cenę? Czy w ogóle poruszył kwestię dostępności, czy temat po prostu nie istniał?

Zwróćmy uwagę na to, czego agent nie powiedział. Jeżeli agent nigdy nie wspomina o stanie magazynowym, zwykle znaczy to, że nie znalazł na ten temat nic, a nie że uznał produkt za dostępny. 

Pomocne jest poproszenie o wynik w ustrukturyzowanej formie, zawierającej nazwę, cenę, walutę, rozmiar, dostępność i link. Taki wynik nie jest wiarygodny, ponieważ model potrafi uzupełnić brakujące pole domysłem. Ale wtedy widać wprost, które pola dało się wypełnić z Twojej strony, a które musiał zgadnąć.

Oracle testowy poza samą stroną

Potrzebny jest tu wiarygodny oracle, czyli źródło wyniku oczekiwanego: API, baza, panel administracyjny, a nie to, co samemu odczytało się z tej samej strony. Wtedy zestawia się ze sobą dwie interpretacje tego samego niejednoznacznego źródła i wynik niczego nie rozstrzyga. Rozbieżność między jednym a drugim to defekt jak każdy inny: opisuje się, na którym etapie informacja przestała istnieć, i zgłasza normalną ścieżką.

Która wersja informacji działa

Ten krok bywa najciekawszy, bo zamiast diagnozy daje materiał do decyzji projektowej. Polega na przygotowaniu kilku wariantów tej samej karty produktu i zadaniu na każdym tego samego pytania:

• sama cena, bez informacji o stanie (czyli to, co masz dziś)
• cena plus widoczny tekst "rozmiar 23: niedostępny"
• cena plus stan OutOfStock w danych strukturalnych
• jedno i drugie, plus disabled na elemencie wyboru

Przy powtarzanych próbach widać, czy i od którego wariantu rośnie odsetek przypadków, w których agent poprawnie odrzuca niedostępną ofertę. Pojedyncze uruchomienie niewiele mówi, bo model bywa niedeterministyczny. Zamiast opinii pojawia się obserwacja, jaka reprezentacja informacji faktycznie zadziałała w tym konkretnym przypadku. Taki argument bywa na spotkaniu z product ownerem znacznie mocniejszy niż "powinniśmy dodać dane strukturalne, bo tak się teraz robi".

Miejsce w procesie

Jednorazowy audyt bywa ciekawostką, o której nikt nie pamięta miesiąc później. Jeśli ma zostać na dłużej, warto poszukać dla niego miejsca tam, gdzie i tak przechodzi każda zmiana. Poniżej kilka możliwości, do wyboru zależnie od tego, jak pracuje zespół:

• Kryteria akceptacji przy historyjkach dotyczących ceny, wariantów i dostępności. Stan produktu musi być odczytywalny bez polegania wyłącznie na kolorze lub stylu. To brzmi jak wymóg WCAG i rzeczywiście nim jest, z dodanym drugim beneficjentem.
• Definition of done dla komponentów wyboru wariantu i znaczników stanu. Warstwa wizualna i dane muszą mówić to samo.
• Przegląd kodu. Czy zmiana nie wprowadza rozbieżności między warstwą prezentacji a danymi strukturalnymi? Nie jest to wyłącznie problem agentów. Google wymaga zgodności ceny i dostępności między stroną, danymi strukturalnymi a feedem produktowym, a niezgodność potrafi skutkować odrzuceniem oferty.
• Regresja na kilku najważniejszych ścieżkach zakupowych, uruchamiana rzadziej niż testy jednostkowe, ale regularnie.

Adres, pod który agent może trafić

Jest jeszcze jeden wątek, w rozmowie o agentach poruszany rzadko, a rozwiązujący kilka opisanych wyżej przypadków naraz. Chodzi o to, czy konkretny wariant produktu ma własny adres.

W wielu sklepach wybór rozmiaru czy koloru odbywa się wyłącznie po stronie przeglądarki. Adres pozostaje ten sam, zmienia się tylko stan komponentu w JavaScripcie. Dla klienta bywa to wygodne, dla agenta oznacza, że nie ma jak wskazać wariantu inaczej niż przez odtworzenie interakcji: znajdź właściwy element, kliknij, poczekaj na przerysowanie, odczytaj wynik. Każdy z tych kroków może się nie udać, a przy okazji trzeba założyć, że agent w ogóle wykonuje skrypty, co nie zawsze jest prawdą.

/produkty/but-xyz → wariant wybierany skryptem, adres nic nie mówi

/produkty/but-xyz?rozmiar=23 → wariant w adresie, stan czytelny od razu

Druga wersja pozwala trafić od razu do właściwego wariantu i odczytać jego cenę oraz dostępność bez wchodzenia w interakcję. Przy okazji rozwiązuje problem, który zna każdy zespół wsparcia: link wysłany klientowi prowadzi tam, gdzie miał prowadzić. To klasyczny deep link, tylko poprowadzony nie do karty produktu, ale do konkretnego wariantu, o który klientowi chodziło. Warto przy tym pamiętać o tym, że parametry w adresach potrafią wygenerować tysiące niemal identycznych stron. Wybrane warianty trzeba więc oznaczyć jako kanoniczne, a resztę zostawić poza indeksem. To osobna decyzja i lepiej podjąć ją świadomie niż przypadkiem.

Na horyzoncie jest jeszcze jedna zmiana warta odnotowania. W czerwcu 2026 IETF opublikował RFC 10008, czyli metodę QUERY: bezpieczną i idempotentną jak GET, ale przenoszącą zapytanie do ciała żądania. Rozwiązuje realny problem rozbudowanych wyszukiwań, które nie mieszczą się w adresie. Trwa też dyskusja nad wsparciem tej metody w formularzach HTML.

Przeniesienie parametrów do ciała żądania odbiera im adresowalność – takiego stanu nie da się przesłać linkiem ani zapisać w zakładce.  Taki układ służy rozbudowanym wyszukiwarkom, ale konkretny wariant produktu nadal najbardziej zyskuje na własnym, prostym adresie. Równolegle w WHATWG pojawiła się propozycja rozszerzenia znaczników HTML wprost pod kątem agentów, czyli rozpoznawania typu treści, w tym produktów. Na razie odrzucono ją jako gotowy do wdrożenia pomysł, ale to pokazuje, w którą stronę zmierzają dyskusje. Ani wsparcie QUERY w formularzach, ani nowe znaczniki dla agentów nie są dziś gotowe do zastosowania. Sama metoda QUERY jako standard już istnieje, ale brakuje na razie jej wsparcia w przeglądarkach i formularzach.

Co z tym zrobi zespół

Kiedy defekt jest już zgłoszony, pada pytanie o rozwiązanie. Odpowiedzi układają się w drabinę i warto ją znać, żeby zgłoszenie zawierało sensowną rekomendację, a nie samo "popsute". Wśród nich znalazły się:

• Semantyczny HTML. <button disabled> zamiast <div> ze zmienionym tłem. To najtańszy poziom i zwykle najbardziej opłacalny, bo przy okazji poprawia dostępność.
• Jednoznaczny tekst. Przykładowy opis: "Rozmiar 23: niedostępny" zamiast samotnej liczby "0".  Banalne rozwiązanie, które zaskakująco często sprawdza się w praktyce. Modele językowe są przecież stworzone do czytania tekstu.
• Dane strukturalne. Obiekt Offer ze Schema.org: cena, waluta, dostępność, stan. Przy produktach z wariantami dostępność trzeba przypisać do konkretnego wariantu, modelowanego jako ProductGroup z osobnym Offer dla każdego rozmiaru, a nie do produktu jako całości; inaczej rozmiar 23 i 24 dzielą ten sam status, co jest dokładnie błędem z otwarcia tego tekstu. Warunkiem jest to, że te dane muszą być prawdziwe. InStock w znacznikach przy pustym magazynie będzie określane jako dezinformacja, a nie jako brak optymalizacji. Niespójność ceny czy dostępności między stroną a danymi strukturalnymi to jeden z powodów, dla których Google odrzuca ofertę lub zawiesza konto w Merchant Center.
• Interfejs wprost dla maszyny. Zamiast zmuszać agenta do wnioskowania z HTML-a, można wystawić mu funkcje do wywołania. W tym kierunku idzie WebMCP, proponowany standard rozwijany m.in. w W3C Web Machine Learning Community Group przy udziale inżynierów Google i Microsoftu. Cloudflare udostępniło w 2026 roku podgląd deweloperski pozwalający jednym przełącznikiem włączyć taki interfejs dla domeny, na razie eksperymentalnie i tylko w nowych wersjach Chrome. To jeszcze nie jest technologia produkcyjna i nie sugeruję planowania pod nią sprintu.

Dwa pierwsze poziomy kosztują niewiele, a potrafią rozwiązać większość problemu. Zanim więc w organizacji padnie pomysł wdrożenia eksperymentalnego protokołu, warto zerknąć, czy przyciski mają etykiety.

Wracamy do buta

Kafelek rozmiaru 23 nadal wygląda na nieaktywny. Człowiek bez problemu domyśli się w czym rzecz. Dlatego dobry UX nie stracił ani grama na znaczeniu, a projektowanie pod użytkownika pozostaje sensem tej pracy. Badania zachowań konsumentów potwierdzają zresztą, że nawet przy rekomendacji od AI, rozpoznawalność marki i opinie innych kupujących nadal decydują o zakupie. Marka zmienia funkcję, ale nie znika.

Zmieniło się co innego. Do tego samego kafelka trafia teraz nowa grupa odbiorców, która sama z siebie niczego się nie domyśli, bo wygląd elementu to nie jest informacja, tylko sposób zaprezentowania informacji, które muszą fizycznie istnieć w kodzie. 

Nie sądzę, żeby wymagało to nowego działu, nowego stanowiska ani rewolucji w procesie. Czasem wystarczy jedno dodatkowe pytanie podczas przeglądu wymagań: czy stan biznesowy tego ekranu da się odczytać bez interpretowania jego wyglądu? Bywa, że odpowiedź brzmi "tak" i temat zamyka się w minutę. Bywa też, że otwiera rozmowę, której nikt wcześniej nie odbył.

Nie twierdzę, że przedstawiona wyżej kolejność pytań jest jedyną sensowną ani że pięć kroków audytu sprawdzi się w każdym zespole. Można potraktować ten schemat jako propozycję do rozebrania na części i użycia tam, gdzie wniesie wartość. Ciekaw jestem zresztą, jak wypadnie u innych, bo o ile sam problem jest już nieźle opisany, o tyle praktyki dopiero się kształtują i najlepsze pomysły w tej sprawie pewnie jeszcze nie padły.

Jedno wydaje mi się warte zapamiętania: nie chodzi tu o testowanie sztucznej inteligencji, tylko o sprawdzenie, czy nasz serwis mówi prawdę również wtedy, gdy nikt po drugiej stronie nie domyśli się reszty.