llms-full.txt: зачем нужен и как правильно заполнить

llms-full.txt — это опциональный файл-компаньон к llms.txt, который вместо ссылок на страницы содержит их полный текст, сконкатенированный в единый Markdown-документ, что позволяет AI-системе получить весь значимый контент сайта одним HTTP-запросом вместо десятков отдельных. Формат определён той же спецификацией llmstxt.org, что и базовый llms.txt, но адаптация файла значительно ниже: по данным Thunderbit на выборке топ-10000 доменов Tranco, валидный llms-full.txt имеют 1.03% сайтов против 5.86% для базового llms.txt — то есть даже среди принявших основной стандарт лишь 17.6% идут дальше и публикуют полную версию. При этом данные Crawlmind по клиентским кейсам показывают 2-4-кратный рост цитируемости у сайтов, опубликовавших llms-full.txt, а исследование OpenHermit фиксирует, что этот файл получает значительно больше реального трафика от AI-агентов, чем базовый llms.txt, причём основной объём запросов приходится на ChatGPT.

Разница между llms.txt и llms-full.txt на практике

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

Разница в объёме между двумя файлами драматическая. По данным OpenHermit, средний llms-full.txt содержит примерно 58 000 слов против примерно 1600 слов в базовом llms.txt — то есть полный файл в среднем крупнее указателя почти в 25 раз. Rankability приводит близкую пропорцию по своей выборке топ-1000 сайтов: среди обнаруженных файлов средний размер llms.txt — несколько килобайт, тогда как медианный размер llms-full.txt у сайтов, публикующих оба файла, составляет 412 КБ, а крупнейший найденный файл — 38 МБ у одного из вендорских документационных хабов.

Технически оба файла используют одинаковый Markdown-синтаксис и размещаются в корне домена, но выполняют принципиально разные задачи в жизненном цикле обработки контента AI-системой. llms.txt отвечает на вопрос "что у вас есть и куда идти за подробностями", llms-full.txt отвечает на вопрос "дайте мне всё содержание сразу, без навигации по сайту".

Кто и зачем на самом деле использует llms-full.txt

Практическая ценность файла завязана на конкретный сценарий использования: retrieval-системы, которым нужен единый offline-корпус для построения собственного индекса, вместо постраничного обхода сайта в реальном времени. Это делает файл особенно полезным для трёх категорий потребителей.

Первая категория — коддинг-агенты и IDE-инструменты (Cursor, GitHub Copilot, Claude Code), которым нужен быстрый offline-доступ к документации библиотеки или API без множественных сетевых запросов во время работы разработчика. Вторая категория — RAG-системы (Retrieval-Augmented Generation), которые заранее индексируют корпус контента в собственную векторную базу и обращаются к llms-full.txt один раз при построении индекса, а не при каждом пользовательском запросе. Третья категория — сами крупные языковые модели при обработке прямых вопросов о конкретном сайте или продукте, когда модель делает browse-запрос и получает максимум контекста за один HTTP-вызов.

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

Данные OpenHermit о трафике подтверждают, что это не теоретическое различие: llms-full.txt получает существенно больше запросов от AI-агентов, чем базовый llms.txt, при этом ChatGPT составляет большинство этих запросов. Это означает, что даже если модель формально прочитала короткий индекс, следующим шагом она с высокой вероятностью запросит именно полный файл, если он опубликован — а если его нет, вынуждена либо довольствоваться урезанным контекстом, либо делать десятки отдельных запросов по ссылкам из базового файла.

Статистика: почему адаптация в разы ниже, чем у llms.txt

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

Общая закономерность вне зависимости от методологии: llms-full.txt внедряют примерно 10-30% тех, кто уже внедрил базовый llms.txt, то есть это вторичное, а не первичное решение. Originality.ai отдельно фиксирует, что рост adoption llms-full.txt опережает рост базового файла в относительном выражении — 107-кратный рост против 8.8-кратного у llms.txt за тот же годовой период, — что говорит о растущем понимании differentiated ценности полного файла среди тех, кто уже знаком со стандартом.

Спецификация и требования к формату

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

Файл должен содержать полный Markdown-текст выбранных страниц, объединённый в один документ, обычно в порядке, соответствующем структуре секций базового llms.txt. Каждая страница внутри файла отделяется явным разделителем — типично horizontal rule (---) или заголовком с исходным URL страницы — чтобы модель могла определить границы между отдельными документами внутри единого файла и при необходимости процитировать источник конкретного фрагмента.

Ключевое требование по объёму, зафиксированное в нескольких независимых разборах: файл не должен превышать примерно 100 КБ по консервативной рекомендации Citevera или до нескольких сотен килобайт по более мягким гайдам, поскольку AI-системы применяют собственные лимиты на объём обрабатываемого контента, а превышение лимита приводит не к ошибке, а к молчаливому обрезанию файла без предупреждения. Citevera прямо указывает: файл на 500 КБ хуже файла на 50 КБ, если превышение вызывает silent truncation — потому что автор не может знать, какие именно страницы модель фактически получила, а какие были отброшены при обрезке.

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

Пошаговый процесс создания llms-full.txt

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

