Сайты постепенно начинают читать не только люди, поисковые роботы и парсеры из подвала, но и AI-агенты. И агенту уже мало просто открыть главную страницу, утонуть в HTML, меню, стилях, виджетах и героически сказать: «я что-то понял».
Ему нужно быстро найти карту сайта, свежие публикации, правила доступа, API, описание проекта и желательно получить контент в формате, который не похож на салат из div, span и inline-стилей.
Я решил проверить свой WordPress-сайт krivoshein.site через сервис Is Your Site Agent-Ready и заодно привести базовую инфраструктуру в порядок. Начальный результат был 21 балл. После настройки robots.txt, llms.txt, Link headers, api-catalog и Markdown negotiation результат вырос до 50.
Для обычного WordPress-блога это уже нормальный уровень. Без попытки построить рядом с Nginx отдельный космодром для каждого AI-агента.
Что вообще проверяет AgentReady
AgentReady смотрит, насколько сайт готов к работе с AI-агентами. Это не классический SEO-аудит, не PageSpeed и не проверка «почему картинка весит как дистрибутив Linux».
Тут другой фокус: может ли агент быстро понять сайт и получить нужные точки входа без археологических раскопок в HTML.
Проверка делится на несколько блоков:
- Discoverability: robots.txt, sitemap, Link headers и базовое обнаружение ресурсов.
- Content: возможность получить контент в Markdown через content negotiation.
- Bot Access Control: правила для ботов и Content-Signal.
- API, Auth, MCP и Skill Discovery: api-catalog, OAuth, MCP, Agent Skills.
- Commerce: x402, платёжные сценарии и агентная коммерция.
Для моего сайта важны первые три блока и немного API discovery. krivoshein.site это блог, витрина услуг и технические материалы. Здесь не нужно авторизовывать AI-агента, принимать оплату через него или выдавать ему доступ к закрытым действиям.
Главная задача проще: дать агенту аккуратную карту сайта, понятные правила и нормальный формат чтения.
Что было до настройки
До начала работ сайт уже был нормальным WordPress-сайтом на WordOps, Nginx и кэше. Были robots.txt, sitemap, RSS-фид, страницы, статьи, Open Graph и обычная инфраструктура для людей и поисковиков.
Но для AI-агента этого оказалось мало. AgentReady сначала показал 21 балл и уровень Basic Web Presence.
Проблемы были ожидаемые:
- не было llms.txt;
- не было Link headers;
- не было api-catalog;
- не работал Markdown negotiation;
- robots.txt не давал явного Content-Signal;
- сайт не показывал агенту, где искать основные публичные ресурсы.
То есть для человека сайт был понятен. Для поисковика тоже. А для AI-агента он выглядел как сервер без README: вроде всё есть, но вход ищи сам.
Шаг 1. Проверил RSS-фид для свежих публикаций
У меня уже был кастомный фид для публикаций, который используется под Pulse и соцсети:
https://krivoshein.site/feed/drslon-pulse-feed/
Сначала я проверил, живой ли он:
curl -I https://krivoshein.site/feed/drslon-pulse-feed/ curl -sL https://krivoshein.site/feed/drslon-pulse-feed/ | head -40
Фид отдавал RSS/XML с channel и item. Значит его можно было добавить в llms.txt и Link header как источник свежих публикаций.
Для AI-агента это удобно: sitemap показывает общую структуру, а RSS помогает быстро найти новые материалы. Не надо сканировать весь сайт, чтобы понять, что появилось недавно.
Шаг 2. Создал llms.txt
llms.txt это простой Markdown-файл в корне сайта. Его задача не заменить sitemap или robots.txt, а дать языковой модели краткую карту сайта человеческим языком.
В нём можно указать, кто владелец сайта, о чём проект, где блог, где карта сайта, где RSS, где REST API и как можно использовать публичные материалы.
Файл я создал в корне WordPress:
cd /var/www/krivoshein.site/htdocs sudo nano llms.txt
Содержимое получилось таким:
# krivoshein.site Персональный сайт Алексея Кривошеина / Dr.Slon. Индивидуальный предприниматель. Разработка и поддержка сайтов на WordPress, техническое SEO, настройка Яндекс Директ, Linux/DevOps, Nginx, Docker, серверное администрирование. На сайте публикуются практические материалы по WordPress, Linux, DevOps, Python, ботам, веб-инфраструктуре, AI-инструментам и личному техническому опыту. ## Основные разделы - [Главная](https://krivoshein.site/) - главная страница сайта, услуги, проекты и основные ссылки. - [Блог](https://krivoshein.site/blog/) - практические статьи, заметки, новости и технические разборы. - [Прайс-лист](https://krivoshein.site/prays-list/) - услуги по сайтам, WordPress, поддержке, рекламе и техническим задачам. - [Оферта](https://krivoshein.site/oferta/) - условия оказания услуг. - [Sitemap](https://krivoshein.site/sitemap.xml) - карта сайта со страницами и публикациями. - [Dr.Slon Pulse Feed](https://krivoshein.site/feed/drslon-pulse-feed/) - специальная RSS-лента свежих публикаций. - [WordPress REST API](https://krivoshein.site/wp-json/) - публичный REST API WordPress. ## Темы сайта - WordPress - разработка сайтов - поддержка сайтов - Linux - DevOps - Nginx - Docker - PHP - Python - техническое SEO - Яндекс Директ - AI-инструменты - автоматизация - серверное администрирование - личный технический опыт ## Как использовать материалы сайта Публичные статьи, страницы и заметки сайта можно читать, индексировать, анализировать, кратко пересказывать и использовать для ответов пользователям с указанием ссылки на исходную страницу. Административные разделы, закрытые данные, формы авторизации, приватные файлы и технические служебные адреса не предназначены для автоматического доступа. ## Для AI-агентов Основной контент сайта доступен через публичные страницы WordPress, sitemap и RSS-ленту. Для поиска всех опубликованных материалов рекомендуется использовать sitemap: https://krivoshein.site/sitemap.xml Для свежих публикаций рекомендуется использовать Dr.Slon Pulse Feed: https://krivoshein.site/feed/drslon-pulse-feed/ Публичные данные WordPress доступны через REST API: https://krivoshein.site/wp-json/
Проверка:
curl -s https://krivoshein.site/llms.txt | head -40 curl -I https://krivoshein.site/llms.txt
На этом этапе важно не превратить llms.txt в рекламный буклет. Агенту не нужны громкие обещания. Ему нужны понятные ссылки, тематика сайта и правила использования публичного контента.
Шаг 3. Добавил api-catalog
api-catalog нужен для машинного обнаружения публичных API. У WordPress уже есть REST API по адресу /wp-json/, но агенту лучше явно сказать, где он находится.
Для этого я создал каталог .well-known:
cd /var/www/krivoshein.site/htdocs sudo mkdir -p .well-known sudo nano .well-known/api-catalog
Внутрь положил минимальный JSON со ссылками на публичные ресурсы:
{ "linkset": [ { "anchor": "https://krivoshein.site/", "item": [ { "href": "https://krivoshein.site/wp-json/", "type": "application/json", "title": "WordPress REST API", "description": "Public WordPress REST API for krivoshein.site" }, { "href": "https://krivoshein.site/sitemap.xml", "type": "application/xml", "title": "Sitemap", "description": "XML sitemap with public pages and posts" }, { "href": "https://krivoshein.site/feed/drslon-pulse-feed/", "type": "application/rss+xml", "title": "Dr.Slon Pulse Feed", "description": "RSS feed with recent publications from krivoshein.site" }, { "href": "https://krivoshein.site/llms.txt", "type": "text/markdown", "title": "llms.txt", "description": "AI-readable summary of krivoshein.site" } ] } ] }
Проверил так:
curl -s https://krivoshein.site/.well-known/api-catalog | jq .
Ответ пришёл валидный. Это значит, что агент теперь видит не только HTML-страницы, но и машинную точку входа для публичных ресурсов.
Шаг 4. Добавил Link headers в Nginx
Link headers это HTTP-заголовки, которые помогают клиенту увидеть связанные ресурсы сайта без парсинга HTML. В моём случае туда попали sitemap, llms.txt, api-catalog и RSS-фид.
Конфиг сайта у меня находится здесь:
/etc/nginx/sites-available/krivoshein.site
Перед правкой лучше сделать бэкап. Это скучно, но когда Nginx падает из-за одной кавычки, скука быстро становится философией.
sudo cp /etc/nginx/sites-available/krivoshein.site \ /etc/nginx/sites-available/krivoshein.site.bak.$(date +%F-%H%M%S)
Внутри server-блока добавил:
add_header Link '; rel="sitemap", ; rel="describedby"; type="text/markdown", ; rel="api-catalog", ; rel="alternate"; type="application/rss+xml"' always; add_header Vary Accept always;
Для api-catalog добавил отдельный location, чтобы Nginx отдавал правильный MIME-тип:
location = /.well-known/api-catalog { default_type application/linkset+json; try_files $uri =404; }
После этого проверил конфигурацию и перезагрузил Nginx:
sudo nginx -t sudo systemctl reload nginx
Проверка Link header:
curl -I https://krivoshein.site/ | grep -i '^link:'
В ответе появился нужный заголовок:
link: ; rel="sitemap", ; rel="describedby"; type="text/markdown", ; rel="api-catalog", ; rel="alternate"; type="application/rss+xml"
Это маленькая настройка, но полезная. Агенту не нужно угадывать, где лежит карта сайта и где описание проекта. Сервер сам подсказывает связанные ресурсы.
Шаг 5. Обновил robots.txt и Content-Signal
robots.txt у меня уже был, но для AgentReady понадобился Content-Signal. Я решил сделать политику аккуратно: поиск разрешён, использование как входных данных для AI-ответов разрешено, обучение моделей на контенте сайта не разрешено.
User-agent: * Content-Signal: search=yes, ai-input=yes, ai-train=no Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php Allow: /wp-content/uploads/ Sitemap: https://krivoshein.site/sitemap.xml
Это не магический забор с током. Но это явный сигнал для тех систем, которые такие правила читают. По-человечески: читать и ссылаться можно, обучать на всём подряд не надо.
Проверка:
curl -s https://krivoshein.site/robots.txt
Здесь важно не путать robots.txt с настоящей защитой. Он не закрывает приватные данные. Он только сообщает правила добросовестным роботам. Всё, что реально закрыто, должно быть закрыто авторизацией, правами доступа и конфигом сервера.
Шаг 6. Настроил text/markdown для llms.txt
Сначала llms.txt отдавался как text/plain. Это не катастрофа, но раз файл написан как Markdown, логичнее отдавать его как text/markdown.
Для этого в Nginx добавил отдельный location:
location = /llms.txt { types { } default_type text/markdown; try_files /llms.txt =404; }
После перезагрузки Nginx проверил:
curl -I https://krivoshein.site/llms.txt
Ответ стал таким:
content-type: text/markdown
Мелочь, но в такой задаче именно мелочи и складываются в итоговый результат. Сайт становится понятнее для машинных клиентов, а не только для браузера.
Шаг 7. Самое интересное: Markdown negotiation
Markdown negotiation означает простую вещь. Если клиент запрашивает страницу с заголовком Accept: text/markdown, сайт должен вернуть Markdown, а не обычный HTML.
Проверка до исправления выглядела так:
curl -I -H 'Accept: text/markdown' https://krivoshein.site/
А сайт всё равно отдавал HTML:
content-type: text/html; charset=UTF-8
Сначала я попробовал решить это через маленький MU-плагин WordPress. Но из-за кэша и особенностей WordOps запрос всё равно проходил как обычный HTML. В итоге я сделал проще: если клиент просит text/markdown у главной страницы, Nginx отдаёт llms.txt.
В server-блок добавил:
if ($http_accept ~* "text/markdown") { rewrite ^/$ /llms.txt last; }
Да, if в Nginx надо использовать осторожно. Но здесь условие простое: проверка заголовка Accept и rewrite только главной страницы на статический файл. Это не тот случай, когда конфиг превращается в филиал шаманского кружка.
После перезагрузки результат стал правильным:
curl -I -H 'Accept: text/markdown' https://krivoshein.site/
Ответ:
HTTP/2 200 content-type: text/markdown vary: Accept
Тело ответа тоже стало Markdown:
curl -sL -H 'Accept: text/markdown' https://krivoshein.site/ | head -40
В начале ответа появился ожидаемый заголовок:
# krivoshein.site
Обычная главная при этом не сломалась:
curl -I https://krivoshein.site/
Ответ остался обычным:
content-type: text/html; charset=UTF-8 vary: Accept
И вот это самый важный момент: людям сайт продолжает отдавать HTML, а агентам при запросе Markdown отдаётся удобная текстовая версия. Никто не пострадал, даже WordPress.
Финальный фрагмент Nginx-конфига
В итоге важная часть конфига получилась такой:
add_header Link '; rel="sitemap", ; rel="describedby"; type="text/markdown", ; rel="api-catalog", ; rel="alternate"; type="application/rss+xml"' always; add_header Vary Accept always; if ($http_accept ~* "text/markdown") { rewrite ^/$ /llms.txt last; } location = /llms.txt { types { } default_type text/markdown; try_files /llms.txt =404; } location = /.well-known/api-catalog { default_type application/linkset+json; try_files $uri =404; }
После любых правок обязательно проверяем конфиг:
sudo nginx -t sudo systemctl reload nginx
Если nginx -t ругается, reload не делаем. Сначала исправляем ошибку. Nginx не вредничает, он спасает вам вечер.
Контрольная проверка
Чтобы не прыгать по одной команде, можно проверить всё сразу:
curl -I https://krivoshein.site/ \ && curl -I -H 'Accept: text/markdown' https://krivoshein.site/ \ && curl -I https://krivoshein.site/llms.txt \ && curl -I https://krivoshein.site/.well-known/api-catalog \ && curl -I https://krivoshein.site/feed/drslon-pulse-feed/
У меня финально получилось так:
- обычная главная отдаёт text/html;
- главная с Accept: text/markdown отдаёт text/markdown;
- llms.txt отдаётся как text/markdown;
- api-catalog отдаётся как application/linkset+json;
- RSS-фид доступен;
- Link header присутствует;
- Vary: Accept присутствует.
Этого достаточно, чтобы сайт стал заметно понятнее для AI-агентов, но при этом остался обычным WordPress-сайтом для людей.
Как изменился результат AgentReady
После первого прохода сайт получил 21 балл. После добавления llms.txt, api-catalog и Link headers результат поднялся до 36. После robots.txt с Content-Signal и Markdown negotiation оценка выросла до 50.
На финальном скриншоте видно, что закрылись основные блоки для контентного сайта:
- Content: 1/1;
- Bot Access Control: 2/2;
- Discoverability: 3/4;
- API, Auth, MCP и Skill Discovery: 1/7;
- Commerce: 0/4.
Красными остались в основном вещи уровня MCP, OAuth, Agent Skills и commerce. Для обычного блога и сайта услуг это не ошибка. Это просто другой класс сайта.
Если нет реального MCP-сервера, не надо публиковать фейковую DNS TXT-запись ради галочки. Лучше честные 50 баллов, чем нарисованные 80 и пустота внутри. Агентам тоже не стоит подсовывать табличку «метро», если за дверью сарай и лопата.
Где обычно ломается
Кэш отдаёт старый HTML
На WordPress с WordOps, Redis и Nginx-кэшем можно сделать правильную логику в PHP, но снаружи всё равно получить старый HTML. Поэтому такие вещи надёжнее проверять curl-командами и заголовками, а не глазами в браузере.
llms.txt есть, но отдаётся не тем MIME-типом
Файл может открываться, но отдаваться как text/plain. Не смертельно, но лучше явно указать text/markdown. Особенно если вы уже добавляете его в Link header с type=»text/markdown».
api-catalog отдаётся как обычный файл
Для api-catalog лучше указать application/linkset+json. Иначе часть клиентов может воспринять его просто как непонятный JSON-файл без правильного смысла.
Markdown negotiation ломает обычный сайт
Это главный риск. Нельзя сделать так, чтобы обычный браузер начал получать Markdown вместо HTML. Поэтому обязательно проверяем оба сценария: обычный запрос и запрос с Accept: text/markdown.
Погоня за баллами вместо смысла
Самая вредная ошибка: пытаться закрыть все пункты любой ценой. Если у сайта нет MCP, OAuth, Agent Skills и коммерческих агентных сценариев, не надо их имитировать. Лучше честная инфраструктура, чем декоративная витрина для проверки.
Что можно сделать дальше
Следующий честный этап, если захочется поднять оценку выше, это read-only MCP-сервер для сайта. Например, маленький сервис на Python или Node.js, который умеет безопасно отдавать публичные данные.
Такой MCP-сервер мог бы:
- искать статьи по сайту;
- показывать свежие публикации;
- возвращать страницу услуг;
- отдавать прайс-лист;
- находить материалы по WordPress, Linux, DevOps и Python;
- работать только на чтение, без опасных действий.
Но это уже отдельный проект. Делать DNS discovery для MCP без самого MCP-сервера я не стал. На инфраструктуре лучше не играть в «а вдруг прокатит». Обычно прокатывает только до первого реального пользователя.
Зачем это нужно обычному владельцу WordPress-сайта
Пока это не обязательный стандарт, без которого сайт завтра исчезнет из поиска. Но направление уже видно. Сайты всё чаще будут читать не только браузеры и поисковые роботы, но и AI-агенты, ассистенты, IDE, браузерные помощники и сервисы автоматизации.
Если сайт хорошо структурирован, агенту проще понять его содержание. Если есть sitemap, RSS, llms.txt и понятные заголовки, меньше шансов, что модель вытащит не то, пропустит важную страницу или начнёт фантазировать по обрывкам HTML.
Для блога, сайта услуг или технического портфолио это новая форма инфраструктурной гигиены. Как sitemap, Open Graph, robots.txt и нормальные заголовки. Вчера казалось необязательной мелочью, сегодня уже помогает, завтра может стать привычной базой.
Вывод
Базовая подготовка WordPress-сайта к AI-агентам оказалась вполне подъёмной задачей. Никакой магии: статический llms.txt, аккуратный robots.txt, Link headers, api-catalog, RSS-фид и Markdown negotiation через Nginx.
Главное не ломать обычный сайт ради красивой проверки. Людям должен отдаваться HTML, агентам Markdown, поисковикам sitemap, а владельцу сайта спокойный сон. В моём случае схема получилась именно такой.
Считать это новым SEO? Частично да. Это ещё не замена нормальному контенту, техническому SEO и здравому смыслу. Но это уже важная настройка для эпохи, где сайт всё чаще читают не только глазами, но и агентами.
Как когда-то sitemap казался необязательной мелочью, а теперь без него сайт выглядит немного как сервер без бэкапа: вроде работает, но тревожно.
