Przeglądanie Agentowe w PageSpeed Insights: jak przygotować stronę pod agentów AI

Przeglądanie Agentowe to eksperymentalna kategoria audytów w Lighthouse, która sprawdza, czy strona jest czytelna i nawigowalna dla agentów AI. Pojawia się w raportach PageSpeed Insights obok znanych kategorii jak Performance czy Accessibility, ale działa inaczej. Zamiast jednego wyniku punktowego dostarcza zestaw audytów zaliczonych, niezaliczonych i informacyjnych oraz proporcję zaliczonych kontroli.

Jest to o tyle istotne, że Lighthouse zaczyna diagnozować, czy strona jest wystarczająco czytelna, stabilna i opisana, żeby agent AI mógł się po niej poruszać bez zgadywania. Nie jest to jednak oficjalny czynnik rankingowy Google ani miara cytowalności w odpowiedziach AI. To deterministyczny audyt techniczny, który pomaga wykryć problemy z interakcją i strukturą strony.

Dlaczego strony projektowane tylko dla użytkowników tracą czytelność dla agentów AI

Strona może wyglądać świetnie dla użytkownika, ale może być jednocześnie chaosem dla poruszającego się po niej agenta AI. Wystarczy kilka błędnych rozwiązań frontendowych. Może to być menu renderowane dopiero po hydracji, przyciski zrobione z div, formularz bez etykiet, hero przesuwające layout po załadowaniu fontu albo treść schowana za klientowym JavaScriptem.

Użytkownik może tego nie zauważyć podczas korzystania ze strony, ale dla agenta AI oznacza to utratę kontekstu. Agenci przeglądarkowi mogą korzystać z drzewa dostępności, DOM-u, tekstu i zrzutów ekranu. Jeśli te warstwy nie przekazują spójnych informacji, agent może źle rozpoznać ofertę albo kliknąć niewłaściwy element. Taki problem utrudnia wykonanie zadania na stronie, ale sam w sobie nie dowodzi, że witryna zostanie pominięta w odpowiedziach AI.

Warto rozdzielić dwa etapy. Wyszukiwanie i wybór strony nadal opierają się na zasadach SEO oraz mechanizmach konkretnego dostawcy. Przeglądanie Agentowe dotyczy późniejszego etapu, w którym agent otwiera witrynę, interpretuje interfejs i próbuje wykonać zadanie.

Co bada Przeglądanie Agentowe w Lighthouse i PageSpeed Insights?

W praktyce można opisać gotowość strony za pomocą dwóch pojęć: discoverability i navigability. To pomocniczy sposób interpretacji wyniku, a nie dwa oficjalne wymiary punktacji Lighthouse.

Discoverability oznacza, czy agent potrafi odkryć, co jest na stronie ważne. Czy widzi główną treść? Czy linki prowadzą do kluczowych sekcji? Czy llms.txt podpowiada, gdzie szukać najważniejszych informacji? Czy formularz kontaktowy ma etykiety, a przycisk mówi programowo, co robi?

Navigability oznacza, czy agent potrafi po tej stronie bezpiecznie przejść i nie zgubić kontekstu. Istotne są kwestie: czy layout nie przesuwa się pod kursorem? Czy element interaktywny jest realnym <button> albo <a>, a nie dekoracyjnym kontenerem z onClick? Czy menu, formularze i karty są obecne w DOM-ie w przewidywalny sposób?

Aktualna konfiguracja kategorii obejmuje accessibility tree, CLS, trzy kontrole WebMCP oraz audyt llms.txt:

• Accessibility tree. Agent korzysta z nazw, ról i relacji elementów. Jeśli ikona-przycisk nie ma etykiety, człowiek może się domyślić po wyglądzie, ale agent dostaje pustą informację.

• CLS, czyli Cumulative Layout Shift, opisuje stabilność układu. Jeśli element zmienia pozycję między identyfikacją a kliknięciem, agent może trafić w nieprawidłowe miejsce.

• llms.txt jest opcjonalną konwencją umieszczaną w katalogu głównym domeny. Lighthouse sprawdza jego dostępność i podstawową strukturę, ale odpowiedź 404 daje wynik N/A, a nie błąd.

• WebMCP obejmuje listę zarejestrowanych narzędzi, formularze bez deklaratywnych metadanych i poprawność schematu. Część tych wyników ma obecnie charakter informacyjny.

