Google właśnie dodało do Lighthouse nową kategorię — „Agentic Browsing". Ocenia ona nie jak szybka jest Twoja strona, ale jak dobrze radzi sobie z nią agent AI. W centrum tej zmiany jest standard W3C o nazwie WebMCP. Wdrożyłem go na czujowski.pl — i opisuję jak to zrobiłem krok po kroku.

Czym jest agentic browsing i dlaczego to zmienia zasady gry

Przez ostatnie dwie dekady strony internetowe projektowaliśmy pod ludzi. Później — pod boty indeksujące (SEO). Teraz nadchodzi trzecia era: projektowanie pod agentów AI, którzy nie tylko czytają Twoją stronę, ale na niej działają.

Agent AI to program który działa autonomicznie: może kliknąć przycisk, wypełnić formularz, zebrać dane o usługach, zapisać spotkanie. Dotychczas robił to metodą brute-force — parsował HTML, szukał elementów, strzelał w CSS selektory. Był kruchy i nieprzewidywalny.

WebMCP zmienia to fundamentalnie. Zamiast zgadywać co jest na stronie, agent może zapytać wprost: „jakie narzędzia tu masz?" — i otrzymać ustrukturyzowaną odpowiedź. Tak jak API, tyle że wbudowane w przeglądarkę.

Konkretnie: agent AI obsługujący asystenta biznesowego mógłby wejść na czujowski.pl, wywołać narzędzie get_services, dostać JSON z listą usług i cenami, a następnie wywołać book_consultation i podać klientowi gotowy link do rezerwacji — bez jednego kliknięcia przez człowieka.

Czym różni się WebMCP od llms.txt?

Mam już na czujowski.pl pliki llms.txt i llms-full.txt — które opisują stronę dla botów AI zbierających dane do modeli językowych. Ale to jest statyczna dokumentacja — jak wizytówka: „oto czym jesteśmy, oto nasze usługi".

WebMCP to aktywny interfejs. Różnica jest jak między broszurą a recepcjonistką, która odpowiada na pytania w czasie rzeczywistym.

Cecha llms.txt WebMCP
Typ Plik statyczny Aktywny interfejs JS
Cel Opisać stronę dla AI Udostępnić akcje dla agentów
Filtrowanie Brak Agent może filtrować po kategorii
Wynik Tekst / markdown Ustrukturyzowany JSON
Ryzyko Minimalne Minimalne (tylko odczyt na stronie statycznej)

Optymalna strona powinna mieć oba — llms.txt dla botów indeksujących, WebMCP dla agentów działających.

Jak działa WebMCP technicznie

Standard W3C definiuje jeden kluczowy obiekt w przeglądarce: document.modelContext. Jeśli istnieje — przeglądarka (lub agent) wspiera WebMCP. Jeśli nie — nic się nie dzieje, strona działa normalnie.

Na tym obiekcie wywołujesz registerTool() z trzema elementami:

Minimalne, działające narzędzie wygląda tak:

// Zabezpieczenie — kod nie uruchomi się w zwykłej przeglądarce
if (!('modelContext' in document)) return;

document.modelContext.registerTool({
  name: 'get_contact',
  description: 'Zwraca dane kontaktowe firmy: e-mail, telefon i link do rezerwacji.',
  inputSchema: { type: 'object', properties: {} },
  async execute() {
    return {
      content: [{
        type: 'text',
        text: JSON.stringify({
          email: 'kontakt@czujowski.pl',
          phone: '+48 452 422 086',
          booking: 'https://cal.com/przemyslaw-czujowski-sasnsv/30min'
        }, null, 2)
      }]
    };
  }
});

Co wdrożyłem na czujowski.pl — 5 narzędzi

Zarejestrowałem pięć narzędzi które pokrywają wszystko czego agent AI może potrzebować odwiedzając stronę konsultanta:

Narzędzie Co zwraca Parametry
get_services Lista usług z cenami, opisami i URL-ami Opcjonalnie: kategoria (web, seo, ai, ads…)
get_contact E-mail, telefon, NIP, link Cal.com Brak
get_articles Lista artykułów z datami i tagami tematycznymi Opcjonalnie: słowo kluczowe (SEO, AI, WordPress…)
book_consultation Link do rezerwacji + opis procesu Brak
get_about Profil: doświadczenie, certyfikaty, specjalizacje Brak

Dlaczego akurat te pięć? Bo to typowe pytania które zadaje agent pomagający użytkownikowi wybrać usługodawcę: „co oferuje?", „ile kosztuje?", „jak się skontaktować?", „co piszą na blogu?", „kim jest?". Zamiast parsować HTML — dostaje gotowy JSON w milisekundy.

Kluczowy detal — opisy narzędzi

Najważniejszy element każdego narzędzia to pole description. Agent AI decyduje które narzędzia wywołać wyłącznie na podstawie ich opisów — bez czytania kodu. Słabe opisy = narzędzia których nikt nie użyje.

