Entity & Identity Schema

TL;DR — Most schema markup describes what’s on a page (“this is the price,” “this is a review”). Entity & identity schema does a different job: it tells search engines who or what is behind the site — a company, a local business, or a person. The three main types are Organization, LocalBusiness, and Person (not the only identity-capable schema.org types, just the three that matter most here). Their point is to help Google identify you as a distinct “entity,” not to earn star ratings. It does not directly make you rank higher, and it does not guarantee you a Knowledge Panel.

What “entity schema” means

Schema.org’s Thing type and sameAs property provide vocabulary for identifying a thing and linking unambiguous identity references. Evidence for this claim Official or primary documentation supporting the adjacent article claim, with scope limited to the source's published description. Scope: No ranking guarantee or undisclosed system mechanics are inferred beyond the cited source. Confidence: high · Verified: 2026-07-14 Schema.org: sameAs Google recommends structured data that accurately represents visible page content and uses stable identifiers consistently. Evidence for this claim Official or primary documentation supporting the adjacent article claim, with scope limited to the source's published description. Scope: No ranking guarantee or undisclosed system mechanics are inferred beyond the cited source. Confidence: high · Verified: 2026-07-14 Google: Structured data policies

When you read a web page, you can tell that “Apple” the company is different from “apple” the fruit, and that the author “John Smith” is a specific real person and not just a name. A search engine has to work that out from signals. An entity is Google’s word for a uniquely identifiable real-world thing — a person, a place, an organization — that it stores in its Knowledge Graph.

Most schema markup labels content: Article, Product, FAQPage. Entity and identity schema is the small set of types that labels identity instead — it declares the thing behind the content:

• Organization — for any company or brand.
• LocalBusiness — for a business with a real, physical, local presence (a shop, a restaurant, a dentist).
• Person — for an individual: an author, a founder, an expert, a personal brand.

“Entity schema” isn’t an official Google or schema.org category, by the way — it’s just a handy name I use for these three identity-bearing types. It’s also not exhaustive: schema.org has other types that can identify a real-world thing (Product, Place, and dozens more under the general Thing type). Organization, LocalBusiness, and Person are the three that matter most for declaring who runs the site, not the full list of identity-capable schema.org types.

Why it matters

Marking up your identity helps Google be sure which entity your site is about, instead of guessing. Done well, that can feed the Knowledge Graph and support things like a Knowledge Panel or your logo showing next to your listing. There’s also a growing practitioner theory that it plays into whether AI tools (ChatGPT, Perplexity, AI Overviews) recognize your brand as a real, citable thing — but no AI provider documents that connection, so treat it as a plausible hypothesis, not a lever with proven pull.

But be clear about what it does not do:

• It is not a ranking factor. Adding Organization schema won’t move you up the results.
• It does not guarantee a Knowledge Panel. It can help you become eligible; Google still decides.

The one property that ties it together: sameAs

The key ingredient is a property called sameAs. It’s how you tell Google “this Organization (or Person) is the same entity as this other authoritative record” — your Wikipedia page, your Wikidata entry, your verified social profiles. Those links help Google connect the dots and confirm your identity.

The trap: a sameAs link pointing at the wrong profile can misidentify you. So it’s a helpful signal, not a magic trust button — and it has to be accurate.

Want the full version — how entities resolve across sources, the Organization vs. LocalBusiness vs. Person decision, @id, and the AI-search angle? Switch to the Advanced tab.

TL;DR — “Entity & identity schema” is my non-exhaustive umbrella term for Organization, LocalBusiness, and Person — the schema.org types whose job is disambiguation, not rich results. They declare which real-world entity a site belongs to and, via sameAs, tie that claim to authoritative records (examples like Wikipedia, Wikidata, verified profiles — not requirements) so engines can resolve it. LocalBusiness is a subtype of Organization — use the most specific type that fits; Person is the individual counterpart. It is not a ranking factor and does not guarantee a Knowledge Panel; sameAs is an identity-resolution signal, not a trust lever, and a reused or misdirected value actively misattributes your entity. Whether it drives AI-answer citation is an unproven hypothesis, not a documented mechanism.

What Google means by “entity”

