Before you start

What you'll need

• —Basic familiarity with JSON syntax
• —Understanding of what schema.org structured data is used for

JSON-LD

a JSON-based format for embedding schema.org structured data in a page, read by Google to power rich results.

Rich results

enhanced search listings, star ratings, prices, FAQ dropdowns, generated from valid structured data matching what's visibly on the page.

Guideline violation

structured data that is technically valid JSON but violates Google's content rules, such as marking up content not visible on the page, risking a manual action.

The process

Specimens to review

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "name": "Lenskart Ray Vision Blue-Light Glasses",
  "description": "Lightweight blue-light-filtering eyewear frame.",
  "offers": {
    "@type": "Offer",
    "price": "1499"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "212"
  }
}
</script>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the return policy for RayCon sunglasses?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "RayCon offers a 30-day return window on all sunglasses."
      },
    }
  ]
}
</script>

Analyze your findings

What to look for

Type match

Does @type actually describe what's on the page, or is it borrowed from a different content type?

Visibility match

Does every marked-up value actually appear on the rendered page, or is something declared that isn't shown?

Syntax validity

Is the JSON itself well-formed, no trailing commas, matching braces, before checking anything else?

Value provenance

Do the specific values (price, ratings, policy text) belong to this exact product, or were they copied from elsewhere?

Recommendation · Priority: High

“Neither specimen should ship as drafted. Specimen 1's @type must change from Article to Product, its aggregateRating block must be removed until the reviews section actually ships (marking up invisible content risks a sitewide manual action), and priceCurrency must be added to the offers object. Specimen 2's trailing comma is a hard JSON syntax error that silently voids the entire block, and its FAQ content must be rewritten to reflect this product's actual return policy rather than the copied RayCon reference.”

Common mistakes

What trips people up

• ×

  Only checking JSON syntax, not content accuracy — syntactically valid JSON can still violate Google's content guidelines, like an aggregateRating for reviews that aren't visible on the page.

• ×

  Missing a mismatched @type because the rest of the fields look complete — a wrong @type disqualifies the entire block from its intended rich-result type regardless of how complete the other fields are.

• ×

  Overlooking a trailing comma as a minor issue — invalid JSON is silently ignored by Google entirely, it isn't a partial failure, it's zero rich-result eligibility.

• ×

  Assuming copied-and-edited schema is safe once the type and product name are updated — every value inside the block, not just the headline fields, needs to be verified against this exact page, not the page it was copied from.

Final deliverable

A completed teardown sheet flagging every schema defect across both specimens, ranked critical to cosmetic, each with the corrected JSON-LD line.

Applying the same read to a Warby Parker-style frame PDP (illustrative): the draft correctly used @type: Product, but the aggregateRating block cited a 4.9 rating pulled from a different frame color's reviews entirely, a values-not-updated mistake caught before launch. The fix scoped aggregateRating to the exact SKU shown on the page rather than the product family average.

Success criteria

You're done when you can:

• Identified the Article-instead-of-Product type mismatch in specimen 1 as the highest-severity defect
• Flagged the invisible aggregateRating (no reviews shown on page) as a guidelines violation, not just a missing field
• Caught the trailing comma in specimen 2 as a hard validation failure, not a cosmetic issue
• Named the copied RayCon reference in specimen 2 as a values-not-updated mistake distinct from the syntax error

Key takeaway

A schema teardown has two separate failure classes: syntax errors that silently kill eligibility, and guideline violations that are syntactically fine but risk a manual penalty. Catching only one class isn't enough, both specimens needed a full read against the actual rendered page, not just a JSON linter.