NLWeb stands for Natural Language Web. In practice, it means: your website exposes two REST endpoints, /ask for humans and /mcp for AI agents, that answer questions about your content in structured JSON. ChatGPT, Claude, and Perplexity can call your site directly instead of guessing from the HTML.
The phone-number-for-your-site analogy
SEO got your page into ten blue links. GEO got it cited in synthesized AI answers. AEO got it pulled into Google's answer boxes. NLWeb is the next step: it gives your website a phone number that AI agents can dial.
When ChatGPT, Claude, or Microsoft Copilot needs to know about your products, your inventory, or your articles, they currently scrape and guess. With NLWeb, they call /mcp on your site and ask in plain text. You answer in plain text. They quote your answer in their reply. You stay the source of truth.
How it actually works under the hood
Two endpoints. NLWeb adds /ask and /mcp to your domain. The /ask endpoint takes a natural-language query as JSON, returns a Schema.org-shaped JSON response. The /mcp endpoint speaks the Model Context Protocol, the same protocol Claude Desktop uses to talk to local tools, so AI agents can list your site as a callable tool.
Schema.org as the input. NLWeb reads the structured data that's already on your site: Product, Recipe, Article, Event, LocalBusiness, whichever Schema.org types you've marked up. It embeds those into a vector store and indexes them for retrieval. If your site has zero Schema.org markup, NLWeb has nothing to chew on.
LLM in the middle. When a query arrives at /ask, NLWeb decontextualizes it (resolves «what's that cost» against the prior turn), retrieves the matching content from the vector store, reranks with an LLM, and writes a final structured response. The site owner picks which vector store (Qdrant, Postgres pgvector) and which LLM (OpenAI, Anthropic, others).
MCP server by default. Every NLWeb deployment is also an MCP server. That's the key shift: your site stops being a destination AI agents have to crawl, and starts being a tool they can call. The published launch partners (Shopify, Tripadvisor, Eventbrite, O'Reilly, Booking, Hugging Face, Allrecipes) all run NLWeb endpoints today.
Who's behind it. Microsoft launched NLWeb at Build 2025. The lead is R.V. Guha, the same person who built RSS, RDF, and Schema.org. It's MIT-licensed, with reference implementations in Python and .NET on GitHub at github.com/microsoft/NLWeb.
How Lovable handles this for you
Honestly, it doesn't, yet. NLWeb is a server-side service: a Python (or .NET) process, a vector store, an LLM connection. Lovable's project-in-a-chat model can't currently provision that infrastructure. There's no «add NLWeb» row in the SEO & AI search review.
What Lovable does that feeds NLWeb's value: the JSON-LD structured data Lovable already generates per page (Article, BreadcrumbList, Organization) is exactly what NLWeb needs to index. The cleaner your site's Schema.org markup, the better NLWeb works once you wire it up. So the SEO & AI search foundation pays off twice: once for traditional search engines, once for an NLWeb endpoint pointed at your own site.
If you want NLWeb today, you run it next to your Lovable site, not inside it.
What you still need to do yourself
Decide if you actually need this. NLWeb makes sense when your site has structured content AI agents would call for (products, recipes, articles, events, listings). A personal blog probably doesn't justify the infrastructure. A content-heavy publication, a store, a knowledge base does.
Deploy the NLWeb service. Clone github.com/microsoft/NLWeb, pick a vector store (Postgres pgvector or Qdrant are the documented paths), connect an LLM (OpenAI, Anthropic, Azure), point it at your Lovable site's structured data. The Microsoft Community Hub has a Postgres-specific guide; there's also a .NET 9 reference implementation if you prefer.
Audit your Schema.org markup. NLWeb only knows what your structured data tells it. If your products lack price, your recipes lack ingredients, your articles lack author, NLWeb will answer with gaps. Use the SEO & AI search tab to find Schema.org weaknesses first.
Decide what to expose at /mcp. Not every part of your site needs to be a callable tool. Pick the operations that make sense for agents: search products, list events, find articles by topic. Skip admin pages and personal data.
Watch for spec drift. NLWeb is months old as a public spec, not years. Endpoints, response shapes, and configuration may change. The spec lives at nlweb.ai/spec.
A worked example: prep a Lovable site's Schema.org markup for NLWeb
The fastest way to learn this is to feed NLWeb good input. Here's the end-to-end loop for getting a Lovable site's Schema.org markup NLWeb-ready, even before you stand up the NLWeb service.
Step 1. Write the prompt.
Audit the structured data on the /products listing and /products/[slug] detail pages. Each product should emit JSON-LD with type "Product" including name, description, image, sku, brand, offers (price, priceCurrency, availability). The visible page content should match the structured fields exactly. Render the JSON-LD in the server-rendered <head>, not in a client-only component. Show me one rendered Product JSON-LD block from the preview source so I can verify.
The «server-rendered <head>» line is the one that matters. If JSON-LD ships from a client component, NLWeb's indexer can't see it.
Step 2. Inspect.
In the Lovable code panel. Find the Product page component. The JSON-LD should live in a <Head> helper or equivalent server-side render path. Search the file for "@type": "Product" and confirm price, currency, availability are real values pulled from the data layer, not placeholder strings.
In the running preview. Open one product URL in a new tab. Right-click then View Page Source. Search for application/ld+json. You should see one block per page with the full Product schema. Paste the live URL into Google's Rich Results Test (search.google.com/test/rich-results) to confirm price and availability are parsed.
Step 3. Validate against NLWeb's expectations. NLWeb's reference impl reads Schema.org as plain JSON-LD. If Google's Rich Results Test parses your Product schema cleanly, NLWeb will too. The reverse isn't true (NLWeb is more lenient), but Google's validator is the strict baseline. Once products are clean, repeat for Article, Event, Recipe, whichever types match your content.
What to remember
NLWeb is your website becoming a tool AI agents can call. Not a ranking play, not a citation play. A protocol shift.
Two endpoints (/ask, /mcp), built on Schema.org and MCP, open source, Microsoft-led but vendor-neutral. Major content sites have already deployed it.
Lovable doesn't run NLWeb for you. Its job in the chain is to keep your Schema.org structured data clean enough that NLWeb has something real to index when you do wire it up.