llms.txt: нужен ли он сайту и как сделать правильно

llms.txt - это Markdown-файл в корне сайта с кратким описанием проекта и списком ключевых страниц для языковых моделей и агентов. Формат предложил Джереми Говард в сентябре 2024 года. С тех пор генераторы llms.txt появились в Yoast SEO и AIOSEO, файл публикуют документации Anthropic, Perplexity и Яндекса, а в Chrome Lighthouse есть отдельный аудит. При этом ни одна крупная AI-платформа не подтвердила, что читает этот файл, а Google прямо пишет, что поиск его игнорирует.

По данным Ahrefs за май 2026 года, 97% файлов llms.txt за месяц не получили ни одного запроса. К остальным 3% обращались в основном SEO-аудиторы и прочие боты: на названных AI-ботов пришлось 19,5% запросов.

Статья о том, что подтверждено про llms.txt, а что нет, кому файл действительно нужен, как сгенерировать его из контента и проверить в CI, зачем рядом с ним нужны .md-версии страниц и как измерить эффект. Примеры взяты из блога futurecraft.pro: генератор, инцидент с битыми ссылками, сокращение файла со 111 до 31,5 КБ.

Что такое llms.txt и чем он отличается от robots.txt и sitemap.xml

Спецификация опубликована на llmstxt.org. Цель файла - дать агенту краткий контекст о сайте и ссылки на подробные материалы, причём сам файл должен быть достаточно компактным, чтобы поместиться в контекст модели.

Формат по порядку:

1. H1 с названием проекта. Это единственный обязательный элемент.
2. Blockquote с кратким описанием.
3. Произвольные абзацы и списки без заголовков: ключевые факты, оговорки, указания.
4. Ноль или больше разделов H2, каждый из которых содержит список ссылок вида [name](url): заметка.
5. Раздел ## Optional: ссылки, которые агент может пропустить, если контекста не хватает.

Файл лежит в /llms.txt или в подпути, например /docs/llms.txt; если подходит несколько файлов, агент берёт самый специфичный. Отдельно спецификация предлагает отдавать чистую Markdown-версию каждой страницы по тому же адресу с суффиксом .md (page.html.md или page.md, для адресов без имени файла index.html.md). Для обнаружения этих версий предлагаются rel="alternate" type="text/markdown", для самого llms.txt rel="describedby", в теге <link> или в HTTP-заголовке Link:.

llms.txt - предложение одного автора, а не стандарт IETF или W3C. За ним нет процесса стандартизации, и никто из тех, кто мог бы читать файл, не брал на себя обязательств.

Главное отличие от robots.txt в том, что llms.txt ничего не разрешает и не запрещает. Если цель - пустить или не пустить AI-ботов, работать нужно с robots.txt.

Кто читает llms.txt: что подтверждено, а что нет

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

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

Публикация собственных файлов тоже ничего не доказывает. У Anthropic есть llms.txt документации со ссылкой на llms-full.txt, у Perplexity - docs.perplexity.ai/llms.txt, у Яндекса - llms.txt документации API Вебмастера. Это значит, что компании считают файл полезным для своих документаций, но не значит, что их краулеры читают llms.txt на чужих сайтах.

Позиция Google и Lighthouse: два разных сигнала

В мае 2026 года Google опубликовал руководство по оптимизации под генеративный поиск (анонс в Search Central Blog, 15 мая 2026). В разделе про llms.txt и специальную разметку сказано: Google Search эти файлы не использует и игнорирует, на видимость сайта они не влияют ни в плюс, ни в минус, а поддерживать их для других систем можно. Страница AI features and your website добавляет общий принцип: для показа в AI-функциях поиска не нужны новые машиночитаемые файлы, AI-текстовые файлы или разметка.

Джон Мюллер из Google высказывался на эту тему дважды. В июне 2025 года он написал в Bluesky, что ни одна AI-система сейчас не использует llms.txt (пересказ Search Engine Roundtable). В июне 2026 года, по пересказу Search Engine Journal выпуска подкаста Search Off the Record, он объяснил, почему файл не помогает выбирать источники: llms.txt заполняет сам владелец сайта, поэтому по нему нельзя отличить один сайт от другого. Узкая роль возможна, когда агент уже работает с сайтом.

