Structured Data Errors: How to Validate and Fix Schema

Why structured data errors matter

Broken markup can prevent a platform from interpreting the graph or make a page ineligible for a supported search feature. Conflicting organization, author, breadcrumb, service, or page identities can obscure the intended source. Markup that invents visible facts can violate platform policies and mislead users.

Structured data is descriptive. It cannot manufacture authority, a service, a review, a price, or an AI citation. Repair work should produce one coherent representation of the actual page and organization.

Three different error classes

A “valid” result in one tool may cover only one class. The Schema.org validator can examine vocabulary and graph structure, while Google's Rich Results Test focuses on supported Google features. Neither can decide whether an unverified business claim is true.

Confirm the final rendered markup

1. Request the exact canonical page without an authenticated session.
2. Extract every JSON-LD block and inspect microdata or RDFa if present.
3. Compare initial HTML with the rendered DOM to detect script-generated duplication.
4. Parse each JSON block and record the exact line or path of an error.
5. Validate the combined graph with Schema.org's validator.
6. Use the relevant platform test only when the page targets a supported feature.
7. Compare every important value with the visible page, canonical, breadcrumbs, author, contact facts, and approved business records.

Fix errors in the right order

1. Choose one source of truth: identify whether the template, CMS, custom plugin, SEO extension, or page body owns the graph.
2. Repair JSON syntax: correct quotes, commas, brackets, escapes, data types, and encoding.
3. Remove duplicate graphs: merge or disable competing organization, website, page, breadcrumb, and article output.
4. Use accurate types: select the most specific real type without forcing a rich-result category.
5. Stabilize identifiers: use approved absolute production URLs and consistent @id values.
6. Connect entities: link page, WebSite, Organization, author, service, and breadcrumb nodes rather than creating unrelated copies.
7. Match visible facts: remove unsupported reviews, prices, offers, service areas, people, images, and claims.
8. Meet feature requirements: add only properties supported by the page and current official feature documentation.
9. Deploy and retest: clear caches and inspect the final public DOM.

Resolve duplicate and conflicting entities

Two blocks are not automatically wrong; a page can legitimately contain a WebPage, Article, Organization, author, and BreadcrumbList. The problem is unconnected or contradictory representations of the same entity. Look for multiple Organization nodes with different names, URLs, logos, telephone numbers, or IDs and multiple breadcrumb trails generated for different routes.

Prefer one stable node per real entity and reference it. Avoid deleting a useful graph before confirming what other templates and pages rely on it.

Also compare identifiers across environments. A production page should not connect its Organization, WebSite, author, or breadcrumb nodes to a staging hostname. During migration, update the complete graph and validate representative routes rather than using a broad search-and-replace without reviewing context.

Keep examples inert. A JSON-LD snippet shown to teach readers should be escaped as code, not executed as another graph on the article page.

If a property cannot be verified, omit it until the business record or visible content is approved. An incomplete but truthful graph is safer than a validator-friendly graph containing fabricated values. Record the omission as a deliberate, reviewable production decision, not an error to fill automatically much later.

Joomla and WordPress notes

Joomla

Inspect the template, article, menu item, component view, custom fields, modules, and system or content plugins. Route-specific BreadcrumbList output may depend on Itemid. Do not paste active JSON-LD into article bodies when the template already owns the graph. Keep example markup in escaped code.

WordPress

SEO, schema, review, local-business, recipe, and ecommerce plugins can overlap with theme output. Disable or scope the duplicate source only after inventorying the final graph across representative post types and archives. Clear full-page, object, and CDN caches before validation.

Pass and fail criteria

PASS
- Every JSON-LD block parses
- Types and properties exist in the intended vocabulary
- Supported-feature requirements are met where applicable
- One coherent graph uses stable production identifiers
- Markup matches visible, current, verified content
- Final rendered DOM contains no conflicting duplicate output

FAIL
- Invalid JSON, broken escaping, or wrong data types
- Required feature property missing
- Staging, redirected, parameter, or conflicting entity URLs
- Duplicate plugins emit contradictory organizations or breadcrumbs
- Hidden or invented reviews, prices, authors, locations, or services
- Syntax passes but the selected type does not match the page

Verify and rescan

Test the final canonical URL in both validators, compare the graph with the visible page, inspect representative routes, and confirm caches do not restore the old output. Rescan the public page and monitor applicable search reports after recrawling. Validation does not guarantee a rich result or AI citation.

Sources

• Google Search Central: Structured data introduction
• Google Search Central: Structured data policies
• Schema.org validator