JSON Rich Snippets: Diagnose Markup and Search Eligibility

Identify the search feature before changing markup

A JSON object does not create a rich snippet simply because it contains a product name or an article title. For web search, JSON-LD is one supported way to describe page content. Whether that description is eligible for a particular enhanced appearance depends on the search platform, the feature and the actual page.

Begin with the current Google Search structured-data gallery. Find the feature that corresponds to the page. If an old tutorial names a retired display, copying its sample cannot restore that display. As of this review, Google's documentation changelog records the removal of FAQ rich results in May 2026 and the later removal of their documentation.

Work through four separate failure layers

The first layer is JSON syntax: missing commas, smart quotation marks, unescaped line breaks and duplicate serialization can prevent useful parsing. The second is the vocabulary: a syntactically valid object can still use a misspelled property or a type unrelated to its page.

The third layer is the feature's requirements and content policies. The fourth is delivery: the intended page and its data must actually be accessible and discoverable. Fixing a comma does not fix a login wall, and submitting a sitemap does not make an inaccurate review rating truthful.

Inspect a modest navigation example

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Guides",
      "item": "https://example.com/guides/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Reading maps",
      "item": "https://example.com/guides/maps/"
    }
  ]
}

The two positions describe an ordered trail, not two unrelated search keywords. The names should be recognizable navigation labels and the links should lead to the intended pages. This example uses fictional URLs; deploying those URLs unchanged would describe the wrong site.

Google's breadcrumb documentation currently describes this feature as available on desktop. That matters when reviewing a phone screenshot: the absence of a desktop-only presentation on a mobile result is not proof that the JSON failed to parse.

Use each test for the question it answers

Paste the JSON into the local Structured Data Validator to catch parsing and basic shape problems. Then use Google's Rich Results Test for supported feature-specific checks. A vocabulary validator and a search eligibility test are different tools; neither confirms that every claim on the page is accurate.

Compare a code test with a test of the published URL. Code pasted into a testing form may be correct while a template emits an older object, escapes it twice or places it only on a different route. Inspect the actual rendered page, including any data inserted by client-side JavaScript.

Save the tested URL, the deployment version and the exact validation message. A screenshot saying only that something passed is difficult to investigate later. Keep errors distinct from recommendations so that an optional property is not treated as a universal publishing requirement.

Review indexing and observed presentation separately

After release, inspect how the intended URL is fetched and indexed. Verify that the canonical URL points where you expect and that authentication, access controls or accidental indexing directives are not hiding the page. Allow for recrawling before interpreting an unchanged search result as a failed deployment.

Google's structured-data guidelines make clear that correctly implemented data does not guarantee a rich result. Search presentation also depends on context. Avoid promising a particular ranking, traffic increase or permanent visual treatment to a client based only on a successful validator response.

When a feature remains absent, change one diagnosed problem at a time. Keep a known-good page as a comparison, record the revised markup and retest the live output. Adding many unrelated schema types makes that investigation harder and can introduce claims the page never supported.

For the breadcrumb example, follow both links in a fresh browser session and compare the trail with the page navigation. A technically reachable link that redirects to an unrelated landing page is still the wrong relationship. Test a second article in another section to expose hardcoded category names that a one-page check would miss.

Related guides

WordPress JSON-LD: Inspect and Maintain the Rendered Markup

Find the JSON-LD WordPress already emits, choose one publishing owner, serialize content safely, and verify changes on rendered article pages.

Scala JSON Schema

A practical guide to scala json schema, including the key steps and checks for schema draft, required fields, types and validation errors.

Ruby JSON Schema

Step through ruby json schema and verify schema draft, required fields, types and validation errors before you use or share the result.