robots.txt и AI-боты: обучение, цитирование, проверка

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

Чем ИИ-краулер отличается от поискового робота

Механика та же: GET по списку адресов, разбор HTML, сохранение. Отличается цель, а вместе с ней — последствия запрета.

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

• Обучение. Массовая выкачка в корпус, на котором тренируют модель. Влияние на конкретный ответ проследить невозможно: между обходом и релизом модели проходят месяцы, а внутри модели ваш текст не хранится как документ.
• Индекс для ответов. Бот строит поисковую базу ассистента. Здесь связь прямая: попали в базу — можете быть процитированы со ссылкой, выпали — не можете.
• Загрузка по запросу пользователя. Человек дал ассистенту ссылку, тот пошёл её открывать прямо сейчас. Никакого индекса, никакого обучения — разовая выкачка ради одного ответа.

Смешивать эти три класса в одном решении «пускать / не пускать» — самая дорогая ошибка в теме. Формально это один и тот же User-agent в одном и том же файле, по сути — три разных договора. Как ИИ-агенты разбирают полученный HTML, разобрано отдельно: как ИИ-краулеры читают сайты.

robots.txt — договорённость, а не барьер. Добросовестный оператор её соблюдает, недобросовестный игнорирует и ничего за это не получает. Технический запрет живёт на уровне веб-сервера и WAF, а не в текстовом файле.

Кто обучает модель, а кто отвечает в реальном времени: таблица агентов

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

Токен User-agent	Оператор	Класс	Что означает запрет
GPTBot	OpenAI	Обучающий обход	Контент не уйдёт в обучающие наборы; на цитирование не влияет
OAI-SearchBot	OpenAI	Индекс для ответов	Сайт не попадёт в поисковую базу ассистента
ChatGPT-User	OpenAI	Загрузка по запросу	Ассистент не откроет вашу ссылку, даже если её дал ваш клиент
ClaudeBot	Anthropic	Обход	Основной краулер Anthropic не будет ходить по сайту
Claude-SearchBot	Anthropic	Индекс для ответов	Сайт не попадёт в поисковую базу ассистента
Claude-User	Anthropic	Загрузка по запросу	Ассистент не откроет ссылку по просьбе пользователя
PerplexityBot	Perplexity	Индекс для ответов	Выпадение из источников сервиса
Perplexity-User	Perplexity	Загрузка по запросу	Разовые переходы по ссылке не сработают
Google-Extended	Google	Токен управления	Отказ от использования в ИИ-продуктах Google; поиск не затрагивается
Googlebot	Google	Поисковый индекс	Полное исчезновение из Поиска — а с ним и из построенных поверх него ИИ-ответов
Bingbot	Microsoft	Поисковый индекс	Исчезновение из Bing и из надстроек над его индексом
Applebot	Apple	Поиск и ассистент	Выпадение из поисковых поверхностей Apple
Applebot-Extended	Apple	Токен управления	Отказ от использования данных в обучении моделей Apple
CCBot	Common Crawl	Открытый корпус	Страницы не попадут в публичный архив, которым пользуются многие
Meta-ExternalAgent	Meta	Обход для ИИ	Контент не уйдёт в продукты и наборы данных оператора
Amazonbot	Amazon	Обход	Выпадение из сервисов оператора
Bytespider	ByteDance	Обход	Выпадение из продуктов оператора

Две строки в этой таблице требуют отдельного внимания.

Google-Extended и Applebot-Extended — это не краулеры. Своих запросов они не делают и в логах вы их не найдёте никогда. Это управляющие токены: обход выполняет обычный Googlebot или Applebot, а токен говорит, разрешено ли использовать полученное в ИИ-продуктах оператора. Отсюда частая ложная тревога: «поставили Disallow для Google-Extended, а он всё равно ходит» — не ходит, вы видите в логах другой агент.

Пользовательские агенты (ChatGPT-User, Claude-User, Perplexity-User) — это не обход сайта. Это ситуация, когда живой человек дал ассистенту ссылку: свою же документацию, свою же карточку товара, свою же статью. Запрет здесь не защищает контент — он ломает сценарий, в котором ваш клиент пытается разобраться в вашем продукте.

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

Как разрешить цитирование, но запретить обучение

Это самая ходовая конфигурация: контент не уходит в обучающие наборы, но сайт остаётся источником, на который ссылаются в ответах.

# --- обучающий обход: закрыт ---
User-agent: GPTBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# --- индекс для ответов и цитирования: открыт ---
User-agent: OAI-SearchBot
Allow: /
Disallow: /admin/
Disallow: /cart/
Disallow: /search

User-agent: Claude-SearchBot
Allow: /
Disallow: /admin/
Disallow: /cart/
Disallow: /search

User-agent: PerplexityBot
Allow: /
Disallow: /admin/
Disallow: /cart/
Disallow: /search

# --- загрузка по прямой просьбе пользователя: открыта ---
User-agent: ChatGPT-User
Allow: /

User-agent: Claude-User
Allow: /

User-agent: Perplexity-User
Allow: /

# --- всё остальное ---
User-agent: *
Disallow: /admin/
Disallow: /cart/
Disallow: /search
Disallow: /*?utm_

Sitemap: https://example.com/sitemap.xml

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

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

Как сопоставляются группы и где на этом ошибаются

Протокол исключений для роботов описан в RFC 9309, и в нём есть правило, которое ломает больше конфигураций, чем все опечатки вместе взятые: краулер применяет ровно одну группу — ту, что совпала с его именем. Группа User-agent: * используется только тогда, когда ни одна именная группа не подошла. Правила не наследуются и не складываются.

Посмотрите на этот файл глазами GPTBot:

User-agent: *
Disallow: /admin/
Disallow: /internal/

User-agent: GPTBot
Allow: /

Автор был уверен, что закрыл админку от всех, а GPTBot просто дополнительно разрешил. На деле GPTBot читает только свою группу, видит в ней Allow: / и получает доступ в том числе к /admin/ и /internal/. Служебные пути нужно повторить внутри именной группы — как в конфигурации выше.

Остальные правила разбора, которые стоит держать в голове:

• Несколько строк User-agent подряд образуют одну группу. Правила после них применяются ко всем перечисленным агентам. Пустая строка между User-agent и правилами разрывает группу — и правила уходят не туда, куда задумано.
• Имена агентов сравниваются без учёта регистра, а вот пути в Allow и Disallow — с учётом. /Blog/ и /blog/ — разные пути.
• При конфликте выигрывает более длинное правило. Allow: /blog/public/ перекрывает Disallow: /blog/ для вложенного каталога.
• Файл действует на схему, хост и порт. https://example.com/robots.txt ничего не говорит ни про http://, ни про https://shop.example.com/. Каждому поддомену — свой файл.
• Crawl-delay не входит в стандарт. Часть операторов его учитывает, часть игнорирует. Для управления нагрузкой надёжнее ограничение частоты на веб-сервере.
• Файл кэшируется. Правки подхватываются не мгновенно — обычно в пределах суток. Ждать эффекта «через пять минут» бессмысленно.

Отдельно про аварии: недоступный robots.txt — 500-я ошибка или таймаут — многие краулеры трактуют как «запрещено всё». Файл, который генерируется приложением, падает вместе с приложением. Отдавайте его статикой и следите за кодом ответа: мониторинг здесь дешевле разбора последствий.

Базовый синтаксис файла и общие правила для поисковых роботов — в гайде по robots.txt. Здесь мы разбираем только специфику ИИ-агентов.

Почему Disallow не удаляет то, на чём уже обучились

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

К этому добавляются три обстоятельства, которые не лечатся файлом в корне сайта:

• Копии. Ваш текст мог попасть в открытые архивы, агрегаторы, зеркала и перепечатки. Их robots.txt вы не контролируете.
• Цитаты. Пересказ вашей позиции в чужой статье — уже чужой контент, и он останется в корпусе.
• Срок. Между обходом и релизом модели проходят месяцы. Запрет, поставленный после релиза, не мог повлиять на него по определению.

Отсюда важная асимметрия, которую стоит учитывать при планировании:

Что закрываете	Когда наступит эффект	Проверяемость	Обратимость
Обучающий обход	Отложенно, к следующему циклу обучения	Проверить нельзя: связь «обход → ответ» непрослеживаема	Прошлое не откатывается
Индекс для ответов	Быстро, по мере переобхода	Видно по исчезновению ссылок на сайт в ответах	Полная: сняли запрет — вернулись
Загрузка по запросу пользователя	Немедленно	Видно сразу: ассистент сообщает, что доступ закрыт	Полная
Поисковый робот	Быстро	Видно по выпадению из выдачи	Полная, но с задержкой на переиндексацию

Читается это так: запрет обучения — ставка на будущее с непроверяемым результатом, запрет индексных и пользовательских агентов — мгновенная и хорошо заметная потеря. Если контент — ваш продукт (исследования, базы, платные материалы), первое оправданно. Если контент — способ привлечь клиента, второе почти всегда убыточно.

Про то, как сайт вообще попадает в ИИ-ответы и что на это влияет кроме доступа, — в материалах как попасть в ИИ-ответы и GEO.

robots.txt, noindex и X-Robots-Tag: что чем управляет

Эти механизмы регулярно путают, а они решают разные задачи и работают на разных этапах.

Механизм	Что говорит боту	Нужен ли доступ к странице	Где живёт
Disallow в robots.txt	«Не запрашивай этот адрес»	Нет — бот не скачивает страницу вовсе	Файл в корне хоста
noindex в meta-теге	«Скачай, но не показывай в выдаче»	Да — иначе директиву никто не прочитает	HTML-код страницы
X-Robots-Tag: noindex	То же, но работает и для не-HTML	Да	HTTP-заголовок ответа
Content-Signal	«Вот разрешённые виды использования»	Нет	Строка в robots.txt

Из таблицы следует главная ловушка: Disallow и noindex вместе не работают. Закрытую в robots.txt страницу бот не скачивает — значит, не видит noindex внутри неё. Адрес при этом может остаться в выдаче как ссылка без описания: робот знает, что страница существует, но не знает, что на ней. Нужно убрать из индекса — оставьте доступ и отдайте noindex.

Заголовок X-Robots-Tag удобен там, где HTML-тег поставить некуда: PDF, изображения, выгрузки. Проверить, что заголовок реально отдаётся, можно анализатором HTTP-заголовков:

# видит ли бот директивы индексации в заголовках
curl -sSI -A 'GPTBot' https://example.com/docs/manual.pdf \
  | grep -iE '^(x-robots-tag|content-type|http/)'

# и что отдаёт сам robots.txt — код ответа важнее содержимого
curl -sSI https://example.com/robots.txt | head -1
curl -sS https://example.com/robots.txt | head -40

Отдельно про нестандартные токены вроде noai и noimageai в X-Robots-Tag: их продвигают отдельные площадки, в стандарт они не входят, поддержка не гарантирована. Ставить не вредно, рассчитывать на них как на механизм защиты — нельзя.

Content-Signal: что это даёт и чего не даёт

Идея в том, чтобы вместо грубого «пускать / не пускать» декларировать разрешённые виды использования: поиск, обучение модели, использование как контекста для ответа. Синтаксис размещается в robots.txt рядом с обычными директивами:

User-agent: *
Content-Signal: search=yes, ai-train=no, ai-input=yes
Allow: /
Disallow: /admin/

Sitemap: https://example.com/sitemap.xml

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

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

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

Как проверить по логам, кто реально приходил

Файл в корне описывает намерение. Логи описывают факт, и они почти всегда расходятся. Начните с того, кто вообще к вам ходит:

# топ ИИ-агентов за период, по журналу nginx в формате combined
grep -Ei 'gptbot|oai-searchbot|chatgpt-user|claudebot|claude-user|claude-searchbot|perplexitybot|perplexity-user|ccbot|bytespider|amazonbot|meta-externalagent|applebot' \
    /var/log/nginx/access.log \
  | awk -F'"' '{print $6}' \
  | sed -E 's/.*(GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|CCBot|Bytespider|Amazonbot|Meta-ExternalAgent|Applebot).*/\1/I' \
  | sort | uniq -c | sort -rn

Затем — что именно бот берёт и с каким кодом ответа. Столбцы $9 и $7 в формате combined — это статус и запрошенный путь:

# какие страницы и с каким статусом отдаются конкретному агенту
grep -i 'gptbot' /var/log/nginx/access.log \
  | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head -20

# сколько уникальных адресов представилось этим агентом
grep -i 'claudebot' /var/log/nginx/access.log \
  | awk '{print $1}' | sort -u | wc -l

# суточная динамика: не растёт ли нагрузка от одного агента
grep -i 'perplexitybot' /var/log/nginx/access.log \
  | awk -F'[:[]' '{print $2, $3}' | sort | uniq -c

Что читать в результатах:

• Ноль запросов от агента, которого вы открыли. Это нормально: обход не гарантирован. Но проверьте код ответа robots.txt — при 5xx вас закрыли для всех.
• Запросы от агента, которого вы закрыли. Три причины: кэш файла ещё не обновился, файл отдаётся с ошибкой, либо перед вами не тот, за кого он себя выдаёт. Последнее проверяется в следующем разделе.
• Много 404 и 301 у бота. Он ходит по устаревшим ссылкам — проверьте карту сайта и битые ссылки.
• Резкий рост запросов. Обход тяжёлых страниц может стоить заметных ресурсов — здесь помогает ограничение частоты, а не запрет.

Если логи читаются неудобно или их формат отличается от стандартного, начните с разбора логов nginx. Учтите ещё одно: за обратным прокси в логе окажется адрес прокси, а не бота — за настоящим адресом идите в заголовок X-Forwarded-For.

Поддельные User-Agent и проверка обратным DNS

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

Надёжный способ подтверждения — прямое подтверждение обратной зоны (FCrDNS): по адресу запрашивается имя, затем имя разрешается обратно и сравнивается с исходным адресом. Подделать это без контроля над обратной зоной провайдера нельзя.

# 1. какое имя объявляет адрес
dig +short -x 203.0.113.10

# 2. разрешается ли это имя обратно в тот же адрес
dig +short crawler.example-operator.com

# 3. то же самое пакетно для всех адресов, представившихся ботом
grep -i 'gptbot' /var/log/nginx/access.log \
  | awk '{print $1}' | sort -u \
  | while read ip; do
      name=$(dig +short -x "$ip" | head -1)
      back=$(dig +short "${name%.}" | head -1)
      if [ -n "$name" ] && [ "$ip" = "$back" ]; then
        echo "$ip CONFIRMED $name"
      else
        echo "$ip UNCONFIRMED ${name:-no-ptr}"
      fi
    done

Важная оговорка, чтобы не наделать ложных выводов: UNCONFIRMED не равно «подделка». Часть операторов обратные зоны для своих краулеров не публикует, а вместо этого выкладывает списки IP-диапазонов в машиночитаемом виде. Тогда проверка сводится к принадлежности адреса официальному диапазону оператора, а не к обратному DNS. Прежде чем блокировать по результату скрипта, посмотрите, что именно публикует конкретный вендор.

Устройство обратных зон и записей PTR разобрано в материале про обратный DNS.

Никогда не блокируйте по одному лишь совпадению строки User-agent — так вы наказываете добросовестных и не задеваете тех, ради кого всё затевалось. Блокировка по подтверждённому адресу работает, блокировка по имени — только против ленивых.

Жёсткая блокировка: nginx, Apache и ограничение частоты

Если решение принято и оно должно исполняться, а не декларироваться, — уровень исполнения находится на веб-сервере. Для nginx: карта в контексте http и проверка в нужном месте.

# http-контекст
map $http_user_agent $ai_blocked {
    default                  0;
    "~*gptbot"               1;
    "~*ccbot"                1;
    "~*bytespider"           1;
    "~*meta-externalagent"   1;
}

# server-контекст
if ($ai_blocked) {
    return 403;
}

Для Apache то же самое средствами mod_setenvif и mod_authz_core:

BrowserMatchNoCase "GPTBot"     ai_blocked
BrowserMatchNoCase "CCBot"      ai_blocked
BrowserMatchNoCase "Bytespider" ai_blocked

<RequireAll>
    Require all granted
    Require not env ai_blocked
</RequireAll>

Три замечания к обоим вариантам:

• Проверка по строке User-agent обходится за секунду. Она отсекает добросовестные обходы, то есть ровно тех, кто и так соблюдал бы robots.txt. Против намеренного сбора нужен другой уровень — правила межсетевого экрана уровня приложений и поведенческие сигналы.
• Часто задача не «не пускать», а «не дать положить сервер». Тогда правильный инструмент — ограничение частоты запросов и корректный ответ 429 с заголовком Retry-After, а не 403. Добросовестный краулер понимает 429 и сбавляет темп.
• 403 в ответ поисковому роботу — способ выпасть из выдачи целиком. Проверяйте регулярное выражение: ~*bot отлично ловит и Googlebot.

Частые ошибки: симптом, причина, проверка, фикс

