english
español
Magdalena Szypulska
Idea wydaje się prosta – zamiast liczyć, że model językowy sam odnajdzie najważniejsze treści, właściciel strony może przygotować dla niego przewodnik po swoim serwisie.
Wraz z rosnącą popularnością standardu zaczęły jednak pojawiać się coraz śmielsze tezy. Jedni określają llms.txt mianem „robots.txt dla AI”, inni sugerują, że zwiększa szanse na cytowanie przez ChatGPT czy Perplexity.
Problem w tym, że liczba opinii rośnie szybciej niż liczba dowodów.
Analizy logów wskazują, że większość opublikowanych plików praktycznie nie jest odczytywana, a Google nie potwierdza, by llms.txt odgrywał obecnie istotną rolę w jego systemach.
To właśnie ta rozbieżność sprawia, że llms.txt jest dziś jednym z najciekawszych tematów na styku SEO i AI.
Dlatego zamiast odpowiadać na pytanie, czy llms.txt „działa", warto najpierw przyjrzeć się faktom. Skąd wziął się ten standard? Co dokładnie proponuje jego autor? Jak podchodzą do niego dostawcy modeli językowych? I czy dostępne dane rzeczywiście potwierdzają narrację, która narosła wokół niego w ostatnich miesiącach?
Skąd wziął się pomysł na llms.txt?
Autorem standardu nie jest Google ani OpenAI. Geneza llms.txt nie ma nic wspólnego z wyszukiwarkami internetowymi.
Autorem specyfikacji jest Jeremy Howard, współzałożyciel Answer.AI oraz twórca fast.ai, który opublikował pierwszą wersję projektu we wrześniu 2024 roku.
Howard nie próbował stworzyć nowego sygnału rankingowego ani alternatywy dla robots.txt. Punktem wyjścia był znacznie bardziej praktyczny problem. W jego ocenie współczesne strony internetowe są projektowane przede wszystkim z myślą o ludziach i przeglądarkach, podczas gdy modele językowe potrzebują możliwie prostego dostępu do właściwej treści.
W opisie specyfikacji Howard zwraca uwagę, że pojedyncza podstrona bardzo często zawiera ogromną liczbę elementów, które z punktu widzenia modelu nie wnoszą żadnej wartości.
Menu, stopki, reklamy, skrypty JavaScript, banery czy rozbudowana nawigacja zwiększają liczbę tokenów potrzebnych do przetworzenia dokumentu, utrudniając dotarcie do właściwej wiedzy.
To właśnie z tej obserwacji narodził się pomysł llms.txt.
Pierwotnym celem standardu nie była optymalizacja SEO, ale ułatwienie modelom językowym odnalezienia najważniejszych treści w obrębie serwisu.
Problem, który próbował rozwiązać Jeremy Howard
Założenie projektu można streścić w jednym zdaniu: skoro modele językowe czytają internet inaczej niż ludzie, być może potrzebują również innego sposobu nawigacji.
Howard zaproponował więc, aby właściciel strony mógł przygotować prosty dokument tekstowy zawierający najważniejsze zasoby witryny wraz z krótkim opisem każdego z nich. Zamiast analizować całą architekturę serwisu, agent AI otrzymywałby gotową listę materiałów, od których warto zacząć.
To ważne rozróżnienie. Specyfikacja nie zakłada zastąpienia istniejącej struktury strony ani stworzenia nowego mechanizmu indeksowania. Plik ma jedynie wskazywać, które dokumenty autor uważa za najbardziej wartościowe.
Można więc powiedzieć, że llms.txt jest propozycją dodatkowej warstwy komunikacji pomiędzy właścicielem witryny a systemami AI.
Autor specyfikacji opisuje llms.txt jako przewodnik po serwisie, a nie nową metodę publikowania treści.
Czy llms.txt jest oficjalnym standardem internetu?
Na razie nie.
To jedno z najczęściej pomijanych rozróżnień w dyskusjach o llms.txt.
Mimo rosnącej popularności projekt nie został przyjęty przez organizacje odpowiedzialne za rozwój standardów internetowych, takie jak W3C czy IETF. Oznacza to, że nie ma statusu oficjalnej specyfikacji sieciowej, a jego implementacja pozostaje całkowicie dobrowolna.
Ma to bardzo konkretne konsekwencje.
Żaden dostawca modeli językowych nie jest zobowiązany do odczytywania tego pliku. Również właściciele stron internetowych nie mają obowiązku jego publikowania. Sukces całego projektu zależy więc wyłącznie od tego, czy obie strony uznają go za użyteczny.
To odróżnia llms.txt od wielu standardów, które z czasem stały się powszechnym elementem infrastruktury internetu.
Na obecnym etapie llms.txt należy traktować jako otwartą propozycję społeczności AI, a nie obowiązujący standard sieci.
Jak wygląda specyfikacja llms.txt?
Jednym z założeń projektu była maksymalna prostota.
Zgodnie ze specyfikacją plik powinien znajdować się pod adresem /llms.txt w katalogu głównym domeny.
Jego zawartość zapisuje się nie w XML ani JSON, lecz w formacie Markdown. To świadoma decyzja autora projektu.
Jeremy Howard argumentuje, że Markdown jest jednym z najlepiej rozpoznawanych przez modele językowe formatów tekstowych. Wynika to z faktu, że ogromna część dokumentacji technicznej właśnie z niego korzysta.
Minimalna struktura dokumentu obejmuje nazwę projektu, krótki opis serwisu oraz sekcje grupujące najważniejsze zasoby wraz z krótkimi opisami i linkami zapisanymi w składni Markdown.
Równie istotne jest to, czego specyfikacja nie zaleca.
Autor projektu nie proponuje kopiowania całej mapy witryny ani publikowania setek adresów URL. Wręcz przeciwnie – ideą jest przygotowanie krótkiego, ręcznie wybranego zestawu najważniejszych materiałów.
llms.txt ma przypominać starannie przygotowany spis treści, a nie automatycznie wygenerowaną listę wszystkich podstron.
Dlaczego nie jest to kolejna sitemap.xml?
Na pierwszy rzut oka oba rozwiązania wydają się podobne. Zarówno sitemap.xml, jak i llms.txt zawierają przecież odnośniki do stron.
Na tym podobieństwa praktycznie się kończą.
Sitemap.xml służy wyszukiwarkom do odkrywania adresów URL przeznaczonych do indeksowania. W praktyce często zawiera tysiące podstron i jest generowana automatycznie przez CMS lub narzędzia SEO.
llms.txt pełni zupełnie inną funkcję. Nie próbuje opisać całej witryny. Ma wskazać niewielką liczbę materiałów, które – zdaniem autora – najlepiej reprezentują wiedzę zawartą w serwisie.
To różnica nie tylko techniczna, ale również filozoficzna.
Sitemap odpowiada na pytanie „co znajduje się w serwisie”, natomiast llms.txt próbuje odpowiedzieć na pytanie „od czego warto zacząć”.
Rzeczywista adopcja llms.txt. Entuzjazm branży to jedno, wykorzystanie przez AI – drugie
Liczba wdrożeń nie oznacza jeszcze wykorzystania
Liczba domen publikujących llms.txt szybko rośnie. W ciągu kilkunastu miesięcy od opublikowania specyfikacji plik pojawił się w setkach tysięcy serwisów, a jego generowanie zaczęły oferować popularne narzędzia SEO i platformy dokumentacyjne.
Nie oznacza to jednak, że modele językowe rzeczywiście z niego korzystają. Wdrożenie przez właścicieli stron i wykorzystanie przez systemy AI to dwie różne kwestie – i właśnie ta różnica jest osią całej dyskusji.
BuiltWith pokazuje skalę wdrożeń
Dane BuiltWith potwierdzają dynamiczny wzrost liczby stron posiadających plik llms.txt. Pokazują jednak jedynie obecność technologii, a nie to, czy jest ona wykorzystywana przez modele AI. Historia SEO zna wiele rozwiązań wdrażanych masowo głównie dlatego, że zostały dodane do CMS-ów i wtyczek.
Rosnąca liczba wdrożeń nie jest więc dowodem na praktyczne znaczenie standardu.
Ahrefs sprawdził logi serwerowe
Znacznie ciekawszych danych dostarcza analiza Ahrefs, oparta na logach HTTP z ponad 137 tys. domen. Zamiast liczyć wdrożenia, firma sprawdziła, czy pliki llms.txt są faktycznie pobierane.
Wyniki okazały się ostrożne. Około 97% plików nie otrzymało ani jednego żądania HTTP w badanym okresie. Nie oznacza to, że modele AI nigdy z nich nie korzystają, ale pokazuje, że wykorzystanie standardu nie jest dziś zjawiskiem powszechnym.
Co więcej, znaczna część odnotowanego ruchu pochodziła od narzędzi monitorujących wdrożenia i skanerów technologicznych, a nie od systemów generujących odpowiedzi użytkownikom. Samo pobranie pliku nie oznacza więc, że został on wykorzystany przez model językowy.
OtterlyAI dochodzi do podobnych wniosków
Podobne obserwacje opublikowało OtterlyAI. W analizie obejmującej ponad 60 tys. wizyt botów AI odwołania do llms.txt stanowiły zaledwie około 0,1% ruchu.
Dwa niezależne badania prowadzą więc do tego samego wniosku: liczba wdrożeń llms.txt rośnie szybko, ale obecnie niewiele wskazuje na jego powszechne wykorzystanie przez systemy AI.
Co na to Google?
Stanowisko Google jest znacznie bardziej powściągliwe niż dyskusja w branży.
John Mueller podkreśla, że systemy Google potrafią samodzielnie analizować strukturę stron i nie potrzebują dodatkowego pliku, aby zrozumieć ich zawartość. Firma nie komunikuje również żadnych korzyści rankingowych wynikających z wdrożenia llms.txt.
Google zwraca też uwagę, że zawartość pliku jest tworzona przez właściciela witryny, a więc stanowi sygnał deklaratywny (self-reported signal). Takie informacje są podatne na manipulacje, dlatego wyszukiwarka większą wagę przywiązuje do sygnałów obserwowanych samodzielnie niż do deklaracji autorów stron.
Na dziś nie ma podstaw, aby traktować llms.txt jako odpowiednik robots.txt czy sitemap.xml ani jako czynnik wpływający na ranking w Google.
Skoro modele potrafią czytać HTML, po co im dodatkowy plik?
Tu pojawia się najważniejszy argument sceptyków
Dyskusja o llms.txt często sprowadza się do prostego założenia: skoro modele językowe mają otrzymać "lepszą mapę strony", powinny generować lepsze odpowiedzi.
Problem polega na tym, że współczesne modele już dziś dysponują bardzo zaawansowanymi mechanizmami analizy dokumentów.
Zarówno systemy wyszukiwania, jak i modele językowe potrafią odróżniać główną treść od elementów nawigacyjnych, reklam, stopki czy komponentów interfejsu. Nie jest to nowa umiejętność rozwijana na potrzeby AI. Podobne techniki od wielu lat wykorzystują klasyczne wyszukiwarki internetowe.
Jeżeli więc model potrafi samodzielnie zidentyfikować właściwy fragment dokumentu, warto zadać pytanie, jaką dodatkową wartość wnosi ręcznie przygotowany przewodnik.
To właśnie ten problem regularnie pojawia się w dyskusjach pomiędzy zwolennikami i sceptykami standardu.
Im lepiej modele radzą sobie z analizą stron, tym trudniej uzasadnić potrzebę istnienia dodatkowej warstwy opisowej.
Różnica między crawlerem treningowym a systemem RAG ma tutaj kluczowe znaczenie
Nie wszystkie modele AI odwiedzają strony z tego samego powodu
Crawler treningowy działa podobnie do klasycznego robota indeksującego internet. Jego zadaniem jest zebranie ogromnej liczby dokumentów, które później zostaną wykorzystane podczas procesu uczenia modelu. W takim scenariuszu liczy się przede wszystkim możliwość pobrania dużych zbiorów danych i ich późniejszego oczyszczenia.
Systemy wykorzystujące architekturę RAG (Retrieval-Augmented Generation) pracują zupełnie inaczej. Nie próbują zbudować kompletnej kopii internetu. Ich zadaniem jest znalezienie odpowiednich dokumentów dopiero w chwili, gdy użytkownik zada konkretne pytanie.
To rozróżnienie zmienia sposób patrzenia na llms.txt.
Ocena przydatności standardu zależy od tego, o którym etapie pracy modelu językowego mówimy.
W systemach RAG liczy się szybkość odpowiedzi
Nowoczesne wyszukiwarki AI działają w kilku etapach. Najpierw wyszukują potencjalnie trafne dokumenty, następnie pobierają ich treść, a dopiero później przekazują ją modelowi językowemu odpowiedzialnemu za wygenerowanie odpowiedzi.
Z perspektywy takiej architektury pojawia się istotne pytanie.
Jeżeli system już wie, że odpowiedź znajduje się pod konkretnym adresem URL, czy ma powód, aby wykonywać dodatkowe zapytanie HTTP tylko po to, żeby pobrać plik llms.txt, przeczytać listę polecanych materiałów i ponownie wrócić do wcześniej znalezionej strony?
Właśnie tutaj pojawiają się największe wątpliwości dotyczące praktycznej użyteczności standardu. Każdy dodatkowy krok wydłuża czas odpowiedzi i zwiększa liczbę operacji wykonywanych przez system.
W środowisku, w którym liczą się milisekundy, nie jest to argument bez znaczenia.
Jeżeli wyszukiwarka AI zna już właściwy dokument, dodatkowy przewodnik może okazać się po prostu zbędny.
Są jednak scenariusze, w których llms.txt wydaje się mieć więcej sensu
Najlepszym przykładem są narzędzia programistyczne
To, że Google zachowuje ostrożność, nie oznacza automatycznie, że cały standard jest pozbawiony wartości.
Wręcz przeciwnie. Badania pokazują, że największe zainteresowanie llms.txt pojawia się nie w klasycznych wyszukiwarkach, lecz w środowisku narzędzi dla programistów.
Asystenci kodowania, agenci wykonujący zadania oraz systemy analizujące dokumentację techniczną często pracują na znacznie mniejszych zbiorach danych niż wyszukiwarki internetowe. W takim przypadku ręcznie przygotowany przewodnik po dokumentacji może rzeczywiście skrócić czas potrzebny na odnalezienie odpowiednich informacji.
Nieprzypadkowo jednymi z pierwszych serwisów wdrażających llms.txt były platformy publikujące dokumentację API, biblioteki programistyczne oraz projekty open source.
To środowisko znacznie lepiej odpowiada pierwotnym założeniom Jeremy'ego Howarda niż klasyczny portal informacyjny czy sklep internetowy.
Najbardziej przekonujące zastosowania llms.txt dotyczą dziś dokumentacji technicznej, a nie szeroko rozumianego SEO.
Warto oddzielić potencjał standardu od jego obecnej roli
Po zestawieniu danych z Ahrefs, analiz OtterlyAI oraz stanowiska Google trudno obronić tezę, że llms.txt stał się już powszechnie wykorzystywanym elementem infrastruktury AI. Jednocześnie równie trudno uznać go za projekt całkowicie pozbawiony sensu.
Specyfikacja rozwiązuje konkretny problem opisany przez jej autora i znajduje zastosowanie w określonych scenariuszach, zwłaszcza tam, gdzie modele pracują na dokumentacji technicznej lub wykonują zadania agentowe. To jednak nie to samo, co potwierdzenie szerokiego wykorzystania przez wyszukiwarki AI obsługujące miliony codziennych zapytań.
Ta różnica jest kluczowa dla całej dyskusji. Zamiast pytać, czy llms.txt „działa”, warto zapytać dla kogo i w jakim środowisku został zaprojektowany. Dopiero wtedy można rzetelnie ocenić jego potencjał.
Argumenty za i przeciw llms.txt. Dlaczego branża SEO jest podzielona?
Kontrowersje wokół llms.txt nie dotyczą samej specyfikacji. Format jest prosty i łatwy do wdrożenia. Spór dotyczy tego, czy rozwiązuje realny problem współczesnych modeli językowych.
Można uznać pomysł Jeremy'ego Howarda za logiczny, a jednocześnie wątpić, czy dzisiejsze systemy AI rzeczywiście go potrzebują. W praktyce pytanie nie brzmi więc, czy llms.txt jest poprawnym standardem, lecz czy modele mają powód, by z niego korzystać.
Strony internetowe powstają dla ludzi, nie dla modeli
Zwolennicy wskazują, że współczesne strony zawierają wiele elementów, które dla modeli językowych stanowią jedynie dodatkowy szum. llms.txt ma skrócić drogę do najważniejszych materiałów i wskazać priorytety, a nie zastępować HTML czy sitemap.xml.
W tym ujęciu standard pełni rolę przewodnika, a nie nowego sposobu publikowania treści.
Modele coraz lepiej radzą sobie bez niego
Sceptycy zwracają uwagę, że nowoczesne modele potrafią samodzielnie rozpoznawać strukturę dokumentów i oddzielać treść od elementów nawigacyjnych. W systemach opartych na RAG odczytanie dodatkowego pliku oznacza też kolejne zapytanie HTTP i większy koszt przetwarzania.
Jeżeli model już odnalazł właściwy dokument, dodatkowy przewodnik może okazać się zbędny.
Obie strony mają rację w pewnym zakresie
Obecne dane sugerują, że llms.txt może być wartościowy w niektórych zastosowaniach, takich jak dokumentacja techniczna czy systemy agentowe. Jednocześnie nie ma dowodów, że odgrywa dziś istotną rolę w klasycznych wyszukiwarkach AI.
Dlatego standard warto traktować jako obiecujący eksperyment, a nie obowiązkowy element technicznego SEO.
Co można uznać za potwierdzone?
Sam standard istnieje i szybko zyskuje popularność
Nie ma wątpliwości, że llms.txt jest rozwijanym projektem. Od publikacji specyfikacji pojawiły się kolejne implementacje, generatory i wsparcie w narzędziach dla dokumentacji technicznej, a liczba wdrożeń rośnie bardzo szybko.
Dyskusja nie dotyczy istnienia standardu, lecz skali jego rzeczywistego wykorzystania.
Nie ma dowodów na wpływ na Google
Google nie potwierdziło, aby llms.txt wpływał na ranking lub działanie AI Overviews. John Mueller podkreśla, że wyszukiwarka potrafi samodzielnie analizować strukturę stron i nie potrzebuje dodatkowego pliku do zrozumienia ich treści.
Obecnie nie ma podstaw, aby traktować llms.txt jako czynnik rankingowy.
Co można uznać za mit?
„llms.txt działa tak samo jak robots.txt”
To jedno z najczęściej powtarzanych uproszczeń. Choć oba pliki znajdują się w katalogu głównym domeny, pełnią zupełnie inne funkcje.
robots.txt służy do komunikacji z crawlerami i określania zasad dostępu do zasobów. llms.txt niczego nie blokuje ani nie wpływa na indeksowanie. Jego rolą jest jedynie wskazanie materiałów, które właściciel strony uważa za najważniejsze.
Porównanie do robots.txt może być użyteczne jako metafora, ale technicznie oba rozwiązania rozwiązują zupełnie inne problemy.
„Wdrożenie llms.txt poprawia SEO”
Obecnie nie ma danych potwierdzających taki wpływ. Żadne z dostępnych badań nie wykazało wzrostu widoczności organicznej po wdrożeniu standardu, a Google nie komunikuje, by traktowało llms.txt jako sygnał rankingowy.
Nie oznacza to, że sytuacja nie zmieni się w przyszłości. Na dziś jednak łączenie llms.txt z klasycznym SEO wykracza poza dostępne dowody.
Obecnie nie ma podstaw, aby przedstawiać llms.txt jako czynnik wpływający na pozycje w Google.
„Brak llms.txt sprawia, że AI nie korzysta z treści strony”
To również nie znajduje potwierdzenia. Modele językowe od lat analizują strony internetowe bez pomocy llms.txt, korzystając z crawlerów, własnych indeksów i mechanizmów wyszukiwania.
Jeżeli system AI wykorzystuje treści danej witryny, najczęściej robi to dzięki istniejącej infrastrukturze indeksowania, a nie dlatego, że znalazł plik llms.txt.
Brak llms.txt nie oznacza niewidoczności strony dla systemów AI.
Jak powinien spojrzeć na to wydawca?
Jeśli prowadzisz stronę, możesz wdrożyć llms.txt, ale dziś nie ma podstaw, by oczekiwać wymiernych efektów.
Samo przygotowanie pliku nie jest trudne i w większości przypadków nie wiąże się z dużymi kosztami. Problem polega na tym, że obecnie brakuje dowodów, aby jego wdrożenie przekładało się na lepszą widoczność w Google, częstsze cytowanie przez systemy AI czy większy ruch na stronie.
Nie oznacza to jednak, że llms.txt jest bezwartościowy. Jeżeli prowadzisz rozbudowaną dokumentację, bazę wiedzy lub serwis z dużą liczbą materiałów eksperckich, taki przewodnik może okazać się przydatny w przyszłości, zwłaszcza wraz z rozwojem agentów AI.
Na dziś llms.txt warto traktować jako eksperyment, który kosztuje niewiele, ale którego korzyści nie zostały jeszcze potwierdzone.
W przypadku większości wydawców znacznie większy wpływ na widoczność będą jednak miały działania o potwierdzonej skuteczności: tworzenie wartościowych treści, poprawa architektury informacji, danych strukturalnych czy szybkości działania serwisu.
To właśnie te obszary powinien wspierać dobry CMS.
CMS 4media został zaprojektowany z myślą o portalach informacyjnych i mediach lokalnych, dlatego wspiera działania o potwierdzonej skuteczności, oferując m.in. wbudowane funkcje SEO, obsługę danych strukturalnych, optymalizację pod Google News, asystenta AI oraz inne udogodnienia, które usprawniają codzienną pracę redakcji.
