@id graph (schema)

How @id works in practice

Without @id (common but suboptimal):

// On every page, the Organization is redeclared:
{
  "@type": "BlogPosting",
  "publisher": {
    "@type": "Organization",
    "name": "Resocial",
    "url": "https://resocial.us"
  }
}

Each Organization block is technically a separate entity in the schema graph — the processor has to GUESS they’re the same brand.

With @id (the better pattern):

// Defined ONCE in the homepage / Layout schema:
{
  "@type": "Organization",
  "@id": "https://resocial.us/#organization",
  "name": "Resocial",
  "url": "https://resocial.us",
  "sameAs": [...]
}

// Referenced everywhere else:
{
  "@type": "BlogPosting",
  "publisher": { "@id": "https://resocial.us/#organization" }
}

Now schema processors and AI engines recognize the publisher across every blog post is the SAME Organization defined on the homepage. The entity graph consolidates.

Why @id matters for AI search

AI engines build internal entity graphs from schema data. With consistent @id:

• “Resocial published this article” → resolves to the Resocial Organization with full sameAs + properties
• “Resocial offers this service” → same Organization
• “Resocial’s founder is X” → same Organization

The graph consolidates into one rich entity. Without @id, you’re shipping fragments that the engine has to stitch together heuristically — and often fails.

Choosing stable @id URLs

The convention: use a URL on your own domain with a fragment identifier:

• Organization: https://yourdomain.com/#organization
• WebSite: https://yourdomain.com/#website
• Person: https://yourdomain.com/#person-{slug}
• Service: https://yourdomain.com/services/{slug}/#service

The @id doesn’t have to resolve to a real page; it’s a stable identifier, not a navigation URL. But using your own domain in the @id reinforces the entity-to-domain connection.

Common mistakes

• Different @id for the same entity on different pages — defeats the consolidation
• No @id at all — schema works but as fragments, not as a graph
• @id that changes — every modification to the URL breaks accumulated graph signals
• @id that references an entity declared on a third-party site — schema validators may flag this as a chain that can’t be resolved

The graph extending beyond schema

@id-style consolidation extends to:

• sameAs linking to Wikidata + LinkedIn + GitHub + Crunchbase
• worksFor (Person) referencing your Organization @id
• publisher (Article/BlogPosting) referencing Organization @id
• provider (Service) referencing Organization @id
• parentOrganization for sub-divisions

Each of these creates a node in the entity graph that links back to your central Organization @id.

Resocial perspective

Most schema implementations we audit have @id graphs that are partial or absent. Every Resocial-built site uses the @id pattern consistently — one Organization declaration with @id, referenced from every other schema block. This single change typically lifts AI citation rate measurably within 90 days. See the Schema Markup Complete Guide for the broader implementation context.