Entity SEO: Building a Schema @id Graph Search Engines Can Follow

Short answer: An entity graph declares your organisation, website, and people once, each with a stable @id, then has every other schema block reference those identifiers instead of repeating the details. The result is one connected entity a machine can resolve, rather than dozens of loose copies that drift apart.

Key Takeaways

• Most sites paste the same Organization block into every page, which creates many near-identical copies instead of one entity.
• A stable @id such as https://example.com/#organization gives machines something to resolve against.
• Declare each entity once, then reference it with { "@id": "..." } from provider, publisher, isPartOf and author.
• sameAs links to profiles you control are how you connect your entity to the wider web.
• One pragmatic exception: Google requires certain display fields on Article, so author is the place you still repeat a name.

What an Entity Is, Without the Jargon

Search engines and AI assistants do not think in pages. They maintain records about things: companies, people, products, places. Your pages are evidence about those things. "Entity SEO" simply means making the evidence consistent and explicit enough that the record is correct.

When your business name, address, founder, and social profiles are stated identically everywhere a machine looks, the record is confident. When your schema says one thing, your footer says another, and your Google Business Profile says a third, the record is uncertain, and uncertain records get cited less.

The Mistake Almost Every Site Makes

The standard approach is to drop a full Organization block into every page template. Each page then declares a separate, unlinked Organization object. Nothing tells a parser these are the same company. They are twenty objects that happen to look alike.

This usually stays invisible until something changes. Someone updates the phone number in the homepage block and misses the service page template. Now two blocks disagree, and there is no way for a machine to know which is current.

The alternative is to treat your schema like a small database, where entities have primary keys.

How @id Works

A JSON-LD @id is a globally unique identifier for a node. The convention is a URL fragment on your own domain:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/",
  "sameAs": ["https://www.linkedin.com/company/example"]
}

Declare that once, in a block present on every page. Then every other schema object references it rather than restating it:

{
  "@type": "Service",
  "name": "Technical SEO",
  "provider": { "@id": "https://example.com/#organization" }
}

The fragment never resolves to a real page, and it is not meant to. It is a key. What matters is that it is stable and that you use the same one everywhere.

The Three Entities Worth Declaring

Three entities cover most business sites. Add more only when you have something genuinely distinct to describe, such as individual physical locations.

A Worked Example: This Site

This site declares exactly those three entities, once, in the base HTML template that every page is built from. Each carries a stable identifier: #organization, #website, and #person.

Every service page then emits a Service object whose provider is a bare reference to #organization, and a WebPage object whose isPartOf references #website. The company name, address, and social profiles appear in exactly one place in the codebase. Updating the phone number is a one-line change that is correct everywhere immediately, because nothing else ever restated it.

You can confirm this by viewing source on any page here and searching for @id. The service pages reference identifiers they never define, and the definitions sit in the shared template.

The Exception We Kept, and Why

There is one place we deliberately repeat ourselves, and it is worth explaining because the pure version of this advice will cost you a warning in Google's testing tools.

Google's Article structured data expects an author with a visible name. If a blog post's author is only a bare @id reference, validators commonly report the name as missing, because they do not always resolve the reference across blocks when checking required fields. So on blog posts we keep @id and also repeat the author's name and role.

That is the practical trade-off: @id alone is cleaner and correct as linked data, but required display fields still belong inline where a validator expects them. Anyone who tells you to strip every duplicated property has not run the result through the Rich Results Test.

Consistency Beyond Your Own Site

The graph on your site is half the job. The other half is that the same facts appear the same way everywhere else: your Google Business Profile, LinkedIn, GitHub, directory listings, and anywhere your business is described by someone else.

Use sameAs on your Organization and Person entities to point at the profiles you control. That is the explicit statement that those accounts are you. Then keep the name, address, and description consistent across them, because a conflicting third-party description is exactly the kind of uncertainty that keeps an AI assistant from naming you confidently. We go further into that in getting cited by AI search.

How to Audit Yours

1. View source on three different page types and extract every JSON-LD block.
2. Count how many times your organisation name appears. More than once per page usually means duplication rather than references.
3. Check that every @id you reference is defined somewhere on that same page.
4. Run the pages through the Schema.org validator and Google's Rich Results Test. They disagree sometimes, and the disagreements are informative.
5. Compare the facts in your schema against your Google Business Profile and main social profiles, field by field.

Our AEO service includes this entity work, implemented in your templates rather than bolted on with a tag manager. Websites start from $500 and web applications from $1,500 on our pricing overview, with final cost depending on scope.

Frequently Asked Questions