Join our community of websites already using SEOJuice to automate the boring SEO work.
See what our customers say and learn about sustainable SEO that drives long-term growth.
Explore the blog →TL;DR: Test rich snippet eligibility with Google’s Rich Results Test. Use URL mode for the published page, fix every error, and treat warnings as optional improvements. Then monitor the corresponding report in Google Search Console. A passing test means the page is eligible for a rich result, not guaranteed to receive one.
| Tool | What it answers | Best use |
|---|---|---|
| Google Rich Results Test | Can this URL or code generate a Google-supported rich result? | Before publishing, after deployment, and after each schema fix |
| Schema Markup Validator | Is the markup valid against the broader schema.org vocabulary? | Debugging syntax or validating types Google does not support as rich results |
| Google Search Console | What structured-data issues has Google found across crawled pages? | Ongoing site-wide monitoring and validating deployed fixes |

The tool choice matters. Google describes the Rich Results Test as “The official Google tool for testing your structured data to see which Google rich results can be generated by the structured data on your page,” in its Search Central structured-data documentation.
That is where I start when somebody asks me to test rich snippet eligibility. Not with a browser extension, a plugin’s green tick, or the retired Structured Data Testing Tool mentioned in an old tutorial.
One terminology correction: Google now calls these rich results. “Rich snippet” is the older phrase people still use. Both describe enhanced search listings that can include ratings, prices, images, breadcrumbs, event dates, recipe details, and other information beyond the standard title and description.
The structured data is not the search result itself. It is a machine-readable description of the page, commonly written as JSON-LD. Google can also parse microdata and RDFa, but JSON-LD is usually easier to generate, inspect, and maintain without tangling the markup into visible HTML.
Valid structured data creates eligibility. Google still decides if an enhancement appears for a particular page and query. That distinction explains a large share of “the test passes, but I see no rich snippet” reports.
The Rich Results Test has URL and Code modes. They overlap, but they do not prove the same thing.
URL mode answers the useful production question: What can Google retrieve from this URL right now?
Your JSON-LD can be flawless in a CMS field and absent from the published page. A template condition may suppress it, a cache may serve the previous version, a JavaScript error may stop injection, or the production deployment may omit the component entirely. The editor is evidence of intent. The live URL is evidence of output.
URL mode also renders pages, so it can detect structured data inserted through JavaScript. Still, I prefer server-rendered JSON-LD where practical because it removes one more failure point (not every implementation needs another moving part).
During our January 2026 migration from seojuice.io to seojuice.com, representative live-URL tests were part of the release checklist. A migration can preserve the schema template while changing canonicals, production paths, caches, and page output around it. Testing only the JSON-LD snippet would have ignored most of the migration risk.
Code mode is useful while building or editing markup. Paste the relevant HTML or JSON-LD, run the test, and repair the structure before touching production.
Paste a raw snippet like this Article markup and test it before the page ships:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to Test Rich Snippets",
"author": { "@type": "Person", "name": "Vadim Kravcenko" },
"datePublished": "2026-07-19"
}
</script>
For stubborn problems, test both. Code mode tells you whether the proposed markup is acceptable. URL mode tells you whether that version reached the page. Those results often diverge, which is the clue rather than an inconvenience.
If you need to build the JSON-LD first, use our Schema markup generator, then pass its output through Google’s test. A generator can reduce bracket, nesting, and property mistakes. It cannot verify that your CMS supplied the right data or that production rendered the final block.
This is the distinction to preserve when reading the test output.
| Status | Meaning | Response |
|---|---|---|
| Error | A required property is missing or a value is invalid. The affected item is not eligible for that rich result. | Fix it before launch or before expecting the enhancement. |
| Warning | A recommended property is missing. The item can remain eligible. | Add it when it accurately improves the item; do not treat it as a blocker. |
| Valid | The test found no eligibility-blocking issue for that item. | Deploy and monitor. Display is still not guaranteed. |
An item means a particular structured-data object detected on the page. One URL can contain several items and several schema types, each with a different status.
I have seen teams clear a dozen warnings while leaving one required-property error unresolved. That reverses the priority. Fix blockers first, rerun the test, and put genuinely useful warnings into an optimization backlog.
A warning can still expose weak source data. For example, an optional image or identifier may help Google understand and present a Product more completely. But recommended does not mean secretly required (and adding invented values to silence a warning is worse than leaving it alone).
The Rich Results Test normally names the missing property. Start there rather than swapping plugins or copying another site’s JSON-LD.
A Product item might be missing its name or the necessary offers, review, or aggregate-rating information. A Recipe might be missing an image. Requirements differ by rich-result type, so open Google’s documentation for the detected feature and compare the expected structure with the parsed item.
Then trace the missing property upstream. If a template expects a price, author, image, or date field and the CMS record is empty, editing the generated JSON-LD treats the symptom. Fix the content model, validation rule, or template fallback instead.
From what we see across sites on SEOJuice, the awkward failures tend to happen at this handoff between valid schema logic and incomplete page data. The generator knows where a value belongs; it cannot manufacture a real price or visible review that the page does not contain. Nor should it.
Schema properties do not all accept plain text. A property may require a number, URL, Offer, PostalAddress, or another nested object. A value can look reasonable to a reader and still have the wrong machine-readable type.
Open the affected item in the test, locate the precise property, and compare its value with the expected type. If the template generated the same mistake on one URL, test several other pages using that template. One failure is often a sample of a larger issue, not an isolated page.
Fixing the template once is the efficient move. Fixing 80 generated pages manually is 80 opportunities to make the same mistake again (or 79, if luck is carrying the first edit).
Properties such as datePublished, dateModified, and startDate need machine-readable ISO 8601 values. A CMS may display “July 19, 2026” correctly to readers while passing a localized or ambiguous string into the schema.
Correct the date formatter at template level. Also inspect time zones for events and offers; a syntactically valid timestamp can still communicate the wrong start or expiry time.
Run the production URL through the Rich Results Test. If the expected type is not detected, inspect the actual output rather than repeatedly editing the schema object.
SEOJuice auto-generates schema on the pages it manages, but Lida and I still test representative output. We are a two-person team, so automation is essential. Treating automation as infallible would merely automate our blind spot.
A page may receive schema from its theme, SEO plugin, commerce plugin, specialist schema plugin, and custom JSON-LD simultaneously. The Rich Results Test separates detected items, making incomplete or unexpected copies easier to spot.
Do not celebrate one valid Product item while ignoring a second broken Product block. Identify which system emits each object and choose one owner for that schema type. Disabling redundant output is usually safer than trying to keep several generators synchronized.
Be careful before deleting apparently duplicated Organization or WebSite markup, though. Similar-looking objects can describe different entities or serve different page-level purposes. Compare their identifiers, types, and relationships first (this is one area where “remove duplicates” is too blunt).
Technically valid markup can still violate Google’s structured-data policies. A validator checks whether data can be parsed; it does not certify that the claims are truthful.
“Don’t mark up content that is not visible to readers of the page.”
Google’s structured-data general guidelines add: “Your structured data must be a true representation of the page content.” The consequence is explicit too: “A structured data manual action means that a page loses eligibility for appearance as a rich result.”
Do not add aggregate review stars if users cannot find those reviews on the page. Do not mark up an event date that the page never displays. Do not turn an ordinary article into a Recipe object because the recipe result looks more prominent.
This also applies to stale values. If the visible product price changes but cached JSON-LD retains the old price, the markup no longer represents the page. It may have perfect syntax and still be wrong.
Google deprecated its old Structured Data Testing Tool in 2020. Generic schema.org validation now continues through the Schema Markup Validator, while Google directs rich-result eligibility testing to the Rich Results Test.
A schema.org type can therefore be valid without producing a Google enhancement. There is no contradiction: schema.org describes far more entities and relationships than Google’s search gallery supports.
Use the validator to answer “Is this valid schema.org markup?” Use Google’s tool to answer “Is this eligible for a Google rich result?” If you need the deeper distinction, our Schema.org 2026 guide covers what Google currently reads and uses.
Plenty of otherwise competent schema tutorials are now outdated.
Google’s live structured-data search gallery remains the source to check before implementing a type for search visibility. Supported features include Article, Breadcrumb, Dataset, Discussion forum, Event, Job posting, Local business, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Vacation rental, and Video, among others.
FAQ and HowTo are absent.
Google removed HowTo as a search feature in 2023. Its documentation changelog states: “Removed the How-to structured data documentation, as this rich result is no longer shown in search results, on both desktop and mobile devices.”
FAQ survived longer in a restricted form, but that ended too. Barry Schwartz reported in Search Engine Land that Google discontinued FAQ rich results as of May 7, 2026. Google’s documentation notice said:
“FAQ rich results are no longer appearing in Google Search. We will be dropping the FAQ search appearance, rich result report, and support in the Rich results test in June 2026.”
FAQPage remains part of schema.org, and other systems may process it. It will not generate a Google FAQ rich result. HowTo markup can still describe instructional content in a general semantic sense, but it no longer earns a HowTo enhancement in Google Search.
Keep useful FAQs and step-by-step instructions for readers. Just do not budget implementation time on the assumption that these two schema types will create Google rich snippets. That tactic has expired.
The Rich Results Test is a page-level diagnostic. Search Console reports what Google encountered across crawled pages.
Open the relevant report, such as Breadcrumbs, Product snippets, or Merchant listings. Inspect affected URLs, find the shared template or data source, deploy the correction, and select Validate fix when available. Google must recrawl and process the URLs before the report updates.
Search Console is slower than pasted-code testing because it reflects Google’s crawl cycle, not your latest local edit. That delay can be annoying (I have refreshed those reports knowing perfectly well it would change nothing), but it is also what makes the data valuable: it represents production pages at scale.
Our free SEO audit can help identify broader site issues before you narrow the investigation to individual URLs. Confirm rich-result eligibility in Google’s own test afterward; a third-party audit should not be the final authority on a Google feature.
A valid result means eligibility, not guaranteed display.
Google decides whether to show an enhancement for each query and result. Search appearance can also be affected by page quality, misleading or mismatched markup, unsupported feature types, and structured-data manual actions.
If the test passes but no enhancement appears:
I am confident in that diagnostic sequence. Predicting exactly when Google will decorate an eligible result is less certain because Google gives no display guarantee. Rewriting already-valid JSON-LD every time a rich result disappears can introduce fresh errors without changing the underlying decision.
Eligibility and presentation are separate across more than schema. Our guide to SERP snippets and AI visibility explains why indexing and snippet control still matter even when search platforms choose the final presentation.
Paste the published URL into Google’s Rich Results Test. Use Code mode for HTML or JSON-LD that has not been published. The tool identifies supported rich-result types and lists errors, warnings, and parsed properties. Use Search Console for aggregate information across crawled pages.
Google retired the old Structured Data Testing Tool. Use the Rich Results Test for Google rich-result eligibility and the Schema Markup Validator at validator.schema.org for broader schema.org validation.
The Rich Results Test checks whether markup can produce a Google-supported rich result. The Schema Markup Validator checks general schema.org validity, including vocabulary Google does not use for search enhancements. Passing the latter does not prove Google eligibility.
An error means a required property is missing or invalid, making the affected item ineligible. A warning usually means a recommended property is missing while the item remains eligible. Fix all errors first, then assess warnings according to their usefulness and the data actually shown on the page.
No. Google fully removed FAQ rich results on May 7, 2026 and subsequently dropped the related testing and reporting support. FAQPage remains valid schema.org vocabulary, but it no longer generates a Google FAQ rich result.
The markup may not have reached production, may be suppressed by a template condition, may sit behind stale caching, or may depend on JavaScript that failed during rendering. Compare Code mode with URL mode, then inspect the rendered production output and every system capable of injecting schema.
Passing means the page is eligible, not guaranteed to receive an enhanced listing. Confirm that the markup matches visible content, check the relevant Search Console report, verify that the feature remains supported, and make sure the site has no structured-data manual action.
If you are generating or repairing JSON-LD, start with one representative page, test it in Code mode, deploy it, and test the live URL. Once that page is clean, apply the template-level fix across the site and let Search Console confirm the result at scale.
no credit card required