Fix schema markup in layers. Make the JSON readable first. Then confirm the Schema.org vocabulary. Then compare every claim with the visible page. Only after that should you chase feature-specific warnings.

A long validator report feels like one large failure. It usually contains several different kinds of problem. Separating them keeps a missing comma from turning into an afternoon of random edits.

Start with the block in front of you. Paste it into the Schema Markup Checker to find parsing problems, types, identifiers, and canonical disagreements before opening the official validators.

First decide which layer failed

Problem layerTypical messageFirst move
JSON formatParsing error or invalid JSONFix punctuation and escaping
Schema.org vocabularyUnknown property or wrong expected typeCheck the type and property definition
Google featureMissing required fieldRead the guide for that supported feature
Page accuracyMarkup does not represent the pageCorrect the page or remove the claim
Graph identityDuplicate or conflicting entityReconcile IDs and names

Invalid JSON stops the whole block

When a block cannot be parsed, no validator can reliably inspect the schema inside it. Common causes include:

  • A missing comma between properties
  • An extra comma before a closing brace or bracket
  • A quote inside text that was not escaped
  • Curly quotes copied from a word processor
  • A missing closing brace or bracket
  • Two top-level objects pasted together without a list or graph
  • HTML script tags pasted into a field that expects only JSON

Fix the first parsing error and run the test again. One missing character can create several later messages that disappear as soon as the parser can read the block.

The JSON-LD format guide explains each punctuation mark and value type.

Unknown properties and wrong expected types

An unknown property may be misspelled, attached to the wrong type, or taken from a vocabulary the validator is not checking.

Open the Schema.org page for the declared type. Confirm that the property belongs on that type or one of its parents. Then check what kind of value the property expects.

For example, an author property normally points to a Person or Organization. A plain name may be accepted in some contexts, but a connected entity with a stable ID and name says more clearly who the author is.

Required and recommended fields belong to a feature

Google feature guides label some properties required and others recommended. A missing required property can block eligibility for that feature. A recommended property may improve completeness without making the Schema.org object invalid.

Do not add a value only to silence the tool. If a product page has no visible price, inventing one for an Offer makes the data worse. Add the real offer to the page or remove the unsupported Offer.

Valid markup can still misdescribe the page

A parser cannot tell whether a review is real, whether a price is current, or whether an FAQ is visible. Compare the markup with the public page.

  • Names should match the entity shown.
  • Dates should describe the current publication or event state.
  • Prices and availability should match the offer a visitor can use.
  • Questions and answers should be visible when the page claims FAQ content.
  • Images should belong to the subject and remain accessible.
  • The canonical URL should identify the page being described.

When the page and markup disagree, fix the source that is wrong. Do not choose the version that makes the validator look cleaner.

Duplicate entities and conflicting @id values

Several plugins or templates may publish their own Organization, WebSite, WebPage, and Article nodes. Multiple blocks are not automatically wrong. The problem begins when they create competing identities.

Watch for:

  • The same organization using several IDs
  • One ID attached to different names or types
  • Two canonical WebPage nodes for one URL
  • An Article pointing to a publisher that is never defined
  • Relative IDs that resolve differently across pages
  • A staging hostname left inside production markup

Choose one canonical ID for each recurring entity. Merge matching facts. Remove or rewrite the source that keeps creating a second identity.

A warning is not always an error

Tools often report optional or recommended properties. Read the exact wording. A warning can identify a worthwhile improvement, but it does not always make the item invalid.

Add a recommended property when the page genuinely supports it and the added information helps describe the entity. Do not pad the graph with empty, guessed, or invisible values.

Fix the generator, not only one rendered page

If the same failure appears across many pages, the source is probably shared. It may be a template, plugin, helper, or content field.

  1. Find the code or record that creates the bad value.
  2. Correct the shared source.
  3. Render several representative pages.
  4. Confirm the fix did not remove richer page-specific data.
  5. Crawl the affected page set and look for remaining exceptions.

Hand-fixing one public block hides the system problem. The next rebuild will bring it back.

Use the official tools in the right order

  1. Use the AItoAIWeb Schema Markup Checker for the first block inventory and common problems.
  2. Use the Schema.org Markup Validator for vocabulary and graph extraction.
  3. Use the Google Rich Results Test for supported feature rules.
  4. Use URL Inspection and Search Console reports after publication.

If every tool is clean and the rich result still does not appear, continue with Why Schema Markup Is Not Showing in Google.