Soubor llms.txt: jak připravit web a dokumentaci pro AI agenty

Web pro AI agenty připravíte ve čtyřech krocích. Do kořene webu nebo sekce dokumentace dejte soubor llms.txt jako stručnou mapu a ke každé důležité stránce nabídněte čistou Markdown verzi. Všechny formáty dokumentace generujte z jednoho zdroje. Nakonec hlídejte odkazy v CI a chování agentů ověřte vlastní sadou úloh.

Co je soubor llms.txt a čím se liší od sitemap.xml?

Soubor llms.txt je kurátorovaný index v Markdownu, který agentovi ukáže, co je na webu důležité. Sitemap.xml jen vypisuje, kde leží všechny stránky.

Agenti čtou weby běžně. Programovací agent si stáhne dokumentaci knihovny, aby správně zavolal API, a asistent s vyhledáváním čte stránky produktu, aby odpověděl na dotaz. Specifikace llms.txt to popisuje jako rutinu, ne jako předpověď. Stránky jsou ale stavěné pro lidi. HTML obaluje informace navigací, reklamami a JavaScriptem. Převod zpět na čistý text je nepřesný a každý zbytečný token stojí čas i peníze. Jak agenti s weby a nástroji pracují, rozebíráme v textu o tom, co dělají AI agenti ve firmě.

Návrh představil Jeremy Howard z Answer.AI 3. září 2024. Verze v2 podle stránky projektu shrnuje poznatky ze dvou let adopce. Že firmy musí produkt a dokumentaci psát i pro agenty, nejen pro lidi, popsala také Iva Brejlová v článku na Lupa.cz z 5. listopadu 2026.

Rozdíl proti robots.txt je v účelu. Robots.txt říká crawlerům, kam smějí. Soubor llms.txt agent načte na vyžádání, když potřebuje informaci k úkolu uživatele. Používá se tedy hlavně při inferenci, ne při trénování modelů.

Srovnání vychází ze specifikace llms.txt v2 a z dokumentace OpenAI k MCP. OpenAI v ní MCP označuje za vznikající průmyslový standard pro rozšiřování modelů o nástroje.

Soubor publikují OpenAI, Anthropic i Gemini pro své vývojářské dokumentace. Lighthouse v Chromu ho kontroluje v rámci auditů agentického prohlížení a podle webu projektu ho mají tisíce webů. Pořád jde ale o komunitní konvenci, ne o ratifikovaný internetový standard typu HTTP.

Jak má soubor llms.txt vypadat a kam ho umístit?

Soubor llms.txt je Markdown s pevným pořadím částí. Umístíte ho do kořene webu nebo do podcesty, například /docs/llms.txt.

Ukázka souboru

Specifikace v2 předepisuje toto pořadí:

• volitelný BOM (byte-order mark),
• nadpis H1 s názvem projektu, jediná povinná část,
• citace (blockquote) se shrnutím klíčových informací,
• libovolné odstavce nebo seznamy bez nadpisů,
• sekce pod H2 se seznamy odkazů ve tvaru název: poznámka.

Soubor pokrývá všechny URL pod svou cestou. Když platí víc souborů, agent má použít ten nejkonkrétnější. Takto může vypadat soubor pro fakturační API:

# Fakturační API

> REST API pro vystavování faktur. Výchozí verze je v2, v1 je deprecated.

Všechny požadavky posílejte s hlavičkou Authorization: Bearer <token>.
Nepoužívejte endpointy v1 pro nové integrace.

