Strona gotowa na agentów AI: llms.txt, JSON-LD i WebMCP

Publikacja
Aktualizacja

Strona czytelna dla agentów AI to głównie stara dyscyplina: uczciwe kody HTTP, semantyczny HTML i dane strukturalne, a nie produkt do kupienia. Nowe są tylko dwie niewielkie konwencje, llms.txt i WebMCP. Całość to kilka dni pracy inżynierskiej, a pierwszą rzeczą do naprawy bywa zwykły błąd poprawności, który z AI nie ma nic wspólnego.

Piszemy to na przykładzie własnej strony. PageSpeed Insights z Lighthouse 13.6 ocenił naszą kategorię Agentic Browsing na 2 z 3. Nie przeszedł audyt llms.txt, a przyczyna leżała w routingu aplikacji, nie w braku „optymalizacji pod AI”.

Co sprawdza kategoria Agentic Browsing

Dokumentacja Chrome opisuje kategorię jako zestaw deterministycznych audytów, które sprawdzają, jak strona jest zbudowana pod kątem interakcji z maszyną. Jest wprost oznaczona jako eksperymentalna i oparta na proponowanych standardach. Testowanie wymaga Chrome 150 lub nowszego, a audyty WebMCP dodatkowo rejestracji w origin trial.

Sprawdzane są cztery obszary: podzbiór audytów dostępności (nazwy i etykiety, spójność drzewa dostępności, widoczność), bo agent czyta stronę przez to drzewo, a nie przez piksele; stabilność układu mierzona przez CLS; plik llms.txt; rejestracja narzędzi WebMCP, deklaratywnych w HTML i imperatywnych w JavaScript.

Punktacja działa inaczej niż w pozostałych kategoriach. Nie ma średniej ważonej 0–100, jest stosunek zaliczonych sprawdzeń. Audyt formularzy bez WebMCP jest informacyjny i nie generuje ostrzeżeń. Osobny audyt ARD szuka manifestu /.well-known/ard.json (lub starszego ai-catalog.json) z opisem serwerów MCP, agentów A2A i skilli. Gdy manifestu nie ma, wynik brzmi „nie dotyczy”. Firmowa strona, która nie wystawia agentów, nie musi go tworzyć.

Kod odpowiedzi to pierwszy interfejs agenta

Audyt zgłosił, że nasz llms.txt nie ma wymaganego nagłówka H1 i nie zawiera żadnych linków. Kłopot w tym, że pliku w ogóle nie było. Routing i18n traktował pierwszy segment ścieżki jako kod języka, a middleware pomijał ścieżki z kropką. W efekcie /llms.txt, podobnie jak dowolne /cokolwiek.txt, renderowało stronę główną z kodem 200 i adresem kanonicznym wskazującym na samą siebie. Audytor dostał HTML zamiast Markdownu.

To typowy soft 404. Google w opisie raportu indeksowania Search Console zaleca zwracanie kodu 404 dla stron, które naprawdę nie istnieją. Lighthouse widzi to podobnie: według opisu audytu llms.txt brak pliku oznacza wynik „nie dotyczy”, bo plik jest na razie opcjonalny. Uczciwy 404 nie obniżyłby więc wyniku. Odpowiedź 200 z cudzą treścią skończyła się niezaliczonym audytem.

Poprawka zajęła kilka linii. Layout sprawdza, czy pierwszy segment jest obsługiwanym językiem, i w przeciwnym razie wywołuje notFound(). Lekcja jest szersza: agent, crawler i walidator najpierw czytają status. Serwer, który na wszystko odpowiada 200, wprowadza w błąd każdy automat. Zanim dodacie nowe pliki, odpytajcie kilka nieistniejących adresów, także z rozszerzeniem .txt.

Dobry llms.txt to krótka mapa, nie sitemap

Specyfikacja llms.txt to propozycja Jeremy'ego Howarda, opublikowana we wrześniu 2024 roku i od tamtej pory rozwijana. Jedynym wymaganym elementem jest H1 z nazwą serwisu. Dalej idą: cytat blokowy z krótkim streszczeniem, opcjonalne akapity i sekcje H2 z listami linków w formacie [nazwa](url): notatka. Sekcja nazwana „Optional” zbiera linki, które czytnik może pominąć, gdy potrzebuje krótszego kontekstu.

Nasz plik powstaje z CMS, więc nie rozjeżdża się z treścią strony: usługi, realizacje, artykuły, kontakt i sekcja Optional, osobno dla każdego języka. Szkielet:

1# CloudTech Consulting
2

3> Software house z Warszawy: aplikacje webowe, integracje systemów, AWS i Google Cloud.
4

5## Usługi
6

