Identify the exact block under review

Copy the JSON inside the application/ld+json script from the final rendered page. Keep the URL and deployment revision with it. A template in your editor may differ from the published output because metadata is assembled across components. Check whether multiple blocks describe the same entity before adding another script as a quick fix.

Separate JSON validity from schema meaning

A missing comma is a syntax failure; a valid JSON object describing the wrong entity is a content failure. The local checker can report selected context, graph and type issues without contacting a remote server. Passing these checks does not establish that every property is supported or that a search feature accepts the result.

Follow identifiers through the graph

When two blocks refer to one author or website, use a stable identifier and verify that its definition is consistent. A URL-shaped identifier does not automatically make the entity a web page, and a reference alone may not provide the information a consumer needs. Inspect the author, publisher and main page separately instead of treating every URL field as interchangeable.

Compare every important claim with the page

Read the title, byline, publication date, update date, product details and visible navigation. Markup should explain these facts rather than introduce a new story. Remove invented ratings and unverified review counts. An article update date should follow a meaningful edit; rebuilding a site is not evidence that its editorial content changed.

Validate the intended feature separately

Use a schema vocabulary validator for broader type/property review, then the search engine’s feature-specific testing tool where applicable. Inspect warnings in context instead of blindly filling every possible property. Some useful schema descriptions have no rich-result presentation. Eligibility, rendering and actual appearance remain separate questions.

Keep a regression sample

Save one representative article, one tool and one breadcrumb example in your release checks. Parse their generated JSON and compare it with the source content. Include an intentionally broken example in focused tests to show that validation can fail. This catches a useful class of template regressions without creating a misleading universal SEO score.

json / WORKED EXAMPLE
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "A practical debugging example",
  "author": { "@type": "Person", "name": "Example Author" }
}

Frequently asked questions

Can I paste a whole script element?

For the OurJS basic checker, paste only its JSON value. It does not parse an HTML document.

Why does valid markup show no rich result?

Syntax is only one layer. The content, supported feature requirements and search presentation decisions also matter.

Further reading

Put the idea to work.

Explore free browser tools for images, text and developer workflows.

Try a free tool