Designing Stable Entity Identifiers

What @id does

In JSON-LD, @id gives a node an identifier. Two nodes with the same identifier describe the same thing, so a short reference such as {"@id": "https://verdantcrown.example/#org"} can stand in for the whole Organization node. Google's general guidelines mention this directly: related items on a page can be linked with @id.

That makes identifiers the glue of an entity graph. The publisher of every article, the owner of every website and the employer of every author can all point at one Organization node instead of repeating it.

Choosing a format

Use the canonical https URL of the page that describes the entity best, plus a short fragment that names the entity's role:

Google switched its in-page examples to hash fragments in January 2024. The fragment never reaches the server, so it cannot clash with a real URL, and it stays readable in logs and debugging tools.

Rules that keep identifiers stable

1. One entity, one identifier. If two companies hold licenses in two markets, they are two Organizations with two identifiers, even if they share a brand.
2. Same host, always. Pick https and one host, with or without www, and never mix them. http:// and https:// versions are different identifiers.
3. Owned by one domain. The main brand site owns the brand's identifier. Market editions and blogs refer to it.
4. Independent of the CMS. Do not build identifiers from database keys or post IDs that change when content moves.
5. Never recycled. When a brand is retired, its identifier is retired with it.

@id, url and sameAs are different

These three are often confused:

• @id names the node inside your structured data.
• url says where the entity's page is. Keep it even when @id contains the same address.
• sameAs lists other pages that identify the same entity. Schema.org defines it as the "URL of a reference Web page that unambiguously indicates the item's identity."

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://northwake.example/#org",
      "name": "Northwake Sportsbook",
      "legalName": "Northwake Betting Ltd (fictional)",
      "url": "https://northwake.example/",
      "logo": "https://northwake.example/media/logo.png",
      "sameAs": [
        "https://social.example/northwake"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://northwake.example/#website",
      "name": "Northwake",
      "url": "https://northwake.example/",
      "publisher": {
        "@id": "https://northwake.example/#org"
      }
    },
    {
      "@type": "WebSite",
      "@id": "https://on.northwake.example/#website",
      "name": "Northwake Ontario",
      "url": "https://on.northwake.example/",
      "publisher": {
        "@id": "https://northwake.example/#org"
      },
      "inLanguage": "en-CA"
    }
  ]
}

Referring across domains

A reference to an identifier defined on another domain is normal. Our workbench reports such references as a note, not an error: "referenced but not described in this markup". What you cannot assume is that every system will fetch the other page to learn about the node, so include the few facts readers would expect, such as the publisher's name, alongside the reference when it matters for that page.

Retiring and merging

When a brand moves to a new domain, keep the old domain's markup pointing at the new canonical identifier while redirects are in place, then remove it with the old pages. When two brands merge, keep both Organization nodes as long as both brands appear on the site, and describe the relationship with parentOrganization or brand once it is public.

Sources

How SchemaReel chooses, reads and dates its sources is set out on the data sources page.

1. Google Search Central, General structured data guidelines, last updated July 10, 2026.
2. Google Search Central, Latest Google Search documentation updates, entry of January 9, 2024.
3. W3C, JSON-LD 1.1 Specifications are W3C Recommendations, July 16, 2020.
4. Schema.org, sameAs, V30.1 (2026-09-16).