NLWeb — jak sprawić żeby Twoja strona odpowiadała agentom

Artykuł 7 z serii Anatomia Agenta AI ← Co może pójść nie tak — bezpieczeństwo agentów dla builderów

Do tej pory w tej serii budowaliśmy agenty. Teraz zmieniamy perspektywę — budujesz stronę która agenty obsługuje.

Każdy agent który wykonuje zadanie dla użytkownika w pewnym momencie trafia na strony internetowe. Szuka informacji, porównuje produkty, sprawdza dostępność. I napotyka ten sam problem: strona jest zaprojektowana dla człowieka — oczu które skanują layout, mózgu który wyciąga znaczenie z estetyki i kontekstu.

Agent nie ma oczu. Parsuje HTML, próbuje wywnioskować strukturę, szuka odpowiedzi w morzu tagów. Dla agenta typowa strona to jak szukanie konkretnego zdania w podręczniku bez spisu treści i bez indeksu.

NLWeb to odpowiedź na ten problem. Nie z perspektywy agenta — z perspektywy właściciela strony który chce żeby jego treść była dostępna agentom bez zgadywania.

Co NLWeb robi i jak działa

NLWeb to otwarty standard Microsoftu (ogłoszony na Build 2025 przez R.V. Guha — tego samego który stworzył RSS i stał za Schema.org). Idea jest prosta: każda strona wystawia endpoint /ask gdzie agent może zadać pytanie w języku naturalnym i dostać ustrukturyzowaną odpowiedź.

Bez NLWeb:

Agent → otwiera stronę → scrape HTML → przetwarza tagi → 
szuka odpowiedzi → interpretuje kontekst → może znaleźć

Z NLWeb:

Agent → GET /ask?q=jakie+produkty+masz+dla+firm → 
{"products": [...], "context": "..."} → gotowe

Dwa endpointy:

/ask — dla pytań w języku naturalnym. Agent pyta, strona odpowiada JSON-em bazując na danych Schema.org. Dla ludzi, dla agentów, dla wszystkiego co umie wysłać HTTP request.

/mcp — ten sam endpoint jako serwer MCP. Microsoft powiedział wprost: każda implementacja NLWeb jest jednocześnie serwerem MCP. Agenty które używają protokołu MCP mogą połączyć się bezpośrednio i wywołać narzędzia.

Fundament technicznie to dane strukturalne Schema.org. NLWeb nie buduje własnego indeksu — bierze to co strona już ma (Product, Article, Organization, FAQ) i wystawia to jako konwersacyjny interfejs. To jest powód dla którego właściwe dane strukturalne to prerequisit, nie opcja.

Trzy ścieżki implementacji

Ścieżka 1: WordPress + Yoast (najprostsza)

Jeśli masz WordPress z Yoastem — jesteś bliżej niż myślisz. Yoast ogłosił współpracę z Microsoftem i integracja NLWeb wchodzi w kolejnych aktualizacjach pluginu.

Co musisz mieć żeby ścieżka Yoast działała:

Yoast SEO w aktualnej wersji — sprawdź w Pluginy → Zainstalowane. Yoast 24.x i wyżej ma NLWeb w planach roadmapy, szczegóły w changelog każdej wersji.

Poprawne Schema.org — Yoast generuje je automatycznie, ale warto sprawdzić. Wejdź na dowolną stronę produktu lub artykuł i sprawdź source HTML pod kątem <script type="application/ld+json">. Powinien zawierać @type: "Product" albo @type: "Article" z wypełnionymi polami.

Weryfikacja — po aktualizacji Yoasta wejdź na twojastrona.pl/ask?q=test. Jeśli dostaniesz JSON odpowiedź — endpoint działa.

Ścieżka 2: Biblioteka nlweb.dev (dla developerów)

Microsoft udostępnił bibliotekę Python która implementuje cały stack NLWeb. Możesz uruchomić ją przy dowolnej stronie — WordPress, Headless, statycznej, custom.

git clone https://github.com/microsoft/NLWeb
cd NLWeb
pip install -r requirements.txt

Biblioteka oczekuje danych Schema.org jako wejścia — możesz podać URL sitemapy, plik JSON-LD, albo własną bazę danych. Uruchamia serwer który wystawia /ask i /mcp.

Dla WordPressa który ma poprawne Schema.org — podajesz sitemap.xml i biblioteka sama pobiera i indeksuje dane. Całość działa lokalnie lub na własnym serwerze.

Konfiguracja modelu AI: biblioteka obsługuje OpenAI API, Azure OpenAI, Anthropic i lokalne modele przez Ollama. System prompt i logika odpowiedzi jest konfigurowalna.

Ścieżka 3: Własny endpoint /ask

Najprostsza implementacja koncepcyjnie — endpoint który bierze query param q, odpytuje własną bazę wiedzy (RAG na llms-full.txt albo Schema.org) i zwraca JSON.

W WordPress jako custom REST API endpoint:

