Dlaczego asystent AI klienta nie może wysłać formularza kontaktowego na Twojej stronie?

Formularz kontaktowy na stronie firmowej działa poprawnie dla człowieka, ale asystent AI klienta wysyła zapytanie w próżnię. Dzieje się tak, bo większość formularzy przesyła dane w tle przez AJAX lub fetch, a po wysłaniu nie przekazuje agentowi żadnej informacji zwrotnej o tym, co się stało. Efekt jest podwójnie niewidoczny: klient myśli, że zapytanie dotarło, a właściciel strony nie dostaje niczego i żadna statystyka tego nie sygnalizuje.

Klient wysłał, Ty nie dostałeś: skąd ta luka?

Wyobraź sobie taką sytuację. Kontrahent z innego miasta ma firmowego asystenta AI na telefonie. Pyta go: "wyślij zapytanie o wycenę do tej firmy". Asystent otwiera stronę, lokalizuje formularz kontaktowy, wypełnia pola: imię, firma, numer telefonu, treść zapytania. Klika "Wyślij". Asystent mówi użytkownikowi: "Gotowe, zapytanie wysłane".

Ty nie dostałeś nic.

Żadnego maila. Żadnego wpisu w CRM. Żadnego powiadomienia. Klient czeka na kontakt, bo jest absolutnie przekonany, że zapytanie dotarło. Przez kilka dni myśli, że masz dużo pracy. Po tygodniu pisze do kogoś innego.

To nie jest klasyczna awaria techniczna. Nikt nie zobaczył komunikatu o błędzie. Formularz po prostu nigdy nie powiedział agentowi, co się stało z danymi po kliknięciu przycisku.

Co się dzieje pod spodem, kiedy formularz wysyła dane w tle

Przez ostatnie lata webdesign poszedł w kierunku, gdzie kliknięcie "Wyślij" na formularzu nie przeładowuje strony. JavaScript przechwytuje kliknięcie zanim przeglądarka zdąży cokolwiek zrobić, sam wysyła dane do serwera w tle i wyświetla komunikat: "Dziękujemy, odezwiemy się wkrótce." Użytkownik widzi ten komunikat i zamyka kartę zadowolony.

Dla człowieka to działa perfekcyjnie. Szybko, bez brzydkiego przeładowania, z ładną animacją.

Dla agenta AI pracującego przez WebMCP to problem strukturalny. Agent obserwuje stronę i jej stan. Kliknął przycisk Wyślij. Strona nie przeładowała się. Strona nie wyrzuciła błędu. Ale agent nie dostał żadnej wiadomości: "dane dotarły do serwera", "wiadomość zapisana w bazie", "mail poszedł". JavaScript przechwycił zdarzenie formularza (addEventListener z event.preventDefault), wysłał dane przez fetch albo XMLHttpRequest, dostał odpowiedź serwera na swój wewnętrzny użytek i na tym skończył. Agent siedzi bez odpowiedzi.

W specyfikacji WebMCP jest na to konkretna odpowiedź: funkcja respondWith, która powinna być wywołana przez stronę po zakończeniu akcji, żeby poinformować agenta o wyniku. Jeśli strona tego nie robi, agent albo zaczeka chwilę i uzna akcję za nieudaną, albo błędnie założy sukces. Oba scenariusze kończą się tym samym: brakującym zapytaniem po Twojej stronie.

Większość wtyczek formularzy w WordPressie działa przez AJAX od lat. Contact Form 7, WPForms, Gravity Forms, Ninja Forms: żadna z nich nie obsługuje WebMCP, bo WebMCP jeszcze nie jest standardem. To specyfikacja w fazie testów, nie gotowy element przeglądarki, który każdy deweloper wtyczek miałby pod ręką.

Dlaczego właściciel nie widzi tego w statystykach

To jest ta część problemu, która sprawia, że najtrudniej go w ogóle wykryć.

Gdy człowiek trafi na zepsuty formularz, zazwyczaj dostaje komunikat o błędzie albo strona ładuje się wiecznie. Sfrustrowany pisze maila albo dzwoni. Zostawia ślad. Wiesz, że coś nie działa.

Gdy agent AI trafi na formularz bez respondWith, po prostu kończy próbę. Nie pisze w imieniu klienta maila z informacją, że coś nie przeszło. Nie zostawia zgłoszenia błędu w Twoim systemie analitycznym. Odwiedzina w Google Analytics jest zarejestrowana, ale jako sesja bez konwersji.

