llms.txt: кто его на самом деле читает и нужен ли он вашему сайту

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

Коротко о выводе: llms.txt существует, у него есть автор и написанные правила, а в августе 2026 года вышла их вторая редакция. При этом ни одна крупная ИИ-компания публично не заявляла, что читает такой документ на чужих сайтах, а серверные логи ста тридцати семи тысяч доменов показывают, что почти никто его и не запрашивает. Это не повод отказываться — это повод понимать, за что вы платите работой.

Дальше — что предписывает спецификация, что говорят справки Google, OpenAI, Anthropic и Яндекса, что показали два независимых исследования на логах и кому такой документ действительно приносит пользу. Всё, что мы утверждаем ниже, проверено прямыми запросами к первоисточникам 17 августа 2026 года; ссылки стоят по тексту.

Что такое llms.txt и что о нём говорит спецификация

Это один файл llms.txt в формате Markdown, который лежит по адресу /llms.txt и представляет сайт языковой модели: чем сайт занимается и какие материалы на нём главные. Предложил его Джереми Ховард из Answer.AI — на сайте llmstxt стоят его имя и дата первой публикации, 3 сентября 2024 года. В поиске название набирают и с точкой, и как «llms txt» — на суть это не влияет.

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

Единственная обязательная секция — заголовок

Спецификация описывает содержимое строго и по порядку:

1. Необязательная метка порядка байтов в начале.
2. Заголовок H1 с названием проекта или сайта. Это единственная обязательная секция.
3. Цитата-блок с кратким описанием проекта — тем, без чего непонятно остальное.
4. Ноль или больше блоков Markdown любого типа, кроме заголовков: абзацы, списки, пояснения о том, как читать перечисленные материалы.
5. Ноль или больше секций, разделённых заголовками H2, — перечни адресов.

Содержимое файла llms.txt задано жёстко: каждая строка перечня обязана содержать ссылку вида [название](адрес), после которой можно поставить двоеточие и примечание. Вот минимальный корректный пример файла:

# Название сайта

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

Пояснение: как пользоваться этим перечнем.

## Документация

