Co agent AI w przeglądarce klienta widzi na Twojej stronie i jak ją przygotować?

Agent AI w przeglądarce klienta to program, który na jego polecenie samodzielnie klika po stronach i wypełnia formularze. Na typowej stronie firmowej staje w połowie drogi: brak etykiet pól, nieczytelne listy rozwijane i przyciski jako grafika wystarczą, żeby go zablokować. Czytelne formularze, opisy pól i dane strukturalne pomagają już dziś, a WebMCP, testowane teraz w Chrome i Edge, doda warstwę bezpośrednich opisów narzędzi bezpośrednio w HTML Waszej strony.

Co agent AI robi, gdy odwiedza Waszą stronę?

Pani Monika z działu zakupów mówi do swojego asystenta: "wyślij zapytanie ofertowe do dostawcy, typ produktu: uszczelka 44-B, potrzebna w piątek". Agent otwiera stronę w tle, szuka formularza i trafia na trzy ekrany. Pole "Typ produktu" to rozwijana lista z opcjami "Typ A", "Typ B", "Typ C" bez żadnych opisów. Pole "Termin" wymaga formatu RRRR-MM-DD, ale nigdzie tego nie mówi. Przycisk wysyłki to grafika ze strzałką bez tekstu. Agent nie wie, co gdzie wpisać, i odsyła Monice krótką informację: nie mogę dokończyć.

Agent działa jak niewidomy użytkownik z klawiaturą. Czyta HTML, szuka etykiet pól, tytułów sekcji, opisów przycisków. Nie ma dostępu do bazy danych ani backendu. Pracuje wyłącznie z tym, co przeglądarka renderuje na ekranie. Gdzie opis jest niejasny, staje. Gdzie brakuje etykiety, nie wie co wpisać. Gdzie przycisk to ikona CSS bez atrybutu alt i bez tekstu, nie ma jak go kliknąć.

To nie jest problem szczególnie skomplikowany. To dokładnie ten sam problem, który od lat ma czytnik ekranu dla niewidomych i crawler Google'a. Agent AI tylko bardziej go widać, bo klient natychmiast dostaje informację zwrotną: ta strona mnie blokuje.

Trzy miejsca, gdzie zwykła strona go zatrzymuje

Z audytów stron firmowych wynika, że agent napotyka problemy najczęściej w tych samych miejscach:

• Formularze bez etykiet w HTML. Pole "Imię" z samym placeholderem, który znika po kliknięciu, to pułapka. Agent widzi pustą ramkę i nie wie, co ma w niej wpisać. Jedyne, co mu pomaga, to tag label powiązany z polem atrybutem for albo atrybut aria-label bezpośrednio na elemencie input.
• Listy rozwijane z kodami zamiast opisów. Opcje "A1", "B2", "C3" albo "Typ A", "Typ B" nic nie mówią agentowi, który dostał polecenie "zamów uszczelkę do sprężarki". Nie ma jak dopasować polecenia do technicznego kodu. Nazwy opcji powinny opisywać wartość, nie tylko ją identyfikować.
• Przyciski bez tekstu. Strzałka CSS jako przycisk "Dalej", ikona kosza bez aria-label, obrazek z napisem "Wyślij" bez tekstu w HTML. Agent nie rozpoznaje ich jako przyciski akcji. Każdy przycisk powinien mieć czytelny tekst albo atrybut aria-label z opisem tego, co robi.

Do tego dochodzą dwa problemy poza samymi formularzami. Pierwszy: dane kontaktowe jako grafika. Numer telefonu wklejony jako plik PNG jest niemożliwy do odczytania przez agenta. Drugi: procesy wieloetapowe bez nagłówków kroków, gdzie agent nie wie, czy jest na początku, czy na końcu procesu, ani ile kroków zostało.

Co pomaga już dziś, bez żadnych nowych technologii

