Specyfikacja llms.txt doczekała się wersji 2.0. Jeremy Howard, współzałożyciel Answer.AI i autor pierwotnej propozycji, opublikował 10 sierpnia aktualizację, która po raz pierwszy formalnie opisuje, w jaki sposób agent AI ma znaleźć markdownową wersję strony. Zmiana wygląda na drobiazg techniczny, ale dotyka najsłabszego punktu całego pomysłu: plik llms.txt wskazywał dotąd adresy stron, nie mówiąc ani słowem, gdzie leżą ich czyste odpowiedniki w markdown.
Aktualizacja jest o tyle istotna, że nie powstała przy biurku. Howard opisuje ją jako wynik dwóch lat obserwacji tego, co realnie dzieje się z plikiem w produkcji: tysięcy wdrożeń, automatycznej generacji przez platformy dokumentacyjne i pierwszych audytów w narzędziach przeglądarkowych. Wersja 2.0 wycina to, czego nikt nie używał, i domyka to, co okazało się potrzebne.
Kontekst: dwa lata pliku, którego Google nie czyta
llms.txt pojawił się jako propozycja prostego pliku tekstowego w katalogu głównym domeny, który podaje modelowi językowemu skróconą mapę witryny. Zamiast kazać agentowi przekopywać się przez HTML naszpikowany nawigacją, banerami cookie i skryptami, właściciel serwisu wystawia listę najważniejszych zasobów w markdown, z krótkimi opisami. Analogia do robots.txt jest kusząca, ale myląca: robots.txt mówi botom, czego nie wolno, llms.txt mówi, co warto przeczytać najpierw.
Przez dwa lata plik zyskał zaskakująco szeroką bazę. Według danych przytaczanych przez serwis Search Engine Journal publikują go dziś tysiące witryn, platforma Mintlify generuje go automatycznie dla każdej hostowanej dokumentacji, a własne pliki llms.txt dla swoich dokumentacji deweloperskich utrzymują OpenAI, Anthropic oraz zespół Gemini w Google. Lighthouse w Chrome sprawdza obecność pliku w ramach kontroli agentic browsing, choć traktuje jego brak jako informację, nie jako błąd.
Równocześnie propozycja ma solidny problem z wiarygodnością. Zespół wyszukiwarki Google wielokrotnie powtarzał, że wsparcie dla llms.txt nie jest w jego planach, a utrzymywanie takiego pliku ani nie zaszkodzi, ani nie pomoże widoczności witryny, ponieważ Google Search go po prostu ignoruje. Pisaliśmy o tym szerzej przy okazji komentarzy Johna Muellera na temat osobnych kopii treści w markdown dla modeli AI. Sedno sporu: czy warto utrzymywać równoległy obieg treści, skoro największy gracz deklaruje, że go nie czyta.
Kluczowe fakty: co dokładnie zmienia wersja 2.0
Aktualizacja wprowadza sześć konkretnych zmian. Trzy z nich rozszerzają specyfikację, trzy ją upraszczają.
| Obszar | Wersja 1 | Wersja 2 |
|---|---|---|
| Wykrywanie markdown | Brak mechanizmu, agent musiał zgadywać | Formalne relacje linków oraz nagłówek HTTP |
| Wzorzec adresu | Tylko doklejenie .md do pełnego adresu (page.html.md) | Dopuszczalne również podmienienie rozszerzenia (page.md) |
| Pliki w podkatalogach | Dozwolone, bez definicji zasięgu | Plik obejmuje strony poniżej swojej ścieżki, wygrywa najbardziej szczegółowy |
| Narzędzie llms_txt2ctx | Część propozycji | Usunięte ze specyfikacji |
| Sekcja Optional | Znaczenie programistyczne | Wyłącznie konwencja dla linków drugorzędnych |
| Opis zastosowań | Scenariusze przyszłego wykorzystania | Opis tego, jak agenty realnie korzystają z witryn |
Dwie relacje linków zamiast zgadywania
Najważniejszy element aktualizacji to para standardowych relacji. Pierwsza, rel="alternate" z atrybutem type="text/markdown", wskazuje markdownową wersję bieżącej strony. Druga, rel="describedby", prowadzi do pliku llms.txt, który tę stronę opisuje. Obie można podać w elemencie <link> w sekcji head albo, co często wygodniejsze, w nagłówku odpowiedzi HTTP.
Wariant nagłówkowy wygląda tak, jak w przykładzie z oficjalnej specyfikacji:
Link: </docs/page.html.md>; rel="alternate"; type="text/markdown", </docs/llms.txt>; rel="describedby"
Ten wariant ma dwie zalety praktyczne. Po pierwsze działa dla zasobów, które nie są HTML, więc obejmie także pliki PDF czy odpowiedzi API. Po drugie da się go wdrożyć na poziomie serwera lub CDN, bez dotykania szablonów i bez wdrażania zmian w CMS. Dla dużych serwisów to różnica między jednodniowym ticketem u devopsu a kwartalnym projektem frontendowym.
Warto zauważyć, że obie relacje są elementami standardowego słownika linków, a nie wynalazkiem autora specyfikacji. alternate od lat obsługuje wersje językowe, kanały RSS i warianty mobilne, describedby wywodzi się ze świata danych strukturalnych. Howard nie tworzy nowego mechanizmu, tylko sięga po istniejący i nadaje mu konkretne zastosowanie. To znacząco obniża próg adopcji: parsery, biblioteki i serwery już te relacje rozumieją.
Elastyczniejsze adresy i jasny zasięg
Wersja 1 wymagała, żeby markdownowa kopia żyła pod adresem powstałym przez doklejenie .md do pełnego adresu strony, czyli page.html.md. W praktyce większość generatorów stron statycznych i platform dokumentacyjnych produkuje pliki w postaci page.md. Wersja 2 dopuszcza oba warianty. Dla ścieżek bez nazwy pliku specyfikacja przewiduje index.html.md lub index.md.
Doprecyzowany został także zasięg plików umieszczonych w podkatalogach. Wcześniej specyfikacja pozwalała na plik llms.txt w dowolnym miejscu drzewa, nie mówiąc, czego on właściwie dotyczy. Teraz obowiązuje reguła znana z innych standardów webowych: plik obejmuje strony leżące poniżej jego ścieżki, a gdy pasuje więcej niż jeden, stosuje się najbardziej szczegółowy. Dla serwisów z osobną dokumentacją produktową, blogiem i bazą wiedzy to znaczy, że każda sekcja może mieć własny plik, bez konfliktu z tym w katalogu głównym.
Co wyleciało ze specyfikacji
Wersja 2 usuwa opis narzędzia llms_txt2ctx, które miało rozwijać plik llms.txt do pełnego kontekstu podawanego modelowi. Autor uznał, że warstwa narzędziowa nie należy do propozycji standardu. Podobnie potraktowana została sekcja Optional: wcześniej miała znaczenie mechaniczne, sugerujące narzędziom, że te linki można pominąć przy ograniczonym oknie kontekstu. Teraz jest wyłącznie konwencją redakcyjną dla materiałów drugorzędnych.
Zmienił się też ton samego dokumentu. Wersja 1 opisywała scenariusze przyszłego wykorzystania pliku, wersja 2 opisuje to, jak agenty faktycznie korzystają z witryn. Ta korekta jest ważniejsza, niż wygląda: propozycja przestaje obiecywać, a zaczyna dokumentować zaobserwowaną praktykę, co zdejmuje z niej część zarzutów o spekulatywność.
Sam format pliku pozostaje bez zmian i jest zaskakująco lekki. Wymagany jest wyłącznie nagłówek H1 z nazwą projektu. Opcjonalnie dochodzi blockquote z krótkim podsumowaniem, dowolna liczba sekcji opisowych oraz listy plików rozdzielone nagłówkami H2, w których każda pozycja to link markdown z opcjonalną notatką.
Co to znaczy dla SEO i AIO
Pierwszy wniosek jest niewygodny: to nadal nie jest sygnał rankingowy. Google nie czyta llms.txt i nie zapowiada zmiany stanowiska. Każdy, kto sprzedaje wdrożenie tego pliku jako sposób na wyższe pozycje w wyszukiwarce, mija się z faktami. Warto to powiedzieć wprost, zanim rynek zrobi z wersji 2 kolejny obowiązkowy punkt audytu.
Drugi wniosek jest ciekawszy. Zmiana w wersji 2 nie celuje w wyszukiwarki, tylko w agenty: asystentów kodowania, narzędzia typu deep research i przeglądarki agentowe. To inna klasa odbiorcy niż crawler indeksujący. Agent kodowania nie buduje indeksu całego internetu, tylko potrzebuje w danej chwili poprawnej dokumentacji jednej biblioteki i chce ją dostać w formie, która nie zjada połowy okna kontekstu na nawigację i stopkę. Relacja rel="alternate" załatwia mu to jednym zapytaniem.
Dla zespołów pracujących nad widocznością w modelach oznacza to rozdzielenie dwóch celów, które często są mylone. Cytowalność w odpowiedziach ChatGPT czy Perplexity zależy przede wszystkim od tego, czy treść jest w indeksie i cache danego dostawcy oraz czy jest wystarczająco jednoznaczna, żeby model chciał się na nią powołać. Opisywaliśmy ten mechanizm w analizie kanałów, z których ChatGPT pobiera źródła. llms.txt nie wpływa na ten obieg. Wpływa na obieg drugi: świadome pobranie konkretnej strony przez agenta, który już wie, dokąd idzie.
Praktyczna konsekwencja jest taka, że zwrot z wdrożenia zależy od typu serwisu. Dokumentacja techniczna, baza wiedzy SaaS, referencja API oraz obszerne poradniki produktowe zyskują realnie, bo ich odbiorca często siedzi w asystencie kodowania. Blog lifestylowy, serwis lokalny czy sklep z krótkimi opisami kategorii nie zyskają praktycznie nic, a dołożą sobie drugi obieg treści do utrzymania.
Kolejność wdrożenia też ma znaczenie. Zacznij od wystawienia poprawnych wersji markdown i sprawdzenia, czy zwracają typ MIME text/markdown, dopiero potem dodaj relacje i nagłówki. Odwrotna kolejność oznacza, że przez jakiś czas kierujesz agenty pod adresy zwracające 404, a to najgorszy możliwy pierwszy kontakt z twoją dokumentacją.
Ryzyko, o którym warto pamiętać
Równoległa wersja markdown to duplikat. Jeśli wystawisz ją pod adresem indeksowalnym, bez atrybutu canonical wskazującego wersję HTML i bez kontroli nad tym, co robią z nią crawlery, w najlepszym razie zmarnujesz budżet crawlowania, w najgorszym wprowadzisz zamęt w indeksie. Praktyczne minimum to canonical na wersji HTML, konsekwentne trzymanie obu wersji w synchronizacji oraz świadoma decyzja, czy pliki markdown mają być dostępne dla botów wyszukiwarek, czy tylko dla agentów. Kwestia dostępu dla poszczególnych botów jest zresztą osobnym polem minowym, co pokazała sprawa interpretacji robots.txt przez ChatGPT-User.
Drugie ryzyko to koszt utrzymania. Plik llms.txt generowany ręcznie starzeje się w tempie, w jakim zmienia się serwis. Jeśli nie da się go budować automatycznie z tego samego źródła co nawigacja, po pół roku będzie zbiorem martwych linków, który zaszkodzi bardziej niż jego brak. Ta sama zasada dotyczy kopii markdown: rozjazd treści między wersją HTML a markdownową jest gorszy od braku tej drugiej, bo agent zacytuje nieaktualną wersję, a użytkownik trafi na inną.
Reakcje branży
Podział opinii utrzymuje się od premiery pierwszej wersji i aktualizacja go nie zlikwidowała. Obóz sceptyczny powtarza argument, który trudno obalić: przez dwa lata nie pojawił się publiczny dowód, że którykolwiek duży crawler AI faktycznie pobiera llms.txt przed pobraniem strony. Dostawcy modeli publikują własne pliki dla swoich dokumentacji, co jest wygodnym argumentem marketingowym, ale nie jest tym samym co deklaracja, że ich boty te pliki czytają u innych.
Obóz przychylny odpowiada, że punkt ciężkości przesunął się z crawlerów na agenty działające w czasie rzeczywistym, a tam adopcja jest widoczna gołym okiem w narzędziach deweloperskich i platformach dokumentacyjnych. Z tej perspektywy wersja 2 jest dokładnie tym, czego brakowało: standard przestaje udawać konkurencję dla mapy witryny, a zaczyna być protokołem negocjacji formatu treści, bliższym w duchu nagłówkowi Accept niż plikowi robots.txt.
Wymowna jest też postawa Chrome. Lighthouse sprawdza obecność pliku w kontroli agentic browsing, ale jego brak raportuje jako nieistotny, a nie jako błąd. To sygnał ostrożny: przeglądarka uznaje temat za na tyle realny, żeby go mierzyć, i na tyle niepewny, żeby nikogo za niego nie karać.
W polskiej branży dominuje postawa wyczekująca. Agencje, które wdrożyły llms.txt u klientów, zwykle robiły to jako element pakietu AIO, bez twardych metryk potwierdzających efekt. Problem z pomiarem jest fundamentalny: pobrania pliku widać w logach serwera, ale powiązanie ich z późniejszym cytowaniem w odpowiedzi modelu wymaga danych, których żaden dostawca nie udostępnia. Dopóki to się nie zmieni, dyskusja pozostanie sporem o przewidywania, nie o wyniki.
Co dalej
Następne miesiące rozstrzygną, czy llms.txt zostanie w niszy dokumentacji technicznej, czy przebije się szerzej. Są trzy sygnały warte obserwacji.
- Deklaracje dostawców modeli. Publiczne potwierdzenie ze strony OpenAI, Anthropic lub Google, że konkretny bot honoruje relacje z wersji 2, zmieni kalkulację z dnia na dzień.
- Wsparcie w CMS. Jeśli generowanie markdownowych odpowiedników i nagłówków Link trafi do popularnych wtyczek dla WordPressa oraz frameworków, koszt wdrożenia spadnie do zera i adopcja przestanie być decyzją strategiczną.
- Zachowanie Lighthouse. Zmiana statusu z informacyjnego na ostrzeżenie byłaby najmocniejszym dotąd sygnałem, że Chrome traktuje plik jako element higieny technicznej.
Rekomendacja na dziś jest prozaiczna. Jeśli prowadzisz dokumentację techniczną albo rozbudowaną bazę wiedzy i masz już markdown w repozytorium, dodanie nagłówka Link na poziomie CDN to praca na godziny, a nie na tygodnie, i warto ją wykonać. Jeśli musiałbyś budować cały równoległy obieg treści od zera dla serwisu, którego czytelnikiem nie jest agent kodowania, poczekaj na deklaracje dostawców. Terminologię, która się tu przewija, od groundingu po cytowalność, zebraliśmy w słowniku AIO.
Wersja 2 nie rozstrzyga sporu o sens llms.txt. Robi coś skromniejszego i uczciwszego: zamyka techniczną lukę, która przez dwa lata pozwalała odrzucać propozycję jako niedokończoną. Ciężar dowodu przeszedł teraz na dostawców modeli.
FAQ
Czy llms.txt wpływa na pozycje w Google?
Nie. Zespół wyszukiwarki Google konsekwentnie deklaruje, że wsparcie dla llms.txt nie znajduje się w jego planach, a obecność pliku ani nie pomaga, ani nie szkodzi widoczności witryny w wynikach. Traktuj go jako element optymalizacji pod agenty AI, nie pod ranking organiczny.
Czym różni się llms.txt od robots.txt i mapy witryny?
robots.txt określa, czego botom nie wolno pobierać, mapa witryny wylicza adresy do zaindeksowania, a llms.txt wskazuje modelowi językowemu, które zasoby przeczytać w pierwszej kolejności i gdzie znaleźć ich czystą wersję markdown. Trzy różne cele, trzy różne pliki, które się nie zastępują.
Którą wersję adresu markdown wybrać po aktualizacji?
Specyfikacja w wersji 2 dopuszcza oba warianty: doklejenie rozszerzenia do pełnego adresu (page.html.md) oraz jego podmianę (page.md). Wybierz ten, który naturalnie generuje twoja platforma, i trzymaj się go konsekwentnie w całym serwisie.
Czy trzeba modyfikować szablony stron, żeby wdrożyć relacje z wersji 2?
Nie musisz. Relacje można podać w elemencie link w sekcji head albo w nagłówku odpowiedzi HTTP. Wariant nagłówkowy konfiguruje się na poziomie serwera lub CDN, działa także dla zasobów innych niż HTML i nie wymaga zmian w CMS.
Dla jakich serwisów wdrożenie ma sens ekonomiczny?
Największy zwrot notują dokumentacje techniczne, referencje API, bazy wiedzy SaaS i obszerne poradniki produktowe, bo ich odbiorca często pracuje w asystencie kodowania. Małe serwisy lokalne, blogi lifestylowe i sklepy z krótkimi opisami kategorii dołożyłyby sobie drugi obieg treści bez wymiernej korzyści.