Lista kontrolna techniczna: jak przygotować stronę pod Przeglądanie Agentowe

Pierwszym krokiem powinno być zrobienie porządku w rzeczach, które od lat są podstawą dobrego frontendu, dostępności oraz technicznego SEO.

Semantyczny HTML i struktura DOM dla agentów AI

Agent AI czyta strukturę strony, dlatego potrzebujemy klasycznego, semantycznego HTML:

• Używaj <main>, <nav>, <article>, <section>, <aside> zgodnie z przeznaczeniem
• Buduj interakcje na <button> i <a href>, nie na klikalnych div-ach
• Każdy element interaktywny musi mieć programową nazwę: tekst, aria-label albo poprawnie powiązany <label>
• Trzymaj logiczną hierarchię nagłówków i opisowe anchor texty
• Nie ukrywaj kluczowej treści przez aria-hidden, karuzele bez fallbacku albo komponenty istniejące dopiero po hydracji

W React najczęstszy problem jest z komponentami współdzielonymi: jeden źle napisany IconButton, CardLink albo customowy Select potrafi masowo zepsuć dostępność np. na kilkunastu podstronach naraz.

Plik llms.txt jako mapa strony dla agentów AI

llms.txt nie jest nowym robots.txt, który komunikuje reguły crawlowania. Jest rozwijającą się, opcjonalną konwencją mającą dostarczać obsługującym ją narzędziom skrócony przewodnik po stronie. Nie ma jednak publicznej gwarancji, że dany agent pobierze ten plik. Google Search wyraźnie informuje, że go ignoruje. Szczegółowy format, przykłady dla Next.js i Astro oraz zasady utrzymania opisałem w osobnym poradniku o wdrożeniu pliku llms.txt.

Specyfikacja wymaga tylko nagłówka H1. Krótki opis w blockquote i sekcje H2 z listami linków są opcjonalne, ale tworzą użyteczny, zalecany kształt dokumentu. Dla małej strony możesz zacząć od statycznego pliku, natomiast w blogu albo serwisie z CMS lepiej generować go z tego samego źródła prawdy co sitemapę. Jeśli sitemapę tworzysz automatycznie, a llms.txt aktualizujesz ręcznie, oba pliki szybko się rozjadą.

Przykład minimalnego kształtu:

# Example Studio
 
> Przykładowa firma tworząca szybkie strony, aplikacje webowe i treści eksperckie.
 
## Najważniejsze elementy strony czytelnej dla agentów AI
 
