How to check JSON-LD before publishing: syntax, meaning and page evidence

Structured data is easiest to maintain when it is treated as another representation of the page’s facts. It should describe the same article, organization and navigation that a visitor can see. A successful parser is a useful first check, but it cannot tell you whether an author is genuine, a date is accurate or a review has actually happened.

Start with the page you intend to publish

Choose the exact canonical URL and identify the page’s main job. An editorial guide, product detail, organization profile and software tool need different descriptions. List the visible facts you can substantiate before selecting types and fields. Leave out unknown ratings, offers, qualifications and authors instead of filling gaps to make a validator quieter.

Google’s structured data introduction explains that markup describes the page it appears on and should represent information visible to users. Use that as the first review rule. If a statement is missing or wrong in the body, repair the content and markup together.

Inspect the emitted document, not just the template

Build the page and open the generated HTML. Locate every application/ld+json block. Parse each block separately, then collect all of the entities into a single inventory. This catches situations where a theme, plugin and publishing formatter each output their own copy of the same organization or article.

Record the type, identifier and main URL for each entity. Check that local references point to the intended entity and that the page’s canonical, article URL and breadcrumb destination agree. Reused organization identifiers should be stable across pages; distinct articles should not share one article identifier.

A practical review sheet can have four columns: visible fact, structured field, evidence location and verdict. For example, compare the byline with author, the publication label with datePublished and the visible trail with the breadcrumb items. Mark missing evidence as a question to resolve, not as permission to invent it.

Run three different checks

1. Syntax: can every JSON block be parsed without errors, and has the template safely serialized text?
2. Vocabulary: are the selected types, properties and values appropriate for Schema.org?
3. Feature eligibility: does the page meet the current guidance for a particular Google search feature?

The Schema.org validator checks Schema.org markup generally. Google’s Rich Results Test focuses on supported search features. A type that is useful within the vocabulary need not produce a Google feature. Keep the tool name, tested URL and result alongside your conclusion so “validated” has a clear meaning.

CheckMySchema is useful for inspecting extracted markup and findings. For repeatable local checking or a hosted API route, read its Machine Interface. Combine automated findings with the visible-fact review; no parser can independently verify every editorial claim.

Apply article fields without manufacturing provenance

For an article, examine the real headline, responsible author, original publication date and any genuine modification date. Google’s Article guidance lists applicable recommended properties and accepts a Person or Organization author. Use the actual responsible entity rather than inventing an individual biography.

Keep the original publication date during migrations and ordinary formatting repairs. Add a modification date when a real update occurs. If you supply an image, verify that its URL works and that it represents the article; do not fabricate a hero image or substitute a rating merely to populate more fields.

Check navigation and actual delivery

Follow the breadcrumb links as a visitor. The trail should lead through real pages in the hierarchy, not through invented categories. Check that the article appears in its archive and that internal links use the preferred destination. Run the live HTML through the same extraction checks after deployment, because production configuration can differ from a preview build.

Google explicitly does not guarantee rich results even when markup is correct. Its general structured data policies also require accurate, relevant content. Close the task with a precise result: which blocks passed which checks, which facts were verified and which questions remain.

For the surrounding access and release checks, continue with our crawler access guide and publishing validation procedure. Correct markup is part of a maintained page, not a replacement for a useful one.