llms.txt как страховка: анализ эффективности спецификации и результаты 64-тестового валидатора
Файл llms.txt, предложенный как стандарт для навигации языковых моделей по структуре веб-сайта, сталкивается с реальностью статистики: за последние 90 дней боты запросили его всего 408 раз на фоне более чем 500 миллионов других событий. Несмотря на низкий трафик, создание автоматизированного валидатора с детальной системой оценки ошибок proves полезность контроля качества, даже если идеальный формат пока не стал массовым стандартом.
# llms.txt как страховка: анализ эффективности спецификации и результаты 64-тестового валидатора
С 2024 года в цифровой экосистеме появилась рекомендация размещать в корне домена файл llms.txt. Автор спецификации, Джереми Ховард, выдвинул простую идею: предоставить языковым моделям короткую карту сайта на естественном языке. Файл должен содержать описание проекта и ссылки на ключевые разделы, избегая сложностей с анализом HTML-вёрстки. Однако на практике эффективность этого механизма вызвала вопросы.
Статистика запросов: цифра меньше 0,1%
Прежде чем разрабатывать инструменты для анализа, необходимо понять, насколько актуален этот формат. На основе данных от Limy.ai за период с мая 2026 года по сентябрь 2026 года (покрытие 90 дней) картина выглядит следующим образом:
* Общее количество событий, связанных с трафиком ИИ-ботов: 515 миллионов. * Количество запросов конкретно к файлу llms.txt: 408.
Эти цифры показывают, что доля ботов, ищущих этот файл, составляет менее одной десятитысячной процента от общего объема трафика. Основные игроки рынка, такие как GPTBot, ClaudeBot и PerplexityBot, активно сканируют веб-ресурсы, но они не стремятся целенаправленно запрашивать отдельный файл-карту. Более того, поисковая система Яндекс не заявляет поддержки llms.txt ни для своего нейросетевого поиска, ни для Алисы AI. В этом случае ответы формируются путем синтеза данных из органической выдачи, а не через прямой доступ к файлу в корне домена.
Как устроен парсер и система оценки
Несмотря на низкий спрос, структура файла специфицирована достаточно жестко, чтобы ошибки могли нарушить читаемость. Формат требует:
1. Точно одного заголовка уровня H1 в первой значимой строке. 2. Блока описания (в формате Markdown-цитаты) сразу после заголовка. 3. Секций с подзаголовками, содержащих маркированные списки ссылок.
Нарушения часто носят хаотичный характер: встречается несколько H1, описание стоит перед заголовком, используются абсолютные ссылки на http:// вместо https://, либо внутри секций попадаются абзацы прозы вместо списков. Эти проблемы решаются детерминированными правилами, не требующими сложных нейросетевых моделей.
Разработанный инструмент разделил задачу на две части: парсинг (преобразование текста в структурированный объект) и валидация (проверка объекта по набору правил). Система оценки работает по принципу вычета штрафных баллов от 100.
Шкала штрафов
Каждая ошибка имеет вес в зависимости от того, насколько она критична для машинного чтения:
* Критическая (вес 40): Отсутствует заголовок H1 или файл пустой. Без заголовка файл фактически нечитаем. Это равносильно тому, что модель не понимает, о чем идет речь. * Высокая (вес 25): Описание расположено до заголовка H1, или в файле обнаружено более одного H1. Структура документа при этом «рассыпается». * Средняя (вес 12): Битый формат буллета или посторонний текстовый контент внутри секции, предназначенной для ссылок. * Низкая (вес 5): Использование протокола http:// вместо https:// или мелкие отклонения в оформлении.
Таким образом, наличие нескольких некорректных ссылок не приведет к полному провалу файла, но отсутствие заголовка сделает его бесполезным.
Результаты тестирования: 64 случая
Для отладки и проверки валидатора было проведено 64 теста. Только для базовых правил (описание до заголовка, проверка http://, посторонний текст) было разработано 22 специфических теста. Остальные проверки охватывают проверку микроразметки, работу с прокси и обработку граничных случаев.
Особое внимание уделено пограничным ситуациям: как ведет себя парсер на пустом вводе, файле из одних пробелов или при смешанных переводах строк (\r\n). В первой версии алгоритма такой ввод мог привести к потере последней секции, что исправилось благодаря дополнительным тестам. Сам процесс валидации занимает всего 43 миллисекунды.
Выводы: стратегия использования файла
Анализ показывает, что ставить llms.txt не стоит с расчетом на то, что нейросети автоматически найдут сайт в поиске через этот файл. Для этого существуют органическая выдача и контент страниц. Однако, учитывая простоту спецификации и распространенность ошибок в её исполнении, файл может служить дешевой страховкой.
Если вы решите разместить llms.txt, рекомендуется потратить около пяти минут на проверку структуры с помощью валидатора. Критические требования к идеальному файлу:
1. H1 в первой значимой строке и ни одного другого H1 во всем файле. 2. Описание оформлено как цитата (> Текст) и стоит сразу после заголовка. 3. Секции содержат только маркированные списки ссылок. Все остальное — лишнее.
Файл не является обязательным для работы ботов, но корректно оформленный llms.txt может немного улучшить понимание структуры сайта инструментами, которые еще не используют органический поиск для формирования ответов. Главное правило для разработчика: не создавать файл, если у вас нет времени на его валидацию и поддержку соответствия спецификации.
Пример корректного файла: > ``text > # Название компании > > Краткое описание того, чем занимается компания и для кого работает. > > ## Наши услуги > * Ссылка на страницу услуг > * Ссылка на страницу кейсов > > ## Контакты > * Ссылка на страницу контактов > * Ссылка на Telegram >