Entities are identifiable things in information systems; structured data can clarify identity but does not guarantee Knowledge Graph inclusion. Evidence for this claim Official or primary documentation supporting the adjacent article claim, with scope limited to the source's published description. Scope: No ranking guarantee or undisclosed system mechanics are inferred beyond the cited source. Confidence: high · Verified: 2026-07-14 Schema.org: sameAs Google’s documented structured-data rules remain feature-specific. Evidence for this claim Official or primary documentation supporting the adjacent article claim, with scope limited to the source's published description. Scope: No ranking guarantee or undisclosed system mechanics are inferred beyond the cited source. Confidence: high · Verified: 2026-07-14 Google: Structured data policies

An entity is a uniquely identifiable real-world thing that Google stores in its Knowledge Graph — people, places, organizations, but also abstract concepts. Google resolves an entity by cross-referencing signals about it across many independent sources: your own website, your social profiles, directories, public databases, notable press mentions, and structured records like Wikidata. Entity schema is your chance to state your identity clearly and point Google at those other records so it can line them up with confidence.

One distinction worth keeping straight: Google’s Knowledge Graph Search API is a developer tool for querying entities — it is not the same system as the ranking-facing Knowledge Panel, and marking up Organization schema doesn’t “submit” you to it. Don’t conflate the API with how identity schema feeds the panel; they’re different things.

Identity schema vs. content schema

This is the central distinction of this hub, so let me draw it cleanly:

• Content schema — Article, Product, FAQPage, HowTo, Recipe — describes what is on the page. Its usual payoff is rich-result eligibility: a visible SERP enhancement (stars, price, breadcrumbs).
• Identity schema — Organization, LocalBusiness, Person — describes who or what publishes the page. Its payoff is entity understanding and disambiguation, with no visible badge attached.

The practical consequence: identity schema is worth implementing even though it usually produces no rich result. That’s the opposite instinct from most schema work, and it’s why people who only think in “rich results” tend to skip it.

The three identity-bearing types

They aren’t three unrelated siblings — they’re a base type, a specialization of it, and an individual counterpart:

• Organization is the base/umbrella type for any company or brand. It’s the one almost every site should have.
• LocalBusiness is technically a subtype of Organization (Thing > Organization > LocalBusiness), for businesses with a physical or local presence — hours, address, service area. Google’s guidance is to use the most specific applicable subtype, so a local business uses LocalBusiness (or a narrower subtype like Restaurant), not generic Organization.
• Person sits in its own branch (Thing > Person). It establishes an individual identity — an author, a founder or exec, a consultant, a sole proprietor, anyone building a personal brand that needs to be distinguished from same-named people.

A single site often uses more than one: an Organization for the brand and Person markup for the authors, ideally linked into one graph (see @id below).

sameAs and identity resolution

sameAs is the core mechanic. Schema.org defines it plainly: a URL to a reference page that unambiguously identifies the item — Wikipedia, Wikidata, or an official website are the examples schema.org gives, not a required list. Practically, you reference the profiles that genuinely describe you: a Wikidata entry, a Wikipedia page if you have one, verified social accounts. On the Organization side, the homepage is the single most important place to establish brand identity, with at least name, logo, url, and sameAs.

Two rules make or break it:

1. One value, one entity. A sameAs URL must unambiguously identify the entity — don’t reuse the same sameAs value for two different entities. Reusing or misdirecting it doesn’t just fail to help; it actively misattributes your entity.
2. sameAs is an identity-resolution signal, nothing more documented than that. It’s schema.org’s mechanism for pointing at another authoritative record of the same entity — not a ranking boost, not a source of “trust,” and not a documented AI-citation lever. Any claim that sameAs does one of those things is a separate, currently unsupported claim; don’t treat it as bundled into the property’s actual job.

A cautionary tale from the industry: Ryan Law at Ahrefs once accidentally set his personal sameAs to Ahrefs’ blog instead of his own author page, which caused Google to misattribute his personal entity to Ahrefs’ site — a small schema slip with a visible, wrong-in-public result. The lesson: entity schema is powerful enough that errors show up in how your brand is represented, so double-check every value. The Ryan Law anecdote is relayed from Ahrefs’ Knowledge Graph guide and is paraphrased here, not quoted verbatim.

@id — connecting your nodes into one graph

@id is a JSON-LD node identifier, full stop — that’s what the JSON-LD spec defines it as: a way to give a node in a graph a stable identifier and reuse that same identifier to refer back to it. Practically, if you have Organization, WebSite, and Person markup scattered across a site, you give the Organization node an @id URI, then point author.@id (on a Person) or publisher.@id (on an Article) at that same URI. That makes “this Article’s author is this Person, who is part of this Organization” unambiguous within the JSON-LD graph you wrote.

