Готовность к ИИ-агентам

Файл robots.txt умеет отвечать только на один вопрос: пускать робота на страницу или нет. Но «пустить почитать» и «разрешить обучать на этом нейросеть» — совершенно разные вещи, и второго вы пока не говорили никому. Здесь вы отвечаете отдельно на три вопроса: можно ли обучать модели на вашем контенте, можно ли показывать вас в поиске и можно ли пересказывать ваши тексты в ответах чат-ботов. Обычный расклад для бизнеса: поиск и ответы разрешить (это к вам приводит клиентов), обучение запретить.

—

В файле robots.txt добавьте строку вида «Content-Signal: ai-train=no, search=yes, ai-input=yes». Здесь ai-train — обучение нейросетей, search — показ в поиске, ai-input — пересказ ваших текстов в ответе ИИ. Значение yes разрешает, no запрещает. Строка действует на тот блок User-agent, внутри которого стоит.

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

—

Научите сервер различать, кто просит страницу. Если в запросе пришёл заголовок «Accept: text/markdown», отдавайте текстовую версию и указывайте тип text/markdown. Обязательно добавьте заголовок «Vary: Accept» — иначе кэш однажды покажет голый текст живому посетителю.

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

—

Положите файл robots.txt в корень сайта, чтобы он открывался по адресу вашсайт.ру/robots.txt. Внутри — блоки User-agent с правилами Allow и Disallow и строка Sitemap с полным адресом карты сайта. Отдавайте его как обычный текст. Проверьте, что по несуществующим адресам сервер отвечает ошибкой 404, а не подставляет главную страницу.

Карта сайта — это готовый перечень всего, что у вас есть. Без неё помощник ходит по ссылкам и видит только то, на что уже кто-то сослался. Сильнее всего страдает новое: свежий товар, недавняя статья, страница из раздела, куда ведёт одна ссылка из глубины меню. Формально они на сайте есть, а для помощника их не существует.

—

Создайте файл sitemap.xml со списком всех публичных страниц и укажите его полный адрес в robots.txt строкой «Sitemap:». Если страниц больше 50 тысяч, разбейте на несколько файлов и соберите их в один общий. Почти все системы управления сайтом умеют делать это сами — часто достаточно включить нужную настройку или поставить модуль.

В robots.txt обычно стоит одно правило «для всех» — звёздочка. Под него разом попадают и поисковик, и парсер картинок, и робот нейросети. То есть решения про ИИ вы не принимали: оно получилось само собой. А решения тут разные. Робот, который приводит к вам клиентов из чат-бота, нужен. Робот, который выкачивает каталог для обучения чужой модели, — вряд ли. Различить их можно, только назвав поимённо: этих правил вендоры придерживаются.

—

Добавьте в robots.txt отдельные блоки User-agent для конкретных роботов и задайте каждому свои правила. Основные: GPTBot (обучение OpenAI), OAI-SearchBot и ChatGPT-User (показ и переходы из ChatGPT), ClaudeBot, Google-Extended (обучение Google), PerplexityBot, CCBot, YandexAdditional. Общее правило со звёздочкой оставьте в конце как запасное.

Пункт нужен, только если у вас есть открытое API — способ получать данные сайта программно. Тогда помощнику надо как-то узнать, что оно вообще существует и где его описание. Иначе он будет добывать данные со страниц, хотя рядом лежит готовый и точный способ их получить. Если API у вас нет, спокойно пропускайте.

—

Положите по адресу /.well-known/api-catalog небольшой файл со ссылками на описание вашего API и на документацию к нему.

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

—

Настройте на главной странице отдачу заголовков Link со ссылками на важные ресурсы: describedby (описание), service-desc (описание API), alternate (версии материала), api-catalog. Делается на уровне веб-сервера, трогать код сайта не нужно. Служебные ссылки вроде стилей и иконок не в счёт — они есть у всех и помощнику ничего не дают.

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

—

Положите файл auth.md в корень сайта. Внутри простым текстом опишите: как зарегистрироваться, как войти, нужны ли ключи доступа и где их взять, сколько запросов в минуту допустимо. Проверьте, что файл отдаётся именно как текст, а не как оформленная страница сайта.

