llms.txt: что на самом деле делает файл для AI-краулеров

llms.txt - это Markdown-файл, который вы публикуете в корне своего домена - yourdomain.com/llms.txt - и который перечисляет страницы, которые вы больше всего хотели бы, чтобы прочитала AI-модель, каждую с однострочным описанием. Джереми Ховард из Answer.AI предложил стандарт llms.txt в сентябре 2024 года, и актуальная спецификация находится на llmstxt.org. В этом вся идея: курируемый список для чтения, а не свод правил.

Вот что пропускает большинство объяснений. Ничего не выдаётся и ничего не блокируется, и ни один крупный поставщик моделей - ни OpenAI, ни Anthropic, ни Google - публично не подтвердил, что забирает llms.txt перед тем, как ответить на вопрос. Несколько инструментов для разработчиков действительно читают файл. Почти всё остальное - нет. Если вы пришли сюда, чтобы узнать, следуют ли GPTBot или ClaudeBot по вашим редиректам, это отдельный вопрос - смотрите что AI-краулеры на самом деле делают со ссылкой. Этот пост - о самом файле llms.txt: что в нём на самом деле есть, кто его читает, во что обходится его поддержка и стоит ли публикация одного файла потраченного на это дня в 2026 году.

Что такое llms.txt на самом деле

Спецификация достаточно короткая, чтобы прочитать её за две минуты. Валидному файлу нужен ровно один обязательный элемент: заголовок H1 с названием вашего сайта или проекта. Всё остальное - опционально, но принято по соглашению. Блок цитаты сразу под H1 даёт однострочное резюме. Свободные абзацы могут добавлять контекст. Затем идут заголовки H2, каждый со списком ссылок, и у каждой ссылки может быть двоеточие и короткая пометка о том, что в ней содержится. Раздел с заголовком "Optional" на уровне H2 - это соглашение для второстепенных материалов, которые модель может пропустить, если работает с ограниченным контекстом.

Формат был создан для одной конкретной проблемы: сайт документации - это в основном навигационный "обвес" и ссылки в сайдбаре, и модель, читающая сырой HTML, тратит токены на всё это. Вместо этого файл llms.txt даёт ей чистый индекс. Это более узкая задача, чем предполагает большинство материалов по теме: формат создавался для документации, а не для открытого веба. Сравните это с реальной работой по answer engine optimization - и это различие и есть большая часть ответа.

llms.txt - это не robots.txt

Сравнение, к которому все тянутся, - это robots.txt, и оно вводит в заблуждение больше, чем помогает.

robots.txt по RFC 9309 ограничен одним хостом, и он работает, потому что поимённо названные краулеры - Googlebot, Bingbot, и в их числе AI-краулеры - проверяют его перед тем, как что-либо забрать, и соблюдают строку Disallow в силу десятилетиями сложившегося соглашения. Он тоже никогда не выдавал доступ - агент, который его игнорирует, игнорировал бы его в любом случае, - но краулеры, о которых стоит беспокоиться, действительно его читают.

У llms.txt такой опоры нет. Ничто не говорит модели проверить /llms.txt перед тем, как ответить на вопрос о вашем сайте. Проверяет его горстка инструментов для разработчиков. Универсальный ассистент, отвечающий на вопрос в окне чата, не обязан искать ваш файл, и большинство даже не пытаются. Называть его "файлом для AI-краулеров" или "robots.txt для AI" - оба ярлыка встречаются почти в каждом объяснении - значит приписывать ему механизм принуждения, которого у формата попросту нет. Не было никогда.

Кто на самом деле читает этот файл

Внедрение реально. Просто оно уже, чем предполагают публикации на эту тему.

Mintlify добавила автоматическую генерацию llms.txt для каждого сайта, который она хостит, в конце 2024 года, и внедрение подскочило за одну ночь, потому что Anthropic, Cursor, Stripe, Cloudflare и Vercel публикуют документацию через такие платформы, как Mintlify, Fern или GitBook, которые теперь генерируют файл по умолчанию. Инструменты для разработки - Cursor, Windsurf, Claude Code, GitHub Copilot, Cline, Aider - действительно ищут /llms.txt, когда их направляют на сайт документации, потому что для этой конкретной задачи чистый индекс превосходит парсинг отрендеренной навигации.

А вот чего не случилось - это та часть, на которую намекает большинство постов. Ни один универсальный потребительский ассистент не подтвердил, что проверяет файл перед тем, как ответить на вопрос, и люди, наиболее близкие к поиску, говорят об этом прямо. Джон Мюллер из Google сказал это без обиняков: ни один из AI-сервисов не заявил, что использует файл, а логи серверов показывают, что большинство даже не запрашивают его. Он сравнил его с мета-тегом keywords - полем, которое издатели когда-то честно заполняли, пока поисковые системы тихо не перестали его читать, потому что его было слишком легко обмануть.