What I can’t tell you with the same confidence: how reliably, or in what form, Google’s indexing systems stitch separately-crawled pages into one entity using @id matches. That’s not something Google documents in detail. Treat consistent @id usage as good, spec-compliant practice and a useful implementation convention — not a proven, documented cross-page ranking or entity-linking signal. The deep mechanics of @id belong in the Organization deep dive — for the hub, just know it’s a JSON-LD identifier convention, and be honest that its cross-page effect on Google’s side is an open question, not a documented fact.

Why this matters for AI search / GEO

Here’s the modern stakes, and here’s the honest boundary of what’s proven. Classic ranking and entity recognition are separate problems: you can rank #1 in traditional search and still be invisible to an AI answer engine that doesn’t recognize your brand as a distinct entity — that part is a reasonable inference from how these systems work. What I can’t back with primary evidence is a causal claim that identity schema, sameAs, or @id makes ChatGPT, Perplexity, or AI Overviews recognize or cite you. No AI provider documents that mechanism. So I’ll state it as a hypothesis, not a fact: identity schema is plausible entity infrastructure — accurate, well-linked markup that removes ambiguity a model might otherwise have to guess through — but I don’t have a controlled test showing it changes citation behavior, and you should be skeptical of anyone who claims they do without showing one. This ties into my broader work on AI search / GEO — being ranked and being recognized as an entity look like different battles, but the causal link between “recognized” and “cited” is still an open question, not settled infrastructure.

To be honest about the evidence more broadly: schema is often oversold as an AI-citation lever, and Google’s own reps have been careful here. John Mueller, asked whether lots of schema helps LLMs understand entities, gave the very SEO answer of “yes, no, and it depends” — structured data helps engines understand the entities on a page, but it doesn’t make you rank higher or get labeled “best” in an AI answer; credibility and authority still dominate. The Mueller remark is relayed via Search Engine Roundtable’s coverage and is paraphrased, not presented as a verified verbatim quote.

There’s also a broader disagreement worth surfacing: not everyone thinks “entity SEO” is even a separate discipline. Ahrefs has argued that once Google’s search runs on entities, “entity SEO is just SEO” — ordinary structured data, content quality, and authority-building, not a novel tactic set — and the piece quotes me making the same point: “The entity identification part is more on Google’s end than on our end.” Jump to quote That’s consistent with how I’ve scoped this hub: identity schema is accurate, verifiable markup you control, not a checklist of special “entity optimization” moves — the actual identification and inference work happens on the search engine’s side.

Common mistakes

• Treating identity schema like any other schema task. It’s not chasing a rich result; it’s disambiguation. Judge it by whether Google can identify your entity, not by whether a badge shows up.
• Reusing or misdirecting sameAs — the Ryan Law failure mode. One value, one entity; verify every URL points where you mean.
• Marking up the wrong pages. Google recommends placing Organization schema on your homepage or a dedicated About page — it does not need to be repeated on every page site-wide.
• Assuming you need Wikipedia. You don’t. Wikidata (much easier to create and edit) plus consistent cross-source signals can establish entity-hood; Wikipedia is one strong signal, not a hard requirement.
• Expecting a guaranteed Knowledge Panel. Schema can make you eligible; Google decides. There is no “submit for panel” button.

Where to go next

This hub is the map. Each identity type has its own deep dive — implementation, required and recommended properties, and validation:

• Organization Schema — the base type for any brand or company: where it goes (homepage/About), the name/logo/url/sameAs foundation, and @id graph linking. Start here if you do nothing else.
• LocalBusiness Schema — the specialized subtype for physical/local presence: address, hours, geo, service area, and choosing the most specific business subtype.
• Person Schema — establishing an individual’s identity: authors, founders, experts, and personal brands, and how to link a Person to an Organization.

All three sit under the broader structured data / schema markup cluster this hub belongs to — if you’re still fuzzy on the vocabulary, formats (JSON-LD vs. Microdata), and how rich results differ from entity understanding, start with the schema markup overview first, then come back here for the identity layer.

AI summary

A condensed take on the Advanced version:

• What it is: “entity & identity schema” is a practitioner label — non-exhaustive, not an official category — for three schema.org types that declare who/what is behind a site: Organization, LocalBusiness, Person.
• Identity vs. content schema: content types (Article, Product, FAQPage) describe the page and chase rich results; identity types describe the publisher and do disambiguation/entity understanding — usually no visible badge.
• The three types relate hierarchically: LocalBusiness is a subtype of Organization (use the most specific applicable type); Person is the individual counterpart. Sites often use several, linked via @id.
• sameAs is the core mechanic: schema.org defines it as a URL to a reference page that unambiguously identifies the entity (Wikipedia, Wikidata, and verified social profiles are examples, not requirements). Rules: one value = one entity (never reuse), and it’s an identity-resolution signal — not a ranking boost, a trust lever, or a documented AI-citation mechanism. A wrong sameAs misattributes your entity (the Ryan Law anecdote).
• @id is a JSON-LD node identifier that lets you connect Organization/WebSite/ Person nodes into one graph within your markup; how confidently Google stitches that across separately-crawled pages isn’t documented, so treat it as a spec-compliant convention, not a proven cross-page signal.
• Not a ranking factor; no guaranteed Knowledge Panel. It can make you eligible for panel/logo treatment and feed the Knowledge Graph; Google still decides.
• AI-search angle: ranking ≠ being recognized as a citable entity, and identity schema is plausible entity infrastructure — but there’s no primary evidence it causes AI recognition or citation (Mueller: “yes, no, and it depends”). Ahrefs also argues entity SEO isn’t a separate discipline at all — quoting Patrick: “the entity identification part is more on Google’s end than on our end.”
• Placement: Organization on the homepage or About page — not every page.
• Myth-busting: you don’t need Wikipedia (Wikidata + cross-source signals work).
• Where to go next: Organization Schema, LocalBusiness Schema, Person Schema deep dives; start with the schema markup overview if the vocabulary is still fuzzy.

Official documentation

Primary-source documentation on entity and identity types.

Google

• Organization structured data — the core doc: how Organization schema helps Google understand and disambiguate your organization, the sameAs definition, the “no required properties” guidance, and homepage/About placement.
• Local Business structured data — the LocalBusiness subtype: address, hours, geo, department, and which business subtypes Google supports.
• Intro to structured data markup — how Google uses structured data to understand the page and gather information about the world, and the “most specific applicable type” guidance.
• General structured data guidelines — quality/spam rules: mark up only visible content, use the most specific type, keep it accurate.
• Knowledge Graph Search API — the developer API for querying entities (a tool for searching the Knowledge Graph — not the ranking-facing Knowledge Panel system; don’t conflate the two).
• Rich Results Test / Schema Markup Validator — validate your markup (the schema.org validator covers types that produce no rich result, like Organization and Person).

Bing / Microsoft

• Bing Webmaster Guidelines — Bing’s support for schema.org structured data.
• Marking up your site with structured data — Bing’s structured-data help and Markup Validator.

Quotes from the source

On-the-record statements. Where a page exposes the text, the link is a deep link that jumps to the quoted passage.

Google docs — Organization schema and disambiguation

• “Adding organization structured data to your home page can help Google better understand your organization’s administrative details and disambiguate your organization in search results.” Jump to quote
• On disambiguation properties: “Some properties are used behind the scenes to disambiguate your organization from other organizations.” Jump to quote
• On required properties: “There are no required properties; instead, we recommend adding as many properties that are relevant to your organization.” Jump to quote
• On sameAs: “The URL of a page on another website with additional information about your organization” — for example, a profile page on a social media or review site. Jump to quote

Google — sameAs identity semantics (paraphrase)

• Across Google’s structured-data docs the consistent instruction is that a sameAs value must unambiguously identify the entity — you shouldn’t use the same sameAs value for two different entities. This is the mechanic behind entity resolution. Paraphrased: this phrasing recurs across several Google structured-data pages rather than one canonical quotable page, so it’s summarized here, not presented as a single verbatim citation.

John Mueller, Google — schema and LLM/entity understanding (paraphrase)

• Asked whether extensive schema markup helps LLMs understand entities better, Mueller reportedly answered that it’s a “yes, no, and it depends” question: structured data helps engines understand the entities on a page and is most valuable for precise details, but it doesn’t make an entity rank higher or get labeled “best” in AI answers — broader authority signals still dominate. Relayed via Search Engine Roundtable’s coverage; paraphrased, not confirmed as a verbatim quote. Do not treat the exact wording as final.

