Schema is key for e-com revenue

Stop digging into reports.

Just Ask Ahrefs

Ahrefs AI assitant analyzes your questions and serves you the data you need for growth.

In June, Google dropped FAQ rich results. My LinkedIn feed was filled for the next two weeks with people declaring schema dead.

Then Alex Moss (Principal SEO at Yoast) published a piece in Search Engine Journal that I've been thinking about since + I saw his talk on this topic at Search’n’stuff in London.

He argues that the job of technical SEO is shifting from getting crawled to getting believed. He calls it data integrity.

I mostly agree with him. But he writes from a broad web angle, and most of you run big e-commerce catalogs. So here's how it looks from where we sit, plus what I'd tell a dev team to build this quarter.

Moss counts 9 structured data types that Google has stopped supporting for rich results in the past 2 years, with FAQ the latest.

Read the deprecation notice closely, though. Google removed a search appearance: the FAQ dropdown in the SERP, the report in Search Console and the check in the Rich Results Test. The notice says nothing about the markup being useless.

Moss's point is that schema has always done 2 jobs. One was cosmetic: stars, dropdowns, prices in the SERP. The other was comprehension, telling machines what a thing is and how it connects to other things. The cosmetic job is shrinking. The comprehension job is getting more important.

For e-commerce, the signal is even clearer. While FAQ was being retired, Google was adding properties to Product markup. That's the opposite of a schema being abandoned.

So if you ripped out your schema in a panic, I'd put it back.

This is the part of Moss's article that stuck with me most.

He says the biggest risk to your site is ambiguity. When a machine isn't sure what you are, it guesses. Guesses turn into hallucinations, and those build on each other - and it gets even more confusing when we’re talking about an AI crawling your site.

His line is roughly this: if an agent can misread you, sooner or later it will.

He cites an experiment by WordLift where big frontier models kept choosing a good story over the facts, while a small model with access to a knowledge graph did just as well. Structure beat size.

Here's what I'd add from the e-commerce side.

We've been fighting ambiguity for 10 years under other names.

Google has always had to pick one version when you give it several. A shopping agent has to pick too, except it might pick in front of a customer who's about to buy.

That's why I think "data integrity" is a useful label. It covers the technical cleanup we've always done and the clear entity setup we've been pushing for years, with Koray's framework behind a lot of it.

Being understood just matters more now.

Moss splits data integrity into 5 layers. Paraphrasing:

You control the first 4. The 5th is PR and reputation.

What I like about this model is the order. Layers 3 and 4 get the attention because they're new and shiny. Layers 1 and 2 decide whether any of it works.

Moss's article has a table of what he calls the agentic grounding stack. I counted 17 entries: llms.txt, agents.md, WebMCP, NLWeb, ACP, UCP, a couple of markdown serving methods, OKF, ARD and more. Most launched in the last 2 years.

The problem he points out is that nobody's agreeing on any of them.

XML sitemaps (2006) and schema.org (2011) happened because Google, Microsoft and Yahoo sat down together and agreed on a standard. Nothing like that is happening now. Even something as basic as whether to serve markdown versions of pages to AI is disputed, with Google on record cautioning against it.

His read is that AI companies have bigger things on their minds than SEO standards. I think he's right. Nobody's coming to tell us which of the 17 wins.

For a client with a 3-person dev team and a 200-ticket backlog, this matters a lot. Every hour spent on a protocol that dies next year is an hour taken from something that would've moved revenue.

Moss gives his own order of priority. Mine is close, with an e-commerce twist and a bit more impatience about dev time.

Mission 1: one product, one URL, one ID.

Canonical and parameter cleanup, the boring stuff. If a product can be reached at 5 addresses, fix that before you do anything with entity IDs.

Clean structure = clearing up the ambiguity

Mission 2: make the feed, the schema and the page agree.

This is the one I'd push hardest. Pull a sample of products. Compare price, availability, GTIN, and brand across your Merchant Center feed, your Product markup, and what's visible on the page.

Every mismatch is a fact a machine has to guess about. Moss says to audit the product feed before touching anything shiny. I'd go further and say the feed is where most catalogs are quietly lying to machines right now.

Mission 3: stable @ids and sameAs for the organization and brands.

Give your organization one ID and use it everywhere. Link out to Wikidata and your official profiles. Same for your own brands if you have them. It's cheap, and everything else builds on it.

Mission 4: add the new Product properties Google just extended.

This is low effort if your templates are in good shape, and it's where Google is still actively investing. They recently added CategoryCode and attributes for sales duration.

Mission 5: test how you're read.

Moss suggests NLWeb for checking whether your graph is interpreted the way you meant it. Even a basic version helps: ask a few AI assistants what your top products cost and whether they're in stock, and compare the answers to reality.

Park for now: markdown serving, WebMCP, the rest.

Here I'd go slower than Moss. He'd try WebMCP next and has already built these protocols into his personal site to learn how they work.

For a client's production, I'd wait until you have more resources. The exception is anything that costs close to nothing. If you're on Cloudflare, their Markdown for Agents feature is basically a switch.

Moss ends by saying rankings were the old success metric, and trust, accuracy, and validity are what we're earning now.

I like the idea. But your CFO doesn't have a line for "trust." Transactions and revenue still pay the invoices, ours included.

So I'd frame it this way: data integrity is how you protect transactions and revenue as more buying decisions pass through a machine first. It's worth doing because it keeps revenue from leaking, and you can measure that.

Stop waiting for the protocol war to end. It might not.

Build the layers every protocol reads from: clean URLs, stable entities, a feed that matches the page. Whatever wins in 2 years will read those first.

Want a quick check? Reply with your e-commerce domain. I'll tell you whether your structure, your schema, or more are causing the issues for agents and what it costs you.