Czy llms.txt działa? Co mówią dane

Czym miał być llms.txt

Pomysł jest prosty i sensowny: skoro roboty wyszukiwarek mają robots.txt, to modele językowe powinny mieć własny plik. Mapę treści serwisu napisaną tak, żeby model od razu wiedział, czym ta strona jest, kto za nią stoi i które podstrony są najważniejsze. Stąd llms.txt: plik tekstowy w katalogu głównym, zwykle w markdownie, z krótkim opisem encji i listą najważniejszych adresów.

Propozycja standardu pojawiła się w 2024 roku i szybko została podchwycona przez branżę SEO jako element „optymalizacji pod AI”. Adopcja rośnie. W skali roku liczba serwisów publikujących ten plik wzrosła kilkukrotnie.

Pytanie brzmi, czy cokolwiek z tego wynika.

Co pokazują dane

Co mówi sam Google. Strona „AI features and your website” w Search Central odnosi się do plików maszynowych wprost, choć nie w kategoriach czytania czy nieczytania, tylko potrzeby:

„You don’t need to create new machine readable files, AI text files, or markup to appear in these features. There’s also no special schema.org structured data that you need to add.”

— Google Search Central, AI features and your website

W tym samym dokumencie Google stwierdza również: „There are no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary”. To deklaracja braku konieczności, a nie oświadczenie, że plik nie jest pobierany — z „nie musisz tego tworzyć” nie wynikało „nie czytamy tego”. Mocniejsze stanowisko Google zajął dopiero w nocie z 15 czerwca 2026, do której wracam w sekcji o zmianach z tego roku. Żaden inny duży dostawca nie zadeklarował obsługi pliku w systemach produkcyjnych.

Wcześniej, w kwietniu 2025 roku, John Mueller z Google porównał llms.txt do wygasłego znacznika keywords i stwierdził, że żadna z usług AI nie zadeklarowała korzystania z tego pliku. Relację z tej wypowiedzi opublikował Search Engine Journal 17 kwietnia 2025 roku.

Pozostali dostawcy. Na sierpień 2026 żadna z dużych firm (OpenAI, Google, Anthropic, Meta, Mistral) nie zadeklarowała publicznie, że czyta i wykorzystuje llms.txt w systemach produkcyjnych. Dokumentacja crawlerów OpenAI i wytyczne Anthropic odsyłają w sprawach dostępu do treści do robots.txt.

Dane o pobraniach. Badanie Ahrefs na logach serwerowych 137 210 domen wykazało, że w maju 2026 roku 97% opublikowanych plików llms.txt nie zostało pobranych ani razu. Wśród tych 3%, które ktokolwiek pobrał, boty AI odpowiadały tylko za 19,5% żądań. Największą pojedynczą kategorią były narzędzia audytowe SEO (21,7%, w tym własne crawlery Ahrefs; same narzędzia zewnętrzne to 11,1%), a resztę stanowiły anonimowe scrapery, ogólne crawlery i narzędzia profilujące technologie; 4% żądań pochodziło od ludzi.

Dane o cytowaniach. Osobna analiza SE Ranking z listopada 2025 objęła około 300 tys. domen i sprawdziła, czy obecność pliku wiąże się z częstością cytowań w silnikach AI. Nie znaleziono istotnego statystycznie związku, a po usunięciu tej zmiennej model predykcyjny działał wręcz lepiej. To, co naprawdę decyduje o zacytowaniu strony przez model, opisałem osobno w tekście jak modele AI wybierają źródła.

To rzadka sytuacja w tej branży: dane są twarde i zgodne. Pliku prawie nikt nie pobiera.

Kto naprawdę czyta ten plik

Odbiorca, jeśli istnieje, jest inny niż zakładano. Najbardziej prawdopodobni czytelnicy llms.txt to agenci programistyczni i przeglądarki agentowe: narzędzia, które wchodzą na stronę z konkretnym zadaniem i szukają skrótu do struktury serwisu. Pomiar Ahrefs tego jednak nie potwierdza, bo wśród nielicznych pobrań największą kategorią są narzędzia audytowe SEO. Dlatego plik publikują firmy, których dokumentacja jest czytana przez takie narzędzia: Stripe, Vercel, Cloudflare, Anthropic, Mastercard.

To użyteczny przypadek, ale zupełnie inny niż „lepsza widoczność w ChatGPT”.

Aktualizacja: co zmieniło obraz w 2026 roku

Cztery rzeczy z pierwszej połowy i z lata 2026 — żadna na korzyść pliku. Ostatnia zaczęła się w lutym, ale domknął ją wpis z 6 sierpnia 2026, już po publikacji.