Продолжение предыдущего пункта, но для машин. Чтобы помощник вошёл в кабинет от имени клиента, ему нужно знать технические адреса вашей системы входа. Либо разработчик прописывает их руками для каждого сервиса, либо вы выкладываете один файл, и подключение настраивается само. Пункт имеет смысл, только если система входа у вас действительно есть — файл сам по себе ничего не открывает.

—

Опубликуйте файл /.well-known/oauth-authorization-server (или openid-configuration) с адресами вашей системы входа и обязательным полем issuer.

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

—

Опубликуйте файл /.well-known/oauth-protected-resource: в нём перечислено, какие разделы закрыты и какие пропуска для них годятся. Работает в паре с предыдущим пунктом.

Этот и следующие два пункта нужны, только если у вас на сайте есть свой ИИ-помощник — чат-бот, консультант, подборщик. Тогда чужие помощники должны уметь его найти и понять, о чём с ним вообще можно говорить. Визитка — это его анкета: как зовут, что умеет, по какому адресу обращаться. Если своего помощника нет, три пункта смело пропускайте.

—

Опубликуйте файл /.well-known/agent-card.json с именем помощника, описанием, списком возможностей и адресом для обращения.

Визитка говорит, кто ваш помощник. Список умений — что конкретно он делает: подбирает товар, считает доставку, оформляет возврат. Без него чужой помощник видит собеседника, но не понимает, с чем к нему можно прийти, и не приходит вовсе.

—

Опубликуйте список умений: у каждого — название, понятное описание и то, какие данные нужны для вызова.

Самый глубокий уровень: вместо того чтобы читать сайт, нейросеть вызывает ваши функции напрямую — «найди товар», «проверь остаток», «создай заявку». Данные всегда точные, потому что берутся из вашей системы, а не вычитываются со страницы. Требует настоящей разработки: нужен работающий сервер, одного файла мало.

—

Поднимите MCP-сервер с нужными функциями и опубликуйте его карточку по адресу /.well-known/mcp.json.

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

—

Опубликуйте набор ключей по адресу /.well-known/http-message-signatures-directory и настройте подпись исходящих запросов ваших роботов.

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

—

Объявите основные действия интерфейса как инструменты для помощника. Начните с поиска и фильтров — это самые частые сценарии.

Способ заявить о своих ИИ-помощниках в настройках домена, чтобы их находили ещё до захода на сайт. Работает быстрее файлов, но есть условие: без электронной подписи домена такую запись может подменить любой, кто оказался на пути запроса. Поэтому подпись здесь не пожелание, а обязательная часть.

—

Добавьте в настройках домена TXT-записи с адресами ваших помощников и включите DNSSEC — электронную подпись домена. Нужен доступ к панели управления доменом.

Когда клиент просит помощника «найди, где дешевле», тот идёт по магазинам и собирает цены со страниц. Получается медленно, а ошибается он там, где нельзя: берёт зачёркнутую цену, не замечает, что товара нет в наличии. Открытый каталог решает это: помощник получает ассортимент, цены и остатки в готовом виде, прямо из вашей системы.

—

Опубликуйте файл /.well-known/acp.json с адресами каталога и правилами работы с ним. Имеет смысл, только если за файлом стоит живая товарная база.

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

—

Добавьте раздел об оплате в визитку помощника и укажите свою роль — например, продавец. Сначала нужна сама визитка.

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

—

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

Если часть материалов платная, у помощника есть ровно два выхода: уйти ни с чем или искать обходной путь. Оба плохи. Третий появляется, когда есть понятное правило: вот цена, вот как заплатить, вот что открывается после оплаты. Тогда закрытый контент начинает приносить деньги и с этой стороны тоже.

—

Опубликуйте файл /.well-known/ucp.json с условиями доступа и порядком оплаты. Нужен работающий приём платежей, иначе это останется декларацией.

Здесь нет никакого файла с описанием — правило заложено в поведение сервера. На платный запрос он отвечает «нужна оплата», помощник платит и повторяет запрос. Подходит, когда цена считается за обращение, а не за месяц подписки: разовые расчёты, справки, выгрузки по запросу.

—

Подключите обработчик, который на защищённых адресах отвечает кодом 402 и платёжным заголовком. Понадобятся адрес расчётного сервиса и кошелёк.