llms.txt: fakty kontra hype w widoczności AI

llms.txt to plik tekstowy w katalogu głównym domeny, który ma podpowiadać modelom językowym, które strony serwisu są najważniejsze. Część branży SEO sprzedaje go jako warunek cytowania w ChatGPT czy Perplexity. Dowodów na to nie ma. Google wprost mówi, że plik jest zbędny, a trzy niezależne badania z 2026 roku na łącznej próbie ponad 400 tysięcy domen nie wykazały żadnego liftu.

Czym jest plik llms.txt?

llms.txt to zwykły plik tekstowy w formacie Markdown, publikowany pod adresem typu twojadomena.pl/llms.txt, który ma streszczać najważniejsze zasoby witryny w formie czytelnej dla modeli językowych. Koncepcję zaproponował pod koniec 2024 roku Jeremy Howard z Answer. AI, twórca biblioteki fastai, jako odpowiedź na problem, że strony internetowe są przeładowane nawigacją, reklamami i skryptami, przez co model musi „przekopywać się” przez niepotrzebny szum, żeby dotrzeć do treści.

Porównanie do sitemap.xml jest kuszące, ale mylące. Sitemap.xml to sformalizowany, egzekwowany protokół XML, który wyszukiwarki faktycznie odczytują i wykorzystują do planowania crawlowania. llms.txt to propozycja jednego autora, bez formalnej specyfikacji przyjętej przez konsorcjum czy operatora, bez mechanizmu weryfikacji i bez zobowiązania żadnego dostawcy modelu do jego odczytywania. To różnica fundamentalna: jeden standard ma odbiorcę, który go respektuje, drugi na razie nie.

Co dokładnie ma zawierać plik llms.txt?

Plik zaczyna się od nagłówka H1 z nazwą projektu lub firmy, krótkiego opisu w jednym akapicie, a potem list linków pogrupowanych sekcjami, gdzie każdy odnośnik ma jednozdaniowy opis. Dla strony firmowej będą to zwykle: oferta, dokumentacja, najważniejsze artykuły z bazy wiedzy, dane kontaktowe. Niektóre wdrożenia dodają wariant llms-full.txt, czyli pełną treść najważniejszych stron sklejoną w jednym dokumencie, żeby model mógł ją pobrać za jednym zapytaniem.

Techniczne wdrożenie zajmuje od 30 minut do godziny, nawet ręcznie, bo to zwykły plik statyczny bez wymogów serwerowych. Problem nie leży w trudności wykonania, tylko w tym, że nie ma dziś operatora modelu, który potwierdziłby, że w ogóle sprawdza ten plik przed wygenerowaniem odpowiedzi. Sam format jest logiczny i schludny. Pytanie brzmi, czy ktokolwiek po drugiej stronie go czyta.

Czy Google bierze pod uwagę llms.txt w wynikach i AI Overviews?

Nie, i od czerwca 2026 roku to stanowisko wyrażone jest wprost, nie tylko w komentarzach pracowników na konferencjach. 15 czerwca 2026 Google Search Central zaktualizował swój przewodnik po optymalizacji pod funkcje generatywne, dodając sekcję „Mythbusting generative AI search”. Napisano w niej dosłownie: nie trzeba tworzyć nowych plików czytelnych maszynowo, plików tekstowych AI, znaczników ani dokumentów Markdown, żeby pojawić się w Google Search, w tym w jego funkcjach generatywnych, ponieważ Google Search po prostu z nich nie korzysta . To sformułowanie obejmuje wprost AI Overviews i AI Mode, czyli generatywne funkcje wyszukiwania Google.

To nie jest nowa opinia, tylko domknięcie stanowiska, które Google powtarzał od dłuższego czasu w mniej formalnych kanałach. John Mueller z zespołu Search Relations porównywał llms.txt do dawnego meta tagu keywords: to, co właściciel strony deklaruje o swojej witrynie, a nie to, co wyszukiwarka faktycznie w niej znajduje, więc żaden poważny system nie ma powodu na tym polegać. Gary Illyes i Amir Taboul potwierdzili na Search Central Live Asia Pacific w 2025 roku, że Google nie planuje wdrażać obsługi tego formatu. Poziom pewności tego faktu jest wysoki: to oficjalna dokumentacja operatora, nie interpretacja trzeciej strony.

Skoro Google go ignoruje, dlaczego Chrome ma audyt sprawdzający llms.txt?

Bo Google to nie jeden zespół z jednym zdaniem, tylko kilka produktów z osobnymi celami, i tu leży niuans, który większość poradników pomija. Lighthouse 13.3, narzędzie do audytu stron w Chrome DevTools, wprowadziło w maju 2026 eksperymentalną kategorię „Agentic Browsing”, która sprawdza między innymi obecność i poprawność pliku llms.txt. To brzmi jak sprzeczność ze stanowiskiem zespołu Search, ale nią nie jest, bo dotyczy zupełnie innego przypadku użycia.

