Free tool
Schema Markup Validator
Validate JSON-LD syntax and structure, pasted or read from a page, against a published rule set.
The check could not be completed
Structured data results
JSON-LD blocks
0
Entities described
0
Errors
0
Warnings
0
Summary
Block by block
Generate JSON-LD
Builds original JSON-LD from the fields you fill in. Valid JSON-LD does not guarantee eligibility for Google rich results.
Question on one line, answer on the next, blank line between pairs.
One item per line as Name | URL.
What a pass here does and does not mean
This tool checks syntax and structure against a published rule set. It does not decide whether a page qualifies for a rich result, because that depends on criteria search engines do not publish in full. For that question use the Google Rich Results Test (opens in a new tab), and for a full vocabulary check use the schema.org validator (opens in a new tab).
What This Tool Does
The schema markup validator checks JSON-LD structured data in two stages. First it confirms the markup is valid JSON-LD at all: that it parses, that it declares a vocabulary, and that each entity says what type of thing it describes. Then it checks each entity against a published set of property expectations for its type, and reports what is missing, what is empty, and what is shaped wrongly.
You can paste markup directly or have it read from a live page. Pasting is useful while you are still writing the markup, because nothing is fetched and nothing is stored.
How to Use It
Choose whether to paste JSON-LD or read it from a page, then work through the block-by-block section rather than only the summary. Each problem names the exact property path it concerns, such as "Article > author > name", so you can find it in your markup without searching.
- Paste your markup while drafting it, then check the published page afterwards to confirm your CMS output matches what you wrote.
- Read the errors first: they describe markup that cannot do its job as written.
- Treat warnings as a question rather than a task. A missing recommended property may be genuinely unavailable, and inventing a value to clear a warning is worse than leaving it out.
- Note the rule set version shown under the results, so a saved report is read against the rules that produced it.
How the Tool Calculates or Retrieves Data
Every application/ld+json block is read as text. Nothing from the analysed page is executed, and no markup from it is ever rendered back into this page as HTML. The JSON is parsed with a depth limit, and blocks beyond a fixed size or count are reported as skipped rather than being silently dropped.
Validation runs against a rule set defined inside Searqo and versioned, so results stay reproducible. That rule set records, for each supported type, which properties are treated as required because the entity does not identify its subject without them, and which are treated as recommended because consumers commonly expect them. It is derived from the schema.org type definitions and from the structured data requirements search engines publish. A type outside the rule set is reported as such: only its syntax and value formats are checked, and that is stated rather than being presented as a pass.
Values are checked for shape as well as presence. Properties that must be absolute URLs are rejected when they hold a relative path, and date properties are rejected when they are not ISO 8601. Nesting mistakes that appear constantly in real markup are checked directly: an author given as a bare string, a price with no currency, an aggregate rating with no count, a breadcrumb with no positions, an FAQ question with no answer.
Understanding Your Results
Syntax validity and structural completeness are reported separately, because they fail differently. A block that does not parse is discarded in full, so everything in it is lost rather than just the broken part; that is why a single stray comma can remove all of a page's structured data at once. A block that parses but is missing a required property is being read, and simply describes less than it appears to.
Duplicate entities are flagged because they are usually accidental. Two plugins each describing the same organisation, or the same @id used twice, leaves consumers unable to tell which description is authoritative.
A clean result means the markup is well formed and complete against this rule set. It does not mean a search engine will show a rich result for the page.
Frequently Asked Questions
No, and no tool can tell you that. Valid markup is a precondition, not a guarantee. Search engines decide which pages receive a rich result using criteria they do not fully publish, and they can stop showing one for a page that has not changed.
Because a JSON-LD block is parsed as a whole. If the parse fails anywhere in the block, the entire block is discarded, so every entity in it disappears rather than only the faulty property. A trailing comma or a curly quote pasted in from a word processor is enough.
An error means the markup cannot do its job as written: it does not parse, it declares no type, or it lacks a property this rule set treats as required for that type. A warning means something commonly expected is absent or empty. Warnings are worth reading, but clearing one by inventing a value is a step backwards.
Either works. Several separate blocks are valid, and so is a single block using @graph to relate the entities to one another. What matters is that entities are not duplicated across them, since duplication leaves consumers no way to know which description to trust.