Najważniejsze wnioski w pigułce
Skala problemu
- W benchmarku Online-Mind2Web (300 codziennych zadań na 136 realnych stronach) najlepszy agent ukończył 61,3% zadań, a większość zatrzymała się w okolicach 30%.
- W teście WebGames ludzie osiągnęli 95,7% skuteczności, a najlepszy system AI zaledwie 43,1%.
- Mind2Web 2: najmocniejsze rozwiązanie (OpenAI Deep Research) sięgnęło 50–70% wyników człowieka przy wielokrokowych zadaniach — w połowie czasu.
- GAIA to jedyny benchmark, w którym agenci zrównali się z ludzką bazą 92%, ale mierzy odpowiadanie na pytania i użycie narzędzi, nie sterowanie przeglądarką.
Gdzie agenci się wykładają
- Błędy filtrowania i sortowania odpowiadały za 57,7% porażek najlepszego testowanego agenta (Operator), a błędy nawigacji za kolejne 19,6%.
- Nieudane próby zajmowały niemal dwa razy więcej kroków niż udane — głównie przez powtarzane akcje i nieoczekiwane wyskakujące okna.
- Filtry, nawigacja i pop-upy znajdują się na Twojej stronie, więc większość przyczyn leży po stronie właściciela serwisu.
Co zmienił Google
- Lighthouse 13.3 dodał eksperymentalną kategorię Agentic Browsing, oceniającą przydatność strony dla agentów AI.
- Kategoria opiera się na czterech audytach: poprawności drzewa dostępności, walidacji WebMCP, pliku llms.txt oraz wykryciu przesunięć układu (CLS).
Jak wygląda audyt
- Sześć etapów: baseline w Lighthouse, odczyt drzewa dostępności, przegląd ośmiu blokerów, realne przebiegi z agentem, decyzja o WebMCP oraz scoring i lista poprawek.
- Etap czwarty jest najważniejszy — tylko on daje dowody, a nie hipotezy.
- Pierwsze podejście do trzech zadań zajmuje około pół dnia roboczego.
- Najczęstsza pojedyncza naprawa: nieopisany przycisk ikonowy w globalnym nagłówku. Cztery linie HTML rozwiązują problem na całym serwisie.
Twoja strona jest widoczna, ale agent i tak nie dokończy zadania
Agent AI potrafi znaleźć Twoją podstronę, przeczytać ją i zacytować użytkownikowi — a mimo to nie wykonać jedynej rzeczy, o którą go poproszono. Dociera do cennika i nie potrafi wskazać przycisku uruchamiającego okres próbny. Otwiera formularz rezerwacji, układ przesuwa się pod kursorem i kliknięcie trafia w pustkę. Z perspektywy użytkownika to porażka Twojej strony, nie modelu.
Google nazwał ten problem, dodając w Lighthouse 13.3 kategorię Agentic Browsing, która punktuje przygotowanie witryny na agentów AI. Kilka tygodni później pojawił się zestaw narzędzi dla deweloperów. Kategoria jest eksperymentalna i oparta na propozycjach standardów, co Google jasno zaznacza w swojej dokumentacji.
To i tak przełom, ponieważ po raz pierwszy dostaliśmy mierzalną definicję gotowości na agentów. Wcześniej dyskusja o tym, czy strona „działa dla AI”, opierała się na intuicji. Teraz można ją sprowadzić do liczb w raporcie i konkretnych linii kodu.
Czym różni się gotowość na agentów od widoczności w AI search
Widoczność w wyszukiwaniu AI odpowiada na pytanie, czy jesteś w odpowiedzi modelu i czy jesteś w niej opisany poprawnie. Gotowość na agentów odpowiada na zupełnie inne pytanie: czy agent jest w stanie dokończyć na Twojej stronie realne zadanie — zarezerwować demo, pobrać dokument, dodać produkt do koszyka. Można świetnie rankować w odpowiedziach AI i mieć proces zakupowy, którego żaden agent nie przejdzie do końca.
Różnica bierze się z tego, jak agent czyta stronę. Człowiek patrzy na układ, ikony i kolory i wyciąga wniosek, w co kliknąć. Agent czyta kod pod spodem i pracuje na nazwach, które tam znajdzie — na liście, którą przeglądarki nazywają drzewem dostępności (accessibility tree). Wszystko, co ma sens wyłącznie wizualnie, dla agenta nie istnieje: ikona koszyka to dla człowieka obrazek, a dla agenta bezimienny przycisk.
Odległość między stroną, którą widzi człowiek, a stroną, na której agent może działać, to Twoja luka gotowości na agentów. Właściciel audytu widoczności to zwykle zespół SEO i content, a poprawki dotyczą treści, danych strukturalnych i obecności w źródłach zewnętrznych. Audyt gotowości należy do technicznego SEO, a naprawy trafiają do frontendu: semantyczny HTML, renderowanie po stronie serwera, stabilne układy i nazwane kontrolki.
Warto zauważyć, że nakładanie się tej pracy z dostępnością cyfrową jest niemal całkowite. Praktycznie każda poprawka, która pomaga agentowi, pomaga też osobie korzystającej z czytnika ekranu. Agenci dostarczyli argument biznesowy, którego zwolennicy dostępności latami nie potrafili przeforsować.
Cztery pytania, na które odpowiada audyt
Audyt gotowości na agentic search przechodzi przez cztery pytania w ustalonej kolejności. Pierwsze to odkrywalność — czy agent w ogóle dotrze do strony i ją przeczyta. To grunt, który pokrywa już klasyczny audyt widoczności i miejsce, w którym większość firm kończy pracę.
Drugie pytanie dotyczy interpretowalności: czy agent rozpozna, do czego służą Twoje przyciski i pola formularza. Każda kontrolka potrzebuje nazwy zapisanej w kodzie, bo ikona czytelna dla człowieka nie daje agentowi nic. Trzecie to stabilność — czy strona stoi w miejscu. Agent najpierw decyduje, gdzie kliknąć, potem klika, więc każde przesunięcie układu w tym oknie czasowym kończy się trafieniem w niewłaściwy element.
Czwarte pytanie brzmi: czy zadanie zostaje ukończone. Realny agent, realne zadanie, do samego końca. To jedyny etap mierzony wobec rzeczywistości — trzy poprzednie tylko tłumaczą wynik. Agent wykonujący zadanie zawsze przechodzi tę samą pętlę: przyjmuje cel, planuje kroki, działa na stronie, kończy albo rezygnuje. Kroki pierwszy, drugi i czwarty dzieją się wewnątrz modelu i żaden właściciel witryny na nie nie wpłynie. Krok trzeci dzieje się w Twoim HTML-u — i to tam zdarza się niemal każda porażka.
Sześć etapów audytu w praktyce
Do przeprowadzenia audytu potrzebujesz Chrome w wersji 150 lub nowszej (to ona zawiera kategorię Agentic Browsing), listy trzech do pięciu realnych zadań, które Twoja strona ma obsługiwać, oraz przynajmniej jednego agenta potrafiącego klikać i pisać na stronie — Comet Assistant, Claude in Chrome albo Chrome DevTools for Agents. Przyda się też porównanie surowego HTML-a z wyrenderowaną stroną dla kilku kluczowych szablonów, żeby zobaczyć, co pojawia się dopiero po wykonaniu JavaScriptu.
Etap pierwszy to baseline w Lighthouse. Kategorię Agentic Browsing uruchamiasz na stronie głównej, po jednym szablonie każdego typu i na wszystkich podstronach ścieżki krytycznej. Składa się z czterech audytów: poprawności drzewa dostępności, walidacji WebMCP (czyli sprawdzenia, czy strona informuje agentów, co potrafi zrobić), zgodności pliku llms.txt z zaleceniami oraz wykrywania przesunięć układu. Ten ostatni to znany z audytów prędkości wskaźnik CLS — z tą różnicą, że dla agenta waży znacznie więcej niż dla człowieka, bo człowiek widzi, że przycisk się przesunął, i podąża za nim wzrokiem.
Etap drugi to odczyt drzewa dostępności, czyli wypisanie wszystkich akcji na stronie, których agent nie widzi albo nie potrafi nazwać. Etap trzeci to przegląd ośmiu znanych blokerów uniemożliwiających ukończenie zadania i zlokalizowanie ich w konkretnych szablonach.
Etap czwarty — realne przebiegi z agentem — jest sercem całego audytu, ponieważ jako jedyny produkuje dowody zamiast przypuszczeń. Daje wskaźnik ukończenia zadań i dokładny krok, na którym agent się poddał. Etap piąty to decyzja o WebMCP: czy ten protokół jest już wart Twojego czasu, czy może poczekać. Etap szósty zamyka pracę scoringiem i listą poprawek uporządkowaną według liczby szablonów, które każda zmiana naprawia.
Jak czytać wyniki i ustalić priorytety
Liczby z benchmarków warto traktować jako sufit, a nie średnią. Testy prowadzono na popularnych, mocno używanych serwisach, które i tak miały spory zasób dobrych praktyk technicznych. Jedynym sposobem sprawdzenia, gdzie w tym rozkładzie znajduje się Twoja witryna, jest przeprowadzenie czwartego etapu na własnych zadaniach.
Kolejność napraw ustalasz według zasięgu, a nie według dramatyzmu błędu. Nieopisany przycisk ikonowy w globalnym nagłówku to najczęstsza pojedyncza usterka i jednocześnie najbardziej opłacalna — cztery linie HTML naprawiają ją na wszystkich podstronach naraz. Poprawka w jednym niszowym formularzu odblokuje jedną ścieżkę; poprawka w komponencie nawigacji odblokuje ich kilkadziesiąt.
Raporty warto archiwizować. Kategoria Agentic Browsing wciąż się zmienia, więc wynik zaliczony dzisiaj nie musi być zaliczony za trzy miesiące. Sam audyt nie wymaga programisty, ale zdecydowana większość poprawek już tak — dlatego lista naprawcza powinna trafiać do zespołu deweloperskiego w formie gotowej do wdrożenia, z konkretnym szablonem i selektorem przy każdej pozycji.
Podsumowanie
Widoczność w odpowiedziach AI wprowadza Cię do rozmowy, ale to gotowość na agentów decyduje o tym, czy użytkownik dokończy zadanie i zostawi u Ciebie pieniądze. Benchmarki pokazują, że większość agentów radzi sobie dziś w okolicach 30–60% skuteczności, a lwia część przyczyn leży w kodzie, który możesz zmienić. Sześcioetapowy audyt zamienia to ryzyko w mierzalną listę poprawek — najczęściej krótszą, niż się wydaje.
Źródło: Orit Mutznik, „Can AI Agents Complete Tasks on Your Site? My Agentic Search Readiness Audit Framework” — oritmutznik.com
