Najważniejsze wnioski w pigułce
Co pokazało badanie
- MERJ przeprowadził 100 specjalnie zaprojektowanych testów, a potem badał strony produkcyjne. Każdy scenariusz uruchamiano wielokrotnie na kilku modelach AI.
- Badacze celowo nadali dwóm przyciskom mylące etykiety ARIA. Poproszony o zapisanie dokumentu agent w 25 na 25 prób najpierw kliknął „Cancel” (Anuluj).
- Duża i ważna biznesowo część błędów agentów wynika z tych samych wad struktury, nazewnictwa, stanów i komunikatów zwrotnych, które usuwa się w ramach dostępności (accessibility).
Dlaczego to problem dla biznesu
- Agent, któremu coś się nie udało, nie zgłosi błędu. Użytkownik zobaczy tylko komunikat „nie udało się” i może uznać, że Twoja strona nie działa z AI.
- Sesje agentów przypominają ruch ludzi. Uruchamiają JavaScript, przyjmują cookies i mogą zaburzać lejki, testy A/B oraz dane RUM.
- Agent, który 11 razy ponawia wysłanie formularza, w analityce wygląda jak jeden wyjątkowo uparty użytkownik.
Co z tego wynika
- Interfejs strony stał się w praktyce API dla oprogramowania, choć nikt go tak nie projektował.
- Publiczne benchmarki i skanery „gotowości na AI” nie powiedzą, czy agent przejdzie Twoją ścieżkę zakupową. Odpowiedź daje tylko pomiar na poziomie zadań na Twojej własnej stronie.
- Dostępność warto wdrażać przede wszystkim dla ludzi. Lepsza współpraca z agentami jest jej efektem ubocznym.
Trzeci rodzaj odwiedzającego: agent, który używa interfejsu
Przez dekady strony projektowano dla ludzi, a dla robotów wyszukiwarek dbano przede wszystkim o to, żeby dało się je znaleźć i zaindeksować. Agenci przeglądarkowi to trzeci typ odwiedzającego. Nie wystarczy im przeczytać treści - muszą jeszcze obsłużyć interfejs: kliknąć, wpisać dane i dokończyć zadanie. Zespół MERJ, kierowany przez Giacomo Zecchiniego, nazywa ten obszar warstwą interakcji (interaction layer).
To osobny problem niż ten, który zna każdy specjalista SEO. Pytania o dostęp botów, robots.txt czy firewalle dotyczą tego, czy treść da się pobrać. Pytania o SSR i hydratację dotyczą tego, czy strona się wyrenderuje. Warstwa interakcji zaczyna się dopiero potem: agent dotarł na stronę, wszystko się załadowało, ale czy potrafi z niej skorzystać? Szerzej opisywaliśmy tę zmianę w tekście o tym, jak agentic web zmienia technical SEO .
Do badania MERJ zbudował podejście, które nazywa Agent Interaction Monitoring. Mieści się ono między testami syntetycznymi, w których każdy krok jest zapisany w skrypcie, a Real User Monitoringiem, który rejestruje każdą sesję, jaka akurat się pojawi. Badacze definiują zadanie i uruchamiają sesję, ale kolejne kroki wybiera sam agent. System zapisuje, co agent zrobił, czy zamierzona zmiana stanu rzeczywiście nastąpiła i w którym dokładnie miejscu sekwencja się posypała.
Autorzy uczciwie zaznaczają, że prace zaczęli w listopadzie 2025 roku i od tego czasu zachowanie agentów wyraźnie się zmieniło. Scenariusz, który nie przechodził w grudniu, dziś może działać, a nowy model może wprowadzić zupełnie inny błąd. Wyniki trzeba więc traktować jako obraz konkretnych wersji modeli, a nie trwałe cechy agentów AI.
Niewidoczny problem: analityka i brak zgłoszeń
Pomiar ruchu w sieci długo opierał się na w miarę jasnym podziale na sesje ludzi i automatyczne crawlery. Agenci ten podział rozmywają. Działają w pełnej przeglądarce, uruchamiają JavaScript, przechowują cookies i generują sekwencje interakcji podobne do ludzkich. Część z nich się przedstawia, część nie, a niektóre przejmują sesję przeglądarki, którą chwilę wcześniej obsługiwał człowiek.
Najpoważniej cierpi na tym atrybucja. Skąd przyszła sesja bez referrera, która w rzeczywistości zaczęła się w oknie czatu? Jak ocenić ruch z adresu IP centrum danych w kraju, którego użytkownik nigdy nie odwiedził? Jeśli agent uruchamia skrypty analityczne po stronie klienta, trafia do lejków, eksperymentów i danych o wydajności. Przy większej skali takie niesegmentowane sesje mogą zafałszować analizę konwersji. Warto to uwzględnić przy porządkowaniu danych, podobnie jak przy diagnozowaniu ruchu nieprzypisanego w Google Analytics 4 .
Drugi problem to brak informacji zwrotnej. Gdy człowiek trafi na zepsuty interfejs, prędzej czy później się o tym dowiesz: z porzuceń w lejku, maila do obsługi klienta albo zgłoszenia w stylu „przycisk Dodaj do koszyka nie działa w Safari na telefonie”. Agent zwykle kilka razy ponawia próbę i rezygnuje, nie podając przyczyny. Nie powstaje żadne zgłoszenie ani wpis w logach, który mówiłby, że agent źle rozpoznał główną akcję na stronie. Taki błąd po prostu nie zostawia śladu.
Przeglądarka czy API - dlaczego interfejs wciąż wygrywa
Agenci korzystają z funkcji strony na dwa sposoby. Pierwszy to dostęp przez API, czyli komunikacja system-system, na przykład przez protokół MCP. Nie ma tu renderowania ani klikania - agent wywołuje funkcję z określonymi parametrami i dostaje ustrukturyzowane dane. Drugi sposób to dostęp przez przeglądarkę: agent otwiera prawdziwą stronę i obsługuje ją za pomocą analizy obrazu, parsowania DOM albo obu metod naraz, naśladując kliknięcia i pisanie na klawiaturze.
Autorzy zwracają uwagę, że to w gruncie rzeczy stary spór „scraping czy API”, który trwa mniej więcej od 2005 roku. Dostęp przez przeglądarkę jest kruchy, ale API mają ograniczony zasięg. Większość stron w ogóle ich nie udostępnia, a te, które to robią, często pomijają funkcje i dane dostępne w interfejsie. Kiedyś o wyborze decydował programista, któremu zależało na niezawodności. W świecie agentów decyduje użytkownik końcowy, któremu zależy na jak najmniejszym wysiłku. To zmienia odpowiedź na to pytanie.
MCP to obiecujący kierunek, czego przykładem jest integracja WooCommerce z Model Context Protocol . Każde takie połączenie wymaga jednak kolejnych kroków: trzeba znaleźć konektor, zalogować się, nadać uprawnienia i zdecydować, czy mu ufać. Przeglądarka tego nie potrzebuje, bo strona już istnieje. Wyszukiwanie odpowiada za odkrywanie, strona za markę, istniejące konto za tożsamość, a formularz checkoutu za płatności. Polecenie w stylu „zarezerwuj mi stolik w tej knajpce koło biura na czwartek” nie wymaga żadnej integracji.
Równolegle pojawia się kilka protokołów handlu agentowego. Google ogłosił w styczniu 2026 roku Universal Commerce Protocol, rozwijany wspólnie z Shopify, Etsy, Wayfair, Target i Walmart. OpenAI ze Stripe rozwijają Agentic Commerce Protocol, a AP2 odpowiada za autoryzację płatności. Jak przygotować sklep na pierwszy z nich, opisaliśmy w poradniku o optymalizacji e-commerce pod Universal Commerce Protocol . MERJ nie przesądza, który protokół wygra. Podkreśla tylko, że przeglądarka pozostaje najszerzej dostępną ścieżką awaryjną, bo interfejs już istnieje.
Jak agent „widzi” stronę i co psuje interakcję
Skoro agenci obsługują strony tak jak ludzie, interfejs staje się w praktyce API - tyle że bez specyfikacji, dokumentacji i zapowiedzi zmian. Każda niejednoznaczność może zerwać tę nieformalną umowę. Przykłady to przycisk z samą ikoną, element div udający przycisk, przesunięcie układu podczas ładowania czy okno modalne, z którego nie da się wyjść klawiaturą. Człowiek zwykle jakoś sobie poradzi, a agentowi brakuje kontekstu i intuicji, które pomagają przebrnąć przez słabo zaprojektowany interfejs.
Badacze dzielą agentów na trzy grupy pod względem tego, jak postrzegają stronę: nastawionych na strukturę, na obraz oraz hybrydowych. To raczej kategorie analityczne niż sztywne granice między produktami, bo implementacje się zmieniają i na różnych etapach zadania mogą korzystać z różnych źródeł. Agenci strukturalni czytają HTML, DOM, znaczniki semantyczne i drzewo dostępności, czyli tę samą reprezentację strony, z której od dekad korzystają czytniki ekranu. Jeśli system projektowy renderuje przycisk jako element div, drzewo dostępności pokazuje zwykły element ogólny, a nie przycisk. Z punktu widzenia agenta nie ma wtedy czego kliknąć.
Agenci wizualni działają inaczej. Robią zrzut ekranu, analizują obraz i klikają w konkretne współrzędne. Tak działa na przykład Computer Use od Anthropic. Tu kłopot sprawiają głównie przesunięcia układu i elementy, które wizualnie nie przypominają kontrolek. Eksperyment z mylącymi etykietami ARIA pokazuje drugą stronę medalu: agent, który ufa warstwie semantycznej, wykona to, co mówi kod, nawet jeśli na ekranie widać coś innego.
Co zrobić: dostępność i pomiar na poziomie zadań
Pierwszy wniosek jest bardzo praktyczny. Skoro znaczna część błędów agentów bierze się z tych samych wad, które usuwa dostępność, warto zacząć od solidnych fundamentów. Prawdziwe przyciski zamiast klikalnych divów, poprawne nazwy dostępne dla każdej kontrolki, spójne etykiety ARIA, czytelne komunikaty o stanie i błędach oraz stabilny układ strony pomagają jednocześnie ludziom i agentom. Autorzy zastrzegają jednak, że dostępność należy wdrażać dla osób z różnymi potrzebami, niezależnie od korzyści dla AI.
Drugi wniosek dotyczy pomiaru. Benchmarki i automatyczne skanery „gotowości na agentów” nie powiedzą, czy agent przejdzie przez Twój koszyk, formularz rezerwacji albo konfigurator produktu. Trzeba to sprawdzić na własnych, kluczowych ścieżkach - zdefiniować zadania, uruchomić na nich różne modele i weryfikować, czy zamierzona zmiana stanu faktycznie nastąpiła. Równolegle warto wydzielić w analityce ruch prawdopodobnie agentowy, żeby nie zaburzał danych o konwersjach.
W top.position patrzymy na to jako na naturalne rozszerzenie technicznego SEO i audytów UX. Wcześniej pytaliśmy, czy robot dotrze do treści i ją zrozumie. Teraz dochodzi pytanie, czy agent dokończy zakup. Jeśli prowadzisz sklep, połącz to z tematem agentic commerce i gotowości na modele językowe , a strategicznie - z tym, co firmy muszą zbudować na potrzeby agentic search .
Podsumowanie
Agenci AI już korzystają ze stron, ale ich błędy pozostają niewidoczne. Nie generują zgłoszeń, a do tego zaburzają analitykę. Badanie MERJ pokazuje, że najsolidniejszą podstawą współpracy z agentami jest dobrze wdrożona dostępność i semantyczny HTML. Jedynym wiarygodnym sprawdzianem pozostaje natomiast pomiar realnych zadań na własnej stronie.
Źródło: MERJ - How AI Agents Use Websites, Where They Fail, and What to Fix (otwiera się w nowej karcie)
