Vutral
How to use this tool

Schema Markup & JSON-LD Structured Data Validator

How to use the schema markup validator

Back to the tool

One page goes in; every JSON-LD block in its raw HTML is parsed and checked against the Schema.org vocabulary.

  1. 01

    Enter the page to check

    One page per run: structured data belongs to a single page, and a stack of entity trees is not something you read side by side. Normalize URL still matters; set it to Domain only and you are reading the home page markup, not the page you pasted.

  2. 02

    Run the check on the raw HTML

    The tool fetches the page and parses the HTML it receives. It does not run JavaScript, so markup injected by a script after load is not there to find. That is why an empty result says "not found in the raw HTML" rather than "this page has no schema".

  3. 03

    Read the JSON print of the declared data

    The result is one line-numbered JSON document: the structured data as read, not the raw markup you wrote. An item referenced by @id is filled in where it is used. A line with a problem is tinted, with one icon for errors and another for warnings. Below the print, a chip per declared type highlights every block of that type.

  4. 04

    Follow the list to the exact line and export

    Under the print are the two counts and one entry per problem, ordered by line number. Each entry links to its own line in the print, so a page with thirty problems is still walkable. Copy and Export in the row above the print hand you the print itself: the download is a .json file you can paste straight back.

How to read the JSON-LD structured data report

The list answers two questions: what this page declares, and which parts of it a parser would refuse. Required fields and rich result eligibility are not judged here; the search engine decides those per rich result.

Elements of the print

@type
The Schema.org type of the item, printed as its first line, and the line an invalid type is flagged on. An item that is only a reference has no @type line: the page declared none and the print invents nothing.
@id
What tells two items of the same type apart, printed right after @type. An item referenced by @id is filled in where it is used, not repeated at the top level, so the print can be shorter than the markup.
Errors
Markup a parser would reject or ignore: a type or property that is not in the vocabulary, a value of the wrong kind, a block that is not valid JSON.
Warnings
Valid markup that is probably not what you meant: most often a property that exists but is not defined for this type. Schema.org calls those expectations, not rules, so they never become errors here.

Message reference

Type is not in the vocabulary
The @type does not exist in Schema.org: usually a typo or a name invented for the site. An item with no @type at all reports the same way, because a parser cannot do anything with either.
Property is not in the vocabulary
The property name exists nowhere in Schema.org, so nothing can read it. This is an error: the value is thrown away whatever it says.
Property is not valid for this type
The property exists, just not on this type: cookTime on an Article, for instance. Only a warning: Schema.org treats the type a property belongs to as guidance, and consumers routinely read past it.
Value does not match the expected type
The property exists and belongs here, but the value is the wrong kind of thing: a plain string where a date or a nested item was expected.
This block is not valid JSON
Reported above the list rather than inside a block, because a block that will not parse has no items to attach anything to. Everything after the syntax error is unread; one stray comma can hide the rest of the markup.
No @context pointing to schema.org
Deliberately reported here even though the reference validator stays silent. Without @context the names inside are just words, so nothing in the block could be checked, and a clean report on an unchecked block is the worst possible answer.