How to Check Structured Data for Rich Results

Last updated 2026-08-05

Structured data describes a page in a vocabulary machines already agree on, and it is what makes a result eligible for a richer treatment: breadcrumbs, review stars, recipe cards, event listings. Eligible is the operative word. Correct markup is a requirement for a rich result, never a guarantee of one.

Use JSON-LD

Three formats exist: JSON-LD, microdata, and RDFa. Google recommends JSON-LD, and it is easier to live with because the markup sits in one script tag instead of being woven through your HTML, so a designer changing the layout cannot break it.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Check Structured Data for Rich Results",
  "image": "https://example.com/cover.png",
  "datePublished": "2026-08-05",
  "dateModified": "2026-08-05",
  "author": { "@type": "Organization", "name": "Example Co" }
}
</script>

Three things have to be true

The syntax parses. One trailing comma or one unescaped quote takes the whole block out, silently.
The type has its required properties. Missing a required property removes eligibility for that feature.
The markup matches the visible page, and complies with Google’s structured data policies. Marking up content a reader cannot see is a spam signal, not a shortcut.

Required and recommended properties by type

The types below cover most of what small sites need. Required means Google will not consider the item for a rich result without it; recommended means the feature works but shows less.

Type	Required	Recommended
`Article`, `NewsArticle`, `BlogPosting`	`headline`	`image`, `datePublished`, `author`
`Product`	`name`	`image`, `description`, `offers`
`Offer`	`price`, `priceCurrency`	`availability`
`FAQPage`	`mainEntity`
`BreadcrumbList`	`itemListElement`
`Organization`	`name`	`url`, `logo`
`LocalBusiness`	`name`, `address`	`telephone`, `openingHours`
`Recipe`	`name`	`image`, `recipeIngredient`, `recipeInstructions`
`Event`	`name`, `startDate`, `location`	`image`, `endDate`

How to check a page

Find every block: document.querySelectorAll('script[type="application/ld+json"]').
Parse each one with JSON.parse. If it throws, nothing else about that block matters.
Flatten the structure. A block can be a single object, an array of objects, or an @graph wrapper, and each node inside carries its own @type.
For each node, check the required and recommended properties for its type.
Read the page and confirm every marked-up value is visible to a reader.
Confirm with Google’s Rich Results Test for eligibility, and the Schema.org validator for vocabulary correctness. They answer different questions.
After deploying, watch the enhancement reports in Search Console, which show what Google actually parsed across the site.

Mistakes that quietly remove eligibility

Markup for invisible content: an FAQPage on a page with no visible FAQ, or a rating nobody can see. This violates policy and can cost you more than the feature was worth.
Expecting FAQ rich results: in 2023 Google narrowed FAQ rich results to authoritative government and health sites. The markup is still useful for understanding, but most sites will not see the accordion.
Dates that are not ISO 8601: datePublished wants 2026-08-05 or a full timestamp, not "August 5, 2026".
Self-serving reviews: review markup for your own business on your own site is not eligible. Reviews have to be about something else, or collected independently.
A typo in @type: BlogPost instead of BlogPosting parses as valid JSON and matches nothing. Unknown types fail silently.
Contradictory blocks: a plugin and a theme both emitting an Article with different headlines. Consolidate into one block, ideally with @graph.
Unreachable images: an image URL blocked by robots.txt or returning 403 cannot be used, and image is required for several rich result types.
Markup injected after load: JSON-LD added by client-side script is read only if Google renders the page. Server-side output is safer.

Why valid markup still shows no rich result

Rich results are chosen per query and per result, and Google reserves the right to show none. Common reasons: the page is new and not yet reprocessed, the query does not warrant the feature, the page ranks too low for the treatment, the feature was restricted or retired, or a manual action applies to the site. Confirm eligibility with the Rich Results Test, then treat display as Google’s call, not a bug in your markup.

Common questions

Does structured data improve rankings?

Not directly. Google has said it is not a ranking factor in itself. What it does is make results eligible for richer presentation and help search engines understand entities on the page, and a richer result usually earns more clicks from the same position.

Should I use JSON-LD or microdata?

JSON-LD, unless you are maintaining an existing microdata implementation that already works. Google supports both, but JSON-LD keeps the markup in one place, is easier to generate and test, and does not break when someone edits the HTML around it.

Is more structured data always better?

No. Add markup for what the page genuinely is, and stop. Padding a page with types that do not describe it adds risk of policy violations and mismatches without adding eligibility for anything.

What is the difference between the Rich Results Test and the Schema Markup Validator?

The Rich Results Test tells you whether Google considers the page eligible for a specific rich result and reports the errors that block it. The Schema Markup Validator checks your markup against the schema.org vocabulary in general. A page can pass the second and still be ineligible in the first.