Content-Signal в robots.txt: новая директива для контроля над контентом

Почему одного Allow/Disallow стало недостаточно

Еще несколько лет назад файл robots.txt казался предельно простым и понятным инструментом. Мы писали User-agent: Googlebot, затем Disallow: /admin/ или Allow: /public/ — и поисковик четко понимал границы дозволенного. Директива работала как шлагбаум: если доступ закрыт, бот даже не пытается зайти на страницу. Если открыт — смело идет туда, скачивает HTML, картинки, скрипты и использует их по своему усмотрению.

Но за последние два года контекст радикально изменился. Поисковые системы перестали быть единственными потребителями контента. На арену вышли десятки AI-ботов: GPTBot от OpenAI, ClaudeBot от Anthropic, PerplexityBot, Google-Extended, CCBot от Common Crawl и многие другие. И вот тут возникает фундаментальное противоречие.

Традиционный Allow отвечает на вопрос: «Может ли бот технически зайти на страницу и прочитать ее содержимое?». Но он ничего не говорит о том, что именно бот может сделать с этим содержимым после того, как скопирует его к себе на сервер. Раньше это не имело значения: поисковый бот индексировал страницу, показывал сниппет и ссылку в выдаче. Сегодня же один и тот же краулер может:

• проиндексировать страницу для поисковой выдачи (это обычно полезно);
• использовать текст как контекст для генерации ответа в чат-боте (спорно, но может приносить трафик);
• включить ваш контент в обучающий датасет для языковой модели (чаще всего нежелательно, так как это использование безвозмездно и безвозвратно).

Вы не можете закрыть доступ к странице для GPTBot, если хотите, чтобы он упоминал ваш сайт в поиске. Но вы совсем не хотите, чтобы ваша эксклюзивная аналитика стала частью обучающей выборки для ChatGPT. Стандартный Disallow не решает эту дилемму: он либо полностью запрещает боту доступ (и вы теряете упоминания), либо разрешает всё (и ваши тексты уходят в датасет). Именно для решения этой задачи и появилась новая директива — Content-Signal.

Откуда взялась директива Content-Signal

Content-Signal — это не официальный стандарт W3C и не обязательный протокол, который уже принят всеми. Речь идет о развивающейся конвенции, инициативе, которая была предложена в 2025 году. Связана эта работа с компанией Cloudflare и организацией contentsignals.org. Суть инициативы — создать простой и единый способ для владельцев сайтов сообщать краулерам не просто «можно/нельзя заходить», а «что именно можно делать с контентом после того, как вы его получили».

Почему это важно? Потому что сейчас каждый AI-провайдер пытается ввести собственные правила. У OpenAI есть свой файл с GPTBot и OAI-SearchBot, у Google — Google-Extended. Владельцу сайта приходится отслеживать десятки новых User-agent и прописывать для каждого отдельные правила. Content-Signal пытается унифицировать этот процесс: вместо того чтобы плодить новых ботов, мы даем старым ботам дополнительные инструкции в уже существующем файле robots.txt.

Важно понимать: это не финальная спецификация, а предложение. Стандарт еще не принят, и часть краулеров может игнорировать его. Но направление задано верное, и разбираться в синтаксисе нужно уже сейчас, чтобы быть готовым, когда поддержка станет массовой.

Три параметра Content-Signal: подробный разбор

Синтаксически директива выглядит как строка внутри блока User-agent. Она располагается рядом с классическими Allow и Disallow. Общий вид такой:

Content-Signal: search=yes, ai-input=yes, ai-train=no

Как видите, директива содержит три параметра, каждый из которых принимает значение yes или no. Разберем каждый параметр отдельно, поскольку они регулируют совершенно разные сценарии использования контента.

Параметр search: классическая индексация для поисковых систем

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

Представьте ситуацию: у вас есть сайт с платными статьями. Вы хотите, чтобы Google индексировал анонсы и первые абзацы, чтобы люди находили вас через поиск. При этом полный текст вы открываете только после оплаты. С помощью классического Disallow вы бы закрыли доступ боту вообще, и страницы исчезли бы из выдачи. С помощью Content-Signal: search=yes вы разрешаете боту зайти и прочитать страницу для индексации, но параллельно вы можете настроить параметры ai-input и ai-train так, чтобы он не использовал полный текст для других целей.

