Lipcowy test przeprowadzony w 200 amsterdamskich restauracjach wykazał, że obecne asystenci AI nie potrafią dokończyć rezerwacji stolika, ponieważ widget rezerwacyjny jest ukryty wewnątrz ramki iframe.

Dlaczego iframe blokuje agentów

Większość narzędzi do rezerwacji online jest dostarczana w formie osadzonego iframe. Odwiedzający klika przycisk „Rezerwuj”, pojawia się kalendarz, a użytkownik wybiera przedział czasowy. Dla człowieka proces ten działa; dla agenta AI staje w miejscu.

  • Agent analizuje główną stronę HTML.
  • Przycisk rezerwacji wskazuje na adres URL w innej domenie.
  • Przeglądarka ładuje ten adres URL wewnątrz iframe, izolując go od strony nadrzędnej.

Ponieważ polityka tego samego pochodzenia (same-origin policy) blokuje skryptom na stronie nadrzędnej możliwość odczytywania DOM ramki iframe lub przechwytywania jej wywołań sieciowych, agent AI, który czyta zawartość strony i wysyła żądania HTTP, widzi jedynie przycisk. Nigdy nie widzi kalendarza, przedziałów czasowych ani procesu potwierdzania. Nawet jeśli kliknie przycisk, wciąż musi rozwiązywać captche, dostosowywać się do zmian układu lub omijać mechanizmy obronne przed automatyzacją, które stosuje wiele serwisów rezerwacyjnych.

Osobny audyt 163 działających stron restauracji wykazał, że tylko dziewięć z nich udostępniało jakiekolwiek dane rezerwacyjne czytelne dla maszyn. Te dziewięć stron wymieniało podstawowe informacje — nazwę i adres — używając znaczników schema.org, ale żadna nie zawierała akcji rezerwacji, które agent mógłby wywołać. Schema.org definiuje w tym celu typy takie jak ReserveAction, jednak większość stron publikuje jedynie metadane opisowe, a nie instrukcje umożliwiające podjęcie działań.

W praktyce asystent szuka danych ustrukturyzowanych, które mówią mu, jak wykonać zadanie, a nie tylko, czym jest to zadanie. Bez ReserveAction lub porównywalnego punktu końcowego (endpoint), agent musi polegać na naśladowaniu kliknięcia człowieka, co — jak opisano powyżej — jest zawodne.

Praktyczne rozwiązanie, które nie wymaga przebudowy UI

  1. Opublikuj API rezerwacyjne – Stwórz lekki punkt końcowy HTTP, który przyjmuje żądania JSON w celu zapytania o dostępność i utworzenia rezerwacji. API zwraca pola takie jak data, godzina, liczba osób i kod potwierdzenia. Każdy agent może z niego korzystać bez konieczności renderowania strony.
  2. Umożliw odkrywalność API – Umieść wskaźnik w dobrze znanym miejscu, np. /.well-known/booking, lub osadź wpis ReserveAction w znacznikach schema.org strony. Informuje to agentów, że „istnieje programowy sposób na dokonanie rezerwacji”, bez konieczności stosowania scrapingu.
  3. Przyjmij Model Context Protocol (MCP) – MCP pozwala asystentom bezpośrednio wywoływać zewnętrzne narzędzia, przekazując dane wejściowe i otrzymując ustrukturyzowane wyniki. Główni dostawcy AI wspierają już MCP, więc restauracja, która wdroży punkt końcowy zgodny z MCP, może być wywoływana przez agentów tak, jakby była wbudowaną funkcją.

Te kroki pozwalają zachować wizualny iframe dla użytkowników-ludzi, jednocześnie zapewniając agentom czystą i niezawodną ścieżkę do tych samych danych rezerwacyjnych.

Podsumowanie

Osadzenie kalendarza wewnątrz iframe chroni wizualny przepływ dla ludzi, ale pozostawia asystentów AI „ślepych”. Dodanie skromnego, dobrze udokumentowanego API rezerwacyjnego i promowanie go poprzez standardowe metadane lub MCP otwiera nowy kanał rezerwacji bez konieczności przebudowy strony internetowej. Ten wysiłek zwiększa widoczność dla nowej generacji asystentów cyfrowych, a ryzyko można kontrolować za pomocą tych samych mechanizmów bezpieczeństwa, które są już stosowane w obecnym interfejsie użytkownika (UI).