- [Strona główna](https://example.com/)
- [Usługi](https://example.com/services/)
- [Blog](https://example.com/blog/)

Jeśli decydujesz się na llms.txt, nie wrzucaj do niego wszystkiego jak leci. Linkuj strony kanoniczne, publiczne, aktualne i warte umieszczenia w skróconym kontekście. Pełne przykłady endpointów, filtrowanie draft/noindex, llms-full.txt i różnice między Astro a Next.js zostawiam w poradniku wdrożeniowym.

Jak poprawnie serwować llms.txt

Kompresja i cache ograniczają transfer oraz liczbę ponownych pobrań llms.txt, ale sam plik nie obniża Core Web Vitals strony, jeśli nie jest częścią jej procesu ładowania. Lighthouse pobiera go osobno na potrzeby audytu Przeglądania Agentowego.

W Next.js najprostszy wariant statyczny polega na zapisaniu pliku jako public/llms.txt i ustawieniu nagłówków w next.config.mjs:

// next.config.mjs
const nextConfig = {
  async headers() {
    return [
      {
        source: '/llms.txt',
        headers: [
          { key: 'Content-Type', value: 'text/plain; charset=utf-8' },
          {
            key: 'Cache-Control',
            value: 'public, max-age=3600, s-maxage=86400',
          },
        ],
      },
    ]
  },
}
 
export default nextConfig

max-age określa czas świeżości w przeglądarce, a s-maxage dotyczy współdzielonego cache CDN. Dłuższa wartość może opóźnić widoczność zmian, jeżeli hosting nie unieważnia cache po wdrożeniu. Przy generowaniu pliku przez Route Handler ustaw te same nagłówki bezpośrednio w zwracanym obiekcie Response.

Obsługę kompresji sprawdź na produkcji przez curl -I --compressed https://example.com/llms.txt. Nie zakładaj jej wyłącznie na podstawie konfiguracji frameworka, ponieważ ostateczne zachowanie zależy również od hostingu i CDN.

JavaScript, SSR i hydracja: jak ograniczyć szum dla agentów AI

Część agentów i crawlerów ma problem ze stronami, które bez JavaScriptu zwracają pusty dokument, a po hydracji są niestabilne wizualnie. Dlatego treść i podstawowa nawigacja nie powinny niepotrzebnie zależeć wyłącznie od klientowego runtime'u. SSR, SSG i Server Components są tutaj rekomendacjami architektonicznymi, a nie osobnymi kontrolami kategorii Agentic Browsing.

1. SSR/SSG dla treści, która ma być odkrywalna.
2. Server Components tam, gdzie nie ma realnej interakcji.
3. Małe Client Components zamiast całych sekcji oznaczonych "use client".
4. Brak lazy-loadu dla kluczowej treści tekstowej.
5. Rezerwacja miejsca na obrazy, embedy, cookie bary i dynamiczne bloki.
6. Ograniczenie third-party scripts, które opóźniają interakcję i zmieniają layout.

Najgorszy wariant to strona, która po pobraniu HTML-a pokazuje tylko pusty root aplikacji, a właściwa oferta, menu i CTA pojawiają się dopiero po hydracji. Dla użytkownika na szybkim laptopie to może być niezauważalne. Dla części agentów i prostych crawlerów to nadal pusta strona.

WebMCP w Przeglądaniu Agentowym: kiedy ma sens, a kiedy jest za wcześnie

WebMCP jest ważny, ale trzeba go opisać precyzyjnie. To nie jest to samo co klasyczny MCP używany przez Cursor, Claude Desktop czy własne integracje z CMS-em. O tym drugim piszę osobno w artykule o Model Context Protocol w TypeScript.

W kontekście Lighthouse WebMCP dotyczy strony w przeglądarce: formularzy, akcji i narzędzi, które agent mógłby rozpoznać bez zgadywania po wyglądzie. Przykładowo, może to być formularz kontaktowy opisany tak, żeby agent wiedział, jakie dane wpisać i co się stanie po wysłaniu.

Deklaratywna wersja WebMCP dodaje opis narzędzia bezpośrednio do formularza:

<form
  toolname="contact_request"
  tooldescription="Wysyła zapytanie do zespołu sprzedaży"
>
  <label for="email">E-mail</label>
  <input
    id="email"
    name="email"
    type="email"
    required
    toolparamdescription="Adres e-mail osoby wysyłającej zapytanie"
  />
  <button type="submit">Wyślij zapytanie</button>
</form>

Lighthouse sprawdza między innymi, czy toolname i tooldescription występują razem, czy wymagane pola mają name oraz czy parametry mają opis albo powiązaną etykietę. Audyt formularzy bez deklaratywnego WebMCP ma obecnie charakter informacyjny. Testy WebMCP wymagają wsparcia eksperymentalnej funkcji i udziału w origin trialu.

Jak przetestować Przeglądanie Agentowe i gotowość strony dla agentów AI?

Aktualnie nie istnieje jeden „AI-ready score", dlatego najlepiej połączyć ze sobą kilka prostych testów.

PageSpeed Insights i Lighthouse. Sprawdź, czy Przeglądanie Agentowe pojawia się w raporcie i które audyty są oznaczone jako zaliczone, oblane albo informacyjne. Lokalnie możesz użyć CLI:

npx lighthouse@latest https://example.com --only-categories=agentic-browsing

Do testu tej kategorii potrzebujesz Chrome 150 lub nowszego. Audyty WebMCP dodatkowo wymagają udziału witryny w origin trialu, dlatego ich brak w lokalnym raporcie nie oznacza błędu implementacji.

Accessibility tree. W Chrome DevTools sprawdź nazwy i role najważniejszych elementów, czyli menu, CTA, formularzy, kart usług, przycisków ikonowych. W sytuacji, jeśli użytkownik widzi przycisk, a accessibility tree widzi pusty element, agent też dostaje słaby sygnał.

Playwright jako smoke test semantyki. W CI nie musisz robić testów pod AI, ale możesz testować warunki, których agent potrzebuje:

import { expect, test } from '@playwright/test'
 
test('strona ma czytelne CTA i formularz kontaktowy', async ({ page }) => {
  await page.goto('https://example.com')
 
  await expect(page.getByRole('navigation')).toBeVisible()
  await expect(page.getByRole('link', { name: /kontakt/i })).toBeVisible()
  await expect(page.getByRole('button', { name: /wyślij|umów/i })).toBeVisible()
})

Eksploracyjny test z modelem. Może być pożyteczny, by wyłapać niektóre problemy. Wklej agentowi HTML strony albo podaj link i poproś: „Znajdź najważniejszą ofertę, formularz kontaktowy i najnowszy artykuł". Jeśli model gubi się w nawigacji, myli CTA albo nie potrafi wskazać kluczowej treści, sprawdź strukturę strony. Taki test nie jest jednak powtarzalnym benchmarkiem, ponieważ wynik zależy od modelu, narzędzi i sposobu renderowania.

Logi i crawling bez JS. Możesz też sprawdzić, co widzi prosty crawler bez renderowania JavaScriptu. Jeżeli bez JS znikają menu, oferta, dane autora i linki wewnętrzne, to masz problem nie tylko z Przeglądaniem Agentowym, ale także z technicznym SEO.

Logi serwera jako uzupełnienie GA4. Klasyczna analityka nie pokaże wielu żądań crawlerów, ponieważ GA4 wymaga uruchomienia JavaScriptu. Logi dostępu pozwalają sprawdzić żądania do llms.txt i podstron, ale sam nagłówek User-Agent nie potwierdza tożsamości bota. Jeśli dostawca publikuje metodę weryfikacji lub zakresy adresów IP, zestaw je z logami. Pamiętaj też, że żądanie w logu nie dowodzi wykorzystania ani zacytowania treści.

Dlaczego strona czytelna dla agentów AI daje przewagę biznesową?

Ścieżka zakupowa może zacząć się od zlecenia przekazanego asystentowi, na przykład „znajdź mi wykonawcę szybkiej strony usługowej w Astro albo Next.js, który zna techniczne SEO". Jest to inny scenariusz niż klasyczne wpisanie kilku słów w wyszukiwarkę. Nie należy jednak wyciągać z samego raportu zapytań w Search Console wniosku, że konkretną frazę wygenerował agent. Dla funkcji generatywnych Google właściwszym źródłem jest dedykowany raport Generative AI w Search Console, jeśli jest dostępny dla danej usługi i witryny.

Jeśli Twoja strona jest czytelna dla maszyn, zmniejszasz ryzyko, że agent nie zrozumie oferty albo nie znajdzie właściwej podstrony. W ten sposób techniczna czytelność strony staje się częścią dystrybucji. Witryna ma nie tylko wyglądać atrakcyjnie, ale także powinna być łatwa do streszczenia i użycia. Nie jest to jednak gwarancja cytowania przez asystentów AI.

Kontekst jako usługa: przyszłość SEO dla agentów AI

Zamiast optymalizować stronę pod nieznany algorytm AI, tworzyć sztuczne listy kontrolne, składać przesadne obietnice i pisać treści bardziej pod narzędzie niż pod człowieka, lepiej zacząć od przyjęcia innego modelu myślenia o problemie.

Można nazwać ten model kontekstem jako usługą (z ang. context-as-a-service), w którym strona dostarcza informacje różnym odbiorcom. Najważniejsi są użytkownicy, którzy chcą szybko zrozumieć ofertę lub produkt. Odbiorcą jest również Twój zespół utrzymujący treść, sitemapę i dane strukturalne z jednego źródła prawdy. Do tego dochodzi Googlebot indeksujący treść oraz agent AI, który może ją streścić, porównać albo wykonać akcję.

Semantyczny HTML, stabilny layout, dostępna nawigacja i czytelna treść pomagają ludziom, wyszukiwarkom oraz agentom. SSR lub SSG mogą dodatkowo ograniczyć zależność kluczowej treści od klientowego JavaScriptu. llms.txt i WebMCP pozostają opcjonalnymi warstwami dla konkretnych narzędzi i scenariuszy.

Jeśli chcesz sprawdzić gotowość projektu w React, Next.js albo Astro, obejmującą accessibility tree, CLS i renderowanie treści, napisz do mnie. Audyt powinien kończyć się listą konkretnych poprawek w kodzie, a nie ogólną etykietą „AI-ready".