Симптом	Причина	Как проверить	Фикс
Бот игнорирует общий блок User-agent: *	У него есть именная группа, общая не применяется	Найти в файле группу с именем этого агента	Продублировать служебные Disallow в именной группе
Агент закрыт, но продолжает ходить	Кэш файла, ошибка отдачи или подделка имени	Код ответа robots.txt плюс проверка обратной зоной	Отдавать файл статикой, подождать сутки, блокировать по адресу
Сайт пропал из ИИ-ответов после правки	Закрыли индексный или пользовательский агент вместо обучающего	Сверить класс каждого токена по таблице выше	Вернуть доступ индексным и пользовательским агентам
В логах ноль запросов от Google-Extended	Это управляющий токен, а не краулер	Искать в логах Googlebot	Ничего не чинить — так и задумано
Правила не действуют на поддомен	Файл действует на схему, хост и порт	Открыть robots.txt самого поддомена	Свой файл на каждый хост
robots.txt отдаёт 500 во время аварии	Файл генерируется приложением	curl -sSI по адресу файла	Статическая отдача, независимая от бэкенда
Закрыли всё случайно	Disallow: / в общей группе после отладки	Проверка файла инструментом до деплоя	Проверка robots.txt в конвейере сборки
Бот выкачивает тяжёлые страницы, растёт нагрузка	Нет ограничения частоты	Топ путей агента из логов	Лимит частоты и ответ 429, а не 403
Блокировка задела поисковых роботов	Слишком широкое регулярное выражение	Запрос с -A 'Googlebot' и проверка кода	Точные имена вместо ~*bot

Как проверить на enterno.io

• Проверка robots.txt — разбирает файл по группам ровно так, как это делает краулер, и показывает, какие правила применятся к конкретному агенту.
• Проверка готовности к ИИ — комплексная оценка: доступ, структура, разметка, карта контента.
• Проверка llms.txt — валидация карты контента для моделей.
• Анализ HTTP-заголовков — X-Robots-Tag, коды ответа, редиректы для разных агентов.
• Мониторинг — следить за доступностью robots.txt: 500-я на этом адресе стоит дороже, чем на большинстве страниц.
• SEO-аудит — проверить, что вместе с ИИ-агентами вы не закрыли поисковых роботов.

Чеклист

• Каждый токен в файле отнесён к классу: обучение, индекс, загрузка по запросу пользователя.
• Решение по каждому классу принято осознанно, а не скопировано из чужого файла.
• Служебные пути продублированы в каждой именной группе, а не только в User-agent: *.
• Sitemap: указан; карта сайта отдаётся со статусом 200.
• robots.txt отдаётся статикой и не зависит от работоспособности приложения.
• Код ответа robots.txt под мониторингом.
• У каждого поддомена свой файл.
• Логи проверены: пришедшие агенты сопоставлены с ожидаемыми.
• Подозрительные агенты подтверждены обратной зоной или официальным списком диапазонов.
• Для защиты от нагрузки используется ограничение частоты и 429, а не 403.
• Регулярные выражения в блокировках не задевают поисковых роботов.
• Файл проверен инструментом до деплоя, а не после жалоб.

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

Соблюдают ли ИИ-боты robots.txt?

Крупные операторы декларируют соблюдение и в основном его выполняют — им дороже репутационный ущерб, чем ваш контент. Мелкие и намеренно недобросовестные сборщики файл игнорируют, и никакого наказания за это не предусмотрено. Поэтому robots.txt — инструмент управления добросовестными, а не защиты от всех.

Заблокирует ли Google-Extended мой обычный поиск?

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

Стоит ли блокировать всех ИИ-ботов подряд?

Почти никогда. Это одно движение, которое одновременно защищает от обучения (эффект отложенный и непроверяемый) и убирает вас из цитирования (эффект немедленный и заметный). Разумная развилка проходит по классу агента, а не по всему списку сразу.

Что делать с CCBot?

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

Работает ли Content-Signal сейчас?

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

Можно ли удалить свой контент из уже обученной модели?

Средствами robots.txt — нет: файл управляет будущими обходами, а не содержимым выпущенной модели. Если вопрос принципиальный, смотрите формы отзыва и правовые процедуры конкретного оператора; это область не веб-сервера, а договорённостей и права.

Нужен ли llms.txt, если robots.txt уже настроен?

Это разные слои: robots.txt отвечает на вопрос «кому можно», llms.txt — на вопрос «что здесь главное». Второй не заменяет первый и не открывает доступ сам по себе. Подробности — в гайде по llms.txt.

Что дальше: базовый гайд по robots.txt, как ИИ-краулеры читают сайты, разметка Schema.org для ИИ-поиска, чеклист готовности к ИИ-поиску, как получать цитирования.

Проверить robots.txt по группам агентов →