Structured data (covered in Module 3.1–3.4) tells search engines what type of thing a piece of content is.
Entity SEO answers a deeper question: which specific thing in the world does this page or site represent?
The difference between a keyword and an entity is the difference between the string "apple" and
the unambiguous concept Apple Inc. (the technology company, founded 1976, headquartered in Cupertino).
This module teaches you how search engines build and query that distinction — and how to use it deliberately.
For most of search history, ranking was about matching keyword strings. Google's Knowledge Graph (launched 2012) and subsequent systems — the Hummingbird algorithm, RankBrain, BERT, and MUM — moved toward understanding meaning. An entity is a uniquely identifiable thing (person, organisation, place, product, concept) that exists independently of how it is typed into a search box.
Search engines maintain a graph of billions of entities and their relationships. When a user searches, the engine attempts to resolve their query to one or more entities in that graph, then returns the most relevant documents about those entities. Your technical SEO job is to make it unambiguous which entity your page is about and to prove that your representation of that entity is authoritative.
Think of the Knowledge Graph as a massive property graph database. Each node is an entity. Each edge is a named relationship. Attributes (scalar values like dates, names, or URLs) hang off nodes.
[Organisation: Acme Corp]
--foundingDate--> "2005"
--founder--> [Person: Jane Doe]
--location--> [Place: Austin, TX]
--sameAs--> "https://www.wikidata.org/wiki/Q12345678"
--sameAs--> "https://en.wikipedia.org/wiki/Acme_Corp"
Google's Knowledge Graph is populated from multiple sources: structured data on web pages, Wikipedia / Wikidata, government datasets, licensed data providers, and increasingly from crawled content that Google's systems parse into implicit triples. You cannot write directly to the Knowledge Graph — but you can publish signals that make it easier for Google to confidently add or update an entity's record.
sameAs Property: The Core Entity Signal
The sameAs property in Schema.org is the primary technical mechanism for entity
disambiguation. It declares: "This thing I am describing is the same entity as the one
identified by this URL."
Use authoritative, stable, globally recognised knowledge bases as targets:
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.acmecorp.com/#organization",
"name": "Acme Corp",
"url": "https://www.acmecorp.com",
"sameAs": [
"https://www.wikidata.org/wiki/Q12345678",
"https://en.wikipedia.org/wiki/Acme_Corp",
"https://www.linkedin.com/company/acme-corp",
"https://twitter.com/acmecorp"
]
}
A sameAs array with verified, stable external identifiers tells Google: "You
already know this entity — here is how to map your internal node to my site."
@id Property: Internal Entity Referencing
While sameAs links to external authority, @id creates a persistent,
dereferenceable identifier within your own site's entity graph. It is an IRI (Internationalized
Resource Identifier) — typically a URL with a fragment — that uniquely names an entity so it can
be referenced from other schema blocks across your site without repeating all properties.
// On the homepage — full Organization definition
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.acmecorp.com/#organization",
"name": "Acme Corp",
"logo": {
"@type": "ImageObject",
"url": "https://www.acmecorp.com/logo.png"
},
"sameAs": ["https://www.wikidata.org/wiki/Q12345678"]
}
// On a product page — reference without repeating
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Widget Pro",
"brand": {
"@type": "Organization",
"@id": "https://www.acmecorp.com/#organization"
}
}
This pattern lets a search engine parser stitch your entire site's schema into a coherent local knowledge graph, where the Organisation entity is referenced — not re-declared — everywhere it appears. Consistency is what builds confidence in the entity resolution.
For most sites, the Organisation (or Person, for personal brands) is the root entity. Everything else — products, articles, reviews, locations — hangs off it. Getting this entity established cleanly is a prerequisite for the Knowledge Panel and rich treatment in brand SERPs.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://www.acmecorp.com/#organization",
"name": "Acme Corp",
"alternateName": "Acme Corporation",
"url": "https://www.acmecorp.com",
"logo": {
"@type": "ImageObject",
"@id": "https://www.acmecorp.com/#logo",
"url": "https://www.acmecorp.com/images/logo.png",
"width": 512,
"height": 512
},
"image": "https://www.acmecorp.com/images/og-home.jpg",
"description": "Acme Corp manufactures precision widgets for industrial automation.",
"foundingDate": "2005",
"numberOfEmployees": {
"@type": "QuantitativeValue",
"value": 450
},
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street",
"addressLocality": "Austin",
"addressRegion": "TX",
"postalCode": "78701",
"addressCountry": "US"
},
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+1-512-555-0100",
"contactType": "customer service",
"availableLanguage": ["English"]
},
"sameAs": [
"https://www.wikidata.org/wiki/Q12345678",
"https://en.wikipedia.org/wiki/Acme_Corp",
"https://www.linkedin.com/company/acme-corp",
"https://www.facebook.com/acmecorp",
"https://twitter.com/acmecorp",
"https://www.crunchbase.com/organization/acme-corp"
]
}
Pair the Organisation with a WebSite entity. This also enables the Sitelinks
Searchbox rich result for branded queries.
{
"@context": "https://schema.org",
"@type": "WebSite",
"@id": "https://www.acmecorp.com/#website",
"name": "Acme Corp",
"url": "https://www.acmecorp.com",
"publisher": {
"@id": "https://www.acmecorp.com/#organization"
},
"potentialAction": {
"@type": "SearchAction",
"target": {
"@type": "EntryPoint",
"urlTemplate": "https://www.acmecorp.com/search?q={search_term_string}"
},
"query-input": "required name=search_term_string"
}
}
For individual authors, executives, or personal brands, the Person type is the
root entity. This is also critical for establishing E-E-A-T (Experience, Expertise,
Authoritativeness, Trustworthiness) signals at the author level.
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://www.janedoe.com/#person",
"name": "Jane Doe",
"givenName": "Jane",
"familyName": "Doe",
"url": "https://www.janedoe.com",
"image": {
"@type": "ImageObject",
"url": "https://www.janedoe.com/images/jane-headshot.jpg"
},
"jobTitle": "Software Engineer",
"worksFor": {
"@type": "Organization",
"@id": "https://www.acmecorp.com/#organization"
},
"alumniOf": {
"@type": "EducationalOrganization",
"name": "MIT",
"sameAs": "https://www.wikidata.org/wiki/Q49108"
},
"sameAs": [
"https://www.wikidata.org/wiki/Q87654321",
"https://en.wikipedia.org/wiki/Jane_Doe",
"https://www.linkedin.com/in/janedoe",
"https://twitter.com/janedoe",
"https://orcid.org/0000-0002-1825-0097",
"https://github.com/janedoe"
]
}
Reference this Person entity from Article blocks via
"author": { "@id": "https://www.janedoe.com/#person" }. This connects the
author's authority to the content they write — an increasingly important signal.
Structured data is only one input into entity resolution. Google triangulates across dozens of signals. Inconsistency between your schema and your off-site presence undermines the entity's credibility. Treat the following as part of your entity SEO work:
P856 (official website), P18
(image), P571 (inception date), and relevant industry identifiers.Understanding entities changes how you approach content. Instead of asking "what keyword should this page target?" ask "which entity should this page be the authoritative document about?"
When a page clearly represents a single, unambiguous entity and that entity is well-connected in your schema graph, several things happen:
@id on entities — schema blocks describe the same thing in
isolation on every page. No cross-page entity graph is built.sameAs — pointing to a redirect, a disambiguation
page, or an incorrect Wikidata item.@type incorrectly — using LocalBusiness
for a purely online company, or NewsArticle for a product landing page.sameAs for nested entities — e.g., listing a brand
as a plain string rather than referencing a defined entity with an @id.validator.schema.org) — checks
syntactic correctness and property coverage against the Schema.org vocabulary.search.google.com/test/rich-results) —
checks eligibility for Google's specific rich result types; more conservative than the
schema validator.Entity schema should be generated automatically from your CMS — never hand-typed per page. The following patterns apply to both the WordPress and Payload tracks.
The key principle: your CMS holds the ground-truth data (organisation name, address, logo URL, Wikidata ID, social profiles). Your schema generator reads from those fields and outputs the JSON-LD block. When the CMS data changes, the schema updates everywhere automatically.
// Conceptual: organisation entity from CMS site settings
function buildOrganisationSchema(settings) {
return {
"@context": "https://schema.org",
"@type": "Organization",
"@id": `${settings.siteUrl}/#organization`,
"name": settings.organisationName,
"url": settings.siteUrl,
"logo": {
"@type": "ImageObject",
"url": settings.logoUrl,
"width": settings.logoWidth,
"height": settings.logoHeight
},
"sameAs": settings.sameAsUrls // array stored in CMS
};
}
Store the following as CMS site-settings fields:
This approach is covered in practice in both Track A (WordPress) — using a
custom functions.php hook to read ACF/options-page fields and output the schema —
and Track B (Payload) — using a global collection field and
generateMetadata / a server component to render the JSON-LD.
Below is a representative entity graph for a mid-size e-commerce site. Each node corresponds
to a schema @id; arrows represent schema property references.
https://www.acmecorp.com/#organization (Organization)
└── published by ──────────────────────> WebSite #website
└── sells ─────────────────────────────> Product #widget-pro
└── brand ──────────────────────> #organization
└── offers ─────────────────────> Offer #offer-widget-pro
└── aggregateRating ────────────> AggregateRating
└── review ───────────────> Review
└── author ──────────> Person #reviewer-john
└── author (articles) ─────────────────> Person #jane-doe
└── worksFor ───────────────────> #organization
Each page also carries a BreadcrumbList that references the same URL hierarchy.
Notice that #organization appears on every product page and every article —
but only as a lightweight { "@id": "..." } reference after it is defined fully
on the homepage. This gives Google a complete, consistent picture of who publishes this content
and what they sell, without redundant, potentially inconsistent copies of the same data.
Google's Quality Raters Guidelines use E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) as a framework for assessing page and site quality. Entities are the technical mechanism through which you make E-E-A-T machine-readable.
Person entity with
sameAs references to academic profiles (ORCID, Google Scholar), professional
networks (LinkedIn), and Wikidata signals that this author has a verifiable identity and
track record.Organization entity referenced by
external authoritative sources (Wikipedia, industry databases) signals that Google can
independently verify claims about your organisation.E-E-A-T is not a ranking factor in the traditional sense — there is no "E-E-A-T score." But the underlying entity signals it points to are inputs into how Google evaluates content quality, especially for YMYL (Your Money or Your Life) topics.
Complete all three tasks before moving to the Platform Tracks.
@id, and which use
sameAs. Identify gaps: missing @id references, inconsistent names,
absent sameAs targets.
sameAs target, a logo ImageObject, and a
WebSite entity. Validate both blocks clean in the Schema Markup Validator
and the Rich Results Test.
@id only,
not a full redeclaration — the Organisation entity you defined in Task 2. Confirm the reference
is syntactically valid.
You are ready to proceed when you can do all of the following without referring back to this module:
Organization or Person JSON-LD block with
correct @id, sameAs, and all recommended properties.@id.sameAs targets appropriate to the entity
type and explain why each one is valuable.