llms.txt: Google mówi „niepotrzebne” — i sam go audytuje w Lighthouse. Co robić w 2026?

Skąd w ogóle wziął się llms.txt?

Standard zaproponował Jeremy Howard (Answer.AI) 3 września 2024. Pomysł jest prosty: plik /llms.txt w katalogu głównym domeny, pisany Markdownem — nagłówek z nazwą serwisu, streszczenie i sekcje z linkami do najważniejszych treści. Wariant llms-full.txt zawiera od razu pełną treść. Uzasadnienie: okna kontekstu modeli są za małe na całe strony, a HTML pełen nawigacji i skryptów źle się konwertuje. „Autorzy stron wiedzą najlepiej, co model powinien przeczytać” — pisał Howard.

Co dokładnie mówi Google?

Stanowisko Google jest konsekwentne od ponad roku i łatwe do udokumentowania:

• Kwiecień 2025 — John Mueller na Reddicie: „O ile wiem, żaden serwis AI nie zadeklarował, że używa llms.txt (a po logach serwera widać, że nawet o niego nie pytają). Dla mnie to odpowiednik meta tagu keywords.”
• Lipiec 2025 — Gary Illyes na Search Central Live: Google nie używa llms.txt i nie planuje.
• Oficjalna dokumentacja (sprawdziliśmy bezpośrednio 25.07.2026): „You don't need to create new machine readable files, AI text files, or markup to appear in these features.”
• 15 czerwca 2026 — doprecyzowanie w wytycznych: tworzenie takich plików „nie zaszkodzi (ani nie pomoże) widoczności w Google Search, bo Google Search je ignoruje”.

Skoro Search go ignoruje, czemu Lighthouse go sprawdza?

Na początku maja 2026 — miesiąc przed tym doprecyzowaniem — Lighthouse 13.3 dostał nową kategorię audytu Agentic Browsing, a w niej sprawdzanie… llms.txt (obok WebMCP, drzewa dostępności i CLS). Oficjalny opis Chrome: bez tego pliku „agenci mogą spędzać więcej czasu na crawlowaniu strony, żeby zrozumieć jej strukturę i główną treść”.

To nie jest sprzeczność w jednej głowie — to dwa zespoły i dwa różne pytania. Zespół Search odpowiada na pytanie „czy ten plik wpływa na ranking?” (nie wpływa). Zespół Chrome odpowiada na pytanie „czy strona jest przygotowana na agentów AI, którzy będą po niej nawigować?” — i tu llms.txt traktowany jest jako wschodząca konwencja. Ważny szczegół techniczny: brak pliku daje w audycie status „Not Applicable” i nie obniża wyniku; walidowana jest dopiero poprawność istniejącego pliku.

Co mówią dane o adopcji i realnym użyciu?

Dla kontrastu: boty AI są bardzo aktywne — GPTBot generował ~569 mln żądań miesięcznie, ClaudeBot ~370 mln (dane z sieci Vercel). One po prostu crawlują strony, nie plik llms.txt. Żaden duży dostawca LLM (OpenAI, Anthropic, Google, Perplexity) formalnie nie zadeklarował czytania tego standardu.

Kto naprawdę ma llms.txt — nasz własny test

Sprawdziliśmy 25 lipca 2026 dwanaście kluczowych domen (curl, bez pośredników):

Wzór jest wyraźny: plik żyje na subdomenach dokumentacji deweloperskiej, nie na stronach głównych. I to jest klucz do całej układanki — bo jedyni potwierdzeni konsumenci llms.txt to asystenci kodowania (Cursor, GitHub Copilot, Continue), które używają go do nawigacji po docsach. Nawet Mueller przyznaje: dla narzędzi AI do kodu plik „oszczędza trochę tokenów”.

Nasza rekomendacja

• Masz dokumentację produktu, API, bazę wiedzy? Wdrażaj — koszt to około godziny, a realni odbiorcy (coding assistants, agenci) istnieją.
• Masz zwykłą stronę firmową? Opcjonalnie. Zero efektu w Google dziś, ale zielony status w Lighthouse i zabezpieczenie na wypadek, gdyby agentic web dojrzał. My na adawards.ai plik mamy — z dokładnie takimi oczekiwaniami.
• Czego nie robić: nie obiecuj sobie (ani klientom) wpływu na pozycje w Google — to wprost zdementowane. I pilnuj spójności pliku z treścią strony, bo rozjazd zamienia go w „keywords meta tag 2.0”, przez który standard umrze.

Widoczność w odpowiedziach AI buduje struktura samej treści — cytowalne dane, pytaniowe nagłówki, weryfikowalne źródła — a nie plik tekstowy w rootcie domeny. O tym, które taktyki dają zmierzony efekt, piszemy w osobnej analizie badania GEO z Princeton.