- [Быстрый старт](https://example.com/docs/start.md): с чего начать
- [Справочник API](https://example.com/docs/api.md): все методы и параметры

## Optional

- [История изменений](https://example.com/changelog.md)

Секция Optional — соглашение для второстепенного: то, что агент может пропустить, когда контекст ограничен.

Чем это не является

Тут стоит быть жёстким, потому что путаница в терминах — источник большей части завышенных ожиданий.

• Это не robots.txt. Несмотря на похожее имя, llms.txt ничем не управляет и ничего не закрывает. В нём нет директив, которые кто-то обязан исполнять. Доступом краулеров по-прежнему управляет robots.txt.
• Это не карта сайта. Разница между файлом llms.txt и sitemap.xml принципиальная: карта перечисляет все индексируемые адреса для поисковых роботов, а тут — отобранная руками выжимка, и в неё нормально положить адрес чужого сайта, если без него ваш продукт не понять.
• Это не микроразметка. Структурированные данные описывают сущности внутри страницы, а llms.txt описывает сайт снаружи. Разбор микроразметки мы вынесли в отдельный материал блога.
• Это не стандарт. Ни в реестре IETF, ни в рекомендациях W3C такого документа нет, и сам автор называет его предложением. Формулировка «новый веб-стандарт» из десятков статей — редакторская вольность: стандарт проходит через рабочую группу и публичный процесс, а тут ни того, ни другого не было.

Отдельно про отклонённую альтернативу. Автор разбирает вариант с каталогом /.well-known/ из RFC 8615 и объясняет, почему пошёл другим путём: адреса /.well-known/ существуют только в корне домена, а публиковать llms.txt должен уметь и тот, кто владеет одной папкой на общем хосте — например проектом на GitHub Pages.

В августе 2026 вышла версия 2, и русскоязычные руководства её ещё не описывают

Мы разобрали десять страниц из ТОП-10 Яндекса по этому запросу. Все десять описывают первую редакцию. Между тем 10 августа 2026 года предложение обновилось, и страница теперь называется «The /llms.txt file, v2».

Что изменилось

Главная претензия за два года была к находимости: агент получил страницу — как ему узнать, что у неё есть markdown-версия и что где-то лежит описывающий её индекс, не угадывая адрес? Вторая редакция отвечает стандартными отношениями ссылок:

• rel="alternate" с типом text/markdown указывает на markdown-версию конкретной страницы;
• rel="describedby" указывает на llms.txt, который эту страницу покрывает.

Отдавать их можно тегом <link> в HTML или HTTP-заголовком Link: — второй способ работает и для не-HTML ресурсов и настраивается на уровне веб-сервера или CDN, без правки страниц.

Три остальных изменения:

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

llms-full.txt в спецификации нет

Про «расширенную версию» пишут почти все. Мы проверили обе страницы первоисточника целиком: ни в описании формата, ни в списке изменений слово llms-full.txt не встречается ни разу.

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

Кто из ИИ-компаний заявил, что читает его

Это главный вопрос, и ответ ищется не в обзорах, а в справках самих компаний. Мы их открыли.

Google: в справке сказано, что ничего создавать не нужно

Справка Google Search Central «AI-функции и ваш сайт» перечисляет, что делать для попадания в AI Overviews и AI Mode, и заканчивает раздел прямой формулировкой: «Вам не нужно создавать новые машиночитаемые файлы, текстовые файлы для ИИ или разметку, чтобы появиться в этих функциях». Упоминаний llms.txt на этой странице нет ни одного.

При этом у команды Gemini собственный индекс есть: ai.google.dev/api/llms.txt открывается и отдаёт 200. Когда Джона Мюллера из Google прямо спросили в Bluesky, считать ли это одобрением формата, он ответил 20 января 2026 года: «Меня подмывает сказать что-нибудь язвительное, потому что вопрос всплывает слишком часто, но если прямо — нет». Мы сверили формулировку с первоисточником через открытый API Bluesky, а не по пересказу в отраслевых изданиях.

Показательная деталь: у справки Поиска Google, наоборот, ничего нет — developers.google.com/search/llms.txt отдаёт 404. Разные команды внутри одной компании решили по-разному, и это лучшая иллюстрация статуса формата.

OpenAI и Anthropic: в справках краулеров только robots.txt

Справка OpenAI описывает OAI-SearchBot и GPTBot и говорит об одном механизме управления — записях в robots.txt. Наш формат на этой странице упомянут дважды, и оба раза это адрес индекса собственной документации OpenAI, а не заявление о том, что боты читают такое у вас.

У Anthropic картина та же: страница про ClaudeBot сообщает, что боты уважают сигналы «не обходить», исполняя отраслевые директивы в robots.txt, и поддерживают Crawl-delay. Упоминаний llms.txt здесь — ноль.

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

Яндекс: позиции нет, а индекс есть

Официального заявления Яндекса о поддержке формата мы не нашли — ни в справке Вебмастера, ни в блогах поиска. Но справка Яндекс Вебмастера сама отдаёт llms.txt и llms-full.txt, её страницы доступны в markdown с соответствующим типом, а в ответе приходит HTTP-заголовок Link с rel="alternate" и таким же типом — то есть ровно тот механизм находимости, который описан во второй редакции.

Мелкая, но говорящая деталь: правила предписывают для ссылки на сам индекс отношение describedby, а в заголовке Яндекса стоит alternate для обеих ссылок. Формат новый, и его реализуют по-разному даже те, кто взялся его реализовывать.

Отдельно скажем, что у Яндекса есть свой инструмент для темы «видимость в ИИ» — раздел про Алису AI в Вебмастере. К нашему формату он отношения не имеет, и если вас интересует именно российская аудитория ИИ-ответов, смотреть надо туда.

Что показывают серверные логи: два исследования на 137 и 300 тысяч доменов

Заявления — одно, поведение — другое. Публичных данных по теме мало, но два исследования есть, и оба смотрят не на мнения, а на цифры.

Ahrefs, 15 июня 2026, 137 210 доменов. Взяли все домены сервиса веб-аналитики, получавшие трафик в мае 2026 года, проверили корень каждого на ответ 200 и подняли логи всех обращений к /llms.txt, разложив их по user-agent. Результаты:

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

Там же нашлись две отрезвляющие частности: Slackbot, который разворачивает превью в мессенджере, обращался к llms.txt чаще, чем PerplexityBot, а аудит Lighthouse дал двадцать два обращения — примерно одно из тысячи.

SE Ranking, 7 ноября 2025, около 300 000 доменов. Здесь проверяли связь наличия индекса с частотой цитирования домена языковыми моделями. Он нашёлся у 10,13 % доменов. Ни статистический анализ, ни машинное обучение связи не показали, а удаление этой переменной из модели XGBoost её точность улучшило — то есть признак вносил шум, а не сигнал.

Ни одна из двух работ не является экспериментом «до и после» с контрольной группой. Они показывают отсутствие корреляции и отсутствие обращений, но не доказывают, что использование llms.txt не сработает в будущем. Публичного причинного эксперимента по теме на сегодня нет — и это тоже честный результат, а не пробел в поиске.

Почему Lighthouse отмечает то, чего нет, и что мы нашли у себя

В мае 2026 года в Lighthouse появилась экспериментальная категория Agentic browsing, а в ней проверка llms.txt. Именно она подняла новую волну обсуждений: инструмент Google проверяет то, что справка Google объявляет ненужным.

Разберём, что проверка делает на самом деле. В справке Chrome написано буквально следующее: страница помечается, если при получении происходит ошибка сервера; если ничего нет и сервер отвечает 404, аудит помечается как неприменимый, поскольку наличие пока необязательно.

Это меняет весь смысл. Проверка наказывает не за отсутствие, а за неправильный ответ сервера. Ничего нет и честный 404 — вопросов нет. Есть 500 — есть проблема, и проблема не в самом файле.

Теперь неловкая часть. Когда мы садились писать этот материал, https://anyseo.io/llms.txt отдавал HTTP 500 и строку `Internal Server Error` длиной двадцать один байт. Сайт, который занимается видимостью в ответах нейросетей, ронял ровно тот адрес, о котором собирался рассказывать. Пока статья готовилась, файл мы выложили — сейчас он отдаёт 200, и это проверяется за десять секунд.

Интереснее, что вскрылось по дороге. Причину мы нашли в собственном техническом аудите, и она не в отсутствии файла. Обработчик маршрутов исключает из локализации любой путь, содержащий точку, и такие адреса уходят мимо штатного роутинга. То, что физически лежит на диске, отдаётся нормально: robots.txt, sitemap.xml, favicon.ico — 200. А любой несуществующий адрес с расширением возвращает 500 вместо 404.

Проверить это на нас можно прямо сейчас, и результат будет для нас неудобным: /llms-full.txt отдаёт 500, /rss.xml отдаёт 500, выдуманный /nope.txt — тоже 500. Адрес без точки, /nope, честно возвращает 404. То есть выкладка файла закрыла ровно один адрес из всех, а причина осталась и ждёт правки маршрутизации.

Вывод из нашего же случая ровно тот, ради которого стоит читать всю статью: сначала проверьте, какой код отдают несуществующие адреса на вашем домене, и только потом думайте про llms.txt. Серия ответов 500 для робота означает «приходи позже» — он тратит краулинговый бюджет и получает основания считать хост нестабильным. Это дороже любой выгоды от нового формата. Выложить один файл проще, чем починить причину, и именно поэтому так обычно и делают.

Кому это нужно, а кому нет

Здесь придётся отойти от бинарного «внедряйте — не внедряйте», потому что польза распределена крайне неравномерно.

Смысл есть, если у вас документация или API. Это единственный сценарий, где формат работает измеримо. Из данных Ahrefs: в категории ИИ-ботов первым идёт GPTBot, вторым — Claude-Code, оба впереди любых ботов ИИ-поиска. Кодовые агенты действительно ходят за справкой, и им действительно проще получить карту, чем разбирать HTML. Если ваш продукт подключают разработчики, работа окупается.

Смысл есть, если платформа генерирует всё сама. Ряд платформ, CMS и плагинов делают это автоматически. Тогда цена внедрения — ноль, и обсуждать нечего: пусть будет.

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

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

Как настроить llms.txt по второй редакции

Если по разделу выше вы попали в первые две группы — вот порядок работы. Он занимает час, и большая часть часа уходит не на набор текста.

1. Отберите страницы. Не все, а те, без которых продукт не понять: что вы делаете, как начать, справочник, ограничения. Двадцать хороших адресов в файле лучше двухсот.
2. Напишите описание. Одно-два предложения в цитате-блоке, из которых понятно, чем занимается компания и для кого. Это то, что LLM прочитает первым, и по этим двум предложениям она решит, стоит ли идти дальше.
3. Сгруппируйте адреса по секциям H2. Названия секций пишите обычными словами: «Документация», «Примеры», «Тарифы». Каждой строке дайте примечание после двоеточия: агент выбирает по нему, куда идти.
4. Ведите перечень на markdown-версии страниц, если они у вас есть. Именно ради них формат и задуман, иначе агент опять получит HTML с навигацией и рекламой.
5. Положите результат в корень — по адресу /llms.txt. Если вы владеете только подпапкой, кладите в неё: вторая редакция это разрешает, и покрытие распространится на страницы под этим путём.
6. Проверьте живым запросом, что llms.txt работает: файл должен отдавать 200 и тип text/plain. Заодно посмотрите, что отдают несуществующие адреса с расширением.
7. Обновляйте файл вместе с сайтом. Перечень со ссылками на удалённые страницы приносит вред, а не пользу.

Как сделать его находимым

Этот шаг отличает вторую редакцию от первой, и его почти никто не делает. Добавьте в ответ сервера заголовок:

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown",
      </docs/llms.txt>; rel="describedby"

Первое отношение говорит «у этой страницы есть markdown-версия по такому адресу», второе — «а вот индекс, который её описывает». То же самое можно отдать тегами <link> в разметке страницы. Без этого агент обязан угадывать адреса, а угадывать он не будет.

Проверить результат просто: запросите заголовки своей страницы и убедитесь, что Link в ответе есть. Ровно так мы проверяли справку Яндекса — и увидели, что механизм у неё работает. Каталоги вроде llmstxt site собирают примеры чужих реализаций, если хочется посмотреть на живые файлы.

Что на самом деле влияет на попадание в AI-ответы

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

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

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

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

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

Все проверки выполнены 17 августа 2026 года; в тот же день мы выложили у себя llms.txt, о чём сказано в тексте. Формат новый и меняется: правила обновлялись в августе 2026 года, аудит в Lighthouse появился в мае 2026 года. Перед внедрением сверьтесь с первоисточниками — они собраны в конце материала.