llms.txt po badaniu Ahrefs z czerwca 2026 – dlaczego 97% plików nie dostało ani jednego żądania i czy nadal ma sens w GEO?

Badanie Ahrefs opublikowane 15 czerwca 2026 roku mocno ostudziło entuzjazm wokół llms.txt. Najczęściej cytowana liczba brzmi efektownie: 97% plików nie dostało ani jednego żądania. Problem w tym, że bez kontekstu łatwo wyciągnąć z niej zbyt daleki wniosek — na przykład taki, że llms.txt jest martwym standardem albo że należy go natychmiast usuwać.

Dane pokazują coś bardziej konkretnego. W maju 2026 roku zdecydowana większość istniejących plików rzeczywiście była ignorowana, a boty odpowiedzialne bezpośrednio za wyszukiwanie informacji dla ChatGPT, Perplexity czy podobnych usług stanowiły śladową część ruchu. Jednocześnie największe zainteresowanie plikiem było widoczne po stronie agentów AI, narzędzi programistycznych oraz infrastruktury agentowej, czyli dokładnie tam, gdzie pierwotna koncepcja llms.txt ma najwięcej technicznego sensu.

Dlatego pytanie w drugiej połowie 2026 roku nie brzmi już: „czy każda strona powinna mieć llms.txt?”. Odpowiedź na nie jest prosta: nie. Ważniejsze jest ustalenie, czy plik rozwiązuje konkretny problem danego serwisu i czy nie odciąga czasu od działań GEO, które faktycznie wpływają na możliwość znalezienia, zrozumienia i zacytowania treści.

97% bez ruchu brzmi źle, ale najpierw trzeba zrozumieć, co dokładnie zmierzył Ahrefs

Ahrefs przeanalizował 137 210 domen korzystających z Ahrefs Web Analytics, które otrzymały ruch w maju 2026 roku. W katalogu głównym każdej domeny sprawdzono obecność /llms.txt zwracającego kod HTTP 200. Następnie Bot Analytics przeanalizował żądania kierowane do ścieżek związanych z tym plikiem.

Około 28% badanych domen, czyli mniej więcej 38 tys., posiadało poprawnie dostępny plik llms.txt. Ahrefs zaznaczył przy tym istotne ograniczenie: użytkownicy jego analityki to grupa bardziej techniczna i bardziej zainteresowana SEO niż przeciętna strona internetowa. Realny udział llms.txt w całym internecie prawdopodobnie był więc niższy niż 28%.

Dopiero wśród tych około 38 tys. witryn pojawia się słynne 97%.

W maju 2026 roku:

• 97% plików llms.txt nie otrzymało ani jednego żądania;

• tylko około 3%, czyli 1,1 tys. domen, zanotowało jakikolwiek ruch do pliku;

• na tej niewielkiej grupie zarejestrowano łącznie około 22 tys. żądań;

• 96% żądań pochodziło od botów, a około 4% od ludzi;

• aż 77% botów pobierających llms.txt nie było narzędziami AI.

To ostatnie jest ważniejsze niż sama liczba 97%. Wśród około 22 tys. żądań największą kategorią były zwykłe narzędzia audytujące SEO: 4776 żądań, czyli 21,7% całości. Dalej znalazły się niezidentyfikowane boty i scrapery z wynikiem 14,9%, klasyczne crawlery internetowe z wynikiem 13,1% oraz narzędzia profilujące technologie — 11,6%.

Dopiero później pojawiają się systemy, które rzeczywiście można powiązać z AI.

Agenci AI i infrastruktura agentowa odpowiadały za 2302 żądania, czyli 10,5% ruchu. Crawlery zbierające dane do trenowania modeli wygenerowały 1179 żądań, czyli 5,3%. Asystenci przeglądający internet w imieniu użytkownika odpowiadali za 559 żądań — 2,5%.

Najbardziej interesująca z punktu widzenia GEO kategoria, czyli boty pobierające strony w celu udzielenia aktualnej odpowiedzi użytkownikowi, była na samym końcu. OAI-SearchBot, PerplexityBot i podobne crawlery retrieval wygenerowały łącznie zaledwie 233 żądania, około 1,1% całego analizowanego ruchu do llms.txt.

Dla porównania sam Slackbot, pobierający strony między innymi po to, aby wygenerować podgląd linku w komunikatorze, zaglądał do llms.txt częściej niż PerplexityBot.

Jest jeszcze jeden haczyk. Żądanie HTTP nie oznacza wykorzystania zawartości pliku. Bot może pobrać dokument i nic z nim później nie zrobić. Dlatego nawet udział 19,5% wszystkich żądań przypisanych łącznie różnym kategoriom botów AI należy traktować jako maksymalny możliwy poziom technicznego zainteresowania, a nie dowód, że treść pliku wpłynęła na odpowiedź modelu.

