Schema Validation: Catching Errors That Block Rich Results

A client's recipe site has JSON-LD on every page. Google's Rich Results Test returns a green checkmark. No rich results appear in search. Three months of troubleshooting later, the agency finds a single required property missing from the Recipe type — one that the Rich Results Test doesn't flag as an error, only as a warning.

Valid JSON-LD and rich-result-eligible JSON-LD are not the same thing. This distinction costs more agencies more time than almost any other technical SEO issue.

What "Valid" Actually Means (and Doesn't)

JSON-LD validation has two independent layers:

1. Syntactic validity: Is the JSON parseable? No trailing commas, balanced braces, correct quote types. A JSON linter catches this.
2. Schema.org conformance: Are the properties the right types? Does the @type exist? Does the value format match what Schema.org specifies?

But rich results add a third layer Google never fully documents publicly:

3. Rich result eligibility: Are all Google-required properties present? These are stricter than Schema.org's "required" list and vary by type, country, and feature rollout.

A schema can pass layers 1 and 2 and still fail layer 3. That's the trap. Use the Schema Markup Validator to check all three — it surfaces the rich-result gaps that syntactic validators miss.

Required vs Recommended: Type by Type

Organization

Minimum for Knowledge Panel eligibility:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Acme Digital",
  "url": "https://acmedigital.com",
  "logo": "https://acmedigital.com/logo.png",
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+1-800-555-0100",
    "contactType": "customer service"
  }
}

Missing url or logo kills Knowledge Panel eligibility. Missing contactPoint is recoverable.

LocalBusiness

Required for Local Business rich results:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Riverside Plumbing",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main St",
    "addressLocality": "Portland",
    "addressRegion": "OR",
    "postalCode": "97201",
    "addressCountry": "US"
  },
  "telephone": "+1-503-555-0199",
  "url": "https://riversideplumbing.com"
}

address is required. telephone and url are technically recommended but practically required for any meaningful rich result.

Product

Google's Product rich results require name plus at least one of: review, aggregateRating, or offers. This trips up e-commerce sites constantly:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Titanium Water Bottle",
  "image": "https://example.com/bottle.jpg",
  "description": "32oz titanium water bottle, BPA-free.",
  "sku": "TWB-32",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/bottle",
    "priceCurrency": "USD",
    "price": "49.00",
    "availability": "https://schema.org/InStock"
  }
}

price must be a string, not a number. availability must be the full Schema.org URL, not the shorthand "InStock".

FAQPage

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What areas do you serve?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "We serve the greater Portland metro area."
      }
    }
  ]
}

mainEntity must be an array, not a single object. The text value in acceptedAnswer may include HTML — but avoid <script> tags, which Google strips and may penalize.

BreadcrumbList

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Services",
      "item": "https://example.com/services/"
    }
  ]
}

position must be an integer starting at 1. Gaps (1, 3, 5) or strings ("1") break the breadcrumb trail.

Article

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Validation Guide",
  "author": {
    "@type": "Person",
    "name": "Jane Smith"
  },
  "datePublished": "2026-06-17",
  "dateModified": "2026-06-17",
  "image": "https://example.com/og/article.jpg"
}

headline has a 110-character limit. image must be at least 1200px wide for AMP and Top Stories eligibility.

The Most Common Errors the Validator Catches

Trailing commas

// BROKEN — trailing comma after last property
{
  "@type": "Organization",
  "name": "Acme",
  "url": "https://acme.com",
}

This breaks JSON parsing entirely. Browsers forgive trailing commas; Google's structured data crawler does not.

Wrong value types

// BROKEN — price as number
"price": 49.00
 
// CORRECT — price as string
"price": "49.00"

Schema.org specifies price as Text. Passing a number passes JavaScript validation but fails Schema.org type checking.

@graph mistakes

The @graph pattern lets you include multiple schema types in one script block:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "name": "Acme" },
    { "@type": "WebSite", "url": "https://acme.com" }
  ]
}

The mistake: putting @context inside each @graph item. @context belongs on the outer wrapper only. Duplicating it doesn't break parsing, but it creates namespace conflicts that Google's parser may misinterpret.

Shorthand vs full Schema.org URLs

// BROKEN — shorthand
"availability": "InStock"
 
// CORRECT — full URL
"availability": "https://schema.org/InStock"

Google's structured data parser accepts both in most contexts, but rich result eligibility checks often require the full URL. Don't assume shorthand works.

Missing @id for cross-referenced entities

If you reference an entity defined elsewhere in @graph:

{
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://acme.com/#organization",
      "name": "Acme"
    },
    {
      "@type": "WebSite",
      "publisher": { "@id": "https://acme.com/#organization" }
    }
  ]
}

The @id must be a URL. Using a bare string like "acme-org" breaks the reference.

What to Skip

Don't implement every Schema.org type on every page. A LocalBusiness homepage does not need SoftwareApplication, Event, and Dataset schema. Google treats schema spam as a quality signal. Implement the types that match the actual page content.

Don't use Microdata. JSON-LD is Google's preferred format, it's easier to maintain, and it doesn't require restructuring HTML. There is no meaningful benefit to Microdata in 2026.

Don't add schema to pages that aren't indexed. Noindex pages don't appear in search results, so rich results can't display. Schema on a noindex page is wasted implementation effort.

Don't copy-paste schema templates without updating all values. The most common field agency auditors find: "name": "Your Business Name Here" in production.

Validating at Audit Time

Run the Schema Markup Validator on each page type in the site — homepage, service pages, blog posts, product pages — not just the homepage. Each page type typically has different schema, and errors are rarely uniform.

The opinionated truth most agency tooling avoids: Google's Rich Results Test is not a strict eligibility checker. It reports "valid" on schemas that will never generate a rich result because it's checking Schema.org conformance, not Google's unpublished rich result requirements. Cross-reference against the validator and Google's per-type documentation before telling a client their schema is clean.

The audit one-liner for schema validation: Valid JSON-LD means the syntax is correct; rich-result eligibility means every Google-required property is present with the right type — run both checks before signing off.

Related reading

• Schema Bugs That Block Rich Results
• Schema Markup Guide for Agencies
• Structured Data That AI Search Loves