## Reference
- [Autentizace](https://example.com/docs/auth.md): získání a obnova tokenu
- [Faktury v2](https://example.com/docs/v2/invoices.md): vytvoření, storno, stránkování
- [Chybové kódy](https://example.com/docs/errors.md): 401, 404, 409, 429 a reakce na ně
- [OpenAPI v2](https://example.com/openapi/v2.json): strojově čitelný kontrakt

## Změny
- [Changelog](https://example.com/docs/changelog.md): změny podle data
- [Migrace z v1 na v2](https://example.com/docs/migrate-v1-v2.md): mapování endpointů

## Optional
- [Integrace s účetními systémy](https://example.com/docs/integrations.md)

Sekce Optional zůstává konvencí pro doplňkové odkazy. Podle přehledu změn jí ale v2 odebrala zvláštní mechanický význam, který byl svázaný s nástrojem llms_txt2ctx.

Odkazy na Markdown verze

Markdown verze stránek leží na stejné URL jako originál. Buď s připojeným .md (page.html.md), nebo s nahrazenou příponou (page.md). U URL bez názvu souboru se připojí index.html.md nebo index.md. Aby agent nemusel tvar URL hádat, odkažte na obě věci standardními vazbami: rel="alternate" type="text/markdown" vede na Markdown verzi a rel="describedby" na pokrývající llms.txt. Vazby jdou zapsat jako HTML <link>, nebo jako HTTP hlavička:

Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"

Dokumentace pro AI agenty se píše jinak než pro lidi. Patří do ní hutný, věcný text s pokyny v rozkazovacím tvaru („Použijte…“, „Nevolejte…“). Klidně může být na dlouhých stránkách. Agent nepotřebuje vizuální zkratky, potřebuje přesné podmínky. V anglických zdrojích se pro tento typ obsahu používá i označení AI agents documentation.

Co do souboru patří a co ne

Soubor má agenta dovést k informacím nutným pro splnění úkolu. Na tom stojí celý kontrolní seznam.

Stejně důležité je, co do souboru nedávat. Každý řádek navíc zabírá kontext a ředí priority.

Rozsáhlý export celé dokumentace patří do samostatného souboru llms-full.txt. Například OpenAI publikuje vedle navigačního llms.txt pro API dokumentaci i kombinovaný export. Navigační soubor má zůstat malý, aby se vešel do kontextu, detail je za odkazy. Kdo nacpe celou dokumentaci přímo do llms.txt, přijde o jeho jedinou funkci, tedy rychlou orientaci.

Jak zajistit jeden zdroj pravdy pro HTML, Markdown a OpenAPI?

Všechny formy dokumentace generujte z jednoho zdroje, nebo je automaticky porovnávejte. Jinak agent dostane protichůdné informace a vybere tu, kterou načte první.

Typický nesoulad vypadá takto. HTML stránka uvádí POST /v2/orders, Markdown verze /v1/orders a OpenAPI obsahuje třetí variantu. Člověk si všimne, že něco nesedí, a napíše na podporu. Agent obvykle zvolí tu, kterou najde jako první, a integraci postaví na špatném endpointu.

Generování z jednoho zdroje

Zdrojem je obvykle repozitář s Markdown soubory a OpenAPI specifikací. Generátor z něj sestaví HTML web, Markdown verze stránek i llms.txt. Pomůže i správa znalostní báze pomocí AI, pokud dokumentace vzniká na víc místech.

flowchart LR
  A["Zdroj: Markdown + OpenAPI v repozitáři"] --> B["Generátor dokumentace"]
  B --> C["HTML pro lidi"]
  B --> D["Markdown verze .md"]
  B --> E["llms.txt"]
  A --> F["OpenAPI kontrakt"]
  C --> G["CI: porovnání a kontrola odkazů"]
  D --> G
  E --> G
  F --> G

OpenAPI je kontrakt, llms.txt jen mapa. Jedno nemá nahrazovat druhé. Soubor llms.txt má na aktuální OpenAPI specifikaci odkazovat, ne ji přepisovat vlastními slovy.

Hlídání nesouladu

Když generování z jednoho zdroje nejde, porovnávejte formy automaticky. Kontrolujte hlavně:

• endpointy a HTTP metody,
• názvy parametrů a hodnoty enumů,
• způsob autentizace,
• příklady požadavků a odpovědí,
• označení deprecated operací.

Na kontrolu konzistence textů se hodí i validace technické dokumentace. Stejně důležité je verzování: dokumentaci k /v1 a /v2 jasně oddělte a v llms.txt uveďte výchozí verzi. Jinak agent sáhne po starší variantě jen proto, že má kratší název.

Náš úsudek z nasazování agentů: soubor patří do běžného publikačního procesu. Ručně psaný llms.txt, který nikdo neaktualizuje s vydáním, podává agentům zastaralá data a působí víc škody než užitku. Pokud podklady k produktu neexistují v udržované podobě, začněte u toho, co popisujeme jako datovou připravenost pro AI.

Jak ošetřit neplatné URL, 404 a přesměrování

Mapujte staré URL na nové, přesměrujte je trvale na tematicky stejné stránky a odkazy v llms.txt opravte přímo. Agenti na chybě 404 obvykle končí a neumějí ji obejít.

Postup odpovídá doporučení Google Search Central pro přesun webu: permanentně přesměrovat staré URL na odpovídající nové. Google zároveň vysvětluje, že 301 signalizuje trvalou změnu. MDN popisuje, že přesměrování používají stavové kódy 3xx s hlavičkou Location a že 308 na rozdíl od 301 nemění metodu požadavku. U změny POST endpointu proto ověřte chování konkrétního klienta.

Kontrolu odkazů v CI zvládne krátký skript nad curl. Ten projde odkazy v llms.txt a selže při chybě, přesměrování nebo špatném typu obsahu:

#!/usr/bin/env bash
# Kontrola odkazů v llms.txt: status, přesměrování, typ obsahu
set -euo pipefail
FILE="${1:-public/llms.txt}"
fail=0
for url in $(grep -oE '\]\(https?://[^)]+\)' "$FILE" | sed -E 's/^\]\(|\)$//g'); do
  # -L následuje redirecty, počet si ale zapíšeme
  read -r code redirects ctype < <(curl -sL -o /dev/null \
    -w '%{http_code} %{num_redirects} %{content_type}\n' "$url")
  if [[ "$code" != "200" ]]; then
    echo "CHYBA $code: $url"; fail=1
  elif [[ "$redirects" -gt 0 ]]; then
    # odkaz funguje, ale v llms.txt má být rovnou cílová URL
    echo "PŘESMĚROVÁNÍ (${redirects}x): $url"; fail=1
  elif [[ "$url" == *.md && "$ctype" != text/markdown* && "$ctype" != text/plain* ]]; then
    echo "ŠPATNÝ TYP $ctype: $url"; fail=1
  fi
done
exit $fail

Shodu titulku s tématem stránky skript neověří. Na tu stačí jednodušší porovnání s názvem odkazu, nebo namátková ruční kontrola při vydání.

Jak otestovat, zda agent dokumentaci chápe

Připravte sadu reálných úloh, nechte je agenta řešit a hodnoťte jeho kroky, nejen výslednou odpověď. Kontrakt API ověřte zvlášť nástroji nad OpenAPI.

U každého běhu ukládejte zvolený nástroj, přesný název operace, předané argumenty a počet kroků. Sledujte také, zda agent po přesměrování použil cílovou URL a zda si nevymyslel endpoint nebo parametr. Právě vymyšlené parametry se v textové odpovědi snadno přehlédnou.

Popis Agent Evals vychází z dokumentace OpenAI. OpenAI v ní doporučuje začít kontrolou jednotlivých trace a teprve potom přejít na datasety a opakovatelné běhy. Tak porovnáte změny promptů, nástrojů a routingu v čase.

Stejná zásada platí pro zákaznickou podporu, kam agenti zákazníků píšou. Odpovídejte strohými fakty: stav, příčina, další krok, odkaz na dokumentaci. Emoční přesvědčování agent neocení a jen zvětšuje prostor pro nepřesnost. Pokud agenty sami nasazujete, navazuje na to téma AI agenti a automatizace.

Nejčastější chyby při nasazení

Většina chyb vzniká z toho, že llms.txt chápeme jako jednorázový marketingový počin místo technického artefaktu.

1. Záměna za úplnou dokumentaci. Soubor bez odkazů na OpenAPI, autentizaci, chybové kódy a limity dá agentovi navigaci bez detailů.
2. Chybějící verzování. Smíchané odkazy na v1 a v2 bez označení výchozí verze vedou agenta k zastaralým endpointům.
3. Nesoulad HTML, Markdownu a OpenAPI. Tři různé verze téhož endpointu jsou horší než žádná dokumentace.
4. Příliš dlouhý marketingový soubor. Výpis všech stránek a reklamní text ruší funkci indexu a zabírají kontext.
5. Špatný rozsah v podcestě. Soubor /docs/llms.txt popisuje jen /docs/, ne celý web. Více souborů s konfliktními odkazy agenta mate.
6. Předpoklad, že každý agent soubor čte. Soubor není součástí žádné závazné specifikace a klient ho číst nemusí. Udržujte proto i kvalitní HTML, OpenAPI, sitemap.xml, hlavičky Link a případně MCP.

Doporučujeme začít malým souborem pro dokumentaci API, napojeným na generátor dokumentace a CI kontrolu odkazů. Rozšiřovat ho má smysl až podle výsledků testovací sady.

Časté otázky

Je soubor llms.txt oficiální standard?

Ne. Jde o návrh konvence, který v září 2024 publikoval Jeremy Howard z Answer.AI a který komunita postupně přijímá. Nemá status ratifikovaného internetového standardu jako HTTP. Přesto ho používají velké AI laboratoře pro své vývojářské dokumentace a Lighthouse ho kontroluje v auditech. Je to tedy rozšířená praxe, na kterou se ale nedá spoléhat jako na závazné pravidlo.

Čte llms.txt každý AI agent?

Nečte. Konvenci podporuje jen část agentů. Další mají vlastní crawlery, připojují se přes MCP, čtou OpenAPI nebo sitemapu, případně pracují s interním indexem. Proto nestačí publikovat jen llms.txt. Udržujte i čisté HTML, aktuální OpenAPI specifikaci a funkční přesměrování. Jak se chovají agenti vašich zákazníků, zjistíte jedině testem na konkrétních úlohách.

Jaký je rozdíl mezi llms.txt a llms-full.txt?

Soubor llms.txt je navigační mapa. Obsahuje stručný popis a prioritizované odkazy a musí se vejít do kontextu modelu. Soubor llms-full.txt je naopak export celé dokumentace v jednom souboru, vhodný pro situace, kdy agent chce načíst všechno najednou. Mnoho platforem publikuje oba. Nemíchejte je: plný obsah v navigačním souboru agentovi orientaci spíš zhorší.

Nahradí llms.txt OpenAPI specifikaci?

Nenahradí. OpenAPI je strojově čitelný kontrakt s endpointy, parametry, schématy a odpověďmi, ze kterého se generují klienti a testy. Soubor llms.txt jen agentovi ukáže, kde tento kontrakt a vysvětlující dokumentace leží. Správné řešení je odkazovat z llms.txt na aktuální OpenAPI soubor a obojí generovat z jednoho zdroje, aby si informace neodporovaly.