How to choose @id for Schema

Websites and other online platforms often use structured data to give more meaningful context about their content to search engines. One of the key components of this structured data is the use of unique identifiers, or “@id” values, which help search engines identify and understand the relationship between different pieces of information on a website

In this guide, let’s take a closer look at how to choose the @id for your schema markup, especially if you’re an SEO specialist looking to optimize your website.

What is @id in schema markup?

In JSON-LD, the @id is a unique identifier for an entity. Think of it as a permanent ID card - a stable reference that tells search engines "this piece of data refers to this specific thing."

The use of @id is essential for creating links between different pieces of data. It allows you to uniquely identify resources, and it makes it possible to establish relationships between them.

Other parts of the document can then use this @id to reference the resource, creating a web of linked data. This is particularly useful when you want to define an entity once and reference it multiple times in different parts of your website.

For example, if you have an organization that’s mentioned multiple times on your site, you can define it once with an @id and then simply refer to that @id whenever the same organization is mentioned, instead of having to redefine the same properties over and over again.

Here’s an example:

{
 "@context": "https://schema.org",
 "@type": "Organization",
 "@id": "http://www.example.com/#organization",
 "name": "Your Organization Name",
 "url": "http://www.example.com/"
}

You can then use the @id (http://www.example.com/#organization in this case) to point back to this organization elsewhere in your schema. For example:

{
 "@context": "https://schema.org",
 "@type": "Event",
 "organizer": {
   "@type": "Organization",
   "@id": "http://www.example.com/#organization"
 },
 "name": "Event Name",
 "startDate": "2023-10-25T00:00",
 "location": {
   "@type": "Place",
   "name": "Event Location",
   "address": "Event Address"
 }
}

In this example, the organizer property of the Event type is referring to the previously defined Organization by using its @id. This tells search engines that the organizer of the event is the same entity that’s defined in the #organization @id.

Specifying the @type when using @id is not always mandatory, as JSON-LD can infer the type from the context and previous definitions. However, it’s a good practice for clarity, especially in complex or flexible contexts, to explicitly state the type when referring to entities. It helps make the document more self-descriptive and understandable, and it’s particularly useful when working with linked data from diverse sources.

How to choose @id for Schema

The best approach is to use your entity's canonical URL as the base, appended with a descriptive fragment identifier like #organization or #product . This keeps your identifiers stable, human-readable, and grounded in your site's actual structure.

With that principle in mind, here are six best practices to follow:

1. Understand your site hierarchy first

Before assigning any @id values, map out the structure of your website. In schema markup, entities don't exist in isolation - they form a connected graph, and the relationships between them need to be reflected in how you assign and reference identifiers.

Start with your root entities. Most websites anchor their schema graph around two top-level entities: Organization (or Person) and WebSite. These are typically defined once and referenced by @id throughout the rest of your markup. Everything else on the site can point back up to these roots.

Once you understand this structure, your @id values become much easier to choose. You can see clearly which entities need their own stable identifier (because other entities will reference them) versus which are self-contained (and may not need an @id at all). It also helps you avoid common mistakes like defining the same Organization twice under slightly different identifiers, or creating orphaned entities that don't connect to anything.

Understanding this hierarchy upfront helps you assign @id values that accurately represent those connections and avoid gaps or contradictions in your structured data.

2. Make every @id Unique

No two entities on your site should share the same @id. Duplicate identifiers create ambiguity that can undermine how search engines interpret your data.

A good @id is specific enough that it could only refer to one thing, whether that's a product, a page, a person, or your organization as a whole.

3. Use a descriptive, URL-Based IRI

The IRI you choose should be clear and descriptive. It should ideally reflect the name or nature of the entity you’re defining. For example, if you’re defining an organization, an IRI like http://example.com/#organization is more descriptive than a generic IRI.

For an organization:

https://example.com/#organization

For a specific product:

https://example.com/products/blue-widget/#product

If the entity has its own dedicated page on your website, using that page's URL as the base (with a meaningful fragment identifier) works well. It gives search engines a natural anchor point and makes your schema easier to audit.

4. Keep it simple and readable

Avoid using overly complex codes or meaningless strings of characters that are difficult to understand. Instead, opt for a simple, descriptive @id that gives search engines a clear idea of what the entity represents on your site.

While JSON-LD syntax allows for special characters in @id, it’s a good practice to avoid them to prevent potential complications or parsing errors.

5. Be consistent

When choosing your @id, try to maintain consistency across your website. This means using the same @id format for similar entities or pages. For example, if you’re identifying a product on one page using the @id “product123,” use a similar format for other products as well, such as “product345” and “product678.”

6. Test and validate

Once you’ve chosen your @id, it’s essential to test and validate your schema to ensure that it doesn’t conflict with any existing entities on the web or in your dataset. There are online tools, such as Rich Results Test or Schema Validator Tool,, available for checking whether your markup is correctly formatted and free of errors.

If there are any issues with your markup, the tool will highlight them, giving you an opportunity to fix them before publishing your site.

Conclusion

Choosing the right @id for your schema entities is a fundamental step in creating clear, meaningful, and interconnected data. The perfect @id is not just a string; it’s an identifier that empowers your data to speak a universal language, linking your content with the broader web of data.