Blog · Third-party sources

Wikipedia, and the brand facts engines inherit

Published 8 October 2026 · Updated 12 October 2026 · 8 min read

Wikipedia, and the brand facts engines inherit
Photograph: Marian Florinel Condruz / unsplash

The short answer: Wikipedia and its sister database Wikidata are a common source of the background facts an answer engine repeats about a company: founding year, headquarters, category, parent company, what the product is. You cannot write that entry yourself, and for most companies there is no entry to write. What you can do is make the facts correct where they already exist, and make the independent coverage that the rules actually accept.

That split, between the part you can edit and the part you can only earn, is the whole of this topic. Everything else is detail.

Two databases, not one

Most people picture a Wikipedia article. The machine-readable half matters more.

Wikidata is the structured companion: every statement about an entity lives as a typed property on an item with a Q number, queryable over an API and over SPARQL. The statistics page reported 123,612,534 items when we read it on 12 October 2026. Items exist for plenty of subjects that have no article at all, because they arrive from library catalogues, company registers, identifier authorities and other imports. So a company with no Wikipedia presence can still have a Wikidata item carrying a founding date, an industry code and a headquarters city that nobody at the company has ever seen.

The two halves do different jobs for a machine reader. The article gives prose a model can paraphrase. The item gives typed values that resolve an entity to one thing rather than three similarly named things. If your brand name collides with a town, a protein or a 1970s band, the item is what breaks the tie. That is the same machinery described in Knowledge graphs, Wikidata and brand facts, seen from the Wikimedia side.

Why most brands never get an article

The notability rule for companies is stricter than the general one, and it is strict in a way that defeats the standard public relations playbook.

Each source offered as evidence has to clear four tests at once: significant coverage that treats the company directly and in depth, full independence from the subject, reliability, and secondary rather than primary status. Press releases fail. Sponsored placements fail. Funding announcements, hiring news and quarterly numbers are listed as routine and fail. Articles written largely from a company's own materials fail on independence of content. Attention only from local outlets is explicitly not enough.

Read that list against a typical startup's coverage file and the usual result is zero qualifying sources, despite two hundred links in a spreadsheet. This is not a conspiracy against you. It is a rule built to keep an encyclopaedia from becoming a directory, and it has the side effect of making the entry un-buyable.

The consequence for visibility work is simple. Chasing an article is the wrong first move for nearly everyone. The right first move is to be described accurately by the sources engines already read, which is the argument in The third-party sources AI engines keep citing. Those same sources, incidentally, are the raw material a Wikipedia editor would need if an article ever became plausible.

The inheritance problem: a fact can outlive its correction

Here is the mechanism that surprises people.

An engine can learn a fact two ways. It can retrieve a page at answer time, or it can reproduce something absorbed during training. English Wikipedia is named as a training dataset in published model documentation, including the dataset table in Language Models are Few-Shot Learners (Brown et al., 2020), so a description from an old snapshot can end up in what a model says without searching. Correct the article today and retrieval-mode answers can improve within a crawl cycle. The no-retrieval answer, the one you get when a user asks a casual question and the system decides the query needs no search, may keep returning the old description for as long as that model is deployed.

That is why we run the audit prompt set with retrieval on and with retrieval off. The gap between the two is how we tell an inherited description from a fetched one. It is an indication drawn from answers, not a measurement of anything inside the model. A wide gap means a stale prior. A narrow gap with both sides wrong means the live sources are wrong too, which is a different and more fixable problem.

Machine reading of these projects is not a small side effect, either. The Wikimedia Foundation reported on 1 April 2025 that automated clients accounted for around 35 percent of pageviews but at least 65 percent of the most expensive traffic, because crawlers sweep obscure pages in bulk instead of clustering on popular ones. On the Wikimedia projects, by that account, the long tail of entity pages is read more thoroughly by machines than by people. We have not seen comparable figures published for other reference sites, so we do not extend the ratio beyond Wikimedia.

Four failure modes worth checking

A Wikidata item nobody owns. Values imported years ago from a registry: an old legal name, a city you left, an industry label that puts you in the wrong category. Nothing on your site contradicts it loudly enough to win.

A redirect instead of an article. Your brand points at a parent company or a category page, so the facts available to inherit are the parent's. Acquisitions are a common cause.

Name collision. Two entities share a label and the engine merges them. The tell is an answer that is half right, with one sentence that belongs to somebody else.

A category article doing the describing. With no entry of your own, the nearest Wikimedia description of you is the general article about your product category, plus whichever vendor list a retrieval step turns up. Your absence from those lists is then load-bearing, which is the subject of The listicles you are missing from.

The checks, in about twenty minutes

Start machine-side. The Wikidata search API answers without a key:

`` curl -s "https://www.wikidata.org/w/api.php?action=wbsearchentities&search=YOUR+BRAND&language=en&format=json" ``

If a Q number comes back, open the item and read every statement as though a stranger wrote it, because one did. Then fetch the item itself and look at the claims, not the rendered page, since the claims are what gets consumed.

Next, search English Wikipedia for your brand and note what you land on: an article, a redirect, a line inside a category page, or nothing. Each of those four outcomes is a different problem with a different fix.

Then read your own published facts against what you just found. Founding year, legal entity name, headquarters city, category wording, parent. Any field that disagrees between your about page, your schema markup, your directory profiles and the Wikimedia record is a field where the sources an engine might read disagree with each other. The self-check walks through the rest of that pass.

Last, decide who owns the answer when those four disagree. A single internal record that every surface copies from is worth more than any individual correction, which is the case made in Governance: one source of truth for brand facts.

If you do edit, declare it

The Wikimedia terms of use, section 4, require anyone compensated for a contribution to disclose employer, client and affiliation. Wikipedia's conflict of interest guideline goes further: it says COI editors are strongly discouraged from editing affected articles directly and can propose changes on article talk pages instead.

Treat this as a compliance line, not a style preference. An undisclosed edit that gets noticed produces a reverted change, a flagged account and sometimes a talk page thread that is itself indexable and quotable. The careful version is slower and does not blow up.

The adjacent fix you fully control is your own markup. Google's organization structured data documentation defines sameAs as the URL of a page on another website with additional information about your organisation, and lists name, legalName, url, logo and foundingDate among its recommended properties. That page also states there are no required properties, so treat the list as a menu rather than a checklist. Pointing those at the profiles that already exist costs an afternoon and asks nobody's permission.

Honest limits

This post does not establish that correcting a Wikidata item improves how engines describe you. We have not run a controlled test, and entity work usually lands alongside new coverage, so we cannot separate the two: treat it as a condition worth meeting rather than a proven lever. The retrieval-on and retrieval-off comparison we rely on is a sample of about 45 prompts across five engines on the day an audit runs, not a census of what any model holds, and we have not counted how often a stale description turns up, only noticed that it keeps turning up. We also do not know how long an outdated description survives in a deployed model, and nothing here tells you which sources a given engine read for a given answer, because that is not visible from outside.

FAQ

Can I pay to get a Wikipedia article? No service can commit to one, because the decision sits with volunteer editors applying the notability rules. Paid contribution also has to be disclosed under the terms of use. The durable route is independent coverage with depth, which an editor can then use.

My company has no article. Does a Wikidata item still help? Often, yes. Items exist independently of articles and carry typed values that help an engine resolve which entity you are. It is cheap to check and worth checking first.

How do I know whether an engine is using a stale fact or a live page? Ask the same question twice, once where the system searches and once where it answers from memory. Different answers suggest an inherited description rather than a fetched one.

Our Wikipedia article is wrong. What is the fastest honest fix? Post the correction on the article talk page with an independent source for each changed value, and disclose any connection you have. Fix the same fact on your own site and markup at the same time, so the next editor finds agreement rather than contradiction.

Sources

Related reading