На днях я занимался совершенно обычным делом. Открыл сайт одного из наших клиентов и закинул его в PageSpeed Insights. Сколько раз в день я это делаю, даже не сосчитать; в нашей работе чтение отчёта о скорости настолько же рутинно, как утренний кофе. Я просматривал отчёт сверху вниз, и тут мой взгляд зацепился за одну строку: agentic browsing.
Сначала подумал, что это опечатка, потом проворчал про себя: «опять новая метрика вылезла». Но мне стало любопытно, и я кликнул. Этот единственный клик привёл меня на страницу WebMCP в документации разработчиков Chrome. И то, что я там прочитал, честно говоря, оказалось одним из самых тихих, но при этом крупнейших переломов, которые я видел за последние несколько лет.
Наша работа в Detartech заключается в том, чтобы сайты были видимы в поисковых системах, а теперь и в системах искусственного интеллекта, то есть SEO и GEO. Поэтому вопрос «как машины читают сайт» для меня не академический интерес, а вопрос прямого заработка. Прочитав про WebMCP, я понял, что вопрос теперь не просто в том, «как машины будут читать твой сайт». Настоящий вопрос звучит так: как машины будут использовать твой сайт?
Давай расскажу с самого начала. Потому что, стоит один раз уложить эту тему в голове, твой взгляд на веб меняется.
Три эпохи веба: человек кликает, бот сканирует, агент выполняет работу
Историю веба я бы условно разделил на три периода.
Первая эпоха была эпохой людей. Ты сам открывал сайт, сам читал, сам кликал, сам добавлял в корзину. Единственным клиентом дизайна был человек. Кнопки существовали для пальцев, тексты - для глаз.
Вторая эпоха стала эпохой ботов. Пришёл Googlebot, просканировал твою страницу, проиндексировал, отранжировал. Вся дисциплина, которую мы называем SEO, - дитя именно этой эпохи. Чтобы «роботы правильно читали мою страницу», мы писали robots.txt, создавали карту сайта, добавляли разметку schema.org. Боты читали, но ничего не делали. Они только понимали и составляли списки.
Сейчас стучится в дверь третья эпоха: эпоха агентов. ИИ-агенты больше не довольствуются просто чтением твоей страницы, они выполняют действия вместо тебя. Ищут авиабилеты, заполняют форму, записываются на приём, оформляют заказ в корзине. Они имитируют тот самый танец кликов и набора текста, который выполняет человек.
В документации Chrome этому процессу дано точное название: actuation (приведение в действие). Это когда агент, подражая человеку, имитирует клики мышью и набор текста с клавиатуры и выполняет работу на твоём сайте. Это может быть простая одношаговая задача вроде клика по ссылке, а может быть и сложная цепочка действий вроде оформления покупки от начала до конца.
Звучит здорово, не правда ли? Проблема в том, что этот метод крайне хрупкий. И настоящая история начинается именно здесь.
Главная проблема: агент бродит по твоему сайту вслепую
Подумай о том, как сегодня ИИ-агент выполняет работу на твоём сайте. Никаких дорожных знаков, которые ты оставил бы для машины, попросту нет. Агент видит экран, строит догадку вроде «эта кнопка похожа на 'Добавить в корзину'», кликает, интерпретирует результат, а затем снова гадает насчёт следующего шага.
Каждый шаг - интерпретация. Каждая интерпретация - азартная игра.
Ты вносишь на сайте небольшое изменение дизайна - переставляешь кнопку, меняешь надпись «Добавить в корзину» на «Купить сейчас», добавляешь один лишний шаг подтверждения, - и весь сценарий агента рушится. Человек-пользователь приспосабливается к таким изменениям за секунду; машина же теряется посреди целой цепочки догадок.
Я сравниваю это с приёмом гостя у себя дома. Старый способ - это как водить по комнатам гостя, которому ты не дал никакой схемы, приговаривая «кухня, наверное, где-то там». Чаще всего он находит её, но иногда принимает ванную за кухню.
И вот WebMCP появляется именно для того, чтобы положить конец этому слепому блужданию.
Что такое WebMCP?
WebMCP - это предложенный веб-стандарт, который позволяет сайтам определять структурированные инструменты (tools) для ИИ-агентов. Логика предельно чистая: вместо того чтобы ждать, пока агент угадает, для чего нужна твоя кнопка, сам сайт открыто заявляет: «эта функция вот такая, вызывается вот так, принимает вот такие входные данные».
То есть агент больше не смотрит на экран, размышляя «может, это поле - поле поиска?». Сайт прямо говорит ему: «У меня есть инструмент под названием поиск, если передашь ему такой-то текст, он выполнит поиск». Догадки заканчиваются, начинается контракт.
Согласно описанию Chrome, WebMCP делает возможными три вещи:
- Обнаружение (Discovery): страница представляет агенту имеющиеся у неё инструменты в стандартной форме. Например,
odeme_al,sonuclari_filtrele,randevu_olustur. - JSON-схемы: чёткое описание того, какие данные принимает и какие возвращает каждый инструмент. Это серьёзно снижает вероятность того, что модель начнёт «галлюцинировать» (выдумывать), потому что машина теперь точно знает, что от неё требуется.
- Состояние (State): текущий контекст страницы передаётся агенту, то есть агент в реальном времени знает, над какими ресурсами он может выполнять операции.
Для тех из нас, кто пришёл со стороны SEO, проведу такой мостик: когда мы добавляем структурированные данные через schema.org, мы, по сути, размечаем страницу тегами вроде «это товар, вот его цена, а вот отзыв», чтобы Google понял. WebMCP - это как бы следующая версия того же самого: ты размечаешь страницу, но на этот раз не для того, чтобы машина просто поняла, а для того, чтобы она выполнила действие. Вместо «пойми» - «сделай». Разница колоссальная.
Мне понравилась ещё одна вещь: инструменты WebMCP работают на твоей странице видимым образом. Когда агент вызывает инструмент, действие происходит в твоём интерфейсе, на глазах у пользователя. То есть твой бренд, твой дизайн, тот опыт, который ты создал для человека, остаются на месте; агент работает у тебя дома, по твоим правилам. Эта деталь показалась мне очень ценной, потому что альтернатива - это когда бренд полностью растворяется внутри интерфейса какого-то агента.
А теперь заглянем в код: два разных пути
Есть два способа добавить WebMCP на свой сайт. Покажу оба, потому что настоящая искра проскакивает именно тогда, когда видишь код.
1. Imperative API - определение инструмента с помощью JavaScript
В этом способе ты определяешь свой инструмент обычным JavaScript. Тебе нужны имя, описание и схема входных данных. Поскольку в голове у меня всегда примеры на основе моего собственного продукта sanalrandevu.com, воспользуюсь им - инструмент создания записи на приём может выглядеть так:
document.modelContext.registerTool({
name: 'randevu_olustur',
description: 'Seçilen hizmet, tarih ve müşteri için randevu oluşturur.',
inputSchema: {
type: 'object',
properties: {
hizmet: { type: 'string', enum: ['sac-kesimi', 'sakal', 'boya'] },
tarih: { type: 'string', description: 'YYYY-AA-GG biçiminde randevu tarihi' },
adSoyad: { type: 'string' }
},
required: ['hizmet', 'tarih', 'adSoyad']
},
execute: async ({ hizmet, tarih, adSoyad }) => {
const sonuc = await randevuKaydet({ hizmet, tarih, adSoyad });
return `Randevu oluşturuldu: ${adSoyad} - ${hizmet} - ${tarih}`;
}
});
Происходит вот что: с помощью registerTool ты даёшь инструменту идентификатор. description помогает агенту понять, для чего нужен этот инструмент; inputSchema сообщает, какие поля обязательны (например, что поле hizmet принимает только определённые значения); а execute определяет, что на самом деле происходит при вызове инструмента. Когда агент получает задачу «запиши этого человека на стрижку на завтра», он больше не ищет кнопку на экране - он напрямую вызывает этот контракт.
Обрати внимание: navigator.modelContext, который использовался в предыдущих версиях, начиная с Chrome 150 признан устаревшим; правильный способ - через document.modelContext. Если начинаешь с нуля, сразу заходи в правильную дверь.
2. Declarative API - превращение обычной HTML-формы в инструмент
Вот этот способ заставил моё SEO-сердце забиться чаще. Здесь, не написав ни строчки JavaScript, ты добавляешь к уже существующей HTML-форме несколько атрибутов и превращаешь её в инструмент, который может вызвать агент:
<form toolname="iletisimGonder"
tooldescription="Ziyaretçinin iletişim formunu gönderir."
action="/iletisim">
<label for="ad">Ad Soyad</label>
<input type="text" name="ad">
<label for="eposta">E-posta</label>
<input type="email" name="eposta">
<label for="mesaj">Mesajınız</label>
<textarea name="mesaj"></textarea>
<button type="submit">Gönder</button>
</form>
Как только ты добавляешь атрибуты toolname и tooldescription, браузер начинает интерпретировать эту форму как структурированный инструмент; поля формы становятся параметрами инструмента. Когда агент вызывает инструмент, браузер фокусируется на форме и заполняет поля - при этом форма остаётся видимой пользователю. При желании можно автоматизировать отправку с помощью toolautosubmit, а можно оставить подтверждение на усмотрение пользователя.
Глядя на это, первое, что пришло мне в голову: это же schema.org для действий. В структурированных данных ты ставишь на странице метку «это мероприятие, вот его дата»; здесь ты ставишь метку «это инструмент связи, вот какие поля он принимает». Логика абсолютно та же; изменилась лишь цель - от «быть понятым» к «заставить сделать работу». Для того, кто годами объяснял машине содержание страницы через SEO, этот переход вовсе не чужой - это новое упражнение для той же самой мышцы.
«Заменит ли WebMCP собой MCP?» - Нет, и это важное заблуждение
Похоже, это самый частый источник путаницы при чтении на эту тему, и команда Chrome прямо ответила на этот вопрос. MCP (Model Context Protocol) и WebMCP не конкуренты, а партнёры. Они служат разным потребностям, и самые мощные агентские сценарии используют их вместе.
Моя любимая аналогия взята прямо из документации: это можно сравнить с разницей между колл-центром компании и опытным продавцом-консультантом в магазине.
- MCP - это бэкенд. Доступен на любой платформе, в любой момент. Забирает данные, выполняет основную работу. Живёт на стороне сервера, постоянен. Прямо как колл-центр: где бы ты ни был, ты дозвонишься и получишь ответ.
- WebMCP - это фронтенд. Живёт только на твоём сайте, пока сайт открыт. Имеет доступ к реальным данным сессии в активной вкладке браузера, к куки, к элементам DOM. Прямо как консультант в магазине: он существует только в этом магазине, пока ты внутри.
Изложу основные различия между ними в таблице, потому что так это лучше укладывается в голове:
| MCP | WebMCP | |
|---|---|---|
| Где живёт | Сервер / бэкенд | Вкладка браузера / фронтенд |
| Время жизни | Постоянное (пока работает сервер) | Временное (пока открыта вкладка) |
| Доступ | Отовсюду (десктоп, мобильные, облако) | Только для агента в браузере |
| Связь с интерфейсом | Безголовый (headless), независим от интерфейса | Чувствителен к DOM, неразрывно связан с живым интерфейсом |
| Тип работы | Фоновые операции через API | Навигация и действия в живом интерфейсе |
То, что инструменты WebMCP временные (ephemeral), на мой взгляд, очень важное решение с точки зрения дизайна: инструменты существуют только пока открыта твоя страница. В тот момент, когда пользователь закрывает вкладку, агент больше не может ничего сделать на твоём сайте. То есть контроль полностью остаётся у тебя и у пользователя. И это успокаивает с точки зрения безопасности.
Кратко картина в голове должна быть такой: MCP несёт в себе мозг и базу данных всей работы, он готов везде и всегда; WebMCP же обеспечивает быструю и надёжную работу агента с интерфейсом именно в тот момент, когда пользователь находится на твоём сайте. Когда они работают вместе, получается настоящий агентский опыт.
Так что же это значит для SEO и GEO?
Вот эта часть меня по-настоящему увлекла. Потому что я взялся за это дело, читая отчёт, а вышел из него с совершенно другим вопросом в голове.
Годами у SEO была одна-единственная цель: ранжирование. Выйти на верхние позиции по ключевому слову, получить клик. Потом появился GEO - Generative Engine Optimization. То есть создание контента для того, чтобы генеративные системы вроде ChatGPT, Perplexity, ИИ-обзоров Google, отвечая на запрос, ссылались на тебя как на источник. SEO говорил «отранжируй меня»; GEO говорит «пойми меня и процитируй».
А WebMCP идёт ещё на шаг дальше: «используй меня».
Представь эти три вещи как лестницу:
- SEO - пусть машина найдёт тебя и отранжирует.
- GEO - пусть машина поймёт тебя и укажет как источник в своём ответе.
- Совместимость с агентами (WebMCP) - пусть машина выполняет работу через тебя.
Я верю вот во что: в ближайшие несколько лет люди будут передавать агентам всё больше и больше задач. Скажут: «запиши меня на завтра к ближайшей открытой парикмахерской» - и откинутся на спинку кресла. Каким сайтом воспользуется агент в этот момент? Тем, который легче угадать. Тем, у которого понятные формы. Тем, кто открыто заявляет свои инструменты. Тем, где он не спотыкается на слепом блуждании.
Помнишь мобильную адаптивность? Когда-то были те, кто говорил «мой сайт красиво выглядит на десктопе, и этого достаточно». Потом Google сделал мобильную адаптивность сигналом ранжирования, и такие сайты в одну ночь стали невидимыми. Совместимость с агентами кажется мне очень похожим порогом. Сегодня, да, это экспериментально. Но слово «экспериментально» в технологиях чаще всего означает «ещё рано, но поезд вот-вот тронется».
Именно поэтому в Detartech мы рассматриваем SEO и GEO не по отдельности, а как части одного и того же будущего. Потому что будущее твоей видимости проходит именно через то, как машина взаимодействует с твоим сайтом - читает ли она его, понимает ли, может ли выполнять на нём действия.
Конкретный сценарий из Турции
Не будем говорить абстрактно. Допустим, ты управляешь сайтом электронной коммерции или, как я, у тебя есть платформа для записи на приём.
Пользователь говорит ассистенту в телефоне: «Забронируй столик на двоих с видом на море на эти выходные». Агент приступает к действию. Если на сайте ресторана есть хорошо описанный инструмент masa_rezervasyonu - с полями даты, количества гостей, предпочтений по столику, - агент завершает это бронирование за несколько секунд, без ошибок. Если инструмента нет, агент бродит по сайту вслепую: может, справится, может, откроет бронь не на тот день, а может, сдастся и перейдёт к следующему ресторану.
Во втором сценарии проигрываешь ты. Причём даже не заметив этого, потому что тот клиент на твой сайт вообще не «заходил» - заходил его агент, и он развернулся и ушёл.
Запись на приём, бронирование, заказ, обращение в поддержку... Это именно те операции, которые чаще всего используются на сайтах малого и среднего бизнеса в Турции. То есть это не какая-то далёкая мечта Кремниевой долины - это напрямую касается твоей формы обратной связи, твоей корзины, твоего календаря записи.
Будем честны: у этого есть и ограничения
К этому моменту ты уже понял, что я не из тех, кто поддаётся хайпу. Поэтому расскажу и обратную сторону медали, потому что каждый, кто об этом не говорит, что-то продаёт.
Это ещё очень свежо. WebMCP сейчас находится на стадии «origin trial» и открыт для тестирования начиная с Chrome 149. То есть стандарт ещё не устоялся и в будущем может измениться. Если хочешь попробовать локально, можешь включить флаг chrome://flags/#enable-webmcp-testing и начать эксперименты, но не забывай, что это не гарантированная инфраструктура для продакшена.
Нужна открытая вкладка. Поскольку вызовы инструментов выполняются через JavaScript, обязательно должен быть видимый интерфейс, то есть открытая вкладка браузера. Безголовый (headless) агент не может вызывать эти инструменты. Для той части работы, что тихо выполняется в фоне, уже есть MCP.
Сложные интерфейсы требуют труда. Если твой сайт многослойный и сложный, тебе может понадобиться писать код, а местами даже проводить рефакторинг, чтобы правильно передавать агенту управление состоянием.
Есть ограничение по обнаруживаемости. Пока что клиенту или браузеру, чтобы узнать о доступных для вызова инструментах на твоём сайте, необходимо посетить сайт напрямую.
Зачем я это рассказываю? Потому что легко сказать «завтра всё изменится, беги немедленно», но это нечестно. Правда в том, что сегодня это семя. Но именно знание того, когда посадить семя, определяет, кто будет сидеть в тени дерева.
Что делаю я и что советую тебе?
Закончив эту статью, я по порядку сделаю следующее:
Сначала я посмотрю на критически важные формы и операции в своих продуктах глазами агента. Форма обратной связи, поток записи на приём, шаг оплаты - может ли машина видеть их чётко, или ей приходится действовать через догадки? Затем я начну мыслить в парадигме «инструмента»: представлю каждое важное действие на своём сайте как чистый инструмент, который может вызвать агент. Начать с Declarative API кажется самым простым способом окунуться в эту воду, не залезая в JavaScript; вероятно, начну именно оттуда.
Мой совет тебе не отличается. Сегодня тебе не нужно переписывать всю инфраструктуру с нуля. Но ты можешь сделать три вещи: строй HTML-формы с чистыми и осмысленными структурами name, label (они и без того на вес золота как для доступности, так и для совместимости с агентами), приучи себя думать об основных операциях на сайте как об «инструментах» и следи за этим стандартом хотя бы издалека. Поезд ещё не отошёл от станции; но купить билет заранее точно не повредит.
Вся эта история началась с одной-единственной строки в крошечном отчёте о скорости. Иногда дверь в будущее прячется в самой рутинной работе, в детали, которая просто ждёт, чтобы её заметили. Наша работа как раз в том и заключается, чтобы видеть эту деталь - чтобы твой сайт был виден в сегодняшних поисковых системах и был удобен для завтрашних ИИ-агентов.
Веб меняется. И снова. И на этот раз меняется не то, как машины читают твою страницу, а то, как они её используют.
Часто задаваемые вопросы (FAQ)
Что такое WebMCP?
WebMCP - это предложенный веб-стандарт, который позволяет сайтам определять структурированные инструменты (tools) для ИИ-агентов. Вместо того чтобы агент угадывал, для чего нужны кнопки на странице, сам сайт открыто заявляет о назначении каждой функции и о том, как её вызывать. Благодаря этому агенты выполняют задачи гораздо надёжнее и без ошибок.
В чём разница между WebMCP и MCP?
MCP (Model Context Protocol) живёт на бэкенде; работает на стороне сервера, постоянен и доступен с любой платформы. WebMCP же живёт на фронтенде, пока открыта вкладка браузера; имеет доступ к активной сессии, куки и DOM. Они не конкуренты; самые мощные агентские сценарии используют MCP для основной логики и данных, а WebMCP - для взаимодействия с живым интерфейсом.
Что означает agentic browsing (навигация на основе агентов)?
Это когда ИИ-агент от имени пользователя перемещается по веб-сайтам и выполняет операции. Такие действия, как заполнение форм, запись на приём, оформление заказа, агент выполняет либо имитируя поведение человека при клике и наборе текста (actuation), либо напрямую вызывая определённые инструменты через такие стандарты, как WebMCP.
Как WebMCP влияет на SEO и GEO?
SEO нацелен на то, чтобы машина находила твою страницу и ранжировала её, GEO - на то, чтобы системы ИИ понимали тебя и указывали как источник. WebMCP же идёт на шаг дальше и позволяет агентам выполнять действия через твой сайт. В ближайшем будущем агенты будут отдавать предпочтение сайтам с чётко определёнными инструментами и понятными формами, поэтому совместимость с агентами имеет все шансы стать новым фактором видимости и конверсии.
Как попробовать WebMCP?
WebMCP сейчас доступен как origin trial начиная с Chrome 149. Для локальной разработки можно включить в Chrome флаг chrome://flags/#enable-webmcp-testing, перезапустить браузер и начать тестирование. Инструменты можно определять двумя способами: с помощью JavaScript (Imperative API) или добавляя атрибуты к HTML-формам (Declarative API).
Заменит ли WebMCP собой MCP?
Нет. Это распространённое заблуждение. WebMCP не является ни расширением MCP, ни технологией, которая придёт ему на замену; они служат разным потребностям на разных уровнях и спроектированы для совместной работы.