Второй шаг — извлечь чистый текст каждой выбранной страницы в Markdown-формате, убрав навигационные элементы, футер, боковые панели, рекламные блоки и повторяющиеся CTA-кнопки. Для сайтов на статических генераторах (Next.js, Astro, Docusaurus) эта задача решается относительно просто, поскольку контентная часть страницы обычно уже отделена от layout-компонентов на уровне архитектуры приложения; для сайтов на React с client-side рендерингом без SSG может потребоваться отдельный скрипт извлечения текста из отрендеренного DOM.

Третий шаг — объединить извлечённые тексты в единый файл с явными разделителями между страницами. Практика 2026 года использует чаще всего простой паттерн: горизонтальная линия (три дефиса на отдельной строке), затем заголовок H1 или H2 с названием страницы и опционально комментарий с исходным URL, затем сам текст страницы.

Четвёртый шаг — проверить итоговый размер файла и, если он превышает разумный порог, пересмотреть список включённых страниц в пользу более сжатого набора, а не пытаться поместить весь корпус контента целиком. Лучше 15 тщательно отобранных страниц в файле на 60 КБ, чем 80 страниц в файле на 800 КБ, часть которого будет отброшена при обработке моделью без предупреждения.

Пятый шаг — опубликовать файл по пути /llms-full.txt в корне домена с корректным HTTP-заголовком Content-Type: text/markdown или text/plain, аналогично требованиям к базовому llms.txt, и добавить ссылку на него из самого llms.txt, обычно в виде отдельного пункта или примечания в конце файла.

Автоматизация генерации для сайтов на статических генераторах

Для проектов на React с SSG-рендерингом процесс создания llms-full.txt можно частично автоматизировать на этапе сборки, поскольку контент страниц на момент генерации уже существует в структурированном виде — как markdown-файлы, MDX-компоненты или данные из CMS, из которых страницы рендерятся. Практический паттерн — написать build-скрипт, который на этапе постпроцессинга сборки собирает контент выбранных страниц из исходных данных (а не из финального HTML, что избавляет от необходимости парсить вёрстку), удаляет технические артефакты (frontmatter, импорты компонентов) и записывает итоговый результат в public/llms-full.txt рядом с базовым llms.txt.

Для документационных платформ вроде Mintlify эта задача уже решена на уровне платформы — начиная с ноября 2024 года Mintlify автоматически генерирует оба файла, llms.txt и llms-full.txt, для всех сайтов, размещённых на платформе, без дополнительной настройки со стороны владельца документации. По данным OpenHermit, именно этот автоматический rollout стал основным драйвером роста общей adoption llms.txt среди developer-tooling сайтов — большая часть прироста пришла не от осознанного индивидуального внедрения, а от платформенной автоматизации.

Важное отличие ручной и автоматизированной генерации: платформенные генераторы (Mintlify, некоторые плагины для WordPress вроде All in One SEO) создают технически валидный файл по формальным критериям спецификации, но не гарантируют редакционного качества описаний и осознанного отбора контента. Web Almanac 2025 обнаружил, что около 40% файлов llms.txt в его выборке были именно такими автосгенерированными стабами без реальной кураторской работы — та же проблема потенциально применима и к автоматически сгенерированным llms-full.txt файлам, где отбор страниц сделан по формальному правилу (например, "все страницы документации"), а не по продуманному приоритету ценности для модели.

Ограничения и риски избыточного контента

Помимо риска молчаливой обрезки при превышении лимита объёма, есть менее очевидная проблема — размывание сигнала при включении слишком большого количества второстепенного контента. Если файл содержит 200 страниц вперемешку с ключевыми и малозначимыми материалами, модель тратит контекстное окно на обработку низкоценного контента, что снижает относительную заметность действительно важных фактов о бизнесе внутри общего объёма файла.

Отдельный риск — рассинхронизация с реальным контентом сайта. Поскольку llms-full.txt — это статичный снепшот контента на момент генерации, при любом обновлении исходных страниц (изменение цены, обновление описания услуги, добавление нового кейса) файл начинает противоречить актуальному состоянию сайта, если не пересобирается автоматически. Для сайтов с часто меняющимся коммерческим контентом (актуальные цены, акции, наличие товаров) рекомендуется либо настроить автоматическую регенерацию файла при каждом деплое как часть CI/CD-пайплайна, либо вовсе исключить быстро меняющиеся страницы из выборки для llms-full.txt, оставив в файле только относительно статичный контент — описание услуг, кейсы, документацию.

Наконец, стоит учитывать общий контекст ценности файла для рынка, где сайт публикуется. Данные Ahrefs о том, что 97% файлов llms.txt не получают вообще ни одного запроса, распространяются и на компаньон-файл: если сайт не относится к категориям с высокой фактической adoption AI-агентами — developer tooling, документационные платформы, AI-native продукты — трудозатраты на поддержание актуального llms-full.txt могут не окупаться реальным использованием файла системами, ради которых он создаётся.

Пример структуры реального файла

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

# Like Sites — полный контент для AI-систем