Słaby opis: „Pobiera usługi."

Dobry opis: „Zwraca listę usług oferowanych przez Przemysława Czujowskiego — konsultanta IT i marketingu z Wrocławia. Zawiera nazwy, opisy, ceny orientacyjne i URL-e stron usługowych. Opcjonalnie filtruje po kategorii: web, seo, ai, ecommerce, ads, medical."

Dobry opis odpowiada na pytania: kto to oferuje? co dokładnie jest w odpowiedzi? kiedy warto wywołać to narzędzie?

Jak to sprawdzić — Lighthouse Agentic Browsing

Google dodało nową kategorię do Lighthouse dostępną w Chrome Canary. Ocenia ona:

  1. Registered WebMCP Tools — czy strona rejestruje narzędzia przez document.modelContext
  2. WebMCP Schema Validity — czy JSON Schema narzędzi jest poprawny
  3. llms.txt — czy plik istnieje i jest dostępny pod /llms.txt
  4. Accessibility for Agents — czy DOM ma sensowne nazwy (aria-label, alt, semantyczny HTML)
  5. Layout Stability (CLS) — czy strona nie „skacze" gdy agent próbuje coś kliknąć

Wynik nie jest skalą 0–100 jak tradycyjny Lighthouse — to lista zdał/nie zdał dla każdego audytu. Cel to mieć wszystko zielone.

Dlaczego warto być pionierem — argument SEO

Pamiętasz kiedy pojawiło się GEO (Generative Engine Optimization)? Pierwsze strony które wdrożyły llms.txt, schema FAQPage i pisały w formacie cytowanym przez AI — dziś mają wyraźną przewagę widoczności w ChatGPT, Perplexity i Gemini.

WebMCP jest teraz w tym samym punkcie co GEO 12 miesięcy temu. Standard jest eksperymentalny — ale Chrome, Apple i Mozilla aktywnie pracują nad implementacją. Kiedy trafi do stable release, strony które mają już zarejestrowane narzędzia będą natychmiast gotowe.

Kto dziś ma llms.txt — jutro będzie cytowany przez AI. Kto dziś ma WebMCP — pojutrze będzie wywoływany przez agentów AI. Reszta będzie parsowana jak zwykły HTML.

Na czujowski.pl spełniam wszystkie cztery kryteria Lighthouse Agentic Browsing:

Jak wdrożyć WebMCP na własnej stronie — krok po kroku

  1. Określ jakie narzędzia mają sens dla Twojej strony. Sklep: search_products, get_product, get_shipping_info. Gabinet lekarski: get_specializations, get_schedule, book_appointment. Konsultant: get_services, get_contact, book_consultation.
  2. Napisz opisy w języku naturalnym — tak jakbyś tłumaczył nowe narzędzie asystentowi który nigdy nie widział Twojej strony. Im dokładniejszy opis, tym trafniej agent zdecyduje kiedy wywołać narzędzie.
  3. Zaimplementuj narzędzia w JavaScript — wewnątrz bloku if (!('modelContext' in document)) return który chroni przed błędami w zwykłych przeglądarkach.
  4. Sprawdź poprawność JSON Schema — parametry narzędzi muszą być opisane zgodnie ze specyfikacją JSON Schema Draft 7. Validator online: jsonschema.dev.
  5. Przetestuj w Chrome Canary — włącz flagę chrome://flags/#enable-web-mcp i uruchom Lighthouse z kategorią „Agentic Browsing".
Ważne dla stron statycznych: narzędzia WebMCP powinny zwracać tylko dane — nie wykonywać akcji zapisu. Na stronie statycznej to naturalne ograniczenie (nie ma backendu). Na stronach dynamicznych z formularzami rozważ Permissions Policy z allow="tools" do kontroli dostępu.

Co jeszcze Lighthouse sprawdza — accessibility for agents

Poza WebMCP, Lighthouse Agentic Browsing sprawdza czy agent może w ogóle zorientować się co jest na stronie. To te same zasady co w WCAG — ale z perspektywy maszyny, nie człowieka niedowidzącego.

Konkretne wymagania:

Na czujowski.pl wszystkie SVG ikony w nawigacji i treści mają aria-hidden="true". Formularze mają widoczne etykiety lub placeholder z aria-label. To jednocześnie dobre praktyki dostępności dla ludzi — i dobra podstawa dla agentów.

WebMCP jest dziś tam gdzie Schema.org było w 2012 roku — eksperymentalny, ale kierunek jest jasny. Strony które wdrożą go teraz, gdy jeszcze mało kto o nim słyszał, będą miały naturalną przewagę gdy standard trafi do produkcji. Jeśli chcesz wdrożyć WebMCP lub pełny audyt GEO na swojej stronie — napisz do mnie.