Лучшие практики

Десять правил

1. Курируйте. Короткий список страниц с высоким сигналом лучше длинного списка посредственных. Десять — тридцать ссылок могут быть полезной исходной эвристикой, но количество должно определяться предполагаемыми задачами.
2. Используйте абсолютные URL. Всегда https://yourdomain.com/.... Относительные URL технически допустимы, но ненадёжны.
3. Группируйте по продуктовой поверхности. Разделы вроде Продукт, Цены, Разработчики отражают то, как мыслит пользователь (и LLM). Избегайте категорий «блог/документация/руководство», если они не соответствуют реальной навигации вашего сайта.
4. Сохраняйте резюме фактическим. Цитата после H1 должна звучать как начало статьи в Википедии, а не как главный блок посадочной страницы.
5. Одно предложение на элемент. Примечание с двоеточием предназначено для устранения неоднозначности, а не для маркетинга.
6. Используйте Optional используйте экономно. Это очевидное редакционное пространство для прессы, бренд-материалов и архивов, но v2 не придаёт ему особой машинной семантики.
7. Отражайте стабильные URL. Если страница в llms.txt перемещает, обновляет или перенаправляет его. Устаревшие URL подрывают репутацию файла.
8. Опубликовать llms-full.txt только для определённой потребности загрузки. Объединённая документация может помочь известному потребителю, но также увеличивает затраты на размер, актуальность и безопасность.
9. Запустите валидатор в CI. Перенос содержимого, который ломает ваш файл, должен приводить к сбою сборки.
10. Укажите дату файла. Короткая заметка вроде “Последняя проверка: 2026-04-01” в теле полезно и людям, и поисковым роботам.

Распространённые ошибки

• Нет H1. Заголовок H1 — единственный обязательный элемент. Без него файл недействителен.
• Несколько H1. Используйте H2 для разделов. H1 должен быть ровно один.
• Пользовательские front matter. YAML- и JSON-заголовки находятся за пределами опубликованной грамматики и могут заставить совместимые парсеры отклонить файл или неверно его прочитать.
• Вставленные таблицы Markdown или изображения. Сохраняйте вступление сфокусированным и используйте списки ссылок внутри разделов H2. Дополнительные структуры усложняют разбор и часто дублируют связанные страницы.
• Включение URL, защищённых аутентификацией. Если странице требуется вход, не включайте её: LLM упрётся в стену.
• Слишком длинные описания. «самая передовая в мире платформа на базе ИИ для синергетической трансформации нового поколения» не помогает никому. Оставляйте каждую заметку только настолько длинной, насколько нужно для различения назначения.
• Перечисление 500 URL без описания области применения. Перепроверьте задачи, разделите настоящие границы содержимого на файлы уровня пути или предоставьте отдельный ресурс полного содержимого для известного потребителя.
• Непреднамеренная блокировка ресурса. Убедитесь, что каждый объявленный корень или файл на уровне пути доступен в рамках задуманной политики обхода.

Многоязычные сайты

Предложение не предписывает единую архитектуру интернационализации. Распространены два варианта:

1. Один файл на языке по умолчанию в корне. Самый простой вариант, когда перечисленные ресурсы и предполагаемые потребители используют один язык.
2. Варианты для разных локалей. Обслуживайте /llms.txt (по умолчанию), /fr/llms.txt, /es/llms.txt. Ссылайтесь на них из тела корневого файла’s или в разделе Необязательно раздел или объявите применимый файл с помощью rel="describedby" на локализованных страницах.

Какой бы шаблон вы ни выбрали, не дублируйте наборы URL между локалями: каждый вариант должен вести на локализованную версию каждой страницы.

Безопасность и конфиденциальность

• Всё в llms.txt общедоступен. Считайте файл публичным сообщением.
• Никогда не перечисляйте URL тестовой или предварительной версии. Любой клиент, получающий общедоступный файл, может их увидеть.
• Не указывайте URL с секретами в строках запроса. Это кажется очевидным, но мы видели, как такое происходило.
• Если страница открывает пользовательские данные после аутентификации, ей здесь не место.
• Проверяйте файл при каждом выпуске. Утечка URL черновика — самая распространённая ошибка безопасности.

Относитесь к файлу как к внешней конфигурации и не предполагайте, что агенты ему подчиняются. В анализе Ahrefs 137,210 доменов самой крупной строкой user-agent в исследовательской категории была prompt-injection-survey/1.0. Эта метка не доказывает ни атаку, ни личность её организатора, но служит полезным напоминанием: сохраняйте фактическую точность содержимого, проверяйте изменения и ограничивайте возможности любого использующего его агента.

Автоматизация в CI

Считайте llms.txt как любой другой артефакт: генерируйте, проверяйте и ставьте выпуск в зависимость от него.

• Создайте его из источника контента (CMS, коллекции MDX, базы данных).
• Запустите валидатор в CI; завершайте сборку с ошибкой при любой ошибке.
• Сравнивайте файл между релизами и уведомляйте владельца документации о крупных удалениях.
• Проверьте URL рабочей среды после развёртывания: curl -fsS https://yourdomain.com/llms.txt | head -1.

Далее

• Преимущества и ограничения, чего ожидать, а чего нет.
• Примеры из реального мира, скопируйте то, что работает.
• Валидатор.