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.