W 2024 roku Jeremy Howard z Answer.AI zaproponował prosty pomysł. Plik tekstowy w katalogu głównym strony — napisany w Markdown, czytelny dla modeli językowych — który mówi agentowi: tu jestem, to mam, tam szukaj. Analogia do robots.txt była oczywista i chwytliwa. robots.txt mówi botom czego nie robić. llms.txt miał mówić agentom co warto zrobić.
Pomysł był dobry. Problem zaczął się wtedy gdy branża postanowiła sprzedać go jako standard którego jeszcze nie ma.
Czym jest llms.txt
llms.txt to plik tekstowy umieszczany w katalogu głównym strony zawierający uproszczone informacje o witrynie przeznaczone dla modeli językowych — analogia robots.txt ale dla LLM.
Struktura jest prosta: krótki opis strony w Markdown, lista linków do najważniejszych zasobów z ich opisami. Nie wymaga specjalnej konfiguracji serwera. Nie wymaga bazy danych. Koszt wdrożenia to kilkanaście minut — plugin w WordPressie, statyczny plik przez FTP, albo automatyczna generacja przez Yoast SEO czy Rank Math w nowszych wersjach.
To jest ważna informacja: niski koszt wdrożenia. Ale niski koszt wdrożenia nie jest tym samym co wysoka gwarancja skuteczności.
Co llms.txt nie jest
W 2025 i 2026 roku polskie publikacje branżowe opisują llms.txt jako „obowiązkowy element SEO”, „nowy standard agentyczny”, „warstwę bez której twoja strona zniknie z odpowiedzi AI”. Każde z tych sformułowań mija się z aktualnym stanem rzeczy.
llms.txt nie jest standardem. Jest propozycją. Różnica nie jest terminologiczna — jest kategorialna. Standard ma definicję w organizacji typu IETF, W3C albo Ecma International, ma wersjonowanie, ma formalny proces aktualizacji, ma listę implementacji które go wspierają z mocy zobowiązania. Propozycja ma stronę internetową i autora który ją wymyślił. W kwietniu 2026 llms.txt nie jest nigdzie ratyfikowany.
Adopcja przez głównych dostawców jest nierówna. Anthropic w dokumentacji Claude wspomina o llms.txt jako konwencji którą respektuje. Google publicznie powiedziało przez głos Johna Muellera że go nie wspiera — argumentacja brzmiała że duplikuje funkcjonalność którą daje sitemap.xml plus dobre meta-opisy. OpenAI nie zajęło jednoznacznego stanowiska. GPTBot czasem pobiera plik, ale nikt z OpenAI nie potwierdził systematycznego wykorzystania.
To nie jest sytuacja „standard który dojrzewa”. To jest sytuacja „propozycja której wsparcie jest podzielone” — i gdzie jeden z trzech głównych graczy publicznie odmawia.
Mimo to — warto wdrożyć
Krytyka narracji „llms.txt jako must-have” nie jest argumentem za nierobieniem niczego. Jest argumentem za robieniem tego ze świadomością co się robi i dlaczego.
Trzy powody dla których wdrożenie ma sens mimo braku statusu standardu.
Koszt jest minimalny. Kilkanaście minut pracy to nie jest inwestycja której trzeba bronić ROI. To jest opcja kupiona za symboliczną cenę — albo zadziała, albo nie zadziała, ale nie boli.
Są systemy które już teraz aktywnie czytają takie pliki. Nie tylko duże modele AI których adopcja jest dyskusyjna — ale systemy RAG, asystenci kodowania, wyszukiwarki agentowe drugiego rzędu. Dla nich ustrukturyzowane źródło to gotowa baza do zaindeksowania bez crawlowania całej strony.
Agent-readiness to przygotowanie na to co dopiero nadchodzi. Jeśli llms.txt dojrzeje do statusu de facto standardu — strona która ma plik jest gotowa. Jeśli nie dojrzeje — straciła kwadrans.
Kiedy zmienić ocenę
Trzy sygnały które oznaczają że status llms.txt zaczyna się zmieniać: publiczne ogłoszenie systematycznego wsparcia przez Google albo OpenAI; uruchomienie procesu standaryzacji w IETF, W3C albo WHATWG; pojawienie się badania na dużej próbie które pokazuje mierzalny wpływ na widoczność w odpowiedziach AI.
Do żadnego z tych sygnałów w 2026 roku nie doszło.
llms.txt to plik który może zadziałać. Niskim kosztem. Bez gwarancji. Wdrażaj — ale nie traktuj jako odpowiedzi na pytanie którego nikt jeszcze jednoznacznie nie postawił.
Pełna analiza statusu llms.txt w kontekście polskiego rynku dostępna jest w artykule na Webflux.pl: llms.txt w 2026 — dlaczego standard, którego nie ma, jest reklamowany jako must-have