Google rozdwoil komunikat o llms.txt. 22 maja 2026 zespol Chrome wpuscil do publicznego Lighthouse 13.3 nowa kategorie audytu o nazwie Agentic Browsing, ktora domyslnie sprawdza, czy strona udostepnia plik llms.txt. W tym samym tygodniu Search Liaison Google powtorzyl, ze widocznosc w AI Search nie wymaga tego pliku, a John Mueller probowal pogodzic oba stanowiska na LinkedIn. Dla branzy SEO i AIO oznacza to bardzo konkretny problem: ktorego sygnalu sluchac, jezeli oba pochodza z Mountain View.
Sprzecznosci nie ma w samym pliku. Spor toczy sie o to, czy llms.txt sluzy do wyszukiwania, do dzialania agentow, do dokumentacji, czy moze do wszystkich trzech naraz. Roznica jest istotna, bo decyduje o tym, kto ma poswiecic czas na utrzymanie kolejnego pliku w katalogu glownym, i kto z tego ostatecznie skorzysta.
Pytanie nabiera ciezaru w samym srodku rolloutu May 2026 Core Update, ktory startowal 21 maja i potrwa do dwoch tygodni. Wydawcy zywo komentuja zmiany pozycji w SERPach, agencje raportuja klientom, a do tego dochodzi nowa pozycja w raporcie Lighthouse. W praktyce oznacza to, ze dyskusja o llms.txt rozgrywa sie w warunkach maksymalnej widocznosci, w ktorej kazdy sygnal jest interpretowany szybciej, niz produkty Google moga go oficjalnie wyjasnic.
Co dokladnie dodal Lighthouse 13.3
Chrome team opublikowal kategorie Agentic Browsing jako oddzielna sekcje audytu, zaraz obok Performance, Accessibility, Best Practices, SEO oraz PWA. Nowa sekcja zawiera dwie grupy testow: wykrywanie pliku llms.txt oraz audyt jego zawartosci.
Jezeli plik jest obecny, Lighthouse sprawdza trzy warunki: czy zaczyna sie od pojedynczego naglowka H1, czy zawiera co najmniej kilka linijek opisu produktu lub uslugi, oraz czy umieszczono w nim odnosniki do najwazniejszych podstron. Brak pliku jest sygnalizowany jako „could not be detected”, ale nie generuje czerwonego znacznika tylko notatke informacyjna. Audyt zlej zawartosci, na przyklad pliku bez H1 lub bez linkow, zwraca juz status warning.
Wedlug dokumentacji Chrome for Developers nowa kategoria jest „eksperymentalna” i kierowana glownie do „agentic browsing scenarios”, czyli sytuacji w ktorych autonomiczne agenty (przegladarki AI typu Comet, ChatGPT Atlas, asystenci w Gemini) maja zrozumiec strukture serwisu bez pobierania calego DOM. Jest to wyraznie inne podejscie niz robots.txt, ktore reguluje dostep, lub sitemap.xml, ktore wylicza adresy.
Czemu sluzy ten plik
Specyfikacja llms.txt powstala poza Google, w spolecznosci developerow zwiazanych z modelami jezykowymi. Format jest celowo minimalny: H1 z nazwa produktu, kilka linijek opisu, lista linkow do dokumentacji i sekcji uslug, opcjonalnie sekcja Optional dla zasobow rozszerzonych. Plik jest serwowany pod adresem /llms.txt i pisany w czystym Markdown.
Logika za propozycja zaklada, ze agent AI nie chce parsowac calego sitemap, czyta natomiast krotki indeks, ktory zawiera zrozumiale dla modelu opisy zamiast samych URL. To duza roznica w kontekscie LLM Engine Optimization (LLMO), bo zmienia ekonomie context window: agent dostaje od razu mape priorytetow zamiast 200 linkow z sitemap bez znaczenia semantycznego.
Wsparcie pliku w ekosystemie roslo stopniowo od jesieni 2024 roku. W maju 2026 publiczne biblioteki Pythona i Node, generujace llms.txt z markdown bloga lub wpisow w GitBooku, zanotowaly trzykrotny wzrost liczby pobran w porownaniu z marcem. W rezultacie, kiedy Chrome wlozyl audyt pliku do Lighthouse, ruch w spolecznosci developerow byl juz w tym kierunku skierowany, nawet jezeli wlasny indeks Google nadal go nie potrzebuje.
Stanowisko Search: nadal nie potrzebujecie tego pliku
Search Liaison opublikowal w maju aktualizacje przewodnika dla wydawcow w zakresie AI Search, w ktorej powtorzyl trzy zasady. Po pierwsze, AI Overviews oraz AI Mode korzystaja z tego samego indeksu co klasyczne wyszukiwanie. Po drugie, optymalizacje zwane AEO (Answer Engine Optimization) oraz GEO (Generative Engine Optimization) sa „nadal SEO”, a wiec opieraja sie na sygnalach typu E-E-A-T, tresci pomocnej dla uzytkownika i poprawnym renderowaniu. Po trzecie, plik llms.txt nie jest wymagany ani brany pod uwage w rankingu cytowan.
Powod, dla ktorego Search nie uznaje pliku, jest pragmatyczny. Google deklaruje, ze „nie potrzebuje znacznika opisujacego strone, jezeli sam jest w stanie ja renderowac i klasyfikowac” oraz, ze duplikowanie informacji w osobnym pliku zwieksza ryzyko rozjazdu miedzy tym, co widzi crawler, a tym, co czyta uzytkownik. Search Quality team obawia sie sytuacji, w ktorej publishers zaczna pisac „alternatywna prawde” w llms.txt tylko po to, by zoptymalizowac cytowania.
Reakcja Search Liaison
W krotkim watku z 22 maja Liaison przypomnial wydawcom, ze nie warto wprowadzac zmian w architekturze tylko dla pliku, ktorego dwa najwieksze produkty Google nie przetwarzaja. Wskazal jednoczesnie, ze publishers, ktorzy juz uzywaja llms.txt jako pomocy dla integracji z ChatGPT lub Perplexity, „moga go nadal udostepniac, nic to nie zepsuje”.
Drugi watek dotyczyl renderowania. Search Liaison podkreslil, ze Googlebot oraz nowy GoogleOther z rozszerzeniem AI Mode i tak musza renderowac strone w pelnej wersji DOM, aby ocenic kontekst tresci. W tej sytuacji wartosc dodana statycznego pliku llms.txt jest dla rankingu marginalna. Inna sytuacja moglaby zaistniec, gdyby Google opublikowal publiczne API dla agentow trzecich, ktore polegaja na zewnetrznym opisie serwisu, ale takiego API w komunikacie z I/O 2026 nie zapowiedziano.
Stanowisko Chrome i Lighthouse: agent potrzebuje mapy
Chrome team prezentuje zupelnie inna logike. Z punktu widzenia produktu, ktory ma za zadanie ocenic jakosc strony pod katem „agentic browsing”, brak ustrukturyzowanej mapy oznacza wyzszy koszt i wieksza zawodnosc agenta. Zespol Lighthouse argumentuje, ze sygnalizowanie publishers, iz plik jest oczekiwany, zmniejszy ryzyko halucynacji i zwiekszy stabilnosc agentow trzecich.
Trzeba zaznaczyc, ze Lighthouse 13.3 nie kara braku pliku w ogolnym wyniku Performance ani w SEO. Audyt Agentic Browsing jest sekcja eksperymentalna, raportujaca osobno. Ale w branzy widac juz pierwsze konsekwencje: agencje, ktore raportuja klientom raporty Lighthouse, znajduja w ostatnich dniach nowe pole z notatka „llms.txt could not be detected”, co generuje pytania od marketingu i czasem nieuzasadnione panikowanie.
Co sprawdza audyt szczegolowo
| Test | Co kontroluje | Status braku |
|---|---|---|
| llms.txt obecnosc | HTTP 200 na /llms.txt | Informational |
| H1 na poczatku | Pierwsza linia w pliku zaczyna sie od # | Warning |
| Dlugosc | Co najmniej 200 znakow zawartosci | Warning |
| Linki | Minimum kilka odnoskow w sekcji glownej | Warning |
| Optional section | Sekcja Optional dla zasobow rozszerzonych | Info |
Mueller probuje pogodzic dwa glosy
W krotkim wpisie na LinkedIn John Mueller zwrocil uwage, ze pomylka tkwi w lekturze sygnalu jako „Google chce, zebyscie mieli llms.txt”. Mueller rozdzielil dwie sytuacje: „discovery”, czyli odnajdywanie strony lub konkretnych podstron przez globalny silnik wyszukiwania, oraz „functionality”, czyli pomoc uzytkownikowi w wykonaniu zadania w obrebie znanego mu juz serwisu.
W jego ocenie Markdown w katalogu glownym, czyli dokladnie to, co opisuje llms.txt, ma zastosowanie w drugiej kategorii. Dla wiekszosci publishers, ktorych celem jest discovery (czyli pozyskanie ruchu z Google Search lub cytowan w AI Overviews), plik nadal niczego nie zmienia. Dla narzedzi technicznych i SaaS, ktorych uzytkownicy laczacy sie przez Comet lub Atlas wykonuja konkretne zadanie na produkcie, llms.txt moze byc realnym usprawnieniem.
„Lighthouse nie jest narzedziem rankingowym, jest narzedziem deweloperskim. To samo dotyczy nowej kategorii Agentic Browsing”, podsumowal Mueller. Wedlug niego sprzecznosci z Search nie ma, jest natomiast roznica zakresu produktow.
Co to znaczy dla SEO i AIO
W praktyce sygnaly z Google sugeruja trzy bardzo rozne decyzje, w zaleznosci od profilu strony. Dla klasycznego sklepu, bloga lokalnego lub serwisu informacyjnego implementacja llms.txt jest dzisiaj kosztem bez przychodu, bo zaden z systemow rankingowych Google ani Bing tego pliku nie czyta w celach decyzyjnych.
Inaczej wyglada to dla narzedzi B2B SaaS, platform dokumentacyjnych, repozytoriow danych oraz uslug, ktorych uzytkownicy regularnie wchodza w interakcje przez agenty AI. Tutaj plik staje sie czyms w rodzaju „developer-facing manifestu”. Coraz wiecej platform LLMO udostepnia automatyczne generatory tego pliku z sitemap, co obniza koszt wdrozenia do 20 minut pracy.
Lista decyzyjna dla wydawcy
- Jezeli main KPI to ruch organiczny z Google Search lub Bing, mozecie zignorowac plik bez konsekwencji.
- Jezeli main KPI to cytowania w ChatGPT, Perplexity lub Gemini, plik nadal nie wplywa na ranking, ale poprawia czytelnosc serwisu dla niezaleznych agentow.
- Jezeli serwis jest narzedziem (SaaS, dashboard, dokumentacja API) i jego uzytkownicy przychodza coraz czesciej z Comet, Atlas lub asystentow w Edge, plik realnie zmniejsza koszt rozumienia produktu przez agenta.
- Jezeli prowadzicie agencje SEO i raportujecie wyniki Lighthouse klientom, warto ujac w komentarzu, ze sekcja Agentic Browsing jest eksperymentalna i nie wlicza sie do Performance.
Reakcje branzy
Aleyda Solis nazwala decyzje Chrome team „krokiem w strone bezposredniej rozmowy z wydawcami, bez czekania, az AI Mode dorosnie do rozumienia kazdego CMSa”. Lily Ray przypomniala, ze najwiekszym ryzykiem dla SEO jest interpretacja sygnalu z Lighthouse jako „must-have” w sytuacji, gdy Search publicznie mowi cos innego.
Marie Haynes wskazala dodatkowy watek: jezeli Gemini 3.5 Flash, ktory wlasnie zostal modelem domyslnym w AI Mode, zacznie wewnetrznie korzystac z llms.txt do orientacji w serwisie (czyli nie do rankingu, ale do generowania trafniejszej odpowiedzi), to z czasem plik moze stac sie nieformalnym sygnalem jakosci. Na razie jest to spekulacja, ale spojna z kierunkiem ewolucji AI Mode w 2026 roku.
Wsrod polskich seowcow opinie sa podzielone. Jakub Kowalski (Brand24 SEO) napisal na X, ze „to dobra okazja, zeby wreszcie zrobic uczciwa mape strony, niezaleznie od tego, czy Google to czyta”. Z kolei zwolennicy linii Search Liaison przekonuja, ze nie ma sensu duplikowac informacji z sitemap.xml w trzecim formacie.
W srodowisku agencyjnym pojawil sie watek raportowy. Audyt Lighthouse jest standardem zalaczanym do ofert i reportingu miesiecznego, a sekcja Agentic Browsing pojawia sie teraz w raportach klientow bez wczesniejszej komunikacji. Czesc agencji juz przygotowala krotkie wyjasnienie („plik nie wplywa na pozycje, audyt jest eksperymentalny”), inne testuja proste szablony llms.txt generowane automatycznie z RSS bloga.
Co dalej
Najblizsze dwa, trzy miesiace pokaza, czy Lighthouse rozszerzy zakres audytu Agentic Browsing (na przyklad o sprawdzenie ai.txt lub manifestow dla agentow firm trzecich), oraz czy AI Mode wykorzysta llms.txt jako sygnal kontekstowy. Z perspektywy wydawcy najbezpieczniejsza strategia w okresie May 2026 Core Update jest skupienie sie na fundamentach: czystej semantyce HTML, jakosci tresci, autorach z biografiami, schema.org i poprawnym renderowaniu klienta dla GoogleBota oraz robotow AI Mode.
Warto rownolegle obserwowac trzy sygnaly. Pierwszym jest stanowisko OpenAI, ktory dotad publicznie nie komentowal pliku llms.txt, ale w dokumentacji nowego Ads Managera w ChatGPT pojawila sie wzmianka o „manifestach produktowych dostepnych dla agenta”. Drugi sygnal pochodzi od Anthropic: w komunikatach do Claude Tool Use stopniowo wzrasta nacisk na strukturyzowane opisy zasobow webowych. Trzeci sygnal to Bing i Microsoft Copilot, ktorzy w I kwartale rozszerzyli zakres dokumentacji dla „structured web for agents”. Jezeli ktorykolwiek z tych graczy uzna llms.txt za standard, sytuacja zmieni sie dla calej branzy.
W praktyce oznacza to, ze decyzja o wdrozeniu pliku w 2026 roku jest klasycznym przykladem zakladu typu „tania opcja”. Koszt 20 minut pracy raz na kwartal moze sie zwrocic, jezeli ktorys z agentow trzecich zacznie publicznie korzystac z pliku. Jednoczesnie ryzyko nieskorzystania jest dzisiaj zerowe, bo zaden produkt nie kara braku.
Jezeli Twoj serwis nalezy do kategorii narzedziowej, w ktorej agent AI rzeczywiscie wykonuje zadanie po stronie uzytkownika, dolozenie minimalnego llms.txt jest dzisiaj relatywnie tanie i ma sens jako test. Mozesz to potraktowac w taki sam sposob, jak kilka lat temu traktowano humans.txt: krotki manifest dla osob i agentow, ktore wlasnie wchodza na strone i potrzebuja w 30 sekund zrozumiec, co znajda dalej. Wiecej kontekstu znajdziesz w naszym poprzednim materiale o llms.txt i chunkingu, w opracowaniu na temat Information Agents Google oraz w naszym AI Citation Source Index 2026.
FAQ
Czy brak pliku llms.txt obniza pozycje strony w Google?
Nie. Search Liaison i John Mueller potwierdzaja, ze klasyczne wyszukiwanie ani AI Overviews nie korzystaja z pliku llms.txt jako sygnalu rankingowego. Lighthouse 13.3 sprawdza plik wylacznie w eksperymentalnej kategorii Agentic Browsing, ktora nie wlicza sie do oceny Performance ani SEO.
Czy warto wdrozyc llms.txt dla serwisu informacyjnego lub bloga?
W obecnym stanie rzeczy nie ma to wymiernego zwrotu. Klasyczny content publisher pozyskuje ruch z Google Search, AI Overviews i cytowan w ChatGPT lub Perplexity. Zaden z tych systemow nie wymaga pliku llms.txt. Mozesz wrocic do tematu, kiedy AI Mode lub OpenAI ogloszi oficjalne wsparcie.
Komu wdrozenie pliku rzeczywiscie sie oplaca?
Narzedziom B2B SaaS, platformom dokumentacyjnym, dashboardom i serwisom, ktorych uzytkownicy laczacy sie przez Comet, ChatGPT Atlas lub asystenty Microsoftu wykonuja konkretne zadanie. Plik staje sie wtedy mapa funkcji dla agenta i obniza koszt wykonania zadania.
Co dokladnie powinno znalezc sie w pliku llms.txt?
Format jest celowo minimalny. H1 z nazwa produktu, dwa, trzy zdania opisu, lista linkow do najwazniejszych sekcji w skladni Markdown, opcjonalnie sekcja Optional dla zasobow rozszerzonych (changelog, polityki, archiwum). Lighthouse waliduje obecnosc H1, dlugosc i liczbe linkow.
Czy llms.txt zastapi w przyszlosci sitemap.xml?
To malo prawdopodobne. Sitemap.xml jest formatem strukturalnym przeznaczonym dla crawlerow indeksujacych, a llms.txt jest formatem narracyjnym przeznaczonym dla modeli jezykowych. Wieksza szansa jest na rownolegle istnienie obu formatow, podobnie jak rss.xml i sitemap.xml dzialaja dzisiaj obok siebie.