Google Lighthouse 13.5 sprawdza, czy agenci AI znajdą Twoje zasoby. Nowy audyt Agentic Resource Discovery szuka katalogu pod nieaktualną ścieżką

Google wypuścił Lighthouse 13.5 i dołożył do niego audyt, którego jeszcze rok temu nikt by nie zrozumiał: sprawdzenie, czy agent AI potrafi znaleźć na stronie katalog udostępnionych mu zasobów. Nowa kontrola nazywa się Agentic Resource Discovery (ARD) i ląduje w kategorii Agentic Browsing, obok istniejącego już testu pliku llms.txt. Jak podaje serwis Search Engine Journal, audyt jest już dostępny w DevTools Chrome 156, a w PageSpeed Insights ma pojawić się w ciągu dwóch tygodni od premiery.

Dla właścicieli stron to sygnał, że Google przestaje traktować „widoczność dla agentów” jako ciekawostkę z konferencji, a zaczyna ją mierzyć w tym samym narzędziu, którym od lat sprawdza się wydajność, dostępność i SEO. Jednocześnie pierwsze wdrożenie ma wyraźną rysę: Lighthouse szuka katalogu pod adresem, który sama specyfikacja ARD zdążyła już zmienić.

Kontekst: Lighthouse od maja mierzy gotowość na agentów

Kategoria Agentic Browsing pojawiła się w Lighthouse 13.3 w drugim tygodniu maja 2026 roku. Google nie zrobił z niej wielkiej premiery. Nowa sekcja trafiła do narzędzia z adnotacją, że jest eksperymentalna, i zamiast klasycznego wyniku 0–100 pokazuje proporcję zaliczonych testów. Zespół Lighthouse tłumaczył wtedy, że „standardy agentowej sieci wciąż się kształtują”, więc przypisywanie stronie punktacji byłoby przedwczesne.

Do wersji 13.5 kategoria składała się z czterech kontroli. Pierwsza sprawdza, czy drzewo dostępności strony jest poprawnie zbudowane, bo agenci częściej czytają właśnie je niż pełny HTML czy zrzuty ekranu. Druga weryfikuje formularze pod kątem WebMCP, czyli protokołu, który pozwala stronie wystawić agentowi konkretne akcje zamiast zmuszać go do klikania po interfejsie. Trzecia ocenia plik llms.txt: czy istnieje, czy ma nagłówek H1, czy nie jest za długi i czy zawiera linki. Czwarta przenosi do nowej kategorii znany od 2020 roku wskaźnik Cumulative Layout Shift, z uzasadnieniem, że „agenci robiący zrzuty ekranu będą zdezorientowani, jeśli układ strony ciągle się przesuwa”.

Agentic Resource Discovery to piąty element tego zestawu i pierwszy, który dotyczy nie tego, jak agent czyta stronę, ale tego, jak dowiaduje się, co strona mu oferuje. O samym WebMCP i jego wejściu do przeglądarki ChatGPT pisaliśmy w sierpniu w tekście o agentach wpuszczanych na strony przez OpenAI. Lighthouse zamyka teraz pętlę od strony Google.

Czym jest specyfikacja ARD

Agentic Resource Discovery to otwarta specyfikacja opublikowana na licencji Apache 2.0, którą Google ogłosił 17 czerwca 2026 roku na blogu Google for Developers. Autorami wpisu byli Junjie Bu i Srinivas Krishnan, inżynierowie Google, a sam dokument rozwija model danych wypracowany w grupie roboczej AI Catalog przy Linux Foundation. Wśród współtwórców wymienia się poza Google także Microsoft, Hugging Face i GoDaddy.

Specyfikacja odpowiada na trzy pytania, które agent musi zadać, zanim skorzysta z cudzej usługi: gdzie są dostępne możliwości, którą z nich wybrać i czy można jej bezpiecznie zaufać. Rozwiązanie opiera się na czterech elementach:

• Katalog: plik JSON hostowany na domenie organizacji, który opisuje jej zasoby dla agentów. Mogą to być serwery MCP, agenci A2A, narzędzia OpenAPI albo zagnieżdżone katalogi innych działów firmy.
• Rejestry: usługi działające jak wyszukiwarki katalogów, które je crawlują, indeksują i pozwalają agentom wyszukiwać możliwości między organizacjami.
• Weryfikacja kryptograficzna: metadane zaufania dołączone do zasobów, dzięki którym agent potwierdza tożsamość wydawcy, zanim się połączy.
• Bezpośrednie połączenie w czasie działania: agent ładuje znaleziony zasób i komunikuje się z nim jego natywnym protokołem, bez pośredników.

