Languages

Rich-Result Eligibility Checker

Free, no signup. Valid schema doesn't tell you what actually shows up in the SERP — eligibility does. Paste your structured data, a full HTML page, or fetch a live URL, and for every rich-result type Google supports, this names whether the page is eligible, or the exact required field standing in the way.

Built by Patrick Stox

or fetch a live URL

Client-rendered (JS-only) markup won't be seen when fetching a URL; paste it in that case.

compare with a competitor URL

Runs entirely in your browser — nothing you paste is uploaded or stored. Fetch a live URL sends only that address to our server to retrieve the HTML; extraction and checking still happen in your browser. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Rich Result Eligibility? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
   
 
Sample report
 
Say you paste this graph — a Product offer missing its price, plus an FAQPage:
 
 
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Product",
      "name": "Trailhead Running Shoe",
      "image": "https://example.com/shoe.jpg",
      "brand": { "@type": "Brand", "name": "Example" },
      "offers": { "@type": "Offer", "priceCurrency": "USD" }
    },
    {
      "@type": "FAQPage",
      "mainEntity": [{
        "@type": "Question",
        "name": "Is it fast?",
        "acceptedAnswer": { "@type": "Answer", "text": "Yes." }
      }]
    }
  ]
}
 
 
…and it returns cards like these:
 
Example data — captured by running this page's own checker against the JSON-LD above
 
 
 2 rich-result types detected 1 field away 1 unavailable 
 
 
 
Product snippet
✗ Not yet eligible
 
Product · required 2/3 · recommended 3/8
 
Required — blocks the rich result
 
     
  • ✗ Needs an offer price (offers.price or offers.priceSpecification.price)Add price or priceSpecification.price to the Offer.
    •  
 
 
Recommended — improves the result
 
     
  • ⚠ Add description
    •  
  • ⚠ Add sku
    •  
  • ⚠ Add offers.availabilityMerchant listing experiences use availability.
    •  
  • ⚠ Add review
    •  
  • ⚠ Add aggregateRating
    •  
 
 
Google docs → requirements verified 2026-07-12
 
 
 
FAQ
Retired
 
FAQPage · required 0/0 · recommended 0/0
 
Google stopped showing FAQ rich results on May 7, 2026 and removed the feature documentation. FAQPage remains valid schema.org markup, but it no longer produces a Google Search rich result.
 
Google update → requirements verified 2026-07-12
 
 
 
 
     
  • The one blocking field is an offer price, not a review — this Product has an
            Offer and a currency code but no price or priceSpecification.price,
            so it's one field away: 2 of 3 required checks are already met.
            See what the badges mean ↓.
    •  
  • Five recommended fields are still open (description, sku, availability, review,
            aggregateRating) — none of them block eligibility, but each strengthens the result Google might draw.
    •  
  • FAQ is valid markup but Retired, so no required-field checklist is shown at
            all — Google no longer shows the enhancement on any site, no matter how complete the markup is.
    •  
  • Clearing the one required field is not a guarantee — eligibility only means the
            page cleared Google's documented bar; Google still decides whether to draw the result. Compare
            against the Schema Validator if the underlying JSON-LD
            itself needs checking first.
    •  
 
 
 
How to use it
 
     
  1. Choose an input mode. Auto-detect figures out whether you pasted
            JSON-LD or an HTML page; or force JSON-LD / HTML page
explicitly.
    2.  
  2. Paste your structured data into the box — a JSON-LD block, or a full HTML document with
            its <script type="application/ld+json"> tags. Or skip pasting: enter a
            live URL in the fetch a live URL row and press Fetch & check.
    3.  
  3. Press Check eligibility. Not sure what output looks like? Hit
Try an example to load a sample graph and run it.
    4.  
  4. Read the summary line, then the per-type cards. Fix anything marked
required first — those block the rich result — then work through the
            recommended fields.
    5.  
  5. Use Copy shareable link to hand the exact input and result to a
            teammate; the markup is packed into the URL, nothing is stored.
    6.  
 
 
 
       
     
     
 

Need to build or fix the markup?
Schema Generator scaffolds it ·
Schema Validator checks syntax & vocabulary in depth.

 
 
← All free tools
  
 
What the results mean
 
