Schema @id Problems

What @id actually does

In JSON-LD every entity is a node in a graph. @id is that node's identifier. It is written as a URL, but it is a name rather than a link: nothing has to load at that address, and search engines do not need to visit it. What matters is the string itself, because two nodes with exactly the same @id are treated as the same thing, and their properties are combined into one entity.

That single rule explains every problem in this guide:

• If two different things share an @id, a processor merges them into one confused entity, for example a product that also appears to be a blog post.
• If one thing has two different @id values, it becomes two entities that happen to have the same name, and anything you said about one is not linked to the other.
• If a node has no @id, it becomes a blank node. That is fine for small details such as an address or an offer, but a blank node cannot be referred to from anywhere else, so a shared entity without one has to be copied out in full every time it is used.

The JSON Checker flags identifiers that are duplicated across different entities and shared entities that lack one, and it checks whether references in the markup lead to a defined node. The last of those has its own guide on fixing dangling references; this page is about the identifiers themselves.

The @id problems, and what each one causes

The last row is more common than it sounds. It happens when a template hard-codes the site address plus #product instead of using the page address plus #product. A single product is described correctly on each page, but across the site the markup says there is only one product with hundreds of names and prices.

The relative identifier trap

Many hand-written blocks and some older plugins use short identifiers such as "@id": "#organization". JSON-LD treats that as a relative address and resolves it against the address of the page it appears on, in the same way a browser resolves a relative link. So the same line of code produces a different identifier on every page:

Within a single page that is harmless, because the definition and any reference to it resolve the same way. Across a site, it means your business is described as a separate entity on every page. The fix is simple: write site-wide identifiers in full, starting with https://, so they are identical wherever they appear.

A naming scheme that holds up

There is no official format for identifiers. What matters is that each is unique to one thing, identical everywhere that thing appears, and never changes. The simplest way to achieve that is to base each identifier on the canonical address of the page most closely associated with the entity, plus a short fragment naming its role.

Four rules make the scheme reliable:

1. Use the canonical address. Take it from the same value as the page's canonical link, not from the address in the browser, so query strings, tracking parameters and alternative hosts never leak in.
2. One host, one protocol. Pick the version your site redirects to, such as https with www, and use it in every identifier, even on staging copies that are served from another address.
3. Give each role its own fragment. The page and the thing the page is about are different entities. The WebPage takes the bare address; the Article or Product takes the address plus a fragment.
4. Never change an identifier once it is live. If a page moves, keeping the old identifier is acceptable because it is only a name. Changing it disconnects everything already recorded about that entity.

The same scheme applied to a blog post looks like this. Note that the WebPage, the article, the organisation and the author each have their own identifier, and the article points to the others by identifier instead of repeating them.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.co.uk/#organization",
      "name": "Hollin Lane Bathrooms",
      "url": "https://www.example.co.uk/",
      "logo": "https://www.example.co.uk/images/hollin-lane-logo.png"
    },
    {
      "@type": "WebSite",
      "@id": "https://www.example.co.uk/#website",
      "url": "https://www.example.co.uk/",
      "name": "Hollin Lane Bathrooms",
      "publisher": { "@id": "https://www.example.co.uk/#organization" }
    },
    {
      "@type": "Person",
      "@id": "https://www.example.co.uk/team/priya-hale/#person",
      "name": "Priya Hale",
      "url": "https://www.example.co.uk/team/priya-hale/"
    },
    {
      "@type": "WebPage",
      "@id": "https://www.example.co.uk/blog/wet-rooms/",
      "url": "https://www.example.co.uk/blog/wet-rooms/",
      "name": "Planning a Wet Room in an Older House",
      "isPartOf": { "@id": "https://www.example.co.uk/#website" }
    },
    {
      "@type": "BlogPosting",
      "@id": "https://www.example.co.uk/blog/wet-rooms/#article",
      "headline": "Planning a Wet Room in an Older House",
      "datePublished": "2026-06-11T10:00:00+01:00",
      "mainEntityOfPage": { "@id": "https://www.example.co.uk/blog/wet-rooms/" },
      "author": { "@id": "https://www.example.co.uk/team/priya-hale/#person" },
      "publisher": { "@id": "https://www.example.co.uk/#organization" }
    }
  ]
}
</script>

The fix, step by step

When two blocks share an @id on purpose

Reusing an identifier is not always a mistake. It is the correct way to say "this is the same thing" across blocks, and it lets you add to an entity that another tool defines without replacing it. If your SEO plugin describes the organisation with https://www.example.co.uk/#organization, your own block can add opening hours or a sameAs list to the same node by using the same identifier.

Two cautions apply. First, the combined node must still make sense: if the plugin says the organisation is called one thing and your block says another, the entity ends up with two names. That is the subject of the guide on fixing conflicting schema blocks. Second, if the two blocks give the node different types, it becomes both types. That is intended when a business is genuinely a LocalBusiness and an Organization, but not when a theme labels the home page as an organisation.

Not every tool merges nodes across separate script blocks on one page in the same way. Placing the pieces in one @graph where you control the output removes any doubt; where you cannot, identical identifiers are still the best signal you can give.

Identifiers on common platforms

Most SEO plugins and shop platforms generate identifiers automatically, and it is usually better to work with their format than against it. Formats change between versions, so always read the live output rather than relying on documentation or this summary.

• WordPress with Yoast SEO has typically used the site address plus #organization and #website, the page address for the WebPage, and the page address plus #article for posts. People get identifiers under a #/schema/person/ path. Custom code should reuse these values.
• WordPress with Rank Math has typically used site-level fragments such as #organization and #website on the full site address, and page-level fragments such as #webpage. Check the output of your version before copying the pattern.
• Shopify themes vary widely. Many output Product and Organization blocks without identifiers at all, which means a review app or SEO app adding its own Product cannot be linked to the theme's. Adding page-based identifiers in the theme's Liquid is often the cleanest fix.
• Static sites and frameworks should build identifiers from a single configured base address, never from the request address, so preview deployments and local builds do not produce stray hosts.