Most schema implementations look correct at first glance. The Organisation block is there. The Person blocks are there. The Product blocks are there. All the required properties are filled in. The Rich Results Test shows no errors.
And yet the entity recognition does not improve. The Knowledge Graph confidence stays low. The LLM citations do not increase. The structured data is technically valid and operationally useless at the same time.
Almost always, the missing piece is the @id property. It is the single most important technical element of structured data for entity recognition, and it is also the one most teams skip. This post explains what @id does, why your entity graph falls apart without it, and how to implement it properly.
What @id actually is
@id is a property in JSON-LD (and the underlying RDF specification) that assigns a unique, stable identifier to an entity. The identifier is a URI — usually a URL — that serves as the canonical reference for that entity across all the schema markup on your site.
In schema.org JSON-LD, it looks like this:
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://acmecorp.com/entity/organization/acme-corp",
"name": "Acme Corp"
}
The @id URI does not have to resolve to a real page (though it often does). What matters is that the URI is unique to this entity and stays stable over time. Every time the entity is referenced in schema markup anywhere on your site, that reference uses the same @id.
What happens without @id
Consider a site that mentions Acme Corp on the homepage, the about page, the team page, and in every blog post footer. Each page has its own Organisation schema block. None of them use @id.
When AI systems crawl the site, they see fifty separate Organisation declarations that happen to share the name “Acme Corp.” The system has to infer that these are the same organisation. Most of the time it gets the inference right — but “most of the time” is not the same as “always,” and the confidence in each individual mention stays lower than it should be.
Now imagine the homepage Organisation block says the company was founded in 2018, and the about page block says 2017. Without @id, the system has no way to know which is the canonical fact. It might pick one, it might keep both as possibilities, it might lower confidence in the entity overall. The inconsistency creates exactly the kind of ambiguity that prevents confident citation.
Multiply that across every entity on your site — every Person, every Product, every Article — and you have a structured data implementation that produces noise instead of signal.
What happens with @id
Now consider the same site with @id properly implemented. Every mention of Acme Corp references the same URI: https://acmecorp.com/entity/organization/acme-corp. The fifty mentions become one entity that is referenced fifty times.
When AI systems crawl the site, they see a coherent picture. The Organisation entity is declared once with its canonical attributes, and every other page references that entity through its ID. The CEO’s Person schema declares worksFor with the Organisation @id. The Product schema declares brand with the Organisation @id. The Article schema declares publisher with the Organisation @id.
Authority accumulates instead of fragmenting. Every article reinforces the publisher. Every product reinforces the brand. Every employee reinforces the organisation. The graph becomes traversable in a way that flat schema markup never can.
The URI structure that works
Standard URI structure for @id:
https://yourdomain.com/entity/{type}/{identifier}
A few specific patterns:
- Organisation:
https://acmecorp.com/entity/organization/acme-corp - Person:
https://acmecorp.com/entity/person/jane-smith - Product:
https://acmecorp.com/entity/product/acme-platform - Concept:
https://acmecorp.com/entity/concept/bridge-framework - Location:
https://acmecorp.com/entity/location/san-francisco-office
Rules:
- Lowercase, hyphenated. No spaces, no capitalisation, no special characters.
- Stable. This URI should never change after the entity is launched. URI stability is what allows AI systems to maintain recognition over time.
- Unique. Each entity gets exactly one
@id. No two entities share one. - Hierarchical. The structure
/entity/{type}/{identifier}makes the URI scheme self-documenting and prevents collisions between different entity types that might share names.
The URI does not have to point to an actual page, though it often does — a Person @id might also be the URL of that person’s author page. Either way works, as long as the URI is stable.
Common @id mistakes
A few patterns to watch for.
Inconsistent capitalisation or formatting. The Organisation block uses https://acmecorp.com/entity/Organization/Acme-Corp and the Person block references https://acmecorp.com/entity/organization/acme-corp. URIs are case-sensitive. These are two different URIs and the connection breaks.
Using page URLs instead of stable entity URIs. Some implementations use the page URL as the @id. The problem is that page URLs change — the company restructures the site, the URL slug changes, the page moves. Now the @id references no longer match the canonical entity, and the graph breaks. A separate URI scheme dedicated to entities (under /entity/) is more resilient.
Reusing the same @id for related but distinct entities. A team often makes this mistake when treating a product line as a single entity rather than as several related but distinct products. The result is a single @id referenced across what should be multiple entity declarations, which AI systems read as confused signal rather than coherent structure.
Skipping @id for “minor” entities. A common pattern is using @id for the Organisation but not for individual Articles or Products, on the assumption that minor entities do not need it. The problem is that without @id on those entities, you cannot establish proper worksFor, brand, author, or mentions relationships that reference them. The graph degrades from one missing link.
How to retrofit @id to an existing schema implementation
If your existing schema markup does not use @id, you do not have to rebuild from scratch. A practical retrofit sequence:
- Define your URI scheme. Document the URI pattern you will use for each entity type. This becomes the rule everyone follows.
- Catalogue your Tier 1 entities. Organisation, founders, CEO, flagship products, primary location. Five to ten entities is usually the right scope to start with.
- Assign
@idURIs to each Tier 1 entity. One canonical URI per entity, documented in a single source of truth. - Update Organisation schema first. Add the
@idto your Organisation block in every place it appears. - Update Person schema next. Add
@idto Person blocks and updateworksForproperties to reference the Organisation@id. - Update Product schema. Add
@idto Product blocks and updatebrandproperties to reference the Organisation@id. - Update Article schema. Add
@idand updateauthorandpublisherproperties to reference the Person and Organisation@ids. - Validate. Run Google’s Rich Results Test and the schema.org validator on the updated pages. Every reference should resolve cleanly.
The work is methodical, but it does not have to happen all at once. Tier 1 first, then Tier 2 (senior team, core products, key concepts), then Tier 3 (everything else).
Why this is the highest-leverage technical move
Most structured data work produces diminishing returns. The first schema implementation matters a lot. The fiftieth markup tweak rarely moves the needle.
@id is different. Adding it to existing schema typically produces the most significant entity recognition improvement of any single technical change, because it converts existing markup from isolated declarations into a connected graph. The data was already there. It just was not connected.
If you only do one technical entity SEO project this quarter, this is the one to do.
Continue your learning (MLforSEO)
This post covered what @id is, why it is critical for entity recognition, and how to retrofit it to an existing schema implementation. The complete schema templates with @id patterns, the URI structure that scales across hundreds of entities, the validation workflows, and the BRIDGE framework that organises the full system are in the AI Search & LLMs: Entity SEO and Knowledge Graph Strategies for Brands course on MLforSEO.
Enrolling also gets you into the dedicated course channel inside the MLforSEO Slack community, where Beatrice Gamba and Lazarina Stoy answer course-specific questions and discuss ongoing implementation projects with course-takers.
Beatrice Gamba
The future of search and content discovery will be dialogical, personalized and agent-mediated. Digital leaders need to start integrating these concepts in their strategies to be ready for what’s coming.
- Beatrice Gamba
- Beatrice Gamba
- Beatrice Gamba
- Beatrice Gamba
