Home/Blog/Structured Data & Schema.org

Structured Data and Schema.org: How to Earn Rich Results

Structured data doesn't directly move you up the rankings. What it does is make your page eligible for the richer search listings — star ratings, FAQs, breadcrumbs, recipes, events — that pull clicks away from the plain blue links around you.

Published 22 May 2026

Structured data is a machine-readable description of what a page is about, embedded in the page itself. A human reading your product page knows it's a product, with a price, in stock, rated four stars. A search engine has to infer that from the visible text and hope it gets it right. Structured data removes the guesswork: it states, in a vocabulary the search engine already understands, "this is a Product, the price is 49.00 AUD, the AggregateRating is 4.2 from 213 reviews."

The payoff is not a ranking boost. Google has been consistent on this for years — structured data is not a ranking factor the way links or content quality are. The payoff is rich results: the enhanced search listings that occupy more space than a standard result. A recipe with a photo and a star rating, an article with a thumbnail, a product showing price and availability, a breadcrumb trail instead of a raw URL. Those listings tend to earn a higher click-through rate, and CTR is the lever structured data actually pulls.

The Three Formats

There are three syntaxes for marking up structured data. They express the same Schema.org vocabulary in different ways.

Google recommends JSON-LD, and you should use it. The reason is practical: because the markup is a self-contained block rather than attributes woven through your template, you can generate it server-side and edit it without touching presentation. Microdata and RDFa entangle the data with the layout, so every template change risks breaking the markup. JSON-LD keeps the two concerns apart. Google will read all three; pick the one that won't rot.

Schema.org Vocabulary Basics

Schema.org is the shared vocabulary that all the major search engines agreed on. It defines a hierarchy of types (Thing → CreativeWork → Article, or Thing → Product) and the properties each type can carry. A JSON-LD block has three moving parts:

A Concrete Example

Here is the JSON-LD this article uses (every post on this site carries Article markup, and several carry FAQPage markup too). Note how author and publisher are nested Organization objects, not bare strings:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Structured Data and Schema.org: How to Earn Rich Results",
  "description": "A practical guide to structured data and Schema.org.",
  "datePublished": "2026-05-22",
  "dateModified": "2026-05-22",
  "author": {
    "@type": "Organization",
    "name": "ModusOp",
    "url": "https://modusop.app"
  },
  "publisher": {
    "@type": "Organization",
    "name": "ModusOp",
    "url": "https://modusop.app"
  },
  "mainEntityOfPage": "https://meta-tag-checker.com/blog/structured-data-schema-seo/"
}
</script>

An FAQPage follows the same shape but lists questions and answers as nested objects:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Does structured data improve rankings?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Not directly. It makes a page eligible for rich results, which can lift click-through rate."
    }
  }]
}
</script>

That's the whole mental model: pick a @type, fill the properties that match what's on the page, nest typed objects where the vocabulary expects them.

High-Value Schema Types

You don't need to learn the entire Schema.org vocabulary — it runs to hundreds of types. A handful cover most of the useful cases:

The Rules That Keep You Out of Trouble

Structured data is a description of the page, not a wishlist. The single rule that underpins everything: the markup must reflect content that is actually visible on the page. A few consequences worth internalising:

Follow Google's published content guidelines for each rich result type. They're specific about what's required and what's prohibited, and they're the document that gets cited when a manual action lands.

Eligibility Is Not a Guarantee

Valid markup makes your page eligible for a rich result. It never guarantees one. Google decides at query time whether to render the enhancement, based on its own assessment of quality, relevance, and the searcher's intent. You can have flawless, fully validated Product markup and still see a plain listing. Valid markup is a necessary condition, not a sufficient one — treat rich results as something you qualify for, not something you switch on.

A Note on Deprecated Types

The set of rich result types Google renders is not fixed — it changes, and not always in your favour. In 2023 Google substantially restricted FAQ rich results, limiting them to a small set of authoritative government and health sites, and largely deprecated HowTo rich results around the same time. Sites that had built their listings around those enhancements watched them quietly disappear.

The markup is still valid Schema.org and worth including for general machine-readability, but don't assume any given type still produces a visible rich result. Before investing effort in a particular enhancement, check Google's current Search Central documentation for which structured data features are actively supported. What was a reliable win two years ago may render nothing today.

How to Test and Validate

Three tools, each answering a different question:

  1. Google Rich Results Test. Paste a URL or a code snippet and it tells you which rich result types the page is eligible for, plus any errors or warnings specific to Google's requirements. This is the one that answers "will this earn an enhancement?"
  2. Schema Markup Validator (validator.schema.org). The vendor-neutral validator. It checks your markup against the Schema.org spec itself — broader than Google's view, useful for catching malformed JSON or invalid property names regardless of which search engine consumes it.
  3. Search Console "Enhancements" reports. Once a page is live and crawled, Search Console reports per-type coverage — how many pages have valid Product, Breadcrumb, FAQ markup, and which ones have errors. This is your ongoing monitor; the two testers above are for pre-launch checks.

Run new markup through the Rich Results Test before you ship it, validate the syntax with the Schema Markup Validator if anything looks off, then watch the Enhancements reports for drift after launch.

Where Meta Tags Fit In

Structured data lives alongside the rest of your machine-readable signals — the document head and the JSON-LD blocks beside it. It works in concert with your title tag, meta description, and Open Graph tags: the title and description shape the text of your listing, structured data shapes the enhancements around it, and Open Graph shapes how the page looks when shared. Separate systems, one shared job — making the page legible to machines.

That's why Meta Tag Checker surfaces JSON-LD presence among the other head elements when you run a page. A quick check tells you whether a page is even shipping structured data before you go deeper with the Rich Results Test — and it flags the title, description, canonical, and Open Graph tags in the same pass. If Meta Tag Checker reports no JSON-LD on a page that should have it, that's your first clue something didn't render.

The Production Habit

For new pages:

For existing sites:

Structured data is low-risk, moderate-effort, and occasionally high-reward. It won't lift your rankings, but a well-marked-up page that earns a richer listing quietly out-clicks the plain results sitting next to it — and that's a margin worth claiming.

Check your structured data

Meta Tag Checker surfaces JSON-LD presence alongside your title, description, canonical, and Open Graph tags — instantly.

Check Your Page →