Foundation
AI can't cite what
it can't verify
Why the Verification Stack — not content — is the difference between being cited and being ignored.
AI doesn't decide not to cite you. It can't verify you exist. There's a difference — and it's the entire reason most enterprise brands are quietly invisible in AI answers despite huge content libraries, decent SEO, and recognisable names. The verification gap is a structured-data problem, not a content one. Which means more content can't fix it.
LLMs are explicitly trained to avoid hallucinating about entities they can't verify. So when an AI assistant gets asked about your category and your brand has no Knowledge Graph entry, no Wikidata presence, and inconsistent schema across your site, it has three options. It omits you. It describes you vaguely. Or — and this happens more than it should — it attributes your work to a competitor it can verify. All three are common. All three are quietly catastrophic. None of them are content problems.
AI doesn't decide not to cite you. It can't verify you exist.
/ 01
Why this stage exists at all
Most enterprise marketers, of course, have heard of structured data. Most have some Organization schema kicking around on the homepage from when the SEO team set it up four years ago. Some have a Wikipedia page; a few have stumbled into a Knowledge Panel. But almost none have built what the work actually requires — a coherent, cross-referenced Verification Stack that lets AI resolve them as a single, consistent entity across every surface it encounters.
The Verification Stack is the cluster of structured artifacts AI uses to ground citations: the Wikidata entry, the Organization schema, the sameAs array connecting them, the Person schema for the humans who write the content, and — eventually — the Knowledge Graph entry that ties it all together inside Google's system. Each piece does one job. Together they tell AI this brand is real, here's who they are, here's what they're known for, here's where else they appear, and here's how to verify all of it independently.
Without the Stack, AI is making decisions based on unstructured web text — which is exactly what it's trained not to trust. With the Stack, AI has structured, machine-readable, cross-referenced facts about the brand that it can ground claims to. The difference, honestly, is enormous.
There's also a sequencing reason this stage matters. Google AI Mode and AI Overviews ground their answers in the Knowledge Graph directly. ChatGPT, Claude, and Perplexity weren't trained on Google's Knowledge Graph — but they were trained on Wikipedia and Wikidata at scale, which are upstream of it. Build the Stack well and you improve visibility across every major AI platform at once. Skip it, and you're invisible across every major AI platform at once.
/ 02
The playbook
Five moves, in sequence. Total time for a serious enterprise build is 25–40 hours over three to six weeks — Wikidata entries take time to stabilise, and Knowledge Graph recognition is measured in weeks-to-months, not days.
Move 01
Audit what AI currently sees
Before building anything, find out what's broken. The entity audit covers four surfaces:
Branded prompt baseline
Run “What is [Brand],” “Is [Brand] legit,” “[Brand] reviews,” and “[Brand] vs [top competitor]” through ChatGPT, Claude, Perplexity, and Google AI Overviews. Record what AI says about you in response to direct queries. The answers are usually somewhere between awkward and alarming — outdated descriptions, mis-attributed products, executives who left three years ago. Document everything.
Schema audit
Run the homepage and 5–10 representative content pages through Google's Rich Results Test and Schema.org's validator. Look for: missing Organization schema entirely, Organization schema that contradicts itself across pages, missing Person schema on author bylines, broken sameAs URLs, no @id properties tying pieces together.
Wikidata check
Search wikidata.org for the brand name and the founder name(s). Some brands have auto-generated entries from Wikipedia they don't know about. Some have entries that are incomplete or wrong. Some have nothing at all.
Knowledge Panel check
Search the brand name on Google and see if a Knowledge Panel renders. Note what it contains, what's missing, and whether it includes the wrong logo — a surprisingly common problem.
This is the “before” snapshot. Screenshot everything. Half the impact of the work shows up weeks after deployment, and the screenshots are what protect the engagement during the lag.
Move 02
Build the Wikidata entry
Wikidata is the off-site anchor of the Stack — and it comes first, because the Organization schema you'll write in Move 3 needs to link to it via sameAs.
Unlike Wikipedia, Wikidata has no notability threshold. The bar is verifiability: the entity must be real, have at least one external reference, and not be a duplicate. A consultancy, a SaaS startup, a regional law firm, a nonprofit — all qualify. Total time for a complete first entry is about two hours.
The critical properties to populate, each with a reference URL where possible:
Label and description
Official brand name, one-sentence plain-language description.
Instance of (P31)
The most important classification statement. Organization (Q43229), business (Q4830453), or a more specific type if applicable (consulting firm, marketing agency, SaaS company).
Official website (P856)
The primary URL. This is the link that ties Wikidata back to your domain.
Inception (P571)
Founding date, YYYY-MM-DD format.
Country (P17) and headquarters location (P159)
Geographic anchor points the entity recognition system uses to disambiguate similarly-named organisations.
Founder (P112) and CEO (P169)
Each linked to their own Wikidata person items, which you may need to create.
External identifiers
LinkedIn organization ID (P4264), Crunchbase organization ID (P2088), Twitter/X username (P2002), and any industry-specific registries. These are exactly what Google's Knowledge Graph uses for cross-referencing.
Two operational warnings, both from the Wikidata community guidelines, both ignored at your peril:
Don't bulk-fill
Wikidata editors are suspicious of new accounts that show up and fill out an entire entry in one session — it pattern-matches to marketing spam. Add the most important properties first, then return over a week or two to add the rest. Ease in.
Don't edit your own entry without disclosure
Contributors too close to a subject get their edits flagged or removed for conflict of interest. Better to use a dedicated organisational account, disclose the relationship on the user page, and add value to adjacent unrelated entries first to build trust.
Move 03
Deploy Organization schema
Organization schema is the on-site anchor. It's also where most enterprise teams either don't have it at all, or have a version that contradicts other markup on the same domain.
Deploy JSON-LD in the head of the homepage, and reference it via @id from every other schema block on the site. The minimum useful properties:
@context, @type, @id, name, url, logo
The core. The @id should be a stable URI like https://www.yourcompany.com/#organization so other schema blocks can reference it without duplicating the whole object.
description, foundingDate, knowsAbout
Declared expertise topics matter for AI weighting.
address, contactPoint
For AI Overviews answering location and contact queries.
founder, employee
Referencing the Person schema entities you'll build in Move 5.
sameAs
The critical property. An array of URLs pointing to every authoritative external profile. Wikidata first (the Q-number URL from Move 2), then Wikipedia if applicable, then LinkedIn company page, Crunchbase, official Twitter/X, GitHub if relevant, the founder's LinkedIn.
The sameAs property is what does the heavy lifting here. Search Engine Land's entity guidance — and frankly every credible source on the topic — points to sameAs as the single most important property for Knowledge Graph entity recognition. It's how AI cross-references “the company on this website” with “the company on Wikidata” with “the company on LinkedIn” and concludes they're the same entity.
One small detail that matters: every URL in sameAs must resolve. Dead profiles, redirects, abandoned LinkedIn pages — these actively weaken the signal, because they make the brand look fragmented across sources that can't be verified. Audit and prune ruthlessly.
Move 04
Connect the graph in both directions
The sameAs array in your Organization schema points outward. Verification only holds when the connections run both ways — every profile in the array also needs to point back at you. A one-directional graph reads to AI like an unverified claim. A bidirectional graph reads as a verified entity. The work is in three parts:
Update every authoritative profile
LinkedIn company page, Crunchbase, G2/Capterra if relevant, Google Business Profile, Bing Places — to use the same name, the same description, and to link to your website as the official URL. Each one needs to be reachable from the Organization schema and reach back to it.
NAP consistency
Name, Address, Phone Number — identical, character for character, across every listing. Variations (“Inc.” vs “Incorporated,” different suite numbers, different phone formats) fragment the entity signal and force AI to guess which version is canonical.
Link Wikidata back to your other authoritative profiles
Using the external identifier properties — the Q-numbers from Move 2 now bind in both directions. This closes the loop: site ↔ Wikidata ↔ LinkedIn ↔ Crunchbase ↔ Wikipedia (if applicable), each one verifying the others.
This is unglamorous work. It's also the work that produces the most dramatic before/after in AI responses, because a bidirectionally-connected entity is what AI uses to decide whether a brand is one coherent thing or three plausibly-different ones.
Move 05
Stand up Person entities for authors
Content without a verifiable human author is, weirdly, one of the strongest hidden penalties in AEO. AI systems trained on E-E-A-T-style signals weight content far more heavily when the author can be resolved as a real, qualified person. Bylines without Person schema are bylines AI can't trust.
For every author who writes on the site, build:
A hub page
One canonical author bio page on the company domain. Full name (exactly as it appears on bylines), current role, credentials relevant to the topic, links to every external platform where they publish, professional photograph matching profile images on those external platforms.
Person schema on the hub page
Name matching the byline exactly, jobTitle, worksFor referencing the Organization @id, sameAs array linking to LinkedIn, any industry publication profiles, Google Scholar if applicable, professional directory listings.
Article schema on every post they write
Author property referencing the Person @id, publisher referencing the Organization @id. This builds the trust chain AI walks: Article → Author → Organization.
The work compounds. Once a Person entity is verifiable, every piece of content that author publishes — on your site, on LinkedIn, on third-party publications — strengthens the entity. Skip the Person work and every byline starts from zero, forever.
/ 03
What to measure
Five entity-foundation signals. Most won't move overnight — Knowledge Graph recognition takes weeks to months — so report on these quarterly rather than monthly, paired with the branded-prompt baseline from The Brief.
Knowledge Panel status
Y/N, and if Y: what it contains, what's missing, whether the logo and description are correct. The Panel is the single most visible confirmation that Google has resolved you as an entity.
Wikidata entry completeness
Number of populated properties (target: 15+), percentage of statements with reference URLs (target: 80%+), and whether the entry is connected to a Wikipedia article via sitelink.
Schema validation health
Pass rate on Rich Results Test across homepage, about, contact, and the top 20 content pages. Track validation errors and warnings over time. Errors trending down = healthy.
Branded prompt sentiment
From the priority-1 prompt library — specifically the “What is [Brand],” “Is [Brand] legit,” and “[Brand] reviews” cluster. Is AI describing you correctly? Attributing your products to you? Naming the current CEO? Track factual accuracy as a percentage.
NAP consistency score
Audit the top 20 listings and count exact-match Name/Address/Phone. Inconsistencies fragment entity signal — and unlike most of this work, NAP cleanup pays off in days, not months.
/ 04
Common failure modes
Five patterns we see in almost every enterprise audit. They compound, which is the bad news — and they're almost all fixable in weeks rather than months, which is the good news.
Schema that contradicts itself
Organization markup on the homepage says one thing. Product schema on the pricing page says another. Author markup is missing entirely from blog posts. AI systems trying to ground a citation see three different versions of the brand and trust none of them. We see this in almost every enterprise audit we run — and the fix is mostly editorial: pick one source-of-truth Organization schema, give it a stable @id, and have every other schema block on the site reference it.
The Anonymous Author Problem
Every blog post has a byline. None of the bylines have Person schema. Half of them point to author pages that don't exist; the other half point to thin author pages with no credentials, no sameAs links, no photograph. From AI's perspective, the content has no human accountability — which means it gets weighted as low-trust regardless of how good the writing is. This is one of the highest-leverage fixes in the entire Foundation layer because it touches every piece of content the site has ever published.
sameAs that points to nothing
The Organization schema has a sameAs array. Two of the URLs 404. One redirects to a parked domain. One points to a LinkedIn profile that hasn't been updated since 2021. Each broken link is a verification failure, and verification failures accumulate. AI doesn't read intent — it reads connectivity.
The Wikidata Trojan Horse
A marketer creates a Wikidata account, fills out the entire entry in one sitting, links every property to the company website, and adds no references to independent sources. Within 48 hours, an editor flags it for promotional bias and either guts the entry or deletes it entirely. Two months of work lost — with the side effect of making future submissions harder. The fix is patience. Ease in, add the most important properties first, return over a week or two, and reference independent sources wherever possible.
Treating the Knowledge Panel as a goal
The most common strategic mistake. Teams set “get a Knowledge Panel” as the target and try to apply for one directly. You don't apply for a Knowledge Panel. You earn one — by building the Wikidata entry, deploying complete Organization schema with a full sameAs graph, maintaining NAP consistency across 10+ authoritative platforms, and standing up Person entities for your authors. The Panel is the outcome of the Stack, not a deliverable you can request. Treating it as a goal produces three months of wasted effort. Treating it as a downstream signal produces one within six.