Dlaczego boty nie szukały llms.txt i skąd wzięła się różnica między obietnicą a praktyką

Najbardziej wymowny wynik badania nie dotyczy plików istniejących, lecz tych, których nie było.

Ahrefs przeanalizował również żądania kierowane na /llms.txt, które kończyły się kodem 404. Ani jedno takie zapytanie nie pochodziło od zidentyfikowanego bota AI. Innymi słowy, systemy AI nie chodziły od domeny do domeny i nie sprawdzały automatycznie, czy pod standardowym adresem znajduje się plik.

To zmienia sposób myślenia o jego roli.

robots.txt działa dlatego, że crawlery wiedzą, że powinny go sprawdzić. sitemap.xml ma długoletnią obsługę przez wyszukiwarki i może być zgłoszony bezpośrednio. llms.txt nie dostał jeszcze podobnego mechanizmu powszechnej autodetekcji.

W praktyce bot najczęściej musi wcześniej dowiedzieć się o pliku z linku, dokumentacji, katalogu, konfiguracji narzędzia albo instrukcji użytkownika. Sam fakt umieszczenia /llms.txt na serwerze nie powoduje, że witryna trafia na radar ChatGPT czy Perplexity.

W czerwcu 2026 roku sytuację dodatkowo skomplikował Google. Z jednej strony dokumentacja Google Search jasno wskazuje, że llms.txt nie jest potrzebny do uzyskania widoczności ani w klasycznych wynikach, ani w funkcjach generatywnych Google. 15 czerwca Google doprecyzował nawet, że obecność pliku nie daje pozytywnego ani negatywnego wpływu na ranking czy widoczność w Google Search.

Z drugiej strony Chrome umieścił kontrolę llms.txt w eksperymentalnych audytach Lighthouse Agentic Browsing. Nie oznacza to jednak, że Google Search zaczął korzystać z pliku. W Lighthouse brak pliku kończący się zwykłym 404 jest oznaczany jako „nie dotyczy”, ponieważ plik pozostaje opcjonalny. Problemem jest raczej błąd serwera podczas próby jego pobrania.

Dane Ahrefs pokazują skalę zainteresowania ze strony samego Lighthouse: 22 żądania w całym badanym zbiorze, czyli mniej więcej jedno na tysiąc wszystkich requestów do llms.txt.

Nie ma tu więc realnej sprzeczności. Google Search mówi: nie potrzebujemy llms.txt do wyszukiwania. Chrome mówi: plik może być wygodny dla agentów próbujących zorientować się w strukturze strony. To dwa inne zastosowania.

Co ciekawe, właśnie agenci, a nie wyszukiwarki generatywne, okazali się najbardziej sensownym odbiorcą standardu. Claude Code znalazł się wysoko wśród narzędzi pobierających plik, a infrastruktura agentowa odpowiadała łącznie za 10,5% wszystkich zarejestrowanych żądań.

To pasuje do technicznej logiki llms.txt. Jeśli agent ma przeanalizować dokumentację API mającą 300 podstron, krótki indeks prowadzący do najważniejszych instrukcji może oszczędzić czas, requesty oraz tokeny. Jeżeli ma natomiast znaleźć kancelarię prawną w Krakowie albo porównać sklepy sprzedające dany produkt, znacznie częściej korzysta z normalnie zaindeksowanych stron, danych wyszukiwarki, wyników lokalnych i treści HTML.

Jest też mniej przyjemna strona rozwiązania. Publiczny llms.txt może stać się gotową mapą najważniejszych zasobów dla scraperów i konkurencji. Ahrefs zauważył również ruch związany z badaniem możliwości prompt injection. Jeżeli plik zacznie zawierać instrukcje dla agentów zamiast prostego opisu i linków, ryzyko rośnie. Dlatego plik powinien być traktowany jak element konfiguracji: kontrolowany, wersjonowany i pozbawiony informacji, których nie chcielibyśmy publicznie wystawiać.

Czy llms.txt nadal ma sens w GEO? Tak, ale dopiero jako zadanie drugiego albo trzeciego priorytetu

Nie traktowałbym llms.txt jako techniki zwiększającej widoczność w odpowiedziach AI. W sierpniu 2026 roku nie ma danych pozwalających przypisać samemu plikowi wzrost cytowań, ruchu z ChatGPT, widoczności w Perplexity czy obecności w Google AI Overviews.

Ma natomiast sens w kilku konkretnych sytuacjach.

Pierwsza to dokumentacja techniczna, API, SDK, biblioteki, SaaS i produkty używane przez programistów. Jeżeli użytkownik może poprosić Claude Code albo innego agenta o napisanie integracji z produktem, uporządkowana mapa dokumentacji jest logicznym ułatwieniem.

Druga to serwisy, w których agent ma wykonywać zadania, a nie tylko wyszukiwać informacje. Przykładem może być rozbudowany system rezerwacyjny, panel usługowy albo platforma z dobrze opisanym API.

Trzecia sytuacja jest czysto ekonomiczna: CMS generuje plik automatycznie, a jego utrzymywanie prawie nic nie kosztuje. Wix robi to automatycznie, a generatory dostępne są również w popularnych narzędziach dla WordPressa. Jeśli wdrożenie wymaga kilku minut i później aktualizuje się bez ręcznej pracy, można potraktować plik jako tanią polisę na rozwój agentowego internetu.

Nie powinien natomiast trafiać wysoko na liście zadań typowej polskiej firmy usługowej, sklepu internetowego czy portalu contentowego.

Jeżeli budżet i czas są ograniczone, kolejność jest inna:

1. Sprawdź dostęp crawlerów. Dla widoczności w ChatGPT ważniejsze jest, czy OAI-SearchBot może pobierać treści. Dla funkcji AI Google podstawą pozostaje możliwość crawlowania przez Googlebot. Blokada w robots.txt, firewallu, Cloudflare albo innym WAF-ie może przekreślić dalszą optymalizację.

2. Sprawdź indeksowalność najważniejszych adresów. Kanoniczne URL-e, noindex, przekierowania, błędy 4xx i 5xx oraz błędne canonicale mają większe znaczenie niż brak llms.txt.

3. Daj botom treść w HTML, a nie wyłącznie w JavaScript. Najważniejsze informacje o produkcie, firmie, cenie, lokalizacji, warunkach i kompetencjach powinny być dostępne jako normalny tekst.

4. Napraw linkowanie wewnętrzne. Osierocona podstrona, do której nie prowadzi żaden logiczny link, jest znacznie większym problemem GEO niż brak pliku tekstowego w katalogu głównym.

5. Utrzymuj zgodne dane strukturalne. Schema.org nie jest magicznym znacznikiem dla AI, ale pomaga porządkować informacje. Dane strukturalne muszą odpowiadać temu, co użytkownik faktycznie widzi na stronie.

6. Dostarczaj informacje, które da się zacytować. Konkretne liczby, własne badania, tabele porównawcze, zasady, terminy, ceny, ograniczenia i jednoznaczne odpowiedzi są dla systemów generatywnych bardziej użyteczne niż kolejny tekst napisany pod szeroką frazę.

7. Dopiero wtedy wdrażaj llms.txt, jeżeli masz konkretny scenariusz agentowy albo koszt jego utrzymania jest pomijalny.

Jeżeli decyzja padnie na wdrożenie, nie kopiowałbym bezmyślnie starego generatora. 10 sierpnia 2026 roku specyfikacja została zaktualizowana do wersji v2, czyli już po okresie analizowanym w badaniu Ahrefs.

Aktualna propozycja pozwala między innymi umieszczać llms.txt nie tylko w katalogu głównym, lecz również w określonej ścieżce, na przykład /docs/llms.txt. Plik znajdujący się głębiej ma opisywać zasoby pod daną ścieżką. To rozsądne rozwiązanie dla serwisów, w których agentom faktycznie przydaje się dokumentacja, podczas gdy reszta strony nie wymaga osobnego indeksu.

Minimalna struktura jest prosta:

• nagłówek H1 z nazwą projektu lub witryny — to jedyny wymagany element;

• krótkie podsumowanie w cytacie;

• ewentualne dodatkowe objaśnienie;

• sekcje H2 zawierające listy najważniejszych zasobów;

• dla każdego linku krótki opis tego, co agent znajdzie pod wskazanym adresem;

• opcjonalna sekcja Optional z materiałami, które można pominąć przy ograniczonym kontekście.

W wersji v2 pojawiło się też bardziej praktyczne podejście do wykrywania pliku: możliwość wskazywania go przez rel="describedby" oraz oznaczania wersji Markdown stron przez rel="alternate" type="text/markdown". To próba rozwiązania jednego z problemów ujawnionych przez Ahrefs — agent musi najpierw dowiedzieć się, że plik istnieje.

