NLWeb — the natural-language discovery layer for the agentic web

What is NLWeb?

NLWeb is an open-source protocol — initially proposed by Microsoft and authored by R.V. Guha (the creator of Schema.org) — that layers a natural-language query interface on top of a site's existing Schema.org markup, so agents and humans can ask conversational questions and receive structured answers. Every NLWeb deployment also exposes an MCP server.

By the numbers

• 6,200+ — GitHub stars on the open-source NLWeb reference implementation, up from launch in May 2025 (GitHub — nlweb-ai/NLWeb)
• 12+ — named launch pioneers — Shopify, Tripadvisor, Eventbrite, O'Reilly, Common Sense Media, Hearst, others (Microsoft Source)
• 7 — vector-store backends NLWeb natively supports — Qdrant, Snowflake, Milvus, Azure, plus more (GitHub — nlweb-ai/NLWeb)

Why it matters

NLWeb extends Schema.org from static structured data to queryable natural-language interface. The difference matters at the agent layer: today an agent that wants to know "does this site have hiking boots under $200 in size 11?" has to crawl product pages, parse Schema.org/Product, and reason over the result set itself. With NLWeb, the agent asks the question and the site answers. That's a step-change in how reachable your catalog, content, or knowledge base is to an agent operating in conversational mode — and it compounds on Schema.org investment you've likely already made.

NLWeb sits on top of Schema.org — it's an extension, not a replacement. This is the most important framing. If your site already has good Schema.org markup, NLWeb is a small additional step: configure the reference implementation, point it at your structured data, pick a vector backend, ship the endpoint. If you don't have Schema.org, NLWeb has nothing to query — fix the markup first, layer NLWeb second. The protocol assumes you've done the structured-data work; it doesn't substitute for it.

The ecosystem ships with real choice on day one. Per the open-source repo at nlweb-ai/NLWeb (6,200+ stars), the reference implementation supports 7 vector backends (Qdrant, Snowflake, Milvus, Azure AI Search, Elasticsearch, Postgres, Cloudflare AutoRAG) and 6+ LLM provider integrations (OpenAI, Anthropic, Gemini, others). That's a deliberate design choice — NLWeb doesn't lock you into a particular cloud, retriever, or model vendor. The deployment shape matches your existing infrastructure rather than forcing a migration.

The early-adopter list is short but signals direction. 12+ named launch pioneers spanning Shopify, Tripadvisor, Eventbrite, O'Reilly, Common Sense Media, Hearst, Allrecipes, and others. The pattern is content-heavy or catalog-heavy sites where the value of "agent can ask conversational questions" maps cleanly to user behavior. SaaS hasn't moved on NLWeb yet (MCP is the higher-leverage move for SaaS); content publishers and marketplaces have. If your site looks like one of those pioneers, the adoption signal is real.

Every NLWeb endpoint is also an MCP server. This is a packaging decision in the reference implementation — when you ship NLWeb, the server also exposes an MCP interface for tool-style access to the same underlying data. Sites deploying NLWeb get protocol-stack convergence for free: a single deployment covers both the natural-language query surface (NLWeb) and the tool-call surface (Model Context Protocol) inside one package. The architectural elegance is the point — it's why R.V. Guha's framing of the protocol stack treats NLWeb as the entry point and MCP as the action layer.

The strategic positioning: agent-reachability beats machine-readability. Schema.org made your data machine-readable. NLWeb makes it agent-reachable. The distinction is the difference between "a parser could extract this if it knew what to look for" and "an agent can ask a question and get a structured answer back." For sites whose value is locked inside content the agent has to discover rather than actions the agent has to perform, NLWeb is the higher-leverage move.

Where it's heading

Conversational-discovery features harden. Today NLWeb is mostly single-turn query → structured response. Expect multi-turn dialog over Schema.org to land in 2026 — the agent asks a question, the site responds, the agent refines, the site narrows. The reference implementation already has hooks for session state; the protocol-level pattern follows shortly.

Microsoft + Cloudflare partnership deepens. Cloudflare AutoRAG was an early NLWeb backend; expect tighter integration as Cloudflare's edge-AI story expands. The likely shape: one-click NLWeb deployment from Cloudflare Pages with AutoRAG as the default backend, sitting in front of an arbitrary content source. That collapses the deployment friction further — from "configure a backend" to "flip a toggle."

W3C Web Machine Learning CG formalizes parts of the spec. Parts of NLWeb (the query envelope, the response shape, the MCP-bundling convention) are candidates for formal standardization through the same W3C group that's editing the WebMCP draft. Standards-track stabilization makes NLWeb safer to bet on for enterprises that won't ship on an open-source-only spec.

An agent-discoverability benchmark emerges. Independent benchmarks that score sites on "can a conversational agent successfully answer questions about this site's content?" are likely in 2026-2027. NLWeb-deployed sites will lead those benchmarks; non-deployed sites will lag. That's the kind of signal that moves NLWeb from "early adopter" to "competitive necessity" — same arc OpenAPI followed for developer-facing APIs.

Common mistakes

• Skipping Schema.org before deploying NLWeb. NLWeb queries the structured data you've published. No Schema.org means no data to query against. Fix schema coverage first, layer NLWeb second.
• Deploying NLWeb without choosing a vector backend. Running the reference implementation on default config in production gets you a demo, not a service. Pick a backend that matches your infrastructure and operate it like you operate the rest of your stack.
• Treating NLWeb as a replacement for MCP or A2A. They solve different layers. NLWeb is the content-discovery entry point. MCP is the action surface. A2A is the cross-vendor coordination layer. Most agent-ready sites end up with at least two of the three.
• Not exposing the NLWeb endpoint at a well-known path. Agents discover NLWeb endpoints by convention. Bury the endpoint at a custom path and you lose discoverability — defeating the point of deploying it. Follow the reference path or document it explicitly in your llms.txt.
• Auth that breaks crawler access to the underlying Schema.org. A common failure mode: NLWeb deploys fine, but the structured-data pages it queries against are gated behind auth that blocks crawlers. The Schema.org has to be reachable for the NLWeb layer to surface it. Audit access policy alongside NLWeb deployment.
• Shipping NLWeb on a stale knowledge base. NLWeb is only as fresh as the index behind it. If your vector backend hasn't reindexed in three months, agents are getting stale answers to current questions. Treat the index as a first-class operational concern with a refresh cadence that matches content change frequency.

Frequently asked

Related

• Agent Protocols (FRONTIER HUB) — The Frontier category covering MCP, A2A, NLWeb, and WebMCP — the protocol layer of the agent stack.
• Model Context Protocol (MCP) (PARAMETER) — Companion protocol — every NLWeb deployment is also an MCP server. NLWeb sits on top of structured data; MCP carries the tool calls.
• Agent-to-Agent Protocol (A2A) (PARAMETER) — Sibling protocol — A2A coordinates agents across vendors; NLWeb gives them a natural-language entry point into your content.
• Schema Coverage (PARAMETER) — The scored Clarity parameter NLWeb compounds on — NLWeb without Schema.org has nothing to query.