Chrome Lighthouse смотрит на llms.txt с другой стороны. Его аудит llms.txt описан в разделе документации про agentic browsing и проверяет одно: не отвечает ли сервер ошибкой на запрос файла. Сам файл Chrome называет формирующейся конвенцией (emerging convention). Если файла нет и сервер отдаёт 404, аудит получает статус Not Applicable, потому что файл пока необязателен. Это сигнал для браузерных агентов, а не фактор ранжирования.

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

Данные логов: что видно и чего не видно

Самый крупный замер - исследование Ahrefs, опубликованное 15 июня 2026 года. Ahrefs взял 137 210 доменов с трафиком из своей Web Analytics за май 2026 года.

Оговорки, которые делают сами авторы, важнее цифр. Запрос файла не означает, что модель использовала его содержимое. Запросы получили только около 1,1 тыс. доменов (около 22 тыс. запросов), и разбор ботов построен на этой части. Выборка смещена к техническим сайтам клиентов Ahrefs, поэтому 28% - оценка сверху. Соответствие файлов спецификации не проверялось.

Отдельные наблюдения практиков расходятся. SEO-специалист Рэй Мартинес показывал логи, где OpenAI запрашивал его llms.txt примерно каждые 15 минут (Search Engine Roundtable, июль 2025); другие замеры на небольших выборках видят от AI-ботов единичные запросы или ноль. Логи одного сайта не говорят ничего о поведении платформы в целом.

Для собственного сайта логи - единственный честный способ ответить на вопрос «читают ли мой файл». В блоге futurecraft.pro такого замера нет: логов запросов к /llms.txt у автора нет, а Метрика и GA4 ботов не видят. Поэтому утверждать, что файл что-то дал этому сайту, не на чем.

Нужен ли llms.txt вашему сайту

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

Если сайт на WordPress, генератор есть в Yoast SEO (в том числе в бесплатной версии) и в AIOSEO. Mintlify и GitBook из списка на llmstxt.org генерируют файл сами, для VitePress и Docusaurus есть плагины. Писать свой генератор имеет смысл, когда контент лежит в репозитории, как в случае статического сайта на Astro, Hugo или Next.js.

Как выглядит правильный llms.txt

Минимальный файл по спецификации для условной документации API:

# Example API

> Документация REST API сервиса Example: аутентификация, эндпоинты, SDK для Python и TypeScript.

Все примеры используют API v2. Версия v1 отключена с 2026-01-01.

## Docs

