Агенты ИИ не видят ваш сайт так, как люди, и дерево доступности быстро становится интерфейсом, определяющим, могут ли они его использовать.

<п>Каждая крупная платформа искусственного интеллекта теперь может просматривать веб-сайты автономно. Автоматический просмотр Chrome прокручивает и щелкает. ChatGPT Atlas заполняет формы и совершает покупки. Исследования Perplexity Comet на разных вкладках. Но ни один из этих агентов не видит ваш сайт так, как человек.

<стр>Это четвертая часть серии из пяти частей, посвящённой оптимизации веб-сайтов для агентской сети. Часть 1 посвящена эволюции от SEO к AAIO. Во второй части объясняется, как добиться цитирования вашего контента в ответах ИИ. В части 3 были описаны протоколы, образующие уровень инфраструктуры. Эта статья носит технический характер: как агенты ИИ на самом деле воспринимают ваш веб-сайт и что для них нужно создать.

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

<п>Согласно отчету Imperva Bad Bot Report за 2025 год (Imperva — компания, занимающаяся кибербезопасностью), автоматический трафик впервые в 2024 году превысил человеческий трафик, составляя 51% всех веб-взаимодействий. Не все это является агентным просмотром, но направление ясно: нечеловеческая аудитория вашего сайта уже больше человеческой, и она растет. В этой статье мы опираемся исключительно на официальную документацию, рецензируемые исследования и объявления компаний, создающих эту инфраструктуру.

Три способа, которыми агенты видят ваш сайт

<стр>Когда человек посещает ваш сайт, он видит цвета, макет, изображения и типографику. Когда приходит агент ИИ, он видит нечто совершенно иное. Понимание того, что на самом деле воспринимают агенты, является основой для создания веб-сайтов, которые будут работать на них.

<стр>Основные платформы искусственного интеллекта используют три различных подхода, и различия имеют прямое значение для того, как вам следует структурировать свой веб-сайт.

Vision: чтение скриншотов

<п>В книге «Использование компьютера» Anthropic используется самый буквальный подход. Клод делает снимки экрана браузера, анализирует визуальный контент и решает, что нажимать или печатать, основываясь на том, что он «видит». Это непрерывный цикл обратной связи: снимок экрана, причина, действие, снимок экрана. Агент работает на уровне пикселей, идентифицируя кнопки по их внешнему виду и считывая текст из визуализированного изображения.

Проект Mariner от Google следует аналогичной схеме, которую Google описывает как «наблюдать-планировать-действовать». цикл: наблюдение фиксирует визуальные элементы и лежащие в их основе структуры кода, план формулирует последовательность действий, а действие имитирует взаимодействие с пользователем. Mariner достиг 83,5% успеха в тесте WebVoyager.

Подход с визуальным зрением работает, но он требует больших вычислительных затрат, чувствителен к изменениям макета и ограничен тем, что визуально отображается на экране.

Дерево доступности: структура чтения

<п>OpenAI пошла по другому пути с ChatGPT Atlas. Их часто задаваемые вопросы для издателей и разработчиков являются явными:

ChatGPT Atlas использует теги ARIA, те же метки и роли, которые поддерживают программы чтения с экрана, для интерпретации структуры страницы и интерактивных элементов.

<п>Atlas построен на Chromium, но вместо анализа визуализированных пикселей он запрашивает дерево доступности для элементов с определенными ролями (“кнопка”, “ссылка”) и доступными именами. Это та же структура данных, которую используют программы чтения с экрана, такие как VoiceOver и NVDA, чтобы помочь людям с нарушениями зрения ориентироваться в Интернете.

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

Гибрид: оба одновременно

<п>На практике наиболее способные агенты комбинируют подходы. Компьютерный агент OpenAI (CUA), который поддерживает как Оператор, так и Атлас, совмещает анализ снимков экрана с обработкой DOM и анализом дерева доступности. Он отдает приоритет меткам и ролям ARIA, возвращаясь к текстовому содержимому и структурным селекторам, когда данные о доступности недоступны.