Patrick Stox, quoted by Ahrefs — is entity SEO a separate discipline?

• “The entity identification part is more on Google’s end than on our end.” Jump to quote — from Ahrefs’ “Entity SEO is Just SEO” piece, arguing that most “entity SEO” tactics are ordinary SEO rather than a distinct discipline.

When to use Organization vs. LocalBusiness vs. Person

Decision shortcuts

• Have a brand/site? → Organization (almost always).
• Physical or local business? → LocalBusiness (the specific subtype) instead of generic Organization — use the most specific applicable subtype.
• Named individual to establish? → Person, usually alongside Organization, linked with @id.

Fast facts

• “Entity/identity schema” = not an official category; it’s a label for these three identity-bearing types.
• Core mechanic = sameAs → Wikipedia / Wikidata / verified social profiles.
• One sameAs value = one entity. Never reuse or misdirect it.
• Not a ranking factor. No guaranteed Knowledge Panel.
• sameAs = identity-resolution signal, not a trust/authority lever.
• Place Organization on the homepage/About, not every page.
• No Wikipedia required — Wikidata + cross-source signals can establish entity-hood.

Treating identity schema like a rich-result task

I see people implement Organization or Person markup and then check the Rich Results Test, waiting for a badge that was never coming. Why it’s wrong: identity schema’s job is disambiguation, not SERP decoration — most of it produces no visible enhancement at all, so judging it by “did a rich result show up” makes you conclude the markup “didn’t work” when it’s actually doing exactly what it’s supposed to do. Do instead: judge identity schema by whether Google can confidently identify your entity — validate the markup, confirm sameAs values resolve to the right profiles, and stop expecting a visual payoff.

Reusing or misdirecting a sameAs value

The failure mode here is concrete, not hypothetical: Ryan Law at Ahrefs once had his personal sameAs pointing at Ahrefs’ blog instead of his own author page, and Google misattributed his personal entity to Ahrefs’ site. Why it’s wrong: a sameAs URL has to unambiguously identify one entity — reusing the same value across two different entities, or pointing it at the wrong profile, doesn’t just fail to help, it actively misattributes who you are. Do instead: apply the one-value-one-entity rule strictly, and double-check every sameAs URL actually points at your profile before publishing, not a lookalike or a parent brand’s.

Marking up Organization on every page site-wide

Some sites repeat full Organization JSON-LD on every template, treating it like a tracking pixel. Why it’s wrong: Google’s guidance is to place Organization schema on the homepage or a dedicated About page — repeating it everywhere adds maintenance risk (one stale copy drifts from the rest) without adding any signal strength. Do instead: mark up Organization once, on the homepage or About page, and link other identity nodes (Person, WebSite) into that one graph via @id rather than duplicating the whole block.

Assuming you need a Wikipedia page to be a recognized entity

I regularly hear “we can’t do entity schema, we don’t have a Wikipedia page” as if that’s a blocker. Why it’s wrong: Wikipedia is one strong signal among many, not a requirement — plenty of real, well-established entities have no Wikipedia page and still resolve fine. Do instead: create or claim a Wikidata entry (much easier to create and edit than Wikipedia) and keep your cross-source signals — social profiles, directories, consistent name/logo usage — consistent; that combination can establish entity-hood on its own.

Expecting a Knowledge Panel as a guaranteed outcome

I’ve had people ask why their new Organization markup didn’t “trigger” a Knowledge Panel within a week. Why it’s wrong: entity schema is not a ranking factor and does not guarantee a Knowledge Panel — it can make you eligible, but Google decides whether and when a panel appears, and there’s no “submit for panel” button to press. Do instead: treat correct, accurate markup as necessary infrastructure, not a request form — implement it well, keep your sameAs and cross-source signals consistent, and let entity recognition build over time rather than measuring success against a panel appearing on schedule.

Check what entities your page actually surfaces

My Entity Coverage Analyzer extracts the likely entities on a page, lets you reconcile which matches are correct, and drafts transparent about/mentions JSON-LD from the result. Run it before you write any Organization or Person markup by hand — it shows you what a machine already infers about the page’s entities, so your schema reinforces that reading instead of contradicting it.

Confirm whether Google’s Knowledge Graph already knows you