> Полный текст ключевых страниц сайта Like Sites: веб-студии разработки на React с фокусом на GEO-оптимизацию и SEO.

---

## Главная страница
URL: https://like-sites.ru/

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

---

## Услуги: Разработка сайтов
URL: https://like-sites.ru/razrabotka/

Полный цикл разработки сайта на React включает: анализ конкурентов,
проектирование архитектуры, дизайн, вёрстку, интеграцию CMS, SEO-настройку
и запуск. Средний срок разработки лендинга — 7-14 дней, многостраничного
корпоративного сайта — 21-30 дней...

---

## Цены
URL: https://like-sites.ru/tseny/

Стоимость лендинга на React начинается от 90 000 рублей и включает дизайн,
вёрстку, базовую SEO-настройку и хостинг на первый год. Стоимость
многостраничного сайта — от 180 000 рублей...

---

## Optional: О компании
URL: https://like-sites.ru/o-nas/

Like Sites работает на рынке разработки сайтов с 2022 года, специализируясь
на технологическом стеке React, Vite и Node.js...

Обратите внимание на три структурных детали этого примера. Во-первых, каждый блок начинается с horizontal rule (три дефиса), что даёт модели чёткий визуальный и синтаксический маркер границы между документами. Во-вторых, под каждым заголовком указан исходный URL как явный комментарий-метаданные — это позволяет модели при цитировании факта сослаться на конкретную страницу-источник, а не на файл llms-full.txt целиком. В-третьих, порядок блоков в файле повторяет приоритизацию из базового llms.txt: сначала главная страница, затем ключевые коммерческие разделы, в конце — второстепенный контент из секции Optional.

Разграничение ответственности между llms.txt, llms-full.txt и Schema.org

При построении GEO-стратегии полезно чётко понимать, какую задачу решает каждый из инструментов, поскольку они не конкурируют друг с другом, а закрывают разные этапы того, как AI-система получает и интерпретирует информацию о сайте.

Из этого разделения следует практический вывод: наиболее устойчивая архитектура AI-видимости сайта комбинирует все четыре уровня, а не полагается на один инструмент. robots.txt открывает доступ нужным ботам, llms.txt даёт быструю навигационную карту, llms-full.txt (там, где оправдан) избавляет модель от множественных запросов, а Schema.org на самих страницах обеспечивает извлекаемость конкретных проверяемых фактов — именно последний уровень, по совокупности данных крупных GEO-исследований 2026 года, вносит наибольший вклад в фактическую цитируемость, тогда как первые три создают инфраструктурные условия для доступа и удобства обработки.

Влияние на скорость и стоимость AI-обработки сайта

Помимо вопроса цитируемости, у llms-full.txt есть менее очевидный, но практически значимый эффект — снижение вычислительной нагрузки на сторону AI-системы при обработке запроса о сайте. Каждый отдельный HTTP-запрос, который модель делает для получения страницы по ссылке из базового llms.txt, добавляет задержку в цепочку обработки запроса пользователя: сетевой round-trip, парсинг ответа, решение о необходимости следующего запроса. Если модели нужно последовательно открыть пять-семь страниц сайта, чтобы собрать полный контекст для ответа, суммарная задержка может значимо увеличить время генерации ответа или даже привести к тому, что модель остановится раньше, не дойдя до всех релевантных страниц из-за ограничений на число инструментальных вызовов за один диалоговый ход.

llms-full.txt устраняет эту проблему архитектурно: один запрос вместо серии, предсказуемый объём данных вместо неопределённого числа round-trip. Для систем, работающих в режиме реального времени с жёсткими ограничениями на латентность ответа пользователю — а именно к этой категории относится большинство коммерческих AI-поисковых интерфейсов, — такая экономия может определять, попадёт ли сайт в число реально обработанных источников при формировании ответа, или модель ограничится более быстро доступными альтернативами и не станет исследовать сайт глубже одного запроса.

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

Чек-лист перед публикацией

Перед тем как выкладывать файл в продакшн, стоит пройти через короткую проверку, снижающую риск типовых ошибок, зафиксированных в разборах реальных файлов 2026 года.

• Файл отдаётся по адресу /llms-full.txt в корне домена с HTTP-статусом 200, а не через редирект или под авторизацией
• Content-Type заголовок установлен как text/plain или text/markdown, а не application/octet-stream, вызывающий принудительное скачивание
• Общий размер файла не превышает разумный порог (ориентировочно 100 КБ для консервативного подхода), чтобы избежать silent truncation
• Каждая включённая страница отделена явным разделителем и сопровождена исходным URL как справочной меткой
• В файле нет пагинации, тег-архивов, страниц с авторизацией и юридического шаблонного текста (условия использования, политика конфиденциальности)
• Быстро меняющийся контент (актуальные цены, наличие, акции) либо исключён из файла, либо файл пересобирается автоматически при каждом деплое
• В базовом llms.txt есть явная ссылка на llms-full.txt, чтобы модель, прочитавшая индекс, знала о существовании полной версии
• Файл провалидирован одним из доступных инструментов (llms-txt.io/validator, agent-ready.dev/llms-txt-checker) на соответствие базовому Markdown-синтаксису