What does @context do in JSON-LD?

It maps the document's keys onto a vocabulary, so that a key such as name refers to a globally defined term rather than an arbitrary label.

Can I have several JSON-LD blocks on one page?

Yes, and consumers combine them. Using a single @graph with @id references is usually clearer than several blocks repeating the same objects.

Where should the script block go?

Either the head or the body is valid. The head is conventional and makes it easier to confirm the block is in the served HTML.

Glossary

JSON-LD

JSON-LD is a W3C standard for expressing linked data as ordinary JSON, using a small set of reserved keywords to give the keys global meaning. On the web it is the usual way to publish structured data: a `<script type="application/ld+json">` block whose `@context` points at a vocabulary such as schema.org, so that a key like `name` means a defined thing rather than whatever the author intended.

The keywords that do the work

`@context` maps the document's keys onto a vocabulary. `"@context": "https://schema.org"` makes every subsequent key a schema.org term.

`@type` states what the object is: `Article`, `Product`, `BreadcrumbList`.

`@id` gives the object a global identifier, normally a URL. It is what lets one block refer to an object defined in another rather than repeating it.

`@graph` holds several objects in one block, which is how a page describes an article, its publisher and its breadcrumb trail together without three separate scripts.

Why it is preferred over inline annotation

It is separate from the markup. Microdata and RDFa annotate the HTML elements themselves, so a redesign that changes the markup can silently break the data.

It can be generated from the same source as the page content, which makes divergence between the two a bug in one place rather than a drift in two.

It can be validated as a standalone document, and it can be read without parsing the HTML around it.

Those are the reasons Google's documentation gives for preferring it, and the pattern of a single `@graph` block in the head is now the common shape.

Where it goes wrong

Invalid JSON. A trailing comma or an unescaped quote makes the whole block unreadable, and the failure is silent — nothing renders differently.

A missing or wrong `@context`, which leaves the keys with no defined meaning.

Values that do not match the page, which is a guidelines violation regardless of whether the JSON is valid.

Duplicate objects describing the same thing differently across several blocks, where consumers have no rule for choosing between them. Using `@id` to link rather than repeat avoids it.

Dates in the wrong format: schema.org date properties expect ISO 8601, and a localised date string is read as an arbitrary text value.

How to check it

Extract the block and parse it with any JSON tool. A parse error is the first thing to rule out and the easiest to miss.

The Schema Markup Validator checks the vocabulary, and Google's Rich Results Test checks eligibility for specific result types.

Compare each value against what the page displays. The markup is a claim about the page, and a claim that is out of date is worse than none.

Check the rendered DOM as well as the source if the block is injected by JavaScript.

Frequently asked questions

What does @context do in JSON-LD?: It maps the document's keys onto a vocabulary, so that a key such as name refers to a globally defined term rather than an arbitrary label.
Can I have several JSON-LD blocks on one page?: Yes, and consumers combine them. Using a single @graph with @id references is usually clearer than several blocks repeating the same objects.
Where should the script block go?: Either the head or the body is valid. The head is conventional and makes it easier to confirm the block is in the served HTML.

Sources

VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.

Scan a website