Why @id Referencing Is the Most Underrated Schema Technique for AEO

What @id Actually Does

@id assigns a unique identifier to an entity in your structured data. Think of it as a permanent address. Not a URL that loads a page. Just a string that says this specific entity lives here, and any time you see this identifier, it is the same thing.

Here is an Organization defined with an @id:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://yoursite.com/#organization",
  "name": "Your Company",
  "url": "https://yoursite.com",
  "logo": "https://yoursite.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/yourcompany",
    "https://twitter.com/yourcompany"
  ]
}

The @id is https://yoursite.com/#organization. The #organization part is a hash fragment. It never resolves to an actual page. It is a naming convention. A namespace.

Now on any other page of your site, when you need to reference this Organization, you do not redefine it. You point to it:

{
  "@type": "Article",
  "headline": "How to Do the Thing",
  "publisher": { "@id": "https://yoursite.com/#organization" }
}

Two lines. The machine reads @id, finds the full definition, connects the article to your Organization entity. No ambiguity. No duplication. No guessing.

The Problem Without @id

Without @id, every page defines its entities from scratch. Your homepage has one Organization object. Your blog post has another nested inside publisher. Your product page has yet another nested inside brand. Three pages. Three separate Organization objects.

A search engine or AI model sees three entities that happen to share a name. Are they the same? Probably. But probably is not how knowledge graphs work. Google's Knowledge Graph, Perplexity's retrieval system, and ChatGPT's source evaluation all work with entities, not strings. An entity is a distinct, identifiable thing. A string is just text.

When your schema uses @id, you are speaking the language of entities. When it does not, you are hoping the machine does the disambiguation work for you. On a 20-page site, this rarely causes problems. On a 2,000-page site with products, blog posts, authors, and locations, it creates a mess of conflicting and redundant data.

How to Build a Connected Entity Graph

The architecture is simple. You have a small set of core entities that get defined once and referenced everywhere.

Step 1: Organization (Homepage)

Define your Organization with full properties on the homepage. Include @id, name, url, logo, sameAs links to all official profiles, and a description.

{
  "@type": "Organization",
  "@id": "https://yoursite.com/#organization",
  "name": "Your Company",
  "url": "https://yoursite.com",
  "logo": {
    "@type": "ImageObject",
    "@id": "https://yoursite.com/#logo",
    "url": "https://yoursite.com/logo.png"
  },
  "sameAs": [
    "https://www.linkedin.com/company/yourcompany",
    "https://twitter.com/yourcompany"
  ]
}

Step 2: WebSite (Homepage)

Also on the homepage, define the WebSite entity. This represents the site itself and its publisher points back to the Organization @id.

{
  "@type": "WebSite",
  "@id": "https://yoursite.com/#website",
  "name": "Your Company",
  "url": "https://yoursite.com",
  "publisher": { "@id": "https://yoursite.com/#organization" }
}

Step 3: Authors

Each author gets a Person entity with their own @id. Include name, jobTitle, profile URL, sameAs for LinkedIn, and worksFor pointing back to the Organization.

{
  "@type": "Person",
  "@id": "https://yoursite.com/#person-jane-doe",
  "name": "Jane Doe",
  "jobTitle": "Head of Content",
  "sameAs": ["https://www.linkedin.com/in/janedoe"],
  "worksFor": { "@id": "https://yoursite.com/#organization" }
}

Step 4: Reference on Every Other Page

Once your core entities exist, every other schema on the site references them instead of redefining them.

Blog post:

{
  "@type": "BlogPosting",
  "@id": "https://yoursite.com/blog/post-slug/#article",
  "headline": "How to Do the Thing",
  "datePublished": "2025-06-15",
  "author": { "@id": "https://yoursite.com/#person-jane-doe" },
  "publisher": { "@id": "https://yoursite.com/#organization" },
  "isPartOf": { "@id": "https://yoursite.com/#website" }
}

Product page:

{
  "@type": "Product",
  "@id": "https://yoursite.com/products/widget/#product",
  "name": "Widget Pro",
  "brand": { "@id": "https://yoursite.com/#organization" },
  "offers": {
    "@type": "Offer",
    "price": "99.00",
    "priceCurrency": "USD"
  }
}

No nested Organization block. No repeated author details. Just clean references.

Using @graph to Bundle Multiple Entities