Исследования Perplexity подтверждают ту же закономерность. В их документе BrowseSafe, в котором подробно описана инфраструктура безопасности, лежащая в основе агента браузера Comet, описывается использование «гибридного управления контекстом, сочетающего снимки дерева доступности с выборочным зрением».

<таблица> <тр> ~60>Платформа ~60>Основной подход ~60>Подробности <тело> <тр>

Антропное использование компьютера Видение (скриншоты) Снимок экрана, причина, цикл обратной связи

<тр>

Google Project Mariner Видение + структура кода Наблюдать-планировать-действовать с визуальными и структурными данными

<тр>

OpenAI Atlas Дерево доступности Явно использует теги и роли ARIA

<тр>

OpenAI CUA Гибрид

<д>Скриншоты + DOM + дерево доступности

<тр>

Microsoft Playwright MCP Дерево доступности Снимки специальных возможностей, без скриншотов

<тр>

Комета недоумения Гибрид Дерево доступности + выборочный просмотр

Схема ясна. Даже платформы, которые начинали с подходов, ориентированных на видение, включают данные о доступности. А платформы, оптимизированные по надежности и эффективности (Atlas, Playwright MCP), лидируют по дереву доступности.

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

В прошлом году, до вступления в силу Европейского закона о доступности, я полушутя сказал, что было бы иронично, если бы то, что, наконец, заставило бы людей заботиться о доступности, было агентами ИИ, а не людьми, для которых была разработана доступность. Это уже не шутка.

Дерево доступности — это интерфейс вашего агента

<п>Дерево доступности — это упрощенное представление DOM вашей страницы, которое браузеры создают для вспомогательных технологий. Там, где полный DOM содержит все элементы div, span, стиль и скрипт, дерево доступности удаляет шум и отображает только то, что имеет значение: интерактивные элементы, их роли, их имена и их состояния.

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

Часто задаваемые вопросы издателей и разработчиков OpenAI об этом очень ясно:

Следуйте лучшим практикам WAI-ARIA, добавляя описательные роли, метки и состояния к интерактивным элементам, таким как кнопки, меню и формы. Это помогает ChatGPT распознавать, что делает каждый элемент, и более точно взаимодействовать с вашим сайтом.

<п>И: <блоковая цитата><п>Повышение доступности вашего веб-сайта поможет агенту ChatGPT в Atlas лучше его понять.

Данные исследований подтверждают это. Наиболее точные данные по этому поводу получены из исследования Калифорнийского университета в Беркли и Мичиганского университета, опубликованного для CHI 2026, главной научной конференции по взаимодействию человека и компьютера. Исследователи протестировали Claude Sonnet 4.5 на 60 реальных веб-задачах в различных условиях доступности, собрав 40,4 часа данных взаимодействия по 158 325 событиям. Результаты были поразительными:

<таблица> <тр> ~60>Состояние ~60>Процент успешных задач

Ср. Время завершения <тело> <тр>

Стандарт (по умолчанию)

<ср>78,33%

324,87 секунд

<тр>

Только клавиатура

<ср>41,67%

650,91 секунды

<тр>

Увеличенное окно просмотра

<ср>28,33%

1072,20 секунды

В стандартных условиях агенту это удавалось почти в 80% случаев. Ограничьте его взаимодействием только с помощью клавиатуры (имитируя навигацию пользователей программ чтения с экрана), и успех упадет до 42%, что займет вдвое больше времени. Ограничьте область просмотра (имитируя инструменты увеличения), и успех упадет до 28%, что займет в три раза больше времени.

В статье выделяются три категории пробелов:

<ул>

<сильный>Пробелы в восприятии: агенты не могут надежно получить доступ к объявлениям программы чтения с экрана или изменениям состояния ARIA, которые могли бы сообщить им, что произошло после действия.

<сильный>Когнитивные пробелы: агентам сложно отслеживать состояние задачи на нескольких этапах.

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

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

