Google UCP: ИИ нашёл ваш сайт, а сможет ли он на нём купить?

Рубрика: Теория и статистика | Время на чтение: 13 мин.

Универсальный коммерческий протокол (UCP) от Google — это первый производственный образец того, что в конечном итоге потребуется предоставлять каждому веб-сайту (будь то интернет-магазин или нет) агентам искусственного интеллекта: обнаруживаемые действия, предсказуемые результаты, постоянные сессии и явные политики для агентов.

UCP был выпущен как инфраструктура для розничных продавцов Google Merchant Center. Но более важная история — это архитектура, лежащая в его основе. Если вы хотите понять, как выглядят готовые к работе с агентами веб-сайты на практике, вам нужно обратиться к документации для разработчиков UCP.

Google UCP: ИИ нашёл ваш сайт, а сможет ли он на нём купить?

Оглавление

Что на самом деле создала Google

UCP — это открытый стандарт, представленный Google в январе 2026 года на конференции Национальной федерации розничной торговли (National Retail Federation) совместно с Shopify, Etsy, Wayfair, Target и Walmart, как общий язык между платформами искусственного интеллекта (Gemini, Google AI Mode) и бэкэндами продавцов. Согласно публикации Google «Под капотом» о UCP, протокол имеет четыре составляющие, на которые стоит обратить внимание.

Конечная точка обнаружения находится по адресу /.well-known/ucp. Агенты запрашивают URL-адрес /.well-known/ucp, чтобы узнать, что может делать веб-сайт продавца, какие товары он продаёт, какие действия он предоставляет и какие транспортные протоколы поддерживает. Этот манифест — это своего рода рукопожатие между агентом ИИ и бэкэндом продавца. Без этого манифеста агент не знает, что ему нужно анализировать или вызывать. В лучшем случае он попытается угадать.

Три REST-конечные точки для оформления заказа. UCP сводит всю транзакцию к трём вызовам: создание сессии, обновление сессии, завершение сессии. Вот и всё. Нет страницы корзины, нет формы адреса, нет экрана подтверждения. Состояние оформления заказа хранится в ответах сессии, а не в сгенерированном HTML. Человеческий слой вашего веб-сайта полностью игнорируется. Интерфейс будет существовать, но это будет не тот, который вы разработали. Почему в таком сценарии страницы сайта становятся необязательными, я разбирал отдельно.

Гибкость передачи данных. UCP поддерживает REST, привязки протокола контекста модели (MCP) и A2A (Agent-to-Agent), поэтому агенты, построенные на разных стеках, могут взаимодействовать с одним и тем же бэкэндом продавца без пользовательских адаптеров. Агент, работающий внутри Gemini, и агент, работающий на пользовательском MCP-клиенте, могут обращаться к одним и тем же конечным точкам UCP. Это было очень умное решение. Как агенты могут вызывать функции самого сайта, я разбирал в статье о WebMCP и его влиянии на SEO.

Открытая спецификация на ucp.dev. UCP опубликован как открытая спецификация, которую может реализовать любой веб-сайт, платформа ИИ или платформа продавца. Google не владеет протоколом и не управляет им. Открытость важна, потому что архитектура становится переносимой на любой веб-сайт за пределами Google Merchant Center, даже если путь регистрации Google этого не позволяет.

Google разрабатывает UCP в первую очередь для своей собственной экосистемы покупок. Дизайн UCP — это настоящий урок для всех остальных, и этот дизайн является классической реализацией принципа взаимодействия в архитектуре, ориентированной на машинное обучение.

Корзины покупок бросают примерно 70% людей (согласно многолетнему исследованию Baymard Institute о процессе оформления заказа). На сайтах без интерактивного слоя процент отказов от посещения, как правило, приближается к 100%.

UCP — это столп взаимодействия в производственной среде

Столп взаимодействия в архитектуре, ориентированной на машинное обучение, описывает, что должен предоставлять веб-сайт, чтобы ИИ-агент мог достичь на нём цели. Пять свойств: обнаруживаемые действия, предсказуемые результаты, непрерывность рабочего процесса, восстановление после ошибок и политики для агентов. UCP практически идеально соответствует каждому из них.

Обнаруживаемые действия. Столп взаимодействия гласит, что агентам необходим машиночитаемый индекс того, что им разрешено делать на странице, прежде чем они попытаются это сделать. Манифест возможностей UCP /.well-known/ucp — это в точности машиночитаемый индекс действий, запрашиваемый компонентом «Взаимодействие», поставляемый в качестве рабочей точки. Агент получает манифест, считывает список доступных операций и планирует свой следующий шаг. Никаких проб и ошибок, никакого парсинга DOM.