Zanim zajmiemy się WebMCP, jest cały zestaw poprawek, które można wdrożyć przy okazji najbliższej aktualizacji strony. Każda z nich poprawia czytelność dla agentów i przy okazji dla czytników ekranu, crawlerów Google i użytkowników na telefonach. To nie jest praca "tylko dla AI".

• Etykiety pól w HTML: każde pole input, select i textarea powinno mieć tag label powiązany atrybutem for, albo atrybut aria-label na samym polu. Placeholder jako jedyna forma opisu to za mało.
• Opisy opcji w listach rozwijanych: zamiast "Typ A / Typ B / Typ C" warto mieć "Uszczelka standardowa / Uszczelka wzmocniona / Uszczelka gumowa". Albo co najmniej atrybut title przy każdej opcji z opisem wartości.
• Format daty i liczb podany wprost: jeśli pole oczekuje formatu DD.MM.RRRR, napisz to w placeholder lub w elemencie opisanym przez aria-describedby. Jedno zdanie, które oszczędza błędów przy automatycznym wypełnianiu.
• Przyciski z tekstem: każdy przycisk musi mieć czytelny tekst w HTML albo atrybut aria-label z opisem akcji. Ikony bez opisu blokują agentów tak samo jak blokują użytkowników z czytnikami ekranu.
• Dane kontaktowe w zwykłym tekście: numer telefonu, adres e-mail i adres biura jako tekst w HTML możliwy do skopiowania, nie jako grafika.
• Nagłówki kroków w procesach: jeśli formularz zamówienia ma trzy etapy, każdy powinien mieć nagłówek z informacją o postępie, np. "Krok 2 z 3: Dane dostawy".
• Dane strukturalne Schema.org: dla sklepów Product i Offer, dla firm usługowych Organization i Service, ContactPoint. Agent wie wtedy bez czytania całej strony, że "249 zł" to cena konkretnego produktu, a nie liczba na plakacie.

Większość tych zmian nie wpływa na wygląd strony. Programista robi je zwykle w kilka godzin, jeśli kod formularzy jest porządny. Przy starszych stronach bez struktury czas się wydłuża, ale rzadko chodzi o przebudowę od zera.

Co dodaje WebMCP i czego bez niego brakuje

WebMCP to specyfikacja opracowywana przez grupę roboczą W3C (Community Group), za którą stoją Google i Microsoft. Nie jest jeszcze standardem. Chrome testuje ją w ramach origin trial, Edge też. Safari nie zapowiedział wsparcia. Przeglądarka bez WebMCP po prostu ignoruje opisy zdefiniowane przez tę technologię: strona działa normalnie, nic się nie psuje. Wdrożenie WebMCP nie grozi żadną regresją dla obecnych użytkowników.

Czysty HTML z dobrymi etykietami pozwala agentowi odgadnąć przeznaczenie pola. WebMCP pozwala stronie samej powiedzieć agentowi wprost, co to za narzędzie i jak je użyć. Zamiast domyślać się z kodu co robi ten formularz, agent dostaje gotowy opis: "to formularz zamówienia próbki, podaj kod referencyjny jako tekst, ilość sztuk jako liczbę całkowitą i preferowany termin dostawy w formacie daty".

Technicznie WebMCP opiera się na trzech atrybutach HTML dodawanych do formularzy: toolname (nazwa narzędzia, np. "zamow-probke"), tooldescription (opis, co ten formularz robi i kiedy agent powinien go użyć) i toolparamdescription (opis każdego pola: co wpisać, w jakim formacie, jakie wartości są możliwe). Do tego dochodzi API JavaScript navigator.modelContext, przez które strona może aktywnie komunikować się z agentem: przekazywać mu stan sesji, dostępność produktów albo aktualne dane z koszyka.

Warto tu odróżnić WebMCP od MCP (Model Context Protocol). MCP to otwarty standard łączenia asystentów AI z programami, rozwijany pod opieką Linux Foundation. Działa przez serwer MCP po stronie firmy. WebMCP działa po stronie przeglądarki klienta, bezpośrednio podczas wizyty na stronie. Nie trzeba mieć własnego serwera MCP, żeby skorzystać z WebMCP. To dwie różne warstwy, które mogą ze sobą współpracować.