<п>Документ по архитектуре API поиска Perplexity от сентября 2025 года подтверждает это с точки зрения содержания. Их система индексирования отдает приоритет контенту, который является «высококачественным как по содержанию, так и по форме, при этом информация фиксируется таким образом, чтобы сохранить исходную структуру и макет контента». Веб-сайты «нагружены хорошо структурированными данными в виде списков или таблиц»; извлечь выгоду из «более шаблонных правил синтаксического анализа и извлечения». Структура не просто полезна. Именно это делает возможным надежный анализ.

Семантический HTML: The Agent Foundation

Дерево доступности строится на основе вашего HTML. Используйте семантические элементы, и браузер автоматически сгенерирует полезное дерево доступности. Пропустите их, и дерево окажется редким или будет вводить в заблуждение.

<п>Это не новый совет. Сторонники веб-стандартов кричат: «Используйте семантический HTML». в течение двух десятилетий. Не все услышали. Новым является то, что аудитория расширилась. Раньше речь шла о программах чтения с экрана и относительно небольшом проценте пользователей. Теперь речь идет о каждом ИИ-агенте, который посещает ваш сайт.

Использовать собственные элементы. <button> элемент автоматически появляется в дереве доступности с ролью “button” и его текстовое содержимое в качестве доступного имени. <div onclick=”doSomething()”> нет. Агент не знает, что на него можно кликнуть.

<!– Агент может идентифицировать этот объект и взаимодействовать с ним –> <button type=”submit”>Поиск рейсов</button> <!– Агент может не распознать это как интерактивное –> <div class=”btn btn-primary” onclick=”searchFlights()”>Поиск рейсов</div>

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

<!– Агент знает, что это поле электронной почты –> <label for=”email”>Адрес электронной почты</label> <input type=”email” id=”email” name=”email” autocomplete=”email”> <!– Агент видит непомеченный текстовый ввод –> <input type=”text” Placeholder=”Введите адрес электронной почты…”> <п>Атрибут autocomplete заслуживает внимания. Он сообщает агентам (и браузерам), какой именно тип данных ожидает поле, используя стандартизированные значения, такие как имя, адрес электронной почты, телефон, почтовый адрес и организация. Когда агент заполняет форму от чьего-либо имени, атрибуты автозаполнения определяют разницу между уверенным сопоставлением полей и угадыванием.

Установите иерархию заголовков. Используйте h1–h6 в логическом порядке. Агенты используют заголовки, чтобы понять структуру страницы и найти определенные разделы контента. Пропуск уровней (переход с h1 на h4) создает путаницу в отношении взаимоотношений контента.

Использовать ориентиры.Элементы ориентиров HTML5 (<nav>, <main>, <aside>, <footer>, <header>) сообщают агентам, где они находятся на странице. <nav> элемент однозначно является навигацией. <div class=”nav-wrapper”> требует интерпретации. Ясность ради победы, всегда.

<nav aria-label=”Основная навигация”> <ул> <li><a href=”/products”>Продукты</a></li> <li><a href=”/pricing”>Цены</a></li> </ul> </nav> <main> <статья> <h1>Поиск рейсов</h1> <!– Основное содержание –> </статья> </main>

Агенты тестирования Microsoft Playwright, представленные в октябре 2025 года, генерируют тестовый код, который по умолчанию использует доступные селекторы. Когда ИИ генерирует тест драматурга, он пишет:

const todoInput = page.getByRole(‘textbox’, { name: ‘Что нужно сделать?’ }); <п>Не CSS-селекторы. Не XPath. Доступные роли и имена. Microsoft создала свои инструменты тестирования искусственного интеллекта, чтобы находить элементы так же, как это делают программы чтения с экрана, потому что это более надежно.

Последний слайд моего основного доклада Conversion Hotel об оптимизации веб-сайтов для агентов ИИ. (Изображение предоставлено: Слободан Маник)

АРИЯ: Полезно, а не волшебно

<п>OpenAI рекомендует ARIA (Accessible Rich Internet Applications), стандарт W3C для обеспечения доступности динамического веб-контента. Но ARIA — это дополнение, а не замена. Как протеиновые коктейли: полезны в дополнение к настоящей диете, контрпродуктивны в качестве замены настоящей еды.

