Agent-ready сайт — методология подготовки сайта для работы с ИИ-агентами

Agent-ready сайт помогает ИИ-агенту находить информацию, понимать структуру страниц и выполнять разрешённые действия в заданных пределах. Для этого нужны доступный контент, семантическая разметка, предсказуемая навигация и явно заданные полномочия.

Целевая архитектура agent-ready сайта

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

Целевое состояние выглядит так:

1. У страниц есть стабильные канонические URL.
2. Основной контент присутствует в понятной HTML-структуре.
3. Интерактивные элементы имеют корректные роли, названия и состояния.
4. Внутренние ссылки показывают место страницы в корпусе материалов.
5. Агент может обнаружить краткий путеводитель по сайту и облегчённые версии документов.
6. Автоматические действия ограничены разрешениями и подтверждениями.
7. Публикация и необратимые изменения остаются под контролем человека.

graph LR
    A["HTML и дерево доступности"] --> D["Понимание страницы"]
    B["llms.txt и Markdown-версии"] --> E["Обнаружение материалов"]
    C["Ссылки и метаданные"] --> F["Понимание контекста"]
    D --> G["Безопасное действие"]
    E --> G
    F --> G
    G --> H["Подтверждение человеком"]

Чеклист быстрой проверки

Этот список можно пройти за пять минут:

Семь слоёв готовности

Доступный HTML и стабильный интерфейс

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

Руководство Build agent-friendly websites, обновлённое 1 апреля 2026 года, выделяет три основных канала: скриншот, HTML и дерево доступности. Скриншот помогает понять визуальную композицию, но обычно требует больше ресурсов. HTML показывает структуру и данные. Дерево доступности передаёт роли, названия и состояния элементов управления.

Практические правила:

• используйте настоящие <button>, <a>, <label>, заголовки и списки;
• если семантический элемент применить нельзя, задайте корректные role и tabindex;
• связывайте <label> и поле формы атрибутом for;
• не закрывайте элементы прозрачными оверлеями;
• избегайте скачков макета и случайного изменения расположения ключевых действий;
• отображайте результат каждого действия в интерфейсе;
• проверяйте дерево доступности в инструментах разработчика браузера.

llms.txt и Markdown-представления

Спецификация llms.txt v2, изменённая 10 августа 2026 года, по-прежнему оформлена как предложение. Авторы спецификации указывают, что файл уже публикуют тысячи сайтов, а платформы документации генерируют его автоматически. Это описание распространённости из самой спецификации и не меняет её статуса предложения.

Файл llms.txt можно разместить в корне сайта или по любому пути внутри него. Он описывает URL под своим путём; если применимо несколько файлов, агенту следует использовать наиболее специфичный.

Единственный обязательный раздел — заголовок H1. Далее можно добавить краткое описание в blockquote, пояснения и списки ссылок под заголовками H2.

# Example Site

> Краткое описание сайта и его аудитории.

## Основные разделы

