An enterprise marketing team can deploy immaculate Organization schema, populate every recommended JSON-LD property, and still watch a generative engine attribute their own case study to a competitor with a similar name. This is not a crawling failure. The site was indexed correctly. The schema validated without errors. The failure occurred one layer downstream, in a process most technical SEO teams have never had to reason about: entity resolution — the mechanism by which an AI system decides whether the organisation described on your domain is the same organisation it already has a confident record of, or an unverified claim it should treat with scepticism.
This distinction matters because generative engines do not extend trust to a website in isolation. They extend trust to an entity, and entities are established through corroboration across independent, structured sources — not through self-declaration. On-site JSON-LD tells an engine what you claim to be. External knowledge graphs like Wikidata, alongside Companies House, LinkedIn and sector registries, tell an engine what can be independently verified. Until those two signals are reconciled, your `sameAs` links are inert — syntactically valid, semantically unconfirmed.
Retrieval-Augmented Generation Doesn’t Trust the Page — It Trusts the Graph
The architectural reason for this is retrieval-augmented generation (RAG), the pattern underlying how ChatGPT, Gemini and Perplexity construct factual claims about organisations. Rather than reasoning purely from parametric memory or from a single crawled page, these systems query pre-indexed, structured knowledge sources at inference time and use them to ground or corroborate what the model generates. Wikipedia functions as a default knowledge layer inside ChatGPT’s retrieval pipeline with sufficient regularity that independent analysis in August 2026 found it appearing in roughly one in six cited conversations — not because Wikipedia is definitive, but because it is structured, independently maintained, and cross-referenced against Wikidata’s entity graph via frameworks such as LangChain.
Gemini’s approach is architecturally distinct but converges on the same principle: models in the Gemini family are used to extract entities and relationships from raw text and assemble them into dynamic knowledge graphs, rather than treating a single page as an atomic unit of truth. Perplexity takes a third route, performing live retrieval across authoritative sources at query time and returning numbered citations — but the sources it treats as authoritative are disproportionately those with independent verification, not brand-controlled pages.
The common thread across all three is this: none of them ask “what does this website say about itself?” as the primary question. They ask “does an independent, structured record corroborate this claim?” A JSON-LD `Organization` block is a claim. Wikidata, Companies House and a verified LinkedIn company page are evidence. Engines are built to prefer evidence over claims, and this preference is precisely why research from late 2025 found that only around 9% of AI-generated responses cited a brand’s own website directly — the remaining 91% were sourced from third-party corroboration. A technical architecture that optimises exclusively for on-site schema is optimising for the 9% and ignoring the mechanism that governs the other 91%.
What `sameAs` Actually Does — and Where Teams Get It Wrong
The `sameAs` property is frequently implemented as a box-ticking exercise: a list of social URLs appended to the `Organization` schema because a technical SEO checklist said to include it. This misunderstands its function. `sameAs` is not a citation list. It is a merge instruction — a technical assertion to the knowledge graph that says, in effect, “this URL, this Wikidata item, this LinkedIn page, and this Companies House record all describe the same real-world entity, so consolidate them into a single node.” The strength of that merge instruction is entirely dependent on the authority of what it points to.
A `sameAs` array pointing exclusively to a Twitter/X profile and a Facebook page carries negligible disambiguation weight, because those platforms do not themselves perform identity verification or notability gatekeeping — anyone can register a page under any name. A `sameAs` array that includes a Wikidata item ID carries substantially more weight, because Wikidata items are subject to sourcing requirements and community review before they persist. This is why two organisations can implement structurally identical `Organization` schema, both technically valid, and receive materially different treatment from an AI engine’s entity resolution layer — the difference is not in the markup, it is in what the markup points to.
There is a second, quieter failure mode: internal inconsistency across the `sameAs` targets themselves. If your Wikidata item lists a different legal name, founding year, or headquarters location than your LinkedIn company page, and both diverge slightly from what’s registered at Companies House, you have not created three corroborating sources — you have created three competing claims. Entity resolution systems are built to detect this kind of divergence, and the effect is not neutral; it actively suppresses confidence. Coherent repetition of the same core facts across compatible, independent surfaces is what reduces ambiguity. Divergent facts, even minor ones — a trading name versus a registered name, a rounded founding year — do the opposite, and the cost is paid in the form of omission or misattribution at the point of generation.
The Wikidata Notability Threshold: Lower Than Wikipedia, Still Not Trivial
For UK enterprises, the practical obstacle is usually the assumption that Wikidata requires Wikipedia-level notability. It doesn’t. Wikidata’s threshold is deliberately broader, and an item is acceptable if it meets at least one of three conditions: it has a sitelink to an existing page on another Wikimedia project (most commonly Wikipedia); it describes a clearly identifiable entity supported by reliable, publicly available references such as press coverage, an industry database, or a government registry; or it serves a structural function within the graph itself, such as completing a corporate relationship (a subsidiary linked to a parent, for instance).
The second condition is the one most private UK companies should target, because it explicitly permits government registries — including Companies House — as qualifying references. This means a mid-sized enterprise with no press coverage and no realistic Wikipedia notability case can still create a legitimate, sourced Wikidata item, provided the claims in that item are backed by verifiable external references rather than the company’s own website.
Submissions fail for predictable, avoidable reasons. The most common is sourcing an item entirely from the brand’s own domain — a Wikidata entry that cites only the company’s “About Us” page is functionally unsourced from the graph’s perspective, because self-published claims are not independent corroboration. The second most common failure is tone: descriptions written with promotional language (“industry-leading,” “award-winning”) get flagged and reverted, because Wikidata’s editorial model requires neutral, factual description, not marketing copy. The third is duplication — creating a new item when one already exists under a slightly different name, which produces exactly the entity-collision problem this article is concerned with, rather than solving it.
The practical implication for a technical team is that a Wikidata submission is not a form-filling exercise delegated to a junior marketer. It requires the same evidentiary discipline as a due-diligence document: identify two or three genuinely independent, citable references (Companies House filing, a trade press mention, an industry directory listing), draft a neutral description with no adjectival inflation, and be prepared for the item to be reviewed and challenged before it stabilises.
Where Entity Collisions Actually Come From
Entity collision is rarely a single dramatic error. It accumulates from small structural gaps that compound over time, and it disproportionately affects exactly the kind of established, complex organisations that most need AI visibility — law firms with historic name changes, construction groups with multiple trading subsidiaries, healthcare groups formed through acquisition.
The most common collision type is straightforward homonymy: a company name that overlaps with an unrelated entity — another business, a person, a generic term. Without a disambiguating structured record, an AI engine has no reliable way to determine which entity a page, a mention, or a citation actually refers to, and it will either default to the more established entity in its training data or hedge by declining to attribute the claim at all.
The second is subsidiary and parent confusion. When a group structure exists — a holding company with several operating subsidiaries, or a rebrand where the trading name diverges from the registered legal name — and this relationship is not explicitly encoded in structured data on both sides, engines frequently attribute achievements, reviews, or credentials to the wrong node in the corporate graph. A case study genuinely delivered by the operating subsidiary can end up silently attributed to the parent, or vice versa, because nothing in the public data explicitly states the relationship.
The third is the defunct or stale record — a Companies House entry for a dissolved predecessor company, an old Wikidata item that was never updated after a rebrand, a LinkedIn page still listing a former registered name. These don’t just fail to help; they actively compete with the current, correct record for the engine’s confidence, fragmenting what should be a single coherent entity signal into two or three partial, contradictory ones. An engine encountering fragmented signals about the “same” organisation does not average them into a correct picture. It tends to reduce confidence in the entity as a whole, which increases the likelihood of omission from a generated answer entirely — the AI-visibility equivalent of simply not existing.
Secondary Corroboration When Wikidata Notability Isn’t Achievable
Not every organisation will clear even Wikidata’s broader threshold, and in those cases the correct response is not to abandon external entity-building but to construct a corroboration stack from sources that are independently authoritative even without a Wikidata item.
Companies House is the foundation, not an optional extra. As the UK’s statutory register, it provides free, publicly accessible, government-verified data — company status, registered officers, Persons of Significant Control, and filing history — and its evidentiary weight has increased following the Economic Crime and Corporate Transparency Act 2023, which expanded Companies House’s identity-verification and data-quality enforcement powers. For entity-resolution purposes, this makes a Companies House record one of the strongest low-cost corroborating nodes available to a UK enterprise, precisely because it is independently maintained and increasingly subject to active verification rather than passive self-registration.
A fully completed, accurate LinkedIn company page functions as a second corroborating node — not because LinkedIn performs identity verification comparable to a government registry, but because it is a distinct, independently indexed platform that, when consistent with Companies House and on-site schema, adds to the coherent repetition of facts that reduces an engine’s resolution ambiguity. Industry-specific registries — professional body directories, trade association listings, sector accreditation databases — serve the same function and are explicitly recognised as valid qualifying references for Wikidata’s structural-need criterion, meaning they can also serve double duty: corroborating the entity directly, and later supporting a Wikidata submission once sufficient independent references accumulate.
The governing principle across all of these is that volume does not substitute for independence. A company with fifty mentions across its own press releases, syndicated content, and paid placements has generated volume without corroboration, and an entity-resolution system is specifically designed to discount exactly this pattern. Three genuinely independent, structurally authoritative sources — Companies House, one verified industry registry, one accurate LinkedIn page — will outperform a much larger volume of self-published or syndicated mentions, because independence, not quantity, is what the resolution mechanism is actually weighing.
Governance: Entity Resolution Is Not a Deployment, It’s a Standing Process
The organisations that get entity resolution wrong most often are not the ones who never built an external record — they’re the ones who built it once, correctly, and then let it decay. A Wikidata item is not a static asset. A name change, a change of registered office, a new managing director, a change in corporate structure following an acquisition — each of these creates a window during which Companies House, LinkedIn, the Wikidata item, and the on-site schema can diverge, and every day that divergence persists is a day the entity-resolution confidence for that organisation is actively degraded rather than merely static.
A defensible governance process therefore needs three standing components. First, an update cadence tied to corporate events rather than a calendar — any filing at Companies House that changes officers, registered name, or SIC code should trigger a review of the Wikidata item, the LinkedIn page, and the `sameAs` targets in the site’s JSON-LD, in that order, since Companies House is now the fastest-moving and most authoritative of the three. Second, conflict monitoring — periodically querying the Wikidata item’s revision history and cross-checking core facts (legal name, founding year, headquarters, parent/subsidiary relationships) against the live Companies House record and the on-site schema, specifically looking for the kind of small, silent divergence that erodes resolution confidence without triggering any obvious alarm. Third, active interrogation — querying ChatGPT, Gemini and Perplexity directly with questions a prospective buyer might plausibly ask (“who is [entity], what does it do, who owns it”) and treating any misattribution, omission, or conflation with a similarly-named entity as a defect to be corrected at the structured-data layer, not a curiosity to be noted and forgotten.
This is meaningfully different from the traditional SEO governance model, where a schema audit every six or twelve months was considered adequate. Entity resolution failures compound silently — a stale Wikidata item doesn’t produce an error message, it produces a slowly declining probability of correct attribution that is only visible if someone is actually testing for it.
The Takeaway
On-site structured data establishes what an organisation claims to be. External entity resolution — Wikidata, Companies House, verified industry registries, and a consistent LinkedIn record — establishes what can be independently corroborated, and it is corroboration, not declaration, that generative engines are architecturally built to prefer. A `sameAs` array is only as strong as the authority and internal consistency of what it points to; pointed at unverifiable or contradictory sources, it is markup without mechanism.
The practical work this demands is not exotic, but it is disciplined and ongoing: build or correct the Wikidata item using genuinely independent references rather than self-published ones, treat Companies House as the authoritative source of truth for legal identity and structure, keep every corroborating profile in lock-step whenever a corporate fact changes, and periodically interrogate the major engines directly to confirm the entity graph you’ve built is the one they’re actually retrieving. Organisations that treat this as infrastructure — owned, monitored, and maintained with the same rigour as uptime or security headers — will be resolved correctly and cited with confidence. Those that treat it as a one-off schema deployment will keep discovering, usually from a client who mentions it in passing, that the AI engine confidently described someone else.
Frequently asked questions
What is entity resolution and why does it matter for AI visibility?
Entity resolution is the process by which AI engines decide whether the organisation described on a website is the same entity they already hold a verified record of, based on corroboration across independent structured sources rather than self-declared schema.
Why isn’t correctly implemented Organization schema enough to be trusted by AI engines?
On-site JSON-LD only states what an organisation claims about itself; generative engines built on retrieval-augmented generation prioritise independent, structured corroboration from sources like Wikidata, Companies House and LinkedIn over self-published claims.
What does the sameAs schema property actually accomplish?
sameAs functions as a merge instruction telling a knowledge graph that a URL, Wikidata item, LinkedIn page and Companies House record all describe one real-world entity, but its strength depends entirely on the authority of the linked sources, not the mere presence of the property.
Can a mid-sized UK company qualify for a Wikidata entry without Wikipedia-level notability?
Yes — Wikidata accepts items supported by reliable public references such as government registries including Companies House, which is a lower and explicitly defined threshold than Wikipedia notability.