Twój dashboard pokazuje wtedy coś zupełnie normalnego: odwiedziny, czas na stronie, może nieco wyższy wskaźnik odrzuceń przy ruchu mobilnym. Żadnego sygnału "te zapytania były próbami od asystentów AI, które się nie powiodły". Żaden standardowy system analityki nie rozróżnia agenta AI od człowieka na tym poziomie szczegółowości.

Przez to problem może istnieć miesiącami zanim ktokolwiek go zauważy. Zazwyczaj dopiero wtedy, gdy klient zadzwoni i powie wprost: "mój asystent wysłał zapytanie, ale chyba coś nie doszło".

Czego WebMCP oczekuje od formularza: skrót bez kodu

WebMCP to specyfikacja przygotowywana przez Google i Microsoft w ramach W3C Community Group. Nie jest jeszcze standardem. Chrome testuje ją w fazie origin trial, Edge również, Safari nie zapowiedziało wsparcia. Koniec 2026 roku to planowany cel wejścia do stabilnej wersji Chrome, choć harmonogramy przy specyfikacjach webowych potrafią się przesuwać.

Idea leżąca u podstaw jest prosta. Strona deklaruje, co agent może na niej zrobić. Nie przez osobny plik konfiguracyjny gdzieś na serwerze, tylko przez atrybuty bezpośrednio w kodzie HTML formularza i poszczególnych pól. Atrybut toolname mówi, jak ta akcja się nazywa. Atrybut tooldescription tłumaczy, do czego służy. Atrybut toolparamdescription opisuje poszczególne pola.

Agent dostaje z przeglądarki listę akcji dostępnych na stronie. Nie musi zgadywać, że "input type=email" to pewnie adres do kontaktu. Strona mu to mówi wprost. Dzięki temu agent wypełnia formularz precyzyjnie, a nie metodą prób i błędów.

Po wykonaniu akcji strona powinna przez JavaScript poinformować agenta o wyniku: czy wysyłka się powiodła, jaki był ewentualny błąd, co wróciło z serwera. To właśnie respondWith. Bez niego agent działa jak pracownik, któremu wziął ktoś telefon z ręki w połowie potwierdzenia zamówienia.

Jeśli strona nie ma atrybutów WebMCP, przeglądarka je ignoruje i nic się nie psuje. To sprawia, że wdrożenie jest bezpieczne: można je zrobić na działającej stronie bez żadnego ryzyka dla dotychczasowych użytkowników.

MCP, czyli Model Context Protocol, to szerzej znany standard łączenia asystentów AI z programami i systemami, rozwijany teraz pod opieką Linux Foundation. WebMCP przenosi ten pomysł bezpośrednio na stronę HTML.

Dla programisty: na co patrzeć w kodzie formularza

Ta sekcja jest techniczna. Właściciel może przejść od razu do listy kontrolnej.

Przy przeglądzie formularza pod kątem WebMCP patrzę na cztery rzeczy:

• addEventListener('submit', ...) z event.preventDefault(): to punkt, gdzie standardowa wysyłka jest przerywana. Od tego miejsca agent traci wgląd w to, co dzieje się z danymi.
• fetch() lub XMLHttpRequest po preventDefault: dane idą do serwera, odpowiedź serwera trafia do JavaScript, ale nigdzie dalej. Jeśli fetch zwraca 200 OK, skrypt wie o tym, agent nie.
• Brak atrybutów toolname, tooldescription, toolparamdescription na formularzu i polach: formularz jest dla agenta anonimowy. Agent może go znaleźć po strukturze HTML, ale nie wie, do czego służy ani jakie pola są wymagane, co prowadzi do błędów wypełnienia.
• Brak navigator.modelContext.respondWith() po zakończeniu fetch: formularz wysłał dane, ale nigdy nie zamknął akcji od strony agenta. Agent czeka na odpowiedź, która nie nadejdzie.

