Validating Structured Data: Rich Results Test and Search Console

The plain-language idea

Writing JSON-LD that parses as valid JSON is the easy 20% of structured data. The actual bar search engines apply — "is this page eligible to show a rich result" — is a separate, stricter check, and the only reliable way to know you've cleared it is to run the page through Google's own validation tooling, not to eyeball the schema against schema.org's docs and assume it's fine.

Two tools do this job, and they check different things:

• The Rich Results Test — paste a URL or raw HTML, and it renders the page (including JavaScript, the way Googlebot does), parses out structured data, and tells you specifically which of Google's roughly 30 supported rich-result types the page is eligible for — with errors (block eligibility) called out separately from warnings (missing recommended-but-not-required properties).
• URL Inspection, inside Search Console, checks the live, already-indexed version of a specific URL — useful for confirming what Google actually saw and indexed, as opposed to what a fresh test run against the page right now returns.

See it in a real thing: valid JSON that still fails eligibility

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wireless Mouse",
  "image": "https://example.com/mouse.jpg",
  "description": "A wireless mouse."
}

This is syntactically valid JSON-LD and will parse without error — but it's very likely ineligible for a Product rich result, because Google's Product requirements expect offers (price/availability) or review/aggregateRating to actually produce the price or star-rating snippet people associate with product rich results. "Valid JSON" only means the parser didn't choke; "eligible for a rich result" means the specific schema type's required and recommended fields are present and match what's genuinely visible on the page:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wireless Mouse",
  "image": "https://example.com/mouse.jpg",
  "description": "A wireless mouse.",
  "offers": {
    "@type": "Offer",
    "price": "24.99",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

Watch out

• "Valid JSON-LD" and "eligible for a rich result" are two different bars, checked by two different things — a JSON linter (or schema.org's own validator) only confirms the first; only Google's Rich Results Test tells you about the second.
• Errors block eligibility, warnings don't — a page with only warnings (missing recommended fields) still qualifies for the rich result, just a less complete-looking one; conflating the two makes people chase fixes that don't actually gate anything.
• Structured data must describe genuinely visible page content — this is a real, enforced Google guideline, not a technicality, and it's the failure mode that "the JSON validated fine" gives people the most false confidence about.
• The Rich Results Test renders JavaScript, so client-side-injected JSON-LD (common in SPA-style React apps) is testable — but that also means testing a static HTML file locally, without running the JS that injects the schema, will show nothing, a mismatch people don't expect.
• Rich result types are not permanent — Google adds and removes types over time (FAQ rich results specifically lost both search-result display and Rich Results Test support in 2026); revalidate periodically rather than assuming a type that worked at launch still works today.

Why this matters in interviews

This is a strong "have you actually shipped structured data, or just read about JSON-LD" filter — a candidate who only knows to "add schema markup" hasn't closed the loop, while one who describes pasting the URL into the Rich Results Test, distinguishing errors from warnings, and checking that the marked-up content is actually visible on the page is describing a real validation workflow, not a copy-paste step.