Klient prosi ChatGPT albo Claude'a: „znajdź mi donicę 40 cm do 200 zł i dodaj do koszyka”. Agent otwiera Twój sklep i zgaduje, które pole jest wyszukiwarką.
Cena, dostępność i koszt wysyłki są tylko na obrazkach albo w skryptach, więc agent porównuje sklepy bez Twoich danych.
Firewall albo CAPTCHA blokuje agenta tak samo jak scraper, a klient dostaje odpowiedź „nie udało się otworzyć sklepu”.
Formularz kontaktowy ma etykiety niepowiązane z polami. Czytnik ekranu i agent widzą „pole tekstowe” bez nazwy.
Sześć obszarów, które decydują, czy agent dojdzie od pytania klienta do koszyka.
Formularz wyszukiwania i filtry kategorii dostają opis WebMCP, więc agent wywołuje „szukaj produktu” z parametrami zamiast klikać po stronie.
Dodanie do koszyka jako narzędzie, a płatność zostaje u klienta: agent przygotowuje zamówienie, człowiek je zatwierdza.
Product i Offer z ceną, walutą, dostępnością, GTIN, kosztem wysyłki i polityką zwrotów. To samo czytają Google i asystenci AI.
Feed do Google Merchant Center i drugi w formacie OpenAI (identyfikator, tytuł, opis, URL, marka, zdjęcie, dostępność, cena).
Etykiety powiązane z polami, nazwy przycisków, autouzupełnianie e-maila i telefonu. Z tego drzewa korzystają agenci i czytniki ekranu.
Reguły dla podpisanych agentów (ChatGPT agent podpisuje żądania standardem Web Bot Auth) i dla ChatGPT-User, Claude-User i Perplexity-User. Scrapery cen dalej blokujemy.
Bez WebMCP agent robi zrzut ekranu albo czyta drzewo dostępności i zgaduje, gdzie kliknąć, więc każda zmiana szablonu może go zgubić. Z WebMCP formularz sam się przedstawia: ma nazwę narzędzia, opis i parametry z opisami. Agent dostaje gotowy schemat, wypełnia go i dostaje odpowiedź ze sklepu, np. listę produktów albo potwierdzenie dodania do koszyka.
Wersja deklaratywna to kilka atrybutów HTML na istniejącym formularzu:
<form toolname="szukaj_produktu"
tooldescription="Szuka produktów w sklepie po nazwie i cenie"
toolautosubmit action="/szukaj">
<input name="q" toolparamdescription="Czego szuka klient">
<input name="max_cena" type="number" toolparamdescription="Cena maksymalna w zł">
</form>Wyszukiwanie i filtry wysyłają się automatycznie, a formularze z danymi klienta i checkout czekają na kliknięcie człowieka, bo tam agent działa w imieniu konkretnej osoby. Szczegóły są w dokumentacji Chrome o deklaratywnym API WebMCP.
Zanim zaproponowaliśmy to klientom, wdrożyliśmy WebMCP i poprawki dostępności na naszej stronie.
| Co mierzyliśmy | Przed → po |
|---|---|
| Drzewo dostępności (Lighthouse) | niezaliczone → zaliczone |
| Formularze opisane jako narzędzia WebMCP | 0 → 3 formularze, schemat poprawny |
| Ceny abonamentu w danych strukturalnych | brak → 3 oferty z ceną netto miesięcznie |
| Lighthouse Agentic Browsing | 6 z 6 audytów zaliczonych |
| Ochrona formularzy | honeypot i limit 5 zgłoszeń na 10 minut z jednego IP |
Lighthouse 13.5, kategoria Agentic Browsing, Chrome 154 z włączonym WebMCP.
W Polsce agent kupuje przez stronę sklepu, więc dziś najwięcej daje WebMCP, pełne dane produktu i firewall, który go wpuszcza, a feedy przygotowujemy w obu formatach, żeby dołączenie do programów zajęło dni, a nie miesiące.
Dajemy agentowi zadanie zakupowe w Twoim sklepie i zapisujemy, gdzie się gubi. Do tego Lighthouse Agentic Browsing na kluczowych stronach.
Formularze, dane produktu, feedy, firewall i robots.txt, od zmian, które odblokowują agenta, do tych, które go przyspieszają.
WebMCP na wyszukiwarce, filtrach, koszyku i formularzach, schema.org i feedy. Na kopii sklepu, potem na produkcji.
Ten sam test agentem i Lighthouse po zmianach. W GA4 oddzielamy wysyłki formularzy zrobione przez agenta.

Współpracowałam z Kamilem przy kodowaniu Landing Pages. Mogę polecić go z uwagi na jego otwartość, chęć rozwoju współpracy i wytrzymałość na moją perfekcję pikselową
Współpraca z ASAPDevs przebiega bardzo profesjonalnie. Zleciliśmy przeniesienie naszego sklepu internetowego na nową platformę i cały proces przebiegł bardzo sprawnie. Specjaliści bez problemu wdrażają wszystkie modyfikacje.