What is @id in JSON-LD?

An identifier for a node, written as an IRI such as https://shop.example/#organization. Nodes with the same @id describe the same entity and are merged by JSON-LD processors.

Is @id required by schema.org?

No. It is optional. Without it each node is anonymous, so other nodes cannot reference it and parsers cannot tell whether two nodes describe the same thing.

Does the @id URL have to exist?

No. It is an identifier, not a link a crawler has to open. Using a real URL with a fragment keeps identifiers unique and easy to understand.

Should the Product @id be the product page URL?

Use the page URL plus a fragment, such as #product. The page itself is a WebPage; the fragment keeps the two entities apart.

@id is part of the JSON-LD standard and processors merge nodes by it, but Google does not publish how much its systems rely on it.

Canonical definition

Entity @id in JSON-LD – Definition

@id is the JSON-LD property that gives an entity a stable identifier, so every mention of it points to the same thing. With it, the organization on your homepage, the seller on your product pages and the publisher of your articles are one entity. Without it, a parser sees several anonymous nodes that happen to share a name.

In one sentence

The identifier that turns separate schema blocks into one connected graph of your store, your products and your people.

What @id does

In JSON-LD, @id gives a node an identifier – an IRI, usually a URL with a fragment. Two nodes with the same @id describe the same thing, even when they sit in different script blocks or on different pages. A node without @id is a blank node: it describes something, but nothing else can point to it.

That is the difference between a list of facts and a graph. With @id, a parser can tell that the seller on every product page is the organization on the homepage, and that the author of every article is one person.

Without and with @id

{"@type": "Organization", "name": "Example Store"}              <- on the homepage
{"@type": "Product", "seller": {"@type": "Organization",
                                "name": "Example Store"}}   <- on a product page

Here a parser sees two organizations that happen to share a name. Now the same data as one graph:

{"@context": "https://schema.org", "@graph": [
  {"@type": "Organization", "@id": "https://shop.example/#organization",
   "name": "Example Store", "url": "https://shop.example/"},
  {"@type": "WebSite", "@id": "https://shop.example/#website",
   "publisher": {"@id": "https://shop.example/#organization"}},
  {"@type": "Product", "@id": "https://shop.example/skillet.html#product",
   "name": "Cast Iron Skillet 26cm",
   "offers": {"@type": "Offer", "price": "89.00", "priceCurrency": "EUR",
              "availability": "https://schema.org/InStock",
              "seller": {"@id": "https://shop.example/#organization"}}}
]}

A naming pattern that works

Entity	@id	Where it is described in full
Organization	`https://shop.example/#organization`	Homepage
WebSite	`https://shop.example/#website`	Homepage
Person (author)	`https://shop.example/about/#person`	About page
Product	`{product URL}#product`	Product page
Article	`{page URL}#article`	The article

Use the same @id everywhere the entity appears. Describe it in full once; elsewhere, a reference like {"@id": "https://shop.example/#organization"} is enough. Use a fragment (#product) so the Product and the page it sits on have different identifiers.

Common mistakes

No @id at all. Every Product, Organization and Person is a separate, anonymous node.
Two @ids for one thing. The theme uses /about/#person, a content block uses /#person: that is two people. We found exactly this on angeo.dev in September 2026.
The page URL as the Product @id. Then the WebPage and the Product share an identifier. Add a fragment.
Several plugins, several graphs. An SEO plugin, the theme and the content each output an Organization or Article with their own @id. Pick one source per entity.

What is known and what is not

@id is part of the JSON-LD standard, and any JSON-LD processor merges nodes by it. How much a given search engine or AI system relies on it is not published. It costs nothing to get right, and it removes ambiguity a parser would otherwise have to guess about.

On Magento 2

Magento’s default microdata and many extensions emit no @id. The web scan reports it under JSON-LD quality – whether nodes reference each other or sit in isolation – and it found exactly this gap on our own demo store: Product and Organization JSON-LD without @id. In the CLI audit, jsonld_quality checks breadcrumbs, item lists and duplicate schemas.

Questions

What is @id in JSON-LD?: An identifier for a node, written as an IRI such as https://shop.example/#organization. Nodes with the same @id describe the same entity and are merged by JSON-LD processors.
Is @id required by schema.org?: No. It is optional. Without it each node is anonymous, so other nodes cannot reference it and parsers cannot tell whether two nodes describe the same thing.
Does the @id URL have to exist?: No. It is an identifier, not a link a crawler has to open. Using a real URL with a fragment keeps identifiers unique and easy to understand.
Should the Product @id be the product page URL?: Use the page URL plus a fragment, such as #product. The page itself is a WebPage; the fragment keeps the two entities apart.
Does Google use @id?: @id is part of the JSON-LD standard and processors merge nodes by it, but Google does not publish how much its systems rely on it.

Sources

Checked 24 September 2026 against the W3C JSON-LD 1.1 recommendation and schema.org. Disclosure: we build the audit and the schema module.