How to Check Structured Data Beyond Whether the JSON Parses

When you add schema markup to a web page, a JSON parser can tell you whether the code follows JSON syntax. Schema markup is machine-readable information that describes page content, such as a product, event, or organization. A syntax check does not tell you whether that description is accurate, follows the right structure, or qualifies for a Google search feature.

First, confirm that the markup describes the visible page and validate its structure. Then test the live page for supported search features and compare the result with what Google has indexed. Each check answers a different question, and passing one does not guarantee a rich result in Search.

A valid JSON file can still describe the page badly

JSON-LD is a way to express structured data using JSON. Its context explains what its terms mean. Its properties describe entities, the things the markup represents, and how they relate to one another. A parser checks the JSON syntax, but it does not determine whether those terms and relationships make sense for the page. The JSON-LD processing specification describes how processors interpret JSON-LD and turn it into linked data.

For example, a product page’s markup might parse successfully while naming the wrong product, giving an outdated price, or attaching a rating to the wrong item. These are meaning and accuracy problems, not JSON errors. Google’s structured data policies require markup to represent page content accurately and to follow the relevant feature’s guidelines.

Start by comparing the important claims in the markup with the page a visitor sees. Check that the marked-up entity is the page’s subject. Then compare names and dates with the page, and make sure visitors can see the information. A validator can find some structural problems; it cannot reliably judge whether a claim is true or whether the markup reflects the page fairly.

Use the validator that matches the question

The Schema.org Markup Validator checks whether it can extract Schema.org terms and relationships from markup. Use it to inspect the structured data graph: the things (entities) the markup describes and the connections between them. The Schema.org validator can test a URL or pasted markup and supports JSON-LD, Microdata, and RDFa. Its documentation also notes a limit: for JSON-LD, it does not fetch or interpret other URLs listed in @context.

Google’s Rich Results Test answers a narrower question: whether the tested page contains markup for a rich-result feature Google supports and whether it meets that feature’s technical checks. Google distinguishes these tools in its structured data testing guidance: use the Rich Results Test for Google rich-result features and the Schema.org validator for broader Schema.org checks.

Each tool answers only the question it was designed to test. A Schema.org validator finding does not establish Google rich-result eligibility. A Rich Results Test result does not confirm that every detail is accurate or that the page follows all quality policies. Check Google’s current supported structured data features before treating a Schema.org type as a route to a specific Search display.

Test the live page, including rendered markup

A code sample can pass a test while the deployed page serves different markup. Test the public URL when possible, especially when JavaScript generates the structured data. Google recommends testing the URL for JavaScript implementations because pasted code does not show what the live page produces. If the test does not show the markup, inspect the page’s rendered HTML after its code runs and confirm that it contains the expected data. Google’s instructions for structured data generated with JavaScript explain this distinction.

Also confirm that Google can access the page. A blocked page or a noindex directive affects whether Google can use it in Search, regardless of whether a local code sample validates. Google’s general guidelines cover accessibility and other conditions that apply to structured data.

If the test result is unexpected, check the live page, not just the source file or template. Look for missing markup in the rendered HTML, differences between the live page and the code you tested, and access restrictions that prevent Google from fetching the page.

Compare live tests with Google’s indexed view

Search Console’s URL Inspection tool reports on two versions of a page: the one Google last crawled and the one it can fetch now. Its indexed view reflects what Google learned from the version it last crawled. Its live test checks what Google can fetch now. Google explains the distinction in its guidance to inspect and troubleshoot a single page.

If the live test passes but the indexed view still reports an earlier issue, the two results do not conflict: one describes the current test, while the other describes Google’s stored information. A successful live test does not prove that Google has already recrawled or updated its index. Use the indexed view to see what Google has processed. Use the live test to check the page Google can fetch now.

Search Console’s rich-result reports help monitor detected issues over time, but Google describes them as samples of detected items, and their totals count items rather than pages. The rich result report overview explains those limits. Treat the reports as monitoring evidence, not as a complete inventory of every marked-up page.

What each result tells you

A useful diagnosis keeps each result within its scope:

A valid result means the tested layer passed. Google still decides whether to show a rich result, and a page that passes a test is not guaranteed to appear with an enhancement. Its structured data policies distinguish technical eligibility from actual display.

Common failures and what to check next

When markup parses but a validator reports an issue, check how it organizes information. A property might have the wrong kind of value. An item might be nested under a type that cannot contain it, or the markup might be missing a required field. Google documents examples of these problems in its rich result error messages.

If Schema.org validation succeeds but the Rich Results Test does not recognize a feature, check whether Google currently supports that feature and whether the markup meets its specific requirements. If a URL test does not show markup that appears in your code, inspect the rendered page and confirm that the live version includes it. If the live test succeeds while Search Console’s indexed view shows old data, check the indexed version separately rather than treating the live test as proof of an updated index.

A test can pass even when the marked-up information is inaccurate, hidden from visitors, or different from what the page says. Review those cases against the visible content and Google’s policies; syntax tools cannot settle them. And if all checks pass but no rich result appears, the result can still be consistent with Google’s stated policy that eligibility does not guarantee display.

What structured data does not guarantee

Structured data helps search engines interpret page information and can make a page eligible for supported rich results. Passing a test does not guarantee a particular search display or establish a ranking improvement. Google’s documentation recommends measuring Search performance on the site instead of assuming that adding markup improves it.

For AI search, Google says its AI Overviews and AI Mode do not require special Schema.org markup or additional technical requirements. Its guidance for AI features still recommends that structured data match visible page content. Accurate markup helps describe the page clearly, but it does not guarantee that an AI answer will include the page or cite it.

Key Takeaways

• Compare markup with the page: Check that the marked-up subject and its details match information visitors can see.
• Use separate validators: The Schema.org Markup Validator checks vocabulary and extraction; Google’s Rich Results Test checks supported Google features.
• Test the live URL: Confirm that the deployed, rendered page contains the expected markup, especially when JavaScript generates it.
• Separate live and indexed evidence: URL Inspection’s live test reflects a current fetch, while its indexed view reports what Google last processed.
• Treat eligibility as a condition, not an outcome: A passing test does not guarantee a rich result, a ranking gain, or an AI-search citation.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com