Чому агент може зламатися на нормальній сторінці
Сторінка запису, покупки або заявки може виглядати нормально для людини й водночас бути поганою для ШІ-агента. Людина бачить контекст: візуальну групу, знайому іконку, порядок кроків, підказку біля поля. Агент частіше спирається на структуру сторінки, дерево доступності, стабільність розмітки й машиночитні сигнали. Якщо там хаос, він не «здогадається красиво», а натисне не те, пропустить поле або зупиниться.
Саме тому готовність сайту до ШІ-агентів починається не з магії ШІ. Вона починається з хорошого інтерфейсу: зрозумілих назв, передбачуваних форм, стабільного екрана й чесних повідомлень про помилки. Chrome for Developers описує це через нову категорію Lighthouse Agentic Browsing, покращення DevTools для агентів і перевірки WebMCP. Але головна думка ширша за Chrome: якщо сторінка зрозуміла для допоміжних технологій і тестів, вона зазвичай зрозуміліша й для агентів.
Різниця між «знайшов сторінку» і «виконав дію»
SEO допомагає сторінці бути знайденою. Для агента цього мало. Уявімо сценарій: треба записати користувача на консультацію. Агент відкриває сторінку, знаходить форму, вводить ім’я, телефон, дату, натискає кнопку й має отримати підтвердження. Проблема може з’явитися на будь-якому кроці.
Кнопка з іконкою календаря не має програмної назви. Поле «Ім’я» насправді підписане тільки візуальною підказкою. Після завантаження банера кнопка «Надіслати» зсувається вниз, і агент натискає сусідній елемент. Повідомлення про помилку з’являється кольором, але не пов’язане з полем. Для людини це дрібні незручності. Для агента це перешкоди в сценарії.
Тому перевірка має йти не від загального питання «чи сайт сучасний», а від конкретної дії. Якщо агент має зробити покупку, перевіряємо покупку. Якщо має створити заявку, перевіряємо заявку. Якщо має забронювати час, перевіряємо весь шлях до підтвердження.
Перша поверхня: дерево доступності
Дерево доступності показує, як сторінку бачать не очі, а інструменти. Lighthouse Agentic Browsing перевіряє частину доступності, важливу для машинної взаємодії. Особливо критичні інтерактивні елементи: кнопки, посилання, поля, перемикачі, повідомлення про помилки.
Практична перевірка проста. Відкрийте сценарій у DevTools і подивіться, чи кожна дія має зрозумілу програмну назву. Погано: три кнопки «Далі» без контексту на одному екрані. Краще: «Далі до вибору часу», «Далі до контактів», «Підтвердити запис». Погано: кнопка з іконкою кошика без назви. Краще: кнопка, яку інструменти читають як «Видалити товар з кошика».
Це не тільки про агентів. Такі самі виправлення допомагають людям, які користуються скрінрідерами, клавіатурою або автоматизованими тестами. Якщо команда каже «ми готуємо сайт до агентів», перший практичний крок часто звучить нудно: виправити HTML, ARIA й назви елементів. Саме це і треба зробити.
Друга поверхня: стабільність екрана
CLS важливий не лише для оцінки якості сторінки. Для агента зсув елемента може означати промах. Він вирішив натиснути «Підтвердити», але між розрахунком і натисканням підвантажився банер, список або рекламний блок. Координати змінилися, дія пішла не туди.
Перевіряйте стабільність не абстрактно, а в точках натискання. Чи рухається кнопка після появи валідації? Чи зсувається форма після підвантаження варіантів доставки? Чи не змінюється порядок елементів після автозаповнення? Якщо відповідь «так», це ризик для агента і для людини також.
Добра практика: зарезервувати місце під динамічні блоки, не вставляти важливі елементи над активною формою, показувати стан завантаження поруч із дією, а не поверх неї. Сценарій має залишатися передбачуваним навіть на повільному з’єднанні.
Третя поверхня: WebMCP і явні дії
WebMCP не треба сприймати як обов’язкову кнопку «тепер сайт готовий до ШІ». Це експериментальний напрям, який дозволяє описувати дії, форми й стан сторінки більш явно. Його варто розглядати там, де інтерфейс складний: багатокрокові форми, календарі, налаштування, заявки з великою кількістю полів.
Ідея корисна навіть без негайного впровадження. Команда може поставити питання: яку дію ми хочемо зробити зрозумілою для машини? Які поля має заповнити агент? Які помилки він має побачити? Який результат означає успіх? Якщо на ці питання немає коротких відповідей, проблема не в агенті. Проблема в нечіткому сценарії.
Мінімальний аудит для команди
Почніть з трьох дій, які мають найбільшу цінність: створити заявку, оплатити замовлення, записатися на зустріч. Для кожної дії запишіть кроки й очікуваний фінальний стан. Потім проганяйте сторінку через Lighthouse Agentic Browsing, перегляньте дерево доступності в DevTools і вручну пройдіть сценарій повільно, уявляючи, що ви бачите тільки назви елементів і стан сторінки.
Фіксуйте не «низький бал», а конкретні перешкоди: безіменна кнопка, поле без нормального підпису, повідомлення про помилку без зв’язку з полем, зсув кнопки, однакові тексти для різних дій. Після виправлень повторіть перевірку саме на тому самому сценарії. Інакше команда може покращити загальну сторінку, але не виправити дію, заради якої все починалося.
Типові помилки
Перша помилка — думати, що готовність до агентів дорівнює SEO. Агент може знайти сторінку й усе одно не виконати дію. Друга — додати WebMCP поверх поганої форми, не виправивши назви, помилки й стабільність. Третя — перевіряти тільки головну сторінку, хоча реальна цінність живе в оплаті, заявці або бронюванні.
Ще один ризик — тестувати тільки ідеальний сценарій. Агент має зрозуміти, що робити, коли телефон некоректний, дата зайнята, товар закінчився або сесія завершилась. Якщо людина може здогадатися, а агент ні, це не дрібниця. Це частина UX.
Що зробити завтра
Візьміть один сценарій, який приносить користь бізнесу або користувачу. Перевірте дерево доступності, CLS і назви інтерактивних елементів. Запишіть перешкоди простими задачами для фронтенду й QA. WebMCP залиште для місць, де справді потрібен явний машинний контракт.
Готовність до ШІ-агентів не вимагає одразу перебудовувати сайт. Вона вимагає прибрати неоднозначність там, де користувач або агент має зробити важливу дію. Це хороший критерій якості: якщо сценарій зрозумілий машині, він, найімовірніше, став зрозумілішим і для людини.
Джерела
- Chrome for Developers: A developer toolkit to make your website agent-ready — https://developer.chrome.com/blog/agent-ready-toolkit?hl=en
- Chrome for Developers: Join the WebMCP origin trial — https://developer.chrome.com/blog/ai-webmcp-origin-trial?hl=en
Короткий чеклист
- Обрати три найважливіші сценарії сайту й описати очікуваний результат для кожного.
- Перевірити, що кнопки, поля й повідомлення мають зрозумілі програмні назви.
- Прогнати Lighthouse Agentic Browsing і зафіксувати попередження як задачі, а не як декоративний бал.
- Перевірити CLS у місцях, де агент натискає кнопку або переходить до наступного кроку.
- Виписати типові помилки: іконки без назв, приховані кроки, нестабільні форми, кнопки з однаковим текстом.
- Вирішити, чи потрібен WebMCP для складних форм або дій, які агенту важко вгадати з інтерфейсу.
Prompt Pack: аудит ключового сценарію для ШІ-агента
Ти допомагаєш команді перевірити, чи ключовий сценарій сайту готовий до взаємодії з ШІ-агентом. Вхідні дані: - URL або опис сторінки. - Цільова дія користувача: запис, покупка, заявка, бронювання або інша дія. - Список основних кроків у сценарії. - Відомі проблеми: зміщення блоків, незрозумілі кнопки, нестабільні форми, помилки валідації. - Доступні інструменти: Lighthouse, DevTools, автоматизовані тести, перевірка доступності. Поверни результат у форматі: 1. Короткий висновок: чи може агент виконати дію надійно. 2. Карта сценарію: кроки, очікувані елементи, ризикові місця. 3. Перевірка дерева доступності: які кнопки, поля й повідомлення мають погані назви. 4. Перевірка стабільності: де можливий CLS або промах по елементу. 5. Перевірка WebMCP або схеми: чи є сенс додати машиночитний опис дії. 6. Перешкоди: що виправити перед публікацією. 7. Мінімальний набір повторних перевірок після виправлень.