7- [Nazwa usługi](https://example.com/oferta): jedno zdanie z CMS
8

9## Optional
10

11- [English version](https://example.com/en/llms.txt): ten plik po angielsku

Specyfikacja sama wyjaśnia, czym plik nie jest. Sitemap wylicza wszystkie indeksowalne strony, a llms.txt ma być wyselekcjonowanym przeglądem, który zmieści się w kontekście modelu. Robots.txt określa dozwolony dostęp, llms.txt pomaga agentowi w chwili odpowiedzi.

Nie jest to też czynnik rankingowy. W przewodniku o optymalizacji pod funkcje generatywnej AI w wyszukiwarce Google pisze, że wyszukiwarka takich plików nie używa, a ich utrzymywanie nie pomaga ani nie szkodzi widoczności. Nie znamy aktualnego, pierwszoźródłowego zestawienia innych systemów AI, które plik czytają. Traktujemy go więc jako tani dodatek dla agentów i narzędzi, które go obsługują, a nie jako kanał pozyskiwania ruchu.

Dane strukturalne są trwalszą inwestycją

Każda nasza strona ma JSON-LD. Organization i WebSite są w całym serwisie, artykuły mają BlogPosting i BreadcrumbList, a strony usług Service i FAQPage. Organizacja ma jeden stały @id we wszystkich językach, a grafy podstron odwołują się do niego. Dla agenta to sygnał, że obie wersje językowe opisują tę samą firmę.

Google zaleca dane Organization na stronie głównej albo „o nas”, bez pól wymaganych; zalecane są m.in. nazwa, adres, telefon, logo i sameAs. Artykuł może być typu Article, NewsArticle lub BlogPosting, a zalecane pola to autor, nagłówek, obraz i daty.

Trzeba znać granice. Ten sam przewodnik Google mówi, że dane strukturalne nie są wymagane do generatywnych wyników i nie istnieje specjalny znacznik dla AI, choć warto je utrzymywać w ramach SEO. Według dziennika zmian dokumentacji wyniki rozszerzone FAQ zniknęły z wyszukiwarki Google od 7 maja 2026 roku. FAQPage, typ z schema.org, zostawiamy więc dla maszynowego zrozumienia strony, bez oczekiwania na efekt w wynikach wyszukiwania.

Do tej samej warstwy należą sprawy mało efektowne. Przetłumaczone artykuły wskazują się nawzajem przez hreflang, a Google ignoruje adnotacje, które nie są obustronne. Sitemap nie zgłasza już stron z noindex ani sztucznych dat lastmod. Google korzysta z lastmod tylko wtedy, gdy wartość jest konsekwentnie i sprawdzalnie dokładna.

Formularz jako narzędzie: deklaratywny WebMCP

Deklaratywne API WebMCP zamienia zwykły formularz w narzędzie, które agent działający w przeglądarce może wywołać. Atrybuty toolname i tooldescription na elemencie form rejestrują narzędzie. toolparamdescription na polu opisuje parametr, a w jego braku przeglądarka bierze tekst etykiety. Chrome dostarcza to w origin trial i zastrzega, że API jest w trakcie dyskusji i może się zmienić.

Najważniejsza jest decyzja o wysyłce. Bez toolautosubmit przeglądarka wypełnia pola i ustawia na formularzu fokus, a wysłać musi człowiek. Z tym atrybutem wywołanie przez agenta od razu wysyła formularz. Nasz formularz kontaktowy celowo go nie ma:

1<form toolname="send_contact_enquiry"
2      tooldescription="Sends a project enquiry to CloudTech Consulting...">
3  <input name="company-website" tabindex="-1" autocomplete="off"
4         toolparamdescription="Spam trap for bots. Always leave this field empty.">
5</form>

Zapytanie wychodzi w imieniu konkretnej osoby, więc to ona powinna zobaczyć je przed wysłaniem. Drugi szczegół łatwo przeoczyć. Agent widzi wszystkie pola formularza jako parametry narzędzia, także ukryte pole-pułapkę na boty. Bez opisu mógłby je wypełnić, a wtedy filtr antyspamowy odrzuciłby prawdziwe zapytanie. Jedno zdanie w toolparamdescription rozwiązuje ten problem.

Kolejność prac i realny nakład

Szacunki z naszej pracy nad serwisem na CMS, nie norma:

  1. Kody odpowiedzi: 404 dla nieistniejących ścieżek, także z kropką, i brak przekierowań na stronę główną. Od kilku godzin do dnia.
  2. Sitemap, canonical i hreflang: bez stron noindex, z prawdziwymi datami, z obustronnymi parami językowymi. Około dnia.
  3. JSON-LD: Organization i WebSite globalnie, potem typy podstron, walidacja na kilku szablonach. Jeden do dwóch dni.
  4. Dostępność z punktu widzenia agenta: etykiety pól, nazwy przycisków, stabilny układ. Zależnie od stanu strony, zwykle dzień.
  5. llms.txt generowany z CMS, w osobnej wersji dla każdego języka. Kilka godzin.
  6. Atrybuty WebMCP na jednym lub dwóch formularzach i test w Chrome z origin trial. Kilka godzin.

Jeśli chcecie omówić tę listę na przykładzie własnej strony, formularz kontaktowy ma już opisane atrybuty WebMCP.

Czego nie robić

Nie upychajcie słów kluczowych w llms.txt. Model nie wyciągnie z listy fraz nic użytecznego. Każdy link powinien mieć jedno rzeczowe zdanie.

Nie publikujcie znaczników sprzecznych z widoczną stroną. Ogólne wytyczne Google wymagają, by dane strukturalne wiernie odzwierciedlały treść, i zabraniają oznaczania treści niewidocznej dla czytelnika. FAQ istniejące tylko w JSON-LD albo adres inny niż w stopce to błąd, nie optymalizacja.

Nie włączajcie toolautosubmit w formularzach, które coś wysyłają, zamawiają lub zmieniają w imieniu użytkownika.

Nie kupujcie wtyczki „AI SEO”, zanim nie sprawdzicie kodów odpowiedzi, i nie róbcie z wyniku kategorii celu. Nasz wynik po poprawkach nie był jeszcze mierzony na produkcji, a kategoria może się zmienić z kolejną wersją Lighthouse.

Źródła