Poprawka sprowadza się do: dodania atrybutów WebMCP do tagu form i tagów input, a po udanej odpowiedzi serwera wywołania respondWith z informacją o sukcesie lub komunikatem błędu. Przy wtyczkach WordPress najprościej dopisać obsługę respondWith przez własny skrypt nasłuchujący na zdarzenie emitowane przez wtyczkę po wysłaniu, np. document.addEventListener('wpcf7mailsent', ...) dla Contact Form 7. Schemat jest powtarzalny dla wszystkich popularnych wtyczek.

Warto też sprawdzić Content Security Policy strony: zbyt restrykcyjne CSP z ograniczeniem script-src może blokować wywołanie navigator.modelContext, zanim dotrze do respondWith.

Lista kontrolna: jak sprawdzić własną stronę bez programisty

Te kroki można przejść samemu w kilkanaście minut.

• Otwórz formularz kontaktowy i kliknij Wyślij z testowymi danymi. Jeśli strona się nie przeładowuje i pojawia się komunikat bez odświeżenia: formularz używa AJAX. To pierwszy sygnał, że wymaga dodatkowej pracy pod WebMCP.
• Sprawdź, jakiej wtyczki używasz (w panelu WordPress pod Plugins albo zapytaj programistę). Contact Form 7, WPForms, Gravity Forms, Ninja Forms: każda z nich używa AJAX i żadna nie obsługuje WebMCP samodzielnie.
• Otwórz stronę w Chrome, naciśnij F12, wybierz zakładkę Console. Wpisz navigator.modelContext i naciśnij Enter. Jeśli pojawi się undefined lub błąd: strona nie ma wdrożonego WebMCP. Jeśli pojawi się obiekt: WebMCP jest aktywne na tej stronie.
• Otwórz źródło strony (Ctrl+U) i wyszukaj frazę toolname. Brak wyników: formularz nie ma atrybutów WebMCP i agent nie dostaje od strony żadnych informacji o tym, jak go użyć.
• Zapytaj programistę jednym pytaniem: czy formularz wywołuje respondWith po wysłaniu danych? Odpowiedź Tak albo Nie. Jeśli programista nie wie, co to respondWith w kontekście WebMCP: wie teraz, że jest coś do sprawdzenia.
• Zrób test z agentem i sprawdź logi. Wyślij formularz ręcznie i sprawdź, czy wpis pojawił się w logach aplikacji lub bazie danych. Potem poproś kogoś o wysłanie przez asystenta AI w Chrome z włączonym WebMCP i porównaj. Jeśli ręczne wysłanie zostawiło ślad, a przez agenta nie: masz potwierdzony problem.

Od czego zacząć, jeśli chcesz to naprawić

Najpierw ocena skali. Jeżeli Twoi klienci nie korzystają jeszcze z asystentów AI, które operują na stronach, strata jest teraz mała. Ale WebMCP wchodzi do stabilnej wersji Chrome pod koniec 2026 roku i skala użycia wzrośnie. Formularz, który działa dla człowieka, a nie działa dla agenta, stanie się wtedy coraz bardziej odczuwalnym problemem.

Poprawka formularza to zazwyczaj jeden, góra dwa dni pracy dla programisty: dodanie atrybutów HTML do istniejącego formularza, napisanie kilkunastu linii kodu obsługujących respondWith i test na żywym formularzu przez agenta w Chrome. Dla standardowych wtyczek WordPress schemat jest powtarzalny, więc nie ma potrzeby wymyślać od zera przy każdym projekcie.

Jeżeli wolisz ocenić to razem z pełną listą zmian pod Twoją konkretną stronę, zajmujemy się wdrożeniem WebMCP dla firm: sprawdzamy formularz i inne akcje na stronie, dokumentujemy, co trzeba zmienić, i wdrażamy ze sprawdzeniem na prawdziwym agencie.

Jedna praktyczna rada: po naprawieniu formularza zrób test przez agenta AI, nie tylko przez przeglądarkę. Sprawdź w CRM albo w logach serwera, czy wpis się pojawił. "Kod się skompilował bez błędów" to za mało: "wpis jest w bazie po teście przez agenta" to pewność, że problem zniknął, a nie tylko zmienił postać.

Jeśli chcesz ocenić, czy Twój formularz ma ten problem i co konkretnie wymaga zmiany, 15 minut rozmowy o WebMCP wystarczy na pierwszą diagnozę. A jeśli wolisz zobaczyć, jak to wdrożenie wygląda u innych firm przed podjęciem decyzji, zajrzyj na realne wdrożenia.