Structured Data: A Schema.org Guide That Stops at What Actually Works

Structured data is the part of SEO with the clearest cause and effect. You describe a page in a machine-readable vocabulary; search engines and AI answer engines use that description to display and cite the page more richly. There is no guesswork about whether it was implemented — either the markup validates or it does not.

The judgement is in choosing what to mark up and how to keep it consistent.

Format: JSON-LD, and nothing else

Three syntaxes exist — JSON-LD, Microdata and RDFa. Use JSON-LD. It lives in a <script> tag, separate from your markup, so changing a template does not silently break your schema and a designer reordering a section cannot invalidate it. It is also the format search engines recommend.

<script type="application/ld+json">
{ "@context": "https://schema.org", "@type": "Article", "headline": "..." }
</script>

The types that earn something

Dozens of types exist. A handful produce visible results:

Type	What it can produce	Use on
Organization	Knowledge panel, logo, sitelinks	Site-wide, once
WebSite	Sitelinks search box	Site-wide, once
BreadcrumbList	Breadcrumb path in results	Every page below root
Product + Offer	Price, availability, review stars	Product detail
Article / BlogPosting	Article rich result, Top Stories	Editorial content
FAQPage	Expandable Q&A	Pages with genuine Q&A
HowTo	Step-by-step result	Instructional content
LocalBusiness	Map, hours, directions	Physical locations
VideoObject	Video thumbnail	Pages with video
Event	Date, venue, tickets	Event pages

Start with Organization, WebSite and BreadcrumbList. They apply to every site, take an afternoon, and they are the foundation the rest attaches to.

Build one graph, not five snippets

The common mistake is scattering independent blocks across a template — an Organization block in the header partial, an Article block in the content partial, a Breadcrumb block in another. They do not know about each other, the publisher is described twice with slightly different values, and nothing links together.

Emit one graph per page using @graph and @id:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example",
      "url": "https://example.com/",
      "logo": { "@type": "ImageObject", "url": "https://example.com/logo.png" }
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/post#article",
      "headline": "Post title",
      "datePublished": "2026-09-09",
      "dateModified": "2026-09-09",
      "inLanguage": "en",
      "isPartOf": { "@id": "https://example.com/#website" },
      "publisher": { "@id": "https://example.com/#organization" },
      "author": { "@id": "https://example.com/#organization" }
    }
  ]
}
</script>

Each entity is declared once and referenced by @id everywhere else. One publisher definition, one place to change it, and a graph a machine can actually traverse.

The rules that decide whether anything appears

Markup must match visible content. This is the rule that gets sites penalised. A Product with a price the page does not show, an aggregateRating with no visible reviews, or a FAQPage whose questions are not on the page — these are policy violations, and the consequence is losing rich results across the whole site, not just that page.

Mark up the primary entity of the page. A product detail page is a Product. An article is an Article. Do not mark up every related item as a full entity.

Fill the required properties, then the recommended ones. A Product without name and offers produces nothing. Add brand, sku, image, description and you get a fuller result.

Use ISO 8601 dates. 2026-09-09T10:00:00+09:00, not September 9, 2026.

Absolute URLs everywhere. Relative URLs in JSON-LD are unreliable.

Rich results are never guaranteed. Valid markup makes a page eligible. Whether a rich result is shown is the search engine's decision, based on query and page quality.

Structured data and AI answer engines

There is a second audience now. Generative search systems parse pages to compose answers, and explicit structure makes a page far easier to extract and cite accurately.

FAQPage is the clearest example: a question and its answer, explicitly paired, is exactly the shape an answer engine wants. Article with datePublished and author supports attribution. BreadcrumbList tells the system where the page sits, which helps it describe the source. None of this is a ranking trick — it is the difference between being quoted correctly and being paraphrased into something you did not say. Optimising for AI search goes further into that.

Validating and maintaining

Three checks, in order:

1. Schema.org validator — is the vocabulary itself correct?
2. Google Rich Results Test — is this page eligible for a rich result?
3. Search Console enhancement reports — what is happening across the whole site over time?

The maintenance problem is drift. A price changes in the CMS but the hard-coded JSON-LD does not. A template is refactored and the author field disappears. Two rules prevent it: generate structured data from the same data source that renders the page, never by hand, and crawl your own site periodically to check that every template still emits what you expect. Our crawler collects JSON-LD types per page, which makes "which templates lost their Product markup after the release" a one-line diff rather than a manual audit.

FAQ

Does structured data improve rankings?

Not directly. It makes pages eligible for richer presentation, which raises click-through. The traffic gain is real; the ranking claim is not.

Can I mark up content that is hidden behind a tab?

If the content is present on the page and accessible by interaction, generally yes. If it does not exist on the page at all, no — that is the content-mismatch violation.

How much markup is too much?

Mark up the main entity and its genuine components. Ten disconnected types on one page is a signal of confusion rather than richness, and it dilutes which entity the page is actually about.

Do FAQ rich results still appear?

Their visibility has been reduced for many query types, but FAQPage markup is still worth adding where the Q&A is genuine: it clarifies the page for AI answer engines and costs almost nothing. Do not manufacture fake questions for it.

Should I use Microdata if my CMS generates it?

You can leave existing Microdata in place, but do not maintain both. Two sources of truth drift, and a conflict between them is worse than either alone.