На практике, если вы ставите search=no, это фактически означает «не индексируй для поиска». Но в отличие от Disallow, бот все равно может зайти на страницу, если у него есть другие разрешенные цели (например, ai-input=yes). Это позволяет вам, скажем, кормить контентом PerplexityBot для ответов на вопросы пользователей, но скрывать страницу из обычной выдачи Google. Гибкость, которую не дает стандартный синтаксис.

Параметр ai-input: контекст для живых ответов ИИ (RAG)

Второй параметр — ai-input — пожалуй, самый интересный и спорный. Он регулирует использование вашего контента в системах Retrieval-Augmented Generation (RAG). Это когда языковая модель не переучивается на ваших данных, а в момент запроса пользователя ищет релевантные фрагменты в интернете (или в индексированной базе) и использует их как контекст для генерации ответа.

Простой пример. Пользователь спрашивает у Perplexity: «Какие лучшие практики SEO для сайтов на Next.js?». PerplexityBot находит вашу статью на example.ru, извлекает из нее несколько абзацев и на основе них формирует ответ, указывая источник. Это именно ai-input. Ваш контент не стал частью модели — модель просто прочитала его в момент запроса и использовала для ответа.

Кому и зачем это нужно? Если вы ведете информационный блог и хотите получать упоминания и ссылки из чат-ботов, вам выгодно разрешить ai-input=yes. Пользователи Perplexity или Bing Chat увидят ваш сайт как источник, и это может привести к переходам. Если же вы продаете уникальные данные, аналитику или экспертные материалы, которые пользователи должны читать на вашем сайте, а не получать выжимку в чате — вам стоит поставить ai-input=no. В этом случае бот не сможет цитировать ваш контент в живых ответах.

Важно понимать разницу между ai-input и ai-train. ai-input — это оперативное использование контента для конкретного ответа. Это как если бы вы дали сотруднику документ на минуту, чтобы он ответил на вопрос клиента. ai-train — это долгосрочное использование: контент попадает в память модели и влияет на все ее будущие ответы, даже спустя годы. Очевидно, что второе гораздо опаснее для авторов.

Параметр ai-train: включение в обучающие датасеты

Параметр ai-train — это красная линия для большинства издателей. Он указывает, разрешаете ли вы включать ваш контент в обучающие датасеты для языковых моделей. Если вы ставите ai-train=no, вы говорите: «Вы можете прочитать мою статью, чтобы найти информацию для ответа пользователю (если ai-input=yes), но вы не имеете права использовать ее для обучения вашей модели». Это принципиально важно, потому что обучение модели — это безвозвратное копирование. Ваш текст навсегда останется в весах модели, и вы не сможете его отозвать, даже если удалите страницу.

Рекомендация для большинства сайтов с уникальным контентом — ставить ai-train=no. Исключения составляют разве что сайты, которые сознательно хотят участвовать в обучении ИИ (например, вики-проекты или открытые базы знаний, но и там стоит хорошо подумать). Дело в том, что модели, обученные на ваших данных, могут в будущем конкурировать с вами, генерируя похожие тексты без ссылки на источник. Параметр ai-train — единственный способ на уровне robots.txt заявить о своем нежелании участвовать в этом процессе.

Обратите внимание: если вы ставите ai-train=no, но оставляете ai-input=yes и search=yes, это абсолютно валидная и логичная комбинация. Вы разрешаете поиск и цитирование в живых ответах, но запрещаете «запоминание» вашего контента моделью навсегда.

Полный пример robots.txt с разной политикой для разных ботов

Главная прелесть Content-Signal в том, что директива может быть разной для разных User-agent. Вы можете разрешить Googlebot индексировать всё и использовать для ИИ-ответов, но запретить GPTBot любое использование для обучения. Давайте посмотрим на практический пример файла robots.txt для вымышленного сайта example.ru, который публикует авторские аналитические статьи.

User-agent: *
Disallow:

# Основной поисковый бот Google
User-agent: Googlebot
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=no

# Специальный бот Google для AI-функций
User-agent: Google-Extended
Allow: /
Content-Signal: search=no, ai-input=yes, ai-train=no

# Бот OpenAI
User-agent: GPTBot
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=no

# Поисковый бот OpenAI (для упоминаний в поиске)
User-agent: OAI-SearchBot
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=no

# Бот Perplexity
User-agent: PerplexityBot
Allow: /
Content-Signal: search=yes, ai-input=yes, ai-train=no

# Бот Common Crawl (сбор данных для обучения)
User-agent: CCBot
Disallow: /
Content-Signal: search=no, ai-input=no, ai-train=no

Давайте разберем, что здесь происходит. Для всех ботов, кроме CCBot, мы разрешаем доступ (Allow: /). Для Googlebot мы разрешаем индексацию и использование в ИИ-ответах, но запрещаем обучение. Для Google-Extended (который питает функции SGE и AI Overviews) мы запрещаем обычную индексацию (search=no), но разрешаем использование как контекста для ответов — это тонкий момент, который позволяет вам появляться в AI-выдаче Google, но не в обычных синих ссылках, если вам это зачем-то нужно.

Для GPTBot и OAI-SearchBot политика схожая: поиск разрешен, цитирование в ответах разрешено, обучение запрещено. А вот CCBot, который собирает данные для Common Crawl (огромного датасета, который используется для обучения многих моделей), мы закрываем полностью через Disallow и дополнительно дублируем запрет через Content-Signal. Это пример грамотной страховки: если бот не понимает новую директиву, он хотя бы увидит Disallow и не зайдет. Если же он понимает Content-Signal — он увидит явный запрет на все три действия.

Обратите внимание, что директива Content-Signal не заменяет Allow/Disallow, а дополняет их. Вы должны по-прежнему четко указывать, может ли бот технически зайти на сайт. Content-Signal работает только в паре с разрешением доступа.

Технически ли это работает уже сейчас

Теперь самое время быть честными с вами, как мы всегда это делаем. Content-Signal — это не магическая кнопка, которая мгновенно защитит ваш контент от всех ИИ-краулеров. На данный момент соблюдение этой директивы не гарантировано технически. Это добровольная конвенция.

Что это значит на практике? Крупные провайдеры моделей (OpenAI, Anthropic, Google) публично сигнализировали о готовности поддерживать подобные инициативы и уважать сигналы владельцев сайтов. Они заинтересованы в том, чтобы не плодить юридические споры и соблюдать пожелания издателей, иначе они рискуют потерять доступ к качественному контенту в интернете. Однако на момент написания этой статьи далеко не все краулеры реально читают и уважают Content-Signal. Часть ботов, особенно мелких или неизвестных, продолжает работать по старинке, игнорируя любые директивы, кроме классических Allow/Disallow.

Более того, даже те боты, которые заявляют о поддержке, могут интерпретировать параметры по-своему. Стандарт находится в стадии обсуждения, и не исключено, что финальная спецификация будет отличаться от текущих предложений. Поэтому мы настоятельно рекомендуем использовать Content-Signal не как единственную линию обороны, а как дополнительный слой защиты.

Ваша стратегия должна выглядеть так:

• Для абсолютно нежелательных ботов (например, CCBot) используйте классический Disallow — это работает уже сейчас.
• Для ботов, с которыми вы готовы работать, но с ограничениями, используйте Content-Signal в дополнение к Allow.
• Регулярно проверяйте логи сервера: если вы видите, что GPTBot или PerplexityBot качают контент, но при этом игнорируют ваши Content-Signal настройки, вы можете либо ужесточить правила до Disallow, либо обратиться к провайдеру через веб-формы для владельцев сайтов.

Помните: robots.txt — это не файрвол. Это инструкция для добросовестных ботов. Злоумышленники и просто недобросовестные скрейперы могут игнорировать любой файл robots.txt. Content-Signal не решает проблему пиратского копирования, но он дает вам легальный рычаг давления на крупные компании, которые не хотят судебных исков и публичных скандалов.

