Your Website Can Answer Questions Now. Should It?

By Greg Nowak. Last updated 2026-08-11.

A visitor comes to your website with a specific question. Your search box expects the right keywords. They try once, open a few links, then give up.

NLWeb offers a different experience: visitors ask questions in ordinary language and receive structured answers grounded in the site's own content. This is no longer limited to experimental demos. There is now an open protocol, a reference implementation and a deployment route through Cloudflare.

Getting something running is becoming easier. Deciding whether it belongs on your website is the harder part. Does conversational search solve a genuine discovery problem for your users? And can your team keep the answers accurate, inspectable and current?

What has changed?

The NLWeb software overview starts with a useful observation: many websites are collections of identifiable items. Those items might be articles, products, recipes, job vacancies, listings or reviews. Formats such as Schema.org and RSS may already describe them in a machine-readable form. NLWeb can ingest that structure and use language models to retrieve contextually relevant results.

The protocol specification defines how the interaction works. Its core ask operation accepts a natural-language query, with optional conversation context, filters and response preferences. It returns structured JSON objects and recommends support for result types, source grounding and actions. Results can also stream through Server-Sent Events, and NLWeb operations can be exposed as tools to agent clients.

Cloudflare has turned this into a more concrete deployment option. Its NLWeb documentation, updated on 10 July 2026, shows AI Search crawling and indexing a website before automatically deploying an NLWeb Worker. The Worker exposes an /ask endpoint for conversational interfaces and an /mcp endpoint for trusted AI agents.

There is a catch worth noticing before anyone writes a production plan. Cloudflare labels the implementation a public preview for experimentation and advises prospective production users to contact the company. A short deployment path is helpful, but it does not remove the need for careful evaluation.

An answer carries more responsibility than a search result

Traditional search makes a fairly modest promise: here are some documents that may contain what you need. A conversational interface goes further. It interprets the question, chooses relevant material and assembles an answer.

That saves the visitor time, but shifts responsibility to the website owner. If retrieval misses a key page, two sources disagree or an indexed page is out of date, the response may still sound confident. Citations and source grounding give users a way to check the answer. They also help the team diagnose whether a failure came from poor retrieval or from the generated summary.

This is why NLWeb readiness starts with content rather than model selection. Schema.org and RSS provide a valuable semantic base, but good markup cannot repair contradictory, neglected or ownerless information. The indexed material still needs a clear scope, consistent terminology, authoritative versions and a reliable update process.

What to assess	Promising pilot signal	Reason to pause
Content	Products, documentation, articles or listings with repeatable fields	Mostly promotional pages and unrelated one-off content
User questions	People compare options or need information from several pages	Most visits lead straight to one obvious page or action
Source quality	Current, owned material with clear canonical versions	Duplicate, conflicting or poorly maintained pages
Machine-readable data	Useful Schema.org, RSS or similar inputs already exist	Important facts are inconsistent or absent from indexable content
Ownership	Someone can review logs, test answers and maintain access rules	Nobody owns the service after launch

A first-pass screen for deciding whether an NLWeb feasibility pilot is worth running.

Where NLWeb is likely to earn its keep

The clearest candidates are content-heavy websites where finding an answer currently takes several searches or a fair amount of browsing. A documentation user may need instructions scattered across multiple pages. A catalogue visitor may know their constraints but not the product name. Someone searching a directory may want to combine location, category and attributes in a single question. A publisher may have a valuable archive that keyword search does a poor job of exposing.

These examples fit NLWeb's structured-item model, conversational context and domain-specific filters. Just as importantly, they give a pilot something concrete to test: real questions whose answers can be checked against authoritative material.

A small brochure site is a weaker case. If visitors mainly need opening hours, one service page and a contact form, clearer navigation and tighter copy may deliver more value with less maintenance. There is little reason to introduce conversational search where the underlying journey is already simple.

Your architecture choice determines the ongoing work

Cloudflare's route cuts down the initial setup. Its template crawls rendered website pages, applies retrieval settings intended for content-heavy sites and deploys a Worker. Teams can use the embeddable interface or build their own UI against the /ask endpoint.

The official NLWeb repository provides a more configurable reference architecture. It includes connectors for several language models and vector stores, along with ingestion tools, configuration files and a sample interface. The project describes this as a reference implementation, not a definitive production solution.

Its guidance also recognises that production systems will often need to fit into an existing application, use a custom interface or connect to live databases. That last point matters when copying content into a separate index would create a freshness problem.

The trade-off is straightforward. A hosted template gets a working experiment in front of users sooner. A tailored implementation gives you more control over sources, retrieval, models and integration, while adding engineering and maintenance work. Choose based on the uncertainty the pilot needs to resolve, not on which technology stack makes the grander demo.

Agent access needs a separate risk decision

The same NLWeb endpoint can serve people and software agents. That may increase its value, but it also changes the security boundary. The protocol specification leaves authentication, authorisation and rate limiting to the transport layer, so the implementation team remains responsible for those controls.

A public question-answering interface should not automatically share permissions with an agent-facing tool. Read-only access to published documentation is one thing. Exposing actions or personalised information is another. Scope, authentication, logging and failure behaviour need to be settled before an endpoint is offered to trusted agents.

Treat the pilot as a decision exercise

A useful feasibility pilot starts with a bounded content set and a representative collection of questions. First, audit the available Schema.org and RSS inputs. Remove duplicate or unsuitable material and agree which sources are authoritative. Then deploy one architecture, configure retrieval and model services, and test whether answers find the right sources, represent them accurately and show useful grounding.

The awkward cases matter most: ambiguous questions, missing answers, conflicting pages, stale information and requests outside the approved scope. Logs should reveal what users asked, what the system retrieved and where the answer went wrong. Without that evidence, a pilot is only a polished demo.

Greg can run a focused NLWeb pilot for a documentation site, directory, publisher or product catalogue. The useful output is not simply a working chat box. It is a recommendation based on content readiness, answer quality, access requirements and the effort needed to operate the service. Your website can answer questions now. It should only do so when those answers are useful, checkable and maintainable.