Nie zmienia to jednak głównej decyzji biznesowej. Badanie z maja sprawdzało starszy etap rozwoju standardu, więc nie jest testem obecnej wersji v2. Jednocześnie żadna zmiana specyfikacji nie stworzyła automatycznie powszechnej obsługi llms.txt przez wyszukiwarki AI. Nowy format poprawia techniczne warunki użycia. Nie stanowi dowodu wzrostu widoczności.

Po wdrożeniu trzeba więc patrzeć w logi, a nie w zielony znacznik generatora.

Filtruj żądania do /llms.txt i sprawdzaj:

• liczbę requestów;

• kody odpowiedzi;

• user-agenty;

• źródłowe adresy IP, jeśli można je zweryfikować z zakresami publikowanymi przez operatora;

• czy po pobraniu pliku bot przechodzi na adresy wymienione wewnątrz;

• czy ruch pochodzi od faktycznych agentów, czy tylko od skanerów SEO i generatorów llms.txt.

Sam user-agent nie wystarczy. Można go podszyć w kilka sekund.

Jeżeli po 30–60 dniach plik nie ma wartościowego ruchu, nie inwestowałbym kolejnych godzin w ręczne rozbudowywanie go. Automatycznie utrzymywany plik może zostać. Ręcznie pielęgnowany katalog, którego nikt nie pobiera, jest kosztem bez mierzalnego zwrotu.

FAQ

Czy llms.txt poprawia pozycję strony w Google lub AI Overviews?
Nie. Google wyraźnie wskazuje, że plik nie jest wykorzystywany jako specjalny sygnał Google Search i nie daje pozytywnego ani negatywnego wpływu na ranking czy widoczność w funkcjach generatywnych.

Czy brak llms.txt może zaszkodzić widoczności w ChatGPT?
Nie ma podstaw, aby tak twierdzić. W badaniu Ahrefs boty AI nie wykonywały nawet automatycznych prób pobrania /llms.txt z witryn, które tego pliku nie posiadały. W przypadku ChatGPT znacznie ważniejsze jest między innymi to, czy witryna pozwala na dostęp OAI-SearchBot.

Czy 97% oznacza, że 97% wszystkich analizowanych stron nie dostało żądania?
Nie. 97% odnosi się do około 38 tys. domen, które posiadały llms.txt. Całe badanie obejmowało 137 210 domen. Około 28% z nich miało plik.

Czy Ahrefs sprawdził, czy bot wykorzystał informacje z llms.txt?
Nie. Badanie mierzyło żądania HTTP. Pobranie pliku nie jest dowodem, że model przeczytał jego treść, użył linków albo uwzględnił informacje w odpowiedzi.

Dla jakich stron llms.txt ma obecnie najwięcej sensu?
Przede wszystkim dla dokumentacji technicznej, API, SDK, produktów SaaS i serwisów intensywnie używanych przez agentów. Dane Ahrefs wskazały wyraźnie większe zainteresowanie ze strony agentów i narzędzi programistycznych niż botów odpowiadających za bieżące wyszukiwanie AI.

Czy warto wdrażać llms.txt na stronie lokalnej firmy usługowej?
Nie jako pierwsze działanie GEO. Najpierw trzeba sprawdzić crawlowanie, indeksację, treści usługowe, dane firmy, linkowanie wewnętrzne, Google Business Profile i techniczną dostępność strony. llms.txt można dodać później, szczególnie jeśli CMS generuje go automatycznie.

Czy llms.txt zastępuje robots.txt albo sitemap.xml?
Nie. robots.txt określa zasady dostępu crawlerów, a sitemap.xml pomaga wskazywać adresy witryny wyszukiwarkom. llms.txt jest kuratorowanym opisem i mapą zasobów przeznaczoną przede wszystkim dla modeli oraz agentów.

Czy w pliku warto umieścić wszystkie adresy witryny?
Nie. To jeden z częstszych błędów. llms.txt nie powinien być drugim sitemap.xml. Lepiej wskazać najważniejsze dokumenty i opisać, co znajduje się pod każdym z nich. Agent ma szybciej dotrzeć do właściwego źródła, a nie przetwarzać listę kilku tysięcy URL-i.

Co sprawdzić jako pierwsze przed stworzeniem llms.txt?
Logi serwera. Jeśli celem jest GEO, najpierw sprawdź, czy OAI-SearchBot, Googlebot oraz interesujące Cię boty AI w ogóle mogą pobierać najważniejsze podstrony i czy nie blokuje ich robots.txt, CDN albo WAF. Następnie usuń problemy z indeksacją i linkowaniem wewnętrznym. Dopiero po tych pracach ma sens poświęcanie czasu na llms.txt. To właśnie błędna kolejność priorytetów jest dziś większym problemem niż brak samego pliku.

Więcej na ten temat na stronie: https://toniemarketing.pl