Предсказуемые результаты. В соответствии с принципом взаимодействия, каждое действие должно возвращать машиночитаемое состояние (вычисленные итоги, выделенный запас, флаги успеха), а не ответ 200 OK с HTML-квитанцией. Ответы сессий UCP содержат структурированные данные на каждом этапе: разбивку цен, распределение скидок и явное состояние сессии. Агент, читающий ответ UCP, точно знает, что только что произошло и что ему нужно сделать дальше.

Непрерывность рабочего процесса. В соответствии с принципом взаимодействия, агентам необходимы стабильные ссылки на сессии, которые сохраняются на протяжении многоэтапных рабочих процессов, чтобы они не теряли контекст в середине задачи. Сессии UCP имеют постоянные идентификаторы, и обновления PUT передают этот идентификатор дальше. Агент может добавить позицию, применить скидку, скорректировать доставку и завершить заказ в нескольких звонках без повторного создания состояния.

Восстановление после ошибок. В соответствии с принципом взаимодействия, сбои должны возвращать структурированные альтернативы, а не тупиковые ситуации. Когда код скидки UCP не срабатывает, ответ сессии объясняет причину и предлагает альтернативы, которые агент может попробовать. Человек может нажать «попробовать снова». Агенту необходима полезная нагрузка, которая указывает ему, что делать дальше.

Политика агентов. В рамках концепции взаимодействия веб-сайты должны указывать, что разрешено делать агентам, что требует подтверждения от человека, а что полностью запрещено. Декларации возможностей UCP представляют собой этот уровень политики: продавец указывает, какие действия агенты могут выполнять, при каких условиях и где требуется подтверждение от человека. Подписи запросов и токенизированные платежи обеспечивают соблюдение политики на уровне протокола.

Конечная точка Google /.well-known/ucp — это «доступность действий» в рамках концепции взаимодействия, используемая в качестве производственной инфраструктуры. Агенты запрашивают её, чтобы узнать, что может сделать веб-сайт, прежде чем пытаться это сделать. UCP требует три REST-конечные точки для оформления заказа: создание сессии, обновление и завершение. Таким образом, вся концепция взаимодействия сводится к трём вызовам API.

Пробел, который UCP выявляет для всех остальных

UCP — это ответ Google на пробел в трафике агентов внутри своей экосистемы Shopping. Этот пробел по-прежнему существует на каждом веб-сайте, не использующем UCP, хотя не все ритейлеры согласны с тем, где именно он находится.

Брианна Фаулер, руководитель глобальных программ потребительского дохода Dell, в интервью Digital Commerce 360 в апреле 2026 года заявила, что пока не заметила «ничего поведенчески последовательного» в трафике агентов, поступающем на Dell.com. Её внимание сосредоточено на поиске и доступности, а не на инфраструктуре, специфичной для агентов:

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

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

На веб-сайте, ориентированном на человека, доступность — это проблема пользовательского интерфейса. На веб-сайте, готовом для агентов, доступность — это проблема протокола. UCP существует потому, что Google решил, что рассмотрение доступности и оформления заказа как проблем протокола, а не проблем пользовательского интерфейса, — единственный способ масштабировать конверсию агентов.

Агент Gemini, совершающий покупки через продавца, поддерживающего UCP, не анализирует сетку товаров, не гадает, какие поля формы использовать, и не надеется, что ничего не отобразится повторно. Агент запрашивает /.wellknown/ucp, читает манифест возможностей и продвигает сессию через три конечные точки оформления заказа UCP. Остальная часть веб-пространства (каждая панель управления SaaS, каждый процесс формирования коммерческого предложения B2B, каждая система бронирования, каждый портал подписки) не имеет аналогичного протокола, который мог бы прийти ей на помощь.

Обобщённые исследования Baymard Institute показывают, что процент отказов от покупки человеком составляет 70,22% по результатам 50 исследований. Процент отказов от покупки агентами на веб-сайтах без слоя взаимодействия приближается к 100%, потому что люди колеблются на этапе оформления заказа, в то время как агенты даже не могут найти эту опцию.

Чему каждый сайт может научиться у архитектуры UCP

Вам не обязательно внедрять UCP. Возможно, вы даже не занимаетесь электронной коммерцией. Архитектура UCP, тем не менее, обобщается на пять принципов, которые должен реализовать любой веб-сайт, готовый к использованию агентов: манифест возможностей, структурированные действия, машиночитаемое состояние, постоянные сессии и явная политика для агента.

