Тест 200 амстердамських ресторанів, проведений у липні, показав, що сучасні ШІ-асистенти не можуть завершити бронювання столика, оскільки віджет бронювання прихований всередині iframe.

Чому iframe блокує агентів

Більшість інструментів онлайн-бронювання постачаються у вигляді вбудованого iframe. Відвідувач натискає кнопку «Забронювати», з'являється календар, і користувач обирає часовий слот. Для людини цей процес працює, але для ШІ-агента він зупиняється.

  • Агент аналізує основну HTML-сторінку.
  • Кнопка бронювання веде на URL-адресу на іншому домені.
  • Браузер завантажує цей URL всередині iframe, ізолюючи його від батьківської сторінки.

Оскільки політика одного джерела (same-origin policy) забороняє скриптам на батьківській сторінці читати DOM iframe або перехоплювати його мережеві виклики, ШІ-агент, який зчитує вміст сторінки та надсилає HTTP-запити, бачить лише кнопку. Він ніколи не бачить календаря, часових слотів або процесу підтвердження. Навіть якщо він натисне кнопку, йому все одно доведеться розв'язувати капчі, адаптуватися до змін макета або обходити засоби захисту від автоматизації, які використовує багато сервісів бронювання.

Відсутність машиночитаного зв'язку

Окремий аудит 163 функціональних сайтів ресторанів виявив лише дев'ять ресурсів, які надавали будь-які машиночитані дані для бронювання. Ці дев'ять сайтів наводили базову інформацію — назву та адресу — за допомогою розмітки schema.org, але жоден не містив дій із бронювання, які міг би виконати агент. Schema.org визначає такі типи, як ReserveAction, саме для цієї мети, проте більшість сайтів публікують лише описові метадані, а не інструкції для виконання дій.

На практиці асистент шукає структуровані дані, які підказують йому, як виконати завдання, а не лише що це за завдання. Без ReserveAction або аналогічної кінцевої точки (endpoint) агент змушений імітувати клік людини, що, як було описано вище, є ненадійним.

Практичне рішення, яке не потребує переробки інтерфейсу

  1. Опублікуйте API для бронювання – Створіть легку HTTP-кінцеву точку, яка приймає JSON-запити для перевірки доступності та створення бронювання. API повертає такі поля, як дата, час, кількість осіб та код підтвердження. Будь-який агент може використовувати його без рендерингу сторінки.
  2. Зробіть API доступним для виявлення – Розмістіть посилання у загальновідомому місці, наприклад /.well-known/booking, або вбудуйте запис ReserveAction у розмітку schema.org сторінки. Це повідомить агентам, що «тут є програмний спосіб бронювання», без необхідності веб-скрапінгу.
  3. Впровадьте Model Context Protocol (MCP) – MCP дозволяє асистентам безпосередньо викликати зовнішні інструменти, передаючи вхідні дані та отримуючи структуровані результати. Провідні постачальники ШІ вже підтримують MCP, тому ресторан, який реалізує сумісну з MCP кінцеву точку, може викликатися агентами так, ніби це вбудована функція.

Ці кроки дозволяють залишити візуальний iframe для людей, надаючи агентам чистий і надійний шлях до тих самих даних про бронювання.

Висновок

Вбудовування календаря в iframe захищає візуальний процес для людей, але робить ШІ-асистентів «сліпими». Додавання простого, добре задокументованого API для бронювання та його просування через стандартні метадані або MCP відкриває новий канал бронювання без необхідності переробляти вебсайт. Ці зусилля підвищують видимість для наступного покоління цифрових асистентів, а ризиками можна керувати за допомогою тих самих засобів безпеки, які вже використовуються в існуючому інтерфейсі.