Google przestał mówić nie wprost. 15 czerwca 2026 w changelogu dokumentacji Search Central pojawiła się nota „Clarifying guidance on llms.txt files”: plik nie jest potrzebny dla Google Search i nie wpływa na widoczność ani pozytywnie, ani negatywnie — także w funkcjach AI. Wcześniejsze deklaracje wymagały interpretacji; ta już nie.

Specyfikacja doczekała się drugiej wersji. 10 sierpnia 2026, po niespełna dwóch latach od premiery, autor specyfikacji opublikował rewizję. Zmiany dotyczą tego, jak agent trafia do pliku i co z nim robi. Zmieniło się odkrywanie: strona wskazuje plik znacznikiem link rel="describedby", a wersję markdown danej strony znacznikiem link rel="alternate" type="text/markdown", więc agent nie musi zgadywać adresu. Zmieniło się adresowanie: obok formy z dopisanym .md dopuszczono podmianę rozszerzenia. Doszła hierarchia: plik obejmuje strony leżące pod jego ścieżką, a przy kilku plikach obowiązuje najbardziej szczegółowy.

Inne jest też założenie o odbiorcy. Zamiast narzędzia sklejającego plik w jeden kontekst, specyfikacja mówi wprost, że agent przegląda plik i wchodzi w te odnośniki, które uzna za potrzebne. Sekcja „Optional” pozostaje konwencją, ale przestaje mieć osobne znaczenie techniczne.

Adopcja rośnie, konsumpcja nie. Według analizy na publicznych danych HTTP Archive (czerwiec 2026) poprawny llms.txt ma 5,61% z 10 tys. największych domen — wobec 1,04% rok wcześniej, przy czym maj i czerwiec 2026 to pierwszy płaski odczyt serii.

W Polsce adopcja u największych jest wyraźnie wyższa: w moim pomiarze spółek WIG20 i mWIG40 z sierpnia 2026 plik miało 12 z 58 zmierzonych, tyle że część z nich to zrzuty: 927 kB z wtyczki SEO u LPP, a u BNP Paribas 2 MB w formacie własnym. Rozmiary niemające ze specyfikacją nic wspólnego. Coraz więcej stron publikuje plik, którego wciąż prawie nikt nie pobiera.

Konwencja przesuwa się gdzie indziej. W lutym 2026 Cloudflare ogłosił „Markdown for Agents”, a 6 sierpnia 2026 wpisał ten mechanizm w szerszą wizję agentowego internetu: zamiast osobnej mapy dla modeli — ta sama treść strony w markdownie, tańsza w konsumpcji niż HTML. U Cloudflare dzieje się to przez negocjację nagłówkiem na tym samym adresie; prostszy wariant to bliźniak pod adresem z końcówką .md i ten serwis realizuje właśnie ten wariant. Niezależnie od drogi różnica wobec llms.txt jest jedna: llms.txt opisuje serwis, markdownowy bliźniak jest treścią.

Praktyczny wniosek

Rozdzielmy dwie rzeczy: koszt wdrożenia i oczekiwany zwrot.

Czy wdrażać? Tak, jeśli plik generuje się automatycznie z treści serwisu i kosztuje kilkanaście minut pracy — pod jednym warunkiem: ma pozostać na tyle mały, żeby zmieścił się w kontekście modelu, bo zrzut całej treści pod tą nazwą warunku specyfikacji nie spełnia. Nie szkodzi, jest tani w utrzymaniu, a odbiorca agentowy realnie istnieje i będzie prawdopodobnie rósł.

Czy traktować jako strategię widoczności? Nie. Nie ma dowodów na efekt, są dowody na jego brak. Płacenie za llms.txt jako osobną usługę optymalizacyjną albo budowanie wokół niego oferty to sprzedawanie nadziei.

Co faktycznie wpływa na to, czy model zacytuje twoją stronę: czy strona jest bezpośrednią odpowiedzią na konkretne, wąskie pytanie; czy odpowiedź pada w pierwszych zdaniach; czy treść jest dostępna bezpośrednio w HTML, bez składania w JavaScripcie; czy twierdzenia da się zweryfikować. To nudniejsze niż nowy plik konfiguracyjny i działa.

Zastrzeżenie

Ten wniosek dotyczy stanu na sierpień 2026 roku i może się zdezaktualizować w każdej chwili. Wystarczy, że jeden duży dostawca ogłosi obsługę. Dlatego na tej stronie llms.txt jest wdrożony: koszt jest bliski zeru, a gdyby sytuacja się zmieniła, plik już będzie na miejscu. Taka kalkulacja to dziś jedyna sensowna podstawa decyzji o wdrożeniu tego pliku.