- [Статьи](https://example.com/articles/): аналитические материалы
- [База знаний](https://example.com/knowledge/): руководства и справочники

## Optional

- [Архив](https://example.com/archive/): вторичные материалы

Версия 2 также рекомендует публиковать чистую Markdown-версию важной страницы рядом с HTML и объявлять её через стандартные отношения ссылок:

<link rel="alternate" type="text/markdown" href="/guide.md">
<link rel="describedby" href="/llms.txt">

Те же отношения можно передавать HTTP-заголовком Link. Файл должен оставаться кратким: подробности лучше хранить в документах, на которые он ссылается.

llms.txt не заменяет sitemap.xml и robots.txt. Sitemap перечисляет индексируемые страницы, robots.txt сообщает заявленные правила автоматического доступа и не заменяет серверную авторизацию, а llms.txt служит курированным путеводителем к полезным материалам.

Другие способы выдавать компактный контент

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

Документация Cloudflare, обновлённая 13 июля 2026 года, описывает функцию Markdown for Agents (Beta) для зон, где она включена: клиент отправляет Accept: text/markdown, после чего сервис преобразует HTML в Markdown. Ответ получает Content-Type: text/markdown; charset=utf-8 и Vary: Accept. Сервис также сообщает приблизительное количество токенов до и после преобразования через заголовки x-markdown-tokens и x-original-tokens.

Если исходная HTML-страница содержит JSON-LD, Cloudflare сохраняет его в отдельном блоке fenced JSON в конце Markdown-документа.

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

JSON-LD, Open Graph и RSS решают отдельные задачи:

• JSON-LD описывает сущности и свойства страницы;
• Open Graph формирует данные для предпросмотра;
• RSS или Atom сообщает об обновлениях;
• поисковый индекс в JSON может поддерживать локальный поиск, но его формат определяется самим сайтом.

Связи и контентный граф

Теги отвечают на вопрос «о чём материал». Контекстные ссылки показывают, зачем он нужен и куда двигаться дальше.

Для каждого значимого материала полезно определить:

• родительскую тему или кластер;
• связанные руководства и статьи;
• следующий практический шаг;
• связь с продуктом, кейсом или услугой, если она действительно существует.

Граф внутренних ссылок помогает редакции находить страницы-сироты, тематические разрывы и слабые переходы. В рамках этой методологии граф используется как редакционный инструмент; его наличие не является веб-стандартом. Подробнее: Контентный граф — методология управления контентом через связи, а не рубрики.

Правила доступа и контроль действий

Публичное описание возможностей сайта само по себе не выдаёт агенту полномочий. Реальные ограничения должны обеспечиваться авторизацией, ролями, серверными проверками и подтверждениями пользователя.

AGENTS.md может хранить внутренние правила для coding-агентов конкретного репозитория. Публичный /.well-known/agent-description.md можно использовать как собственное соглашение сайта. В этом материале такой файл рассматривается как локальное соглашение, а не как подтверждённый общий веб-стандарт. Не полагайтесь на него как на механизм безопасности.

WebMCP для действий в браузере

WebMCP — предложенный веб-стандарт для публикации структурированных инструментов на странице. Он позволяет описывать входные и выходные данные через JSON Schema и предоставляет императивный и декларативный API.

По состоянию на 7 августа 2026 года документация Chrome описывает WebMCP как proposed web standard и указывает на экспериментальную программу (origin trial), доступную начиная с Chrome 149. API обсуждается и может измениться. WebMCP рассчитан прежде всего на локальные браузерные сценарии с участием человека. Доступ к нему зависит от изоляции источника (origin) и политики разрешений (Permissions Policy).

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

Пошаговое внедрение

1. Проведите инвентаризацию URL. Найдите дубли, случайные ID и отсутствующие редиректы.
2. Проверьте HTML и дерево доступности. Исправьте заголовки, ссылки, кнопки, формы и состояния.
3. Добавьте контекстные связи. Свяжите материалы внутри тематических кластеров.
4. Опубликуйте машиночитаемый минимум. Настройте sitemap.xml, robots.txt, llms.txt и Markdown для ключевых страниц.
5. Определите полномочия. Разделите чтение, создание черновика, изменение и публикацию.
6. Протестируйте реальные маршруты. Дайте агенту задачу найти документ, сравнить варианты или заполнить форму.
7. Замкните редакционный цикл. Агент предлагает изменение, человек проверяет, после публикации индекс и граф обновляются.

Наблюдаемый результат проверки: агент находит нужную страницу из llms.txt, извлекает основное содержание без навигационного шума, распознаёт элементы управления и останавливается перед действием, требующим подтверждения.

Эталонный шаблон внедрения

/llms.txt                       — краткий путеводитель
/sitemap.xml                    — перечень индексируемых URL
/robots.txt                     — правила автоматического доступа
/knowledge/topic/               — HTML-страница
/knowledge/topic/index.md       — чистая Markdown-версия
/.well-known/agent-description.md — необязательное описание по локальному соглашению сайта

Для каждого материала храните в CMS:

title: Понятный заголовок
slug: stable-slug
status: draft | review | published
canonical_url: https://example.com/knowledge/stable-slug/
related_pages:
  - https://example.com/knowledge/related-topic/
agent_permissions:
  read: true
  propose_changes: true
  publish: false

Это пример внутренней модели. Серверные разрешения остаются источником истины.

Когда полный контур оправдан

Для лендинга обычно достаточно корректного HTML, доступности и стабильного URL. На небольшом сайте добавьте sitemap и ясные связи. llms.txt, Markdown-представления и контентный граф начинают приносить больше пользы по мере роста корпуса материалов.

Сайтам с формами, покупками или агентами в редакционном процессе дополнительно нужны строгие разрешения, журналирование и подтверждения. WebMCP стоит внедрять только под конкретные пользовательские действия с учётом его экспериментального статуса.

Следующий шаг

Что значит «agent-ready» на практике, а не в презентации

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov