Structured Data Testing Tools for Different Checks

Structured data testing tools answer different questions: whether the data can be parsed, whether it uses Schema.org sensibly, and whether Google recognizes a supported rich-result feature. Choose the tool for the question instead of treating every green check as the same result.

A small JSON-LD document is enough to see the distinction:

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "A small static website",
  "url": "https://example.com/static-website/"
}

This is a parser example, not a complete template for a Google rich result. Replace the example content before using it on a real page.

Choose structured data testing tools by the check you need

The most useful starting tools are:

Google’s testing-tool guidance explicitly distinguishes general Schema.org validation from Google-specific testing. The older Google Structured Data Testing Tool became the Schema Markup Validator; it should not remain the first recommendation under its retired name.

I would start with the smallest failing example. It is easier to diagnose one entity than several unrelated graphs injected by a theme, plugin, and client-side widget.

Validate the JSON before investigating search features

Save the opening example as sample.json. A local syntax check can catch a trailing comma or missing quote:

python3 -m json.tool sample.json

That confirms JSON syntax only. It does not validate the Schema.org vocabulary, check whether the named page exists, or establish eligibility for a search feature.

When publishing JSON-LD in HTML, it belongs inside a script element:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "A small static website",
  "url": "https://example.com/static-website/"
}
</script>

Generate the values through the template system’s JSON facilities rather than assembling quoted strings by hand. A title containing quotation marks should remain data, not become a broken script.

The JSON-LD introduction covers publishing the markup. The testing job is to verify what the generated page actually contains.

Inspect the extracted entity and its relationships

The Schema Markup Validator documentation describes extraction of JSON-LD, Microdata, and RDFa. Its output lets you inspect which entities and values the page expresses.

Check the type, names, URLs, and relationships. Read the data as a description of the page, not as a collection of properties to accumulate until warnings disappear.

A valid string can still contain the wrong article title. A valid URL can identify the homepage when the object is supposed to describe an individual post.

If the page contains several entities, stable identifiers and correct relationships matter more than adding the same author or organization in several disconnected places. Keep the graph as small as the content requires.

Use Google’s test for its supported features

Rich Results Test checks Google-specific requirements and can report detected supported items. Its result has a different scope from a general Schema.org parser.

Google’s structured data policies require the markup to represent the page’s content and make clear that correct markup does not guarantee a rich result.

The opening WebPage example is deliberately small. A parser reading it successfully is not a promise that Google will show a special listing for that page.

Check the documentation for the particular feature you are implementing before adding properties to satisfy an unrelated example. An article, product, and event need different information because they describe different things.

Test the deployed URL as well as a pasted snippet

A pasted sample can work while the published page contains stale or duplicate markup. Test the public URL after deployment and compare the extracted values with the visible content.

Authentication, redirects, blocked resources, and template differences can explain why the fetched page differs from a local file. Inspect the response before blaming the vocabulary.

Search Console URL Inspection answers another question: what Google knows about a specific URL and its indexed state. A live check and previously indexed data are different views; neither should be confused with the static snippet you pasted into a validator.

The Schema.org overview explains the vocabulary’s role. Keep its meaning aligned with the actual page throughout the publishing workflow.

Keep specialist tools for their own formats

JSON-LD Playground is useful when the problem involves context, expansion, or another JSON-LD transformation. RDFa Playground is useful for inspecting data expressed through HTML attributes; its own page labels the tool as beta, so treat it as an aid to inspection rather than a production guarantee.

Google’s Structured Data Markup Helper can generate a starting sample. Review that sample against current feature documentation before turning it into a site-wide template.

For email, use the Gmail schema-testing guidance and its Email Markup Tester. Email markup is a different implementation context from an article page.

Facebook’s Sharing Debugger checks sharing-preview information. It is useful for Open Graph problems, but its preview is not a substitute for Schema.org validation or Google eligibility testing.

Retire tools that no longer answer the current question

Older lists included standalone Bing and Yandex validators, browser extensions, format converters, and small Microdata parsers. Some belong to historical workflows, while others require current platform access or maintenance checks before they can be recommended.

A new implementation does not need every tool from that older catalogue. Keep a general validator, the search engine’s relevant test, and a format-specific playground when the actual problem requires it.

The useful outcome is consistent, accurate data on a page that can be fetched and understood. A longer list of green checks is not evidence that the page deserves another search feature.

← Back to all articles