Первое правило ARIA, определенное W3C:

Если вы можете использовать собственный HTML-элемент или атрибут с уже встроенной семантикой и поведением, вместо того, чтобы переназначать элемент и добавлять роль, состояние или свойство ARIA, чтобы сделать его доступным, сделайте это.

Тот факт, что W3C пришлось сделать так, чтобы “don’t use ARIA” первое правило ARIA расскажет вам все о том, как часто им злоупотребляют.

<п>Адриан Роселли, признанный эксперт по веб-доступности, выразил важную обеспокоенность в своем анализе рекомендаций OpenAI в октябре 2025 года. Он утверждает, что рекомендация ВСС без достаточного контекста рискует спровоцировать злоупотребления. Согласно ежегодному опросу миллиона крупнейших веб-сайтов, проведенному WebAIM, веб-сайты, использующие ARIA, обычно менее доступны, поскольку ARIA часто применяется неправильно в качестве средства для исправления плохой структуры HTML. Розелли предупреждает, что руководство OpenAI может стимулировать такие практики, как вставка ключевых слов в атрибуты aria-label — тот же вид игры, который преследовал мета-ключевые слова в ранней SEO.

Правильный подход многоуровневый:

<ол>

Начните с семантического HTML. Используйте <button>, <nav>, <label>, <select> и другие собственные элементы. По умолчанию они работают правильно.

Добавляйте ARIA, когда встроенного HTML недостаточно. Пользовательским компонентам, не имеющим HTML-эквивалентов (панели вкладок, древовидные представления, виджеты раскрытия информации), необходимы роли и состояния ARIA, чтобы быть понятными.

Использовать состояния ARIA для динамического контента. Когда JavaScript изменяет страницу, атрибуты ARIA сообщают о том, что произошло:

<!– Сообщает агентам, открыто или закрыто меню –> <button aria-expanded=”false” aria-controls=”menu-panel”>Menu</button> <div id=”меню-панель” aria-hidden=”true”> <!– Содержимое меню –> </div>

4. Сохраняйте aria-label описательным и честным.Используйте его для предоставления контекста, который не виден на экране, например, для различения нескольких элементов “Удалить” кнопки на той же странице. Не набивайте его ключевыми словами.

Принцип тот же, что и в хорошем SEO: сначала создайте для пользователя, затем оптимизируйте для системы. Семантический HTML создан для пользователя. ARIA выполняет точную настройку для крайних случаев, когда HTML не справляется.

Вопрос по рендерингу

<п>Браузерные агенты, такие как автоматический просмотр Chrome, ChatGPT Atlas и Perplexity Comet, работают на Chromium. Они выполняют JavaScript. Они могут визуализировать ваше одностраничное приложение.

Но не всё, что посещает ваш сайт, является полноценным браузерным агентом.

Сканеры AI (PerplexityBot, OAI-SearchBot, ClaudeBot) индексируют ваш контент для поиска и цитирования. Многие из этих сканеров не выполняют клиентский JavaScript. Если ваша страница представляет собой пустой файл <div id=”root”></div> пока React не гидратируется, эти сканеры видят пустую страницу. Ваш контент невидим для поисковой экосистемы ИИ.

Это требование видимости.

<п>Даже для полноценных браузерных агентов веб-сайты с большим количеством JavaScript создают трудности. Динамический контент, который загружается после взаимодействия, бесконечная прокрутка, которая никогда не сигнализирует о завершении, и формы, которые восстанавливаются после каждого ввода, — все это создает для агентов возможность потерять отслеживание состояния. Исследование A11y-CUA отчасти связывает неудачи агентов с «когнитивными пробелами»: агенты теряют представление о том, что происходит во время сложных многоэтапных взаимодействий. Более простой и предсказуемый рендеринг уменьшает количество подобных ошибок.

