Как создать llms.txt для сайта: полный гайд 2026

llms.txt — это Markdown-файл в корне сайта (/llms.txt), который даёт AI-системам структурированную карту важнейших страниц для использования при ответах на вопросы пользователей. Формат предложил Джереми Ховард из Answer.AI в сентябре 2024 года на llmstxt.org, единственный обязательный элемент — заголовок H1 с названием проекта, далее следуют блок-цитата с описанием, произвольный текст и секции H2 со списками ссылок. По данным на май-июнь 2026 адаптация среди топовых доменов колеблется от 4.2% до 28% в зависимости от методологии выборки, при этом Ahrefs зафиксировал, что 97% опубликованных файлов не получают вообще ни одного запроса. Google официально исключил файл из сигналов ранжирования в Search и AI Overviews, тогда как Anthropic и Perplexity, по имеющимся данным, действительно используют его при retrieval-запросах о конкретном домене.

Зачем нужен llms.txt и кто его реально читает

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

Ключевой вопрос практической ценности файла — кто его на самом деле использует. Здесь данные расходятся по источникам, но общая картина складывается достаточно ясная. Google в июне 2026 года выпустил официальное руководство по AI-оптимизации для поиска, где прямо написано: "Вам не нужно создавать новые машиночитаемые файлы, AI text файлы, разметку или Markdown, чтобы появляться в generative AI search". Это прямой отказ признавать llms.txt сигналом для Google Search и AI Overviews.

При этом Anthropic (Claude) и Perplexity публично указывали, что читают файл при наличии и используют его для информирования retrieval-процесса. Perplexity в частности использует его как первичный индекс для запросов вида "что делает [бренд]" — именно такие вопросы полезно проверять при аудите видимости. ChatGPT через browse-инструмент запрашивает корень домена инцидентально при обосновании ответов о конкретном сайте, но OpenAI не подтверждала официально использование файла как фактора ранжирования в ChatGPT Search.

Даже с учётом ограниченного круга систем, которые системно читают файл, есть и другая сторона использования: файл активно применяется AI-ассистентами разработчика — Cursor, Claude Code, GitHub Copilot — для быстрой ориентации в документации проекта без парсинга полного сайта. Это объясняет, почему адаптация выше среди developer-tooling SaaS (18.7% по данным Crawlmind) и документационных хабов на Docusaurus, Mintlify и Nextra (9.4%), и заметно ниже среди мейнстримного SaaS (2.1%), новостных изданий (0.6%) и государственных сайтов (0.1%).

Статистика адаптации: три разные картины одного явления

Цифры адаптации llms.txt по разным исследованиям 2026 года различаются в разы, и разница объясняется не противоречием данных, а разницей выборок.

Разброс от 2% до 28% объясняется тем, что выборки Ahrefs и SE Ranking смещены в сторону технически подкованных и SEO-осведомлённых сайтов, использующих их аналитику, тогда как выборки по случайному топ-10000 доменов дают более консервативную и, вероятно, более репрезентативную цифру в диапазоне 4-10%. Важная деталь: по данным Chris Humphrey Research, адаптация практически не растёт с ростом авторитетности сайта — топ-100 доменов лидируют с 11%, но дальше показатель колеблется между 6% и 9% вплоть до 10 000-й позиции, а домены с рангом 2000-5000 внедряют файл даже активнее, чем домены с рангом 500-1000.

Ещё более показательный сигнал дало исследование Signals.sh: среди 50 самых цитируемых доменов в мире AI-системами llms.txt использует только один — Target.com, и ни один из топ-20 медиа- и издательских доменов файл не публикует вообще. Параллельный аудит ALLMO проанализировал 94 614 процитированных URL в 11 867 AI-ответах и нашёл ровно один URL из llms.txt-файла — 0.00105693% от всех цитирований.

llms.txt vs robots.txt vs llms-full.txt: разграничение

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

Принципиальный момент: llms.txt физически не может ничего заблокировать — в нём нет ни одной директивы разрешения или запрета. Это чистый content map, "тур-гид", а не "вышибала". Если стоит задача не допустить AI-краулер к определённым разделам сайта, единственный работающий инструмент — robots.txt с явными правилами для User-agent GPTBot, ClaudeBot, Google-Extended, PerplexityBot, CCBot и Bytespider.