W praktyce dla właściciela strony ARD sprowadza się do jednego pliku i jednego wskaźnika: opublikować katalog pod ustalonym adresem i powiedzieć agentom, gdzie go szukać. Właśnie ten drugi krok sprawdza teraz Lighthouse.

Co konkretnie sprawdza nowy audyt

Według opisu w kodzie źródłowym Lighthouse 13.5, audyt Agentic Resource Discovery szuka na stronie trzech metod wskazania katalogu. Wystarczy jedna, żeby test przeszedł do etapu walidacji.

Jeśli Lighthouse nie znajdzie żadnego z trzech wskaźników, sięga po domyślną ścieżkę /.well-known/ai-catalog.json. Gdy pod którymkolwiek z adresów jest plik, audyt sprawdza jeszcze, czy jego zawartość jest zgodna ze schematem specyfikacji. Wyniki trafiają do wspólnej grupy „Agent Discoverability”, w której od maja siedzi już kontrola llms.txt. Obie odpowiadają na to samo pytanie z dwóch stron: llms.txt mówi modelowi, o czym jest strona, a katalog ARD mówi agentowi, co może na niej zrobić.

Warto podkreślić, czego audyt nie robi. Nie ocenia, czy katalog jest sensowny, czy wystawione serwery MCP działają, ani czy ktokolwiek z nich korzysta. To kontrola obecności i poprawności składniowej, dokładnie tak jak test llms.txt nie mówi nic o tym, czy jakikolwiek model ten plik czyta. Co ciekawe, Google sam przyznał w lipcu, że llms.txt nie ma wpływu na wyszukiwarkę, a mimo to Lighthouse nadal go audytuje. Ta sama logika obowiązuje przy ARD: narzędzie sprawdza gotowość infrastruktury, nie efekt.

Rysa na starcie: Lighthouse szuka pliku pod starą nazwą

Najciekawszy szczegół tej premiery to rozjazd między narzędziem a specyfikacją, którą ma sprawdzać. Wersja 0.91 specyfikacji ARD zmieniła nazwę manifestu z ai-catalog.json na /.well-known/ard.json i zastąpiła relację ai-catalog relacją ard. Kod Lighthouse 13.5 tej zmiany jeszcze nie uwzględnia: szuka starej ścieżki i starej relacji.

Skutek jest przewrotny. Strona, która wdrożyła ARD zgodnie z najnowszą wersją dokumentu, może w Lighthouse zobaczyć status „Not Applicable”, bo audyt nie rozpozna wskaźnika rel=”ard” ani pliku ard.json. Z kolei strona, która trzymała się wcześniejszej wersji z ai-catalog.json, dostanie zielony znaczek, mimo że według aktualnej specyfikacji jej wdrożenie jest już przestarzałe. Search Engine Journal zwraca uwagę, że do czasu aktualizacji Lighthouse właściciele stron muszą albo utrzymywać obie ścieżki równolegle, albo pogodzić się z tym, że audyt ich nie zobaczy.

Dla praktyków to nic nowego. Kategoria Agentic Browsing od maja nosi etykietę „w budowie”, a sam zespół Lighthouse nie ukrywa, że dopasowuje testy do standardów, które zmieniają się co kilka tygodni. Ale to pierwszy przypadek, w którym rozjazd jest tak namacalny: dwa pliki, dwie nazwy relacji i narzędzie, które zna tylko starsze z nich.

Kluczowe fakty w skrócie

Co to znaczy dla SEO i AIO

Najprostsza odpowiedź: na dziś nic dla rankingu. Lighthouse nie jest sygnałem rankingowym i żaden z testów kategorii Agentic Browsing nie ma udokumentowanego związku z tym, jak Google ocenia stronę w wynikach wyszukiwania ani w AI Mode. Kto spodziewa się, że wgranie ai-catalog.json podniesie pozycje, powtórzy błąd z llms.txt sprzed roku.

Trudniejsza odpowiedź dotyczy tego, co Google właśnie zakomunikował całej branży. Umieszczenie ARD w narzędziu, z którego korzystają miliony deweloperów, oznacza, że katalogi zasobów dla agentów przestają być tematem dla twórców serwerów MCP, a stają się elementem checklisty technicznej strony. Za dwa tygodnie pojawi się w PageSpeed Insights, czyli w miejscu, gdzie klienci agencji sprawdzają „czy strona jest dobrze zrobiona”. Można się spodziewać, że pierwsze pytania o czerwone kropki w sekcji Agent Discoverability trafią do działów SEO jeszcze w tym kwartale.

Trzy praktyczne konsekwencje wydają się najważniejsze:

• Robots.txt dostaje nową dyrektywę do zarządzania. Agentmap dołącza do Sitemap i do rosnącej listy reguł dla botów AI. Kto porządkował plik pod kątem blokowania i wpuszczania crawlerów AI, musi teraz przewidzieć w nim także wskaźnik do katalogu.
• Katalog to dokument publiczny. Wszystko, co trafi do ai-catalog.json, jest widoczne dla każdego agenta i każdego rejestru. Firmy, które wystawiają wewnętrzne API przez MCP, powinny zdecydować, co chcą pokazać światu, zanim ktoś z zespołu wgra plik „żeby przeszedł audyt”.
• Audyty pod agentów zaczynają żyć własnym cyklem wersji. Test może dziś przejść, a za miesiąc, po aktualizacji Lighthouse do nowej ścieżki, zacząć wskazywać błąd. Monitoring wyników Lighthouse w czasie, a nie jednorazowy raport, staje się koniecznością.

Dla sklepów internetowych i serwisów usługowych ARD ma jeszcze jeden wymiar. Jeśli agent zakupowy, taki jak ten w przeglądarce ChatGPT czy w Google Universal Cart, będzie w przyszłości sięgał po katalogi, żeby dowiedzieć się, jak złożyć zamówienie bez klikania po interfejsie, to brak katalogu może oznaczać wypadnięcie z listy dostawców, których agent w ogóle bierze pod uwagę. To scenariusz, nie fakt, ale Lighthouse właśnie pokazał, w którą stronę Google chce go pchać.

Reakcje branży

Pierwsze komentarze koncentrują się na rozjeździe wersji. Wielu specjalistów odbiera go jako dowód, że Google wypuścił audyt szybciej, niż ustabilizowała się specyfikacja, którą sam współtworzył. Pojawia się też pytanie, po co w ogóle audytować standard, który ma numer wersji 0.91 i sam siebie nazywa szkicem.

Drugi wątek to porównanie z llms.txt. Test tego pliku trafił do Lighthouse w maju, a już w lipcu przedstawiciele Google publicznie mówili, że wyszukiwarka go nie używa. Nasz własny eksperyment z llms.txt i cytowaniami w ChatGPT pokazał podobnie skromne efekty. Część branży obawia się, że ARD podzieli ten los: narzędzie będzie pokazywać czerwone kropki, klienci będą żądać ich usunięcia, a żaden agent przez długi czas nie skorzysta z katalogu.

Głosy przychylne wskazują z kolei, że tym razem Google ma za sobą Linux Foundation, Microsoft i Hugging Face, a katalog ma jasno określony cel techniczny: powiedzieć agentowi, gdzie jest serwer MCP. To zupełnie inna sytuacja niż llms.txt, który był pomysłem jednej firmy z branży narzędzi AI i nigdy nie miał wsparcia żadnego z dużych dostawców modeli. Jeśli rejestry ARD faktycznie powstaną, katalog stanie się dla agentów tym, czym sitemapa dla Googlebota.

Co dalej

Najbliższe tygodnie przyniosą trzy rzeczy do obserwowania. Pierwsza to aktualizacja Lighthouse do ścieżki ard.json i relacji ard, bo obecny rozjazd jest zbyt widoczny, żeby zespół go zignorował. Druga to pojawienie się audytu w PageSpeed Insights i pierwsze raporty klientów z pytaniem, co oznacza sekcja Agent Discoverability. Trzecia to reakcja narzędzi SEO: crawlery i platformy audytowe będą musiały zdecydować, czy dodać własne sprawdzanie ARD, tak jak w tym roku masowo dodały sprawdzanie llms.txt.

W dłuższej perspektywie kluczowe będzie to, czy powstaną publiczne rejestry ARD i czy któryś z dużych agentów, od ChatGPT po Gemini, zacznie z nich korzystać. Bez tego katalog pozostanie plikiem, który przechodzi audyt i nikomu nie służy. Z tym może stać się nowym warstwowym punktem wejścia do agentowej sieci, a Lighthouse będzie pierwszym narzędziem, które to mierzyło.

Dla polskich stron rekomendacja na dziś jest prosta: sprawdzić stronę w Chrome 156 pod kątem nowej kategorii, zanotować wynik, ale nie wdrażać katalogu tylko po to, żeby zamienić szarą kropkę na zieloną. Wdrażać wtedy, gdy firma faktycznie ma serwer MCP, API albo agenta, którego chce udostępnić światu. Wtedy audyt Lighthouse przestaje być testem dla testu, a staje się kontrolą, czy ktoś tę usługę w ogóle znajdzie.

Najczęstsze pytania