Structured data check

A second copy of the page, written for machines

Show a person a product page and they know right away which number is the price and which is the stock count. A program just sees text. Structured data spares it the guessing. Next to the visible page, you publish the same facts as labeled fields, using names from the shared vocabulary at schema.org. This thing is a Product, its name is this, its offers hold a price of 49.00 in USD.

There are three ways to write it. JSON-LD puts everything in one script tag, separate from the layout, and it’s the form Google recommends. Microdata and RDFa spread the labels over the HTML tags as attributes.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How tides work",
  "datePublished": "2026-03-14T09:30:00+00:00",
  "author": { "@type": "Person", "name": "Jane Doe" }
}
</script>

Search engines use these fields to draw richer results, with review stars, a price, a recipe photo or an event date. Those are called rich results.

What this check reads

Our server downloads the page once, up to 3 MB, and doesn’t run its scripts. Then it works in four steps.

1. Syntax. Each JSON-LD block goes through a strict JSON reader. At the first fault it gives the line, the character and the likely cause: a comma before a closing brace, a quote inside a text that wasn’t escaped, curly quotes pasted from a word processor, an HTML comment, a raw line break. One fault is all it takes for a parser to drop the whole block.
2. Items. @graph lists are opened up so that every item is shown separately, with its type and an outline of its properties. A property that points to another item with @id is followed when the target is on the page.
3. Properties. For the types that feed a rich result, the item is compared with a list of required and recommended properties taken from Google’s documentation.
4. Values. In every item, addresses have to be absolute, dates and durations have to follow ISO 8601, @context has to be schema.org, and each @id pointer has to lead somewhere.

Microdata (itemscope, itemtype) and RDFa (typeof) are counted and named by type. Their properties aren’t validated.

The types we compare, and what they need

Other types are outlined and their values checked, without a list of required properties.

Repairing what the report shows

A syntax fault

Blocks edited by hand break on commas and quotes. Generate the block with a JSON encoder (json_encode in PHP, JSON.stringify in JavaScript) and that whole family of faults goes away. In a CMS, paste JSON-LD into a code field. Never use the visual editor for it, because it curls the quotes.

A required property is missing

Add it, with the value a visitor can see on the page. Search engines compare the two, and markup that describes something the page doesn’t show can earn you a manual action.

A relative address

Write https://www.example.com/img/cover.jpg in full, not /img/cover.jpg.

A date that is not ISO 8601

Year first, then T, then the time and the offset from UTC: 2026-03-14T09:30:00+00:00. A day alone, 2026-03-14, is valid too.

A pointer to nowhere

"author": {"@id": "…/#jane"} only works if an item with that exact @id is on the same page. Add the item, or write the author in place.

What this check can’t tell you

It reads the HTML as delivered. Structured data added afterwards by JavaScript or by a tag manager is invisible here, though Google may see it after rendering. Images aren’t downloaded, so a broken or undersized image goes unnoticed. The lists of properties cover the common result types. They don’t cover every type or every optional field.