llms-full.txt — это компаньон-файл, который вместо ссылок на детальные материалы содержит их полный текст, обычно в конкатенированном виде. По данным Thunderbit, adoption llms-full.txt составляет всего 1.03% против 5.86% для базового llms.txt — то есть даже среди сайтов, внедривших llms.txt, лишь малая часть создаёт полную версию. Практический смысл llms-full.txt — избавить модель от необходимости делать десятки отдельных запросов по ссылкам из llms.txt, отдав весь корпус контента одним файлом, что особенно полезно для документационных сайтов и AI-ассистентов разработчика, которым нужен offline-доступ к полному корпусу без множественных HTTP-запросов.

Точная структура файла по спецификации llmstxt.org

Спецификация определяет шесть элементов в фиксированном порядке, из которых обязателен только один.

1. Byte-order mark (BOM) — опциональный технический маркер кодировки, практически никогда не используется в реальных файлах.
2. H1 с названием проекта или сайта — единственный обязательный элемент спецификации. Ровно один заголовок первого уровня, первая содержательная строка файла.
3. Блок-цитата с кратким описанием — краткое summary, содержащее ключевую информацию, необходимую для понимания остального файла. Технически опционально, но конвенционально считается частью минимально полезного файла.
4. Произвольные Markdown-секции без заголовков — абзацы, списки любого типа, кроме заголовков, с дополнительным контекстом о том, как интерпретировать остальные файлы.
5. Секции H2 со списками файлов — заголовки второго уровня, под каждым из которых идёт список ссылок вида [название](url): заметка. Ноль или более таких секций.
6. Секция "## Optional" — специальная секция с зарезервированным именем, содержащая ссылки на второстепенные материалы, которые можно пропустить при ограниченном контекстном окне модели.

Пример минимально валидного файла:

# Like Sites

> Веб-студия разработки сайтов на React с фокусом на GEO-оптимизацию, SSG-рендеринг и SEO для малого и среднего бизнеса в России.

Like Sites специализируется на создании быстрых, полностью индексируемых сайтов на React с pre-rendering (SSG), которые попадают в ответы Яндекс Нейро, ChatGPT и Perplexity с первого дня публикации.

## Услуги

