Why Schema.org is the common denominator
Every AI system that reads the web has the same problem: prose is ambiguous. "Now only 49.90!" could be a price, a discount, or last year's banner nobody removed. To turn a page into usable facts, machines look for structured data: a standardized, machine-readable block that says explicitly "this is a product, this is its price, this is whether you can buy it today." Think of the ingredients label on a jar. The shelf display can be as pretty as it likes; the label is what tells you what is actually inside.
The standard everyone agreed on is Schema.org: a shared vocabulary of fixed labels for things like products, prices and opening hours, maintained jointly since 2011. Google understands it, Bing understands it, and so do the crawlers, the programs that read websites on behalf of AI assistants and shopping agents. This is not a niche audience anymore: Gartner predicts that by 2030, 20% of digital commerce transactions will run through AI platforms. These labels usually travel in JSON-LD: a small script block in your page's code, invisible to human visitors, unambiguous to machines. One thing before you write a single line of it. The markup must be in the HTML your server sends. If your shop builds its pages in the browser first, read why most AI crawlers cannot read JavaScript, because markup that only appears after JavaScript runs might as well not exist.
Step 1: The Product markup, complete and honest
Here is a complete, valid Product block for a fictional shop. Every field in it earns its place. name, description and sku, which is simply your internal article number, identify the product. brand separates it from lookalikes. And offers carries the three facts every purchase decision needs: price, currency, availability.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Ceramic Pour-Over Set, 2 Cups",
"description": "Hand-glazed ceramic pour-over set with dripper, carafe and measuring spoon. Fits standard size 2 filter papers. Dishwasher safe.",
"sku": "CPO-2041",
"brand": { "@type": "Brand", "name": "Example Shop" },
"image": "https://www.example-shop.de/images/cpo-2041.jpg",
"offers": {
"@type": "Offer",
"url": "https://www.example-shop.de/products/ceramic-pour-over-set",
"price": "49.90",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.6",
"reviewCount": "87"
}
}
</script>One field needs a warning label: aggregateRating. Include it only if those 87 reviews actually exist in your shop and actually average 4.6. Invented or "rounded up" ratings are not a growth hack; they violate the guidelines of every platform that consumes this data, and an AI assistant will happily quote your fictional 4.9 stars to a customer who then finds three reviews on the page. If you have no reviews yet, leave the field out entirely. Absence is honest; fabrication is machine-readable lying.
Step 2: FAQ markup for the questions buyers actually ask
Product facts answer "what is it and what does it cost". The second thing buyers and their AI assistants ask is everything around the purchase: does it fit, how do returns work, how long is shipping. If those answers exist on your page as an FAQPage block, an assistant can answer them in your words instead of guessing:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "Does the pour-over set fit standard filter papers?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. The dripper takes standard size 2 filter papers, available in any supermarket."
}
},
{
"@type": "Question",
"name": "What is the return policy?",
"acceptedAnswer": {
"@type": "Answer",
"text": "You can return unused items within 30 days of delivery. Return shipping within Germany is free."
}
}
]
}
</script>The rule that governs everything here: the markup mirrors the visible page. The same questions and answers a human can read should appear in the block, no extras, no markup-only claims. Which brings us to the ways this goes wrong.
Step 3: The mistakes that actively hurt
The markup is added only after the page loads, by a tag manager (a tool that pushes scripts into finished pages) or an app. Testing tools that run JavaScript say everything is fine. The raw HTML that GPTBot and ClaudeBot read, the crawlers behind ChatGPT and Claude, contains nothing. Check with view source, not with a browser plugin.
The block says 49.90, the page says 54.90 after a price change that never reached the markup. Search engines treat systematic mismatches as cloaking, that is, showing machines something different than humans, and any agent that cross-checks stops trusting your data. No other mistake does more damage.
InStock in the markup, "sold out" on the page. An assistant recommends the product, the customer clicks, the shop disappoints. Availability changes more often than any other field, which makes hand-maintained markup rot fastest right here.
One template with a hardcoded aggregateRating, stamped onto every product. Now 300 products share the same 4.8 from 112 reviews, which is both a guideline violation and instantly recognizable as fake to any system that compares pages.
Step 4: Test what you shipped
Two checks, two levels of truth:
- Syntax: paste your product URL into the Schema.org validator or Google's Rich Results Test. They catch broken JSON, missing required fields and type errors.
- Reality: open the page, right-click, "View page source", and find the JSON-LD block. Is it there at all (see mistake 01)? Do price and availability match what the page visibly says? A validator cannot answer that; only comparison with the real page can.
If you want the same check across your whole shop instead of one page at a time, the free Klariton check reads your pages the way crawlers do and reports what is machine-readable and what is missing.
Step 5: Why this falls apart at 500 products
Everything above is perfectly doable for five products. At 500 products with weekly price updates, seasonal availability and a growing FAQ, hand-maintained JSON-LD is not a discipline problem, it is a structural impossibility. Every price change now has two places to update, and the second one is invisible when it is forgotten. That is precisely how mistakes 02 and 03 happen at scale: not through carelessness, but through architecture that requires humans to keep two copies in sync.
The only sustainable answer is generating the markup automatically from your shop data, the same source of truth that renders the page. There are several ways to get there: some shop systems and plugins cover basic Product markup, and shops with a custom-built frontend can generate it on the server. Klariton's Schema Export is built for exactly this job as well. It generates Product, FAQ and Service markup from your shop data and serves it where crawlers can read it: either on an agent-readable subdomain, an extra address of your shop reserved for machines, which you switch on without code, with a single line in your robots.txt, the small text file that tells crawlers what they may read. Or through your own server API, a direct interface from your own system, in around ten lines of code. However you get there, the goal is the same: one source of truth, zero hand-edited JSON, and markup that changes the moment your data does. That baseline is what agentic reach is built on. And if you sell services rather than products, the same playbook applies with even higher stakes: here is why service providers and B2B companies need structured data even more than shops.
Frequently asked questions
Where exactly does the JSON-LD go?
Into a script tag of type application/ld+json inside the HTML your server sends, ideally in the head of the page. The decisive test is view source: if the markup is visible there, crawlers can read it. If it is injected later by a tag manager or a JavaScript bundle, most AI crawlers will never see it.
Do I need markup on every single product page?
On every product you want AI systems to be able to find, compare and quote, which usually means all of them. That is exactly why hand-written markup does not survive contact with a real catalog. The sustainable version is generated automatically from your shop data, so every product gets correct markup and updates flow through without anyone editing JSON.
Can incorrect markup actually hurt me?
Yes. A price in the markup that differs from the visible page is treated as cloaking by search engines and erodes trust with every system that cross-checks. Invented or inflated ratings violate platform guidelines and, worse, get quoted back to customers who then compare them with reality. Wrong structured data is more damaging than none, because it is machine-readably wrong.
How do I verify my markup is correct?
Two levels. Syntax: paste the page URL into the Schema.org validator or Google's Rich Results Test and fix what they flag. Reality: open view source and check that the values in the markup match what the page visibly says, especially price and availability. Validators only check the first level; the second is where shops quietly go wrong over time.
Before you write a line of JSON-LD, see where you stand: the free Klariton check reads your pages the way AI crawlers do and shows which products are machine-readable, which markup exists, and where the gaps are.