Rich Result Eligibility: Valid Is Not a Fold

By William Zhu · Cofounder, InfiniSynapse · Last updated: 2026-10-02 · Last verified: 2026-09-11 · Methods: Compared four current Google Search Central feature guides by named type and documented field contract; no tester verdicts were invented. Local parse, URL reachability, visible-subject matching, sameAs consistency, ownership evidence, and official eligibility remain separate findings. Evidence observed 2026-09-11; not an official Google score.

Author / off-site profiles: GitHub @allwefantasy · auto-coder · GitHub @InfiniSynapse · LinkedIn company (no personal profile) · Editorial standards. No personal LinkedIn or vendor badge.

Reviewed by: InfiniSynapse Data Team · method review 2026-09-11. First-party method review.

Trust / COI: About · Corrections · Publishing principles · Privacy · Terms. SEO Health is commercial. The dated public probe below reports raw fields and limits. The InfiniSynapse Data Team publishes this method.

TL;DR

Rich results eligibility belongs to the official tester and to Google’s systems. A local JSON-LD parse is a different book. A valid script is not a fold. Traffic lights are not a Google 100. Keep the books separate.

Direct answer: Rich result eligibility is the official tester's named feature, not a green parse. Fail the row before you promise a fold.

The markup still has to parse, match the visible page, and meet that feature's fields. A local JSON-LD parse is a different book.

What you'll learn:

• Why rich results eligibility is a separate book from a local JSON-LD parse
• How the official tester and the extract can disagree without either being “broken”
• A dated public probe with raw fields, status handling, and explicit limitations
• When a missing type is still a punch list, not an eligibility claim

The social card at ./images/og-cover.png matches the hero. Paste a public URL at infinitegrowth.agency/seo-tools#check. Do not paste secrets.

We evaluate the official tester as a separate book, hands-on as the InfiniSynapse Data Team. Our review keeps the official feature contract separate from local syntax and never treats InfiniSynapse as an eligibility oracle.

What rich result eligibility is

Key Definition: Rich result eligibility is the official tester's named feature, not a green parse. Fail the row before you promise a fold. It is the tester’s current verdict on one named rich result. It is not a local JSON-LD parse, not an official Google health score of the whole site, and not a promise that Search will draw the feature tomorrow.

Observed page CLI (2026-09-11, infinitegrowth@0.1.1): seo-health check https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data --format json --lang en exited 0. issues[].status listed Title Length (warning), Meta Description (warning). Process exit 0 is not a clean page.

The dated public-page probe below reports raw observations.

