Microdata, briefly

The previous lessons covered tags that change behaviour for screen readers and the document outline. This lesson covers a different audience entirely: search engines and machines that scrape your page for structured data — the title and price of a product, the date and location of an event, the rating of a review.

You can mark any of those up so a search engine knows "this is a product, this is its price, this is its rating", and Google may then show your page with a star rating, a price snippet, or a date in the search results. Those richer search-result blocks are called rich results, and they often double click-through compared to a plain blue link.

Microdata is one way to do this. It is the older way — but it is the one that lives directly in your HTML, so it fits a course on semantic HTML.

schema.org and structured data

The vocabulary that Google, Bing, Yandex, and others all agreed on is called schema.org. It is a long list of types — Product, Recipe, Event, Person, Organization, Article, FAQ — each with a defined set of properties (name, price, ratingValue, datePublished).

When you add structured data to your page, you are saying: "this chunk is a Product, its name is X, its price is Y." The search engine reads it and maybe shows the price next to your link in results.

The same vocabulary can be expressed in three different syntaxes: microdata (HTML attributes inline), RDFa (similar inline attributes, different names), and JSON-LD (a JSON blob in a <script> tag in the head). All three describe the same schema.org types. We cover microdata here and JSON-LD in the html-document-and-meta course.

Microdata syntax

Microdata uses three attributes you sprinkle on existing tags:

• itemscope — opens a scope. "Everything inside is one item."
• itemtype — names the schema.org type. "This item is a Product."
• itemprop — labels a property. "This text is the product's name."

<article itemscope itemtype="https://schema.org/Product">
<h2 itemprop="name">Sourdough loaf</h2>
<img itemprop="image" src="/loaf.jpg" alt="A round sourdough loaf">
<p itemprop="description">A 24-hour wild-yeast loaf, baked Saturdays.</p>

<div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
  <span itemprop="priceCurrency" content="USD">$</span>
  <span itemprop="price">8.00</span>
  <link itemprop="availability" href="https://schema.org/InStock">
</div>
</article>

Reading top to bottom: the <article> opens an item scope of type Product. Inside, the <h2> is the product's name, the <img> is the image, the <p> is the description. The <div> opens a nested scope of type Offer (a price + availability), with its own price, priceCurrency, and availability properties.

A few details that catch people:

• itemprop always pairs with the content of the element. Text inside a <span> becomes the property's value; an image's src is the value; a link's href is the value.
• For property values that are not visible — say, you want the priceCurrency to be the code "USD" but you display "$" — use a <meta itemprop="priceCurrency" content="USD"> or content="USD" on the visible element.
• itemtype URLs are case-sensitive and use https://. https://schema.org/Product is right; http://Schema.org/product is not.

What you get for it

The reason to bother with structured data is that Google and other engines can use it to show richer search results. A short list of what you can earn:

• Product snippets — price, availability, rating, in-stock status appear next to the search result.
• Recipe cards — cook time, calories, star rating, and the recipe image at the top of search.
• FAQ rich results — your FAQ questions show as collapsible items right in the search result.
• Event listings — date, venue, ticket link.
• Breadcrumbs — your page's category path replaces the URL in search results.
• Article cards in Google News and Discover.

None of this is guaranteed — Google decides whether to show a rich result for a given query. But pages with valid structured data get them; pages without never will.

Microdata vs JSON-LD

Microdata is one of three formats. The other common one — and the one Google now recommends — is JSON-LD: a single JSON blob in a <script> tag, separate from the visible markup.

<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Sourdough loaf",
"description": "A 24-hour wild-yeast loaf, baked Saturdays.",
"image": "https://example.com/loaf.jpg",
"offers": {
  "@type": "Offer",
  "price": "8.00",
  "priceCurrency": "USD",
  "availability": "https://schema.org/InStock"
}
}
</script>

The same product, expressed as a JSON blob in the head. Search engines parse the script tag exactly the way they parse microdata — same vocabulary, different syntax.

Three reasons people prefer JSON-LD:

• It lives in one place — usually in the <head>, separate from the visible markup. No itemprop sprinkled across 50 elements.
• It is easier to generate from a CMS — your backend already builds JSON; emitting one more blob is trivial.
• It is what Google explicitly recommends for new sites.

Two reasons to still consider microdata:

• Single source of truth — the visible content and the structured data are the same elements. Update one, both update. With JSON-LD, you have to keep the JSON in sync with the page yourself.
• No risk of mismatch — a JSON-LD block can claim "$8" while the visible page shows "$10". Google penalizes that. Microdata makes it impossible by construction.

For most projects, JSON-LD is the modern default. Microdata is the right choice when keeping the visible page and the structured data in lockstep matters more than convenience.

A useful picture: microdata is sticky labels on every part of a real product on a shelf; JSON-LD is the printed product card the store keeps in the back. Both describe the same product. The labels stay in sync because they are on the thing; the card has to be reprinted every time the thing changes.