add_action('rest_api_init', function() {
    register_rest_route('nlweb/v1', '/ask', [
        'methods' => 'GET',
        'callback' => 'handle_nlweb_ask',
        'permission_callback' => '__return_true',
    ]);
});

function handle_nlweb_ask(WP_REST_Request $request) {
    $query = $request->get_param('q');
    
    // Tu logika odpytywania bazy wiedzy
    // Może być: RAG na llms-full.txt, Schema.org query,
    // lub wywołanie zewnętrznego API
    $response = query_knowledge_base($query);
    
    return rest_ensure_response([
        'query' => $query,
        'answer' => $response,
        'source' => home_url(),
    ]);
}

URL będzie wtedy: twojastrona.pl/wp-json/nlweb/v1/ask?q=pytanie

Dla zgodności z NLWeb standard endpoint powinien też odpowiadać na twojastrona.pl/ask — możesz to zrobić przez redirect w .htaccess lub Nginx config.

Testowanie — pięć komend curl

Masz endpoint. Sprawdzasz czy działa. Pięć testów które powinieneś przejść przed wdrożeniem.

Test 1: Podstawowe pytanie

curl "https://twojastrona.pl/ask?q=co+sprzedajecie"

Oczekiwany wynik: JSON z listą produktów lub usług, nie HTML, nie błąd 404.

Test 2: Pytanie o konkretny produkt

curl "https://twojastrona.pl/ask?q=ile+kosztuje+[nazwa+produktu]"

Oczekiwany wynik: JSON z ceną, dostępnością, linkiem.

Test 3: Pytanie poza zakresem

curl "https://twojastrona.pl/ask?q=jaka+jest+pogoda+w+warszawie"

Oczekiwany wynik: odpowiedź że to pytanie wykracza poza zakres strony — nie błąd serwera, nie halucynacja.

Test 4: Pusty query

curl "https://twojastrona.pl/ask?q="

Oczekiwany wynik: sensowna odpowiedź lub błąd z komunikatem — nie crash.

Test 5: Agent User-Agent

curl -H "User-Agent: Googlebot-AI/1.0" \
     "https://twojastrona.pl/ask?q=produkty"

Sprawdza czy endpoint odpowiada poprawnie na żądania z agent-like User-Agent — niektóre implementacje filtrują ruch inaczej dla agentów.

Schema.org jako prerequisit

NLWeb jest tak dobry jak dane strukturalne które ma pod spodem.

Endpoint /ask odpowiadający na „jakie masz produkty dla firm poniżej 50 pracowników” może dać świetną odpowiedź — jeśli ma dane Schema.org z polem audience i description dla każdego produktu. Może dać pustą lub błędną odpowiedź — jeśli Schema.org jest niepełne.

Minimum które powinieneś mieć zanim wdrożysz NLWeb:

Dla sklepu:

{
  "@type": "Product",
  "name": "Nazwa produktu",
  "description": "Opis który odpowiada na pytania klientów",
  "offers": {
    "price": "299",
    "priceCurrency": "PLN",
    "availability": "https://schema.org/InStock"
  }
}

Dla serwisu usługowego:

{
  "@type": "Service",
  "name": "Nazwa usługi",
  "description": "Co obejmuje, dla kogo, ile kosztuje",
  "provider": {
    "@type": "Organization",
    "name": "Nazwa firmy"
  }
}

Dla bloga/serwisu contentowego:

{
  "@type": "Article",
  "headline": "Tytuł",
  "author": {"@type": "Person", "name": "Autor"},
  "datePublished": "2026-01-15",
  "description": "O czym jest artykuł — to trafi do odpowiedzi agenta"
}

Weryfikacja Schema.org: schema.org/docs/gs.html i Google Rich Results Test. Jeśli Google rich snippets działają — NLWeb ma solidną bazę.

Dlaczego to ma znaczenie dla widoczności w AI

Artykuł 2 serii (RAG vs Agent vs Agentic RAG) wyjaśniał że agenty coraz częściej odpytują zasoby bezpośrednio zamiast przez wyszukiwarki. Strona która ma /ask endpoint jest dla agenta zasobem pierwszorzędnym — nie wynikiem wyszukiwania do sparsowania, ale interfejsem który aktywnie odpowiada.

Dla GEO (Generative Engine Optimization) to jest fundamentalna zmiana:

Tradycyjne SEO: zoptymalizuj stronę żeby Google ją zindeksował i pokazał wysoko.

NLWeb: udostępnij stronę bezpośrednio dla agentów żeby mogli pytać bez pośrednika.

Strona bez NLWeb może wciąż być cytowana przez AI Overviews — przez tradycyjny indeks Google. Strona z NLWeb jest cytowana i odpytywana bezpośrednio — to jest wyższy poziom uczestnictwa w ekosystemie agentowym.

W następnym artykule serii: masz agenta, wiesz jak go zabezpieczyć, Twoja strona odpowiada agentom — ile to kosztuje w produkcji i jak to optymalizować? Token cost, model routing i obserwabilność agenta.

Pojęcia ze słownika: NLWeb · Dane strukturalne · MCP · Agent-readiness · llms.txt · GEO