Which Google rich results can your structured data win? Paste JSON-LD or fetch it from a URL — we detect the @types and check the required fields for each rich-result type.
One question, answerable: does your markup carry the required fields for each feature type. Everything past that — whether Google shows the feature on a given query, on a given device, for your particular page — is a judgement no external tool can read. Eligibility is the floor.
That distinction is worth holding onto, because it explains the most common complaint about every such tool: a green check next to a plain listing. The check was right and the feature still did not appear.
Passing means the page qualifies. Whether the feature appears is decided per query, per device, and against your page's overall quality. Google attaches a feature when it helps the searcher, not when your markup deserves it.
So a green check plus a plain result is not a bug. It is Google judging that stars, or a price, or an FAQ accordion would not make that particular search better.
Markup breaks in a way per-block checking cannot report. In August 2026 we audited our own site: 414 pages with structured data, 11 declaring the same page-level type twice. Each block was valid. The page still told Google two different things about one entity.
Why it happens. Two components each inject their own script tag — a page template and a shared partial, a CMS plugin and a theme. Neither author is wrong in isolation, and neither sees the other. The conflict exists only in the assembled page, which is why it survives every source-level review.
Stars, prices, FAQs, breadcrumbs, images in the listing — features Google may attach when a page declares structured data it trusts and the query is one where the feature helps. Both halves are required.
Perfect markup on a query that wants a plain link earns nothing, and no markup on a query begging for a price earns nothing either. Match the markup to what the query is actually asking for.
Nothing changes until the page is recrawled and reprocessed — days to weeks, depending on how often that URL is fetched. Submitting it in Search Console shortens the crawl half of the wait. The other half is Google's decision, and it has no queue you can join.
Re-test after the recrawl rather than the same evening, so you measure the fix instead of the cache.
Enter a URL above. The test reads the page's structured data and reports which rich-result types it qualifies for, plus the blocking errors.
Passing means eligible. Google decides per query and device whether the feature helps, and weighs page quality — eligibility is the floor, not a guarantee.
No. They change how the listing looks and how much it answers, which affects clicks. The ranking position itself is unaffected.
Only after the page is recrawled and reprocessed, which is days to weeks depending on how often that URL is fetched. Submitting the URL in Search Console shortens the crawl half; nothing shortens Google's own decision about whether the feature helps that query.
Yes, and each block stays valid while they do. When a page declares the same page-level type twice — two FAQPage nodes from two components, say — the page states two different things about one entity. We found that on 11 of our own 414 marked-up pages in August 2026. Per-block validation reports both as fine.
No tool can. This test answers a narrower, answerable question: does the markup carry the required fields for each feature type. Everything past that is Google's per-query judgement, which no external check has access to.
Checking whether the markup itself is well-formed is the JSON-LD validator — a wider net than eligibility. To see whether AI engines quote you by name, run the AI Overview checker.
A rich results test checks whether your JSON-LD structured data meets Google's per-type requirements — the required and recommended properties a type like FAQPage, Product, Article, or Recipe must carry to be eligible for a rich result. When fields are missing or malformed, Google shows a plain blue link instead of stars, prices, FAQs, or images, and AI engines that parse the same markup lose the explicit facts they would cite. Validating before you publish turns a silent eligibility failure into a fixable checklist.
An error is a missing required field that makes your item ineligible for the rich result entirely; a warning is a missing recommended field that still allows the rich result but limits how much it can show. Fix errors first, then clear warnings to widen the display.
No — passing means you are eligible, not guaranteed. Google decides per query whether to show a rich result based on page quality, relevance, and its own policies, so valid markup is necessary but not sufficient.
Yes — paste the raw JSON-LD directly instead of a URL, so you can validate and fix required fields while the page is still a draft. That is exactly what checking before you publish is for.
Google supports a fixed, evolving list, including Product, Article, Recipe, Review, Event, BreadcrumbList, and VideoObject. (Google removed HowTo rich results, and FAQ rich results now appear only for authoritative government and health sites.) The tool checks your @type against the requirements for these eligible types; a custom or unsupported type won't produce a rich result no matter how complete it is.
Free tools show you WHAT to fix. The full audit + the autonomous team of 20 AI agents fix it end-to-end — strategy, content, GEO, internal links, publishing and day-2 upkeep.
All free tools →cookies
The Matrix already knows everything about you — cookies are small change by comparison. The choice, as always, is yours: