The useful distinction

A validator can establish that markup is parseable and uses recognised types or properties. Google's Rich Results Test can report supported feature types and field errors. Neither result proves that a value is true, visible on the rendered page or guaranteed to appear in search.

Schema markup is a machine-readable description of entities and relationships already supported by the page. Schema.org supplies the vocabulary. Search systems decide which parts they consume, and Google documents a narrower set of supported search features with their own required and recommended properties. A valid Schema.org object can therefore be irrelevant to a Google feature, and an eligible Google item can still be omitted from the results.

The implementation order matters. Establish the visible fact and its owner, express the same fact in JSON-LD, validate the vocabulary, test any supported Google feature, compare the rendered page with the graph, then inspect Google's detection after release. Starting with the largest graph a plugin can generate reverses that order and creates another source of truth.

The deployment date became the publication date.

Both values are valid ISO 8601 dates. Only the editorial record describes the article. If a build timestamp feeds datePublished, every deployment changes the claim even when the article does not.

Valid format, wrong sourceBuild timestamp
{
  "@type": "Article",
  "headline": "Schema examples",
  "datePublished": "2026-08-27",
  "dateModified": "2026-08-27"
}

Why it passesThe properties and date format are recognised. A validator cannot tell that the values came from today's deployment.

RepairEditorial record
{
  "@type": "Article",
  "headline": "Schema examples",
  "datePublished": "2026-05-14",
  "dateModified": "2026-08-27"
}

What changedThe original publication date comes from the article record. The modified date changes when the content is materially revised.

The byline is repeated without a stable identity.

An embedded Person object is not a syntax error or necessarily false. But repeating the name in every article does not make the intended identity link explicit, and the copies can drift away from the profile.

Valid, but disconnectedName copied per page
{
  "@type": "Article",
  "author": {
    "@type": "Person",
    "name": "Mina Patel"
  }
}

What is missingThe object has a name but no stable identifier. Another template can describe the same person differently.

RepairReference one Person node
{
  "@type": "Article",
  "author": {
    "@id": "https://example.com/about/#mina"
  }
}

What changedThe article points to one Person node. That node maintains the name and profile URL used by the visible byline.

This repairs identity, not credibility. Expertise still depends on visible evidence and accountability; the E-E-A-T diagnostic treats that as a separate question.

A remote company was turned into a local storefront.

The example company has no public place of business, but a template chooses LocalBusiness and supplies an address anyway. The vocabulary accepts the type and property. That does not make the premises real.

Valid vocabulary, false claimTemplate owns the type
{
  "@type": "LocalBusiness",
  "name": "Example Studio",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Market Street"
  }
}

Why it passesLocalBusiness can have an address. Syntax and vocabulary checks do not verify the company's operating model or premises.

RepairReal entity owns the type
{
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Studio",
  "url": "https://example.com/"
}

What changedThe graph states only the identity this fictional company supports. It adds no address because the company presents no business location.

The URL folders became a breadcrumb trail.

Google describes a breadcrumb as a trail on the page that helps readers navigate its site hierarchy. This fictional page renders no such trail, so its Google-facing graph should not manufacture one from URL slashes.

Valid fields, unsupported pathFolders become hierarchy
{
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "SEO",
      "item": "https://example.com/seo/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Technical",
      "item": "https://example.com/technical/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Schema"
    }
  ]
}

What is wrongThe JSON-LD describes a navigation path that the page does not provide to readers.

RepairMake no breadcrumb claim
{
  "@type": "WebPage",
  "@id": "https://example.com/schema/#webpage",
  "url": "https://example.com/schema/"
}

What changedThe repair is omission. Add BreadcrumbList only if the page later presents a truthful breadcrumb path.

The repeated cause Every defect above begins before the JSON-LD is serialised. Correct the editorial record, identity source, entity type or visible navigation first. Then treat generation and release as technical SEO, not as a second source of facts.

The repair is one connected graph, not another set of facts.

This fictional page has a visible headline, byline, author profile, publication date and modification date. It has no breadcrumb trail, so its graph makes no breadcrumb claim. The graph connects values maintained by those visible records instead of keeping another version of them.

Connected Article graphFictional example · no breadcrumb claim
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Studio",
      "url": "https://example.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "publisher": {
        "@id": "https://example.com/#organization"
      }
    },
    {
      "@type": "Person",
      "@id": "https://example.com/about/#mina",
      "name": "Mina Patel",
      "url": "https://example.com/about/"
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/schema/#webpage",
      "url": "https://example.com/schema/",
      "isPartOf": {
        "@id": "https://example.com/#website"
      },
      "mainEntity": {
        "@id": "https://example.com/schema/#article"
      }
    },
    {
      "@type": "Article",
      "@id": "https://example.com/schema/#article",
      "headline": "Schema examples",
      "datePublished": "2026-05-14",
      "dateModified": "2026-08-27",
      "author": {
        "@id": "https://example.com/about/#mina"
      },
      "publisher": {
        "@id": "https://example.com/#organization"
      },
      "mainEntityOfPage": {
        "@id": "https://example.com/schema/#webpage"
      }
    }
  ]
}

The graph repairs the claim defects shown here. It is not a promise of rich-result eligibility or a substitute for the current requirements of a particular consumer.

Use each test for one layer.

Schema Markup Validator

Check parsing and the use of Schema.org types and properties. This does not verify that the business, address, date or author is real.

Rich Results Test

Check which Google-supported rich-result types are found, plus field errors and suggestions. A valid item is not a guarantee that Google will show a rich result.

Rendered page

Compare the JSON-LD with the visible headline, byline, dates, entity details, navigation and canonical. This is where a plausible but false value becomes visible.

Search Console

After release and recrawl, inspect URL Inspection and the relevant rich-result report where one exists. These are observations of what Google detected, not proof of the business facts or a promised search appearance.

A passing validator result starts the review.

Keep that result: it rules out a useful class of implementation errors. Then inspect the source behind every claim. A technically valid graph that misstates the page is still a failed implementation.