- [Разработка сайтов](https://like-sites.ru/razrabotka/): создание сайтов на React SSG под ключ
- [SEO-оптимизация](https://like-sites.ru/seo/): техническое SEO, Schema.org, GEO-оптимизация
- [Готовые решения](https://like-sites.ru/gotovye-resheniya/): типовые сайты под 8 отраслевых ниш

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

- [Как мы работаем](https://like-sites.ru/kak-rabotaem/): этапы разработки от брифа до запуска
- [Цены](https://like-sites.ru/tseny/): стоимость по форматам сайтов

## Optional

- [О нас](https://like-sites.ru/o-nas/): история компании и команда

Ключевое правило по количеству ссылок: практическая рекомендация индустрии — 10-30 самых важных страниц, а не исчерпывающий список всех URL сайта. Файл должен работать как курируемый гид, а не как дубликат sitemap.xml. Загромождение файла сотнями ссылок снижает его практическую пользу для модели, которая читает его для быстрой ориентации, а не для полного индексирования.

Пошаговый процесс создания файла

Первый шаг — определить приоритетные страницы для включения. Это не технический процесс автогенерации, а редакционное решение: какие 10-30 страниц сайта наиболее полно и точно представляют бизнес, продукт или контент. Для коммерческого сайта это обычно страницы услуг, ключевые лендинги, страница "о нас", контакты и, при наличии, документация или база знаний.

Второй шаг — написать summary в блок-цитате. Это должно быть 1-3 предложения, отвечающие на вопросы: кто это, что делает, для кого. Именно этот блок AI-система использует для формирования базового понимания сущности бренда при site-grounded запросах — по аналогии с тем, как meta description формирует сниппет в классическом поиске.

Третий шаг — сгруппировать ссылки по логическим секциям H2. Типичная группировка для коммерческого сайта: "Услуги", "Документация", "Кейсы", "Optional". Для документационного сайта — "Getting Started", "API Reference", "Guides", "Optional". Внутри каждой секции ссылки оформляются как [название](url): заметка, где заметка — не повтор заголовка, а дополнительный контекст о содержании страницы.

Четвёртый шаг — публикация файла на пути /llms.txt в корне домена с корректным HTTP-заголовком Content-Type. Критическая техническая деталь, которую упускают многие реализации: заголовок должен быть text/plain или text/markdown, не application/octet-stream и не заголовок, вызывающий принудительное скачивание файла вместо отображения его как текста. Ошибка в этом заголовке — одна из причин, почему исследование Chris Humphrey Research отсеяло треть найденных "файлов" как soft-404, отдающие HTML-страницу вместо реального Markdown.

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

Частые ошибки при внедрении

Практика показывает несколько повторяющихся проблем в реальных файлах. Web Almanac 2025 обнаружил, что 39.6% "файлов" в их выборке были не осознанным решением владельца сайта, а автоматической генерацией по умолчанию от плагина All in One SEO — то есть формально файл существует, но не содержит редакционно выверенного контента и часто представляет собой шаблонную заготовку без реальной пользы.

Chris Humphrey Research отметил, что только 55% найденных файлов содержат все три ключевых элемента одновременно — H1, summary и структурированные H2-секции; остальные 45% страдают от отсутствия summary, отсутствия секций вообще или неструктурированной "стены ссылок" без группировки. Такой файл технически существует по адресу /llms.txt, но не выполняет функцию курируемого гида, ради которой он создавался.

Отдельная категория ошибок — блокировка собственного файла через WAF или CDN. Рекомендуется явно проверять серверные логи на входящие запросы от GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot и Applebot к пути /llms.txt за последние 30 дней. Если запросов ноль, а файл при этом опубликован корректно, вероятная причина — правило WAF или защита от ботов блокирует эти user-agent на уровне CDN раньше, чем запрос доходит до файла. Решение — явный allow-лист для перечисленных user-agent на уровне CDN, размещённый выше любых географических, репутационных или rate-limit блокировок.

Наконец, значительная часть владельцев сайтов не поддерживает файл в актуальном состоянии после первой публикации. Спецификация не предполагает автоматической синхронизации — при добавлении или удалении крупных разделов сайта файл нужно вручную пересматривать, иначе он начинает указывать на устаревшие или удалённые страницы, что напрямую снижает его полезность для AI-систем, которые всё же его читают.

Как проверить, что файл работает

Проверка состоит из нескольких уровней возрастающей сложности. Базовый уровень — фетч-тест: открыть https://вашдомен.ру/llms.txt в приватном окне браузера и убедиться, что сервер отдаёт HTTP 200, тело ответа — читаемый Markdown-текст, а заголовок Content-Type корректен.

Следующий уровень — валидация структуры через специализированные инструменты. На рынке несколько бесплатных валидаторов: llms-txt.io/validator проверяет соответствие H1, blockquote, синтаксис Markdown-ссылок и наличие компаньона llms-full.txt; agent-ready.dev/llms-txt-checker выполняет 10 проверок, включая HTTP Content-Type заголовок; pixelmojo.io/tools/llms-txt-validator идёт глубже базовой структуры и оценивает распознавание сущностей и полноту контента по 100-балльной шкале.

Третий уровень — анализ логов сервера на реальные обращения ботов к файлу за 30-дневный период, отфильтрованный по user-agent GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot и Applebot. Нулевой результат при корректно опубликованном файле указывает на блокировку на уровне инфраструктуры, а не на отсутствие интереса со стороны AI-систем.

Четвёртый, наиболее прямой уровень — брендовый тест в Perplexity. Задать системе прямой вопрос о бренде ("Что делает [название компании]?" или "Предлагает ли [бренд] [конкретную услугу]?") и проверить, какие именно URL система цитирует в источниках. Если процитированные ссылки совпадают со страницами, перечисленными в llms.txt, файл реально влияет на retrieval. Если Perplexity цитирует случайные страницы сайта, не входящие в файл, вероятная причина — недостаточная сущностная ясность описаний в самом файле, а не проблема с его наличием.

Реальные примеры от Stripe, Vercel и GitHub

Разбор действующих файлов крупных технологических компаний показывает, как теория спецификации превращается в практику. Stripe организует свой /llms.txt вокруг ключевых продуктовых зон — Payments, Billing, Connect, Tax — зеркально повторяя архитектуру собственного API, а не структуру навигационного меню сайта. Каждая ссылка ведёт не на HTML-страницу, а на её Markdown-версию с суффиксом .md, что избавляет модель от необходимости парсить вёрстку.

Наиболее примечательный элемент файла Stripe — нестандартная секция "Instructions for Large Language Model Agents", отсутствующая в базовой спецификации llmstxt.org, но добавленная как расширение. В ней Stripe прямо указывает моделям поведенческие правила интеграции: приоритизировать Payment Intents API над устаревшим Charges API, использовать Checkout Sessions вместо legacy Card Element, при работе с существующими интеграциями на старых API советовать миграцию с конкретной ссылкой на гайд. Это превращает файл из чистого content map в поведенческую инструкцию для AI-агентов, которые помогают разработчикам писать код интеграции — практика, которую отраслевые обзоры называют более значимым нововведением, чем сам факт наличия файла.

Vercel и GitHub придерживаются похожей продуктовой группировки: секции H2 соответствуют не структуре меню сайта, а логическим доменам использования продукта. Общая практика у всех разобранных примеров — короткие, ёмкие описания при каждой ссылке (не "API Reference", а "Payments API: Charges and Payment Intents"), что даёт модели больше контекста при выборе, какую страницу открыть для конкретного вопроса пользователя.

Полный список AI-краулеров для проверки логов

Для трактовки результатов лог-анализа важно различать боты по функциональному назначению, поскольку не все они одинаково влияют на видимость в AI-ответах. Индустриальная классификация 2026 года делит краулеров на три категории.

Практический вывод из этой классификации: если цель — попадание в цитируемые ответы Perplexity и Claude здесь и сейчас, приоритет для allow-листа на CDN — это PerplexityBot, Claude-SearchBot и OAI-SearchBot, а не GPTBot и ClaudeBot, которые влияют лишь на обучение будущих версий моделей без немедленного эффекта на текущую видимость. Блокировка GPTBot в robots.txt не повлияет на способность ChatGPT цитировать сайт в реальном времени — за это отвечает OAI-SearchBot, работающий независимо.

Для верификации, что запрос действительно пришёл от заявленного бота, а не от подделки user-agent-строки, рекомендуемая практика — обратный DNS-поиск по IP из лога с последующей прямой проверкой полученного хостнейма. Настоящий краулер OpenAI резолвится в хостнейм, заканчивающийся на openaibot.com, у Anthropic — в домен, принадлежащий компании; если обратное или прямое разрешение не совпадает с исходным IP, запрос почти наверняка подделан и не должен учитываться при аналитике реального трафика AI-систем.

Место llms.txt в общей GEO-стратегии сайта на React

Для сайтов на React с SSG-рендерингом внедрение llms.txt технически проще, чем для динамических SPA: статически сгенерированные страницы уже существуют как готовые HTML-файлы на этапе сборки, и добавление одного дополнительного текстового файла в корень публикации не требует изменений в серверной логике или маршрутизации. Файл размещается рядом с robots.txt и sitemap.xml в директории public, откуда попадает в корень домена при деплое без дополнительной конфигурации.

Важно не путать роль llms.txt с ролью Schema.org разметки и SSR/SSG-рендеринга в общей задаче видимости для AI-поисковых систем. Структурированные данные (FAQPage, LocalBusiness, Product) и полностью пререндеренный HTML остаются основным каналом, через который AI-краулеры и системы вроде Яндекс Нейро извлекают проверяемые факты о бизнесе. llms.txt в этой архитектуре занимает вспомогательную позицию — он подсказывает, куда идти за такими фактами, но не заменяет их наличие на самих страницах. Сайт с сильной Schema-разметкой и слабым или отсутствующим llms.txt в текущих данных 2026 года получает больше практических цитирований, чем сайт с образцовым llms.txt, но слабой структурированной разметкой на самих целевых страницах.

Нужен ли llms.txt на самом деле

Совокупность данных 2026 года формирует взвешенную, а не однозначно позитивную или негативную картину. С одной стороны, файл — это стандарт с растущей, хотя и неравномерной адаптацией, официально читаемый минимум двумя значимыми AI-системами (Claude, Perplexity) и полезный для широкого класса coding-агентов. Публикация файла требует минимальных трудозатрат — по сути, это статичный текстовый документ без необходимости серверной логики.

С другой стороны, объективные данные Ahrefs о 97% файлов без единого запроса и данные Signals.sh о практическом отсутствии llms.txt среди самых цитируемых AI-системами доменов мира прямо говорят: файл не является ни необходимым, ни достаточным условием попадания в AI-ответы. Google официально исключил его как сигнал для своих генеративных поверхностей, которые остаются крупнейшим источником AI-трафика на русскоязычном рынке через Яндекс Нейро (по аналогичной логике технологической архитектуры).

Практический вывод для владельца коммерческого сайта: llms.txt стоит внедрить как одну из многих мер технической готовности к AI-поиску, но не как главную или единственную ставку в GEO-стратегии. Основной вес в видимости для генеративных систем несут структурированные данные Schema.org, чистая семантическая разметка контента, атомарные факты, пригодные для извлечения моделью, и общая E-E-A-T-репутация домена — эти факторы подтверждённо влияют на цитируемость во всех крупных исследованиях GEO 2026 года, тогда как llms.txt остаётся во многом экспериментальным и вспомогательным элементом с ограниченным и неравномерным охватом среди AI-платформ.