On pages where you need multiple entities like the homepage, use @graph. It is an array of entities in a single JSON-LD block, each with its own @id, referencing each other. For example, your homepage can bundle Organization, WebSite, and FAQPage schema in one @graph.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://yoursite.com/#organization",
      "name": "Your Company",
      "url": "https://yoursite.com"
    },
    {
      "@type": "WebSite",
      "@id": "https://yoursite.com/#website",
      "publisher": { "@id": "https://yoursite.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://yoursite.com/#webpage",
      "about": { "@id": "https://yoursite.com/#organization" },
      "isPartOf": { "@id": "https://yoursite.com/#website" }
    }
  ]
}

This is the standard pattern used by Yoast, RankMath, and most serious schema implementations.

The @id Naming Convention

There is no official rule for @id format. The widely adopted convention is to use your site URL as the base and add a hash fragment for the entity type.

Organization: https://yoursite.com/#organization

WebSite: https://yoursite.com/#website

Logo: https://yoursite.com/#logo

Author: https://yoursite.com/#person-firstname-lastname

Article: https://yoursite.com/blog/post-slug/#article

Product: https://yoursite.com/products/product-slug/#product

The hash fragment never loads in a browser. Keep @id values consistent and permanent. If you change them, you break every reference across the site.

Why This Matters for AEO and AI Search

The real reason @id referencing matters now is how AI search engines evaluate and cite sources.

ChatGPT, Perplexity, Gemini, and Google's AI Overviews all use retrieval-augmented generation. They pull information from web pages, evaluate the source's trustworthiness, and decide whether to cite it. The evaluation is not just about content quality. It is about entity recognition.

When an AI model encounters a blog post with publisher and author both referencing @id values, and that Organization has sameAs pointing to Wikipedia, LinkedIn, and verified social profiles, the model can connect this content to a known, verified entity. The content is not anonymous text on the internet. It is a specific article by a specific person at a specific organization with a verifiable identity.

Compare that to a blog post with a flat inline publisher definition. No @id. No sameAs. No connection to anything. The AI model has to figure out on its own whether that company is a real, trustworthy entity.

This is the structured data version of E-E-A-T. Google has talked about E-E-A-T as a qualitative concept. @id referencing is how you express it in machine-readable format.

A connected entity graph tells AI engines: this content has a known publisher, a known author, a verifiable web presence, exists within a structured site, and all entities are consistent across every page.

The Most Common Mistakes

Redefining entities on every page. Every blog post has a full Organization block nested inside publisher. The entities are not connected. They are just repeated text.

Inconsistent naming. The homepage says Your Company Inc, the blog says Your Company, a product page says YourCompany. Three strings. No @id to unify them.

Missing sameAs. You define the Organization with @id but do not include sameAs links. The entity exists in your schema but is not connected to any external knowledge base.

No author entities. Blog posts have author as a plain string. No Person type. No @id. The author is invisible to the entity graph.

Changing @id values. You restructure your site and the @id values change. Every reference across every page now points to nothing.

How to Audit Your Current Schema

Test your homepage with Google's Rich Results Test. Look for Organization and WebSite entities with @id. Test a blog post and check if publisher and author reference an @id or use inline definitions. Test a product page and check if brand references an @id. Use the Schema Markup Validator to see the full entity graph.

If most answers are no, you are leaving AEO value on the table. For a practical walkthrough of mapping CMS fields to JSON-LD, see our guide on mastering schema and CMS structure in Webflow. Not because your schema is invalid. It might pass every validation test. But it is not building the connected entity graph that gives AI search engines confidence in your content.

Automate This With Karpi Schema HQ

Managing @id references manually across dozens of pages is tedious and error-prone. Karpi Schema HQ is a Webflow app that handles entity definitions, @id referencing, and @graph generation from a single dashboard. Define your Organization, Authors, and WebSite once. Schema HQ injects the correct references on every page automatically.

Learn more about Karpi Schema HQ or talk to us about your schema architecture.

The Bottom Line

@id referencing has been part of the JSON-LD specification since the beginning. Most implementations skip it because it is not required by Google's rich results documentation.

That was fine when structured data was only about earning rich snippets. Rich snippets care about the data on the current page. They do not need cross-page entity connections.

AI search is different. AI search cares about who you are, not just what is on the page. It evaluates entities, not strings. And @id is how you tell it, clearly and unambiguously, exactly which entity is behind your content.

Define your entities once. Reference them everywhere. Connect them to external knowledge bases with sameAs. That is the foundation of AEO-ready structured data. Start with our complete Webflow AEO guide for the full implementation framework.