Structured data and JSON-LD

A JSON-LD block sits in the page code and is not shown on screen:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Volna electric kettle 1.7 l",
  "sku": "VLN-17-W",
  "brand": { "@type": "Brand", "name": "Volna" },
  "offers": {
    "@type": "Offer",
    "price": "24.90",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}
</script>

@context names the vocabulary, @type names the type of the entity. The rest are properties of that type. Case matters: Product and product are different words.

llms.txt and structured data work as a pair, at different steps. The first suggests where to go. The second explains where the machine has arrived. Neither replaces the other: An AI-ready site.

The value for AI is not limited to direct reading. AI search and agents often take facts from search engines, and those do read the markup.

The type is chosen by what is actually on the page.

QAPage and FAQPage are easy to mix up. The first is for a page where one person asks and others answer. The second is for a list of questions answered by the site owner.

A product page gives the markup the most work. It has a price and availability, they change, and a customer will see a mistake.

• The price in the markup equals the price on the page. Not “from”, not the old one, not the price for another region.
• The currency is a three-letter code. A machine will not parse a currency sign.
• Availability comes from stock records; it is not InStock for every product at once.
• A product without a price gets no Offer. An empty or zero offer is worse than a missing one.

When a product comes in sizes or colors, every variant has its own price, SKU and availability. Schema.org has ProductGroup for that: shared facts sit on the group, differences on the variants.

AggregateOffer does not fit variants of one product. That type describes offers from different sellers, and Google requires Offer for merchant listings.

gtin is the international barcode, mpn is the manufacturer’s part number. Systems use them to match the same product across stores.

They must not be invented. A barcode has a check digit, and a wrong value is worse than an empty field. A store’s own SKU is sku, not mpn.

Large platforms receive product data two ways: from a feed and from the page. When the two disagree, the platform notices.

• Google Merchant Center compares the feed with the page and can update price and availability from the markup by itself. Google notes that this is a safety net, not a replacement for updating the feed.
• Yandex gives the data in product page markup the highest priority over other sources.

The practical point: brand, barcode, color and size should come into the markup and into the feed from one product attribute.

• Markup describes what a person sees. A review, a price or an author in the markup is also on the page.
• Nothing is invented. No data, no property.
• The type matches the page. A category page is not a Product; an “About” page is not an Article.
• Entities are linked. An article points to its author and publisher, a product to its seller, a page to the site. @id is used for the links.
• One source. When both the site theme and an extension output markup, the machine gets two conflicting descriptions.
• Markup changes together with content. The price changed, so the markup changed.

Tool addresses and how to read the errors: Validating files and markup.

Almost every property already lives in the content management system: the product name, the price, the article date, the author. There is no reason to write markup by hand for each page. A site theme or an extension builds it.

What stays manual: deciding which attributes are the brand and the barcode, filling in the company card, and checking the result.