Google ponownie miesza w temacie llms.txt. Choć zespół Search od miesięcy powtarza, że plik nie ma znaczenia dla pozycji ani dla obecności w AI Mode, najnowsza wersja Chrome Lighthouse (13.3) wprowadziła audyt sprawdzający obecność llms.txt w katalogu głównym domeny. Sprzeczność wewnątrz jednej firmy w połowie maja 2026 roku każe zadać pytanie, czy w erze agentów AI strona bez machine-readable summary faktycznie traci punkty.
Sygnał, który wysyłają zespoły Google, jest dwuznaczny w stopniu, jakiego społeczność SEO i AIO nie pamięta od czasów meta keywords. Z jednej strony John Mueller publicznie porównuje llms.txt do dawno zdyskredytowanego znacznika meta keywords. Z drugiej, w Chrome DevTools pojawia się świeży audyt, który flaguje stronę bez pliku jako mniej „agent-ready”. Tymczasem wydawcy, agencje i sklepy e-commerce muszą zdecydować, czy w czerwcu wdrażać llms.txt na produkcji, czy poczekać na kolejny ruch ze strony Mountain View.
Co dokładnie się stało w maju 2026 roku
Wydarzenia spięły się w jednym oknie czasowym. Najpierw, 20 maja 2026, na konferencji Google I/O 2026 firma ogłosiła największą od 25 lat przebudowę pola wyszukiwania, oddała AI Mode na Gemini 3.5 Flash jako model domyślny i zaprezentowała pierwsze dane o adopcji: ponad miliard użytkowników miesięcznie w AI Mode i 2,5 miliarda w AI Overviews. Dzień później rozpoczął się rollout May 2026 Core Update, drugiej aktualizacji rdzenia w tym roku. W tle pojawiła się aktualizacja Chrome Lighthouse do wersji 13.3, w której zespół narzędziowy Google włączył kontrolę llms.txt.
Według publicznych wypowiedzi Search Relations Team, llms.txt nie jest potrzebny, żeby pojawić się w generatywnych wynikach Google. Oficjalny przewodnik AI Search powtarza, że „nie trzeba tworzyć nowych plików machine-readable, plików tekstowych dla AI, znaczników ani plików Markdown, żeby pojawić się w generatywnym wyszukiwaniu”. Mueller w odpowiedzi na pytania społeczności wyjaśnił, że krótka odpowiedź brzmi: to nie jest robione dla wyszukiwarki, a strony to coś więcej niż tylko SEO.
Lighthouse 13.3 mówi natomiast wprost: „Bez llms.txt agenci mogą tracić czas na crawl, próbując zrozumieć strukturę i główną treść witryny”. W praktyce raport audytu wyświetli ostrzeżenie, jeśli pliku nie ma w katalogu głównym domeny lub jeśli zwraca on błąd 404. Próg jest binarny: jest lub nie ma.
Kluczowe fakty w skrócie
| Element | Stanowisko Google | Data |
|---|---|---|
| Search Team | llms.txt nie jest potrzebny, nie wpływa na ranking ani AI Mode | aktualna polityka, potwierdzona w maju 2026 |
| John Mueller | porównanie do meta keywords; „to nie jest robione dla wyszukiwarki” | komentarze publiczne, wiosna 2026 |
| Gary Illyes | Google nie wspiera llms.txt i nie planuje wsparcia | lipiec 2025 |
| Chrome Lighthouse 13.3 | audyt obecności pliku, ostrzeżenie przy braku | maj 2026 |
| Oficjalny przewodnik AI Search | „nie potrzebujesz nowych plików machine-readable” | aktualny w maju 2026 |
Krótko: dwie różne ekipy Google produkują w tym samym tygodniu dwie różne rekomendacje dotyczące tego samego pliku. Dla SEO managera to dyskomfort, ale dla zespołów technicznych to konkretny ticket w Jirze, który trzeba zaakceptować lub odrzucić.
Co właściwie testuje Lighthouse 13.3
Nowy audyt nie sprawdza zawartości pliku ani jego zgodności z propozycją specyfikacji. Lighthouse 13.3 wykonuje proste pobranie pod adres /llms.txt i kategoryzuje wynik. Status 200 z treścią tekstową daje zielony znacznik, dowolny inny status (404, 403, 5xx, redirect 30x do strony nieistniejącej) generuje ostrzeżenie w sekcji „agent readiness”. Raport nie blokuje ani nie obniża ogólnej oceny wydajności Lighthouse w sekcji Performance, ale pojawia się w nowej grupie audytów dedykowanych agentom AI.
To rozróżnienie jest istotne. Lighthouse jest narzędziem developerskim i diagnostycznym, używanym przez tysiące zespołów do oceny stanu serwisów przed deployem. PageSpeed Insights ciągnie wyniki Lighthouse, więc audyt pojawi się także w narzędziu webmasterskim. Ale Search Console, Discover ani AI Overviews nie raportują braku llms.txt jako problemu, a w wytycznych Google dla webmasterów nie ma śladu po tym pliku.
Stanowisko Search Team: dlaczego mówią „nie”
Argumentacja Search Team opiera się na trzech filarach. Pierwszy: AI Overviews, AI Mode i Gemini korzystają z tej samej infrastruktury indeksującej, co klasyczny Search. Jeżeli strona jest indeksowana, treść jest dostępna dla modelu. Drugi filar to ryzyko nadużyć. Plik llms.txt jest formą deklaracji właściciela strony: tu jest moja zawartość, taka jest jej hierarchia. W praktyce, jak argumentuje Mueller, niczym nie różni się od starych technik, które operatorzy traktowali jako „tajne wejście” do algorytmu. Trzeci filar: brak masowej adopcji. Według niezależnych obserwacji obecnie llms.txt mają mniej niż 0,3 procent zaindeksowanych domen, w większości serwisy techniczne i dokumentacje SaaS.
W ten kontekst wpisuje się ostatnia wypowiedź Mueller’a: markdown jako format dokumentacji ma sens, jeżeli serwis chce być przeszukiwany przez agenta wykonującego zadania (np. asystent kupujący produkty w imieniu użytkownika). Dla typowych serwisów contentowych, blogów, e-commerce i wydawców, agent i tak czyta HTML, a llms.txt nie zmienia ani sposobu wybierania źródeł, ani sposobu cytowania.
Dlaczego Lighthouse poszedł w drugą stronę
Zespół DevTools w Google działa pod inną logiką niż Search Relations. Lighthouse od dawna zajmuje się ewaluacją czytelności dokumentu dla bota, jakością renderingu, dostępnością i progressive enhancement. Audyt llms.txt wpasowuje się w nową kategorię „agent readiness”, uwzględniającą scenariusze, w których stronę odwiedza nie człowiek, ale autonomiczny agent (Comet, Operator, Search Agents od Google zapowiedziane na lato 2026).
Z perspektywy DevTools llms.txt jest tanim, łatwym do wdrożenia plikiem. Nie zaszkodzi, a może pomóc kolejnym generacjom narzędzi. To podejście „best practice w razie czego”, typowe dla audytów Lighthouse: HTTPS, semantic HTML, alt na obrazach. Ich obecność nie gwarantuje sukcesu, ale brak jest sygnałem złego rzemiosła.
Co to znaczy dla SEO i AIO w polskim rynku
Polskie agencje SEO obserwują temat z dystansem. Sondaż wśród 14 freelancerów i 6 agencji, przeprowadzony pod koniec maja 2026, pokazuje, że tylko 21 procent klientów dopytuje się o llms.txt, a wdrożenie pliku trafia na zlecenie dopiero po pytaniu zarządu. Większość agencji deklaruje, że plik utworzy „przy okazji” innych prac technicznych, ale nie ustawi tego priorytetem.
Wdrożenie kosztuje niewiele. Plik llms.txt w wersji minimalistycznej to lista URL do najważniejszych podstron z krótkim opisem, w formacie markdown. Średni czas wykonania na średniej wielkości serwisie WordPress to 30 do 90 minut, łącznie z generowaniem listy URL i opisem hierarchii. Jeśli mierzysz widoczność w ChatGPT, Perplexity i Gemini, warto rozważyć eksperyment A/B na klastrze tematycznym, podobny do tego, który opisaliśmy w agregacji raportów AIO 2026.
Dla zespołów AIO praktyczna rekomendacja brzmi: traktuj llms.txt jako jeden z elementów scorecard widoczności, ale nie jako silver bullet. Realne dźwignie pozostają niezmienne: jakość treści, struktura entity, autorytet domeny, obecność w cytowaniach AI Overviews (więcej o tym pisaliśmy w analizie pięciu zmian w cytowaniach AI Overviews).
Reakcje branży
Społeczność SEO podzieliła się na trzy obozy. Pierwszy, najliczniejszy, czeka na klarowne stanowisko. Drugi, pragmatyczny, wdraża llms.txt jako „tanie zabezpieczenie”: skoro nie szkodzi, a Lighthouse o tym mówi, to dlaczego nie. Trzeci, sceptyczny, traktuje Lighthouse 13.3 jako pomyłkę komunikacyjną Google i odmawia wdrożenia, dopóki Search Relations Team nie zmieni stanowiska.
Niektórzy specjaliści, jak Aleyda Solis i Lily Ray, przypominają, że historia SEO zna kilka podobnych przypadków rozjazdu komunikacji wewnątrz Google. Najgłośniejszy z nich to spór wokół znacznika nofollow w kontekście link buildingu w 2019 roku, gdy Google wprowadził nowe atrybuty rel=”sponsored” i rel=”ugc”, a społeczność przez kilka miesięcy spierała się o ich faktyczny wpływ na ranking. Wnioski po latach pokazują, że zazwyczaj racja jest po stronie zespołu Search, ale wdrożenie alternatyw nie kosztuje aż tak dużo, żeby z niego rezygnować.
Yoast w cotygodniowym podsumowaniu SEO News wskazuje, że twórcy treści powinni traktować sprzeczne sygnały jako sygnał ostrożności. Plugin Yoast wprowadził w wersji 25.4 (kwiecień 2026) opcjonalną generację llms.txt na bazie XML sitemap, ale ustawia ją domyślnie na wyłączoną. RankMath, według publicznej roadmapy, planuje dodać podobną funkcję w czerwcu 2026 jako „AIO Surface”.
Co dalej i jak się zachować
Patrząc na cykl ostatnich aktualizacji, prawdopodobne są trzy scenariusze rozwoju sytuacji.
- Scenariusz A: Google ujednolici komunikację i wycofa audyt llms.txt z Lighthouse, lub wyraźnie oznaczy go jako eksperymentalny dla agentów stron trzecich. Wtedy plik pozostanie w obszarze „nice to have”.
- Scenariusz B: Search Team dopuści llms.txt jako pomocniczy sygnał dla AI Mode i podobnych powierzchni. Wtedy Lighthouse okaże się zwiastunem przyszłej polityki, a wdrożenia pioniera dadzą realną przewagę.
- Scenariusz C: Nic się nie zmieni przez kolejne 6 do 12 miesięcy. Dwie ekipy Google będą żyły w równoległych światach, a SEO managerowie wybiorą wdrożenie na własne ryzyko.
Praktyczne rekomendacje dla managerów SEO i AIO na drugą połowę maja i pierwszą połowę czerwca 2026 są następujące. Po pierwsze, dodaj sprawdzanie llms.txt do regularnych audytów technicznych, bo Lighthouse i tak będzie raportował jego brak. Po drugie, jeśli prowadzisz serwis dokumentacyjny, SaaS lub bibliotekę API, wygeneruj plik w wersji rozszerzonej, z hierarchią i opisami. Po trzecie, dla serwisów contentowych i e-commerce zostaw decyzję na poziomie „wykonamy, gdy będzie inny ticket techniczny”, ale nie podnoś tego do priorytetu. Po czwarte, mierz widoczność w cytowaniach AI niezależnie od pliku, używając narzędzi opisanych w scorecardzie 12 platform widoczności.
Szczegóły techniczne pliku llms.txt
Specyfikacja, którą promuje Anthropic i autorska społeczność wokół projektu llms-txt.org, opisuje format markdown z nagłówkami H1 dla nazwy projektu, H2 dla sekcji i listą URL z opisem. Plik powinien być umieszczony pod adresem /llms.txt w katalogu głównym domeny, kodowanie UTF-8, content-type text/plain lub text/markdown. Rozszerzona wersja, llms-full.txt, zawiera również pełną treść Markdown dokumentów wskazanych w głównym pliku. Ta rozszerzona wersja ma sens głównie dla dokumentacji technicznej, gdzie model agentowy musi mieć dostęp do całego korpusu w jednym pobraniu.
Lighthouse 13.3 sprawdza tylko obecność pliku /llms.txt. Nie waliduje formatu, nie sprawdza długości, nie testuje obecności llms-full.txt. To minimalny próg techniczny: zwróć status 200 i jakąkolwiek treść tekstową, a audyt przejdzie.
Co z polskim rynkiem wydawców
Wydawcy w Polsce mają obecnie ważniejsze tematy niż llms.txt. Trwający May 2026 Core Update, dyskusja o spadkach ruchu z AI Overviews i decyzje Google Discover dotyczące rozszerzonych profili wydawców (więcej w naszej relacji z Google I/O 2026) zajmują zarówno redakcjom, jak i działom SEO znacznie więcej uwagi. Llms.txt w tym kontekście wygląda jak temat trzeciej kategorii.
Z drugiej strony, redakcje, które już teraz inwestują w widoczność w ChatGPT i Perplexity, traktują plik jako element higieny technicznej. Koszt wdrożenia jest niski, a sygnał „agent-ready” dla narzędzi audytujących jest pozytywny. W praktyce wdrożenie tego pliku można potraktować jak instalację robots.txt: nie zmienia rankingu, ale jest standardem oczekiwanym przez każdy poważny crawl.
Podsumowanie
Sprzeczne sygnały Google w sprawie llms.txt to ciekawy przykład tego, jak duża organizacja produkuje dwa różne stanowiska w tej samej sprawie w tym samym czasie. Z perspektywy SEO i AIO 2026 sytuacja wygląda następująco: plik nie wpłynie istotnie na widoczność w Google Search ani AI Mode, ale jego brak będzie flagowany przez Lighthouse 13.3 i prawdopodobnie przez kolejne narzędzia DevTools. Najbardziej rozsądną strategią jest potraktowanie llms.txt jako elementu agent-readiness, a nie jako sygnału rankingowego. Wdrażaj, jeśli pasuje do twojego stosu technicznego, ale nie buduj wokół niego strategii widoczności.
Czy brak llms.txt obniży moje pozycje w Google?
Nie. Search Team Google publicznie potwierdza, że plik nie jest brany pod uwagę w rankingu ani w AI Mode. John Mueller porównał go do dawnego znacznika meta keywords, który był ignorowany przez algorytm. Audyt Lighthouse 13.3 jest osobnym narzędziem developerskim i nie wpływa na widoczność w wyszukiwarce.
Czy llms.txt pomoże mi pojawiać się w cytowaniach ChatGPT i Perplexity?
Obecnie brak danych potwierdzających ten efekt. Niezależne testy z maja 2026 nie wykazują istotnej różnicy w cytowaniach po dodaniu pliku. Większy wpływ na widoczność w LLM mają jakość treści, struktura entity, autorytet domeny i obecność w źródłach często cytowanych przez modele (Reddit, Wikipedia, branżowe katalogi).
Jak wygenerować llms.txt dla strony WordPress?
Najszybszą opcją jest wtyczka Yoast SEO w wersji 25.4 lub nowszej, gdzie generacja llms.txt na bazie sitemap XML jest opcją w sekcji „Advanced”. RankMath planuje analogiczną funkcję na czerwiec 2026. Ręcznie można utworzyć plik tekstowy z listą najważniejszych URL i krótkimi opisami, umieścić go w katalogu głównym domeny i potwierdzić odpowiedź HTTP 200 w przeglądarce.
Czy Lighthouse 13.3 obniży moją ocenę Performance, jeśli nie mam pliku?
Nie. Audyt llms.txt znajduje się w nowej grupie „agent readiness” i nie wpływa na wynik Performance, Accessibility, Best Practices ani SEO w klasycznym ujęciu Lighthouse. Pojawia się jako ostrzeżenie informacyjne, podobnie jak inne audyty diagnostyczne.
Czy warto czekać z wdrożeniem, aż Google ujednolici stanowisko?
Zależy od kontekstu. Dla serwisów dokumentacyjnych i SaaS warto wdrożyć teraz, koszt jest minimalny, a korzyść dla agentów wykonujących zadania (Operator OpenAI, Comet, Search Agents Google planowane na lato 2026) realna. Dla serwisów contentowych i e-commerce można poczekać na klarowne stanowisko Search Team lub wdrożyć przy okazji innych prac technicznych, bez priorytetowej alokacji zasobów.