How shops make their products readable for AI: structured data, step by step.
AI assistants and shopping agents do not admire your product photography. They read facts. The format they read most reliably is Schema.org markup in JSON-LD: a small data block in your page's source code that states name, price and availability in a way machines cannot misread. This guide shows what correct Product and FAQ markup looks like, which mistakes actively hurt, and what to do when you have 500 products instead of five.
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.
product page · in the server-delivered <head>
<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:
faqpage markup · buying questions
<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
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
Ask your question about Klariton.
Grounded in Klariton’s own knowledge, cited rather than invented.
How visible is your brand to AI?
The free AI visibility check shows you in under a minute how AI assistants see your shop today.