llms.txt и его очень узкая задача

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

Я бы не включал llms.txt в план роста видимости в ИИ как отдельный проект. Я бы относился к нему как к дешевой экспериментальной части издательской инфраструктуры: генерировал из уже поддерживаемых источников, следил за точностью, измерял запросы и удалял, если расходы на поддержку превышают наблюдаемую пользу. Разница важна, потому что команды любят выпускать заметный новый файл, оставляя сломанными доступ для краулеров, серверный рендеринг, канонические страницы и качество документации.

llms.txt дает готовому читателю отобранную карту

Файл объясняет читателю, что это за сайт или проект, и направляет его к выбранным ресурсам. Предложение Джереми Ховарда на llmstxt.org размещает файл по адресу /llms.txt и задает намеренно простую структуру Markdown: один обязательный H1, необязательное краткое описание в цитате, необязательный поясняющий текст и разделы H2 со списками подписанных адресов и описаниями. Раздел Optional отмечает материалы, которые читатель может пропустить при ограниченном контексте.

Такая конструкция решает проблему ориентации. Сайт с документацией может содержать руководства, справочники API, заметки о миграции, сгенерированные страницы, архивные версии и тысячи навигационных ссылок. Агент, который уже знает о файле, получает короткий список от автора, прежде чем тратить запросы и контекст на остальной сайт. Разработчик также может прямо попросить агента для программирования загрузить файл. В таком процессе пользу дает отбор, а не само имя файла.

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

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

Он не управляет краулингом и не выдает разрешения

У llms.txt нет функций контроля доступа. Строка в нем не разрешит вход заблокированному боту, не запретит доступ обучающему краулеру, не исключит контент из обучения модели, не задаст частоту запросов и не даст разрешение на повторное использование. Для управления доступом краулера применяйте механизм из документации его поставщика, обычно robots.txt, и помните, что правила для роботов остаются добровольными инструкциями, а не аутентификацией. Если материал должен оставаться закрытым, используйте вход по учетной записи.

Официальная документация по краулерам четко показывает эту разницу. OpenAI советует издателям управлять доступом OAI-SearchBot через robots.txt для поиска ChatGPT и отдельно задавать правила GPTBot для возможного обучения. Anthropic описывает ClaudeBot, Claude-User и Claude-SearchBot как разных агентов с разными задачами, для каждого из которых применяют свою группу в robots.txt. Perplexity документирует PerplexityBot для поисковой индексации и Perplexity-User для загрузки по запросу пользователя. Ни одна из этих инструкций не предлагает использовать llms.txt как файл разрешений.

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

Есть и другое эксплуатационное последствие. Агент может считать файл ненадежным вводом, игнорировать его прозу или принимать только адреса. Это разумно. Взломанный llms.txt способен направить агента к вредоносным материалам или содержать инструкции, похожие на промпт. Сделайте файл скучным, храните его в системе контроля версий, генерируйте из утвержденного перечня и ограничьте описаниями, которые помогают читателю выбрать ресурс.

Распространение обогнало реальное чтение

Лучшие доступные сейчас массовые данные из логов показывают: в технической выборке файл встречается часто, но запросы к нему редки. Ahrefs изучил 137 210 доменов, которые пользовались его продуктом Web Analytics и получали трафик в мае 2026 года. Корректные файлы нашлись у 28 процентов доменов, примерно у 38 000 сайтов, но авторы предупредили, что среди их клиентов больше технических специалистов и людей из SEO. Считайте этот процент верхней границей для всего интернета, а не универсальным уровнем распространения.

Среди сайтов с корректным файлом 97 процентов не получили за месяц ни одного запроса к нему. Оставшаяся группа, около 1 100 доменов, собрала примерно 22 000 запросов. Боты отправили 96 процентов этих запросов, однако на известные инструменты ИИ пришлось лишь 19,5 процента. Поисковые ИИ-краулеры, то есть категория, которая ближе всего к обычному обещанию улучшить видимость в ИИ-поиске, дали 1,1 процента запросов к файлам, получившим хоть какой-то трафик. На обучающие краулеры пришлось 5,3 процента, на ассистентов 2,5 процента, на агентов 10,5 процента.

Знаменатель здесь важнее всего. Фраза о том, что инструменты ИИ стали крупнейшей различимой группой читателей, звучит обнадеживающе, пока не вспоминаешь: 97 процентов опубликованных файлов вообще не получили трафика. Даже запрос доказывает только то, что клиент загрузил байты. Он не подтверждает, что клиент разобрал Markdown, перешел по адресу, использовал контент в ответе, сослался на сайт или изменил позицию. Для каждого следующего шага нужно отдельное наблюдение.

То же исследование изучило запросы к отсутствующим файлам, получившие ответ 404. Среди таких запросов не оказалось доли ИИ-ботов. Авторы сделали вывод, что системы ИИ не проверяли систематически корень каждого домена в поисках файла. Существующие файлы, вероятно, находились через упоминание, каталог, функцию платформы или инструкцию пользователя. Результат соответствует самому убедительному нынешнему сценарию: ресурс запрашивает намеренно осведомленный агент или разработчик.

Это один набор данных, а не закон интернета. Выборка смещена, один месяц дает короткий период, user-agent можно подделать, а сам запрос ничего не говорит о дальнейшем использовании. И все же измеренный потолок лучше рекламного обещания. Тот, кто обещает автоматический рост цитирований благодаря файлу, должен показать контролируемый эксперимент, где влияние llms.txt отделено от изменений контента, обычного доступа краулеров и остальной части релиза.

Запрос краулера не равен цитате ИИ

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

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

Имена user-agent тоже неточно описывают намерение. Обучающие краулеры, поисковые индексаторы и загрузчики по запросу пользователя выполняют разную работу. OpenAI и Anthropic публикуют отдельные имена именно потому, что владелец сайта может хотеть поискового обнаружения, но отказаться от обучения, либо разрешить явную загрузку пользователем и ограничить массовый краулинг. Объединение каждого запроса со словами bot, GPT, Claude или AI в имени скрывает этот выбор.

Я видел, как команды радовались всплеску ботов, который создал их собственный валидатор, проверка развертывания или сервис предпросмотра ссылок. Исследование Ahrefs обнаружило, что инструменты для аудита или изучения llms.txt создавали заметную долю запросов. Запрос файла со стороны сканера готовности доказывает исправность сканера. Он ничего не говорит о том, использовал ли файл ассистент ваших клиентов.

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

Другие веб-файлы решают другие задачи

robots.txt, карта сайта, каноническая разметка, структурированные данные и llms.txt не конкурируют как версии одной функции. Каждый отвечает на свой вопрос. Замена одного другим оставляет пробел, который новый файл не заполнит.

Группа в robots.txt сообщает краулеру, какие пути он может запрашивать согласно его реализации протокола исключения роботов. Она не скрывает адрес, а блокировка страницы может помешать краулеру увидеть размещенную на ней инструкцию noindex. Карта сайта передает поддерживающим ее поисковым системам доступные канонические адреса и необязательные метаданные. Google прямо называет карту сайта подсказкой, а не гарантией краулинга, индексации или позиции.

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

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

Эта разница задает разумный порядок работы. Обеспечьте доступ к публичным страницам, возвращайте содержательный HTML с сервера, выберите канонические адреса, поддерживайте внутренние ссылки и карту сайта там, где она нужна, намеренно настройте политику для краулеров и публикуйте точный контент. После этого добавляйте отобранный индекс для агентов. Дополнительный файл в корне не исправит оболочку приложения, которая без JavaScript возвращает клиенту пустой HTML, или межсетевой экран, отвечающий нужному боту кодом 403.

Документация дает самый ясный сценарий

Владельцу документации стоит заняться файлом, если агенты уже входят в пользовательский процесс продукта, а выбрать авторитетный корпус трудно. Библиотеки, API, инструменты разработчика, каталоги данных и технические стандарты часто подходят под эти условия. Их пользователи просят агентов для программирования читать документацию, сравнивать версии, искать путь миграции или собирать контекст для изменения. Короткий поддерживаемый индекс избавляет таких пользователей от ручного отбора.

Файл оправдывает себя при четырех условиях. Вы знаете, какие ресурсы авторитетны, их адреса стабильны, агент может получить из них полезный текст, а издательская система умеет обновлять индекс вместе с документацией. Если релиз меняет версионный справочник API, тот же релиз должен обновить или заново сгенерировать файл. Устаревший отбор хуже его отсутствия, потому что уверенно направляет агента к неправильному материалу.

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

Для небольшого сайта-визитки с десятком страниц и хорошими ссылками польза слабее. Краулер и так найдет страницы, а агенту, получившему конкретную страницу, второй индекс не нужен. Если CMS генерирует файл, он все равно может почти ничего не стоить, но бюджет и должен быть почти нулевым. Не запускайте контентный проект ради ручных описаний страниц, где уже есть понятные заголовки, подзаголовки и навигация.

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

Пропустите файл, если работа стала ритуалом

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

Пропустите проект, если он конкурирует с уже известными сбоями краулинга. Сначала исправьте повторяющиеся ответы 403, случайные блокировки ботов, сломанные канонические теги, поверхностную документацию, нестабильные адреса, контент только на стороне клиента и отсутствующие внутренние ссылки. Официальные инструкции OpenAI, Anthropic и Perplexity сосредоточены на доступе через robots.txt, достижимых страницах и защите от ботов, потому что эти элементы лежат на реальном пути загрузки.

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

Я также не стал бы поддерживать файл вручную на новостном сайте или активном блоге, пока аналитика не покажет спрос агентов на стабильную часть материалов. Хронологическая лента, карта сайта, тематические страницы и чистый HTML статей уже открывают корпус. Повторный отбор каждой статьи в Markdown создает еще одну редакционную очередь без понятного читателя.

Team & AI Audit должен считать llms.txt небольшим экспериментом по распространению, а не доказательством того, что компания изменила разработку или продажи. Дорогие вопросы другие: есть ли у команды полезные процессы с агентами, надежные исходные материалы, подходящий контроль доступа и метрики, связанные с результатами бизнеса.

Корректный файл должен легко проверяться

Файлу, соответствующему формату, нужен H1; также можно добавить цитату, поясняющий текст и списки H2. В примере ниже вместо действующих адресов стоят заменяемые токены. Подставьте в каждый токен принадлежащий вам канонический адрес, затем отдавайте результат как обычный текст UTF-8 в корне сайта.

# Example Cloud API

> An API for processing queued jobs. Use the current v2 documentation unless a project explicitly targets v1.

The API reference defines request fields. Tutorials explain workflows but do not override the reference.

 ## Start here

- [Quickstart](QUICKSTART_URL): Create credentials and submit a first job
- [API reference](API_REFERENCE_URL): Current v2 endpoints, request fields, responses, and errors
- [Authentication](AUTHENTICATION_URL): Credential scope, rotation, and failure behavior

 ## Operations

- [Rate limits](RATE_LIMITS_URL): Limit headers, retry rules, and quota behavior
- [Status and errors](ERRORS_URL): Error codes and recovery guidance

 ## Optional

- [Changelog](CHANGELOG_URL): Release history and migration notices
- [Examples](EXAMPLES_URL): Complete sample applications

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

Не копируйте содержимое примера вслепую. Копируйте его структуру. Дайте проекту однозначное имя, напишите краткое описание, которое предотвращает самую вероятную ошибку в категории, и укажите минимальный набор для типичных задач. Второстепенные ресурсы поместите в Optional. Если нужны сотни адресов, улучшите иерархию или создайте отдельные файлы для разных разделов документации.

Проверяйте не только Markdown, но и ответ сервера. Корневой адрес должен возвращать 200, текстовый тип содержимого и ожидаемое тело без страницы входа, цикла перенаправлений, HTML-оболочки ошибки или проверки для ботов. Красивый исходный файл, который CDN превращает в ответ 403, не имеет читателей.

Владение в продакшене важнее синтаксиса

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

Относитесь к изменениям как к изменениям кода. Адрес, добавленный взломанным плагином CMS, может направить агентов к злоумышленнику. Ограничьте редактирование, проверяйте изменения и настройте уведомления о неожиданном хеше или хосте назначения. Не помещайте в описания текст, похожий на исполняемые инструкции. Потребителям следует считать весь файл ненадежным содержимым, но издатель не должен усложнять им задачу.

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

Не раскрывайте закрытую документацию через отбор. Указание публично доступного, но нигде не связанного адреса облегчает его обнаружение. Если ресурс требует авторизации, оставьте защиту на самом ресурсе и обычно не включайте его в публичный индекс. Защита за счет неочевидного адреса уже была сломана до llms.txt; новый индекс лишь делает ошибку заметной.

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

Измеряйте поведение по своим логам доступа

Сначала проверьте запросы к файлу в логах исходного сервера или пограничной сети. Ищите нормализованный путь запроса, затем группируйте по статусу, user-agent, проверенной сетевой принадлежности, когда она доступна, и времени. Не ищите только известные названия ИИ: так вы потеряете неизвестных клиентов и не отделите свой мониторинг от внешнего трафика.

Для распространенного комбинированного лога доступа, скопированного на локальную машину для анализа, эта команда даст грубый первый срез:

awk '$7 == "/llms.txt" {print $9, $1, substr($0, index($0, $12))}' access.log | sort | uniq -c | sort -nr

Формат результата: количество, затем статус, адрес клиента и хвост user-agent:

18 200 192.0.2.40 "Mozilla/5.0 (compatible; ExampleBot/1.0)"
4 304 192.0.2.40 "Mozilla/5.0 (compatible; ExampleBot/1.0)"
2 404 198.51.100.7 "Mozilla/5.0"

Это первичная сортировка, а не атрибуция. Адреса в примере взяты из диапазонов для документации, а бот вымышлен. В реальном анализе удалите проверки работоспособности и собственные валидаторы, сохраните данные о статусе и кеше, затем проверьте заявленную личность краулера способом поставщика. Заголовок user-agent может скопировать кто угодно.

Затем ищите продолжение действий. Запрашивал ли тот же проверенный клиент в разумном временном окне адреса, которые перечислены только в файле или занимают в нем заметное место? Завершились ли эти запросы успешно? Началась ли такая последовательность после публикации? Контрольный адрес может помочь, но на нем должен находиться полезный публичный материал, а не ловушка или скрытая инструкция. Не делайте вывод об использовании в ответе только потому, что два запроса произошли рядом по времени.

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

Соотносите усилия с доказательствами

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

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

Здесь есть полезная асимметрия. Сгенерированный за десять минут индекс для чистой технической документации может стать разумной ставкой: возможный ущерб мал, а известный пользователь агента получит пользу. Многонедельная программа роста видимости в ИИ вокруг того же файла станет плохой ставкой, потому что данные не оправдывают расходы. Байты одинаковы; смысл работы определяют владелец, аудитория и цена упущенной возможности.

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

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

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

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