Слой обнаружения для ИИ: llms.txt, карта сайта и schema

Большая часть того, что пишут о «подготовке сайта к ИИ-агентам», описывает файлы, чтение которых не документирует ни один вендор. Я прошёл по официальной документации OpenAI, Anthropic, Perplexity, Google и Microsoft. Результат: llms.txt — ни одна из этих компаний не документирует его чтение со сторонних сайтов, а Google прямо заявляет, что её Поиск его игнорирует. sitemap.xml — не упоминается ни в одном из трёх документов о ботах. Разметка schema.org — Google пишет, что она не требуется для генеративных функций. А в реестре IANA среди 152 записей нет регистрации ни для mcp, ни для ai, ни для agent. Что действительно существует — и что действительно стоит делать — ниже.

Короткий список того, что реально задокументировано

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

llms.txt: публикуют все, чтение не документирует никто

Этот файл — предложение Джереми Ховарда, опубликованное 3 сентября 2024 года и обновлённое до версии 2 10 августа 2026 года, а на собственном сайте описанное как предложение по стандартизации. Он не находится ни на одном треке стандартизации IETF, W3C или WHATWG — поиск в IETF Datatracker не возвращает ни одного релевантного черновика. Сайт самого предложения называет RFC 8615 альтернативой, которая рассматривалась и не была принята.

Вот главная путаница, с которой я сталкиваюсь снова и снова: OpenAI, Anthropic и Perplexity действительно публикуют файл llms.txt для собственной документации для разработчиков. Это факт, и его легко проверить. Но публиковать файл и читать чужие файлы — два совершенно разных действия, и второе не документирует ни одна из этих компаний. Я прочитал все три официальные страницы о краулерах: строки llms.txt нет ни в одной из них.

Google — единственный вендор, который высказался об этом напрямую. В её руководстве по оптимизации для генеративных функций, на странице, обновлённой 10 июля 2026 года, есть раздел с развенчанием мифов, где llms.txt назван явно, на том основании, что сам Поиск Google его не использует. В том же разделе Google добавляет, что создание файла не повредит и не поможет видимости или позициям сайта.

schema.org: не обязательна, но всё равно стоит того

Именно этот пункт удивляет людей больше всего. В том же руководстве Google от 10 июля 2026 года есть целый раздел под названием «Overfocusing on structured data», где сказано, что структурированные данные не требуются для генеративного ИИ-поиска и что не существует особой разметки schema.org, которую нужно добавить. Параллельная страница об ИИ-функциях, обновлённая 10 декабря 2025 года, утверждает то же самое другими словами: не нужно создавать новые машиночитаемые файлы или специальную разметку.

И всё же Google по-прежнему рекомендует использовать структурированные данные — не из-за ИИ, а ради права на расширенные результаты, и это само по себе отличная причина. Дополнительная рекомендация, прямо относящаяся к теме, — убедиться, что структурированные данные совпадают с видимым текстом страницы. Разметка, которая заявляет то, чего страница не говорит, — это риск, а не преимущество.

Практический вывод: если у вас есть валидная разметка — отлично, оставьте её. Если нет — добавьте, потому что она помогает расширенным результатам, а не потому, что кто-то пообещал, что она приведёт вас в ответы ChatGPT.

sitemap.xml: предположение без источника

«Отправьте карту сайта, чтобы ИИ-краулеры вас нашли» — одна из самых распространённых рекомендаций, и я не смог найти для неё ни одного первичного источника. Страница OpenAI о ботах говорит только о robots.txt и диапазонах IP-адресов. Статья Anthropic о краулере говорит о robots.txt и Crawl-delay. Страница Perplexity о краулере вообще не упоминает карты сайта.

Это не значит, что они не читают карты сайта, — это значит, что никто не сказал, что читает. Различие важно, потому что оно определяет, сколько усилий стоит вкладывать. Валидный sitemap.xml — обязательный минимум для Google, так что он должен у вас быть в любом случае. Но если вы строите целый план работ вокруг карты сайта как «инфраструктуры для ИИ-агентов», вы строите на предположении, которое никто не подтвердил.

/.well-known/ — что действительно зарегистрировано, а что нет

Реестр well-known URI от IANA — единственный источник истины о том, что существует. На момент последнего обновления, 19 августа 2026 года, в нём 152 записи. Что важно для мира агентов:

• agent-card.json — зарегистрирован, постоянный, под контролем изменений Linux Foundation, ссылается на спецификацию протокола A2A. Это единственная запись, которая напрямую касается агентов.
• oauth-protected-resource (RFC 9728) и oauth-authorization-server (RFC 8414) — зарегистрированы и релевантны, потому что MCP строит на них свой слой авторизации.
• mcp, ai, agent, ai-plugin, llm — не зарегистрированы.

Что касается /.well-known/ai-plugin.json эпохи плагинов ChatGPT: этого механизма больше нет. Исходная страница документации теперь ведёт на несуществующую страницу, а на смену пришли MCP-серверы и Apps SDK — вообще без well-known пути.

MCP пока нельзя обнаружить с сайта

Это самый важный пункт, если вы планируете наперёд. Текущая спецификация Model Context Protocol — версия 2026-07-28, и в ней нет механизма обнаружения MCP-сервера с сайта. Что есть, так это server/discover, который спрашивает у сервера, какие версии протокола он поддерживает, — механизм, предполагающий, что адрес сервера вам уже известен. Единственный well-known путь в спецификации принадлежит OAuth и вступает в игру только после обнаружения.

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

IndexNow: исключение от Microsoft

Единственное, что крупный вендор прямо рекомендует в контексте ИИ, — это IndexNow. В публикации Bing Webmaster от 10 февраля 2026 года, представившей новый отчёт об ИИ-эффективности, есть отдельный раздел, объясняющий, что IndexNow помогает поддерживать актуальность информации в поиске и ИИ-сценариях. Сам протокол открыт и бесплатен, а реализация — это один HTTP-запрос на каждый обновлённый URL.

Одно уточнение, которое стоит отметить: документация Bing для разработчиков вообще не упоминает llms.txt. Рекомендации по разметке в контексте ИИ-ответов появляются в блоге Microsoft Advertising, а это маркетинговый контент, а не техническая документация — другой вес доказательства.

Практический порядок приоритетов

Три строки, которые покажут, что ваш сайт уже отдаёт сегодня:

После проверки — вот порядок, который я рекомендую. Первое: корректный robots.txt, разделяющий обучающие краулеры и запросы во время ответа, — я разобрал это в карте ботов 2026. Второе: убедиться, что ваш контент действительно попадает в исходный HTML, потому что без этого всё остальное не имеет значения — проверка описана в материале о том, что ИИ-агент получает на самом деле. Третье: валидная разметка, совпадающая с видимым текстом. Четвёртое: IndexNow, если ваш контент меняется. И пятое, только пятое, — llms.txt, если останется время.

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

Частые вопросы

Продолжить чтение

Спецификация AX – как только агент может вас обнаружить, вопрос становится в том, что вы позволяете ему делать.