llms.txt: что этот файл дает сайту и чего не гарантирует

Начинайте не с файла, а с ограничения проекта

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

Причины могут быть разными:

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

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

«Я не ставлю новый слой в план только потому, что инструмент стал популярным. Сначала нужно назвать ограничение: что агент не находит, почему это важно и какое изменение мы сможем проверить после внедрения».

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

Что представляет собой llms.txt v2

Актуальное предложение llms.txt v2 описывает Markdown-файл, который дает краткую информацию о сайте или разделе и ведет к подробным материалам. Его можно разместить в корне /llms.txt или внутри отдельного пути, например /docs/llms.txt. Файл в подкаталоге относится к материалам под этим путем.

Формат остается открытым предложением, а не обязательным веб-стандартом. В нем только H1 с названием проекта является обязательным. После него могут идти:

• короткое описание в цитате;
• пояснения о проекте и правилах интерпретации;
• H2-разделы со списками ссылок;
• краткие комментарии, объясняющие содержание каждой ссылки;
• раздел Optional для второстепенных материалов.

Версия v2 также предлагает публиковать чистые Markdown-версии важных страниц и связывать их через rel="alternate" и rel="describedby". Главная идея остается простой: сам llms.txt должен быть компактным, а подробности находятся по ссылкам.

Chrome Lighthouse уже проверяет наличие и доступность llms.txt в контуре agentic browsing. При этом Chrome прямо называет формат развивающейся конвенцией и опциональной практикой: если файл отсутствует и сервер отвечает 404, проверка получает статус N/A.

Что llms.txt реально дает сайту

Я оцениваю ценность файла не по формату, а по изменению маршрута к информации.

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

«Файл со всеми URL подряд не становится полезнее от своего размера. Карта ценна тогда, когда она сокращает путь к нужному материалу и объясняет, почему именно эта страница является точкой входа».

Не смешивайте llms.txt, robots.txt и sitemap.xml

Эти файлы решают разные задачи.

Google прямо пишет, что для появления в AI Overviews и AI Mode не нужны новые machine-readable или AI text files. Важными остаются обычные SEO-основы: индексируемость, внутренние ссылки, полезное содержание и доступность значимой информации в текстовой форме.

Показателен и другой факт. OpenAI публикует llms.txt как индекс собственной документации, но управление OAI-SearchBot и GPTBot описывает в отдельной документации по robots.txt. Perplexity также публикует индекс документации, а для PerplexityBot указывает правила в robots.txt. Навигационный индекс и политика доступа существуют рядом, но не подменяют друг друга.

Определите приоритет внедрения

llms.txt стоит ставить выше в план, когда он снимает конкретное ограничение и не создает ручной долг.

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

Соберите минимальный файл без лишнего каталога

Для первого релиза достаточно названия, краткого описания и нескольких разделов с главными ссылками:

 # Компания Краткое описание компании, аудитории и основной задачи сайта. ## Основные услуги - SEO-продвижение: https://example.ru/services/seo - состав услуги и критерии старта - Разработка сайтов: https://example.ru/services/sites - типы проектов и процесс работы ## Экспертиза - База знаний: https://example.ru/expertise - статьи, исследования и методики - Кейсы: https://example.ru/cases - задачи, действия и подтвержденные результаты ## Optional - Контакты: https://example.ru/contact - способы связи и реквизиты

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

• служебные и приватные URL;
• параметры фильтрации и дубли;
• страницы с редиректом вместо конечного адреса;
• удаленные и временные материалы;
• десятки однотипных ссылок без объяснения различий;
• утверждения, которых нет на связанных публичных страницах.

Описание ссылки должно помогать сделать выбор.

Разделите компактную карту и расширенный контекст

Предложение v2 строится вокруг компактного llms.txt и подробностей за ссылками. Отдельный llms-full.txt не является обязательным элементом формата, но сайт может использовать его как дополнительный полный контекст, если такое разделение помогает агентам и остается управляемым.

На сайте Медиакода работают два уровня:

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

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

Обновляйте llms.txt из одного источника правды

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

«Если llms.txt ведется отдельно от CMS и каталога, расхождение становится вопросом времени. Я бы сразу закреплял один источник правды и правило: опубликованный материал появляется в карте автоматически, снятый с публикации исчезает вместе с ним».

Для автоматической сборки нужны понятные правила:

1. Брать только опубликованные публичные материалы.
2. Использовать канонический URL без параметров и дублей.
3. Сохранять один основной тематический раздел страницы.
4. Генерировать короткое описание из отдельного редакционного поля, а не из случайного фрагмента текста.
5. Обновлять карту при публикации, изменении и снятии материала.
6. Проверять ссылки и пустые разделы тестом сборки.
7. Оставлять ручное управление только для приоритетов и дополнительных внешних источников.

Рабочий llms.txt является частью публикационного процесса. Он не живет отдельной таблицей, которую вспоминают перед аудитом.

Проведите приемку по восьми проверкам

После внедрения я бы принимал задачу не по скриншоту файла, а по рабочему маршруту:

1. /llms.txt отвечает HTTP 200 и открывается как текст.
2. H1 точно называет сайт или проект.
3. Краткое описание совпадает с публичным позиционированием.
4. Основные разделы не дублируют друг друга по роли.
5. Все ссылки ведут на конечные публичные URL без ошибок.
6. Комментарий к каждой ссылке помогает понять назначение страницы.
7. Новая тестовая публикация автоматически появляется в нужном разделе.
8. Агент, получив только файл как стартовую точку, находит услугу, доказательство и подробный материал по заданному вопросу.

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

Измеряйте операционное качество файла

У llms.txt есть собственные проверяемые показатели:

• доступность и корректный тип ответа;
• доля рабочих конечных ссылок;
• отсутствие дублей и закрытых URL;
• скорость появления нового опубликованного материала;
• совпадение названий и описаний с каноническими страницами;
• обращения к файлу и связанным Markdown-страницам в серверных логах;
• успешность контрольных заданий для агента.

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

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

Включите файл в общую архитектуру видимости

llms.txt приносит больше пользы, когда связан с каноническими HTML-страницами, внутренней навигацией, schema, sitemap и доступом краулеров. Общий материал Медиакода о SEO и видимости в нейропоиске показывает весь контур целиком.

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