Google wypuścił Lighthouse 13.5, a wraz z nim nowy audyt w kategorii Agentic Browsing: Agentic Resource Discovery (ARD). Narzędzie sprawdza teraz, czy witryna publikuje katalog zasobów, które agenci AI mogą odnaleźć i wywołać, czyli serwery MCP, agentów A2A i inne usługi. Wydanie trafiło na GitHub 18 września, a jak podaje serwis Search Engine Journal, w ciągu dwóch tygodni audyt ma pojawić się także w PageSpeed Insights.
To trzeci krok Google w tę samą stronę w ciągu czterech miesięcy. W maju Lighthouse 13.3 zaczął sprawdzać obecność pliku llms.txt, w sierpniu doszły kontrole pokrycia formularzy przez WebMCP, a teraz zespół Lighthouse dokłada warstwę, która odpowiada nie na pytanie „co agent może przeczytać”, tylko „co agent może uruchomić”.
Kontekst: kategoria Agentic Browsing rośnie po cichu
Kategoria Agentic Browsing pojawiła się w Lighthouse wiosną 2026 roku jako eksperyment. Zamiast wyniku 0–100 pokazuje współczynnik zaliczonych kontroli, bo, jak tłumaczył wtedy zespół Chrome, standardy agentowego internetu dopiero się kształtują. Pierwsza wersja sprawdzała cztery rzeczy: plik llms.txt, obsługę WebMCP, jakość drzewa dostępności oraz Cumulative Layout Shift, który dla agenta wykonującego zakup lub wypełniającego formularz oznacza ryzyko kliknięcia w niewłaściwy element.
Opisywaliśmy wtedy, jak Lighthouse 13.3 zaczął sprawdzać llms.txt i dlaczego rozdwaja to przekaz Google wobec wydawców: Search Central konsekwentnie mówi, że llms.txt nie wpływa na wyszukiwarkę, a narzędzie tego samego koncernu wystawia za jego brak czerwoną ikonę. Z ARD historia się powtarza, tylko stawka jest wyższa, bo dotyczy nie treści, a usług.
Sama specyfikacja ARD nie jest nowa. Google ogłosił ją na blogu deweloperskim 17 czerwca 2026 roku jako otwarty standard na licencji Apache 2.0, opracowany wspólnie z partnerami. Za dokumentem stoją Junjie Bu z Google, R.V. Guha z Microsoftu oraz Shaun Smith z Hugging Face. Model danych bazuje na AI Catalog, projekcie grupy roboczej Linux Foundation. W czerwcu specyfikacja miała numer 0.9, a 26 sierpnia doczekała się wersji 0.91, która zmieniła domyślną nazwę pliku manifestu. Ten szczegół ma znaczenie, do czego wrócimy.
Co dokładnie sprawdza nowy audyt
Audyt ARD w Lighthouse 13.5 szuka wskaźnika do katalogu w ustalonej kolejności. Jeśli witryna nie publikuje żadnego wskaźnika, narzędzie sięga po ścieżkę domyślną. Poniżej pełna sekwencja, którą przechodzi kod audytu.
| Krok | Gdzie Lighthouse szuka | Czego oczekuje |
|---|---|---|
| 1 | Plik robots.txt | Dyrektywa Agentmap wskazująca adres katalogu, na wzór dyrektywy Sitemap |
| 2 | Sekcja head strony | Znacznik link z relacją ai-catalog |
| 3 | Nagłówki HTTP odpowiedzi | Nagłówek Link z relacją ai-catalog |
| 4 | Ścieżka domyślna | Plik /.well-known/ai-catalog.json |
Gdy katalog zostanie znaleziony, Lighthouse porównuje go ze schematem zdefiniowanym przez projekt ARD i zwraca wynik zaliczony lub niezaliczony. Jeśli katalogu nie ma nigdzie, audyt kończy się statusem Not Applicable, a nie błędem. To istotne dla wydawców, którzy nie planują publikować żadnych usług dla agentów: brak katalogu nie obniży współczynnika w kategorii Agentic Browsing.
Z opisu wydania na GitHubie wynika też kilka zmian towarzyszących. Audyty ARD i llms.txt zostały zgrupowane pod wspólnym nagłówkiem „agent discovery”, fetcher Lighthouse nauczył się przechwytywać nagłówki odpowiedzi (co jest potrzebne do kroku trzeciego z tabeli), a kontrola WebMCP zwraca teraz status zaliczony zamiast Not Applicable, gdy wszystkie formularze na stronie mają pokrycie narzędziami. Do tego doszło ostrzeżenie, gdy strona rejestruje więcej narzędzi WebMCP, niż zaleca specyfikacja.
Problem z nazwą pliku
Tu pojawia się pierwsza rysa. Jak zauważa Search Engine Journal, specyfikacja ARD w wersji 0.91 z 26 sierpnia przeniosła manifest do pliku /.well-known/ard.json i zmieniła relację linku na ard. Stara nazwa ai-catalog.json pozostała w dokumencie jako opcjonalna, ale to ard.json jest teraz kanoniczne. Kod Lighthouse 13.5, przeglądany 21 września, wciąż sprawdza wyłącznie starą ścieżkę i starą relację.
W praktyce oznacza to, że witryna wdrożona ściśle według aktualnej specyfikacji, z plikiem ard.json i znacznikiem link rel=”ard”, dostanie w Lighthouse status Not Applicable, tak jakby nie miała żadnego katalogu. Z kolei witryna, która trzyma się nazewnictwa z czerwca, przejdzie audyt bez uwag. Do czasu aktualizacji kodu wynik Lighthouse mówi więc o zgodności z wersją 0.9, nie z bieżącym standardem.
Jak wygląda katalog w praktyce
Katalog ARD to pojedynczy dokument JSON, który organizacja hostuje na własnej domenie. Analogia do pliku security.txt jest zamierzona: jedno stałe, przewidywalne miejsce, w którym agent zawsze może sprawdzić, czy domena coś udostępnia. Wewnątrz znajdują się wpisy opisujące poszczególne zasoby: typ (serwer MCP, agent A2A, narzędzie OpenAPI, skill), adres końcówki, krótki opis przeznaczenia oraz odwołanie do metadanych zaufania. Katalog może też wskazywać na inne katalogi, co pozwala dużym organizacjom rozbić listę usług na działy lub marki bez utraty jednego punktu wejścia.
Dyrektywa Agentmap w robots.txt działa dokładnie jak Sitemap: jedna linia z pełnym adresem katalogu, którą crawler agentowy odczytuje przy pierwszym kontakcie z domeną. Znacznik link w sekcji head i nagłówek HTTP Link pełnią tę samą funkcję dla agentów, które trafiają na konkretną stronę bezpośrednio, z pominięciem robots.txt. Rekord DNS typu Service Binding, czwarta droga w specyfikacji, pozwala z kolei odnaleźć katalog bez pobierania czegokolwiek z serwera WWW, ale tej metody Lighthouse na razie nie testuje.
Dla zespołów, które utrzymują już plik llms.txt, dobra wiadomość jest taka, że oba dokumenty się nie wykluczają i nie dublują. llms.txt pozostaje mapą treści, katalog ARD jest mapą usług. Witryna contentowa z jednym narzędziem online, na przykład kalkulatorem lub API do sprawdzania danych, może opisać treść w pierwszym pliku, a narzędzie w drugim.
ARD, llms.txt i WebMCP: trzy warstwy, trzy różne pytania
Najczęstsze nieporozumienie po premierze dotyczy tego, czym ARD różni się od llms.txt, który omawialiśmy przy okazji wersji 2.0 standardu llms.txt. Rozdzielenie tych pojęć ułatwia zrozumienie, co Google właściwie mierzy.
| Mechanizm | Na jakie pytanie odpowiada | Kiedy agent z niego korzysta | Od kiedy w Lighthouse |
|---|---|---|---|
| llms.txt | Co ta witryna zawiera i które strony warto przeczytać | Przed wejściem, na etapie rozpoznania treści | Maj 2026 (13.3) |
| WebMCP | Jakie akcje można wykonać na tej stronie w przeglądarce | Po wejściu, gdy agent działa w sesji użytkownika | Sierpień 2026 |
| ARD | Jakie usługi ta organizacja udostępnia do wywołania | Przed połączeniem, na etapie wyszukiwania narzędzi | Wrzesień 2026 (13.5) |
Katalog ARD nie opisuje treści. Opisuje serwery MCP, agentów zgodnych z protokołem A2A, narzędzia udostępnione przez OpenAPI, tak zwane skills oraz zagnieżdżone katalogi innych domen. Specyfikacja przewiduje cztery drogi odkrycia takiego katalogu: ścieżkę well-known, dyrektywę Agentmap w robots.txt, znacznik link w nagłówku dokumentu oraz rekord DNS typu Service Binding. Lighthouse sprawdza trzy pierwsze plus nagłówek HTTP, nie sprawdza DNS.
Dochodzi do tego warstwa zaufania. Wydawca dołącza do katalogu metadane kryptograficzne, dzięki którym klient może potwierdzić tożsamość publikującego przed nawiązaniem połączenia. W założeniu ma to ograniczyć podszywanie się pod cudze usługi, czyli problem, który w ekosystemie MCP już się pojawił. Lighthouse na razie sprawdza tylko zgodność ze schematem, nie weryfikuje podpisów.
Co to znaczy dla SEO i AIO
Dla typowego serwisu contentowego, bloga czy sklepu bez własnego API odpowiedź jest krótka: dziś nic. Audyt zwraca Not Applicable i nie wpływa na współczynnik kategorii. Nie ma też żadnej deklaracji ze strony Google Search, że katalog ARD jest sygnałem rankingowym, a ten sam dystans Google zachował wobec llms.txt, o czym pisaliśmy przy okazji checklisty wdrożenia strony pod AI search.
Inaczej wygląda to w trzech grupach wydawców.
- Firmy SaaS i platformy z API. Jeśli produkt ma już serwer MCP albo endpoint OpenAPI, katalog ARD to kilkadziesiąt linii JSON, które sprawiają, że rejestry agentów (Google uruchomił własny w ramach Gemini Enterprise Agent Platform) będą w stanie zaindeksować usługę. To odpowiednik zgłoszenia sitemapy dla narzędzi.
- Sklepy e-commerce. Ekosystem agentowego handlu, od protokołu zakupów w ChatGPT po Universal Commerce Protocol Google, opiera się na tym, że agent musi najpierw znaleźć usługę, a dopiero potem z niej skorzystać. ARD standaryzuje pierwszy z tych kroków.
- Agencje i konsultanci techniczni. Audyt trafi do PageSpeed Insights, czyli narzędzia, którym klienci sprawdzają strony samodzielnie. Pytania o „czerwony wynik w sekcji agentów” pojawią się w skrzynkach agencji w ciągu tygodni, niezależnie od tego, czy wynik ma znaczenie biznesowe.
Jest jeszcze jeden wątek, którego wielu wydawców nie łączy z ARD: kontrola crawlerów. Katalog publikowany w robots.txt i ścieżce well-known to zaproszenie dla agentów, a ci nie zawsze przedstawiają się tak, jak Googlebot. Jeśli witryna blokuje boty AI na poziomie CDN lub reguł user-agent, wdrożenie katalogu bez przeglądu tych reguł da efekt odwrotny do zamierzonego. Listę agentów, które warto rozpoznawać w logach, zebraliśmy w tekście o botach AI i ich user-agentach.
Reakcje branży
Pierwsze komentarze specjalistów od wydajności i dostępności są powściągliwe, ale nie odrzucające. Zespoły narzędzi monitorujących Core Web Vitals, które opisywały kategorię Agentic Browsing już wiosną, podkreślają, że Lighthouse robi to, co zawsze: koduje wschodzący standard w formie kontroli, zanim rynek zdąży go przyjąć, i przez to sam napędza adopcję. Tak było z HTTPS, z lazy loadingiem obrazów i z metrykami CWV.
Krytyka skupia się na dwóch punktach. Pierwszy to opisany wyżej rozjazd między kodem audytu a wersją 0.91 specyfikacji. Wydawcy, którzy śledzą dokument źródłowy, mogą zostać ukarani za bycie na bieżąco, a to podważa sens audytu jako narzędzia weryfikacji zgodności. Drugi punkt to ponownie dwugłos Google: Search Central milczy o ARD w kontekście wyszukiwarki, a Lighthouse, PageSpeed Insights i wkrótce DevTools w Chrome 156 będą je promować na każdym raporcie. Search Engine Journal ujmuje to jednym zdaniem: wytyczne Google Search i kontrole agentowe Lighthouse patrzą na różne rzeczy.
Ze strony społeczności MCP i A2A sygnał jest wyraźnie pozytywny. Dla twórców serwerów narzędziowych ARD rozwiązuje realny problem: dotąd nie było standardowego sposobu, żeby agent wiedział, że dana domena udostępnia MCP, poza ręcznym wpisem w konfiguracji klienta. Rejestry działające jak wyszukiwarki dla narzędzi, które przeszukują katalogi i zwracają wyniki wraz z metadanymi zaufania, są brakującym elementem tej układanki.
Co dalej
Kalendarz na najbliższe tygodnie jest w miarę przewidywalny. Lighthouse 13.5 jest już dostępny jako pakiet npm i w wersji CLI. Wersja wbudowana w DevTools ma pojawić się w Chrome 156, a PageSpeed Insights ma dostać ją w ciągu dwóch tygodni od wydania, czyli na początku października. Wtedy audyt ARD stanie się widoczny dla masowego odbiorcy.
Otwartą kwestią pozostaje aktualizacja kodu pod wersję 0.91 specyfikacji, czyli obsługa pliku ard.json i relacji ard. Biorąc pod uwagę tempo wydań (13.4.1 i 13.5.0 dzieliło kilka tygodni), łatka jest prawdopodobna w wersji 13.5.x lub 13.6. Do tego czasu bezpieczną praktyką dla wdrażających jest publikowanie obu nazw pliku, co specyfikacja wprost dopuszcza.
Dalej w kolejce jest weryfikacja kryptograficzna. Obecny audyt sprawdza wyłącznie zgodność JSON ze schematem. Jeśli Lighthouse zacznie walidować manifest zaufania, kategoria Agentic Browsing przestanie być listą obecności plików, a stanie się testem, czy witryna jest wiarygodnym dostawcą usług dla agentów. To zmieniłoby rozmowę z klientami z „czy mamy plik” na „czy ktoś może się pod nas podszyć”.
Co zrobić w tym tygodniu
- Uruchomić Lighthouse 13.5 z linii poleceń na stronie głównej i sprawdzić, jaki status zwraca audyt ARD. Not Applicable jest wynikiem poprawnym dla witryn bez usług dla agentów.
- Jeśli firma ma serwer MCP lub publiczne API, przygotować katalog według wersji 0.91 i opublikować go pod obiema nazwami: ard.json oraz ai-catalog.json.
- Dodać dyrektywę Agentmap do robots.txt tylko wtedy, gdy katalog już istnieje. Wskaźnik prowadzący do pustego adresu spowoduje niezaliczenie audytu, a nie status Not Applicable.
- Przejrzeć reguły blokujące boty AI, zanim katalog trafi na produkcję.
- Przygotować krótką notatkę dla klientów lub zarządu: audyt nie jest sygnałem rankingowym Google Search i nie wymaga działania na stronach contentowych.
FAQ
Czy brak katalogu ARD obniży wynik mojej strony w Lighthouse?
Nie. Gdy Lighthouse nie znajdzie żadnego wskaźnika ani pliku pod ścieżką domyślną, audyt zwraca status Not Applicable, który nie jest liczony jako niezaliczony. Wynik obniży dopiero katalog, który istnieje, ale nie zgadza się ze schematem, albo dyrektywa Agentmap prowadząca do nieistniejącego adresu.
Czy ARD ma wpływ na pozycje w Google?
Google Search nie ogłosił, że katalog ARD jest brany pod uwagę przy rankingu, podobnie jak wcześniej odciął się od llms.txt. Audyt dotyczy widoczności usług dla agentów AI i rejestrów narzędzi, nie widoczności stron w wynikach wyszukiwania.
Mam plik ard.json zgodny z najnowszą specyfikacją. Dlaczego Lighthouse pokazuje Not Applicable?
Kod Lighthouse 13.5 sprawdza wyłącznie starszą ścieżkę /.well-known/ai-catalog.json oraz relację linku ai-catalog. Wersja 0.91 specyfikacji z 26 sierpnia przeniosła manifest do ard.json, ale audyt jeszcze tego nie obsługuje. Rozwiązaniem przejściowym jest opublikowanie katalogu pod obiema nazwami.
Czym różni się ARD od llms.txt i WebMCP?
llms.txt opisuje treść witryny i wskazuje, które strony warto przeczytać. WebMCP udostępnia akcje na konkretnej stronie, z których agent korzysta już po wejściu na nią. ARD opisuje usługi organizacji, takie jak serwery MCP, agenci A2A czy narzędzia OpenAPI, i służy do ich odnalezienia przed nawiązaniem połączenia.
Kiedy audyt pojawi się w PageSpeed Insights?
Zespół Lighthouse zapowiada, że w ciągu dwóch tygodni od wydania wersji 13.5, które miało miejsce 18 września 2026 roku. W przeglądarce audyt ma trafić do DevTools w Chrome 156.