# Як створити llms.txt

> Покроково: які сторінки відбирати, як написати блок-цитату, як згрупувати секції, куди покласти файл і як перевірити результат.

Джерело: https://llms.com.ua/how-to/ · оновлено 2026-08-12 · llms.com.ua

---

Технічно створити файл — справа десяти хвилин: це звичайний текстовий документ у корені сайту.
Складне інше: вирішити, що саме в нього класти. Нижче — процес, який дає осмислений результат,
а не формально валідний файл заради галочки.

**Крок нуль: чи потрібен він вам**Перш ніж витрачати час, чесно дайте відповідь на питання, чи є у вас _документація_ — довідник, база знань, API, інструкції. Якщо так, файл має сенс. Якщо у вас лендинг чи невеликий комерційний сайт, підтверджених доказів користі немає: див. [дані досліджень](https://llms.com.ua/evidence/). Це не заборона — це чесне попередження про очікування.

## Крок 1. Відберіть сторінки

Головна помилка — почати з переліку всіх розділів сайту. `llms.txt` не sitemap: його цінність саме
в тому, що хтось за агента вже відібрав головне.

Робочий критерій відбору — уявіть конкретне питання, яке людина ставить асистенту про ваш продукт, і спитайте себе: _яка сторінка на нього відповідає_. Ці сторінки й потрібні.

| Тип сайту | Що варто включити |
| --- | --- |
| Документація, API, SDK | Швидкий старт, довідник методів, автентифікація, обмеження, приклади коду, журнал змін |
| SaaS-продукт | Опис продукту, тарифи, інтеграції, база знань, статус сервісу |
| Освітній ресурс | Програма курсів, вимоги до вступу, розклад, контакти приймальної комісії |
| Компанія або агенція | Опис послуг, кейси, команда, контакти, публічні умови роботи |
| Особистий сайт | Резюме, публікації, проєкти, спосіб звʼязку |

Практичний орієнтир кількості — від 5 до 40 посилань. Менше — файл не дає контексту; більше — ви, найімовірніше, перестали відбирати й почали перелічувати.

## Крок 2. Напишіть заголовок і резюме

Заголовок — назва проєкту, без слоганів і ключових слів. Резюме — один-два речення, які відповідають на питання «що це і для кого».

```
# Назва компанії

> Що ви робите, для кого і чим відрізняєтесь — двома реченнями.
> Тут має бути ключова інформація, потрібна, щоб зрозуміти решту файлу.
```

Формально блок-цитата необовʼязкова. Практично — це найважливіший рядок файлу: саме з нього агент розуміє,
чи взагалі варто читати далі. Специфікація описує її як «key information necessary for understanding the rest
of the file».

**Пишіть для машини, але людською мовою**Не треба перелічувати ключові слова через кому. Модель читає це як текст і робить із нього висновки — набір ключів радше зашкодить, ніж допоможе. Пишіть так, як пояснили б колезі за 15 секунд.

## Крок 3. Додайте вільний текст, якщо є що сказати

Після цитати можна дати абзаци чи списки з важливими застереженнями. Це місце для того, що агент інакше
зрозуміє неправильно: обмеження продукту, несумісності, важливі відмінності від схожих рішень.

Класичний приклад із самої специфікації — файл FastHTML, де в цьому блоці попереджають, що бібліотека несумісна з синтаксисом FastAPI попри зовнішню схожість:

_Фрагмент прикладу зі специфікації_

```
Important notes:

- Although parts of its API are inspired by FastAPI, it is *not* compatible with FastAPI syntax
  and is not targeted at creating API services
- FastHTML is compatible with JS-native web components and any vanilla JS library,
  but not with React, Vue, or Svelte.
```

**Тут не може бути заголовків**Специфікація прямо каже: секції цього блоку — «of any type except headings». Один рядок із `###` тут — і офіційний парсер розріже файл не там, де ви очікуєте.

## Крок 4. Згрупуйте посилання в секції H2

Назви секцій довільні. Обирайте їх за логікою користувача, а не за структурою вашої CMS.

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

- [Швидкий старт](https://example.com/docs/start.md): встановлення й перший запит за 5 хвилин
- [Довідник API](https://example.com/docs/api.md): усі методи, параметри й коди помилок
- [Автентифікація](https://example.com/docs/auth.md): як отримати й використати ключ

## Приклади

- [Інтеграція з PHP](https://example.com/examples/php.md): робочий приклад із поясненнями

## Optional

- [Історія змін](https://example.com/changelog.md): журнал релізів
- [Політика приватності](https://example.com/privacy.md)
```

Формат рядка суворий: дефіс, пробіл, `[назва](URL)`, далі необовʼязково двокрапка й опис.

| | Рядок | Чому |
| --- | --- | --- |
| | - [Довідник API](https://site.com/api.md): усі методи | Канонічна форма |
| | - [Довідник API](https://site.com/api.md) | Опис необовʼязковий |
| | - https://site.com/api.md | Не Markdown-посилання — парсер його не бачить |
| | - [Довідник API](/api.md) | Відносна адреса: поза контекстом сайту не розгортається |
| | * [Довідник](https://site.com/a(1).md) | Дужка в URL обриває розбір адреси |

## Крок 5. Дайте посиланням чисті Markdown-версії

Це те, що відрізняє робочий файл від декоративного. Специфікація радить посилатися саме на `.md`-варіанти
сторінок: агент отримує текст без навігації, банерів і скриптів.

На звичайному PHP-хостингу мінімальний варіант — статичні файли поруч:

```
/docs/api.html      ← сторінка для людей
/docs/api.md        ← той самий текст у Markdown
/docs/llms.txt      ← покажчик, що посилається на .md
```

І один рядок у `.htaccess`, щоб сервер віддавав правильний MIME-тип:

```
AddType text/markdown .md
```

Детальніше про це — на сторінці [Markdown-версії сторінок і link relations](https://llms.com.ua/markdown-pages/).

## Крок 6. Покладіть файл на місце

Канонічна адреса — `https://ваш-домен/llms.txt`. Файл має віддаватися з кодом 200 і
`Content-Type: text/plain` або `text/markdown`. Кодування — UTF-8.

Якщо файл описує лише частину сайту, версія v2 дозволяє покласти його в підкаталог:

```
https://example.com/llms.txt          ← покриває весь сайт
https://example.com/docs/llms.txt     ← покриває все під /docs/
```

**Файл треба зберігати без BOM або з ним — байдуже**Версія v2 явно дозволяє byte-order mark. Це рідкісний випадок, коли типова причина головного болю з UTF-8 узаконена специфікацією.

## Крок 7. Перевірте

Формальна перевірка — [наш валідатор](https://llms.com.ua/checker/): він розбирає файл за правилами v2, відтворює поведінку офіційного парсера й показує проблемні рядки.

Функціональна перевірка — та, яку радить сам автор специфікації: дайте асистенту тільки посилання на ваш
`llms.txt` і поставте питання про ваш продукт. Якщо агент знайшов відповідь — файл працює.
Якщо він вигадує або губиться — щось не так із відбором посилань або з описами.

## Крок 8. Тримайте його живим

Застарілий `llms.txt` гірший за його відсутність: він упевнено веде агента на сторінки, яких уже
немає. Внесіть перевірку файлу в той самий процес, у якому ви оновлюєте `sitemap.xml`, і
перевіряйте посилання хоча б раз на квартал.

[ДаліПриклади реальних файлів](https://llms.com.ua/examples/)
[АвтоматизаціяГенератори та плагіни для CMS](https://llms.com.ua/tools/)
[ІнструментПеревірити результат](https://llms.com.ua/checker/)