What is microdata?
Microdata is a format for marking up structured data in HTML code, in which attributes such as itemscope, itemtype, and itemprop label the visible content of a web page so that search engines can read it by machine. Microdata is part of the WHATWG HTML standard and is usually combined with the Schema.org vocabulary. Google processes microdata for rich results but recommends JSON-LD as the preferred format.

Term profile
| Attribute | Details |
|---|---|
| Part of speech | Noun, technical term from web development |
| Pronunciation | ˈmaɪkroʊˌdeɪtə |
| Specification | WHATWG HTML Living Standard, section 5 “Microdata” |
| Core attributes | itemscope, itemtype, itemprop, itemid, itemref |
| Usual vocabulary | Schema.org |
| Related formats | JSON-LD, RDFa |
| Other meaning | In statistics, unit-level data from surveys is also called microdata |
How does microdata work?
Microdata writes the meaning of a piece of content as an attribute directly onto the HTML element that displays that content. A browser renders the page unchanged. A crawler additionally reads from the same elements what kind of thing is being described and which property a given text carries. This creates structured data without a second data block next to the content.
The HTML standard defines 5 attributes for microdata:
- itemscope: Opens a new item, meaning a group of related properties. Everything inside the element belongs to this item.
- itemtype: Specifies by URL which type is being described, for example
https://schema.org/Bakeryfor a bakery. - itemprop: Names a property of the item. The value is the text content of the element, or for links and images the address from
hreforsrc. - itemid: Assigns a globally unique identifier to the item, as long as the vocabulary allows it.
- itemref: Pulls in properties from elements that sit outside the item elsewhere in the document.
Microdata itself does not define which types and properties exist. In practice the vocabulary almost always comes from Schema.org, which Google, Bing, and Yahoo launched jointly in 2011. The Schema.org getting started page still explains markup using microdata as its example.
What does microdata look like in HTML code?
You can recognize microdata in the source code by the itemscope, itemtype, and itemprop attributes on ordinary HTML elements. The following example marks up a fictional bakery with its name, phone number, and address:
<div itemscope itemtype="https://schema.org/Bakery">
<h2 itemprop="name">Bäckerei Sonnenkorn</h2>
<p>Telefon: <span itemprop="telephone">089 000000</span></p>
<div itemprop="address" itemscope itemtype="https://schema.org/PostalAddress">
<span itemprop="streetAddress">Lindenstraße 4</span>,
<span itemprop="postalCode">80331</span>
<span itemprop="addressLocality">München</span>
</div>
</div>
The address is an item of its own with the type PostalAddress, attached to the bakery through itemprop="address". This very nesting makes microdata hard to follow with larger amounts of data: Every level needs its own HTML element, and the structure of the data has to follow the structure of the layout.
The same information looks like this in JSON-LD:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Bakery",
"name": "Bäckerei Sonnenkorn",
"telephone": "089 000000",
"address": {
"@type": "PostalAddress",
"streetAddress": "Lindenstraße 4",
"postalCode": "80331",
"addressLocality": "München"
}
}
</script>
What is the difference between microdata, JSON-LD, and RDFa?
Microdata, JSON-LD, and RDFa carry the same Schema.org information and differ in where the markup lives. Microdata and RDFa sit as attributes on the visible HTML. JSON-LD sits as a separate data block in a script tag and is completely separate from the layout.
| Attribute | Microdata | JSON-LD | RDFa |
|---|---|---|---|
| Where the markup lives | attributes on the visible HTML | separate block in a script tag | attributes on the visible HTML |
| Typical attributes | itemscope, itemtype, itemprop | @context, @type, @id | vocab, typeof, property |
| Tied to the visible text | firmly | not at all | firmly |
| Nesting | through HTML levels | through JSON objects | through HTML levels |
| Insertion via JavaScript | only together with the content | on its own, read by Google | only together with the content |
| Status at Google | supported | recommended | supported |
Microdata is still widespread on the web. According to the HTTP Archive Web Almanac 2024, one in four pages carries microdata (26 percent of mobile pages). JSON-LD appears on 41 percent of mobile pages and has grown from 34 percent since 2022. A large share of the microdata in use comes from themes and store systems that hard-coded the format into their templates.
Why does Google recommend JSON-LD?
Google recommends JSON-LD because the format is the easiest to implement and to maintain over time. The Google Search Central documentation states that JSON-LD is the easiest solution for website owners to implement and maintain structured data at scale, and less prone to errors. Google gives 3 reasons:
- Separate from the visible text: A redesign or a new template does not damage the markup, because it is not attached to any single HTML element.
- Easy nesting: Connected information such as organization, address, and contact person can be expressed as JSON objects, independent of the layout.
- Can be inserted dynamically: Google also reads JSON-LD when a script writes it into the page during loading. What that means for indexing is explained in the entry on JavaScript SEO.
The format plays no role in rankings. Google states explicitly that all three formats are equally fine, as long as the markup is valid and follows the documentation of the respective feature. The testing platform SearchPilot reaches the same result from hundreds of customer tests, by its own account: Switching from microdata to JSON-LD has not shown a measurable effect on organic traffic in any test (as of September 2024). The requirement for rich snippets is the same in both formats: Complete required fields and information that matches the visible content.
When does microdata still make sense today?
Microdata makes sense when markup and content come from the same template and are meant to stay firmly together. Because every itemprop is attached to the displayed text, the markup cannot quietly go out of date. A price in the markup is always the price shown on the page. Microdata is therefore a good fit in 3 situations:
- Working existing setup: A theme or store system outputs valid microdata, and the Rich Results Test shows no errors. A rebuild brings no ranking gain here.
- Small static pages: A handful of details such as name, address, and opening hours that already sit next to each other in the template.
- Breadcrumbs in the template: The breadcrumb navigation already exists as a list in the HTML and can be marked up with a few attributes.
For knowledge graphs with many connected nodes, such as organization, people, services, and articles linked through @id, microdata is too cumbersome. This kind of markup, which visibility in AI answers also builds on, requires JSON-LD.
What happens when microdata and JSON-LD appear on the same page?
When microdata and JSON-LD describe the same thing on one page, Google reads both and, without a shared identifier, treats them as two separate objects. This often happens after switching plugins: The old theme keeps writing microdata into the HTML, and the new SEO plugin adds JSON-LD. A product page then contains two Product objects, in the worst case with different prices or ratings.
How quickly duplicate markup creates errors is something taismo measured on its own website in 2026. Two sources delivered the same breadcrumb list there under the same identifier. After the merge, a required field was missing at one position, and Search Console reported the error on 23 pages at first. The cause was two versions of the same object that contradicted each other.
The safe rule is therefore: Every entity is marked up in exactly one format. If you have to run both formats in parallel for a while, connect them through the same identifier, meaning itemid in microdata and @id in JSON-LD.
How do you switch from microdata to JSON-LD?
Switching from microdata to JSON-LD works in 4 steps that end in one shared deployment.
- Take stock: Google’s Rich Results Test and the Schema Markup Validator from Schema.org show for every page template which types are marked up as microdata.
- Build JSON-LD: For every template, a JSON-LD block is created with the same types and values. Global information such as the organization is defined once and only referenced by
@idon the subpages. - Remove microdata: The attributes disappear from the templates in the same deployment in which the JSON-LD block goes live. That way, duplicate markup is never online at any point.
- Check and monitor: Spot checks in the Rich Results Test, then follow the structured data reports in Google Search Console over several weeks.
Which schema types pay off for which page and how a connected @id graph is built is shown in the practical guide schema markup: types, setup, and testing. Whether your website still has old microdata leftovers next to JSON-LD is uncovered by an SEO audit.
Frequently asked questions about microdata
Is microdata bad for SEO?
No. Google fully supports microdata and treats valid microdata as equal to JSON-LD. Rich results depend on complete required fields; the format does not decide them.
Can AI systems read microdata?
Microdata sits in the HTML source code and can therefore be read by any crawler that fetches the page. Providers such as OpenAI or Perplexity do not disclose how much weight they give to structured data. Many AI crawlers do not execute JavaScript, so JSON-LD also belongs in the HTML on the server side.
Which tools can I use to check microdata?
Google’s Rich Results Test shows which rich results a page can generate. The Schema Markup Validator at validator.schema.org checks the markup independently of Google. Both tools read microdata, JSON-LD, and RDFa.
Welt der SEO lernen?