What Is @id in JSON-LD? Giving Your Entities a Stable Identity

An e-commerce site has 200 product pages. Each page includes a JSON-LD block for the product and another block for the Organization that sells it. The Organization block — company name, logo, address — is copied identically onto all 200 pages. No @id property anywhere. Google crawls the site and encounters 200 Organization blocks with the same name and address. Are these 200 separate organizations, or one organization mentioned 200 times? Google's answer is "probably one" — but "probably" is not a data structure. It is a guess.

@id in JSON-LD eliminates the guess. It assigns a URI — a unique identifier like https://example.com/#org — to the Organization entity. Every other JSON-LD block on the site that needs to reference that Organization points to the @id URI instead of re-declaring all its properties. Google does not need to infer that 200 identical blocks describe the same entity. The @id tells it explicitly: this is one entity, defined once, referenced everywhere.

The W3C JSON-LD 1.1 specification defines @id as the property that assigns an IRI (Internationalized Resource Identifier) to a node. In practical SEO terms: @id is how you give your business, your website, or any entity in your structured data a permanent address in Google's Knowledge Graph.

Without @id, Google Has to Guess Entity Identity

When a JSON-LD block has no @id, it describes an anonymous entity — an entity with properties but no stable identifier. If Google encounters the same anonymous entity on multiple pages, it must run entity resolution: comparing the name, address, URL, and other properties to determine whether these blocks describe the same real-world thing.

Entity resolution works well enough for simple cases. If every page on your site has an Organization block with the name "Sunrise Bakery" and the same address, Google will likely merge them into one entity. But "likely" introduces fragility. Add a slight variation — one page uses "Sunrise Bakery LLC," another omits the address — and the resolution becomes uncertain. Google may split the entity, creating two or more partial records in its Knowledge Graph where one complete record should exist.

The problem scales with site complexity. A multi-location business with separate LocalBusiness blocks per location and a parent Organization block needs Google to understand the hierarchy: these four LocalBusiness entities are branches of this one Organization. Without @id, Google sees four LocalBusiness blocks and one Organization block with no explicit connection between them. The hierarchy is invisible.

Scenario	Without @id	With @id
Organization on 50 pages	Google infers "probably the same entity" from matching properties	All 50 blocks share one @id URI — identity is explicit
Product references its manufacturer	Product block repeats all Organization properties inline	Product's manufacturer field points to {"@id": "https://example.com/#org"}
BreadcrumbList on every page	Each page defines a new anonymous WebSite entity	All breadcrumbs reference the same WebSite via its @id
Multi-location business	Google cannot link LocalBusiness blocks to parent Organization	parentOrganization field references the Organization's @id
Person (founder) on About + blog posts	Google may create duplicate Person entities	One @id for the Person, referenced from author fields across the site

Google's Organization structured data documentation does not list @id as a required property. It is technically optional. But "optional" in a schema spec means "your markup will validate without it" — not "you do not need it." The validation is the floor. Entity resolution accuracy is the ceiling, and @id raises it.

Cross-Page References: How @id Connects Your Schema Graph

The real power of @id is not labeling entities — it is enabling references between them. Once an entity has an @id, any other JSON-LD block on any page of your site can point to it without redeclaring its properties. This turns isolated blocks into a connected graph.

The pattern is: define once, reference everywhere. Your homepage defines the Organization with all its properties and an @id. Every other page that needs to mention the Organization — product pages, blog posts, contact pages — includes only the @id reference:

<!-- Homepage: full definition -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#org",
  "name": "Sunrise Bakery",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/sunrise-bakery",
    "https://www.facebook.com/sunrisebakery"
  ]
}
</script>

<!-- Product page: reference only -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Sourdough Loaf",
  "manufacturer": { "@id": "https://example.com/#org" }
}
</script>

The product page's manufacturer field contains a single line: {"@id": "https://example.com/#org"}. Google resolves this reference by looking up the entity with that @id — either from the same page or from other pages it has crawled on your site. The product is now explicitly linked to the Organization. No property duplication, no inference required.

