# JSON-LD structured data for search and AI > What structured data, Schema.org and JSON-LD are, why a site prepared for search and AI needs them, and which markup fits a store, a blog, a forum and a knowledge base Page: https://llms-full-txt.ru/en/guides/json-ld/ Site index: https://llms-full-txt.ru/en/llms.txt Structured data is a description of a page written for a machine: what is here, what it is called, who wrote it, what it costs, whether it is in stock. A person reads that from the layout. A program has to be told directly. The shared vocabulary for it is [Schema.org](https://schema.org/), and the convenient way to write it is JSON-LD. Search engines read this markup and say so in their documentation. For a site prepared for search and AI it is a required layer, not decoration. ## Vocabulary, format and the data itself - Three different words - What is described - structured data - facts about the page in machine-readable form - In which words - Schema.org - a shared vocabulary of types and properties: Product, Article, price, author - How it is written - JSON-LD - a separate block of data in the page code - Microdata, RDFa - attributes inside HTML tags - One vocabulary, three ways to write it. Google recommends JSON-LD. ## What it looks like A JSON-LD block sits in the page code and is not shown on screen: ```html ``` `@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. ## Where it sits in the whole picture - What a machine learns at each layer - the entity, its properties and relations `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](https://llms-full-txt.ru/en/guides/ai-ready-site/). ## Who reads it **Confirmed** - [Google](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) uses structured data to understand the content of a page and recommends the JSON-LD format. - [Google Merchant Center](https://support.google.com/merchants/answer/3246284) reads the markup of product pages and uses it to update price and availability in product listings. - For product pages marked up as `Product` with an `Offer`, [Yandex](https://yandex.ru/support/webmaster/en/supported-schemas/strict-microdata-offers) gives the data in the markup the highest priority over other sources. - Both search engines run their own markup validators. **Not proven** - That a particular AI system reads the JSON-LD of other sites directly. Only the documentation of that system can settle it. - That markup increases the number of citations in AI answers. **What it does not mean** - Markup is not a condition for indexing: a page will be found without it. - Markup is not a ranking factor. It makes a page eligible for rich results; nobody guarantees they will be shown. 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. ## Which markup fits which site The type is chosen by what is actually on the page. | Site | Page | Schema.org type | Main properties | |---|---|---|---| | Any | every page | `WebPage`, `BreadcrumbList` | name, address, dates, the path from the home page | | Any | home page | `WebSite`, `Organization` | name, logo, contacts, address, social profiles | | Online store | product | `Product`, `Offer` | name, SKU, brand, price, currency, availability, rating | | Blog, media | article | `BlogPosting`, `Article`, `Person` | headline, author, publication and update dates, image | | Forum, community | discussion | `DiscussionForumPosting`, `Comment` | topic, author, date, comments, votes | | Questions and answers | a question with an accepted answer | `QAPage`, `Question`, `Answer` | the question, the answers, the accepted solution | | Knowledge base | an FAQ entry | `FAQPage`, `Question`, `Answer` | a question and the site owner's answer | | Photo gallery | photo, album | `ImageObject`, `ImageGallery` | file address, caption, dimensions, upload date | `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. ## An online store: the main example A product page gives the markup the most work. It has a price and availability, they change, and a customer will see a mistake. - What product markup consists of - a product - the name, as on the page - the seller’s SKU - barcode and manufacturer part number, when they exist - Brand: the brand name - image addresses - Offer: the offer - a number with a decimal point, no spaces and no currency sign - a currency code: USD, EUR, RUB - InStock, OutOfStock, BackOrder - the address of the product page - AggregateRating: the average score and the number of reviews - Review: reviews with an author and text ### Price and availability - 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. ### Product variants 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. ### Barcode and manufacturer part number `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`. ### Markup and the product feed Large platforms receive product data two ways: from a feed and from the page. When the two disagree, the platform notices. - One source, two outputs - The store catalog - price, availability, brand, barcode - Markup on the page - Product and Offer in JSON-LD - The product feed - the same product for Merchant Center - 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. ## Rules for any site - **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. ## How to check 1. Open the page source and find the `application/ld+json` block. It has to be in the server response, not added later by scripts. 2. Run the page through Google's [Rich Results Test](https://search.google.com/test/rich-results): which types were found and whether there are errors. 3. Run it through the Schema Markup Validator as well. 4. Compare the price, availability and name with what is on screen. 5. Make sure there is one markup: no second block of the same type coming from the theme. 6. Repeat on three or four different pages, not on one lucky page. Tool addresses and how to read the errors: [Validating files and markup](https://llms-full-txt.ru/en/guides/validation/). ## What can be automated 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.