W 2024 roku Jeremy Howard z Answer.AI zaproponował format, który miał ułatwić życie modelom językowym odwiedzającym strony internetowe. Plik llms.txt — markdownowy spis zawartości strony, umieszczony w rootcie domeny — miał być dla agentów AI tym, czym jest sitemap dla Google’a. Krótkim, czytelnym przewodnikiem po tym, co na stronie jest, gdzie tego szukać i co warto zaindeksować w pierwszej kolejności.
Półtora roku później, w polskich publikacjach branżowych z 2026, llms.txt jest opisywany jako „obowiązkowy element SEO”, „nowy standard agentyczny”, „warstwa, bez której twoja strona zniknie z odpowiedzi AI”. Konsultanci sprzedają wdrożenia. Agencje wpisują do briefingów. Branżowe media wymieniają obok schema.org i Open Graph.
W tym czasie sam standard wciąż nie jest standardem — jest propozycją. Trzech głównych dostawców modeli AI deklaruje wobec niego trzy różne stanowiska. Twarde dowody na wpływ na widoczność w odpowiedziach AI są minimalne. A polski internet już zdążył przerobić to wszystko na produkt sprzedażowy.
Ten wpis jest drugim z pięciu w serii „Czego nie wdrożycie w 2026 — agentic web między hype a produkcją”. Zacząłem od pay-per-crawl. Dziś llms.txt — temat, w którym mam swoją pozycję. Sam wdrożyłem llms-full.txt na WebFluxie. Ale wdrażając, nie nazywałem tego rewolucją. I to jest dokładnie różnica, o której tu piszę.
Co reklamują
Najczęstsze zdanie, które słyszysz o llms.txt w polskich publikacjach 2025–2026, brzmi mniej więcej tak: „To nowy standard, który decyduje o tym, czy agent AI w ogóle zauważy twoją stronę”. Wokół tego zdania budują się trzy rodzaje narracji.
Pierwsza — narracja standardu. llms.txt jest opisywany analogicznie do robots.txt albo sitemap.xml. Plik w rootcie, jasna konwencja, powszechne wsparcie. Wystarczy go nie mieć, żeby wypaść z gry.
Druga — narracja widoczności. Brak llms.txt = brak obecności w odpowiedziach ChatGPT, Claude’a, Perplexity, Gemini. Strona staje się niewidoczna dla modeli językowych. Ruch agentowy omija cię i idzie do konkurencji.
Trzecia — narracja konkurencyjna. „Twoja konkurencja już to ma”. „Polskie firmy są w tyle”. „W 2026 to absolutne minimum”. Przekaz ma uruchomić poczucie pilności.
Wszystkie trzy narracje powtarzają się w prezentacjach handlowych agencji, w postach na LinkedInie polskich konsultantów AI, w artykułach na branżowych portalach przepisanych z anglojęzycznych źródeł. Często bez weryfikacji aktualnego stanu adopcji.
Co naprawdę jest
Trzy fakty, które tę narrację rozbijają.
Po pierwsze — llms.txt nie jest standardem. Jest propozycją. To nie jest detal terminologiczny — to jest kategoria techniczna. Standard ma definicję w organizacji typu IETF, W3C albo Ecma International, ma wersjonowanie, ma proces aktualizacji, ma listę implementacji, które go formalnie wspierają. Propozycja ma stronę internetową (llmstxt.org) i autora, który ją wymyślił. Różnica jest taka, że standard tworzy zobowiązanie po stronie operatorów oprogramowania. Propozycja tworzy zaproszenie.
llms.txt nie jest dziś nigdzie ratyfikowany. Może w przyszłości to się zmieni. W kwietniu 2026 — nie jest.
Po drugie — adopcja przez głównych dostawców jest nierówna i częściowo negatywna. Anthropic w dokumentacji Claude wspomina o llms.txt jako konwencji, którą respektuje. Google publicznie powiedziało (przez głos Johna Muellera, ale i w innych kontekstach), że nie wspiera llms.txt — argumentacja brzmiała mniej więcej tak, że to duplikuje funkcjonalność, którą już daje sitemap.xml plus dobre meta-opisy. OpenAI nie zajęło jednoznacznego stanowiska — GPTBot czasem pobiera plik, ale nikt z OpenAI nie potwierdził formalnie, że jest on używany w sposób systematyczny.
To nie jest sytuacja „standard, który dojrzewa”. To jest sytuacja „propozycja, której wsparcie jest podzielone”. Strona reklamująca llms.txt jako must-have musi pomijać Google — bo Google publicznie odmawia. Z perspektywy SEO klasycznego, w którym Google to wciąż 80% rynku wyszukiwania, to jest dziura, której nie da się zignorować.
Po trzecie — twardych dowodów skuteczności brakuje. SE Ranking opublikowało w 2025 badanie na próbie 300 tysięcy domen, które nie wykazało mierzalnego wpływu obecności llms.txt na częstość cytowania w odpowiedziach modeli AI. Pojedyncze case studies z anglojęzycznego internetu pokazują różne wyniki — niektóre pozytywne, niektóre neutralne, niektóre niejednoznaczne. Polski rynek nie ma jeszcze własnego badania na sensownej próbie.
Brak twardych dowodów nie oznacza, że plik nie ma wpływu. Oznacza, że dziś nie wiemy, jaki ma wpływ. To jest zupełnie inna pozycja niż „filar SEO 2026″.
Dlaczego to nie znaczy, że llms.txt nie ma sensu
Tu wchodzi część, która odróżnia tę serię od bezsensownego marudzenia. Krytyka narracji „llms.txt to must-have” nie oznacza, że pliku nie warto wdrażać. Oznacza tylko, że trzeba wiedzieć, co się wdraża i dlaczego.
Sam wdrożyłem llms-full.txt na WebFluxie — rozszerzoną wersję, która zawiera nie tylko mapę zawartości, ale i pełne treści wybranych wpisów. Decyzja była świadoma i oparta na trzech kalkulacjach.
Pierwsza — koszt wdrożenia jest minimalny. Plugin na WordPressie, kilkanaście minut konfiguracji, automatyczna aktualizacja przy nowych wpisach. To nie jest inwestycja, której trzeba bronić — to jest rozszerzenie, które albo zadziała, albo nie zadziała, ale nie kosztuje.
Druga — istnieją agenty, które już czytają takie pliki. Nie chodzi tylko o duże modele AI, których adopcja jest dyskusyjna. Chodzi o systemy RAG, asystenci kodowania, wyszukiwarki agentowe drugiego rzędu — te aktywnie indeksują ustrukturyzowane źródła. Dla nich llms-full.txt to gotowa baza, którą można zaindeksować bez crawlowania całej strony.
Trzecia — agent-readiness to przygotowanie na to, co dopiero się stanie. Jeśli za dwa lata któraś z propozycji w warstwie discovery dla agentów dojrzeje do standardu, strona, która już ma plik, ma przewagę nad stroną, która go nie ma. To nie jest gwarancja zwrotu z inwestycji — to jest opcja, której koszt zakupu jest niski.
Ale — i tu jest kluczowy moment — żadna z tych trzech kalkulacji nie uzasadnia narracji „llms.txt jako filar SEO 2026″. Wdrożenie pliku, którego adopcja jest niepewna, którego skuteczność nie jest udowodniona, i którego status nie jest standardem, nie jest fundamentem niczego. Jest dodatkową warstwą, opcjonalną, taniej w realizacji niż w sprzedaży.
Pisałem o tym konkretnie w haśle słownikowym o llms-full.txt — tam jest cała mechanika, kiedy ma sens, kiedy nie ma, jakie są realne pytania o skuteczność. Tu, w serii krytycznej, dokładam tylko jedną rzecz: rozdzielenie między „wdrażam, bo to tanie i może zadziałać” a „sprzedaję jako must-have, bo wszyscy o tym piszą”. To są dwie zupełnie różne pozycje wobec tego samego pliku.
Co zamiast tego zrobić w 2026
Trzy rzeczy, które są bardziej praktyczne niż traktowanie llms.txt jako filaru.
Po pierwsze — wdroż go, ale jako warstwę opcjonalną, nie kluczową. Jeśli używasz Yoast SEO albo Rank Math w nowszych wersjach, generowanie llms.txt jest często wbudowane jako jeden checkbox. Jeśli nie, plugin „Website LLMs.txt” generuje plik automatycznie. Jeśli wolisz pełną kontrolę, statyczny plik wrzucony przez FTP też zadziała. Wszystkie trzy ścieżki są godziną pracy. Nie inwestuj w to dnia. I nie sprzedawaj klientom jako produktu.
Po drugie — zrób porządek w warstwach, które mają udowodnioną skuteczność. Schema.org i JSON-LD dla typów Organization, Article, Product — to ma twarde dowody wpływu na widoczność w wynikach wyszukiwania i odpowiedziach modeli AI. Sitemap.xml z aktualnymi datami modyfikacji — klasyka, ale nadal działa. Robots.txt z świadomą polityką wobec botów AI — nie zwiększa widoczności, ale daje kontrolę nad ruchem agentowym, co jest własną wartością. O tym wszystkim pisałem w serii Agent-ready — tam są praktyczne wpisy dla każdej z tych warstw.
Po trzecie — obserwuj adopcję. Co kwartał sprawdzaj, czy stanowiska Google, OpenAI, Anthropica, Perplexity wobec llms.txt się zmieniły. Czy któryś z tych operatorów ogłosił systematyczne wsparcie. Czy pojawiło się większe badanie, które potwierdza albo zaprzecza skuteczności. Czy próba standaryzacji w IETF albo W3C ruszyła. Każda z tych zmian jest sygnałem, że status llms.txt może się zmieniać. Bez tych sygnałów — pozostaje przy tym, co dziś.
Czego nie warto robić w 2026: traktować llms.txt jako odpowiedzi na pytanie „jak być widocznym dla AI”. Inwestować w narzędzia analityczne, które obiecują pomiar skuteczności tego, co nie jest jeszcze mierzalne. Sprzedawać klientom jako pakiet. Każda z tych rzeczy stoi na fundamencie, którego nie ma.
Kiedy wrócić do tematu
Trzy sygnały, które będą znaczyć, że status llms.txt zaczyna się zmieniać.
Pierwszy — publiczne ogłoszenie systematycznego wsparcia przez Google albo OpenAI. Anthropic już to zrobił. Brakuje dwóch innych głównych graczy. Jeśli któryś z nich publicznie potwierdzi, że llms.txt jest częścią ich procesu indeksowania (a nie tylko ewentualnym sygnałem), to zmienia kategorię tego pliku z „propozycji” na „de facto standard”.
Drugi — proces standaryzacji w IETF, W3C albo WHATWG. Dziś llms.txt nie jest w żadnym z formalnych procesów. Jeśli któryś ruszy — to znaczy, że branża zdecydowała się na konsolidację wokół tej propozycji. Bez procesu pozostaje to, czym jest dziś: dobrym pomysłem bez formalnego zobowiązania.
Trzeci — badanie na większej próbie z wyraźnym efektem. SE Ranking pokazało brak efektu. Może następne badanie pokaże inaczej — z lepszą metodologią, na większej próbie, z dłuższym horyzontem czasowym. Kiedy taki dowód się pojawi, narracja branżowa znajdzie swoją podstawę. Do tego momentu pozostaje przekonaniem.
Do żadnego z tych trzech sygnałów dziś nie doszło. To znaczy, że llms.txt w 2026 jest czym? Plikiem, który możezadziałać. Niskim kosztem. Bez gwarancji. Wdrażaj, jeśli chcesz. Ale nie traktuj jako odpowiedzi na pytanie, którego jeszcze nikt jednoznacznie nie zadał.
