20 июня 2026 года я проверял krivoshein.site на готовность к ИИ-агентам и настраивал публичные точки входа. В описании Agent Readiness от Cloudflare речь идёт о поиске ресурсов, формате содержимого и доступных возможностях сайта. Мой результат вырос с 21 до 50 баллов, но сама цифра не говорит, что задача решена полностью.
Начал с карты сайта и понятных ссылок
У блога уже были обычные страницы, карта сайта и RSS. Я добавил llms.txt с коротким описанием проекта и ссылками на важные разделы. Такой файл помогает найти материалы, но не заменяет ни sitemap, ни сами статьи. Если в нём устаревшие адреса, машинному клиенту от него будет мало пользы.
Важно не путать сам файл llms.txt с отдельной проверкой Markdown negotiation. Cloudflare по умолчанию проверяет, умеет ли сайт отвечать Markdown на соответствующий запрос; проверку llms.txt можно включить дополнительно. Наличие одного файла не означает, что любая статья стала доступна в текстовом виде.
API-каталог должен перечислять API, а не все полезные адреса подряд
Для обнаружения программных интерфейсов есть адрес /.well-known/api-catalog. RFC 9727 описывает его назначение и формат application/linkset+json. Минимальный пример для WordPress может содержать одну ссылку на публичный REST API. Документацию, версии и правила использования при необходимости добавляют отдельно.
{
"linkset": [
{
"anchor": "https://example.com/.well-known/api-catalog",
"item": [
{"href": "https://example.com/?rest_route=/"}
]
}
]
}
Sitemap и RSS удобно показывать в описании сайта и через соответствующие связи Link. Но это не повод называть каждый такой ресурс отдельным API в каталоге. И каталог не должен раскрывать внутренние адреса или служебные интерфейсы только ради прохождения проверки.
У моего решения с Markdown была конкретная граница
В июньской настройке запрос к главной странице с Accept: text/markdown направлялся на llms.txt. Это давало краткую карту проекта вместо главной, а не полную Markdown-копию её содержимого. Статьи по своим адресам при этом не получали автоматическое преобразование. Такой упрощённый маршрут нельзя считать поддержкой Markdown для всего сайта.
Для полноценной альтернативной версии нужно сохранять смысл запрошенной страницы: заголовок, текст, ссылки и важные оговорки. Короткая справка о проекте полезна сама по себе, но не заменяет содержание конкретной инструкции. Высокая оценка простого теста этого различия не отменяет.
Проверять стоит обычный запрос и запрос с Accept, причём не только заголовки, но и тело ответа. Ниже команды для просмотра заголовков через GET. Затем можно убрать -o /dev/null и прочитать фактическое содержимое.
curl -sS -D - -o /dev/null https://example.com/ curl -sS -D - -o /dev/null -H 'Accept: text/markdown' https://example.com/
Кэш и правила для роботов проверяются отдельно
Если ответ зависит от Accept, это должно учитываться кэшированием. Заголовок Vary: Accept сообщает о различии представлений, но настройки конкретного кэша всё равно нужно проверить. Полезно менять порядок запросов: сначала HTML, потом Markdown и наоборот. Иначе один клиент может получить вариант, сохранённый для другого.
В robots.txt я также обозначил предпочтения через Content-Signal. Это декларация условий использования для тех систем, которые её учитывают, а не технический запрет на чтение или обучение. Закрытые данные должны защищаться авторизацией и правами доступа, а не одной строкой в robots.txt.
Для обычного блога нет смысла изображать MCP-сервер, OAuth или платёжные возможности, которых на самом деле нет. Проверки торговли могут показываться отдельно и не обязательно участвуют в итоговом балле. А готовность сайта для агента не является обещанием роста поисковых позиций или посещаемости.
Мне эта работа помогла привести в порядок публичные точки входа и лучше понять границы проверки. Следующий полезный шаг не в погоне за числом, а в корректном содержимом по каждому адресу и предсказуемом кэше. Позже я увидел похожую тему в экспериментальных проверках Lighthouse, но это другой инструмент со своей логикой результатов.
