Structured Data and Rich Results

What structured data is for

Search engines read your page as text and infer meaning. Structured data removes the inference: it states explicitly that this number is a price, this string is an author, this block is a set of steps.

The vocabulary is schema.org, created in 2011 as a joint project of Google, Microsoft, Yahoo and Yandex. It defines around 800 types and 1,500 properties covering everything from Recipe to MedicalCondition.

Two distinct benefits follow. The first is rich results: star ratings, FAQ accordions, recipe cards, event listings and breadcrumbs in the search listing itself, which measurably increase click-through. The second is entity understanding: helping search engines and, increasingly, AI-driven answer systems place your content correctly in a knowledge graph.

JSON-LD, Microdata and RDFa

Three syntaxes express the same vocabulary.

JSON-LD wins for a practical reason: it lives in one block, decoupled from your templates. You can add, change or remove it without touching markup, generate it server-side from the same data that renders the page, and read it at a glance when debugging. Microdata scatters attributes through the DOM where a designer will eventually delete them.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Build a Sitemap",
  "datePublished": "2026-08-02",
  "author": { "@type": "Person", "name": "Jane Doe" }
}
</script>

The types worth implementing

Note two changes worth knowing. Since August 2023 Google shows FAQ rich results only for authoritative government and health sites; the markup is still worth adding for entity understanding, but do not expect the accordion. HowTo rich results were retired entirely in September 2023.

Build any of these with the schema markup generator.

Connecting entities with @graph

Real pages describe several related things: an organisation, an author, a page, an article, a breadcrumb trail. Repeating the organisation inside every node bloats the markup and invites inconsistency.

The @graph construct solves this. Each node gets an @id, and other nodes reference it rather than duplicating it:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://example.com/#org",
      "name": "Example", "url": "https://example.com/" },
    { "@type": "Person", "@id": "https://example.com/#author",
      "name": "Jane Doe", "jobTitle": "Engineer" },
    { "@type": "Article",
      "headline": "How to Build a Sitemap",
      "author": { "@id": "https://example.com/#author" },
      "publisher": { "@id": "https://example.com/#org" } }
  ]
}

Using stable @id values consistently across your whole site is what lets a search engine build a coherent picture of your organisation and its authors, rather than treating each page as an isolated island.

Mistakes that get markup ignored or penalised

1. Marking up content that is not on the page. This is an explicit policy violation. FAQ markup for questions a user cannot see, or a rating that appears nowhere, can trigger a manual action.
2. Self-serving reviews. Since 2019, Google ignores aggregateRating that a business supplies about itself on Organization or LocalBusiness. Ratings must be genuinely collected from users.
3. Fabricated ratings. Inventing 4.8 stars from 340 reviews is straightforwardly deceptive and is the fastest route to a structured data manual action.
4. Wrong date formats. Use ISO 8601: 2026-08-02 or 2026-08-02T14:30:00+02:00. Anything else is silently discarded.
5. Missing required properties. Each rich result type has required and recommended fields. Missing a required field disqualifies the result entirely.
6. Relative URLs. Always absolute, with protocol and host.
7. Markup injected by client-side JavaScript. Google will usually render it, but server-side output is more reliable and other consumers may not execute your script at all.
8. Stale data. A price or availability that contradicts the page is worse than no markup.

Testing and monitoring

1. Rich Results Test. Google’s tool tells you which rich results a page is eligible for and flags missing required fields. It tests eligibility, not whether the result will appear.
2. Schema.org validator. Broader syntactic validation against the vocabulary, without Google’s eligibility filter. Useful for types Google does not use.
3. Search Console enhancement reports. The only view of your live site at scale. Errors here are real, on real pages, and worth acting on.
4. Automated checks in CI. Parse the JSON-LD from your rendered templates in a test and assert the required fields exist. Structured data breaks silently during refactors otherwise.

Structured data and AI answer engines

Structured data is increasingly consumed by systems other than the classic search listing: AI overviews, chat assistants, voice assistants and shopping aggregators. These systems benefit from unambiguous statements about what a page contains.

The practical implications are unglamorous and mostly the same as good SEO:

• State facts explicitly rather than leaving them to be inferred from prose.
• Use consistent @id values so an entity is recognisably the same across pages.
• Mark up authorship and dates so recency and expertise are legible.
• Keep markup and visible content in exact agreement — systems that detect divergence discount the source.

No amount of markup substitutes for content that genuinely answers the question. Structured data makes good content easier to use; it does not make thin content valuable.

Frequently Asked Questions