Common Schema Markup Mistakes That Break Rich Results

Most structured data problems found in real audits aren't invalid syntax — a schema markup validator catches that immediately, and it's rare to see a genuinely malformed JSON-LD block ship to production. The mistakes that actually cost rich-result eligibility, or quietly undermine the entity-disambiguation value covered throughout this series, are structural and semantic, not syntactic. This is a working list of the ones that show up repeatedly.

The single most common issue across every schema type covered in this series: separate Person, Organization, and Article blocks with no @id relationship between them. Each validates individually, and none of them tell a search engine or AI system that the Person authored the Article, or that the Person works for the Organization. The fix — a stable @id per entity, referenced rather than duplicated, all inside one @graph — is covered in depth in the pillar article in this series, and it's worth treating as the default check for any new schema markup rather than an advanced optimization.

Article, Product, and several other rich-result types have specific minimum image resolution requirements that Google's documentation states explicitly but that don't always get checked during implementation. An image field pointing at a real, correctly-formatted URL that happens to be too small silently fails rich-result eligibility — Rich Results Test will flag it, but only if someone actually runs the test after the image changes, which doesn't always happen for a routine content update that swaps a cover image.

Covered in depth in its own article in this series: JSON-LD injected via client-side JavaScript that never reaches the rendered page a crawler or AI system actually processes. This is a growing share of real-world schema failures specifically because so much of the modern web is built on JavaScript frameworks where this failure mode is easy to introduce without any visible symptom — the page looks correct to a human, the schema is simply absent from what gets crawled.

Repeating a full Organization or Person object inline on every page, rather than referencing one canonical @id, does two things wrong at once: it bloats every page's markup unnecessarily, and it creates drift risk — the inline copies inevitably diverge over time as different people update different pages, leaving a search engine parsing genuinely inconsistent claims about what should be the same entity.

A sameAs array pointing at a dead profile, the wrong company's page, or someone else's account. A Review or aggregateRating that doesn't reflect real reviews. A Person schema claiming expertise or credentials that don't hold up. None of these fail automated validation — they're syntactically perfect and semantically false, which is a worse position than having no schema at all, since it's an active trust-signal problem rather than a missing-opportunity one.

FAQ or HowTo schema built from questions and steps invented purely to qualify for the format, rather than reflecting genuine on-page content. Google's guidance explicitly discourages this, and it's a growing enforcement focus as rich-result eligibility has narrowed and Google has gotten more selective about which sites and content actually qualify. The schema should describe content that's actually visible on the page, not a schema-only fiction layered on top of thinner or different real content.

Product schema and Review schema carry a specific enforcement risk beyond generic markup errors: Google has stated it will suspend rich-result eligibility, and in some cases take broader action, against pages where Product schema pricing or availability doesn't match what's actually offered at checkout, or where Review schema ratings don't reflect genuine customer reviews. These aren't hypothetical markup errors caught by a validator — they're policy violations that require a human or automated trust-and-safety review to catch, and the consequence is more severe than a silently-missing rich result. Any site running Product or Review schema at scale should treat price, availability, and rating accuracy as a recurring audit item, not a set-and-forget implementation detail.

Using generic Organization when LocalBusiness or ProfessionalService applies. Using Article when BlogPosting is more accurate. Using a type that technically validates but doesn't match what the content actually is. This doesn't cause a validation error — the wrong-but-valid type is exactly the kind of mistake automated tools won't catch, since "is this the most accurate available type" is a judgment call a validator isn't built to make.

dateModified left unchanged after a substantive content revision, or never populated at all. This is a low-cost fix with real value — it's one of the clearer freshness signals available to a search engine, and leaving it stale or absent is a missed opportunity rather than an active error, but a common one across sites that implemented schema once and never revisited it.

A CMS migration, a framework upgrade, a component refactor — any of these can silently strip or corrupt a schema block that was working correctly before, without any visible rendering issue to flag the problem during normal QA. This is why re-running validation after significant template or framework changes matters as much as getting the initial implementation right; structured data has no visible fallback the way content does; it's either present and correct or effectively gone.

It's worth being concrete about what these mistakes cost, since "broken schema" undersells the actual impact on search visibility. A Product page with an image resolution error loses star ratings and price display in search results — a real click-through-rate cost, not an abstract technical debt item. A site with disconnected Person and Organization entities loses ground in Knowledge Panel eligibility and the kind of author-credibility signal that increasingly feeds AI Overview citation decisions, covered in depth elsewhere in this series. FAQ or HowTo schema that doesn't match on-page content risks losing rich snippets and featured snippets eligibility entirely once flagged, on top of never having reliably earned them under narrowed 2023 criteria. None of this is catastrophic on its own — most of these issues degrade rather than eliminate performance — but they compound across a site with many pages carrying the same underlying mistake in the same template.

It's worth separating markup errors into two categories, because they need different fixes. Syntax errors — malformed JSON, an invalid property name, a missing required field for a given rich-result type — are caught reliably by any schema markup validator and are usually quick to fix once flagged. Semantic errors — the wrong schema type for the content, disconnected entities, inaccurate sameAs or review data, schema-only content that doesn't match the page — pass every automated check and require a human reviewing the actual content and structure against what the schema claims. Almost every mistake covered in this article is the second category, which is exactly why they persist on so many sites: nothing in a standard validation workflow surfaces them.

Not every mistake is something present and wrong — a large share of real-world schema gaps are pages that should carry a given type and simply don't, often because a template was built before a particular schema type was added to the site's standard implementation and older pages never got backfilled. Auditing for coverage gaps across schema types — which pages have Article schema, which have Organization or Person references, which are missing entirely — is as important as auditing the pages that do have schema for correctness, and it's a check that's easy to skip because it requires looking at what's absent rather than what's present and flagged.

Most of these mistakes share a pattern: they pass automated syntax validation and fail on judgment, connection, or accuracy — the things a schema markup validator isn't built to check. The practical fix is the same testing workflow covered in the dedicated testing-tools article in this series: validate syntax with the Schema.org validator and Google's Rich Results Test, then manually verify entity connections, sameAs accuracy, and content-schema alignment as a separate, deliberate step rather than assuming a clean validator pass means the implementation is actually correct.