- [Быстрый старт](https://example.com/docs/quickstart.md): ключ API и первый запрос
- [Аутентификация](https://example.com/docs/auth.md): OAuth 2.0 и сервисные токены
- [Справочник API](https://example.com/docs/api.md): все эндпоинты с параметрами

## Optional

- [Changelog](https://example.com/docs/changelog.md): история версий API

Правила, которые вытекают из спецификации и из практики:

• Десятки ссылок. Файл задуман как оглавление, архив целиком туда не нужен. Всё второстепенное уходит в ## Optional.
• Описание у каждой ссылки. Агент выбирает страницу по заметке после двоеточия, поэтому заметка должна говорить, что внутри, а не повторять заголовок.
• Свободный текст - до первого H2. Парсеры трактуют каждый раздел H2 как список ссылок. Ключевые факты и указания по цитированию лучше держать абзацами после blockquote.
• Ссылки на .md, если они есть. Спецификация просит вести ссылки на контент, удобный для LLM, например на Markdown-версии страниц.
• Только живые адреса. Каждая ссылка должна отдавать 200, иначе агент получит битый маршрут.

Как сгенерировать llms.txt из контента

Когда статьи лежат в Markdown с frontmatter, llms.txt удобно собирать скриптом при каждой сборке. В блоге futurecraft.pro (Astro, около 130 статей в двух локалях) этим занимается scripts/generate-llms.mjs. Источник данных - frontmatter постов, разобранный через gray-matter: заголовок, описание, дата, обновление. Черновики с draft: true отфильтровываются, статьи сортируются по дате.

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

function buildArticlesSection(heading, articles) {
  const lines = articles.map((a) => {
    const desc = a.description ? ` ${a.description}` : '';
    const updated = a.updated ? ` Updated: ${formatDate(a.updated)}.` : '';
    return `- [${a.title}](${a.url}):${desc} Published: ${formatDate(a.date)}.${updated}`;
  });
  return `## ${heading}\n\n${lines.join('\n')}\n`;
}

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

- name: Regenerate llms.txt
  run: node scripts/generate-llms.mjs

- name: Build
  run: npm run build

Тот же подход работает для любого генератора статических сайтов: единый источник правды - Markdown и frontmatter, а llms.txt, RSS и sitemap собираются из него. Подробнее о контенте в Markdown как основе всего пайплайна публикации - в статье про AI Content Engine.

Проверка ссылок в CI

В августе 2026 года в llms.txt блога оказались ссылки на страницы категории news в обеих локалях. Опубликованных статей в этой категории не было, Astro такие маршруты не строит, и ссылки отдавали 404. Человек этого не заметил бы, а агент, который пошёл бы по оглавлению, получил бы битый адрес. В том же файле нашёлся литеральный плейсхолдер <slug>.md в примере для агентов.

Исправлений два. Генератор собирает множество категорий, в которых есть опубликованные статьи, и вырезает ссылки на пустые. А SEO-аудит сборки читает dist/llms.txt, вытаскивает все внутренние URL и проверяет, что для каждого в сборке есть страница:

const llms = fs.readFileSync(path.join(distDir, 'llms.txt'), 'utf8');
if (Buffer.byteLength(llms) > 50_000) {
  errors.push(`llms.txt is ${Buffer.byteLength(llms)} bytes; keep it under 50 KB`);
}
const internalUrls = new Set(
  [...llms.matchAll(/https:\/\/futurecraft\.pro[^)\s]+/g)].map((m) => m[0]),
);
for (const url of internalUrls) {
  const pathname = localPath(url);
  if (!pathname || !generatedTargetExists(pathname)) {
    errors.push(`llms.txt: broken internal link ${url}`);
  }
}

Проверка размера появилась позже, вместе с сокращением файла. Плейсхолдер заменили живым адресом /blog/mcp-security-guide.md.

Размер: было 111 КБ, стало 31,5 КБ

Первая версия llms.txt блога была оглавлением всего архива: 347 строк, 111 245 байт (около 33 КБ после gzip). В ней были H1 и blockquote, ключевые факты, главные страницы и категории в двух локалях, по строке на каждую из примерно 130 статей на английском и столько же на русском, указания по цитированию и раздел о Markdown-версиях.

С духом спецификации такой файл расходился в двух местах. Во-первых, размер: 111 КБ - это десятки тысяч токенов, а спецификация просит файл, который помещается в контекст. По сути получился полный индекс, ближе к практике llms-full.txt. Во-вторых, ключевые факты, указания по цитированию и заметка о Markdown стояли под заголовками H2, а парсеры ждут в каждом H2 список ссылок.

В новой версии 151 строка и 31 564 байта (около 9,6 КБ после gzip):

• Преамбула без заголовков: H1, blockquote, ключевые факты, указания по цитированию и заметка о .md-версиях идут абзацами до первого H2.
• Main pages: главные страницы сайта на двух языках.
• Key articles: 22 ключевые статьи в каждой локали. Это опорные гайды и страницы, которые чаще всего цитирует Copilot по данным Bing Webmaster Tools.
• Latest articles: 10 последних статей на каждую локаль, кроме уже попавших в ключевые.
• ## Optional: страницы категорий, RSS-ленты и sitemap. Через них агент доберётся до остального архива.

Две проверки держат файл в этих рамках. Генератор падает, если статья из списка ключевых не опубликована в какой-то локали, поэтому список нельзя забыть обновить после снятия статьи:

function featuredArticles(articles, locale) {
  const bySlug = new Map(articles.map((a) => [a.slug, a]));
  const missing = FEATURED_SLUGS.filter((slug) => !bySlug.has(slug));
  if (missing.length > 0) {
    throw new Error(`FEATURED_SLUGS not published in ${locale}: ${missing.join(', ')}`);
  }
  return FEATURED_SLUGS.map((slug) => bySlug.get(slug));
}

Вторая проверка - лимит 50 КБ в SEO-аудите и в смоук-тесте продакшена. Порог выбран с запасом над текущими 31,5 КБ, чтобы файл не разросся незаметно.

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

.md-версии страниц: что дают и как их отдать

Если llms.txt - оглавление, то .md-версия страницы - это само содержимое без вёрстки, меню и скриптов. Агенту не нужно разбирать HTML, и в контекст уходит меньше токенов. В отличие от llms.txt, у .md-версий есть наблюдаемый след: в отчёте AI Performance в Bing Webmaster Tools Copilot цитирует адрес /blog/prompt-library-template.md отдельно от HTML-версии той же статьи.

В блоге .md-версии устроены из четырёх частей.

1. Статический эндпоинт. Файлы src/pages/blog/[slug].md.ts и src/pages/ru/blog/[slug].md.ts при сборке создают /blog/<slug>.md и /ru/blog/<slug>.md для каждой опубликованной статьи нужной локали. Тело - заголовок, blockquote с описанием и строкой «автор, дата, канонический URL», затем исходный текст статьи:

export async function GET({ props }: APIContext) {
  const entry = (props as { entry: CollectionEntry<'blog'> }).entry;
  const slug = entry.slug.replace(/^en\//, '');
  const url = `${SITE}/blog/${slug}/`;
  const date = new Date(entry.data.date).toISOString().slice(0, 10);

  const lines = [`# ${entry.data.title}`, ''];
  if (entry.data.description) lines.push(`> ${entry.data.description}`);
  lines.push(`> Author: Roman Belov · Published: ${date} · Source: ${url}`, '', entry.body.trim(), '');

  return new Response(lines.join('\n'), {
    headers: { 'Content-Type': 'text/markdown; charset=utf-8' },
  });
}

Эндпоинт отдаёт исходник как есть, поэтому стоит проверить, что в нём нет импортов и MDX-компонентов. В статьях блога вне блоков кода их нет. Где в исходнике встречается обычный HTML, он и попадает в .md.

2. Согласование по заголовку Accept. Cloudflare Pages Function functions/_middleware.js перехватывает GET к адресу статьи с Accept: text/markdown (или с параметром ?format=md) и отдаёт готовый .md по каноническому URL:

const accept = context.request.headers.get('Accept') || '';
const wantsMd = accept.includes('text/markdown') || url.searchParams.get('format') === 'md';
const isArticle = /^\/(?:ru\/)?blog\/[^/]+\/?$/.test(url.pathname)
  && !url.pathname.includes('/category/') && !url.pathname.endsWith('.md');

if (context.request.method === 'GET' && wantsMd && isArticle && context.env.ASSETS) {
  const mdUrl = new URL(url.pathname.replace(/\/$/, '') + '.md', url.origin);
  const mdResp = await context.env.ASSETS.fetch(mdUrl);
  if (mdResp.ok) {
    return new Response(mdResp.body, {
      status: 200,
      headers: { 'Content-Type': 'text/markdown; charset=utf-8', 'Vary': 'Accept' },
    });
  }
}

Vary: Accept здесь обязателен: без него CDN может закэшировать Markdown и отдать его браузеру по тому же URL.

3. Ссылка из HTML. Layout добавляет в <head> статьи <link rel="alternate" type="text/markdown" href="/ru/blog/<slug>.md">, как предлагает спецификация.

4. Заголовки ответа. В public/_headers:

/blog/*.md
  Content-Type: text/markdown; charset=utf-8
  X-Robots-Tag: noindex, follow
  Link: <https://futurecraft.pro/blog/:splat/>; rel="canonical"

/ru/blog/*.md
  Content-Type: text/markdown; charset=utf-8
  X-Robots-Tag: noindex, follow
  Link: <https://futurecraft.pro/ru/blog/:splat/>; rel="canonical"

noindex убирает .md из поискового индекса, чтобы он не конкурировал с HTML-страницей. rel="canonical" сводит сигналы к HTML-версии; его добавили в октябре 2026 года как раз после того, как .md-адрес появился среди цитируемых Copilot страниц. Проверить заголовки на продакшене можно одной командой (адрес ведёт на Markdown-версию статьи о безопасности MCP):

curl -sI https://futurecraft.pro/ru/blog/mcp-security-guide.md \
  | grep -iE '^(content-type|x-robots-tag|link):'

Ссылки и картинки внутри .md эндпоинт переписывает в абсолютные (https://futurecraft.pro/ru/blog/...), не трогая блоки кода. В исходнике статьи они относительные, и агент, который получил файл без базового адреса, не смог бы по ним перейти. Одна оговорка остаётся: сам llms.txt ведёт на HTML-адреса статей, хотя спецификация советует ссылаться на контент, удобный для LLM, например на .md. Способ получить Markdown описан в преамбуле файла: суффикс .md или заголовок Accept. Довод за HTML-ссылки - в ответе ассистента должен оказаться канонический адрес страницы, а не служебный. Довод против - агенту приходится делать лишний шаг. Оба варианта рабочие.

llms.txt и GEO: что влияет на цитирование на самом деле

GEO (generative engine optimization) - работа над тем, чтобы AI-ассистенты брали страницы сайта источником ответа. Про llms.txt часто пишут как про главный инструмент GEO, хотя подтверждений этому нет. Больше влияют вещи, за которыми стоят документированные механизмы.

robots.txt для AI-ботов. Именно он решает, пустят ли краулер на сайт. В robots.txt блога явно разрешены боты OpenAI, Anthropic и Perplexity (OAI-SearchBot, GPTBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User), а также токены Google-Extended и Applebot-Extended. Закрыты CCBot, Bytespider и meta-externalagent: в файле они помечены как массовые краулеры для обучения. Ошибка в robots.txt может убрать сайт из ответов, а ошибка в llms.txt ни на что подтверждённо не влияет.

Доступный HTML. Текст должен читаться из HTML без исполнения JavaScript. Мюллер в том же выпуске подкаста, по пересказу SEJ, советует для обнаружения обычные HTML-страницы и внутренние ссылки.

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

Обычная индексация. Copilot ищет материал через индекс Bing, поэтому важно, чтобы страницы туда попали. Как ускорить индексацию через IndexNow и API Яндекс Вебмастера - в отдельной статье про IndexNow и API Вебмастера.

Есть наблюдение с этого сайта, но причинности оно не доказывает. С 6 августа по 5 ноября 2026 года отчёт AI Performance в Bing Webmaster Tools показал 3 536 цитирований 81 страницы блога в Copilot и у партнёров Microsoft, причём по месяцам цитирования росли: 972 в сентябре, 2 028 в октябре. llms.txt, .md-версии и открытый robots.txt работали весь этот период, контрольной группы нет, поэтому приписать рост цитирований llms.txt нельзя. Чаще всего цитируются длинные гайды с определениями и таблицами. Разбор данных - в кейсе GEO на практике: 3 500 цитирований в Copilot.

Чего не ждать от llms.txt и как измерить эффект

Чего не будет:

• Роста позиций в Google. Google прямо пишет, что Search файл игнорирует.
• Гарантии цитирований. Ни одна AI-платформа не обещала учитывать llms.txt при выборе источников.
• Защиты контента. Файл ничего не запрещает. Чтобы закрыть сайт от обучения, нужен robots.txt, а для недобросовестных ботов - правила WAF.
• Ускорения индексации. Это задача sitemap, IndexNow и API поисковых систем.
• Защиты от галлюцинаций и гарантированного прироста. Утверждения вроде «llms.txt предотвращает галлюцинации» или «повышает вероятность цитирования на 20–25%» встречаются в русскоязычных гайдах без источника и методики.

Что можно измерить:

Логи важно сохранять с датами до и после изменений. Без них разговор об эффекте llms.txt остаётся на уровне мнений, и это относится к любому сайту, включая этот.

Чек-лист внедрения llms.txt

1. Решите, нужен ли файл: документация и API - да, блог - по желанию, магазин и лендинг - скорее нет.
2. Проверьте robots.txt: нужные AI-боты не должны быть закрыты.
3. Соберите файл по спецификации: H1, blockquote, свободный текст без заголовков, разделы H2 со ссылками, ## Optional.
4. Ограничьте объём: десятки ключевых ссылок, остальное через страницы категорий, RSS и sitemap в ## Optional.
5. Дайте каждой ссылке описание, которое говорит, что на странице.
6. Генерируйте файл из контента при каждой сборке, а не правьте вручную.
7. Проверяйте в CI, что каждая ссылка в файле ведёт на существующую страницу, и ограничьте размер.
8. Если контент в Markdown, отдавайте .md-версии страниц с X-Robots-Tag: noindex и Link: rel=canonical на HTML.
9. Добавьте <link rel="alternate" type="text/markdown"> на страницы и, по желанию, согласование по Accept: text/markdown с Vary: Accept.
10. Настройте измерение: логи запросов к /llms.txt и .md, AI Performance в Bing Webmaster Tools, аудит Lighthouse.

Источники

• llmstxt.org - спецификация llms.txt (Jeremy Howard, 2024).
• Google Search Central: оптимизация под генеративный поиск и анонс руководства, 15 мая 2026.
• Google Search Central: AI features and your website.
• Chrome Lighthouse: аудит llms.txt.
• Ahrefs: исследование llms.txt, июнь 2026.
• Search Engine Journal: Mueller о llms.txt, июнь 2026.
• Search Engine Roundtable: Mueller в Bluesky, июнь 2025.
• Yoast SEO: генератор llms.txt и AIOSEO: LLMs.txt Generator.