Как подготовить сайт к ИИ-агентам: формы, поиск и действия без ручных кликов

Представим обычную задачу.

Пользователь говорит ИИ-агенту: «Найди на сайте подходящую услугу, заполни форму моими данными и подготовь заявку».

Для человека сценарий кажется элементарным: открыть меню, перейти в услуги, выбрать направление, заполнить имя и телефон, нажать кнопку.

Для browser agent это цепочка решений. Где здесь основная навигация? Какая карточка действительно ведёт на услугу? Поле с иконкой телефона — это телефон или произвольный текст? Кнопка «Далее» отправит форму или откроет следующий шаг? Появилась ошибка или заявка уже принята?

Именно на таких сценариях становится видно, насколько сайт действительно понятен машине.

Google сейчас прямо указывает, что browser agents могут анализировать визуальный рендер страницы, структуру DOM и accessibility tree. То есть агент способен сопоставлять то, как интерфейс выглядит, с тем, как он представлен в HTML и браузерной модели доступности.

Поэтому подготовка сайта к ИИ-агентам начинается не с специального «AI-файла» и не с нового SEO-тега. В первую очередь это нормальный HTML, доступные элементы управления, предсказуемые состояния интерфейса и чёткая обратная связь после действия.

Как ИИ-агент понимает страницу

Современный browser agent может использовать сразу несколько источников информации.

Визуальный слой помогает понять расположение элементов: где находится меню, какие элементы сгруппированы вместе, какая кнопка визуально является основной.

DOM показывает структуру документа и отношения между элементами.

Accessibility tree даёт более компактное представление интерфейса: роли элементов, их доступные имена, состояния и отношения. Chrome отдельно отмечает, что agentic-аудиты Lighthouse используют accessibility tree для проверки элементов, важных для машинного взаимодействия.

Это объясняет, почему визуально красивый интерфейс иногда оказывается трудным для автоматического взаимодействия.

Например, дизайнер видит синюю плашку с текстом «Получить расчёт» и понимает, что это кнопка. Но если разработчик сделал её как:

<div class="blue-cta" onclick="openForm()">Получить расчёт</div>

то смысл действия приходится дополнительно угадывать.

Гораздо яснее:

<button type="button" aria-controls="request-dialog">
    Получить расчёт
</button>

У второго варианта сама структура сообщает, что перед нами интерактивная кнопка.

Навигация должна описывать действие, а не только выглядеть как навигация

Хорошая навигация для агента мало отличается от хорошей навигации для человека.

Ссылки должны быть ссылками. Кнопки должны быть кнопками. Тексты элементов должны объяснять, куда они ведут или что выполняют.

Если вся карточка услуги кликабельна через JavaScript, но внутри нет нормальной ссылки на страницу услуги, агент получает менее определённую конструкцию, чем при обычном <a href>.

Проблемы создают и слишком абстрактные подписи.

«Подробнее», «сюда», «открыть» или одна стрелка без доступного имени требуют контекста. «Подробнее о SEO-продвижении» или ссылка, доступное имя которой содержит название услуги, намного понятнее.

web.dev рекомендует для agent-friendly интерфейсов использовать семантический HTML и отдавать предпочтение <button> и <a> перед стилизованными div и span.

Самое важное место — формы

Форма заявки — хороший тест всего интерфейса.

Человек способен догадаться, что поле с placeholder +7 (...) предназначено для телефона. Машине лучше не оставлять такую задачу на догадку.

Поле должно иметь настоящее имя и программно связанную подпись:

<label for="client-phone">Телефон</label>
<input
    id="client-phone"
    name="phone"
    type="tel"
    autocomplete="tel"
    required
>

W3C рекомендует явно связывать <label> с элементом формы через for и id. Такая связь позволяет браузеру и assistive technologies однозначно определить назначение поля.

Placeholder не должен заменять label.

После ввода текста placeholder исчезает. Кроме того, он не создаёт такую же надёжную смысловую связь между названием поля и самим control.

Для формы заявки особенно полезно проверить:

• есть ли у каждого поля понятный label;
• используются ли соответствующие типы email, tel, date;
• имеют ли поля стабильные name;
• отмечены ли обязательные поля через required;
• понятно ли, какие форматы данных разрешены;
• является ли отправка настоящим button type="submit";
• отображаются ли ошибки рядом с нужным полем;
• можно ли понять, что отправка действительно завершена.

Это полезно не только AI agents. Это базовое качество формы.

Ошибка должна быть состоянием, а не просто красной строкой

Допустим, агент заполнил форму и нажал «Отправить».

Сервер вернул ошибку: телефон введён в неправильном формате.

Если под полем просто появился красный текст без связи с input, визуально человек его заметит, но структурно состояние формы изменилось неочевидно.

