Build entity authority AI can verify
AI doesn’t recommend brands.
AI recommends entities it can verify.
And if your “entity” isn’t clean, consistent, and well-referenced across the web… you get the modern marketing nightmare:
- The AI mixes you up with another company.
- It grabs an old founder bio from 2018 and treats it like gospel.
- It invents a headcount, a headquarters, a tagline, a parent company.
- It says you do “enterprise AI consulting” when you sell wedding photography.
Why?
Because the model is trying to answer a very simple question:
“What is this thing?”
…and when it can’t answer confidently, it builds a story out of whatever it finds.
Dave’s line on this is blunt for a reason:
“If you don’t define your brand for AI, AI will define it for you using whatever it finds.”
This pillar post is about taking control of that “whatever it finds.”
Not with vibes.
With structure:
- canonical brand facts
- sameAs links
- entity IDs
- knowledge graph references
- and a workflow to fix wrong answers like it’s an operational system (because it is)
What entity authority means
Let’s demystify the buzzword.
Entity authority is the probability that a machine can:
- Recognize your brand as a distinct entity (not a keyword, not a logo, not “some company”).
- Disambiguate you from similarly named entities.
- Retrieve stable, consistent facts about you from sources it trusts.
- Cite those sources (or at least align with them) across answers.
Google has been moving this direction for years. Their Knowledge Graph framing is literally “things, not strings.”
And it’s not just “search.”
AI interfaces are now showing entity panels and stitched summaries where the system is pulling from third-party sources and citing them. In AOK’s own experiment, the takeaway was clear: the panel wasn’t just homepage copy — it was assembled from sources across the web.
Like this Starbucks example:
So entity authority is less “rank my page” and more:
Can the machine confidently resolve you?
Or to use another AOK phrase:
SEO is becoming Entity Operations.
Old SEO was: keywords, pages, links.
AI-era SEO is: entity clarity, source control, fact consistency, authoritative references.
Why does AI get our company wrong?
Here are the most common reasons I see — and why they’re predictable.
1) Name collisions (you share a name with someone else)
If you’re “Summit Marketing” or “Blue River” or “Axis”… there are probably 14 of you.
Machines don’t “intuit” which one is you. They match patterns.
If your footprint is weak, you get merged.
2) Your own site is inconsistent
These are silent killers:
- “Acme, Inc.” vs “Acme” vs “Acme Labs”
- 3 different founding years across pages
- old office address still on the footer
- phone number differs on contact page vs schema vs Google Business Profile
- 2 “About” pages with different positioning statements
If you can’t keep your own facts straight, don’t expect AI to do it for you.
3) Third-party sources contradict each other
AI systems build trust by triangulating.
If Crunchbase says one thing, LinkedIn says another, and your website says a third… you’ve basically told the model:
“Pick one. Good luck.”
And it will.
4) You don’t have “identity anchors”
Machines love stable identifiers.
That’s where sameAs and entity IDs come in.
Schema.org defines sameAs as a URL that unambiguously indicates identity (Wikipedia, Wikidata, official site, etc.).
Think of sameAs as your digital fingerprint. Not the whole solution — but a crucial piece.
5) Your brand isn’t “worth being careful about” (yet)
This one hurts, but it’s real.
Systems allocate confidence based on signals. If you’re a small brand with little coverage and inconsistent data, the model’s uncertainty is higher.
In AOK’s ChatGPT entity panel post, the point is framed in business terms: entity panels affect trust and decisions by investors, journalists, procurement, candidates, regulators — not just traffic.
If those people are using AI to form first impressions, your “entity clarity” becomes PR.
The single source of truth: your Brand Facts Sheet
If you do nothing else after reading this, do this:
Build a Brand Facts Sheet.
Not a fluffy brand deck.
A factual, canonical, version-controlled doc that answers:
- What are the official facts about the entity?
- What are the approved descriptions?
- What IDs and references define it across the web?
Because when facts drift, you need a place to point and say:
“This is the source of truth.”
Brand Facts Sheet template
Use this as a starting point (copy/paste into a Google Doc, Notion, or a spreadsheet).
1) Identity block (the “who are we?” core)
- Canonical name (brand name used publicly)
- Legal name (registered name, if different)
- Alternate names (DBAs, abbreviations, old names)
- Tagline (current)
- One-sentence description (approved)
- Long description (approved 80–150 words)
- Category (what you are — pick the simplest correct label)
- Primary offer (what you sell)
- Primary audience (who you serve)
2) Key facts block (the “things AI gets wrong” block)
- Founding date (YYYY-MM-DD if possible)
- Founders (names + titles)
- CEO / key executives (names + titles)
- Headquarters (city, region, country)
- Primary phone
- Primary support email
- Primary physical address (if applicable)
- Service area (if local/regional)
- Parent company / subsidiaries (if applicable)
3) Web presence block (canonical URLs only)
- Homepage URL
- About page URL (canonical)
- Contact page URL (canonical)
- Press page / media kit URL
- Logo URL (crawlable)
- Brand images / headshots (URL list)
4) Social profile block (official handles)
- LinkedIn company page
- X
- YouTube
- TikTok
- GitHub (if relevant)
- Substack / Medium (if official)
5) Entity references block (the “machine anchors”)
- Wikidata QID (if exists)
- Wikipedia page (if exists)
- Google Business Profile (if applicable)
- Apple Business Connect (if applicable)
- Industry directories that matter (G2 / Capterra / Clutch / etc.)
- Data providers relevant to your vertical
6) Change log (this is what makes it operational)
Track:
- what changed
- when
- why
- who approved it
Because your brand facts will change (new address, new CEO, rebrand), and you need controlled updates.
sameAs + entity IDs checklist
This is the “entity footprint” work. This is where you stop being “just a website” and start being a resolvable entity.
Step 1: Create a canonical entity ID (source of truth) on your own site
You want one stable identifier for your organization, usually as a URL.
Example:
https://example.com/#organization
That becomes your internal “entity node” you reference in structured data.
Step 2: Add Organization structured data (and do it right)
Google explicitly supports Organization markup and recommends putting it on the homepage or a single page like an About page (not necessarily every page).
They also recommend focusing on properties useful to users (name/alternateName, real-world presence like address/telephone, online presence like url/logo).
And importantly: Google calls out that url helps uniquely identify your organization.
Step 3: Use sameAs like a sniper, not a shotgun
Schema.org’s definition is very specific: sameAs should point to a page that unambiguously indicates identity.
Google’s Organization documentation describes sameAs as links to pages on other websites with more info about your organization (social, review sites) and notes you can provide multiple sameAs URLs.
Rule: Only link profiles/pages that are the same entity.
Not “related.”
Not “partner.”
Not “a random directory page that mentions us once.”
Step 4: Validate your structured data
Google’s structured data guidelines recommend supported formats and explicitly list JSON-LD as recommended.
They also note you can test compliance using tools like Rich Results Test and URL Inspection.
And they’re clear on a key quality point: don’t mark up content that isn’t visible to readers — the markup and page content should match.
Step 5: Build the Entity ID Map (your “sameAs inventory”)
This is the part most brands skip.
They add schema once.
Then they forget it.
Instead, build a living “Entity ID Map” that includes:
- Platform
- Canonical URL
- Entity ID (if the platform has one)
- Ownership status (claimed/unclaimed)
- Notes (what needs fixing)
Here’s the checklist of what to include:
sameAs / entity reference candidates (pick what’s real for you)
Tier 1: Always
- Official website (canonical URL)
- LinkedIn company page
- Any other official social profiles
- Official YouTube channel (if active)
Tier 2: Often
- Crunchbase
- GitHub org
- App stores / marketplace profiles (if SaaS)
- Major review platforms relevant to your industry
- Major media profiles (if you have them)
Tier 3: Knowledge graph anchors
- Wikidata item (QID)
- Wikipedia page (if legitimately earned)
Tier 4: Local / regulated / compliance
- Google Business Profile (local)
- Apple Business Connect (local)
- Government registries (where appropriate)
- Industry accrediting bodies (where appropriate)
What to put in your Organization JSON-LD (example)
Here’s a practical JSON-LD skeleton you can adapt.
{
“@context”: “https://schema.org”,
“@type”: “Organization”,
“@id”: “https://example.com/#organization”,
“name”: “Example Brand”,
“legalName”: “Example Brand, Inc.”,
“alternateName”: [“Example”, “Example Co.”],
“url”: “https://example.com/”,
“logo”: “https://example.com/assets/logo.png”,
“description”: “Example Brand helps X do Y with Z.”,
“foundingDate”: “2016-04-12”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main Street”,
“addressLocality”: “New York”,
“addressRegion”: “NY”,
“postalCode”: “10022”,
“addressCountry”: “US”
},
“telephone”: “+1-646-555-1234”,
“sameAs”: [
“https://www.linkedin.com/company/examplebrand/”,
“https://www.wikidata.org/wiki/Q123456”,
“https://en.wikipedia.org/wiki/Example_Brand”
]
}
Two important notes:
- Don’t add foundingDate, address, executives, etc. unless you’re willing to keep them accurate everywhere. “Facts drift” is a real brand risk. (That’s why you need the facts sheet.)
- If you’re a local business, Google specifically notes LocalBusiness has required properties and additional guidance.
Do we need Wikidata or Wikipedia?
Let’s answer this like adults.
You don’t need Wikipedia to show up in AI answers.
But:
- Wikipedia and Wikidata are common reference points in knowledge systems.
- The Knowledge Graph itself has historically cited sources like Wikipedia (and previously Freebase).
- Wikidata is designed as a machine-readable, editable knowledge base.
So “need” isn’t the right word.
The right word is:
Leverage.
If you can legitimately earn those references, they become strong identity anchors.
But you can also build a strong entity footprint without them by getting your site, schema, and third-party references consistent and authoritative.
Wikidata/Wikipedia readiness path
This is where PR/Comms teams either win… or get themselves into a mess.
Step 1: Understand the difference
- Wikipedia is narrative + citations + editorial standards.
- Wikidata is structured facts + references + IDs.
Wikidata’s own framing: it’s a free and open knowledge base readable and editable by humans and machines.
Step 2: Know the bar for Wikipedia
Wikipedia’s notability guidance for organizations is blunt:
- Notable if there is significant coverage in reliable, independent secondary sources.
- If no independent, third-party reliable sources exist, Wikipedia shouldn’t have an article.
Translation:
Your press release doesn’t count.
Your blog doesn’t count.
Your partner’s blog doesn’t count.
Your paid advertorial doesn’t count.
The game is earned media and independent coverage.
Step 3: Don’t do the classic COI mistake
If you (or your agency) are closely connected to the company, Wikipedia considers that a conflict of interest.
Wikipedia explicitly says COI editing is strongly discouraged, and advises disclosure and proposing changes via talk pages instead of directly editing.
So don’t treat Wikipedia like a profile you “claim.”
Treat it like an encyclopedia you have to earn.
Step 4: A practical “readiness ladder”
Here’s the path I recommend for brands:
Level 0: Not ready
- No independent coverage
- Inconsistent brand facts everywhere
- Basic digital presence is messy
Action: fix your own house first (facts sheet + site consistency + schema + profile cleanup).
Level 1: Wikidata-ready
- The entity is identifiable
- You can cite verifiable references (official site, reputable sources)
- You’re prepared to keep facts accurate
Wikidata has a notability policy: an item is acceptable if it fulfills certain goals/criteria (including having sitelinks and meeting listed criteria).
Action: build a clean Wikidata item with references (and do it ethically).
Level 2: Wikipedia-ready
- Multiple independent reliable secondary sources with significant coverage
- Neutral tone possible
- COI handled properly
Action: do not brute-force publish a page. Use the right process (talk pages / Articles for Creation) and disclose COI.
Level 3: Knowledge panel-ready (the real win)
- Consistent entity across web
- Strong authoritative references
- Clear schema + sameAs
- Clean “about” narrative
This is where machines stop guessing.
Fix wrong AI answers workflow
This is the module that turns “AI got us wrong” from a panic into a process.
Because the fix is rarely “tell ChatGPT to stop.”
The fix is almost always:
Fix the sources the AI trusts.
Here’s the workflow.
Step 1: Capture the bad output like evidence
Create a shared doc/spreadsheet with:
- Prompt used
- Full AI answer
- Date/time
- Screenshot
- Links/citations shown (if any)
- What’s wrong (specific facts)
- Severity (low / medium / high)
If it’s a public-facing AI panel, treat it like a PR issue.
Step 2: Classify the error
Most errors fall into one of these buckets:
- Identity error (entity merge): It’s mixing you with another entity.
- Fact drift: It has an old address/CEO/founding date.
- Inference/hallucination: It’s guessing because it can’t verify.
- Narrative skew: It overweights one controversy or one review source.
- Relationship confusion: Parent/subsidiary/partner relationships are wrong.
Different category = different fix.
Step 3: Trace the likely source of truth conflict
Start with the “obvious” anchors:
- Your website About / Contact
- LinkedIn company page
- Major directories in your category
- Wikipedia/Wikidata (if present)
- Press coverage and bios
- Google Business Profile (if local)
Remember: AI panels and summaries are often assembled from third-party sources — not just your homepage.
Step 4: Fix your canonical facts first
Update:
- Brand Facts Sheet (source of truth)
- Website pages (About, Contact, Press)
- Structured data (Organization schema, LocalBusiness if applicable)
Google’s documentation is explicit that organization markup can include details like address/telephone and helps them understand your organization.
Also: keep markup aligned with visible content. If you update a fact in schema, update it on-page too.
Step 5: Fix third-party contradictions (the unglamorous part)
This is the work no one wants to do, but it’s where the wins are:
- Claim profiles you haven’t claimed
- Correct old addresses / phone numbers
- Update executive names and titles
- Remove duplicate profiles
- Standardize naming (exact punctuation matters more than you think)
Step 6: Strengthen identity anchors with sameAs
If you have stable references, add them.
Schema.org describes sameAs as linking to identity-unambiguous pages like Wikipedia/Wikidata/official site.
Google explicitly supports multiple sameAs URLs for Organization markup.
Step 7: Validate + monitor
Use structured data testing and keep a monitoring cadence.
Google’s guidelines mention testing with tools like Rich Results Test and URL Inspection for technical issues.
Then repeat your AI prompt tests monthly/quarterly and log changes.
Step 8: Create a “Fact Correction” public page (optional but powerful)
This is a secret weapon for PR/Comms teams.
A simple page that answers:
- official founding year
- official headquarters
- official leadership
- official product/service definition
- official parent/subsidiary relationships
- official naming conventions
It becomes a crawlable, citable correction hub.
(And yes, it should match your schema.)
The practical bottom line
AI isn’t sitting there thinking, “How do I represent this company fairly?”
It’s doing pattern matching and confidence scoring.
So your job is to make the pattern obvious:
- One entity
- One set of facts
- Many corroborating references
- Clean sameAs links
- No contradictions
Or, put in AOK terms:
You’re either shaping the sources… or you’re inheriting the narrative.
What to do now
If you want the fastest path to “verified, consistently described brand across AI answers,” do this in order:
- Build the Brand Facts Sheet (today).
- Audit your website for fact consistency (About, Contact, footer, schema).
- Implement Organization schema with a canonical @id.
- Add sameAs links only to true identity anchors.
- Clean up your top third-party profiles (LinkedIn, key directories, local listings).
- Decide your Wikidata/Wikipedia strategy based on notability + COI reality.
- Build the “wrong AI answer” log and turn it into a workflow.
That’s Entity Ops.
And if you want this pillar to work as a real “single source of truth” system (not just a one-time SEO task), assign ownership:
- Marketing owns narrative + positioning
- PR/Comms owns public references + coverage
- Web/SEO owns schema + technical implementation
- Someone owns the facts sheet like it’s governance (because it is)
About The Author