Chrome planuje stabilną wersję WebMCP pod koniec 2026 roku. Do tego czasu wdrożenie działa tylko w przeglądarkach biorących udział w origin trial. Ale same atrybuty HTML dodane już teraz nie powodują żadnych błędów u nikogo innego.

Lista kontrolna: co sprawdzić na stronie przed rozmową o WebMCP

Te punkty możesz przejść z programistą albo z agencją odpowiedzialną za Waszą stronę. Pierwsze siedem to rzeczy do zrobienia teraz, niezależnie od WebMCP:

• Każde pole formularza ma etykietę label powiązaną z polem lub atrybut aria-label.
• Opcje w listach select opisują wartość, nie tylko kod techniczny.
• Pola z formatem (data, NIP, kod pocztowy, numer zamówienia) mają format podany w placeholder lub aria-describedby.
• Każdy przycisk ma czytelny tekst w HTML lub atrybut aria-label z opisem akcji.
• Numer telefonu, e-mail i adres firmy są w HTML jako zwykły tekst, nie jako obrazek.
• Procesy wieloetapowe mają nagłówki kroków z informacją o etapie, np. "Krok 1 z 3: Wybór produktu".
• Strona ma podstawowe dane strukturalne Schema.org odpowiednie dla swojego typu.
• Programista zna atrybuty WebMCP (toolname, tooldescription, toolparamdescription) i API navigator.modelContext.

Ostatni punkt to zadanie na koniec roku, kiedy Chrome wyda stabilną wersję. Pierwsze siedem punktów to zadanie na teraz.

Od czego zaczynamy w praktyce

Zaczynamy od audytu formularzy. Patrzymy na każdy formularz kontaktowy, zamówieniowy i rejestracyjny na stronie i sprawdzamy dwie rzeczy: czy etykiety są w HTML (nie tylko wizualne), i czy agent ma szansę zrozumieć, co wpisać w każde pole.

Typowo wygląda to tak, że strona wygląda czysto i działa bez zarzutu dla zwykłych użytkowników, ale pod spodem brakuje podstaw. U jednego klienta z branży B2B, sprzedającego materiały eksploatacyjne, formularz zapytania ofertowego miał 12 pól. Trzy nie miały etykiet w ogóle, tylko placeholder. Cztery miały opisy wyłącznie w tooltipach JavaScript, których agent nie odczytuje. Jeden przycisk "Dalej" był ikonką strzałki bez tekstu w HTML. Programista poprawił to w kilka godzin. Wygląd strony się nie zmienił, a agent przeszedł przez cały formularz bez problemu.

Potem sprawdzamy dane kontaktowe i Schema.org. Zwykle to kilka uzupełnień w szablonie. Na koniec planujemy atrybuty WebMCP dla formularzy, które mają sens do automatyzacji.

Jeśli zależy Wam na tym, żeby agenci klientów faktycznie mogli korzystać z Waszych formularzy i procesów, wdrożenie WebMCP dla firmy zaczyna się właśnie od takiego audytu, a potem dochodzą atrybuty i testy z prawdziwymi agentami w Chrome i Edge.

Agent AI w przeglądarce Waszego klienta to kolejny "użytkownik" Waszej strony. Tyle że działa bez rąk i bez intuicji. Dajcie mu etykiety, opisy i dane strukturalne, a sam poradzi sobie z większością zadań i nie przepadnie na pierwszym polu formularza kontaktowego.

Jeśli chcesz wiedzieć, gdzie Wasza strona stoi dziś i co konkretnie trzeba poprawić, umów się na 15 minut rozmowy o WebMCP. A jeśli wolisz najpierw zobaczyć, jak wygląda to u innych firm, zajrzyj do realnych wdrożeń.