Итак: реальная аудитория среди инструментов для разработки и платформ документации, и никакой подтверждённой аудитории среди ChatGPT, Gemini или Perplexity, отвечающих на вопрос о покупке или исследовании. Если AI-трафик на ваш сайт достаточно важен, чтобы на него реагировать, не выводите его из файла, чтение которого никто не подтвердил, - измеряйте его. Канал AI Assistant в GA4 - это то место, где такой трафик действительно проявляется, в те дни, когда вообще проявляется, а аналитика Elido показывает, какие переходы по вашим собственным опубликованным ссылкам пришли от ассистента.

Как выглядит файл, строка за строкой

Вот минимальный валидный пример, близкий к образцу из спецификации:

# Acme Docs

> Acme is an API for parsing invoices. This file lists the pages worth reading first.

Full documentation lives at docs.example.com. Sections below are ordered by how often a new integration needs them.

- [Quickstart](https://docs.example.com/quickstart): Authentication and your first API call
- [Rate limits](https://docs.example.com/limits): Current limits and how to request an increase
- [Endpoints](https://docs.example.com/api): Full request and response schemas

Каждая строка выполняет одну задачу. H1 обязателен; если пропустить блок цитаты, модель будет гадать, чем занимается сайт, прежде чем откроет хоть одну ссылку. В реальном файле ссылки группируются под H2 по смыслу, а не по структуре сайта, что обычно прямо противоположно тому, как устроено главное меню (сокращённый пример выше использует одну группу, чтобы быть короче). Двоеточие с описанием после ссылки - это и есть настоящая ценность: однострочная подача, которая решает, заберёт ли модель с ограниченным местом этот URL или пропустит его. Спецификация также допускает H2 с заголовком "Optional" именно для такого же второстепенного материала.

llms-full.txt - это совсем другое

llms.txt - это именно индекс. llms-full.txt включает сам контент: те же страницы, преобразованные в чистый Markdown и объединённые в один файл, иногда разрастающийся до десятков тысяч слов, чтобы модель могла получить его за один запрос вместо того, чтобы переходить по ссылкам по одной. Платформы, которые автоматически генерируют llms.txt - Mintlify, GitBook, Fern - обычно генерируют вместе с ним и llms-full.txt, поскольку конвейер в обоих случаях один и тот же. Сайт документации меньше нескольких сотен страниц - это разумно поддерживать в актуальном состоянии. Каталог товаров на тысячи страниц слишком велик, чтобы быть полезным, и слишком дорог, чтобы держать его актуальным.

Честная цена его поддержки

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

Каждая ссылка должна по-прежнему разрешаться, по-прежнему указывать на актуальную версию страницы и по-прежнему соответствовать тому, что там на самом деле есть. Переименуйте документ или выпустите новую версию API - и файл тихо разойдётся с реальностью, потому что при этом ничего не ломается. Устаревший llms.txt не отдаёт 404 - он просто скармливает модели устаревшую информацию с полной уверенностью.

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

Что на самом деле приводит к цитированию сегодня

Отложите файл в сторону и посмотрите, что на самом деле подтверждено доказательствами.

Директивы robots.txt работают, потому что поимённо названные краулеры проверяют их перед каждым запросом - OpenAI, Anthropic и Google публикуют, какие user agent соблюдают какие правила, и механика этого разобрана здесь, а не повторяется в этом посте. Чистый, быстрый, свободный от JavaScript HTML читается полностью, а не частично; страница, которой нужен клиентский рендеринг, чтобы показать содержимое, может быть заброшена ещё до того, как ваш текст успеет загрузиться, и это же одна из причин, почему гигиена редиректов влияет на то, как воспринимается страница, независимо от того, читатель это человек или модель. Структурированные данные - схемы Article и FAQPage, соответствующие видимому тексту, - дают системе поиска ответов короткий путь к тому, что утверждает страница, и собственные рекомендации Google рассматривают это как обычное техническое SEO, а не как AI-специфичный трюк. Упоминания в другом месте - в отзывах, на форумах, в чужих подборках - коррелируют с цитированием сильнее, чем почти всё на вашем собственном домене, потому что модель взвешивает репутацию, выстроенную по всему вебу, а не только на одной странице.

Ничего из этого не новый совет, переодетый под момент AI. Это тот же список, который вы бы дали кому-то для классического поиска, только нацеленный на систему поиска ответов, а не на алгоритм ранжирования. llms.txt не фигурирует в нём нигде, и именно поэтому этот пост начался с предостережения, а не с инструкции.

Вердикт: стоит ли публиковать его в 2026 году

Так стоит ли его выпускать? Зависит от того, на какой вы стороне.

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

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

Примерно к этому же снова и снова приходит кластер ai в этом блоге: две минуты внимания, ноль минут тревоги.

Ещё по теме в блоге

• Answer engine optimization: что приводит к цитированию страницы
• AI-краулеры и короткие ссылки: что боты делают на самом деле
• Канал AI Assistant в GA4: что он отслеживает, а что упускает
• Вредят ли сервисы сокращения URL для SEO?
• Аналитика коротких ссылок: что стоит измерять