Частые ошибки синтаксиса

Раз директива новая и еще не до конца стандартизирована, легко допустить ошибку в написании. Самое печальное, что ошибка в одну букву приведет к тому, что бот просто проигнорирует вашу директиву, и вы будете думать, что защищены, хотя на самом деле нет. Перечислим самые частые опечатки, которые мы встречаем при аудите сайтов.

Ошибка 1: лишняя буква S в конце

Многие пишут Content-Signals вместо Content-Signal. Это логичная ошибка, так как речь идет о сигналах (во множественном числе). Но синтаксис строго фиксирован: только единственное число.

Неправильно:

Content-Signals: search=yes, ai-input=yes

Правильно:

Content-Signal: search=yes, ai-input=yes

Ошибка 2: неправильный регистр букв

Директива чувствительна к регистру. Некоторые пишут content-signal (все строчные) или Content-Signal с маленькой буквы в середине. Это не работает. Только заглавные C и S в начале слов.

Неправильно:

content-signal: search=yes
Content-signal: search=yes
CONTENT-SIGNAL: search=yes

Правильно:

Content-Signal: search=yes

Ошибка 3: слитное написание

Встречается вариант ContentSignal — без дефиса. Это тоже синтаксическая ошибка.

Неправильно:

ContentSignal: search=yes

Правильно:

Content-Signal: search=yes

Ошибка 4: неправильные значения параметров

Параметры принимают только строго yes или no. Никаких true/false, 1/0, on/off или maybe быть не должно. Также нельзя пропускать значение или ставить пустую строку.

Неправильно:

Content-Signal: search=true, ai-input=1, ai-train=off

Правильно:

Content-Signal: search=yes, ai-input=yes, ai-train=no

Ошибка 5: неверные разделители

Параметры разделяются запятой и пробелом. Некоторые ставят точку с запятой или просто пробел. Это ломает парсинг. Важно: после запятой обязателен пробел.

Неправильно:

Content-Signal: search=yes; ai-input=yes
Content-Signal: search=yes ai-input=yes
Content-Signal: search=yes,ai-input=yes

Правильно:

Content-Signal: search=yes, ai-input=yes

Если вы не уверены в правильности написания, лучше используйте наш инструмент Проверка Content-Signal, который автоматически найдет директиву в вашем robots.txt, проверит синтаксис и валидность значений. Он подскажет, есть ли опечатки и корректно ли вы построили строку.

Кому эта директива особенно важна

Хотя Content-Signal потенциально полезен всем владельцам сайтов, есть категории проектов, для которых эта директива критически важна.

Издатели и новостные порталы. Если вы зарабатываете на рекламе и подписке, для вас критически важно, чтобы пользователи приходили на сайт и читали контент в оригинале. Если GPT или Perplexity будут пересказывать ваши новости в чате, пользователи перестанут кликать по ссылкам. Установка ai-input=no и ai-train=no — это способ защитить свою бизнес-модель. Конечно, это не остановит всех, но даст вам аргумент при разбирательстве с крупными платформами.

Сайты с платным контентом. Например, финансовые аналитические платформы, закрытые базы данных, курсы. Здесь вообще недопустимо, чтобы модель «выучила» ваш контент и потом пересказывала его бесплатно. Для таких сайтов рекомендуется максимально строгая политика: search=yes (чтобы вас находили в поиске), а вот ai-input=no и ai-train=no должны стоять железобетонно.

YMYL-темы (Your Money or Your Life). Это сайты о здоровье, финансах, юридических вопросах, безопасности. Контент из этой сферы особенно опасен тем, что его пересказ моделью может навредить пользователю. Если модель неточно перескажет рекомендации врача или юридическую консультацию, последствия могут быть серьезными. Поэтому владельцы таких сайтов должны четко запрещать использование контента для обучения моделей (ai-train=no), а лучше и для живых ответов (ai-input=no), оставляя только классическую индексацию. Это защитит и вас, и пользователей, которые не получат искаженную информацию из третьих рук.