My Google Knowledge Graph Explorer looks up whether Google’s Knowledge Graph has resolved a person, company, or brand — returning the entity’s name, types, description, and machine ID if it exists, plus copy-paste schema.org JSON-LD if it does and a step-by-step playbook if it doesn’t. This is the direct way to check whether your Organization or Person schema and sameAs links have actually helped Google line you up as a distinct entity, rather than guessing.

Validate your Organization, LocalBusiness, or Person JSON-LD

My Schema Markup Validator checks JSON-LD or a full HTML page for schema.org vocabulary errors, Google’s structured-data requirements, and cross-block @id graph consistency, then hands back a corrected, copy-pasteable block. Since Organization, LocalBusiness, and Person produce no rich result to visually sanity-check, running the markup through a validator is the only reliable way to catch a typo’d property or a broken @id link before it ships.

Test yourself: Entity & Identity Schema

Five quick questions on Organization, LocalBusiness, Person, and what identity schema does (and doesn’t) do. Pick an answer for each, then check.

Resources worth your time

Related schema writing

• Schema Markup — the vocabulary overview: schema.org, formats (JSON-LD vs. Microdata/RDFa), rich results vs. entity understanding. Start here if the basics are fuzzy.
• Schema Markup for AI — the AI-search angle: why schema is entity infrastructure, not a direct citation lever.
• AI Search / GEO — being ranked vs. being recognized as a citable entity by AI answer engines.

From the industry

• Google’s Knowledge Graph Explained: How It Influences SEO & AI Search (Ahrefs — Despina Gavoyannis & Michal Pecánek, reviewed by Ryan Law) — what an entity is, how Google resolves it across sources, sameAs practice, and the Ryan Law sameAs cautionary tale.
• What is the Google Knowledge Graph? (Ahrefs SEO glossary) — a short definition of the entity store these schema types feed.
• When and how to use knowledge graphs and entities for SEO (Search Engine Land) — industry framing on entities and the Knowledge Graph.
• Using @id in Schema.org Markup for SEO, LLMs, & Knowledge Graphs (Momentic) — how @id connects Organization/Person/WebSite nodes into one graph.
• Stop Overcomplicating Things. Entity SEO Is Just SEO (Ahrefs — Si Quan Ong, quoting Patrick) — the counter-argument that entity SEO isn’t a separate discipline, since identification happens on the search engine’s side.

Straight from the source

• Organization structured data (Google) — the primary implementation doc for the base identity type.
• schema.org — Organization / LocalBusiness / Person — the vocabulary definitions and full property lists for each type.
• JSON-LD 1.1 — Node Identifiers (W3C) — the spec definition of @id as a JSON-LD node identifier, independent of any search engine’s cross-page behavior.

Entity & Identity Schema

"Entity & identity schema" is a practitioner label — not an official Google or schema.org category, and not exhaustive of identity-capable schema.org types — for the three main types that declare who or what is behind a site: Organization, LocalBusiness, and Person.

Related: Organization Schema, LocalBusiness Schema, Person Schema, Schema Markup

Entity & Identity Schema

Entity & identity schema isn’t a term Google or schema.org uses themselves — it’s my shorthand for the small group of schema.org types whose job is to declare who or what is behind a site, rather than describe a page’s content. It’s also not the complete list of identity-capable schema.org types — just the three that matter most for this job: Organization (any company or brand), LocalBusiness (the more specific subtype for a business with a physical or local presence), and Person (an individual — an author, founder, expert, or personal brand).

The line that separates these from the rest of schema markup is identity vs. content. Types like Article, Product, or FAQPage describe what’s on the page. Organization, LocalBusiness, and Person describe the entity that publishes it — and, through the sameAs property, connect that declaration to other authoritative records of the same entity. Schema.org defines sameAs as a URL to a reference page that unambiguously identifies the item; Wikipedia, Wikidata, and verified social profiles are the examples it gives, not requirements.

schema.org’s type hierarchy backs this framing: LocalBusiness is a direct subtype of Organization (Thing > Organization > LocalBusiness), and Google’s own guidance is to use the most specific applicable subtype. Person sits in its own branch (Thing > Person). None of the three is a ranking factor, and none guarantees a Knowledge Panel — their documented value is helping Google and other engines identify and disambiguate the entity, which can feed the Knowledge Graph. Whether it also affects whether AI answer engines recognize a brand as a distinct, citable thing is a plausible but currently unproven hypothesis, not a documented mechanism.

Related: Organization Schema, LocalBusiness Schema, Person Schema, Schema Markup

Changelog