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

Most Webflow developers stop at Organization schema and Article schema. They generate the JSON-LD, paste it in the page settings, and call it done. Their schema is technically valid. It will not get them cited by AI engines.

The reason is @id referencing.

@id referencing is the technique of giving every schema entity on your site a unique, persistent identifier, then using that identifier to connect entities across pages. It is the difference between schema that lives in isolated pockets and schema that forms a knowledge graph search engines and AI systems can traverse.

Most schema you encounter does not use @id at all. The Organization on the homepage is one entity. The Organization mentioned in the Article schema on a blog post is a separate entity. To Google and AI engines, those are two unrelated organizations that happen to share a name. With @id referencing, they are explicitly the same entity.

This matters because authority and entity recognition compound. When Bing's AI sees that the Organization in your homepage schema, your blog Article schema, your product Product schema, and your team Person schemas all reference the same @id, it builds a unified entity graph for your brand. That graph is what gets cited.

What @id actually does

@id is a JSON-LD property that assigns a globally unique URI to a node in your schema. The URI does not have to resolve to a real URL, but it should be stable across your entire site. Once defined, you reference that @id from other schema blocks instead of redefining the entity.

Example without @id (the typical implementation):

{ "@context": "https://schema.org", "@type": "Article", "headline": "Example Post", "author": { "@type": "Person", "name": "Jane Smith" }, "publisher": { "@type": "Organization", "name": "Example Corp" } }

Example with @id (the better implementation):

{ "@context": "https://schema.org", "@type": "Article", "headline": "Example Post", "author": { "@id": "https://example.com/about#jane-smith" }, "publisher": { "@id": "https://example.com/#organization" } }

In the first version, every page that mentions Jane Smith creates a new Person entity. In the second, every page references the same persistent identifier. When the AI crawler visits the About page, it finds the full Person entity at https://example.com/about#jane-smith with bio, credentials, social profiles, and works. That same identifier appears on every blog post Jane writes. Now the AI knows that all those articles share an author with verifiable expertise.

Why this matters for AEO specifically

Answer engines like ChatGPT, Perplexity, and Google's AI Overviews need to verify entities before citing them. They look for proof that an entity is real, that it has authority in a topic area, and that the content claiming the entity's statements is actually written by that entity.

Without @id referencing, every schema block is an island. Your homepage says "Acme Corp is a leading SaaS platform." Your blog post says "Acme Corp helps companies grow." Your product page says "Acme Corp's flagship product..." To an AI parser, these are three separate claims about three potentially different organizations. The AI has no way to verify they are connected.

With @id referencing, everything points to a single canonical Organization entity. The AI follows the @id, finds the master record on your homepage, sees the full property graph (sameAs links to LinkedIn, Crunchbase, Wikipedia, etc.), and builds confidence in your brand identity.

This is why entity-level schema connections show stronger correlation with AI citation rates than just having schema at all. The signal is not "this site has Organization schema." The signal is "this site has a unified Organization entity referenced consistently across every page."

The four entities that need @id on every Webflow site

Most B2B SaaS Webflow sites need @id referencing on four core entities. Get these right and you have the foundation for a connected entity graph.

Step 1: Organization (Homepage)

Your Organization entity goes on the homepage. Every other page on the site references it via @id. The canonical pattern is to use the homepage URL with a fragment like #organization.

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

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

{ "@context": "https://schema.org", "@type": "Organization", "@id": "https://yoursite.com/#organization", "name": "Acme Corp", "url": "https://acme.com", "logo": "https://acme.com/logo.png", "description": "B2B SaaS platform for inventory management.", "sameAs": [ "https://linkedin.com/company/acme", "https://crunchbase.com/organization/acme", "https://twitter.com/acme" ] }

Then on every other page, just reference it: { "publisher": { "@id": "https://acme.com/#organization" } }

Step 2: WebSite (Homepage)

Also on the homepage, define the WebSite entity. This is separate from Organization because Schema.org treats them as distinct: an Organization can have multiple websites, and a website can have multiple authors and content types.

{ "@type": "WebSite", "@id": "https://acme.com/#website", "url": "https://acme.com", "name": "Acme Corp", "publisher": { "@id": "https://acme.com/#organization" } }

Step 3: Authors

Each author gets a Person entity with their own @id. Include name, jobTitle, sameAs links to professional profiles, and an explicit reference to the Organization they work for via worksFor.

{ "@type": "Person", "@id": "https://acme.com/about#jane-smith", "name": "Jane Smith", "jobTitle": "Head of Product", "sameAs": [ "https://linkedin.com/in/janesmith" ], "worksFor": { "@id": "https://acme.com/#organization" } }

Now every blog post by Jane references this Person entity instead of redefining her each time.

Step 4: Articles and Blog Posts

Every blog post or content piece is its own Article (or BlogPosting) entity, but with @id references to the author and publisher rather than nested redefinitions.

{ "@type": "Article", "@id": "https://acme.com/blog/example-post#article", "headline": "Example Post Title", "author": { "@id": "https://acme.com/about#jane-smith" }, "publisher": { "@id": "https://acme.com/#organization" } }