Если ваш сайт относится хотя бы к одной из этих категорий, мы рекомендуем не откладывать внедрение Content-Signal в долгий ящик. Лучше настроить его сейчас, даже если поддержка не полная, чем потом пытаться бороться с последствиями использования вашего контента моделями, которые уже обучились на ваших данных.

Как проверить Content-Signal у себя

Внедрение директивы — это половина дела. Вторую половину составляет проверка: корректно ли вы написали синтаксис, не допустили ли опечаток, всем ли ботам прописали нужные политики. Вручную это делать утомительно, особенно если в файле robots.txt десятки блоков User-agent.

Мы подготовили для вас специализированный инструмент Проверка Content-Signal. Он работает просто:

• Вы указываете URL вашего сайта или вставляете содержимое файла robots.txt.
• Инструмент парсит файл, находит все блоки User-agent и ищет в них директиву Content-Signal.
• Проверяется корректность синтаксиса: правильное написание названия директивы (не Content-Signals, не content-signal), отсутствие опечаток в параметрах.
• Проверяется валидность значений: только yes/no, правильные разделители.
• На выходе вы получаете отчет: где директива найдена и корректна, где отсутствует, где есть ошибки с указанием конкретной проблемы.

Также рекомендуем обратить внимание на наш более общий инструмент robots.txt для AI, который помогает сгенерировать файл с нуля с учетом всех современных AI-краулеров и директив, включая Content-Signal. Он подскажет, какие User-agent стоит добавить (GPTBot, ClaudeBot, PerplexityBot, Google-Extended и другие), и поможет настроить политики для каждого.

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

FAQ: пять частых вопросов о Content-Signal

Вопрос 1: Является ли Content-Signal официальным стандартом, и обязаны ли боты его соблюдать?

Нет, на данный момент это не официальный стандарт. Это развивающаяся конвенция, предложенная в 2025 году при участии Cloudflare и организации contentsignals.org. Соблюдение директивы добровольное. Крупные провайдеры заявляют о поддержке, но на практике не все краулеры ее читают. Поэтому мы советуем не полагаться только на Content-Signal, а комбинировать его с классическими Disallow для нежелательных ботов.

Вопрос 2: В чем разница между Disallow и Content-Signal: search=no?

Disallow запрещает боту технически заходить на страницу и читать ее содержимое. Content-Signal: search=no запрещает использовать содержимое для поисковой индексации, но при этом разрешает боту зайти на страницу, если у него есть другие разрешенные цели (например, ai-input=yes). Это более гибкий механизм. Если вы хотите полностью закрыть доступ — используйте Disallow. Если вы хотите разрешить доступ для ИИ-цитирования, но запретить появление в поиске — используйте Content-Signal.

Вопрос 3: Что будет, если я напишу Content-Signal с ошибкой, например Content-Signals?

Бот не поймет директиву и проигнорирует ее. В результате будет действовать политика по умолчанию, которая обычно разрешает все, что не запрещено явно через Disallow. То есть ваш контент может использоваться для обучения моделей без ограничений, даже если вы думали, что защитились. Поэтому так важна проверка синтаксиса через наш инструмент.

Вопрос 4: Могу ли я использовать Content-Signal для разных ботов по-разному?

Да, это одна из ключевых особенностей директивы. Вы можете прописать в блоке User-agent: GPTBot одни значения (например, ai-train=no), а в блоке User-agent: PerplexityBot — другие (ai-input=yes). Это позволяет выстраивать гибкую стратегию взаимодействия с разными краулерами.

Вопрос 5: Защищает ли Content-Signal от копирования контента скрейперами?

Нет. Content-Signal, как и весь robots.txt, работает только с добросовестными ботами, которые уважают инструкции. Скрейперы-злоумышленники игнорируют любые правила. Для защиты от них нужны другие механизмы: анализ IP в логах, капча, динамическая подгрузка контента. Content-Signal — это инструмент для легального взаимодействия с крупными AI-компаниями, которые хотят избежать юридических проблем.

Внедряйте Content-Signal уже сейчас, чтобы быть готовыми к будущему, в котором правила игры с AI-краулерами станут более жесткими и формализованными. Это не панацея, но необходимый элемент современной стратегии управления цифровыми активами.