PageSpeed Insights od lat ocenia Wydajność, Dostępność, Najlepsze praktyki i SEO. W 2026 roku do tego wiersza po cichu dołączyła piąta pozycja: Agentic Browsing. Odpowiada na jedno pytanie, które pozostałe cztery kategorie pomijają — czy agent AI naprawdę może pracować z tą stroną?
Ten przewodnik dotyczy wykorzystania tego testu na własnej stronie: uruchomienia go, odczytania, co faktycznie mówi każdy audyt, i wyjścia z listą poprawek.
Co zyskasz na końcu
Dla kogo: dla zespołów SEO, programistów i właścicieli stron, którzy chcą wiedzieć, jak zachowują się ich strony, gdy przegląda je agent, a nie człowiek.
Co będziesz mieć po zakończeniu: prawdziwy wynik Agentic Browsing dla swojej strony, odczyt test po teście tego, co przechodzi, co nie i co nie dotyczy, oraz uporządkowaną według priorytetów listę poprawek.
Wymagania wstępne: publicznie dostępny adres URL, około dziesięciu minut na pierwsze uruchomienie oraz dostęp do kodu, jeśli zamierzasz coś naprawić tego samego dnia.
Definicja ukończenia: potrafisz wyjaśnić swój wynik ułamkowy audyt po audycie i wskazać, które błędy naprawdę blokują agentom wykonanie zadania na Twojej stronie.
Skąd wziął się ten test i dlaczego teraz
Kategoria Agentic Browsing nie istniała rok temu. Wdrożenie odbyło się w trzech krokach, wszystkie udokumentowane przez Google:
- 7 maja 2026: Lighthouse 13.3 dodaje kategorię do domyślnej konfiguracji, dzięki czemu staje się ona częścią standardowego uruchomienia.
- 22 czerwca 2026: blog Chrome for Developers ogłasza ją w artykule "A developer toolkit to make your website agent-ready", razem z DevTools for agents i wskazówkami WebMCP.
- 20 lipca 2026: Lighthouse 13.4.1 włącza kategorię dla ścieżki API PageSpeed Insights i zapowiada, że wydanie trafi do PageSpeed Insights "w ciągu 2 tygodni". To stawia publiczne wdrożenie na początek sierpnia 2026.
Gdy uruchomiłem ten test 11 września 2026, stopka raportu mówiła "Emulated Moto G Power with Lighthouse 13.4.1", a Agentic Browsing stał bezpośrednio obok SEO. Funkcja jest więc aktywna, nie tylko w kanale canary. Jest też wyraźnie niedokończona. Opis kategorii w raporcie mówi to wprost: "This category is still under development and subject to change."
Jedna praktyczna uwaga przed startem: PSI uruchamia tę kategorię za Ciebie, po stronie Google. Nie potrzebujesz Chrome 150 ani origin trial do testów na poziomie strony. Lokalne uruchomienia w Chrome DevTools to te z wymaganiami wersji.
Uruchom test na własnej stronie
- Otwórz pagespeed.web.dev i wklej swój adres URL. Najpierw uruchom dla telefonu, potem powtórz dla komputera, ponieważ oba uruchomienia laboratoryjne są oceniane osobno.
- Poczekaj, aż dane laboratoryjne się zakończą. Dane terenowe na górze pochodzą z Chrome UX Report i wczytują się szybko. Uruchomienie Lighthouse poniżej trwa dłużej i to tam znajdują się kategorie.
- Znajdź wiersz wyników. Zobaczysz Wydajność, Dostępność, Najlepsze praktyki, SEO, a potem Agentic Browsing jako ułamek, a nie wynik 0–100.
- Rozwiń kategorię. Lista audytów grupuje się w Agent Accessibility, WebMCP oraz zwykłe zbiory testów zaliczonych i nieodpowiednich.
- Otwórz każdy niezaliczony audyt. Każdy wiersz rozwija się i pokazuje konkretną regułę, element lub plik stojący za błędem, czyli dokładnie to, czego potrzebujesz do zgłoszenia naprawczego.
Piąta kategoria stoi w tym samym wierszu co wyniki, które zespoły SEO sprawdzają codziennie. Zrzut z PageSpeed Insights z 11 września 2026.
Kontrola jakości: potwierdź wersję Lighthouse w szczegółach uruchomienia, zanim porównasz wyniki z kolegą. PSI aktualizuje Lighthouse według własnego harmonogramu, a kategoria wciąż zmienia się między wersjami.
Jeśli się nie uda: PSI czasami zwraca przekroczenie limitu czasu RPC na ciężkich stronach. Mnie też się to zdarzyło na dużej stronie w trakcie badania. Spróbuj ponownie albo przetestuj stronę lokalnym Lighthouse.
Odczytaj wynik ułamkowy poprawnie
Agentic Browsing nie ma ważonego wyniku 0–100 i to celowe. Dokumentacja Lighthouse mówi, że standardy dla agentowego webu wciąż się kształtują, więc nacisk jest na sygnały, które można wykorzystać, a nie na ranking.
Oto arytmetyka, która naprawdę ma znaczenie:
Wyświetlanie | Co oznacza |
|---|---|
3/3 | Wszystkie oceniane testy zaliczone. Testy nieodpowiednie są wykluczone. |
1/3 | Jeden zaliczony, dwa niezaliczone. Mianownik zawiera tylko testy zaliczone i niezaliczone. |
0/3 | Żaden oceniany test nie został jeszcze zaliczony. Częste przy pierwszym uruchomieniu na ciężkiej stronie pełnej reklam. |
Brak ułamka | Wszystkie audyty były nieodpowiednie albo kategoria się nie uruchomiła. Sprawdź szczegóły uruchomienia. |
Pułapką jest czytanie 1/3 jako "33 procent gotowości na agentów". To nie jest procent czegokolwiek. To liczba: jeden z trzech testów, które można było ocenić na tej stronie, został zaliczony, a testy nieodpowiednie zostały całkowicie pominięte w obliczeniach. W raporcie, który uchwyciłem, uruchomiono sześć audytów, trzy były nieodpowiednie, a pozostałe trzy dały wynik 1/3.
Wyniki zmieniają się też między uruchomieniami na tej samej stronie. Trzy przyczyny wymieniane przez Lighthouse to dynamiczna rejestracja narzędzi (narzędzia WebMCP rejestrowane przez JavaScript mogą zostać wychwycone albo pominięte w zależności od czasu), zmiany w DOM, które przekształcają drzewo dostępności, oraz przesunięcia układu od reklam, obrazów bez wymiarów lub wstrzykniętej treści. Jeśli Twój wynik się waha, to zwykle dlatego.
Przejdź przez sześć audytów
Obecna kompilacja PSI uruchamia sześć audytów. Jeden kolejny nadchodzi: gałąź rozwojowa Lighthouse dodaje już test ai-catalog.json (Agent Resource Discovery) w nowej grupie Agent Discoverability, więc traktuj tę listę jako zależną od wersji.
Audyt | Co sprawdza | Co oznacza "nie dotyczy" |
|---|---|---|
Drzewo dostępności jest nieprawidłowe | Podzbiór reguł dostępności skupionych na agentach: nazwy i etykiety programistyczne, poprawna struktura ARIA oraz elementy, które pozostają interaktywne, choć są ukryte przed drzewem | Nigdy; ten test jest zawsze oceniany |
llms.txt nie spełnia zaleceń | Czy | Plik zwrócił 404. Brakujący llms.txt jest traktowany jako opcjonalny, nie jako błąd |
Skumulowane przesunięcie układu | Stabilność wizualna, żeby agenci działający na pozycjach elementów nie klikali niewłaściwej rzeczy w trakcie przesunięcia | Nigdy; ten test jest zawsze oceniany |
Zarejestrowane narzędzia WebMCP | Czy strona rejestruje jakiekolwiek narzędzia WebMCP przez API deklaratywne lub imperatywne | Nie wykryto narzędzi WebMCP |
Pokrycie formularzy WebMCP | Formularze deklaratywne, którym brakuje adnotacji narzędzi | Jak wyżej |
Poprawność schematów WebMCP | Czy zarejestrowane narzędzia publikują poprawne schematy wejścia i wyjścia | Jak wyżej |
Rozwinięty widok kategorii: dwa błędy, jedno zaliczenie i trzy testy nieodpowiednie. Lista błędów to najkrótsza droga do zadania do wykonania.
Trzy audyty WebMCP pokazujące "nie dotyczy" to norma w 2026 roku. WebMCP to proponowany standard, w fazie origin trial i wczesnego podglądu, z dwoma API: deklaratywnym, które opisuje standardowe formularze HTML, i imperatywnym, które rejestruje narzędzia z JavaScriptu. Większość stron nie wdrożyła jeszcze żadnego z nich, więc większość raportów pokazuje tam trzy szare kółka. Szary to nie czerwony. Nie traktuj tego jako błędu.
Napraw to, co wskazuje test
Cztery tematy poprawek obejmują sześć audytów. Trzy wiersze WebMCP wymagają uwagi tylko wtedy, gdy naprawdę publikujesz narzędzia dla agentów.
Uczyń drzewo dostępności czytelnym dla agentów
Agenci opierają się na drzewie dostępności jako głównej mapie Twojej strony. Znajdują się tam role, nazwy i stany. Przycisk bez dostępnej nazwy to dla nich ślepa uliczka, podobnie jak dla użytkowników czytników ekranu.
Działanie: przejdź przez niezaliczone reguły z rozwiniętego audytu. Typowi podejrzani to przyciski z samą ikoną, pola formularzy bez etykiet, linki, których tekst to tylko "kliknij tutaj", nieprawidłowe kombinacje ról ARIA oraz zduplikowane identyfikatory wskazywane przez ARIA. Preferuj semantyczny HTML, dodawaj atrybuty for do etykiet i nadawaj niestandardowym widżetom jawną rolę oraz tabindex, gdy element natywny nie jest możliwy.
Oczekiwany rezultat: audyt zmienia się na zaliczony, a Twój zwykły wynik Dostępności zwykle poprawia się w tym samym czasie, ponieważ wersja Agentic Browsing to skupiony podzbiór tych samych testów.
Ścieżka naprawcza: jeśli lista poprawek liczy setki elementów, nie ścigaj ich pojedynczo. Napraw współdzielony komponent, na przykład przycisk z samą ikoną w nagłówku, i uruchom test ponownie. Jeden komponent często czyści dziesiątki wierszy.
Opublikuj llms.txt, który przejdzie test formatu
Ten ma pułapkę, która łapie uważnych ludzi. Audyt nie sprawdza tylko, czy /llms.txt istnieje. Sprawdza zawartość pliku, a plik z samymi adresami URL nie przechodzi, bo test szuka linków w stylu Markdown.
Działanie: utwórz /llms.txt w katalogu głównym swojej domeny z nagłówkiem H1 i prawdziwymi linkami Markdown:
# Your Company
Short description of what the site covers and how it should be used.
## Key pages
- [Product overview](https://example.com/product)
- [Pricing](https://example.com/pricing)
- [Documentation](https://example.com/docs)Oczekiwany rezultat: audyt zmienia się na zielony. Z kolei 404 pokazuje się jako nie dotyczy, co jest dziś akceptowalne. Odpowiedź z serii 500 lub błąd pobierania to prawdziwy błąd wymagający naprawy po stronie serwera.
Kontrola jakości: pobierz własny /llms.txt w terminalu i policz linki. Jeśli wyglądają jak https://example.com/pricing bez nawiasów kwadratowych, audyt nie przejdzie, mimo że plik działa i jest czytelny dla ludzi.
Jedno uczciwe zastrzeżenie: Google Search nie używa llms.txt. Sam przewodnik Google po optymalizacji pod AI mówi, że plik "will neither harm nor help your site's visibility or rankings in Google Search, as Google Search ignores them". Pisz go dla narzędzi agentów, które czytają tę konwencję, a nie dla pozycji w wynikach.
Ustabilizuj układ, żeby agenci mogli celować
Przesunięcie układu ma teraz większe znaczenie. Agent, który zlokalizuje przycisk, a potem kliknie jego współrzędne, spudłuje, jeśli reklama, baner lub późno wczytany obraz zepchnie ten przycisk o 200 pikseli w dół między tymi dwoma momentami.
Działanie: ustaw jawne szerokości i wysokości (lub aspect-ratio) na obrazach i osadzeniach, zarezerwuj stałe miejsce na sloty reklamowe i banery zgody, unikaj wstawiania treści nad istniejącą treścią po wczytaniu oraz animuj za pomocą transform zamiast właściwości wywołujących układ.
Oczekiwany rezultat: Skumulowane przesunięcie układu poniżej 0,1 w uruchomieniu laboratoryjnym, czyli ten sam próg, którego używają Core Web Vitals.
Kontrola jakości: sekcja Layout shift culprits pod Wydajnością wskazuje dokładne elementy odpowiedzialne za problem. Zacznij tam, zamiast zgadywać.
Zdecyduj o WebMCP później
Trzy audyty WebMCP są oceniane tylko wtedy, gdy Twoja strona rejestruje narzędzia. Jeśli prowadzisz proces rezerwacji, płatności, formularz wsparcia albo dowolne ustrukturyzowane zadanie, które agent mógłby wykonać, WebMCP jest wart prototypu: mówi agentom dokładnie, które narzędzie wywołać, zamiast kazać im zgadywać z DOM. Chrome udostępnia tę funkcję za origin trial i lokalną flagą testową, więc to realna opcja, nie eksperyment myślowy.
Jeśli nie masz zadania wartego automatyzacji, zostaw WebMCP w spokoju. Trzy szare kółka nie są problemem. Jedyne, czego nie robić, to rejestrowanie dekoracyjnego narzędzia tylko po to, by ułamek wyglądał lepiej. Kategoria jest sygnałem gotowości, a granie w tę grę niweczy jej sens.
Zweryfikuj poprawkę
Uruchom ponownie ten sam adres URL w PSI i porównaj trzy rzeczy, nie jedną: ułamek, statusy poszczególnych audytów i typ urządzenia. Poprawka może zmienić ułamek bez naprawienia tego, na czym Ci zależało, a telefon i komputer dają osobne wyniki laboratoryjne.
Aby iterować szybciej, uruchom Lighthouse lokalnie zamiast czekać na PSI. Kategoria jest w Lighthouse 13.3 i nowszych, więc lokalna instalacja ją zawiera. Jeśli chcesz wersję z panelu DevTools, dokumentacja Google zauważa, że testowanie kategorii wymaga Chrome 150 lub nowszego, a audyty WebMCP wymagają dodatkowo zarejestrowanego origin trial.
Prowadź krótki zapis przed i po. Wystarczy jeden wiersz z datą, na przykład "2026-09-11: mobile 1/3, niezaliczone drzewo a11y + llms.txt". To mówi, czy późniejsza regresja jest prawdziwa, czy tylko wahnięciem między uruchomieniami.
Czym ten test nie jest
Trzy rzeczy, których nie robi, bo zamieszanie wokół niego jest spore:
- Nie jest czynnikiem rankingowym. Ogłoszenie Chrome opisuje kategorię jako informacyjną i niebenchmarkowaną. Pozycje w Google Search nie zależą od Twojego ułamka Agentic Browsing.
- Nie jest wynikiem widoczności w AI. Mierzy, czy agent potrafi obsłużyć Twoją stronę. Nie mówi nic o tym, czy ChatGPT lub Perplexity cytuje Cię w odpowiedzi.
- Nie jest werdyktem zaliczone/niezaliczone dla Twojej strony. Niski ułamek na prostej stronie marketingowej zwykle oznacza, że było mało do oceny, a nie że agenci są zablokowani.
Soczewka, która pomaga: ta kategoria sprawdza, czy Twoja strona wytrzymuje, gdy odwiedzający nie jest człowiekiem. Wszystko, co nagradza, i tak warto robić: semantyczny HTML, stabilne układy, opisane kontrolki. Wskazówki Google dla stron przyjaznych agentom kończą się tą samą myślą: to, co czyni stronę gotową na agentów, czyni ją też lepszą dla ludzi.
Trzymaj to w swoim cyklu przeglądu
Gotowość na agentów to jedna z tych dziedzin, w których platforma porusza się szybciej niż lista kontrolna. Dwa nawyki utrzymują Cię na bieżąco, nie zamieniając tego w projekt:
- Uruchamiaj test ponownie po każdej zmianie szablonu, nawigacji, formularza lub płatności. To właśnie te zmiany poruszają drzewo dostępności i stabilność układu.
- Śledź ułamek na poziomie szablonu, a nie adresu URL. Dziesięć stron produktów ocenianych identycznie to problem szablonu, a jedna poprawka rozwiązuje wszystkie dziesięć.
Test w PSI jest celowo wąski: sześć audytów, jedna strona naraz. Jeśli chcesz szerszy obraz — w tym czy Twoje reguły robots, karty serwerów MCP, odkrywanie OAuth i sygnały handlu agentowego są na miejscu — Auspia prowadzi bezpłatny test Agent Readiness, który skanuje adres URL pod kątem tych standardów protokolarnych i pokazuje tabelę porównawczą.
FAQ
Czy wynik Agentic Browsing wpływa na pozycje w Google? Nie. Google opisuje tę kategorię jako informacyjną i nie jest ona częścią systemów rankingowych Search. Traktuj ją jako test gotowości dla agentów, nie jako wynik SEO.
Dlaczego mój ułamek zmienił się między dwoma uruchomieniami na tej samej stronie? Dynamiczna rejestracja narzędzi, zmiany w DOM przekształcające drzewo dostępności i późne przesunięcia układu powodują zmienność między uruchomieniami. Przetestuj ponownie i porównaj listę audytów, a nie tylko ułamek.
Dlaczego wszystkie trzy audyty WebMCP pokazują się jako nie dotyczy? Bo Twoja strona nie rejestruje narzędzi WebMCP. To oczekiwany stan dla większości stron w 2026 roku i nie jest to błąd.
Czy brakujący llms.txt to problem? Dla tego audytu nie. 404 jest traktowane jako nie dotyczy. Plik, który istnieje, ale jest wadliwy, nie przechodzi, więc jeśli go publikujesz, opublikuj go poprawnie.
Czy mogę uruchamiać to w CI? Tak, gdy kategoria jest w Twojej wersji Lighthouse. Audyty są deterministyczne z założenia i właśnie dlatego nadają się do testów w pipeline. Pamiętaj, że części WebMCP zależą od wsparcia przeglądarki i zapisu do origin trial, więc w większości środowisk CI spodziewaj się tam wyniku nie dotyczy.
Czy potrzebuję Chrome 150, żeby z tego korzystać? Nie. PageSpeed Insights uruchamia to po stronie serwera. Wymóg Chrome 150 dotyczy lokalnego uruchamiania kategorii w DevTools.
Autor: Alice Monroe, analityk narzędzi AI SEO zajmująca się ponad 150 narzędziami w Auspia. Alice pisze o SEO i narzędziach wyszukiwania AI, o tym, które testy są warte Twojego czasu, i jak wpleść je w codzienną rutynę.
