Специфікація 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

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

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

Специфікація перелічує секції в порядку, у якому вони мають іти у файлі:

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13

# 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. Саме її регулярні вирази є найточнішим визначенням формату — якщо текст специфікації й парсер розходяться, парсер виграє на практиці, бо ним користуються інструменти.

1
2
3
4
5
6
7
8
9
10
11

# розбиття на секції за 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}'

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

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

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

Файл має називатися саме 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

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

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

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

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

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

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

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

Специфікація завершується короткими практичними порадами:

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

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