Module experimental 4 min

NLWeb & MCP Endpoints

Microsoft's NLWeb turns a site into a conversational endpoint (/ask for questions, /mcp for agents) built from the schema and feeds you already publish.

By Akash Sharma SEO, AEO & GEO Strategist · Founder, The First Ranker

Why it mattersIf agents become the front door, a queryable endpoint beats hoping a crawler parses your pages correctly.

Definition & Foundation

Turn your site into something agents can call

NLWeb (Microsoft, May 2025) combines your existing Schema.org markup, RSS and sitemaps with a vector store and an LLM so your site can answer natural-language questions about itself, exposed as /ask for humans and /mcp for agents. The crucial detail: every NLWeb instance is also a Model Context Protocol server, which means agents can call your site as a tool rather than hoping a crawler parses your pages correctly. Early adopters include Shopify, Tripadvisor, O'Reilly and Eventbrite; Cloudflare added a managed deployment path in early 2026.

The GEO logic is a genuine shift in what structured data is for. Historically your schema was a citation hint, a suggestion to a crawler. With NLWeb it becomes the fuel for your own answer surface: sites with clean schema get an NLWeb endpoint nearly for free; sites without it have nothing to serve. If agents become the front door to the web, a queryable endpoint you control beats depending on each engine's crawler to interpret your HTML correctly. This node carries no impact score (adoption is early), but it converts structured-data work you may already be doing into a first-class, agent-callable interface.

Four Things to Know About NLWeb

Your published data, now queryable

two doors, one endpoint

/ask and /mcp

/ask answers natural-language questions from humans about your site; /mcp exposes the same knowledge to agents as a callable tool. One deployment serves both a conversational widget and an agent interface.

the key property

Every NLWeb site is an MCP server

Because the endpoint speaks the Model Context Protocol, agents can call it directly as a tool. Instead of scraping and guessing, an agent asks your site and gets a structured answer you control.

schema + feeds + sitemap

Built from data you already have

NLWeb assembles your Schema.org markup, RSS, and sitemaps into a vector store plus LLM. Clean structured data is the prerequisite; the cleaner your existing feeds, the better the endpoint answers with no new content work.

self-host or managed

Multiple deploy paths

You can self-host the open-source NLWeb stack or use a managed path like Cloudflare's. The managed routes lower the operational bar considerably, making a queryable endpoint realistic even for small teams.

Myths vs Reality

Common misreadings, corrected

Myth"NLWeb is just a chatbot widget for our website."

RealityThe /ask widget is the visible half; the strategic half is /mcp. Because every NLWeb instance is an MCP server, you're not just adding site search; you're publishing an agent-callable interface to your data. The value is being queryable by agents, not decorating your homepage with a chat box.

Myth"We can add NLWeb later once we decide it matters."

RealityYou can, but only if the prerequisite is in place. NLWeb is built from your schema, feeds, and sitemaps, so a site with clean structured data can stand one up quickly, while a site without it has nothing to serve. The readiness work is the structured-data hygiene you should be doing anyway; NLWeb just makes it pay twice.

Putting It to Work

Earn the endpoint with clean data first

NLWeb is only as good as the structured data it's built from. The work is getting your schema and feeds clean enough to serve, then choosing a deploy path that matches your team's operational appetite.

The NLWeb readiness playbook

Get your structured data serving-grade

NLWeb assembles Schema.org markup, RSS, and sitemaps into its knowledge base, so audit those first. Complete, accurate, consistent structured data is what makes the endpoint answer well, the same hygiene that helps every other engine cite you.

Decide what the endpoint should answer

Scope the questions you want /ask and /mcp to handle (product lookups, documentation, catalog queries) and make sure the underlying data covers them. An endpoint that confidently answers your top query types is worth more than one that covers everything shallowly.

Choose a deploy path (see the tabs)

Match the deployment to your team: self-host the open-source stack for maximum control, use a managed path like Cloudflare's to minimize ops, or lean on a CMS/platform integration if one exists for your stack. The per-path steps differ; see the platform tabs below.

Test it as an agent would

Exercise the /mcp endpoint the way an agent will (structured queries against your data), not just the human /ask widget. Confirm the answers are accurate and grounded in your real data, since an agent will act on them.

Keep it fresh with your feeds

Because the endpoint is built from your feeds and sitemaps, its answers are only as current as they are. Fold NLWeb into your normal freshness routine so the endpoint reflects current pricing, inventory, and content.

On your platform

Deploy the open-source NLWeb stack against your own vector store and model, pointing it at your schema, RSS, and sitemap sources.

Own the ops: indexing cadence, model choice, scaling, and monitoring of the /ask and /mcp endpoints.

Best when you need full control over data handling, model, and where the endpoint runs.

Use Cloudflare's managed NLWeb path to stand up the endpoint without running the vector store and model yourself.

Connect your structured-data sources and let the platform handle indexing, hosting, and scaling.

Best for small teams that want a queryable endpoint without the operational burden.

Check whether your CMS or commerce platform offers an NLWeb or MCP integration that emits the endpoint from data you already publish.

Enable it and map your existing schema/feeds to it, rather than building a separate pipeline.

Best when you're on a platform (e.g. a major commerce stack) already moving toward agent endpoints.

The First Ranker Akash's build log · running example

The docs site that became an MCP tool

A The First Ranker client with a large documentation library kept losing agent-driven support queries: assistants would scrape a page, misread a versioned code sample, and answer wrong. Akash saw that the client already had clean structured data and sitemaps, which meant an NLWeb endpoint was nearly free. They stood one up on the managed Cloudflare path, scoped it to answer product and docs questions, and exposed the /mcp endpoint so agents could query the docs as a tool instead of scraping them.

The difference was accuracy: instead of an agent guessing from rendered HTML, it now asked the endpoint and got answers grounded in the client's real, current data. "The schema work they'd done for citations suddenly had a second job," Akash notes. "It stopped being a hint to a crawler and became an interface an agent could call. That's the whole NLWeb bet: if agents are the front door, own the endpoint instead of hoping the crawler gets you right."

Verification Checks

How to know it's really done

0/4 verified

You're NLWeb-ready when clean data powers a queryable endpoint agents can trust. Click a check to mark it verified:

Works Together With

The nodes this one leans on

Tools, sources & live links continue below

Go deeper from Frontier

Voices to follow

Canonical reads

NLWeb: protocol overview & reference implementation (GitHub) ↗

Always current

These links resolve live: what you get is generated or filtered the moment you click.

Ask Perplexity A cited answer, generated the moment you click Ask ChatGPT See how ChatGPT explains it today Google · past month Only what was published in the last 30 days Google News Latest coverage across publications YouTube · newest Most recent walkthroughs and talks

Fresh from the field feed refreshed July 8, 2026

Sources

Microsoft: Introducing NLWeb, conversational interfaces for the web ↗