← Back to Blog

The same person built RSS, RDF, Schema.org, and NLWeb. That is mostly the whole story.

The same person built RSS, RDF, Schema.org, and NLWeb. That is mostly the whole story.

When NLWeb showed up at Microsoft Build, my first thought was the lazy one. Another spec. Another acronym. I almost closed the tab.

Then I noticed the name attached to it. R.V. Guha. And the lineup made sense in a way the keynote did not bother to spell out.

Four passes at one idea

Ramanathan V. Guha has worked on the same problem since the mid-1990s, in plain sight, across roughly four employers. The problem: a web page knows what it is. The clients reading the page do not. Some lightweight, parallel layer needs to carry that meaning so machines can use it without rendering and parsing the visible markup.

Each version of his answer has been thinner than the last, and aimed at a smarter consumer.

Apple, mid-1990s. Guha worked on the Meta Content Framework. MCF tried to give pages structured metadata that browsers could read. The browsers of 1996 had nothing to do with it. Right idea, wrong reader.

Netscape, late 1990s. The MCF ideas filtered into the W3C work that became RDF, and into the early channel formats that turned into RSS. RSS landed because it asked very little of webmasters and gave aggregators something concrete to consume. A short list of items, with structure.

Google, 2011. Guha helped lead the Schema.org launch with Google, Bing, Yahoo, and Yandex. Schema.org walked away from RDF's elegance toward something a non-specialist could ship: a flat shared vocabulary of types like Article, Product, Organization, FAQPage. JSON-LD became the carrier almost overnight because it sits inside a <script> tag and does not disturb the page.

Microsoft, 2025. Guha announced NLWeb at Microsoft Build. The pitch is recognizable if you have been watching: the schema markup, feeds, and structured content you already publish, exposed in a way an agent can query directly. NLWeb does not invent a new vocabulary. It invents a way to ask questions of the one you have already been writing.

The shape that keeps repeating

I find it useful to look at this as four passes, not four standards. Each pass meets the available reader where it actually is.

A 1996 browser could not act on metadata, so MCF was theoretical.

A 1999 portal or feed reader could act on a list of headlines plus URLs, so RSS shipped.

A 2011 search-engine indexer could act on flat type-and-property markup, so Schema.org plus JSON-LD shipped, and the web filled with rich snippets.

A 2025 agent can read schema, feed, and prose at the same time and answer a question against them. NLWeb is the layer that lets it ask without first having to render and scrape.

Looking back, the move is the same every time. Reduce what the publisher has to do. Push the inference cost onto the smarter reader. Wait for the reader to show up.

Why this matters if you have been doing the work

If you have spent the last decade adding Schema.org markup to clients, fixing FAQ schema parity, repairing dateModified fields, you have been doing exactly the work this layer rewards. The reason it pays out now is not that any single piece of markup got more important. It is that the reader on the other end finally got smart enough to use it without instructions.

That is not a strategy you reverse-engineer in a hurry. The sites that show up cleanly to NLWeb-style agents are mostly the ones that have been quietly shipping clean structured data the whole time.

A small clarification: JSON-LD is not JSON Schema

These get confused constantly because the words look almost identical.

JSON-LD is the JSON serialization of the linked-data ideas that grew out of RDF. Your <script type="application/ld+json"> block uses it. This is the carrier for Schema.org markup, and the format NLWeb-aware agents will be reading.

JSON Schema is a separate spec for validating the shape of arbitrary JSON. It is what API teams use to say "this payload must have these fields and these types." It comes from a different community and is not part of the Schema.org or NLWeb lineage.

If you are doing structured-data SEO and AEO, the one you care about is JSON-LD. If a backend engineer hands you a "schema" file for an API, that is JSON Schema, and it is a different conversation.

What to actually do this week

Three things, cheapest first.

  1. Audit your JSON-LD honesty. Pull a few representative pages and check that dateModified, author, brand, gtin, and the rest say what is actually true. Agents trust your structured claims more than your prose. They do not know the difference.

  2. Confirm you publish a real feed. RSS, Atom, or JSON Feed. The format matters less than the fact that one exists and is linked from <head>. Agents that index at scale prefer a structured stream to crawling your homepage.

  3. Run the readiness audit. The Agentic Commerce Readiness Audit scores NLWeb foundation as one of six sections. The Mega Analyzer's AI bucket and the Mega AEO Analyzer pick it up too, and each finding carries Fix, Audit, and Learn pill links.

If you have been the person on a team who actually shipped clean structured data for clients while everyone else was tracking keyword positions, you do not need to chase NLWeb. You finished most of the work years ago. The $20 Dollar Agency is the framing I use when I package this argument as a service offering for someone else's sites; same lineage, same payoff, same long horizon.

Related reading

Fact-check notes and sources

This post is informational, not technical-standards or historical advice. Mentions of Apple, Netscape, Google, Bing, Yahoo, Yandex, Microsoft, and individuals named are nominative fair use. No affiliation is implied. Specific authorship of historical web specifications is often shared across multiple contributors; this post uses "helped lead" or "worked on" framings rather than sole-credit phrasing. Consult the linked sources for full credit.

← Back to Blog

Accessibility Options

Text Size
High Contrast
Reduce Motion
Reading Guide
Link Highlighting
Accessibility Statement

J.A. Watte is committed to ensuring digital accessibility for people with disabilities. This site conforms to WCAG 2.1 and 2.2 Level AA guidelines.

Measures Taken

  • Semantic HTML with proper heading hierarchy
  • ARIA labels and roles for interactive components
  • Color contrast ratios meeting WCAG AA (4.5:1)
  • Full keyboard navigation support
  • Skip navigation link
  • Visible focus indicators (3:1 contrast)
  • 44px minimum touch/click targets
  • Dark/light theme with system preference detection
  • Responsive design for all devices
  • Reduced motion support (CSS + toggle)
  • Text size customization (14px–20px)
  • Print stylesheet

Feedback

Contact: jwatte.com/contact

Full Accessibility StatementPrivacy Policy

Last updated: April 2026