# Специфікація llms.txt

> Офіційна специфікація llms.txt v2 (серпень 2026) у перекладі та з коментарями: обовʼязкові й необовʼязкові секції, порядок елементів, синтаксис списків посилань.

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

---

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

**Статус документа**`llms.txt` — це **пропозиція** (proposal), а не стандарт. Вона не проходила через IETF, W3C чи інший орган стандартизації. Текст живе на [llmstxt.org](https://llmstxt.org/) і в репозиторії [AnswerDotAI/llms-txt](https://github.com/AnswerDotAI/llms-txt). Це важливо розуміти: жоден бот не зобовʼязаний його виконувати.

## Суть пропозиції

Специфікація формулює задачу так: вебсторінки зроблені для людей. HTML загортає інформацію в навігацію,
рекламу та JavaScript, і зворотне перетворення на чистий текст складне й неточне. Контекстні вікна моделей,
хоч і виросли, все одно замалі для сайту цілком, а кожен зайвий токен коштує часу й грошей.

> «We propose adding a `/llms.txt` markdown file to websites to provide LLM-friendly content.
> The file can be placed at the site root, or at any path within it, covering the pages under that path.»
> «Ми пропонуємо додавати на сайти Markdown-файл `/llms.txt`, щоб надати контент, зручний для мовних
> моделей. Файл можна розмістити в корені сайту або за будь-яким шляхом усередині нього — тоді він покриває
> сторінки під цим шляхом.»
> [llmstxt.org](https://llmstxt.org/)

Ключова ідея — **розділення покажчика й деталей**. Сам файл лишається малим: у ньому назва,
коротке резюме та перелік посилань. Уся глибина живе за посиланнями й підвантажується лише тоді, коли агенту
це справді потрібно.

## Формат: секції в суворому порядку

Специфікація перелічує секції в порядку, у якому вони мають іти у файлі:
- **Необовʼязковий byte-order mark (BOM)** — три байти `EF BB BF`. У v2 дозволено явно.
- **H1 з назвою проєкту або сайту.** Це _єдина обовʼязкова секція_.
- **Блок-цитата з коротким резюме** — ключова інформація, потрібна для розуміння решти файлу.
- **Нуль або більше Markdown-секцій** будь-якого типу, _окрім заголовків_: абзаци, списки тощо. Тут детальніші пояснення про проєкт і про те, як інтерпретувати надані файли.
- **Нуль або більше секцій, розділених заголовками H2**, які містять «переліки файлів» — URL, за якими доступні подробиці.
- Кожен «перелік файлів» — це Markdown-список, у якому обовʼязкове гіперпосилання `[назва](URL)`, а далі необовʼязково двокрапка й нотатки про файл.

**Порядок має значення**Заголовки не можна використовувати у вільному тексті (пункт 4). Практично це означає: після блок-цитати й до першого `##` у файлі не повинно бути жодного `#`. Інакше офіційний парсер розріже файл не там, де ви очікуєте.

### Еталонний приклад зі специфікації

_Мок-приклад із тексту специфікації_

```
# Title

> Optional description goes here

Optional details go here

## Section name

- [Link title](https://link_url): Optional link details

## Optional

- [Link title](https://link_url)
```

## Як це насправді розбирається

Формальний опис словами доповнює референсна реалізація на Python. Саме її регулярні вирази є найточнішим
визначенням формату — якщо текст специфікації й парсер розходяться, парсер виграє на практиці, бо ним
користуються інструменти.

_llms_txt/core.py — фрагменти, що визначають формат_

```
# розбиття на секції за H2
start, *rest = re.split(fr'^##\s*(.*?$)', txt, flags=re.MULTILINE)

# рядок-посилання
title = named_re('title', r'[^\]]+')
url   = named_re('url',   r'[^\)]+')
desc  = named_re('desc',  r'.*')
pat = fr'-\s*\[{title}\]\({url}\){desc_pat}'

# блок заголовка
pat = fr'^#\s*{title}\n+{summ_pat}\n+{info}'
```

З цих виразів випливають цілком конкретні наслідки, про які варто знати:

| Особливість парсера | Наслідок для вашого файлу |
| --- | --- |
| URL читається як [^\)]+ | Кругла дужка ) всередині адреси обриває розбір. Кодуйте її як %29. |
| Назва читається як [^\]]+ | Квадратна дужка ] у тексті посилання ламає конструкцію. |
| Розбиття йде по ^## | Заголовок ### теж потрапляє під шаблон і стає секцією з назвою, що починається з #. Не використовуйте H3. |
| Секції складаються у словник за назвою | Дві секції з однаковою назвою — друга мовчки перезаписує першу. Дублікати назв неприпустимі. |
| Для рядка-посилання застосовується search, а не fullmatch | Текст перед дефісом толерується, але покладатися на це не варто. |
| Якщо шаблон H1 не збігся, повертається None | Файл без H1 призводить офіційний парсер до помилки виконання. Це не «попередження», а відмова. |

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

## Розміщення файлу

Файл має називатися саме `llms.txt`. Канонічне місце — корінь: `/llms.txt`.
Версія v2 дозволила підкаталоги й описала, що це означає:

> «A file covers the URLs under its path, and where more than one file applies, agents should use the most specific one.»
> «Файл покриває URL під своїм шляхом, а якщо підходить кілька файлів, агенти мають використовувати найбільш
> конкретний.» [llmstxt.org](https://llmstxt.org/)

Практичний приклад: `/docs/llms.txt` описує все, що лежить під `/docs/`. Якщо на сайті є
і `/llms.txt`, і `/docs/llms.txt`, то для сторінки `/docs/api/` застосовується
другий. Ця зміна зʼявилася, зокрема, щоб проєкти на GitHub Pages, які контролюють лише свій підкаталог,
могли повноцінно брати участь.

**Чому не /.well-known/**Специфікація прямо розглядає альтернативу — стандарт Well-Known URIs (RFC 8615) — і відхиляє її: файли `/.well-known/` існують лише в корені домену, а багато авторів контролюють тільки шлях на спільному хості. Крім того, `llms.txt`, як і `index.html`, описує саме той шлях, де лежить, — а єдине кореневе розташування такого висловити не може.

## Що змінилося у версії v2

Перша версія вийшла у вересні 2024 року, коли сама ідея регулярного читання сайтів мовними моделями була
радше прогнозом. Версія v2 (10 серпня 2026) зафіксувала те, що показали два роки практики.

| Тема | Було у v1 | Стало у v2 |
| --- | --- | --- |
| Виявлення файлу | Нічого не сказано | Додано link relations: rel="alternate" type="text/markdown" та rel="describedby", у тому числі через HTTP-заголовок Link: |
| Markdown-версії сторінок | Лише page.html.md | Дозволено й page.md — заміну розширення, бо частина інструментів робить саме так |
| Підкаталоги | Дозволялися, але без пояснення сенсу | Визначено: файл покриває сторінки під своїм шляхом, застосовується найбільш конкретний |
| Секція Optional | Мала механічне значення для інструменту llms_txt2ctx | Втратила механічне значення; лишилася домовленістю про другорядні посилання |
| Модель споживання | Описувалося розгортання файлу в контекст | Прямо сказано: агент переглядає або шукає у файлі, потім іде за релевантними посиланнями |
| BOM | Не згадувався | Дозволений явно |

**Більшість валідаторів досі перевіряють v1**Це практична проблема. Інструменти, які позначають `/docs/llms.txt` як помилку «файл має бути в корені», або ті, що вимагають «правильного» використання секції `Optional`, перевіряють правила, яких у чинній версії вже немає.

## Співіснування з наявними стандартами

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

Щодо `robots.txt` формулювання ще чіткіше: у них різні призначення. robots.txt повідомляє
автоматизованим інструментам, який доступ до сайту вважається прийнятним. Інформація з llms.txt натомість
використовується _на вимогу_, коли агенту потрібні відомості з певної теми під час допомоги користувачу.

**Тренування чи інференс**Автор специфікації прямо зазначає очікування: `llms.txt` має бути корисним переважно для **інференсу**, а не для **тренування** — і саме так його й використовують, хоча тренувальні прогони теж могли б скористатися цією інформацією.

## Рекомендації автора щодо змісту

Специфікація завершується короткими практичними порадами:
- використовуйте стислу, ясну мову;
- додавайте до посилань короткі інформативні описи;
- уникайте двозначних термінів і непоясненого жаргону;
- перевіряйте файл так: дайте агенту лише ваш `llms.txt` як стартову точку й ставте запитання про ваш контент.

Остання порада — найкорисніша й найчастіше ігнорована. Це функціональний тест, який показує, чи вистачає агенту вашого покажчика, щоб знайти відповідь.

[ДаліMarkdown-версії сторінок і link relations](https://llms.com.ua/markdown-pages/)
[ПрактикаЯк створити llms.txt покроково](https://llms.com.ua/how-to/)
[ІнструментПеревірити файл на відповідність v2](https://llms.com.ua/checker/)