The summary line tallies the detected rich-result types, then each type gets a card with a badge:
 
     
  • ✓ Eligible (green) — every documented required field and one-of
            group is present. The page has cleared Google's requirements bar for that feature.
    •  
  • ✗ Not yet eligible (red) — one or more required fields are
            missing. The card lists exactly which, with a short "add this" hint. This is your fix list.
    •  
  • Restricted (grey) — valid markup, but Google limits the feature to a
            documented subset of sites. It will not draw the rich result for most sites.
    •  
  • Deprecated / Retired (grey) — the feature was removed from Search (e.g.
            HowTo) or retired (e.g. the sitelinks search box). The card names the status instead of
            nagging about fields for a dead feature.
    •  
 
Inside a card, items are split into two tiers:
 
     
  • Required — blocks the rich result: missing required properties, and
            "needs one of" groups where at least one of several properties must be present. Any of
            these unmet means not-yet-eligible.
    •  
  • Recommended — improves the result: fields Google suggests to enrich or
            stabilise the enhancement. Absent ones never block eligibility.
    •  
 
Each card also shows required X/Y and recommended X/Y counts, the
        matched schema.org type, the node's @id, and a dated "requirements verified" note.
 
How it works
 

This tool extends the Schema Validator
rather than forking it: parsing, HTML extraction, and @id graph resolution are
          reused wholesale. The new layer is the eligibility diff — it walks each node's type ancestry,
          matches it to the Google rich-result features that apply (most-specific type wins, so a Recipe
          is judged as a Recipe, not as its HowTo base), then checks each feature's required and
          recommended properties against a curated requirements table mirrored from Google's docs.

 

Paste mode (JSON-LD or full HTML) runs entirely in your browser — no network
          call. URL mode reuses a shared, SSRF-guarded, rate-limited fetch proxy to pull the page HTML
          server-side; extraction and the eligibility check still run client-side. Property lookups
          follow dotted paths through nested objects and @id references, and a value only
          counts as present if it carries real content (an empty string or empty object does not).

 
Features
 
     
  • Per-feature verdicts: for every detected type, eligible or the exact required field
            blocking it — plus the recommended fields worth adding.
    •  
  • Three inputs: paste JSON-LD, paste a full HTML page, or fetch a live URL server-side.
    •  
  • Auto-detect mode that tells JSON-LD from HTML for you.
    •  
  • Handles @graph markup and @id cross-references, resolving values
            across linked nodes exactly like the validator.
    •  
  • Most-specific type matching, so a subtype is scored against its own feature, not its base.
    •  
  • Honestly labels restricted, deprecated, and retired features instead of pretending they
            still draw a result.
    •  
  • Dated "requirements verified" stamp and a rules version on every run, so you can see how
            current the table is.
    •  
  • Shareable-link output that packs the input into the URL fragment — nothing stored.
    •  
 
Limitations
 
 Eligibility is not display. Meeting every required field clears Google's
          requirements bar, but Google alone decides whether to draw a rich result, based on quality,
          query, device, and its own filters. This tool cannot predict that.

 

It checks the rich-result features backed by a documented requirements table, so a niche or
          brand-new feature may not appear. It reads the structured data present in the markup:
          data injected by client-side JavaScript is invisible in URL and HTML modes — paste it directly.
          And the requirements table is a curated mirror of Google's docs at a point in time; Google can
          change requirements between updates, which is why every card carries a verified date.

 
Frequently asked questions
 
Does being eligible mean my rich result will show?
No. Eligibility means the page meets Google’s documented required fields for that feature, which is the price of admission — nothing more. Google still decides case by case whether to show a rich result, based on page quality, query, device, and its own manual and algorithmic filters. A page can be perfectly eligible and never earn the enhancement. This tool tells you whether you have cleared the requirements bar, not whether Google will draw the result.
Why does the checker say I am missing a required field when the Schema Validator passed?
They answer different questions. The Schema Validator checks whether your JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. is valid and uses real schema.org vocabulary. This checker diffs your markup against Google’s per-feature requirements table — the specific properties Google requires for a given rich result. Markup can be flawless schema.org yet still miss a Google-required field (for example a Product with no price or no review), so it validates cleanly but is not yet eligible.
Why does my FAQ show as "Retired" instead of eligible?
Google stopped showing FAQ rich resultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. on May 7, 2026 and later removed the feature documentation. FAQPage remains valid schema.org markup and may still help other consumers of structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding., but it no longer produces a Google Search rich result. The tool reports that as Retired rather than pretending the enhancement is still available.
Can it check a live URL, or only pasted markup?
Both. Paste JSON-LD or a full HTML page, or enter a URL and the tool fetches the page HTML server-side and extracts its structured data in your browser. Because extraction runs on the fetched HTML, structured data injected by client-side JavaScript will not be seen — paste it directly in that case.
Which rich-result types does it check?
It covers the Google Search features backed by a documented requirements table — Product, Article, Recipe, Event, Video, JobPosting, Breadcrumb, Organization, Q&A, and more. It also recognizes retired features such as FAQ and the sitelinks search box, labeling them instead of silently ignoring them. Types with no Google rich result (or none we track) are listed under "no qualifying markup" instead of getting a card.
 
 
 
   
Rich-result requirements last reviewed Jul 12, 2026.
 