W3C рекомендует делать сообщения об ошибках конкретными, связывать их с соответствующими полями и при динамическом появлении уведомлений обеспечивать их программную доступность. Для AJAX-форм, например, может применяться role="alert", а сообщение конкретного поля можно связать через aria-describedby.

То же относится к успешной отправке.

После нажатия кнопки агент должен получить однозначное новое состояние:

заявка отправлена,
требуется исправить поле,
необходимо подтвердить телефон,
нужно авторизоваться.

Просто убрать форму через JavaScript и показать анимацию галочки — красивое, но слабое описание результата.

Поиск и фильтры не должны быть загадкой

Поиск часто усложняют ради дизайна.

Поле появляется только после клика по маленькой иконке, результаты загружаются AJAX-запросом, фильтр открывается нестандартным блоком, выбранное состояние видно только цветом.

Для агента гораздо надёжнее, когда поле поиска имеет собственный label или доступное имя, кнопка понятно обозначена, а выбранные фильтры отражены в DOM и accessibility state.

Если используется custom combobox, autocomplete или dropdown, состояния вроде aria-expanded, связь с popup и текущий выбранный элемент должны соответствовать фактическому интерфейсу. Такие отношения описаны в WAI-ARIA Authoring Practices.

Не обязательно превращать каждый AJAX-фильтр в классическую форму с перезагрузкой страницы. Нужно сделать его состояние наблюдаемым и предсказуемым.

Динамические модальные окна — частая точка отказа

Форма обратного звонка часто открывается в modal.

Визуально всё выглядит правильно: фон затемнился, форма находится по центру.

Но в DOM фокус может оставаться на кнопке под модальным окном, фон продолжает быть интерактивным, у dialog нет доступного имени, а крестик закрытия существует только как SVG.

Для хорошо реализованного modal браузер должен понимать, что появилось отдельное диалоговое состояние.

W3C рекомендует при открытии modal переносить focus внутрь, удерживать последовательность фокуса в диалоге и возвращать её после закрытия. Для диалога используются соответствующие семантические роли и доступное имя; нативный HTML <dialog> также может взять часть поведения на себя.

Для browser agent такая предсказуемость особенно полезна: после открытия формы его следующая рабочая область становится очевидной.

Стабильность интерфейса тоже имеет значение

Агент может определить кнопку по структуре, accessibility tree или визуальному положению. Если интерфейс постоянно перестраивается, вероятность неверного действия возрастает.

Примеры: после загрузки баннера CTA уехала вниз; карточки поменяли порядок; popup появился поверх элемента; кнопка переместилась между моментом анализа страницы и кликом.

В руководстве web.dev стабильный layout прямо указан среди рекомендаций по подготовке сайтов к browser agents. Agentic Browsing в Lighthouse также учитывает визуальную стабильность.

Это ещё одна причина воспринимать CLS не только как формальную метрику Core Web Vitals.

Authentication нельзя «упрощать для робота»

Если действие требует авторизации, агент не должен получать обходной путь только потому, что он агент.

Права пользователя, серверная авторизация, CSRF-защита и контроль доступа остаются обязательными.

При этом сама форма входа должна работать с нормальными механизмами браузера. W3C, например, указывает, что login forms должны позволять user agents и password managers правильно распознавать и заполнять поля; искусственная блокировка автозаполнения или вставки способна создавать проблемы доступности.

Особенно осторожно нужно относиться к необратимым действиям: оплате, удалению данных, публикации, отправке заказа.

Агент может подготовить действие, но финальное подтверждение чувствительной операции во многих сценариях должно оставаться у пользователя.

Что уже полезно делать сейчас

Практически весь базовый слой agent-friendly сайта состоит из давно известных web-practices.

Семантический HTML уже работает.

Корректные label уже работают.

Accessibility tree существует в сегодняшних браузерах.

Стабильный layout уже важен.

Доступные формы, поиск, меню, dialog, ошибки и статусы уже улучшают работу людей, screen readers, автоматизированных тестов и browser agents.

Google Search Central также не предлагает отдельного «SEO для агентов». В руководстве по generative AI Google продолжает рекомендовать фундаментальную техническую структуру, semantic HTML и нормальный пользовательский опыт, а рекомендации по agent-friendly websites приводит как отдельное направление развития интерфейсов.

Поэтому исправлять плохой HTML имеет смысл уже сейчас, даже если с сайта сегодня не приходит ни одного действия от AI-agent.

Что пока остаётся экспериментальным: WebMCP

WebMCP решает другую задачу.

Вместо того чтобы заставлять агента угадывать действие по интерфейсу, сайт может явно предоставить структурированный tool.

