Schema Markup Errors: How to Find and Fix Every Invalid Entity on Your Site

Most structured data problems are not syntax problems. The JSON parses, the validator is happy, and the rich result still never appears. This guide covers the failures that actually cost you eligibility.

1. Errors, Warnings, and Which Ones Matter

Google's Rich Results Test reports two severities, and teams consistently misread both.

• **Errors** — a required property is missing or malformed. The entity is ineligible. Fix these.
• **Warnings** — a recommended property is absent. The entity is *eligible but weaker*. Ignoring every warning is a defensible decision; ignoring them without knowing what they are is not.

The trap is that "valid" and "eligible" are different claims. A validator confirms your markup matches the vocabulary. It cannot confirm you qualify for a rich result, because eligibility also depends on content policy, quality thresholds, and whether the markup matches what a user actually sees.

2. The Failure Nobody Validates For: Markup That Contradicts the Page

The single most common cause of silently lost rich results is structured data describing something the visible page does not.

{
  "@type": "Product",
  "name": "Widget Pro",
  "offers": {
    "@type": "Offer",
    "price": "49.00",
    "availability": "https://schema.org/InStock"
  }
}

Perfectly valid. But if the page shows 59.00, or the product is out of stock, this is a policy violation — and repeated violations attract manual actions, not just lost snippets.

The rule: **structured data must be generated from the same source as the rendered content**, never hand-maintained alongside it. If your price comes from a CMS field, your JSON-LD must read that same field.

3. Entities Are a Graph, Not a Pile

Most sites emit three or four disconnected JSON-LD blocks per page, leaving Google to guess how they relate. Connecting them with `@id` removes the guesswork:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example"
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "Article",
      "@id": "https://example.com/post/#article",
      "isPartOf": { "@id": "https://example.com/#website" },
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

One graph, explicit relationships, every entity anchored to a stable identifier. This is how you state that the Article's publisher *is* the Organization, rather than hoping the parser infers it.

4. Validate Templates, Not URLs

Spot-checking single URLs in the Rich Results Test does not scale and does not find the failures that matter. Structured data breaks **per template**, and it breaks on the edge cases: the product with no reviews, the article with no author, the category page with one item.

A workable process:

1. **Enumerate templates**, not pages. Product, category, article, author, FAQ. 2. **Pick three URLs per template**: a typical one, a minimal one, and the weirdest one you can find. 3. **Diff the emitted JSON-LD** between them. Missing properties on the minimal case are your real bugs. 4. **Check Search Console's Enhancements reports** for aggregate counts — they surface breakage across thousands of URLs that no manual check would find.

5. Structured Data Is Now Also an AI Signal

Retrieval models extract facts far more reliably from typed entities than from prose. A price inside an `Offer` is unambiguous; the same number in a sentence is a guess. As answer engines become a real traffic source, clean entity modelling stops being a rich-results tactic and becomes a citation tactic — the reasoning is covered in [our AI search guide](/blog/the-future-of-seo-in-the-age-of-ai-search-engines) and [the llms.txt implementation guide](/blog/llms-txt-implementation-guide-for-ai-search).

[Metevix](https://metevix.com/audit) validates structured data across every template it crawls and reports which entities changed since the previous crawl.