Search Central mówi o widoczności w wynikach wyszukiwania i w AI Overviews, czyli o tym, czy model zdecyduje się zacytować twoją stronę w odpowiedzi na czyjeś pytanie. Lighthouse mówi o agentach przeglądarkowych, czyli programach, które w imieniu użytkownika klikają, wypełniają formularze i nawigują po realnej stronie internetowej, tak jak Gemini w trybie agentowym czy podobne narzędzia innych dostawców. Dla takiego agenta uporządkowana mapa serwisu może realnie skrócić czas nawigacji. To jednak zupełnie inny cel niż bycie źródłem cytowanym w odpowiedzi generatywnej, i mylenie tych dwóch przypadków to najczęstsza przyczyna nieporozumień wokół tego pliku.

Co pokazują najnowsze badania o wpływie llms.txt na cytowania?

Pokazują zgodnie jedno: brak mierzalnego efektu, na próbach znacznie większych niż te cytowane jeszcze rok temu. Trzy niezależne badania z 2026 roku, o różnej metodologii i różnych autorach, doszły do tego samego wniosku z próby przekraczającej łącznie 400 tysięcy domen.

Wspólny mianownik tych trzech badań to metoda obserwacyjna, nie eksperyment kontrolowany z losowym przypisaniem. Żadne z nich nie dowodzi, że llms.txt nigdy nie zadziała. Dowodzą czegoś węższego, ale mocniejszego niż rok temu: na dziś, przy obecnej skali adopcji przez operatorów modeli, plik nie ma wykrywalnego wpływu na to, czy strona zostanie zacytowana. Poziom pewności: średni, bo to dane korelacyjne z dużych, przejrzystych prób, nie badania przyczynowe.

Dlaczego część branży mimo to sprzedaje llms.txt jako warunek cytowania?

Bo to prosta, tania usługa do zaoferowania klientowi, a niepewność wokół nowych formatów AI ułatwia przypisywanie im magicznych właściwości. Część polskich i zagranicznych poradników SEO podaje przy llms.txt konkretne liczby bez wskazanej metodologii: ile procent „wagi” w decyzji modelu ma rzekomo ten plik, po ilu tygodniach mają pojawić się pierwsze cytowania. Żadna z tych liczb nie ma źródła możliwego do zweryfikowania, a to jest dokładnie ten typ materiału, który zgodnie z zasadą przyjętą w tym miejscu nie jest traktowany jako dowód.

Nie zgadzamy się z tą narracją, bo klient, któremu sprzeda się plik tekstowy jako "warunek cytowania", zapłaci za coś, co żaden operator modelu nie potwierdza, że w ogóle odczytuje, kosztem czasu i budżetu, które mogłyby pójść w rzeczy z dowodami: jakość treści, dane pierwotne, obecność w miejscach, gdzie model faktycznie szuka źródeł. To nie znaczy, że plik jest szkodliwy. Znaczy, że jego sprzedaż jako gwarancji widoczności w AI nie ma pokrycia w żadnym z cytowanych wyżej badań ani w stanowisku Google.

Czy mimo braku dowodów warto wdrożyć llms.txt?

Tak, ale wyłącznie z właściwym uzasadnieniem: jako tani, niskoprocentowy eksperyment przy dokumentacji technicznej, nie jako narzędzie zwiększające cytowania w ChatGPT czy Perplexity. Agenci kodujący, tacy jak asystenci pracujące w środowiskach deweloperskich, faktycznie w niektórych przypadkach sięgają po tego typu pliki, żeby szybciej zrozumieć strukturę dokumentacji API czy repozytorium. To realny, choć wąski, przypadek użycia, zupełnie inny niż cytowanie marki w odpowiedzi na pytanie użytkownika.

Koszt wdrożenia jest niski (30 do 60 minut pracy), a ryzyko techniczne minimalne: żadne z cytowanych badań nie wykazało negatywnego wpływu na widoczność w wyszukiwarce. Jedyna praktyczna ostrożność dotyczy wariantu llms-full.txt, gdzie kopiowanie pełnej treści stron do osobnego dokumentu bez odpowiednich sygnałów kanonicznych może w teorii tworzyć duplikację treści. Rekomendacja jest więc umiarkowana: jeśli masz dokumentację techniczną i zasoby, żeby to zrobić przy okazji innych prac, zrób to bez obietnic wobec klienta czy przełożonego, że przełoży się to na częstsze cytowania. Jeśli miałoby to zająć budżet przeznaczony na treść dowodową czy obecność w miejscach faktycznie korelujących z cytowaniami, nie jest to dobra inwestycja.

FAQ