Entity graph: can AI engines resolve your brand?

What this check measures

We look for an Organization-class block in your structured data (JSON-LD), including the common case where it is nested inside an @graph by an SEO plugin. When we find one, we report two kinds of verbatim fact. First, completeness: whether the Organization carries a name, a logo, and a url, the basic fields an engine needs to render and trust an entity. Second, anchoring: every sameAs link the Organization points at, normalized to its host and classified against named identity sources that knowledge panels actually resolve against, such as Wikipedia, Wikidata, LinkedIn, Crunchbase, X, Facebook, Instagram, YouTube, and GitHub. We then report which of those anchors are present, which are missing, and how broad the anchor set is. When no Organization-class block exists at all, we say so plainly rather than guessing.

Why it matters

AI answer engines do not cite strings, they cite entities. When an engine is deciding whether to name you in an answer, it tries to resolve "this brand" to a known node in the knowledge graph, and the more identity sources agree on who you are, the more confidently it can do that. A brand with an Organization block linked out to Wikipedia, Wikidata, LinkedIn, and Crunchbase is an entity an engine can pin down and attribute; a brand with no Organization schema and no identity links is an ambiguous string the engine may decline to name, or worse, may confuse with a similarly named company. For high-intent verticals where the same brand name can collide with others, well-anchored entity status is the difference between being cited as the authority and being left out because the engine was not sure who you were.

How we score it

We read the completeness fields and classify the sameAs hosts into named anchors, then roll those verbatim facts up into a coarse health band that drives the finding. The receipts side is fully exposed and reproducible: anyone can open your page source, find the Organization JSON-LD, and confirm the same name/logo/url presence and the same present and missing anchors we report. What stays server-side is how those signals combine into the band, because which anchors carry the most authority and how completeness and breadth come together is editorial judgment, not a measurement anyone needs to reproduce. We publish the anchor taxonomy and the verbatim facts; we keep the interpretation that produces the band to ourselves.

Confidence-flag rules

This check reads structured data already present on the page, so when an Organization block exists the read is high confidence: the anchors are a direct, checkable fact about what your sameAs array contains. The read is honest about its limits. A sameAs URL that does not parse, or points at a host we do not recognize as a named anchor, is simply not counted toward an anchor rather than guessed at. When the page carries no Organization-class block, we report a weak entity graph and say no Organization schema was found, instead of inferring anchors from elsewhere. We classify by host only, so a real profile is recognized regardless of the exact URL path, and we never invent an anchor the page does not actually link to.

Common mistakes

• Having social profiles but never linking them from Organization sameAs. The profiles exist, but the engine cannot connect them to your entity because the page never declares the relationship.
• Shipping an Organization block with a name but no logo or url, so the entity is present but too thin for an engine to render and trust confidently.
• Relying only on commodity social links (Facebook, Instagram) while skipping the identity sources knowledge panels actually resolve against, such as Wikipedia, Wikidata, LinkedIn, and Crunchbase.
• Nesting the Organization inside an @graph and assuming it does not count. It does, and we read it, but many older audits miss it entirely.

How to fix it

Add a site-wide Organization JSON-LD block with name, logo, and url, then give it a sameAs array that links to every verified identity source you have, prioritizing Wikipedia, Wikidata, LinkedIn, and Crunchbase where they exist, with social profiles as corroboration. Only link profiles you actually control and that are accurate, because a sameAs to a stale or wrong profile teaches the engine the wrong thing. After you publish the anchors, re-run the audit and confirm the previously missing anchors now show as present; a broader, authority-led anchor set is exactly what makes your brand easier for engines to resolve and cite. Every anchor we report is backed by a real URL in your own page source, so any claim here is one view-source away from verification.

Primary sources

• Schema.org Organization type (name, logo, url, sameAs)

  Schema.org

• Google Search Central, organization structured data and sameAs

  Google Search Central

• Wikidata, the free knowledge base AI engines resolve entities against

  Wikimedia Foundation

• Google Search Central, knowledge panels and entity understanding

  Google Search Central

Changelog

• 2026-06-23 · Initial publication. Documents the entity-graph health read: Organization schema completeness plus the named knowledge-panel anchors (Wikipedia, Wikidata, LinkedIn, Crunchbase, X, and other identity sources) found in your sameAs links, reported as verbatim present/missing facts while the band itself stays server-side.