Мы дали llms.txt нулевой вес и всё равно его рекомендуем

Обновлено: 2026-08-29

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

Что это за файл?

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

По смыслу он близок к robots.txt, который говорит краулерам, что можно скачивать, и к sitemap.xml, который говорит, что существует. llms.txt пытается сказать, что важно и в каком порядке.

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

llms.txt

Предложенный файл в корне сайта, где перечислено, что стоит читать языковой модели.

Предложенная договорённость

Соглашение, которое опубликовано, но которое никто не обязался соблюдать.

В чём проблема идеи?

Никто не согласился его читать.

robots.txt работает, потому что операторы краулеров решили его соблюдать, последовательно, десятилетиями. sitemap.xml работает, потому что поисковики построили под него приём данных. Обе конвенции стали рабочими благодаря принятию, а не публикации.

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

Это описание текущего положения, а не прогноз. Оно может измениться. Пока не изменилось.

Почему наш движок ставит ему ноль?

Мы следим за 75 переменными. У четырёх горизонт помечен как будущий, то есть они описывают вещи, которые правдоподобно будут важны потом и доказуемо не важны сейчас: сам llms.txt, markdown-двойник каждой страницы, согласование содержимого для markdown и выставленная наружу точка доступа MCP.

Каждая из четырёх весит ноль в балле. Их показывают в отдельном разделе отчёта, а не подмешивают к числу.

Но вес, который они несли бы при появлении принятия, сохранён в модели, в поле, которое мы называем «вес при принятии». Рассуждение записано, значение проставлено, а включение это правка конфигурации, а не перепроектирование.

Вот всё решение одной фразой: балл должен отражать то, что измеримо сегодня, а модель должна помнить, за чем она следит.

Мы спросили сами модели, читают ли они llms.txt. Ни одна не назвала его обязательным или хотя бы учитываемым. Поэтому вес у него ноль. Файл мы всё равно держим: это лишний слой контекста, где можно одной строкой изложить главную мысль каждой страницы.

Почему мы всё равно его рекомендуем?

Три причины, в порядке убывания того, насколько я в них верю.

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

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

Асимметрия исхода. Если принятие не придёт никогда, вы потеряли двадцать минут. Если придёт, вы уже на позиции, а цена раннего входа была нулевой. Само по себе это не сильный довод, но в паре с нулевой ценой ему и не нужно быть сильным.

Чего я не утверждаю: что это улучшит ваше цитирование. Измерений в пользу этого нет, и выдумывать их я не буду.

Как написать по-настоящему полезный?

Раз настоящая ценность в диагностике, файл стоит писать руками, а не генерировать.

# Название компании

> Одно предложение о том, чем занимается эта организация и для кого.

## Основные страницы

- [Что мы делаем](https://example.com/services): четыре услуги, которые мы
  оказываем, с объёмом и вилкой цены по каждой.
- [Цены](https://example.com/pricing): три тарифа, что входит в каждый и по
  какому признаку выбирать между ними.

## Справочник

- [Документация](https://example.com/docs): установка, справочник по API,
  разбор проблем.

## Примечания

- Канонический язык русский; версии на испанском и английском лежат в /es/
  и /en/ и являются переводами, а не отдельным содержанием.

Правила, отличающие полезный файл от украшения:

Описания, а не ярлыки. «Цены» не говорят машине ничего, чего она не угадала бы из адреса. «Три тарифа, что входит и по какому признаку выбирать» говорит, на что страница отвечает.

Десять до двадцати записей, а не двести. Единственное преимущество файла перед sitemap это отбор. Полный перечень выбрасывает его и превращает файл в худший sitemap.

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

Держите его честным. Файл, описывающий сайт, которого в таком виде нет, хуже отсутствия файла, ровно по той же причине, по которой несовпадающая разметка хуже её отсутствия.

Что за три других файла в той же категории?

llms.txt самый известный из четырёх вещей, за которыми наш движок следит с нулевым весом. Остальные стоит назвать, потому что у них та же форма и то же рассуждение.

Markdown-двойник каждой страницы. Отдавать /kakaya-to-stranica.md рядом с /kakaya-to-stranica с тем же содержанием, без навигации, оформления и шаблонного текста. Довод в том, что модель, читающая markdown, ничего не тратит на вёрстку. Контрдовод в том, что извлечение из HTML и так работает, а предпочитать markdown-версию никто не обещал.

Согласование содержимого для markdown. Та же идея без второго адреса: агент, присылающий Accept: text/markdown, получает чистую версию по тому же адресу. Изящнее, дороже в реализации, ровно так же не принято.

Выставленная точка MCP. Публикация конечной точки Model Context Protocol, чтобы агент мог запрашивать данные вашего сайта структурно, а не соскабливать страницы. Технически самое интересное и дальше всего отстоящее от того, чтобы иметь значение для обычного сайта компании, потому что предполагает агентов, которым нужен структурный доступ именно к вам.

Все четыре лежат в одном ящике: правдоподобны, дёшевы в подготовке и сегодня не вознаграждаются. У всех четырёх записан вес при принятии. Ни одна не влияет на балл сегодня.

Мы перечисляем их в отдельном разделе каждого отчёта, помеченными как ставки на будущее, именно чтобы никто не прочёл их как невыполненную работу.

Какой более широкий вывод о зарождающихся стандартах?

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

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

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

Последнюю часть люди и пропускают. Мы записали значения веса при принятии для всех четырёх будущих переменных именно затем, чтобы «принятие пришло» стало наблюдаемым событием с заготовленным ответом, а не тем, что замечают через полтора года.

Что изменит нашу позицию?

Заявлено заранее, чтобы было опровержимо:

Поставщик публично обязуется. Если крупный поставщик моделей задокументирует, что его конвейер скачивает /llms.txt, вес в ту же неделю перейдёт с нуля на заготовленное значение.

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

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

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

Часто задаваемые вопросы

llms.txt это официальный стандарт? Нет. Это предложенное соглашение со спецификацией и сообществом. Поддержки со стороны крупных поставщиков моделей у него нет.

Он заменяет robots.txt? Нет. robots.txt управляет доступом и соблюдается. llms.txt описывает содержание и остаётся пожеланием. Держите оба и убедитесь, что robots.txt не блокирует нужных вам краулеров.

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

Нужно ли перечислять все страницы? Нет. Десять до двадцати записей с настоящими описаниями. Полный перечень это sitemap, а он у вас уже есть.

Помогает ли это с Google? Доказательств этому нет, и механизм не даёт оснований этого ждать. У классического поиска свой путь приёма данных.

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

Источники: спецификация llms.txt v1.1.x; определения переменных GeoScan v1.2 и классификация будущего горизонта; компендиум исследований по 165 источникам о поиске с ИИ, август 2026.