The @id Property in JSON-LD: How to Give Your Entities Stable Identifiers

The @id property in JSON-LD is a globally unique identifier you assign to an entity so that search engines and AI systems can recognize it as the same thing every time it appears — across pages, across schema blocks, and across your whole site. If you want your organization, your authors, your products, and your articles to be understood as stable entities rather than disconnected fragments of markup, giving each one a consistent @id is the single most important habit to build.

What @id actually does

Most structured data explains a single thing on a single page. But real websites describe the same entities over and over: your Organization appears in the footer schema of every page, your author appears on dozens of articles, one product is referenced from a review, a breadcrumb, and a collection page. Without a shared identifier, each of those mentions looks like a brand-new, unrelated node to a parsing engine.

The @id gives every entity a canonical name in the form of a URI. When two blocks of markup carry the same @id, consumers treat them as the same entity and merge what they know. This is how you build a connected graph instead of a pile of isolated snippets — the same principle behind connecting your structured data with @graph and nesting.

How to choose stable @id values

An @id should be a URL you control, and it should never change once published. The most common and reliable pattern is a URL with a fragment identifier that names the entity:

• Organization: https://example.com/#organization
• Website: https://example.com/#website
• An author: https://example.com/about/jane-doe/#person
• A specific article: https://example.com/blog/my-post/#article
• A product: https://example.com/products/widget/#product

The fragment (the part after #) is a naming convention, not a fetchable resource — it lets you mint several distinct identifiers under one page URL. Keep the values lowercase, predictable, and permanent. If you later restructure your URLs, resist the temptation to rewrite existing @id values, because doing so tells machines the old entity ceased to exist and a new one appeared.

Reference once, define everywhere

The real power of @id is that you define an entity fully in one place and reference it by ID everywhere else. Instead of copying your full Organization block into every Article, you define the Organization once and then point to it:

• In your Organization block, include the full details plus "@id": "https://example.com/#organization".
• In every Article's publisher field, write only {"@id": "https://example.com/#organization"}.

This keeps your markup small, prevents contradictory copies of the same entity, and makes updates trivial — change the definition once and every reference inherits it. It is the same discipline that makes JSON-LD easier to maintain than Microdata or RDFa: your data lives in one decoupled block instead of being scattered through the HTML.

Common mistakes to avoid

Several patterns quietly break the benefit of @id. Watch for these:

• Reusing the same @id for different entity types. Your Organization and your WebSite are different things; give them different identifiers even though they share a domain.
• Using relative or unstable values. A bare string like "#org" without the full URL is ambiguous across pages. Always use the absolute form.
• Changing @id on every deploy. Some CMS plugins generate a fresh identifier each time a page is rebuilt. That destroys entity continuity — check that your platform emits the same value consistently.
• Defining the entity twice with conflicting data under the same @id. If two blocks claim the same ID but disagree on the name or URL, you send a contradictory signal. Define fully once, reference elsewhere.

Why this matters for AI visibility

AI answer engines and knowledge graphs are built around entities, not keywords. When an assistant decides whether your brand is a trustworthy source, it is reasoning about an entity and everything it can connect to that entity. Stable identifiers make those connections possible: they let a system tie your Organization to your authors, your authors to their articles, and your articles to the topics they cover. That connected structure is exactly what strong entity SEO and knowledge graph building depends on. Sites with clean, consistent identifiers give machines a coherent picture; sites with fragmented markup force them to guess.

Getting @id right is invisible to human visitors but foundational for how machines model your site. If you are not sure whether your structured data forms a connected graph or a scattered mess, run the CheckMy.site scanner to see how crawlers and AI assistants actually read your pages — and fix the gaps before they cost you citations.