Например, агенту не обязательно самостоятельно искать поля формы записи, выбирать дату и нажимать несколько кнопок. Сайт может предоставить действие условного типа book_appointment с определёнными параметрами.

Chrome описывает WebMCP как proposed web standard. На октябрь 2026 года технология остаётся экспериментальной и тестируется через origin trial; документация Chrome отдельно подчёркивает возможность изменения API.

Для обычной HTML-формы предусмотрен Declarative API: дополнительные атрибуты позволяют описать форму как WebMCP tool. Chrome также развивает Imperative API для действий, которые удобнее описывать JavaScript-функциями.

Принцип можно представить так:

<form
    toolname="request_service"
    tooldescription="Creates a request for a selected service"
>
    ...
</form>

Но важнее другое: WebMCP — progressive enhancement, а не замена нормальному HTML.

Если базовая форма плохо работает, нет смысла сначала маскировать проблему новым протоколом.

WebMCP не является новым обязательным фактором SEO

Это разделение особенно важно для SEO.

Google Search Central не говорит, что WebMCP необходим для индексации, ранжирования или присутствия в AI Overviews и других generative AI features.

Более того, Google отдельно предостерегает от попыток искать специальные «AI SEO hacks» и рекомендует сохранять фундаментальные SEO-practices.

WebMCP сейчас нужно рассматривать прежде всего как технологию взаимодействия browser agent с функциями сайта.

Agent-friendly UX и поисковая оптимизация могут пересекаться через качество HTML, скорость и техническую структуру, но это не делает WebMCP самостоятельным фактором ранжирования.

А что с WordPress

У WordPress уже развивается собственное направление agentic-интеграций.

Abilities API позволяет плагинам регистрировать типизированные доступные действия, а официальный MCP Adapter способен предоставлять такие abilities MCP-клиентам как инструменты. WordPress Developer Blog рассматривает эту архитектуру как основу для AI automation.

Но WordPress MCP Adapter и WebMCP — не одно и то же.

MCP Adapter относится к предоставлению возможностей WordPress внешним MCP-клиентам.

WebMCP Chrome относится к browser agents, взаимодействующим с функциональностью открытой веб-страницы.

Поэтому установка MCP-компонента сама по себе не исправит форму темы, где отсутствуют label, и не превратит JavaScript-кнопку из div в хороший интерактивный control.

Для типичного WordPress-сайта правильная последовательность сейчас выглядит так: сначала тема, шаблоны и плагины должны выдавать качественный HTML и доступный интерфейс. Затем можно экспериментировать с дополнительными agentic APIs там, где есть реальный сценарий автоматизации.

Как проверить собственный сайт

Начинать стоит не с вопроса «есть ли у меня WebMCP?», а с простой задачи.

Откройте страницу услуги и представьте, что у агента есть цель: найти нужную услугу, открыть форму, указать имя и телефон и подготовить отправку.

Можно ли пройти этот маршрут, понимая назначение каждого элемента только из HTML и accessibility tree?

Понятно ли, какая кнопка открывает форму?

Есть ли у формы название?

Каждое ли поле имеет label?

Ясно ли, что поле обязательное?

Можно ли пользоваться интерфейсом клавиатурой?

Меняется ли состояние expanded, selected, disabled там, где это необходимо?

Получает ли пользователь понятное сообщение после AJAX-действия?

Возвращается ли focus после закрытия modal?

Если на этих шагах появляются проблемы, именно их стоит исправлять первыми.

Для отдельной технической проверки можно использовать и Agentic Browsing в Lighthouse, который я уже разбирал в материале про агентный просмотр в PageSpeed Insights. Он помогает проверить accessibility-related сигналы, стабильность и экспериментальные WebMCP-интеграции, но сам по себе не заменяет тестирование реального пользовательского сценария.

Главное: не делайте отдельный сайт «для AI»

Самая перспективная стратегия сейчас довольно консервативна.

Не нужно создавать вторую версию сайта специально для агента.

Не нужно заменять интерфейс JSON-представлением.

Не нужно добавлять экспериментальный API в каждую кнопку.

Нужно сделать так, чтобы существующий интерфейс хорошо объяснял сам себя.

Для человека кнопка должна выглядеть и вести себя как кнопка.

Для браузера она должна быть кнопкой.

Для accessibility tree у неё должно быть корректное имя и состояние.

Для server-side логики действие должно проходить ту же валидацию и проверку прав.

И только если сценарий действительно выигрывает от структурированного вызова, поверх этого можно добавить WebMCP.

В таком подходе практически нет ставки на конкретного AI-провайдера или краткосрочный тренд. Даже если сегодняшние browser agents через несколько лет будут работать иначе, качественный semantic HTML, доступные формы, стабильная навигация и понятные состояния интерфейса останутся полезны.