← All articles

November 28, 2026 · 6 min read

Structured data explained: JSON-LD schema for rich results

A practical guide to JSON-LD schema markup, which types actually earn rich results, and how to validate them before they break silently.

Structured data explained: JSON-LD schema for rich results — cover illustration

A recipe site added Recipe schema to its top twenty pages and started showing star ratings, cook time, and calorie count directly in the search results within about three weeks. Click-through rate on those pages rose measurably even though their ranking position didn't move at all. Structured data doesn't change where you rank — it changes how much your listing stands out once you're there, and how much information a searcher gets before ever clicking.

What structured data actually is

Structured data is a standardized way of describing the content on a page — this is a recipe, this is its cook time, this is its rating — in a format search engines can parse directly rather than inferring from ordinary page text. JSON-LD is the format Google recommends, written as a single script block in a page's head or body, separate from the visible HTML content, which makes it easier to maintain than the older inline microdata approach.

Not every schema type produces a visible result

Adding schema doesn't guarantee a rich result will appear — Google decides independently whether to display one, and some schema types exist purely to help disambiguate content for search engines with no visible presentation change at all. FAQPage, HowTo, Recipe, Review, and Product schema are among the types most likely to produce a visible change in the search results; Organization and WebSite schema mostly help with knowledge panel and sitelink data instead.

FAQPage schema, done correctly

FAQPage schema needs each question and its exact visible answer marked up precisely as they appear on the page — Google has enforced this more strictly since 2023, and mismatched or hidden-answer implementations get rejected during validation, or accepted but never actually surfaced as a rich result. It's also worth noting Google restricted eligible sites for FAQ rich results in some categories, so test with the Rich Results Test rather than assuming markup alone guarantees the visual result.

Article schema and author information

Article and NewsArticle schema should include a headline, publish date, and author field with actual name data, not a placeholder like "Admin" or an empty string, since author information has become a more visible trust signal in how Google evaluates and sometimes displays content. Adding an author sameAs field linking to their real byline or profile page reinforces this signal further.

Product schema needs to match the visible page exactly

A common validation failure is Product schema declaring a price or availability status that doesn't match what's actually visible to a user on the page — Google's guidelines explicitly prohibit this kind of mismatch, and inconsistent product data has led to manual actions against some sites in the past. Keep pricing and stock status generated from the same data source that renders the visible page, not maintained as a separate hardcoded value in the schema block.

Validating markup before it goes live

Google's Rich Results Test checks whether your markup is both technically valid and eligible for a specific rich result type, which is a more useful check than generic JSON-LD syntax validation alone, since syntactically valid markup can still fail eligibility rules for a given result type. Run every new template through it before deploying broadly, not just a single sample page, since dynamic templates can render differently for edge-case content.

Nested and combined schema types on one page

A single product page can legitimately carry Product schema, Review schema for individual reviews, BreadcrumbList schema for navigation context, and Organization schema for the seller, all as separate JSON-LD blocks or combined into one @graph structure. Combining related types into a single @graph avoids duplicate declarations of the same entity and is generally easier to maintain than several disconnected script blocks scattered through a template.

Schema markup can silently break during a redesign

A site migration or template redesign frequently strips or duplicates JSON-LD blocks without anyone noticing immediately, since broken schema produces no visible error on the page itself — only a drop in rich result impressions inside Search Console days or weeks later. Adding a rich-results check to your standard pre-launch QA checklist catches this before it costs weeks of lost visibility.

Monitoring rich result performance over time

Search Console's Enhancements reports break out performance by specific schema type — FAQ, Product, Breadcrumb — separately from your overall Performance report, and are the fastest way to catch a sudden drop in valid items or a rise in markup errors after any template change. Checking these reports monthly, not just after a launch, catches drift that accumulates gradually rather than all at once.

Frequently asked

Does adding schema markup directly improve rankings? No — Google has stated structured data isn't a direct ranking factor, but the resulting rich results can meaningfully increase click-through rate, which is a real, measurable traffic benefit independent of rank.

Can I add multiple schema types to the same page? Yes, as long as each one accurately describes something genuinely present on the page — combining unrelated or inaccurate schema types to try to trigger multiple rich results is against Google's guidelines and risks a manual action.

How do I know if my schema is actually working? Check the Rich Results Test for eligibility, then monitor the relevant Enhancements report in Search Console over the following weeks to see whether valid items and impressions increase as expected.