Po niemal dwóch latach od premiery llms.txt doczekał się pierwszej dużej rewizji. Wersja 2.0 specyfikacji, opublikowana 10 sierpnia 2026 roku, dokłada do formatu to, czego brakowało mu od początku: formalny sposób, w jaki agent AI ma odnaleźć czystą, markdownową wersję konkretnej podstrony. Zmiana jest techniczna, ale jej konsekwencje dotykają każdego, kto próbuje kontrolować to, co modele językowe faktycznie czytają z jego serwisu.
Kontekst: czym w ogóle jest llms.txt
Propozycja llms.txt pojawiła się we wrześniu 2024 roku. Jej autorem jest Jeremy Howard, współzałożyciel Answer.AI, znany wcześniej z fast.ai. Pomysł był prosty i celowo skromny: skoro modele językowe mają ograniczone okno kontekstowe, a typowa strona HTML to w większości nawigacja, skrypty, banery cookie i reklamy, to warto dać agentom osobny plik, który mówi wprost, o czym jest serwis i gdzie leżą najważniejsze treści.
Format celowo nie poszedł w stronę XML czy JSON. llms.txt jest napisany w Markdownie, bo Markdown czytają zarówno ludzie, jak i modele, bez dodatkowego parsera. Struktura pliku wygląda następująco:
- nagłówek H1 z nazwą projektu lub serwisu (jedyny obowiązkowy element),
- blockquote z krótkim streszczeniem, czym jest serwis,
- opcjonalne akapity z kontekstem, którego model nie odgadnie sam,
- sekcje H2 z listami odnośników w formacie
[nazwa](url): opcjonalny opis.
Obok tego funkcjonuje konwencja llms-full.txt, czyli pełny zrzut treści w jednym pliku, dla agentów, które wolą pobrać wszystko naraz zamiast chodzić po linkach. Ta część specyfikacji się nie zmieniła.
Pisaliśmy już o tym, jak zbudować taki plik od zera w poradniku llms.txt jak wdrożyć na stronie. Wersja 2.0 nie unieważnia tamtej instrukcji, tylko ją rozszerza.
Kluczowe fakty: co dokładnie zmienia wersja 2.0
Rewizja skupia się na jednym problemie: w wersji pierwszej llms.txt mówił agentowi, które strony są ważne, ale nie mówił, gdzie znaleźć ich czystą wersję. Agent dostawał listę adresów HTML i musiał sam zgadywać, czy istnieje odpowiednik w Markdownie. Wersja 2.0 zamienia to zgadywanie w formalny mechanizm odkrywania.
| Element | llms.txt 1.0 | llms.txt 2.0 |
|---|---|---|
| Adres wersji Markdown | konwencja strona.html.md | dwa dozwolone wzorce: strona.html.md oraz strona.md |
| Wskazanie wersji Markdown | brak formalnego mechanizmu | rel="alternate" z type="text/markdown" |
| Powiązanie strony z plikiem llms.txt | brak | rel="describedby" |
| Sposób dostarczenia relacji | nie dotyczy | element <link> w HTML lub nagłówek HTTP Link |
| Zakres pliku | domyślnie cały serwis | hierarchia: plik w podkatalogu obejmuje tylko ten katalog |
| Format i sekcje | Markdown, H1 plus blockquote plus listy H2 | bez zmian |
Dwa wzorce adresów zamiast jednego
Do tej pory specyfikacja sugerowała doklejanie rozszerzenia: strona pod adresem /docs/tutorial.html miała mieć markdownowy odpowiednik pod /docs/tutorial.html.md. Ten wzorzec zostaje, ale wersja 2.0 dopuszcza również podmianę rozszerzenia, czyli /docs/tutorial.md. Dla indeksów katalogów analogicznie działa index.html.md albo index.md.
Powód jest praktyczny. Duża część nowoczesnych stacków, od generatorów statycznych po platformy dokumentacji, ma URL-e bez rozszerzeń albo wręcz nie potrafi obsłużyć podwójnego rozszerzenia bez grzebania w konfiguracji serwera. Wymuszanie jednego wzorca skutecznie odcinało te serwisy od standardu.
Dwie nowe relacje linków
Najważniejsza część aktualizacji to formalizacja odkrywania przez atrybut rel. Specyfikacja wprowadza dwie relacje:
rel="alternate"ztype="text/markdown", który ze strony HTML wskazuje jej markdownowy odpowiednik. Agent nie musi już próbować kilku wariantów adresu i liczyć na trafienie w 200. Dostaje wskazanie wprost.rel="describedby", który łączy stronę z obowiązującym dla niej plikiem llms.txt. To odwrotny kierunek niż dotychczas: nie tylko llms.txt wskazuje strony, ale i strona wskazuje swój llms.txt.
W praktyce wygląda to tak, że w sekcji head pojawiają się dwa dodatkowe wiersze deklarujące odpowiednio wersję markdownową dokumentu i plik opisujący. Nic więcej. Żadnego nowego formatu, żadnego dodatkowego endpointu.
Nagłówek HTTP zamiast edycji szablonów
Obie relacje można podać nie tylko w HTML, ale też w nagłówku odpowiedzi HTTP Link. To pozornie detal, a w rzeczywistości najbardziej praktyczna zmiana w całej rewizji, z dwóch powodów.
Po pierwsze, nagłówek da się ustawić na poziomie serwera, CDN-u albo edge workera, bez dotykania szablonów i bez wdrożenia aplikacji. Duże serwisy, w których zmiana w head oznacza sprint i regresję, mogą wdrożyć llms.txt 2.0 w konfiguracji Cloudflare albo Nginx w kilkanaście minut.
Po drugie, nagłówek działa dla zasobów, które nie są HTML-em. PDF, plik JSON, obraz, feed: każdy z nich może teraz wskazać swoją markdownową alternatywę albo opisujący go llms.txt. W samym HTML-u nie było jak tego zrobić.
Jak to wygląda w praktyce
Minimalna zgodność z wersją 2.0 dla pojedynczej podstrony sprowadza się do dwóch deklaracji w sekcji head. Pierwsza mówi agentowi, gdzie leży czysta wersja tego dokumentu, druga wskazuje plik opisujący cały obszar serwisu. Zapis ma postać elementu <link> z atrybutem rel ustawionym odpowiednio na alternate z typem text/markdown oraz na describedby z adresem właściwego llms.txt.
Wariant serwerowy wygląda niemal identycznie, tylko trafia do nagłówka odpowiedzi. Nagłówek Link przyjmuje adres w nawiasach ostrych, po nim parametr rel, a przy wersji markdownowej dodatkowo type. Jeden nagłówek może zawierać kilka wpisów rozdzielonych przecinkiem, więc obie relacje da się podać w jednej linii konfiguracji.
Po stronie WordPressa oznacza to zwykle jeden filtr dopinający deklaracje do nagłówka strony pojedynczego wpisu oraz endpoint albo przepisanie adresu, które zwraca surową treść wpisu jako text/markdown. Warto pamiętać o poprawnym typie MIME, bo serwery domyślnie oddają pliki .md jako zwykły tekst albo, co gorsza, proponują pobranie zamiast wyświetlenia.
Hierarchia i zakres plików
Wersja 2.0 doprecyzowuje coś, co wcześniej było niepisaną praktyką. Plik pod adresem /llms.txt obejmuje cały serwis. Plik pod /docs/llms.txt obejmuje wyłącznie katalog /docs/ i to, co pod nim. Gdy do danej strony pasuje więcej niż jeden plik, agent ma użyć najbardziej szczegółowego.
Dla dużych serwisów z wyraźnie rozdzielonymi sekcjami, na przykład dokumentacja, blog i baza wiedzy, to zaproszenie do budowania osobnych plików dla każdej sekcji zamiast jednego rozdętego indeksu, w którym agent i tak się gubi.
Co to znaczy dla SEO i AIO
Trzeba postawić sprawę uczciwie: llms.txt nie jest czynnikiem rankingowym i nikt tego nie obiecuje. Google od ponad roku powtarza, że wsparcie dla tego pliku nie jest na jego agendzie, a wyszukiwarka po prostu go ignoruje. W oficjalnych materiałach o optymalizacji pod funkcje AI Google stwierdza wprost, że obecność takiego pliku ani nie pomaga, ani nie szkodzi widoczności. Pisaliśmy o tym szerzej w tekście Google ignoruje llms.txt.
Ale wyszukiwarka Google to dziś tylko jeden z kilku kanałów, w których treść może zostać przeczytana. Rozgraniczenie jest kluczowe i sprowadza się do trzech scenariuszy:
- Crawler indeksujący, który buduje własny korpus treningowy lub indeks wyszukiwania. Tu llms.txt niczego nie zmienia, bo taki bot i tak przechodzi cały serwis.
- Agent czytający na żądanie, czyli asystent, który w trakcie rozmowy pobiera konkretny adres, żeby odpowiedzieć na pytanie użytkownika. Tu markdownowa wersja strony realnie zmniejsza szum i zwiększa szansę, że model wyciągnie właściwą liczbę zamiast fragmentu stopki.
- Agent kodujący i narzędzia deweloperskie, które pracują na dokumentacji. To środowisko, w którym llms.txt ma dziś największą realną adopcję.
W praktyce oznacza to, że korzyść z wersji 2.0 jest największa dla serwisów o charakterze dokumentacyjnym, produktowym i poradnikowym, gdzie treść ma jednoznaczną strukturę i jest cytowana w odpowiedziach asystentów. Dla sklepu z tysiącami kart produktowych wartość jest ograniczona, bo tam robotę odwala ustrukturyzowany feed i dane w HTML.
Warto też pamiętać o osobnym problemie, który llms.txt w żaden sposób nie rozwiązuje: kontroli dostępu. Plik llms.txt jest zaproszeniem, nie blokadą. Jeśli chcesz decydować, co bot w ogóle może pobrać, wracasz do robots.txt i reguł na poziomie serwera, a te, jak pokazały niedawne dane, bywają traktowane wybiórczo. Opisywaliśmy ten temat w materiale o tym, że robots.txt może nie dotyczyć bota ChatGPT.
Jak zmierzyć, czy to cokolwiek daje
Największym problemem llms.txt od początku jest brak pętli zwrotnej. Nie ma raportu w Search Console, nie ma powiadomienia, nie ma metryki, która powie, że asystent skorzystał właśnie z twojej markdownowej wersji strony. Zostają trzy źródła sygnału, wszystkie pośrednie.
Pierwsze to logi serwera. Filtrowanie żądań po ścieżkach kończących się na .md i po adresie /llms.txt pokazuje, czy ktokolwiek te pliki pobiera, z jakim user agentem i jak często. To jedyny twardy dowód, jakim dysponujesz. Drugie to testy promptowe, czyli regularne pytanie kilku asystentów o tematy, które opisujesz, i sprawdzanie, czy cytują twój serwis oraz czy przytaczane liczby zgadzają się z tym, co jest w treści. Trzecie to ruch z odesłań, bo część asystentów podaje link źródłowy, a taki ruch widać w analityce jako osobne źródło.
Reakcje branży
Odbiór wersji 2.0 jest podzielony dokładnie wzdłuż tej samej linii, co odbiór wersji pierwszej.
Zwolennicy zwracają uwagę, że standard przestał być propozycją jednego autora, a stał się czymś, co wdrażają największe laboratoria. Dokumentacje deweloperskie OpenAI, Anthropic i zespołu Gemini publikują własne pliki llms.txt. Platformy dokumentacyjne, z Mintlify na czele, generują je automatycznie, przez co tysiące serwisów ma taki plik, nawet o tym nie wiedząc. Do tego doszły audyty agentowe w Lighthouse w Chrome, które sprawdzają, czy plik da się pobrać. Audyt jest opcjonalny i przy braku pliku zwraca wynik nieokreślony, więc nie ma mowy o karze, ale sam fakt, że narzędzie Google go testuje, jest dla części branży sygnałem.
Sceptycy odpowiadają, że przez dwa lata nie pojawił się przekonujący dowód na to, żeby główne crawlery AI faktycznie czytały llms.txt i zmieniały na jego podstawie zachowanie. Argument jest twardy: skoro plik ma opisywać serwis modelom, a najwięksi operatorzy modeli mówią, że go nie używają w wyszukiwaniu, to wdrożenie jest optymalizacją pod hipotetyczny odbiornik. Druga linia krytyki jest jeszcze prostsza: jeśli twoje HTML-e są czyste, semantyczne i szybkie, model poradzi sobie bez dodatkowego pliku, a osobna wersja markdownowa to kolejny artefakt do utrzymania i kolejne źródło rozjazdu treści.
Wersja 2.0 częściowo odpowiada na pierwszy zarzut, bo mechanizm oparty na rel i nagłówku Link jest znacznie tańszy we wdrożeniu niż utrzymywanie ręcznie pisanego indeksu. Nie odpowiada na zarzut drugi, bo nikt nadal nie zadeklarował, że będzie te relacje respektował.
Na polskim rynku dochodzi jeszcze jeden argument, rzadko podnoszony w anglojęzycznej dyskusji. Treści w językach o mniejszym zasobie danych treningowych są w modelach reprezentowane słabiej, a jednocześnie polskie strony bywają wyjątkowo obciążone warstwą interfejsu: zgodami, banerami, widgetami i modułami rekomendacji. Różnica między surowym Markdownem a wyrenderowanym HTML-em jest w takich serwisach większa niż w minimalistycznej dokumentacji technicznej, więc potencjalny zysk z podania czystej wersji też jest większy. To argument hipotetyczny, ale spójny z tym, jak działa okno kontekstowe.
Co dalej
Jeśli traktujesz llms.txt jako niskokosztowy zakład o przyszłość, a nie jako dźwignię rankingową, wersja 2.0 jest dobrym momentem, żeby wrócić do tematu. Kolejność działań, która ma sens dla większości serwisów:
- Sprawdź, czy w ogóle masz plik. Jeśli korzystasz z platformy dokumentacyjnej, prawdopodobnie masz go automatycznie i nigdy do niego nie zajrzałeś. Otwórz
/llms.txti przeczytaj, co tam trafiło. - Zdecyduj, czy naprawdę potrzebujesz osobnych plików Markdown. To najdroższy element całości. Jeśli twój CMS potrafi wyrenderować surową treść wpisu, koszt jest niski. Jeśli wymagałoby to budowy osobnego pipeline’u, zacznij od samego llms.txt.
- Wybierz jeden wzorzec adresów i trzymaj się go. Mieszanie
strona.mdistrona.html.mdw jednym serwisie to proszenie się o niespójność i martwe adresy. - Dodaj relacje w nagłówku HTTP, jeśli masz CDN. To najszybsza droga do zgodności z 2.0 bez wdrożenia aplikacyjnego.
- Rozbij duży plik na hierarchię. Osobny llms.txt dla dokumentacji, osobny dla bloga, każdy z realnie wyselekcjonowaną listą stron, a nie zrzutem sitemapy.
- Monitoruj logi serwera. Jedyny wiarygodny dowód, że ktokolwiek czyta twój llms.txt i pliki .md, to wpisy w logach. Jeśli po miesiącu nie ma tam nic, masz odpowiedź na pytanie o sens dalszych inwestycji.
Największym pytaniem otwartym pozostaje adopcja po stronie odbiorców. Specyfikacja może być teraz dowolnie elegancka, ale dopóki operatorzy asystentów nie potwierdzą, że honorują rel="alternate" i rel="describedby", llms.txt 2.0 pozostaje dobrze zaprojektowaną ofertą, na którą druga strona jeszcze nie odpowiedziała. Historia standardów sieciowych pokazuje, że takie oferty czasem czekają latami, a czasem zostają przyjęte w kwartał, gdy komuś dużemu nagle się opłaci.
FAQ
Czy llms.txt wpływa na pozycje w Google?
Nie. Google wielokrotnie potwierdzało, że wyszukiwarka ignoruje ten plik i że jego obecność ani nie pomaga, ani nie szkodzi widoczności. To standard adresowany do agentów i asystentów AI, a nie do klasycznego indeksu wyszukiwarki.
Czy muszę przepisywać istniejący plik llms.txt do wersji 2.0?
Nie. Sam format pliku, czyli nagłówek H1, blockquote ze streszczeniem i sekcje H2 z listami odnośników, pozostaje bez zmian. Wersja 2.0 dokłada mechanizmy odkrywania wersji markdownowych stron, więc istniejący plik nadal jest poprawny.
Jaka jest różnica między llms.txt a llms-full.txt?
llms.txt to indeks, czyli krótki plik ze streszczeniem serwisu i listą odnośników do najważniejszych treści. llms-full.txt to pełny zrzut tych treści w jednym dokumencie, przeznaczony dla agentów, które wolą pobrać całość naraz zamiast odwiedzać kolejne adresy.
Czy llms.txt blokuje boty AI przed pobieraniem treści?
Nie, to nie jest mechanizm kontroli dostępu. llms.txt tylko wskazuje, co warto przeczytać i gdzie leży czysta wersja treści. Do ograniczania dostępu służą robots.txt, reguły na poziomie serwera i rozwiązania typu firewall aplikacyjny.
Który wzorzec adresu Markdown wybrać: strona.md czy strona.html.md?
Oba są zgodne ze specyfikacją 2.0, więc decyduje twój stack. Podmiana rozszerzenia jest wygodniejsza dla serwisów z adresami bez rozszerzeń i generatorów statycznych, a doklejenie .md łatwiej wdrożyć tam, gdzie adresy kończą się na .html. Ważne, żeby w obrębie jednego serwisu trzymać się jednego wzorca.