Knowledge Graph
The Knowledge Graph is a database of entities and the relations between them, from which Google draws facts about companies, people, places and concepts. It feeds the knowledge panels next to search results and serves as a reference layer that claims are checked against. A brand with a record has a say in how machines talk about it. A brand without one depends on whatever the machine assembles on its own.
In short
| What it is | A database of entities and relations, the fact reference layer for Google and connected services |
| What feeds it | Wikipedia and Wikidata, structured data on websites, verified profiles, licensed databases |
| What users see | The knowledge panel next to results, answers to factual questions about a company |
| Why AI cares | Search-grounded AI answers (Google, Bing) lean on graphs like this. A missing record means assembly from fragments |
How the graph is built and where the facts come from
Sources and their weight
The graph is not filled by hand. Google's systems collect statements from sources they can verify, and keep the origin and a confidence level for each. A statement backed by a citation in Wikidata weighs more than a statement from a single company website. A statement that agrees across three independent sources weighs more than one from a single source. Sources also differ in what kind of fact the graph takes from them.
| Wikidata and Wikipedia | Identity, entity type, relations to other entities, description, basic facts with citations |
| Structured data on the website | Name, logo, address, founding date, sameAs profiles, products and people |
| Verified profiles | Google Business Profile, social networks, YouTube: contact, address, opening hours, images |
| Registries and licensed databases | Legal form, registered address, company ID, date of incorporation, management |
| Authoritative sites and media | Independent confirmation of facts, ties to the industry, clients and people |
Merging into one node
Every entity in the graph has its own identifier. When the system encounters a new statement, it first checks whether the name matches an existing node: it compares the name, type, address, sameAs links and relations to other entities. On a match, the statement attaches to the node. When no node exists, a new one forms only if more than one source confirms it. When sources contradict each other, for example on the founding year, the graph either takes the value from the source with higher confidence or leaves the field empty. A company without contradictions therefore is established in the graph sooner than a company whose site, profiles and registry disagree.
What comes out of the graph
The visible output is the knowledge panel. It is assembled from the node's fields: name, short description (usually from Wikipedia), logo, headquarters, founding date, founder, website and social profiles. Google shows it only when it is confident enough about the entity and when the query targets that entity. A company can claim the panel after verification and suggest corrections; fields are not edited directly; every suggestion is checked against the other sources. The same reference layer serves other Google systems, including generated answers that are checked against it.
Worked example: a B2B company states the founding year 2012 in its Organization schema, the business registry says 2012, LinkedIn says 2013 and no Wikidata record exists. The graph holds two values from three sources, two of them matching. The panel either does not appear or shows 2012 with lower confidence. After the LinkedIn profile is corrected, three sources out of three agree, and adding a Wikidata record citing the registry brings a fourth source with higher weight.
How a company gets in
There is no sign-up form. The graph fills from public sources Google trusts: Wikidata and Wikipedia, structured data on the company site, verified profiles and consistent mentions across credible websites. Practically that means three steps: consistent Organization schema on your own site, a Wikidata record with references to verifiable sources, and matching facts in directories and profiles.
From our own practice
While building our own AI visibility we started with what a machine can see right away: the consistency of the site and the profiles. We unified the canonical numbers (EUR 52M+ in managed spend, 30+ markets, 9 reviews rated 5.0 on Clutch) and deployed Organization schema including sameAs links to Clutch, LinkedIn and other profiles. The Wikidata record is a later step on the roadmap, not the first: until an entity has consistent sources, neither the graph nor a knowledge panel has anything to build from.
Common mistakes
- Wanting Wikipedia as the first step. An article without independent sources gets deleted and the attempt does harm. Notability has to be built first.
- Inconsistent facts. The graph fills from several sources. When they contradict each other, the record either never forms or forms wrong.
- Treating the knowledge panel as an ad. It is not paid space but the consequence of trustworthy data.
Related terms
See also entity SEO, structured data, E-E-A-T and GEO.
Frequently asked questions
How do I know whether we are in the graph?
Search for the brand name: the knowledge panel next to the results is the most visible sign of a record. A Wikidata record can be checked directly at wikidata.org.
How long does it take to get in?
Months. The graph updates slowly and requires confirmation from several sources, which is why you start with data consistency, not with the entry itself.
Is a Wikidata record enough?
No, but it is the most accessible of the graph's public sources. It has to be backed by consistent data everywhere else.
How we can help
We build brand machine identity as part of AI visibility. Details on the AI visibility agency page.