Файл llms.txt предлагают класть в корень сайта с 2024 года: считается, что языковые модели прочитают его вместо того, чтобы разбирать вёрстку. Я написал для него генератор и валидатор, проделал 64 теста для отладки — и параллельно посмотрел, сколько раз ИИ-боты вообще запрашивают этот файл. Значения получились неутешительные, но валидатор всё равно оказался полезным. Ниже — устройство разбора, схема оценки и код.

Что такое llms.txt и чем он отличается от llms-full.txt

llms.txt — текстовый файл в корне домена, размеченный обычным Markdown. Замысел автора спецификации Джереми Ховарда простой: дать модели короткую карту сайта на естественном языке — что за проект, какие разделы, куда идти за документацией.

Структура задана жёстко:

  • # Заголовок — H1 первой значимой строкой, ровно один на файл;

  • > Описание — блочная цитата сразу после заголовка;

  • ## Секции — тематические группы со ссылками вида - Название: пояснение.

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

Сколько раз боты запросили llms.txt: 408 из 515 миллионов событий

Запросов к файлу за 90 дней — меньше одной десятитысячной процента бот-трафика
Запросов к файлу за 90 дней — меньше одной десятитысячной процента бот-трафика

Прежде чем писать инструмент, я поискал данные о реальном спросе. Limy.ai в мае 2026 года опубликовала разбор бот-трафика: из примерно 515 миллионов событий ИИ-ботов за 90 дней файл llms.txt запросили 408 раз. Это меньше одной десятитысячной процента.

При этом сами боты работают активно: GPTBot, ClaudeBot и PerplexityBot регулярно обходят сайты, читают HTML и уважают robots.txt. Просто отдельный файл-карту они целенаправленно не запрашивают.

В Яндексе поддержку llms.txt не заявлялт ни для Алисы AI, ни для нейропоиска. Алиса собирает ответ по схеме «нейросеть переписывает запрос → поиск Яндекса отдаёт органику → нейросеть синтезирует ответ», и дорога в этот ответ идёт через выдачу, а не через файл в корне.

Зачем валидатор, если файл почти не запрашивают

  1. Легко сделать. Пятнадцать минут работы и минимум поддержки.

  2. Спецификация выглядит простой ровно до первой попытки её соблюсти. В файлах, которые я разбирал, регулярно встречается описание заголовка, два H1, ссылки на http:// и абзацы прозой посреди секции со ссылками.

  3. Генерация и проверка структуры — детерминированная задача. Здесь не нужна модель, нужен парсер и набор правил. А раз так, к ним пишутся тесты.

Как устроен разбор: парсер отдельно, правила отдельно

Разбор разведён на две функции. parseLlmsTxt(text) превращает текст в структуру и запоминает порядок элементов — именно порядок нарушается чаще всего. validateLlmsTxt(text) прогоняет по структуре набор проверок и складывает оценку.

export function parseLlmsTxt(text) {

  const raw = String(text ?? '').replace(/\r\n?/g, '\n');

  const parsed = {

    title: null,

    titleIsFirst: false,      // H1 стоит первой значимой строкой

    h1Count: 0,

    description: null,

    descriptionBeforeTitle: false,

    sections: [],

    malformedEntries: [],     // буллеты с битым форматом

    strayLines: [],           // проза внутри секции со ссылками

  };

  // …построчный разбор с сохранением порядка

  return parsed;

}

Сеть парсер не трогает: проверяется структура переданного текста, а не доступность ссылок.

Как считается оценка: вес ошибки от 5 до 40

Вес ошибки задаёт, насколько она ломает машинное чтение файла
Вес ошибки задаёт, насколько она ломает машинное чтение файла

Каждая проверка возвращает статус и вес. Итоговая оценка — сто минус сумма весов сработавших проверок.

const SEVERITY_WEIGHT = { critical: 40, high: 25, medium: 12, low: 5 };

Разнесение по весам отражает то, насколько ошибка ломает машинное чтение:

  • critical (40) — файл пустой или в нём нет H1: читать нечего;

  • high (25) — описание стоит раньше заголовка, H1 больше одного: структура рассыпается;

  • medium (12) — битый формат буллета, посторонний текст внутри секции;

  • low (5) — ссылки на http:// вместо https://, мелкие отклонения оформления.

Такая шкала приводит к понятным выводам → один http:// не должен ронять файл в красную зону, а отсутствие заголовка — должен.

Что проверяют 22 теста на llms.txt

Набор тестов на генератор и валидатор — 22 штуки, каждый на одно правило:

  • описание до заголовка → fail

  • http:// (без S) → warn, не pass

  • посторонний текст внутри секции → markdown warn

  • несколько H1 → warn

Всего в наборе инструментов 64 теста — сюда входят ещё проверка микроразметки и прокси для фетча. Прогон занимает 43 миллисекунды.

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

Что проверить в своём llms.txt перед публикацией

  1. H1 первой значимой строкой, ровно один. Всё остальное — после.

  2. Описание цитатой сразу под заголовком. Обычный абзац, курсив или размещение после первой секции спецификации не соответствуют.

  3. Внутри секций только буллеты со ссылками. Подробный текст выносится в описание или в отдельную страницу.

  4. Все ссылки на https:// . Относительные пути модель развернуть не сможет.

  5. Файл отдаётся как text/plain и не редиректит. Проверяется одним curl -I.

Что запомнить

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