Schema Markup Explained: What It Is and How to Generate It

What schema markup actually is

Schema markup is structured data — usually a <script type="application/ld+json"> block in a page's HTML — written in a shared vocabulary (schema.org) that tells search engines exactly what a piece of content is, instead of leaving them to infer it from plain text. A recipe, a product, an FAQ, a review, an event: each has its own schema type with its own expected properties, and a search engine that can read the markup doesn't have to guess.

What it does — and what it doesn't

Schema markup does not directly boost rankings. Adding it to a mediocre page won't make it outrank a better one. What it does do is make a page eligible for rich results — star ratings on a product, a recipe card with a photo and cook time, an FAQ dropdown right in the search result, breadcrumb trails instead of a raw URL. None of that changes the ranking position directly, but a richer, more visually distinct result at the same position reliably earns more clicks.

It's worth distinguishing this from the title and meta description, which control the plain-text headline and snippet every result gets by default. Schema markup only changes the result's presentation when it qualifies for a specific rich-result type — the two aren't alternatives, they stack, and a page missing either one is leaving a distinct, separate opportunity on the table.

Schema types most sites can actually use

• Article — for blog posts and news content.
• Product — price, availability, and review data for e-commerce pages.
• LocalBusiness — address, hours, and contact info for local search.
• Review and AggregateRating — star ratings shown directly in results.
• BreadcrumbList — shows a page's site hierarchy instead of its raw URL.

A note on FAQPage: this type used to render an expandable question list directly in search results, but Google retired the FAQ rich result for all sites in May 2026. Marking up a genuine Q&A section with FAQPage is still valid, accurate structured data — it just no longer earns the visual SERP treatment it used to. If your only reason for adding it was that rich result, it's not worth the effort anymore; if the page already has real, substantive Q&A content, the markup itself does no harm.

A broken Product schema, fixed

Structured data errors are usually small and easy to miss reading top to bottom. Here's a Product block with two real problems:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Runner X2"
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD"
  }
}

A missing comma after "Trail Runner X2" breaks the JSON parser entirely — the whole block fails, not just that line — and even once the syntax is fixed, this Offer is missing price and availability, both required for Product rich-result eligibility. Fixed:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Trail Runner X2",
  "image": "https://example.com/trail-runner-x2.jpg",
  "offers": {
    "@type": "Offer",
    "price": "129.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

Valid JSON, and every property Google's Product rich-result documentation actually requires is present — image, price, and availability alongside the name. This is the difference between markup that's technically present and markup that actually qualifies for anything.

5 schema markup mistakes

How Google actually reads a JSON-LD block

A common misconception is that structured data has to mirror the visible page layout exactly, in the same order. It doesn't — JSON-LD is parsed independently of the rendered DOM, as a separate data document that happens to live inside the page's HTML. That's exactly why it works well for describing things that don't map cleanly to a single visible block, like an event with a separate venue address, or a product with variant-specific pricing spread across a page's UI. The one hard rule, covered above, is that everything in the markup has to be substantively present somewhere on the page for a visitor to see — Google's guidelines call this "structured data must reflect the page's visible content," not "in the same DOM order as the markup."

For a page that's genuinely more than one entity — a product page that's also part of a breadcrumb trail, sitting inside an organization's catalog — multiple schema types can coexist using @graph, an array of separate typed objects in one JSON-LD block instead of forcing everything into a single nested structure. Most single-purpose pages don't need this; it's worth knowing about mainly so a page with a Product block and a separate BreadcrumbList block isn't mistaken for an error — two valid, independent types can legitimately sit side by side.

Validate what you generate

Once markup is live, run it through the Schema Markup Validator to confirm it parses and every required property is present — generating correct JSON-LD and confirming it stayed correct are two separate steps, and skipping the second one is how schema quietly breaks after a redesign.

Schema is additive, not a substitute for the page itself

It's worth stating plainly: no amount of correct structured data compensates for a page that doesn't actually answer what it claims to. Schema tells Google what a piece of content is, not that the content is good — a Product block on a page with a vague, unhelpful description doesn't make that description any more useful, it just labels it more precisely. Treat schema as the last step in publishing a page, applied to content that's already worth indexing, rather than a shortcut that makes weaker content perform better than it otherwise would.

Generate yours now

CheckSEO's Schema Markup Generator builds ready-to-paste JSON-LD for Article, Product, LocalBusiness, Event, Review, HowTo, and more — no need to hand-write the syntax.