Опубликуйте манифест возможностей. Агентам необходимо знать, что может делать ваш веб-сайт, прежде чем они начнут работу. Этот манифест может представлять собой конечную точку /.well-known/, файл llms.txt, узел схемы веб-сайта с записями potentialAction или сервер MCP, перечисляющий доступные инструменты. Формат менее важен, чем само существование. Если агенту нечего запрашивать, ему приходится гадать, а гадание — это путь к снижению конверсии.
Предоставьте действия в виде структурированных данных. Schema.org поддерживает действия уже более десяти лет, включая BuyAction, OrderAction, ReserveAction, SubscribeAction и SearchAction. Практически ни один веб-сайт их не использует. Конечная точка POST /sessions в UCP фактически является целью BuyAction при наличии стабильного API-контракта, что и требовалось действиям Schema.org в течение десяти лет для реальной работы. Любой веб-сайт может сделать то же самое для своих собственных действий: объявить тип действия, назвать конечную точку, задокументировать полезную нагрузку. При этом стоит проверить, доступны ли структурированные данные ИИ-краулерам, особенно если они добавляются через JavaScript.
Возвращайте машиночитаемое состояние на каждом шаге. Каждый ответ агенту должен содержать структурированное состояние, которое агент может проанализировать: что произошло, что изменилось, что будет дальше. HTML-страницы подтверждения — это не машинное состояние. Перенаправление на /thank-you — это не машинное состояние. JSON с именованными полями и явными флагами — это машинное состояние. Возвращение состояния в формате JSON вместо HTML-страниц подтверждения — это самый значительный архитектурный сдвиг от проектирования, ориентированного на человека, к проектированию, готового к работе агента.
Проектируйте для сессий, а не для просмотров страниц. Агенты не перезапускаются, когда отвлекаются. Они возвращаются к текущему рабочему процессу и ожидают, что состояние останется прежним. Сессии со стабильными идентификаторами, обновлениями, которые можно безопасно повторить, и корректными путями возобновления не являются необязательными для агентов; это базовый уровень. Аналитика просмотров страниц приучила целое поколение продуктовых команд мыслить дискретными обращениями. Агенты же мыслят транзакциями.
Явно заявите о политике для агента. Политика агента определяет три вещи: что агенты могут делать без запроса человека, что требует подтверждения от человека и что полностью запрещено. UCP отвечает на эти вопросы с помощью деклараций возможностей. Ваш веб-сайт может ответить на них с помощью файла AGENTS.md, конечной точки политики /.well-known/ или структурированных аннотаций. Выберите один из вариантов. Опубликуйте его. Угадывание политики приводит к тому, что агенты в итоге совершают действия, которые их пользователи не предполагали.

Ни один из этих принципов не требует участия Google. Ни один из них не требует принятия UCP. Они требуют решения рассматривать веб-сайт как API-интерфейс для агентов в дополнение к экрану для людей.

Цитирование приводит к ответу, действия приводят к доходу

Большая часть сегодняшних обсуждений по-прежнему посвящена контенту: как попасть в цитируемые ответы ChatGPT, как занять высокие позиции в ответах ИИ Google, как стать источником цитат, которые ИИ выдаёт. Эта работа важна. Цитирование повышает осведомлённость, а осведомлённость — это вершина воронки продаж.

UCP демонстрирует компонент «Взаимодействие», который является второй половиной готового к работе агента веб-сайта, которую не охватывают AEO и GEO. Компонент «Взаимодействие» подразумевает совершение транзакций через агента ИИ, а не цитирование в его ответе. Разница между цитируемым веб-сайтом и веб-сайтом, с которым можно совершать транзакции, заключается в компоненте «Взаимодействие». Цитирование приводит к ответу ИИ. Действия, которые можно обнаружить, приводят к доходу от ИИ.

В подкасте Cheeky Pint Сундар Пичаи описал будущее, где пользователь ИИ одновременно запускает «множество потоков»: поиск, сравнение, бронирование, покупка — всё выполняется параллельно от имени одного человека. В этой модели побеждает тот веб-сайт, который позволит агенту быстрее всего завершить свой поток. Завершение означает выполнение действия, а не загрузку страницы. У Dell большой трафик, но поток проигрывает. Продавец, использующий UCP, завершает тот же поток за три вызова API.

UCP — это первый рабочий артефакт, который правильно реализует принцип взаимодействия. UCP не будет последним. Каждому веб-сайту, желающему участвовать в получении дохода через ИИ-агентов, в конечном итоге потребуется предоставить свою собственную версию той же архитектуры, используя открытый протокол, уровень возможностей schema.org, конечную точку WebMCP или собственный MCP-сервер. Спецификация может варьироваться, даже если принципы остаются неизменными.

UCP — это рабочая эталонная реализация принципа взаимодействия, разработанная Google и работающая сегодня в Google Shopping. Каждый другой веб-сайт по-прежнему должен найти свой собственный ответ. Брианна Фаулер из Dell сказала, что важна именно возможность обнаружения. Для агента возможность обнаружения — это протокол.