This is where the magic happens. The Article references Jane (Person) and Acme (Organization) via @id. The Person entity is defined fully on the About page with credentials and works. The Organization entity is defined fully on the homepage with profile links. The AI parser follows the @id chain and builds a unified picture: Acme published this article, written by Jane, who is Head of Product at Acme.

Implementing @id referencing in Webflow

Webflow does not have native @id field types in the CMS. You implement @id referencing through custom code, either at the page level or via dynamically populated CMS templates.

Static pages (Homepage, About)

For pages that exist outside the CMS, add the JSON-LD directly in page settings. Pages > select page > Settings > Custom Code > Inside <head> tag.

The homepage gets the Organization and WebSite entities with their canonical @id values. The About page gets the Person entities for each team member, also with their canonical @id values. Use the same @id format consistently: https://yoursite.com/[page-path]#[entity-type] or https://yoursite.com/#[entity-type] for site-wide entities.

CMS-driven pages (Blog posts, Case studies)

For CMS pages, use the CMS template's Custom Code section to inject Article schema with @id references back to your canonical entities. Reference Webflow CMS fields with curly braces.

{ "@type": "Article", "@id": "https://yoursite.com/blog/{{slug}}#article", "headline": "{{Name}}", "author": { "@id": "https://yoursite.com/about#{{Author Slug}}" } }

This requires that your CMS has an "Author Slug" field that matches the @id format on the About page. The author entity itself only needs to be fully defined once, on the About page. The CMS template just references it.

The advanced pattern: @graph blocks

For pages with multiple entities (Article + Person + Organization), wrap them in a single @graph block instead of separate JSON-LD scripts. This signals to parsers that the entities are related and should be processed together.

{ "@context": "https://schema.org", "@graph": [ { "@type": "Article", "@id": "https://acme.com/blog/post#article" }, { "@type": "Person", "@id": "https://acme.com/about#jane-smith" }, { "@type": "Organization", "@id": "https://acme.com/#organization" } ] }

The @graph approach is technically optional but communicates entity relationships more clearly to parsers and is what Schema.org recommends for sites with many connected entities.

What breaks @id referencing

The most common mistakes that destroy @id effectiveness:

Inconsistent @id values across pages. If your homepage uses https://acme.com/#organization but your blog template uses https://acme.com/#org, the AI parser sees two separate organizations. Pick one format and stick to it everywhere.

Using non-canonical URLs in @id. If your site is on the www subdomain but some @id values use the apex domain (or vice versa), you create entity drift. Always match your canonical URL.

Defining the entity multiple times with different properties. The full property definition should appear in exactly one place. On other pages, just reference the @id. Redefining the Organization on every page with slight variations confuses parsers.

Using @id without ever defining the referenced entity. Pointing to #jane-smith when no Person entity with that @id exists anywhere on the site is a dead reference. Make sure the canonical entity definition exists somewhere indexable.

How AI engines actually use @id references

When ChatGPT or Perplexity processes a page with @id referencing, here is what happens internally:

The crawler hits the page and parses the JSON-LD. It identifies all entity nodes. For nodes with @id references that point elsewhere on the same domain, it queues the referenced URL for resolution. When the referenced page is processed, the parser merges the entity definitions across pages.

The result is a unified knowledge graph for your domain. The AI now knows that this Article was written by Jane Smith (full Person entity from About page) and published by Acme (full Organization entity from homepage). When a user asks about "Acme's perspective on inventory management," the AI has high confidence in citing the Article because the entity chain is verified.

Without @id referencing, every page is processed in isolation. The AI cannot connect the Article author to the About page. The brand citation chain breaks. You get extracted but not cited.

How Product pages add the third entity link

For B2B SaaS sites, Product or SoftwareApplication entities should also use @id referencing. Each product gets its own canonical @id, defined fully on the product page, then referenced from feature pages, comparison pages, and pricing pages.

Example product entity:

{ "@type": "Product", "@id": "https://acme.com/products/inventory#product", "name": "Acme Inventory", "brand": { "@id": "https://acme.com/#organization" }, "category": "B2B SaaS" }

Now your homepage Organization, your About page Person entities, your blog Article entities, and your Product entities all form a connected graph. AI engines parsing any page can traverse to any other entity in the graph through @id references.

Validation and debugging

Use Google's Rich Results Test (https://search.google.com/test/rich-results) to validate JSON-LD on any page. The tool will show parsed entities and flag missing or broken @id references.

For checking the full entity graph across your site, use the Schema Markup Validator (https://validator.schema.org/). Paste in JSON-LD from multiple pages and verify that @id values match exactly across pages.

Common issues the validators catch: typos in @id values, mismatched URLs (http vs https, www vs apex), missing entity definitions for referenced @id values.

The bottom line

@id referencing is the difference between schema that exists and schema that works. Most Webflow sites have schema that exists. Few have schema that connects entities across pages into a unified graph.

The implementation is straightforward: define each entity once with a canonical @id, reference it from everywhere else, and use a consistent URL format. The payoff is significant: AI engines treat your site as an authoritative source rather than a collection of unrelated pages.

If you are doing AEO at all, @id referencing should be a foundational pattern. Without it, every other AEO tactic is fighting an uphill battle against entity fragmentation.