Next stepSchema Markup Generator — generate the corrected version.

People also explore
ToolSchema Markup ValidatorToolEntity Coverage AnalyzerToolGoogle Knowledge Graph ExplorerArticleItemList SchemaArticleLocalBusiness SchemaArticleJobPosting Schema
 
 
 
Feature requests for Rich Result Eligibility
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
     
 
Where this tool helps
Common use cases
Find the required field blocking a supported result
Compare detected markup with the documented requirement set and prioritize missing required properties before recommended enhancements.
Separate schema validity from feature eligibility
Use the eligibility layer after syntax and vocabulary checks so valid schema.org markup is not mistaken for a complete Google feature implementation.
Identify retired or restricted enhancements
Keep valid markup for other consumers while avoiding implementation work based on a Google feature that is retired, deprecated, or limited to specific sites.
Compare two public implementations
Fetch two fictional raw-HTML pages and compare their per-feature requirement status without turning the table into a ranking or CTR claim.
Create a current implementation handoff
Share the bounded input, open a near-miss type in Schema Generator, and preserve the rule version, verified date, and display disclaimer.
Watch the full workflow
Rich-Result Eligibility Checker walkthrough
Read the transcript

      
      

        
Rich-Result Eligibility Checker

        

        
This beginner walkthrough explains what rich-result eligibility means, checks the built-in fictional example, and reads four different outcomes: a Product that meets its required checklist, a Recipe missing one required field, an Organization with no required fields in this table, and a retired F-A-Q feature. Then we will compare two fictional Product pages and cover what to do next.

      

      

        
Step 1

        

        
Structured data is machine-readable information added to a page. Google can use some types to create enhanced search displays called rich results. This checker compares the detected types with the dated Google requirement tables it tracks. It shows missing required fields, optional recommended improvements, and unavailable features. It does not promise that Google will display anything.

      

      

        
Step 2

        

        
Use it to find the required field blocking a supported feature, avoid confusing valid schema with a complete feature implementation, spot retired or restricted enhancements, compare two public pages against the same checklist, or create a dated handoff for developers. Eligibility is not a ranking, traffic, or click-through prediction.

      

      

        
Step 3

        

        
Paste J-S-O-N-L-D, which is a common structured-data format, or paste a complete H-T-M-L page. Auto-detect chooses between them, while the tabs can force a mode. Pasted input runs locally. U-R-L mode fetches a public page’s raw H-T-M-L through a guarded service, and the optional second U-R-L creates a side-by-side requirements comparison. It does not render JavaScript.

      

      

        
Step 4

        

        
Select Try an example. The fictional structured-data graph is checked entirely in the browser. Four cards appear: Recipe, Organization, Product snippet, and F-A-Q. Keeping these separate matters because one page can contain several types with different outcomes; there is no honest single pass-or-fail label for the whole graph.

      

      

        
Step 5

        

        
The summary finds four tracked types: two eligible, one not yet eligible, and one unavailable. Treat this as a table of contents. Each detailed card identifies the matched item, counts required and recommended fields, explains the status, links to documentation, and shows when those requirements were verified.

      

      

        
Step 6

        

        
Recipe is not yet eligible. It has the required name but is missing the required image, so it passes one of two required checks. Thirteen recommended fields are also missing, but recommendations do not block this baseline. Add a truthful image of the finished dish first, then decide which recommendations genuinely describe the recipe.

      

      

        
Step 7

        

        
Product snippet meets all three required checks in this baseline: name, image, and an offer price. Six recommended properties remain, including price currency and availability. The sample search-result card is only an illustration, not a prediction. Other Google shopping experiences may use different or additional requirements.

      

      

        
Step 8

        

        
Organization is labeled eligible because this tracked table has zero required properties. Its name and U-R-L satisfy two recommendations. That does not predict a knowledge panel or another specific search display. Add the remaining optional fields only when they are accurate and useful for the organization.

      

      

        
Step 9

        

        
F-A-Q Page can still be valid schema dot org markup, but this card is retired instead of eligible. Its dated note says Google stopped showing F-A-Q rich results on May seventh, twenty twenty-six. The tool does not invent a missing-field checklist for a feature its source table marks unavailable.

      

      

        
Step 10

        

        
This run uses rules version twenty twenty-six dash zero seven dash twelve and warns that Google can change requirements without notice. Every card also shows a verified date and documentation link. Keep those dates with the result so the next reviewer knows exactly which checklist was applied.

      

      

        
Step 11

        

        
Copy shareable link puts the exact pasted input and selected mode in the link after the hash sign. The share workflow does not store it on the server, and inputs that are too large are rejected. Use this for small, non-sensitive review cases. Do not place private data or an unnecessarily large page inside a share link.

      

      

        
Step 12

        

        
The comparison uses two reserved fictional addresses. The primary blue-trail-shoe page includes a Product, its image, and an Offer with a price. The red-road-shoe page also includes Product and Offer markup but leaves out the price. Both responses are fixed raw H-T-M-L fixtures, not live businesses or customer data.

      

      

        
Step 13

        

        
Enter both fictional U-R-Ls and select Fetch and check. The tool checks the primary page and then applies the same dated Product requirements to the second response. The visible note confirms the primary address that was checked, and the comparison panel identifies the shared requirement check. U-R-L mode uses raw H-T-M-L; it does not render JavaScript.

      

      

        
Step 14

        

        
The primary page produces one Product snippet card. Its name, image, and Offer price satisfy all three required checks, so it is eligible against this tracked baseline. Recommended fields still remain, and the card still cannot promise that Google will show a Product enhancement.

      

      

        
Step 15

        

        
The table contains one Product snippet row. The primary page is eligible, while the second page is missing required information because its Offer has no price. This is simply the same requirement check applied twice. It is not a ranking score, a traffic comparison, or proof that one page will earn more clicks.

      

      

        
Step 16

        

        
Eligible means the detected item contains every required field in this tracked table. Not yet eligible points to the required gaps to fix first. Restricted, deprecated, and retired describe whether Google makes the feature available. Recommended properties can make an eligible implementation more complete, but their absence does not block the required baseline.

      

      

        
Step 17

        

        
The checker parses the same J-S-O-N-L-D and H-T-M-L that Schema Validator uses. It follows connected items and nested properties, matches each type to the most specific tracked feature, and treats empty values as missing. It then compares the found fields with the dated requirement table.

      

      

        
Step 18

        

        
The tool supports pasted J-S-O-N-L-D, full H-T-M-L, and public U-R-Ls; automatic input detection; required and recommended lists for each feature; connected-item resolution; unavailable-feature labels; rule versions and verified dates; non-predictive preview cards; bounded share links; and a two-U-R-L requirements comparison.

      

      

        
Step 19

        

        
Passing this checklist does not guarantee display. The table covers only tracked documented features and may briefly lag a new change. U-R-L mode reads raw H-T-M-L, so it can miss markup added by JavaScript. It also does not judge page quality, policy compliance, crawling, indexation, the search query, device, or Google’s other filters. Fix truthful required gaps, validate the final rendered page, and measure what Search actually shows.

      

      

        
Fix required gaps, validate the released page, and let Google decide display.

        

        
Add missing required properties only when the values are truthful and visible on the page. Then validate the final markup, test the released rendered page in Google’s Rich Results Test, and keep the rule version and verification date in the handoff. Finally, observe what Search actually shows. Meeting a checklist makes a page eligible for consideration; it never promises a special result.

      

    
 
          
 
Common issues & how to fix them
 
     
  •  Error Structured data cannot be parsed Fix: Fix the reported JSON-LD syntax error until the document parses, then rerun eligibility checks on the resulting entities. 
  •  Information No supported rich-result type detected Fix: Add a currently Google-supported rich-result type only when it truthfully matches the visible page; otherwise treat no eligibility as a valid outcome. 
  •  Error Rich-result type is missing required fields Fix: Add each named required property with a value visible or otherwise verifiable on the page, then validate the affected entity again. 
  •  Warning Rich-result feature is deprecated Fix: Remove the deprecated feature-specific markup and use a supported successor only if Google documents one and the page qualifies for it. 
  •  Warning Rich-result feature is retired Fix: Remove markup maintained solely for the retired rich-result feature; retain valid Schema.org data only when it still serves another consumer. 
    •