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": "..."} → gotoweDwa 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.txtBiblioteka 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
