- [ Главная ](/ru/) / - [ Блог ](/ru/blog/) / - Лучшие практики llms.txt # Рекомендации по `llms.txt`: как создать понятный файл, который легко поддерживать Практическое руководство по llms.txt: абсолютные URL, фактические описания, понятные разделы и регулярные обновления. Публикация файла не доказывает его использование системой ИИ. Последнее обновление: 6 сентября 2026 г. На этой странице - [ Каким должен быть хороший llms.txt? ](#overview) - [ Что делать ](#dos) - [ Чего НЕ следует делать ](#donts) - [ Именование и структура разделов ](#sections) - [ Написание хороших описаний ссылок ](#descriptions) - [ Раздел Optional ](#optional-section) - [ Поддержание актуальности ](#maintenance) ## Каким должен быть хороший llms.txt? Хорошо составленный файл llms.txt делает одну вещь: даёт системе ИИ надёжный, отобранный быстрый путь к самым важным страницам вашего сайта. Когда фреймворк агента или конвейер RAG читает ваш файл, он сразу должен понять, о чём ваш сайт, какие страницы загрузить для контекста и в каком порядке они важны. Плохо написанный файл, наполненный маркетинговой прозой, относительными URL или всеми страницами сайта, не даёт преимуществ по сравнению со сканированием sitemap.xml. Ценность llms.txt создают отбор и ясность. ## Что ДЕЛАТЬ ### Используйте абсолютные URL-адреса Каждая ссылка в llms.txt должна использовать полный абсолютный URL. Относительные пути не работают, поскольку файл может быть получен клиентом, который заранее не знает ваш домен. ``` # Correct - [API reference](https://example.com/docs/api/): complete endpoint documentation. # Incorrect, relative URL - [API reference](/docs/api/): complete endpoint documentation. ``` ### Напишите фактическую цитату Необязательный (но настоятельно рекомендуемый) блок цитаты сразу после заголовка H1 — первое, что читает система ИИ. Используйте его, чтобы определить ваш сайт или продукт в одном-трёх простых предложениях. Думайте о нём как о машиночитаемом описании, а не рекламной презентации. ``` # Acme > Acme is an open-source inventory management platform for small manufacturers. > It provides real-time stock tracking, supplier integration, and demand forecasting. > Documentation covers setup, configuration, and the REST API. ``` ### Включите 5–15 самых важных страниц Курирование — ключевой смысл. Для большинства сайтов оптимально 5–15 ссылок. Для небольшого сайта документации достаточно меньшего числа. Для крупной платформы с множеством отдельных продуктовых областей можно взять больше, но после 30 ссылок сигнал начинает размываться. Приоритет: quickstart, основные понятия, справочник API, аутентификация и любые страницы, отвечающие на вопросы, которые пользователи чаще всего задают AI-ассистентам о вашем продукте. ### Держите файл в разумных пределах по размеру Спецификация не устанавливает максимальный размер файла, но практические ограничения имеют значение. Файл размером значительно менее 100 КБ можно эффективно получать и обрабатывать. Если ваш llms.txt станет очень большим, подумайте, не относится ли часть содержимого к [llms-full.txt](/ru/llms-full-txt/) вместо этого. ### Добавьте документацию API, если она у вас есть Если у вашего продукта есть API, его справочник почти наверняка будет самым ценным объектом для ссылки. Разработчики часто обращаются к ИИ-ассистентам за помощью с вызовами API, а выдуманный эндпоинт или параметр — самый неприятный вид ошибки ИИ. Ссылка на канонический справочник API снижает этот риск. ### Сохраняйте машиночитаемость Спецификация использует стандартный синтаксис ссылок Markdown: `- [Link text](URL): description.` Не добавляйте HTML, front matter или нестандартное форматирование. Сохраняйте структуру чистой, чтобы любой парсер Markdown мог корректно ее обработать. Пример Проверьте перед публикацией Используйте Валидатор llmtxt.info для проверки файла на соответствие спецификации перед публикацией. Распространённые проблемы: отсутствующий заголовок H1, относительные URL и неправильный синтаксис ссылок. ## Чего НЕ делать ### Не включайте страницы, закрытые авторизацией Ссылки на страницы, требующие входа, не сработают, когда краулер или агент ИИ попытается их получить. Включайте только общедоступные URL. Если важная документация закрыта входом, это стоит исправить отдельно: закрытая документация плохо обнаруживается и людьми. ### Не помещайте маркетинговый текст в blockquote ИИ-системы читают цитату для получения фактического контекста, а не для убеждения людей. Маркетинговая формулировка («ведущее в отрасли решение для...») не помогает ИИ понять, что представляет собой ваш продукт. Помогает фактический и конкретный язык. ### Не используйте относительные URL Относительные URL, такие как `/docs/api/` не являются допустимыми в llms.txt. Всегда используйте полные абсолютные URL с протоколом и доменом. ### Не добавляйте ссылки на каждую страницу сайта llms.txt — не карта сайта. Файл с сотнями ссылок почти не даёт сигнала отбора. Если ИИ-клиенту нужно обнаружить все ваши страницы, для этого у него есть sitemap.xml. llms.txt должен отвечать на вопрос: «если бы вы могли прочитать только 10 страниц, чтобы понять этот сайт, какие 10 страниц вы бы выбрали?» ### Не публикуйте и не забывайте llms.txt устаревает. Если вы удалили указанную страницу, переименовали раздел или опубликовали важную новую документацию, обновите llms.txt, чтобы он отражал изменения. Файл с неработающими ссылками или устаревшими описаниями активно вводит AI-системы в заблуждение относительно вашего содержимого. ### Не включайте URL стенда или перенаправления Ссылайтесь только на канонические URL production-версии. URL staging могут быть защищены паролем, цепочки перенаправлений добавляют задержку, а неканонические URL запутывают системы извлечения, которые отслеживают URL как идентификаторы. ## Названия и структура разделов Спецификация определяет разделы как заголовки Markdown H2 (`##`) со списками ссылок. Названия разделов не стандартизированы: выбирайте их в соответствии с организацией вашего контента. Распространённые варианты: - **Документация** или **Документация**, для сайтов документации. - **Справочник API**, для продуктов с общедоступным API. - **Начало работы**, для продуктов, ориентированных на онбординг. - **Руководства**, для содержимого в формате учебника. - **Блог**, для редакционного контента (пометьте как Optional, если он вторичен). - **Необязательно**, раздел, определённый спецификацией для ссылок с низким приоритетом, которые клиент может пропустить. Выбирайте названия разделов, отражающие организацию вашего содержимого, а не SEO-ключевые слова. ИИ-клиент, читающий файл, понимает естественный язык, поэтому используйте названия, которые ясно показывают структуру. ## Как писать хорошие описания ссылок У каждой ссылки в llms.txt может быть необязательное описание, отделённое от URL двоеточием: ``` - [Page title](https://example.com/page/): what this page contains. ``` Хорошие описания короткие (до 20 слов), фактические и конкретно указывают, о чём страница. Относитесь к ним как к микроаннотациям, а не рекламным текстам. - Хорошо: *"Полный справочник всех конечных точек REST API, включая аутентификацию, ограничения частоты запросов и коды ошибок."* - Плохо: *"Наша первоклассная документация API, которая поможет вам быстро создавать потрясающие интеграции."* - Хорошо: *"Пошаговое краткое руководство для новых пользователей: от создания аккаунта до первого вызова API."* - Плохо: *"Начните сегодня и ощутите силу Acme."* ## Раздел Optional `## Optional` — редакционная метка, а не специальная инструкция обработки в v2. Используйте ее, когда отдельная группа упрощает понимание вторичных ресурсов для людей и совместимых клиентов. Подходящие примеры: - Сообщения блога и редакционный контент, дающие контекст, но не являющиеся технически необходимыми. - Страницы с журналом изменений или примечаниями к выпуску. - Вторичные языковые версии основных страниц. - Страницы FAQ и глоссария полезны, но не являются основным справочным материалом. Не предполагайте, что клиент пропустит, понизит приоритет или иначе обработает этот раздел. Если приоритет важен для рабочего процесса, задокументируйте такое поведение в клиенте, а не выводите его из заголовка. ## Поддерживайте его в актуальном состоянии Простая привычка обслуживания: каждый раз, когда вы публикуете или снимаете с публикации крупную страницу, проверяйте, нужно ли обновить llms.txt. Для крупных сайтов рассмотрите: - Автоматическая генерация llms.txt из структуры навигации или CMS во время сборки. - Добавьте проверку llms.txt в контрольный список публикации контента. - Периодически запускайте [валидатор](/ru/validator/) для обнаружения неработающих ссылок. Если ваш сайт меняется редко, обычно достаточно проверять llms.txt ежеквартально. Если вы публикуете часто, свяжите его с конвейером развёртывания. ## Продолжить чтение - [Лучшие практики (полное руководство)](/ru/best-practices/), десять правил для соответствующего спецификации полезного файла. - [Справочник формата](/ru/llms-txt-format/), полная спецификация с примерами синтаксиса. - [Генератор](/ru/generator/), создайте корректный файл из формы за несколько минут. - [Реальные примеры](/ru/examples/), посмотрите, как Anthropic, Cloudflare и Stripe структурируют свои файлы. ## Источники - [ llmstxt.org, предложение сообщества ](https://llmstxt.org/) - [ Справочник по формату llms.txt, llmtxt.info ](https://llmtxt.info/ru/llms-txt-format/) - [ Рекомендации, llmtxt.info ](https://llmtxt.info/ru/best-practices/)