Independent citation: According to [Rich Results Test](https://search.google.com/test/rich-results), Google's Rich Results Test checks whether a URL is eligible for supported rich result types. Google's Rich Results Test page is the third-party rule this write-up holds to. The dated probe below is evidence, not that rule.

Google’s intro to structured data is the appearance vocabulary. The verdict still lives in the tester and in production systems, not in your pretty-print.

The Rich Results Test is the official book this page names. That tester is the official book. The Chrome extract is not that book. Markup is not eligibility.

Schema.org’s getting started guide teaches types and properties. It does not grant an official tester verdict. A completed tutorial is not a tester verdict.

A rich snippet is an appearance on a search engine results page. The official book is a current official read of whether that appearance could apply. It is not a traffic forecast.

This rich results eligibility review stays focused on the official rich results eligibility verdict. The hub schema markup audit is the local type list. This page is the narrower job: keep the tester separate from the parse.

Local parse is a different object

Microdata is another encoding the local extract may still find. The official book does not become “true” because Microdata parsed. A second encoding can even contradict the first.

Chrome extracts structured data locally. That extract answers “what did we ship.” rich results eligibility answers “does the official tester currently treat this URL as eligible for a named feature.” Those sentences must not collapse.

What this page will not run

This page has no URL box and does not replace the Rich Results Test. A rich result eligibility check will not rewrite robots. Use the robots txt check when the question is allow or disallow. Syntax stays on the JSON-LD checker. It will not score experience. An EEAT checker is a different surface. A service-case traffic story is not product proof that a tester row is a win.

Three gates before the tester row

Rich result eligibility clears three gates before the official row counts. The script has to parse. The node has to match the visible page. The fields have to meet that feature's documentation. JSON-LD, Microdata, and RDFa are encodings on the first gate. A second encoding does not make the tester row true.

A two-book framework

Keep parse local. Keep the tester official. Keep narrative optional. Rich results eligibility that merges those books will sell a green parse as a carousel. A ticket that merges those three layers will sell a green parse as a carousel.

Book one — local extract

Chrome extracts structured data on the machine unless you start AI EEAT. Paste the URL at infinitegrowth.agency/seo-tools#check for the eight modules around the markup. Those lights still apply after you record rich results eligibility. An SEO health checker pass is the cheap companion, not a substitute for the official tester.

If the encoding is the question, open the JSON-LD checker. Syntax versus entity is book one, column two. The official tester stays book two.

Book two — official tester

Open the official tester on the live URL. Record the named feature and the current verdict. The official verdict is that row. It can change when Google changes the feature. A yesterday screenshot is not today’s book.

How you sequence the books is a sibling. Open how to validate schema when the question is local parse, then official test. This page stays on why the books must not merge.

Eight lights still apply after either book

A URL can look eligible in the tester and still fail title, canonical, or speed. A tester screenshot that ignores the eight modules will celebrate a feature on a thin page. Traffic lights are not a Google 100. Rich results eligibility still sits in the official book after the lights.

Eligible is not displayed

Rich result eligibility is a dated tester row for one named feature. It is not the fold, Top Stories, or a product result. A local parse can be valid while the tester says not eligible. That is not a product bug. That is two books.

Valid FAQPage is not a fold

FAQ templates have their own abuse-risk job. Open FAQ schema SEO when the question is present markup versus a fold promise. That check is the FAQ checker. The official tester is the later book. Do not skip the abuse check because the tester was green last quarter.

Valid Article is not Top Stories

Article templates have their own date-and-author job. Open Article schema SEO when the question is clocks and a Person. The official tester may still say not eligible. Keep both rows.

One named feature, one dated row

Record the feature name, the test date, and the live URL. A staging host, last quarter's screenshot, and a Search Console enhancement report are not that row. The enhancement report is a third clock. It is not a promise that the feature will show.

The landscape is local extractors, official testers, and SERP screenshots. Rich results eligibility is only the official tester. Only the official tester is rich results eligibility’s Target. Screenshots expire. Local parses stay local.

The official book is closer to a dated lab note than to a chat. It should record the tester URL, the date, and the named feature. It should not invent an uplift percent. Prefer the live URL over a preview host that injects a different script.

For implementation context, Semrush’s schema markup guide and Yoast’s structured-data guide describe publisher-side markup work. They diversify the practical reading, but neither source can issue a Google eligibility verdict. The official tester remains the decision record for rich results eligibility.

Structured data for answer engines is a different cluster note. Open structured data for AI search when the question is extractable text, not a rich-result feature. Do not retarget that phrase here. Search-feature eligibility and a structured data tool for AI agents stay on separate tickets.

Query movement after a feature appears still uses Search Console. That overlay is a sister job. It does not rewrite the tester into a site-wide Google 100.

Search Console enhancement reports are a third clock beside rich results eligibility. They are not the official tester and not the local parse. A feature can leave the tester’s eligible list after a documentation change. Date the screenshot. Do not file last quarter’s green row as this week’s rich results eligibility.

Preview hosts often inject extra JSON-LD. The official tester on staging is a different URL. Re-run on production after merge. The seo-health CLI (npm i -g infinitegrowth) can fail a pull request when a template drops @type. That gate is book one. The official tester remains book two.

How to run the two books

Run rich results eligibility as four inspectable steps after the local parse. JSON-LD parse is local. Before the official test, record identifier reachability, compare the schema node with the visible subject, check sameAs consistency, and document ownership claims separately.

Step 1 — Extract structured data in Chrome

Open the page in Chrome with the SEO Health extension. Confirm the extract happened on the machine. Rich results eligibility that starts in the official tester with no local type list will hide a truncated script. Before recording the official result, run the page-health check once on the same production URL and date.

Step 2 — Fix the local book first

List @type values, record each identifier’s exact network result, and compare the node’s name, canonical URL, author, or product details with the visible subject. Check sameAs targets for the same identity and retain ownership or account-control evidence when ownership is claimed. If the script is broken, stop; repair the template and re-extract before testing rich results eligibility.

Step 3 — Open the official tester as a second book

Run the official tester on the live URL. Write the named feature and the current verdict in the ticket. Rich results eligibility is that sentence. Do not title the ticket “we will get the fold.” Leave robots and llms.txt to their own tools. The robots.txt checker is the live tool for allow and disallow.

Step 4 — Turn gaps into an assignable list

Name the missing type, unreachable identifier, visible-subject mismatch, inconsistent sameAs, unsupported ownership claim, or official “not eligible” row as its own ticket. Do not name a SERP deadline. Rich results eligibility ends at an assignable gap plus a dated tester note. Optional narrative of the local list is a credited InfiniSynapse task. Chrome stays local unless you start AI EEAT.

Do not present the punch list as an official Google score. Do not present a service-case traffic story as eligibility proof.

Independent citation 2: According to [rich snippet](https://en.wikipedia.org/wiki/Rich_snippet), Rich snippet is documented in that encyclopedia article as a public third-party definition. The encyclopedia definition clarifies “rich snippet,” while current Google feature documentation controls the field matrix.

Official documentation matrix: supported type and required fields

The rows below are the feature contract. They are not the tester result for this URL. Article, product, breadcrumb, and FAQ stay on this page. A news item about expanded product eligibility is not a new section.

Documentation check (2026-09-11, InfiniSynapse Data Team): We read Google Search Central’s current structured-data feature pages and Schema.org definitions, then recorded the named type and the fields the official page labels required or recommended. We did not automate or fabricate Rich Results Test verdicts. Eligibility remains a URL-by-URL official-tool result.

An official field list is still not a URL verdict

Documentation defines the contract for a feature. It does not inspect your live URL, rendering path, policy compliance, or indexing state. A local parser can show that the relevant type and fields exist; only the official tester can return the tester’s current result for that URL. Even that result is eligibility, not a display promise.

Evidence limitation and reproduction.

Open the four linked Google Search Central feature pages on the stated date, record the exact type names and required/recommended sections, and compare them with the extracted node—not with a generic “schema present” flag. The principal limitation is that documentation can change, locales may phrase requirements differently, and the Rich Results Test has no result represented in this table. This evidence is intentionally a field-contract comparison rather than a fictional batch of eligible pages.

Rich results eligibility must retain the named feature and test date. Recheck rich results eligibility after the production URL changes.

Selection scorecard

Use this scorecard to keep rich results eligibility inside its job. Each row is inspectable. None of the rows is an official Google health score of the site.

A row that fails the last test is a crawler ticket. A row that fails the fold test is a sales slide.

Failure modes that merge the books

Most disappointment after rich results eligibility is a category error. The local parse was never the official book.

Inventing a feature from a valid parse

A valid block can still be ineligible, unused, or later restricted. The ticket should say “official tester, dated verdict.” It should not say “we will get the fold.” Do not attach an invented CTR percent.

Running the tester on staging

A staging host that injects extra JSON-LD will produce a tester row you cannot ship. The official tester must use the live URL. Re-run after merge. Preview hosts often ship different script blocks than production.

Keep the official tester outside the product boundary. The deterministic SEO Health layer retains syntax, robots, and llms.txt observations without turning them into a verdict. Parsed defects can then be uploaded server-side into an InfiniSynapse Server API long-task workspace; InfiniSynapse and its API foundation shape the evidence into a human-ready fix queue for an editor or developer. The workspace does not rerun or revalidate Google eligibility, and it cannot prove crawler behavior.

Parse locally, then open the official tester

Extract structured data on a public URL first. Keep the official tester as a separate book.

Run SEO Health Checker

Use a public URL you can stand behind. Do not paste secrets.

Frequently Asked Questions

What is rich result eligibility?

Bottom line: Rich result eligibility is the official tester's named feature, not a green parse. Fail the row before you promise a fold.

Does a valid parse mean an official rich result?

Bottom line: No. A local parse is book one. Rich results eligibility is the official tester. Markup is not eligibility.

Is the tester an official Google score of the site?

Bottom line: No. Traffic lights are eight modules on a pasted URL. Rich results eligibility is a dated feature verdict. Neither object is an official Google health or EEAT score.

Do robots or llms.txt belong in this check?

Bottom line: No. They are siblings in this pillar. Use the robots tool for allow and disallow. Keep rich results eligibility on the official tester.

When does InfiniSynapse write the punch list?

Bottom line: Parse stays on the machine. Any follow-up list must quote the local defect or dated tester message instead of inventing a feature outcome. Rich results eligibility does not spend that budget on the official tester itself.

Conclusion

Rich results eligibility earns trust when it stays the official tester’s book—and stops before parse theater. Extract locally. Test officially. Leave crawler files to their own tools. Open the InfiniSynapse web app only when you want the local punch list written as a task. Then paste the live URL again and keep the eight lights honest.