Руководство Microsoft из части 2 применимо и здесь: “Не скрывайте важные ответы на вкладках или расширяемых меню: системы искусственного интеллекта могут не отображать скрытый контент, поэтому ключевые детали можно пропустить” Если информация имеет значение, поместите ее в видимый HTML-код. Не требуйте взаимодействия, чтобы его раскрыть.

Практические приоритеты рендеринга:

<ул>

5. Рендеринг или предварительный рендеринг страниц контента на стороне сервера. Если сканер ИИ не видит его, значит, он не существует в экосистеме ИИ.
6. Избегайте пустых SPA для страниц с контентом.Такие фреймворки, как Next.js (на котором работает этот сайт), Nuxt и Astro, упрощают SSR.
7. Не скрывайте важную информацию за взаимодействиями. Цены, характеристики, доступность и ключевые сведения должны быть в исходном HTML-коде, а не за аккордеонами или вкладками.
8. Используйте стандартный <a href> ссылки для навигации. Маршрутизация на стороне клиента, которая не обновляет URL-адрес или использует обработчики onClick вместо реальных ссылок, нарушает навигацию агента.

Тестирование интерфейса вашего агента

Вы не выпустите веб-сайт, не протестировав его в браузере. Не менее важным становится тестирование того, как агенты воспринимают ваш сайт.

Тестирование программы чтения с экрана — лучший прокси. Если VoiceOver (macOS), NVDA (Windows) или TalkBack (Android) может успешно перемещаться по вашему веб-сайту, распознавая кнопки, читая метки форм и следуя структуре контента, агенты, скорее всего, смогут делать то же самое. Обе аудитории полагаются на одно и то же дерево доступности. Это не идеальный прокси (у агентов есть возможности, которых нет у программ чтения с экрана, и наоборот), но он устраняет большинство проблем.

Microsoft Playwright MCP обеспечивает снимки прямого доступа.Если вы хотите увидеть именно то, что видит агент ИИ, Playwright MCP генерирует структурированные снимки доступности любой страницы. Эти снимки убирают визуальное представление и показывают роли, имена и состояния, с которыми работают агенты. Опубликованный на npm как @playwright/mcp, это самый прямой способ просмотреть ваш сайт глазами агента.

Вывод выглядит примерно так (упрощенно):

[уровень заголовка=1] Поиск рейса [навигация “Основная навигация”] [ссылка] Продукты [ссылка] Цены [основной] [текстовое поле «Аэропорт вылета»] value=”” [текстовое поле «Аэропорт прибытия»] value=”” [кнопка] Поиск рейсов

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

Браузерная база рабочих сцены(версия 3, выпущенная в октябре 2025 года и скромно названная «лучшей платформой автоматизации браузеров») предлагает другой ракурс. Он анализирует как DOM, так и деревья доступности, а его самовосстанавливающееся выполнение адаптируется к изменениям DOM в реальном времени. Это полезно для проверки того, могут ли агенты выполнять определенные рабочие процессы на вашем веб-сайте, например заполнение формы или оформление заказа.

Браузер Lynx — это низкотехнологичный вариант, который стоит попробовать. Это текстовый браузер, который удаляет весь визуальный рендеринг, показывая вам примерно то, что анализирует невизуальный агент. Трюк, который я позаимствовал у Джеса Шольца в подкасте.

Практический рабочий процесс тестирования:

<ол>

9. Запустите VoiceOver или NVDA через ключевые потоки пользователей вашего веб-сайта. Сможете ли вы выполнить основные задачи без зрения?
10. Создать снимки доступности критически важных страниц Playwright MCP. Имеются ли интерактивные элементы, маркированные и идентифицируемые?
11. Просмотреть исходный код вашей страницы. Является ли основным содержимым HTML или для его рендеринга требуется JavaScript?
12. Загрузите свою страницу в Lynx или отключите CSS и проверьте, имеют ли смысл порядок и иерархия контента. Агенты не видят ваш макет.

Контрольный список для вашей команды разработчиков

<п>Если вы поделитесь этой статьей со своими разработчиками (а вам следует это сделать), вот список приоритетных реализаций. Сортировано по влиянию и усилиям, начиная с изменений, которые затрагивают наибольшее количество взаимодействий агентов с наименьшей работой.

<сильный>Сильный удар, низкие усилия:

<ол>

13. Используйте собственные элементы HTML. <button> для действий <a href> для ссылок <select> для выпадающих списков. Замените <div onclick> шаблоны, где бы они ни существовали.
14. Помечайте каждый ввод формы. Ассоциируйте <label> элементы с входными данными, использующими атрибут for. Добавьте атрибуты автозаполнения со стандартными значениями.
15. Отображение страниц содержимого на стороне сервера. Убедитесь, что основной контент находится в исходном HTML-ответе.

<сильный>Сильный удар, умеренное усилие:

4. Реализовать ориентирные регионы. Обернуть содержимое в <nav>, <main>, <aside> и <footer> элементы. Добавьте aria-label, если на одной странице существует несколько ориентиров одного типа.
5. Исправить иерархию заголовков. Обеспечить один h1, где h2–h6 располагается в логическом порядке, не пропуская уровни.
6. Переместить критически важный контент из скрытых контейнеров. Цены, характеристики и ключевые детали не должны требовать кликов или взаимодействия для раскрытия.

<сильное>Умеренное воздействие, небольшое усилие:

7. Добавьте состояния ARIA к динамическим компонентам. Используйте aria-expanded, aria-controls и aria-hidden для меню, аккордеонов и переключателей.
8. Используйте описательный текст ссылки.“Читать полный отчет” вместо «Нажмите здесь». Агенты используют текст ссылки, чтобы понять, куда ведут ссылки.
9. Протестируйте с помощью программы чтения с экрана. Сделайте это частью процесса контроля качества, а не разовым аудитом.

Ключевые выводы

<ул>

10. Агенты ИИ воспринимают веб-сайты с помощью трех подходов: видение, анализ DOM и дерево доступности.В отрасли используется дерево доступности как наиболее надежный метод. OpenAI Atlas, Microsoft Playwright MCP и Comet от Perplexity полагаются на данные о доступности.
11. Доступность веб-сайтов больше не ограничивается соблюдением требований. Дерево доступности — это буквальный интерфейс, который ИИ-агенты используют для понимания вашего веб-сайта. Исследование Калифорнийского университета в Беркли и Мичиганского университета показывает, что показатели успеха агентов значительно снижаются, когда функции доступности ограничены.
12. Семантический HTML является основой. Нативные элементы, такие как <button>, <label>, <nav> и <main> автоматически создавать полезное дерево доступности. Никаких рамок не требуется. Для основ ARIA не требуется.
13. ARIA является дополнением, а не заменой.Используйте его для динамических состояний и пользовательских компонентов. Но начните с семантического HTML и добавляйте ARIA только там, где нативные элементы не подходят. Неправильное использование ARIA делает веб-сайты менее доступными, а не более.
14. Рендеринг на стороне сервера является требованием видимости агента. Поисковые роботы с искусственным интеллектом, которые не выполняют JavaScript, не могут видеть содержимое в SPA с пустой оболочкой. Если вашего контента нет в исходном HTML, его не существует в экосистеме искусственного интеллекта.
15. Тестирование программы чтения с экрана — лучший показатель совместимости агентов. Если VoiceOver или NVDA могут перемещаться по вашему веб-сайту, то и агенты, вероятно, тоже смогут. Для непосредственной проверки снимки доступности Playwright MCP показывают именно то, что видят агенты.

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

И работа строится сама по себе. Описанные здесь семантический HTML и структурированные данные — это именно то, на чем строится WebMCP в своем подходе к декларативным формам. Дерево доступности, которое ваш веб-сайт представляет сегодня, становится основой для структурированных интерфейсов инструментов завтрашнего дня.

<стр>Следующее в Части 5: уровень коммерции. Как Stripe, Shopify и OpenAI создают инфраструктуру для ИИ-агентов для совершения покупок и что это значит для вашего процесса оформления заказа.

Этот пост был первоначально опубликован на No Hacks.