# What is microdata in SEO? Attributes, schema and Google > What HTML microdata is, how it is written with itemscope, itemtype and itemprop, what Google says compared with JSON-LD and how to check it in your store. URL: https://clione.ai/glossary/microdata/ Lang: en If you open the source code of a [product page](/glossary/product-page/) and see attributes like `itemprop="price"` scattered through the HTML, that is microdata: **[structured data](/glossary/structured-data/) written onto the same tags the customer reads**, instead of in a separate block. We are not talking here about statistical microdata, the files with the individual records of a survey, which share the name and a good share of the searches. They matter to you for two reasons: Google still reads them as structured data, even though it recommends another format,[^google-sd-intro] and if your store already has them, they coexist with any other markup you add. ## How it works The HTML standard defines microdata as a mechanism for adding to a document **nested groups of name-value pairs, in parallel to the content that already exists**.[^whatwg-microdata] There is no separate block: the data is in the tag that shows it. Five attributes do it:[^whatwg-microdata] | Attribute | What it does | | ----------- | ------------------------------------------------------------------------------------- | | `itemscope` | Creates an item: a group of name-value pairs | | `itemtype` | Says what type the item is, with a URL from the vocabulary | | `itemprop` | Names the property that tag provides | | `itemid` | Gives the item a global identifier, if the vocabulary allows it | | `itemref` | Adds to the item properties that are elsewhere on the page, citing them by their `id` | The value of each property comes from the tag according to its kind. On a `meta` it is its `content` attribute; on a `link`, its `href`; on a `time`, its `datetime`; on a `data`, its `value`; on the rest, **the text the tag contains**, which is what the visitor sees.[^whatwg-microdata] That last rule is what defines the format: in most cases, what the machine reads and what the person reads are literally the same thing. The words written in `itemtype` and `itemprop` are those of [Schema.org](/glossary/schema-org/). Its getting started guide, which teaches the vocabulary precisely with microdata, sums it up in three steps: `itemscope` marks the part of the page that talks about one thing, `itemtype` says what the thing is (for example `https://schema.org/Movie`) and `itemprop` labels each of its properties. An item can carry others inside it, like a movie's director described in turn as a person.[^schema-org-gs] Google supports three structured data formats. It describes microdata as an open HTML specification for nesting structured data within the content, with attributes on the tags, and [RDFa](/glossary/rdfa/) as an HTML5 extension that works in a similar way. It recommends the third, [JSON-LD](/glossary/json-ld/), which goes in a `script` tag and **is not mixed in with the visible text**.[^google-sd-intro] Recommending one is not discarding the others: well-made microdata markup works just as well for qualifying for [rich results](/glossary/rich-results/), and the [Rich Results Test](/glossary/rich-results-test/) reads JSON-LD, RDFa and microdata alike.[^rich-results-test] There is no need to rewrite it just because of the format. ## In a store A shirt's offer marked up with microdata. **Fictional example**: the store, the product, the image and the price are made up. ```html

Calella linen shirt, blue

Calella linen shirt in blue
$29.90 In stock
``` Three things the example shows. The first: the name is not written twice, because the text of the `h1` **is** the value of `name`. The second: the product carries a second item inside it, the offer, which is an [Offer](/glossary/offer-schema/) with its own `itemscope`; that is how types nest in this format. The third is the price. The customer sees "$29.90", but Schema.org asks for the price with a decimal point and no symbol, and the currency separately, with its ISO 4217 code,[^schema-org-offer] so the value for machines goes in `meta` tags, and availability, which in the vocabulary is a URL, in a `link`.[^whatwg-microdata] That has a cost. As soon as a value does not come from the visible text but from a `meta`, it can stop matching what the page shows, just like a forgotten JSON-LD block. And because the attributes live inside the template, **switching themes or rewriting a template can wipe out the markup without anyone deciding it**: the new HTML does not have to carry the same attributes. Using the `meta` tag to mark up what the page does not show. Schema.org proposes it for information the page conveys but does not write as text, like a rating shown drawn as stars, and in the same guide it asks to mark up only the content visible to someone visiting the page, not what sits in hidden blocks.[^schema-org-gs] Google says the same: nothing is marked up that the reader cannot see.[^google-sd-policies] ## How to check it 1. **Open the source code of a product page and look for `itemscope`.** If it shows up, the page carries microdata; the `itemtype` next to it tells you what type each item is. 2. **Also look for `application/ld+json`.** If the page carries both formats, check that they describe the same product with the same name, the same price and the same availability. 3. **Run the URL through the Rich Results Test.** It reads all three formats, tells you which rich results it detects and with what errors, and also accepts a pasted code snippet.[^rich-results-test] 4. **Review every `meta` and every `link` with `itemprop`.** They are the values that do not come from the visible text, and each one has to correspond to something the customer sees on the product page.[^google-sd-policies] 5. **Repeat the review after switching themes or templates**, because the markup travels with the HTML. ## Related concept: JSON-LD Microdata and JSON-LD write the same vocabulary; what changes is where the data lives. In microdata it is **inside the visible tags**, so the page's text is the value; in JSON-LD it is in a separate `script` block that is not mixed in with the text the user sees.[^google-sd-intro] The first makes it harder for the two to say different things, because they are the same text, and easier to lose the markup when touching the template. The second lets you change the markup without touching the layout, which is why Google recommends it,[^google-sd-intro] with the opposite risk: that the block falls behind when the page changes. To keep going, the [structured data reading path](/learn/structured-data/) puts the rest of the terms in order, and the guide to [auditing a product page's structured data](/guides/audit-product-page-structured-data/) walks through a product page property by property, in whatever format it has.