The JSON-LD specification calls this "node referencing" — using an @id value to create a link between two nodes in a graph without duplicating data. In SEO terms, it means your structured data becomes a connected graph rather than a collection of isolated blocks. This reference pattern extends to every entity type. A blog post's author can reference a Person defined on the About page. A FAQ page's mainEntity items can reference the Organization that provides the answers. A sameAs declaration on the Organization connects it to external platforms, while @id connects it to internal pages. Together, they build a web of references that Google can traverse to build a complete picture of your entity.

URI Conventions and Common @id Mistakes

An @id value is a URI — but it is an identifier, not a URL you expect users to visit. The convention in SEO structured data is to use your domain with a hash fragment: https://example.com/#org for your Organization, https://example.com/#website for the WebSite entity, https://example.com/about/#founder for a Person defined on the About page.

The hash fragment matters. In HTTP, everything after the # is a fragment identifier that the browser (and Googlebot) does not send to the server. https://example.com/#org resolves to https://example.com/ — your homepage. This is intentional: the @id says "the entity identified as #org on the homepage." It is a naming convention, not a navigation target.

Common mistakes that break the reference chain:

Mistake	Example	Why it breaks
Different @id values for the same entity on different pages	Homepage uses /#org, product page uses /#organization	Google sees two different entities — the reference chain is split
Using a non-existent URL as @id	"@id": "https://example.com/entity/org" (returns 404)	While @id does not need to resolve, a 404 path can confuse crawlers that attempt to fetch it
Omitting the domain	"@id": "#org" (relative fragment)	Relative URIs are resolved against the page URL — #org on /about becomes /about#org, different from /#org on the homepage
Using the page URL as @id	"@id": "https://example.com/about"	This identifies the page, not the entity. The About page and the Person described on it are different things
Mixing HTTP and HTTPS	Some blocks use http://, others https://	Different protocols = different URIs = different entities

The safest pattern is to define a small set of @id URIs and document them. A typical site needs three: /#org (Organization), /#website (WebSite), and optionally /#breadcrumb (BreadcrumbList template). Location pages add /locations/downtown/#location. Person entities use the page where they are defined: /about/#founder. Write these down, use them consistently across every JSON-LD block, and verify that references resolve to the correct definition.

Google Search Central's structured data documentation uses @id in its Organization and WebSite examples, signaling that Google's own tooling expects and processes this property. Sites that omit it are not penalized — they are leaving entity resolution to chance instead of declaring it explicitly.

MendMySEO audits every JSON-LD block on your site for missing @id properties, inconsistent URI values, and broken cross-page references that prevent entity consolidation. Join the waitlist.

Frequently Asked Questions

Does @id directly improve rankings?

@id does not function as a ranking signal in the way backlinks or page speed do. Its effect is structural: it helps Google correctly identify and consolidate your entity across pages, which can lead to Knowledge Panel eligibility, richer SERP presence, and more accurate entity association. The benefit is in entity confidence, not position signals.

Can I use any URI as an @id value?

Technically, any valid IRI works. Practically, use your own domain with a hash fragment (https://yourdomain.com/#org). Using third-party URLs (like a LinkedIn profile URL) as @id creates confusion — the @id identifies your local entity definition, while sameAs links it to external representations. Keep @id on your domain, use sameAs for external platforms.

Do I need @id on every JSON-LD block?

Not every block benefits equally. Prioritize @id for entities that appear across multiple pages: Organization, WebSite, Person (if used as author). One-off entities like a single Product on its own page or an FAQ block benefit less because there is no cross-page reference to resolve. Add @id to those too for completeness, but the high-value targets are the shared entities.

What happens if two different entities share the same @id?

Google treats same @id as same entity. If your Organization and your LocalBusiness both use /#org, Google merges their properties — which may create conflicting type declarations. Each distinct entity needs its own @id: /#org for the Organization, /#business for the LocalBusiness, /#website for the WebSite.

Is @id the same as the url property?

No. The url property tells Google where to find the entity's primary web page — it is a clickable address for humans. @id is a machine identifier for the entity itself — it is a label for Google's internal graph. A Person's url might be /about (where their bio lives), while their @id is /about/#founder (which identifies the Person node, not the page). One is an address. The other is a name.