Understanding Entities and Knowledge Graphs

By: Reputation.blog Editorial
Published: October 31, 2026
Last reviewed: October 31, 2026

Direct answer

An entity is a distinct thing that a system can identify and describe: a person, company, place, product, work, event, or concept. A knowledge graph is a structured collection of entities, facts about them, and relationships between them. The entity—not the word used to name it—is the unit of identity.

That distinction matters because names are ambiguous. “Mercury” can refer to a planet, a chemical element, a Roman god, a singer, or a former car brand. A keyword system sees the same string in each case. An entity-based system tries to determine which Mercury is meant, attach the relevant facts to that separate identity, and avoid mixing them with facts about the others.

For businesses, entity understanding is not a matter of repeating a name more often. It is how machines use names, identifiers, locations, websites, people, brands, products, and other evidence to decide which records describe the same business—and which describe different ones.

How to read the claims in this guide

Entity systems combine published standards, documented platform behavior, and proprietary machinery. This guide keeps those categories separate:

• Documented means a platform or standards body states it in its own documentation.
• Established technical concept means the term has a recognized meaning in data management, information retrieval, or natural language processing.
• Inference means a reasonable interpretation of public evidence, not a platform-confirmed mechanism.
• Unknown means the relevant internal decision rules have not been published.

Public documentation can establish that Google uses entity information in Search without revealing its thresholds, weights, or complete reconciliation process.

1. An entity is not a keyword

A string is a sequence of characters: “Apple,” “Jordan,” “Northstar Dental,” or “Mercury.” A keyword is a string used in a query or document. An entity is the real-world or conceptual referent that the string may identify in context.

Several related terms should not be collapsed:

• A mention is an occurrence of a name or description in text, an image caption, a database, or another source.
• A referent is the thing that mention is about.
• An entity record is a system’s representation of that referent.
• An identifier is a value used to distinguish the record, ideally persistently.

“Jordan” in a sports article may mention a person; in a travel article it may mention a country; in a product article it may be part of a shoe name. A system that merely counts the string learns little. A system that links each mention to the right referent can answer different questions about each one.

The reverse problem also occurs. One entity can have many strings: a legal name, trading name, abbreviation, former name, translated name, misspellings, and informal references. Treating every variant as a new thing fragments the record. Entity work is the discipline of resolving both problems: one name may point to many entities, and one entity may be represented by many names.

Google captured this distinction when it introduced its Knowledge Graph in 2012 under the phrase “things, not strings”. The launch article used “Taj Mahal” to show how one query could refer to a monument, a musician, or another entity, and explained that Google was modeling real-world entities and their relationships rather than only matching words.

2. What is inside an entity record?

Implementations differ, but an entity record commonly contains some combination of:

Component	Function	Business example
Identifier	Distinguishes this record from others	A knowledge-base ID, company number, LEI, DUNS number, or product GTIN
Type	States what kind of thing it is	Organization, LocalBusiness, Person, Product, Place
Names and aliases	Records preferred and alternative labels	Legal name, trading name, former name, abbreviation
Attributes	Describes properties of the entity	Founding date, headquarters, address, website, industry
Relationships	Connects it to other entities	Founder, parent organization, brand, product, location, employer
Source evidence	Shows where assertions came from	Official site, registry, reputable publication, user-contributed database
Time qualifiers	Records when a fact applied	A chief executive’s start and end dates; a former address

Not every system stores or exposes all these fields. Provenance (where a statement came from) and confidence (how likely a match or fact is correct) matter in many data-integration systems, but they are not universal features of every search engine.

An identifier deserves special emphasis. A name is evidence, not proof of identity. Two companies may share a name in different jurisdictions, while one company may change its name without becoming a new legal entity. Persistent identifiers reduce that ambiguity. Wikidata uses Q numbers for items; Google’s Knowledge Graph API documentation uses machine IDs (MIDs) and can return other identifiers, including a Wikidata QID, for an entity. Those examples demonstrate the general principle: the identifier carries identity, while the label can change or be translated.

3. What is a knowledge graph?

A knowledge graph represents facts as connected statements. At its simplest:

Entity — relationship — entity or value

For example:

• Northstar Dental — is a — LocalBusiness
• Northstar Dental — located in — Austin
• Dr. Lee — founder of — Northstar Dental
• Northstar Dental — offers — Orthodontic Service
• Northstar Holdings — parent organization of — Northstar Dental

The entities and values are nodes. The relationships are edges. A collection of such statements allows a system to traverse from a business to its founder, services, locations, parent company, and products without treating each web page as an isolated bag of words.

The W3C’s RDF model expresses statements as triples: subject, predicate, and object. RDF graphs are directed and labeled: “Northstar Dental” is the subject, “founder” is the predicate, and “Dr. Lee” is the object. The W3C RDF Primer explains this graph structure and the role of identifiers in making machine-processable statements. Not every knowledge graph uses RDF internally, but the subject–predicate–object model is a useful, standards-based way to understand the concept.

A knowledge graph also needs a vocabulary—called a schema or ontology—for types and relationships, such as Organization, Person, and Product. Without shared definitions, the meaning of each connection may be unclear.

A knowledge graph is not simply:

• a list of keywords;
• a website’s internal-link structure;
• a knowledge panel;
• a collection of pages about a topic; or
• a guarantee that every statement in it is correct.

A knowledge panel is a presentation layer. Google states that panels are automatically generated information boxes for entities in its Knowledge Graph and that their information comes from various sources across the web. The graph is the underlying system of facts and entities; the panel is one possible display of selected information from it.

4. How machines identify, disambiguate, and reconcile entities

Different technical tasks are often marketed under the single word “entities.” They solve different parts of the problem.

Step 1: Collect candidate information

A system may draw on web pages, structured data, public records, licensed databases, reference works, maps, catalogs, images, and user contributions. Google’s 2020 explanation says its Knowledge Graph uses web materials and open-source and licensed databases, draws from hundreds of sources, and commonly cites—but is not limited to—Wikipedia. That statement is documented for Google and should not be generalized to every AI product.

Step 2: Recognize mentions

Named entity recognition (NER) finds spans of text that appear to mention entities and assigns a broad type, such as person, organization, or location. Recognition alone does not establish identity. Detecting “Washington” as a location or person does not say which Washington it is.

Step 3: Generate candidates

For each mention or record, the system retrieves plausible existing entities. A mention of “Apple” near “iPhone” produces a different candidate set from “Apple” near “orchard.” Candidate generation narrows the search before a final decision is made.

Step 4: Disambiguate and link

Entity linking, also called named entity disambiguation, maps a mention to a specific entry in a knowledge base—or returns NIL when no suitable entry exists. Context, entity type, nearby entities, prior usage, relationships, and source information can all be relevant signals in established entity-linking methods. A page about “Michael Jordan” and “Chicago Bulls” should resolve differently from a page about “Michael Jordan” and a university statistics department.

Step 5: Resolve duplicate records

Entity resolution—also called record linkage or deduplication—decides whether records from one or more datasets refer to the same real-world entity. A peer-reviewed review in Science Advances defines the task as integrating noisy databases and removing duplicate entities, often when no unique identifier is available. Unlike entity linking, which starts with a mention in context, entity resolution commonly compares structured records and clusters the records judged to describe the same thing.

Step 6: Reconcile identities

Entity reconciliation is closely related: local records are matched to an existing reference graph or identifier system. Google Cloud describes entity reconciliation as clustering and deduplication in which matching can use fuzzy text, common relationships, entity types, and attributes rather than only a managed key. Its Enterprise Knowledge Graph documentation says reconciled clusters receive a stable machine ID. That is documented behavior for Google Cloud’s enterprise product, not a disclosure of the exact process used by Google Search.

Step 7: Validate, merge, split, and update

Entity decisions must be reversible. A responsible system needs ways to merge false splits, split false merges, preserve former names and dated facts, replace superseded addresses or officers, retain references for contested statements, and distinguish a rebrand from a new organization.

Two error types pull in opposite directions. A false merge combines different entities and contaminates both records. A false split divides one entity into fragments and weakens each fragment. Strong identifiers make both errors less likely, but they do not eliminate mistakes—identifiers can be missing, mistyped, reused incorrectly, or attached to the wrong record.

5. What is publicly documented about Google’s Knowledge Graph—and what is not

Google’s original announcement described three purposes: find the right thing when a query is ambiguous, summarize relevant facts, and support exploration through relationships. Its later guide to knowledge panels says panels draw on that system and are automatically generated.

Documented:

• Google defines the Knowledge Graph as a system that understands facts and information about entities from web materials and open-source and licensed databases.
• In 2020, Google said it contained more than 500 billion facts about five billion entities. Those are historical figures from that article, not a current count.
• Knowledge panels are automatically generated, vary by topic, and can include a title, summary, images, key facts, and links to official sites and social profiles.
• Subjects or official representatives can claim many panels and suggest changes; general users can submit feedback.
• Google’s Knowledge Graph Search API documentation returns entity data in Schema.org-compatible JSON-LD and uses machine IDs. An example response includes identifiers such as a Google Knowledge Graph MID and a Wikidata QID.

Not publicly documented:

• the complete list of sources and their weights;
• the threshold at which a business becomes a distinct Search entity;
• the exact matching features and confidence cutoff for merging records;
• how each Knowledge Graph fact affects ranking, AI answers, or citations;
• a universal timetable for corrections or new entity creation; and
• whether any particular private or small-business record exists in every Google system that uses entity data.

It is therefore accurate to say that clear, consistent, well-identified information can reduce ambiguity. It is inference, not documented fact, to claim that a specific tactic will create a Knowledge Graph entity, trigger a panel, or cause an AI system to cite a business.

Platform boundaries matter too. The public evidence above concerns Google. It does not establish that ChatGPT, Gemini, Perplexity, Copilot, or other AI systems use Google’s Knowledge Graph, share the same entity records, or apply identical selection rules. For a broader comparison of retrieval systems, see How AI Search Works.

6. How businesses, brands, products, and people become entities

“Become an entity” can be misleading. A company exists legally and commercially whether or not a database represents it. The narrower technical question is whether a particular system has created a stable record for it and connected incoming evidence to that record.

There is no universal application form for “entity status.” A record becomes more distinguishable when independent, authoritative sources use compatible names, identifiers, locations, dates, and relationships. Each platform decides what to ingest and model; Google has not published a qualification checklist.

The entity boundary problem

Before asking whether a business is recognized, define which business object is meant:

Object	Why it may need a separate record
Legal organization	The registered company that owns assets, employs people, and enters contracts
Brand	A public-facing identity that may differ from the legal owner and may cover several products
Location or branch	A physical place with its own address, hours, staff, and reviews
Product family	A named line or platform that persists across versions
Product model or edition	A distinguishable version with its own specifications and identifiers
Individual item	One physical unit, potentially identified by a serial number
Person	A founder, executive, author, clinician, artist, or other individual
Service	An offering that may be provided by an organization or location

Collapsing these objects creates false facts. A parent company did not necessarily found a brand it later acquired. A product model is not the same as every physical unit sold. A branch address is not automatically the legal headquarters. A founder is a separate person entity even when closely associated with the company.

Consider a hypothetical group called Northstar. “Northstar Health, Inc.” is the legal parent. “Northstar Dental” is a consumer brand. Its Austin clinic is a location. “Northstar Align” is a service brand. Dr. Lee is a person who founded the original practice but now works for the parent. A good graph preserves all five identities and their dated relationships. A poor graph merges them into one vague company record and then attaches the clinic’s address, the founder’s biography, and the service’s claims to the wrong subject.

People are represented through similar evidence: names, works, employers, publications, performances, identifiers, and relationships. That does not mean every person with a web page has a stable Google Knowledge Graph entity or can demand inclusion.

7. Structured data: a vocabulary for making claims explicit

Structured data does not create an entity by itself. It lets a publisher state, in a machine-readable vocabulary, “this page describes this thing, of this type, with these properties and relationships.”

Schema.org is a shared vocabulary of types and properties. Its Organization type covers organizations such as companies, schools, NGOs, and clubs. More specific types—including LocalBusiness, Corporation, OnlineStore, and many industry types—inherit or extend the model. The choice of type should reflect the object being described, not whichever type appears most powerful.

What Organization markup can express

A careful Organization description may include:

• name and, when different, legalName;
• alternateName for genuine alternative names;
• url for the official website;
• logo and description;
• foundingDate, address, and contactPoint;
• sameAs links to pages that unambiguously identify the same organization;
• dedicated identifiers such as leiCode, duns, or iso6523Code when they genuinely apply;
• brand, subOrganization, and parentOrganization for relationships;
• founder, employee, or member where accurate and appropriate; and
• a stable @id so other structured-data nodes on the site can refer to the same described organization.

A simplified example is:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Company",
  "legalName": "Example Company Ltd",
  "url": "https://example.com/",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q000000"
  ],
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "LEI",
    "value": "EXAMPLE-IDENTIFIER"
  }
}

The placeholder values would have to be replaced with verified facts. In particular, a Wikidata URL belongs in sameAs only when the item is actually about the same organization. Schema.org defines sameAs as the URL of a reference page that “unambiguously indicates the item’s identity,” such as its Wikipedia page, Wikidata entry, or official website.

What Google documents about Organization markup

Google instructs publishers to place Organization information on the home page or a single page about the organization, rather than repeating it unnecessarily on every page. It recommends the most specific Schema.org subtype and says there are no required properties; publishers should add the relevant ones.

Most importantly for this guide, Google’s Organization documentation says the markup can help Google understand administrative details and disambiguate the organization in Search results. Google specifically notes that identifiers such as iso6523Code and industry codes such as naics can be used behind the scenes for disambiguation, while properties such as logo can influence what is displayed.

That is a bounded claim. Google does not say that valid Organization markup guarantees:

• a Knowledge Graph record;
• a knowledge panel;
• a particular logo or description;
• a ranking improvement; or
• citation by an AI answer system.

Structured data is best understood as high-clarity evidence supplied by the entity’s own website. It can remove avoidable ambiguity, but it is self-asserted evidence. Independent records, registries, publications, and other sources may corroborate or contradict it. A false statement does not become reliable merely because it is encoded in JSON-LD.

8. Wikidata: a public knowledge graph and reconciliation hub

Wikidata is a free, collaborative, multilingual knowledge base published under the Creative Commons Public Domain Dedication 1.0. It is not Google’s Knowledge Graph, and it is not a directory in which every business is entitled to an entry.

A Wikidata item represents a topic, concept, or object and has a persistent Q identifier—Douglas Adams is Q42. Items have labels, descriptions, and aliases. Their facts are expressed as statements, each consisting of a property (identified by a P number) and a value. Statements can carry qualifiers and references. Properties can also record external identifiers that connect the item to other databases, while sitelinks connect it to corresponding pages in Wikimedia projects. Wikidata’s own introduction describes this model and emphasizes that Wikidata records sources and connections to other databases, not just isolated statements.

Wikidata matters because it provides persistent identity (a QID remains stable when labels differ or change), explicit relationships (statements connect a company to headquarters, founders, parent organization, industry, products, and identifiers), and reconciliation value (aliases, identifiers, and sitelinks gathered in one public place).

Those functions do not prove that Google directly copies a Wikidata item into Search or that any AI platform must use it. Google says Wikipedia is a commonly cited Knowledge Graph source, while its own API example can expose a Wikidata QID as one identifier attached to an entity. The safe conclusion is interoperability and potential evidentiary value—not a guaranteed pipeline.

Wikidata also has inclusion rules. An item must satisfy its notability policy, for example by having a valid Wikimedia sitelink, representing a clearly identifiable entity that can be described using serious and publicly available references, or fulfilling a structural need. Promotional item creation can be reverted or deleted. A business should first search for an existing item, correct it with referenced facts if necessary, and consider a new item only when the subject genuinely meets the policy.

9. Why consistent company information matters mechanically

“Be consistent” is often presented as branding advice. In entity resolution, it is a matching problem.

Suppose the same company appears as:

• Official site: Northstar Dental Group, 400 Congress Ave., Austin; founded 2016.
• Directory A: North Star Dental, 400 Congress Avenue; phone number for the Dallas office.
• Directory B: Northstar Dental PLLC, old address; founder listed as current owner.
• Social profile: Northstar Austin; link to an abandoned domain.
• Press article: Northstar Health, the parent company, described as though it were the clinic.

A person may reconcile those records instantly. An automated system sees conflicting names, locations, relationships, and contact points—conflicts that can lower matching confidence, split evidence among candidates, or attach a fact to the parent instead of the clinic.

Consistency helps because it increases redundant, compatible evidence:

• the same legal and public names are used for the same objects;
• name changes are identified as changes, not silently substituted;
• each location keeps its own address, phone, hours, and parent relationship;
• URLs resolve to the current official domain;
• founding dates and leadership dates agree;
• official profiles link back to the same website; and
• identifiers are copied exactly and attached to the correct legal entity.

Consistency does not mean forcing every object to use one name. A legal name and a brand name can both be correct. The mechanical requirement is to state which object each name belongs to and how the objects relate. legalName, alternateName, brand, parentOrganization, and subOrganization are useful precisely because sameness is not the only relationship.

Nor does consistency compel a platform to merge records. It removes contradictions that make a correct merge harder to justify. That distinction keeps the work honest: businesses control the clarity of their own evidence, not Google’s internal decision. Our guide to building AI visibility places that evidence work within a wider source and corroboration strategy.

10. Topical authority and entities are related, but they are not the same thing

In SEO practice, topical authority usually means that a site demonstrates substantial, coherent knowledge of a subject through the breadth, depth, quality, and organization of its content. It is a practitioner concept, not a Schema.org type, a Wikidata property, or a publicly documented Google “entity score.”

The relationship is indirect:

• Content is about entities, concepts, and relationships.
• Focused work describes a subject with consistent terminology and distinctions.
• Authors, publishers, organizations, products, and cited sources are themselves entities.
• Clear coverage helps readers—and potentially machines—understand a page’s subject and a publisher’s expertise.

Google’s public guidance does not reduce this to publishing a fixed number of pages around a keyword. Its helpful-content documentation asks whether content provides a substantial or comprehensive description of its topic, demonstrates expertise, and gives readers reason to trust the source. Those are quality questions, not instructions to manufacture an entity graph with thin pages.

A useful mental model is:

Entity clarity answers “which thing is this?” Topical depth answers “how well is this subject understood and explained?”

A business can have a clean Organization record and almost no subject-matter content. A publisher can produce excellent explainers while its own company identity remains fragmented across names and domains. The two projects reinforce each other when the publisher’s identity is clear and its content consistently treats the relevant concepts as distinct entities, but neither is a substitute for the other.

11. Business implications: an entity-clarity audit

Businesses can audit the public evidence from which entity records are built, even though they cannot inspect or edit every graph.

1. Draw the entity map first

List the legal organization, brands, locations, people, products, services, former names, and parent or subsidiary relationships. Decide which are truly distinct. Most downstream errors begin when this map is never made.

2. Establish one canonical fact sheet

For each distinct object, record the verified name, type, website, identifiers, address or headquarters, founding or launch date, description, and relationships. Mark facts as company-asserted, independently documented, or disputed. Update the sheet when a fact changes rather than editing isolated profiles from memory.

3. Align the official website

Use one stable Organization node in structured data, with a consistent @id, and make the visible About, Contact, location, leadership, and product pages agree with it. Google recommends a single home or organization page for the Organization description. Connect products and people to the organization with accurate relationship properties instead of repeating disconnected names.

4. Reconcile major public records

Check the records a customer or researcher is most likely to encounter: business registrations where public, industry directories, map and business profiles, major social profiles, app or product catalogs, press coverage, Wikipedia where an article legitimately exists, and Wikidata where an item legitimately exists. Correct object-level errors—especially a headquarters confused with a branch, a founder confused with a current executive, or a parent confused with a brand.

5. Use identifiers carefully

Record legal-entity identifiers separately from product and location identifiers. An LEI identifies a legal entity; a GTIN identifies a trade item; an ISBN identifies a book edition or related publication product; a local place identifier identifies a place record. Putting one object’s identifier on another object is worse than omitting it.

6. Preserve history

When a company rebrands, moves, is acquired, or changes leadership, keep the chronology visible. Use former names and dates where the source supports them. Deleting every trace of the old identity can make legitimate historical sources look like records of a different company.

7. Monitor for the two failure modes

Periodically search for signs of a false split—multiple profiles or records that plainly describe the same business but contain fragments of its facts—and a false merge—a record that combines the business with another company’s address, products, people, or history. Correct the sources you control and use the relevant platform’s feedback or claim process for records you do not.

These steps improve public information; they do not guarantee a knowledge panel, citation, ranking, or inclusion in any graph. Reputation.blog’s Knowledge Center evaluates entity work by evidence rather than promises.

Common misconceptions

“If we add Organization schema, Google will create our entity.”

No. Google documents that the markup can help it understand and disambiguate an organization. It does not promise entity creation or a panel.

“A knowledge panel is the knowledge graph.”

No. The graph is an underlying collection of entity facts and relationships. A panel is an automatically generated display for some entities and queries.

“A Wikidata item guarantees AI citations.”

No. Wikidata supplies a public, structured identity record. No public documentation establishes that every AI system uses it, trusts it equally, or will cite the business because an item exists.

“Entity optimization means repeating the brand name.”

Repetition increases mentions, not necessarily clarity. Types, identifiers, relationships, dates, and source agreement distinguish one entity from another.

“All information about a company should be merged into one profile.”

No. Legal entities, brands, locations, products, and people often need separate records with explicit relationships. Indiscriminate merging is the error entity resolution is meant to prevent.

“Topical authority is a score stored on our company entity.”

There is no public evidence for a universal topical-authority score attached to a business entity. The phrase describes an observed or practitioner-inferred pattern about subject coverage and trust; it should not be treated as a documented field in Google’s Knowledge Graph.

FAQ

Is a business automatically an entity because it has a website?

It is an entity in the ordinary sense—an identifiable organization—but that does not establish that Google or another platform has a stable entity record for it. A website is evidence and an official source, not proof of representation in a particular knowledge graph.

What is the difference between entity resolution and entity linking?

Entity linking maps a mention in context to an existing knowledge-base entry, or decides that none fits. Entity resolution compares records or descriptions and decides which ones refer to the same entity, often clustering duplicates across datasets.

Should every business create a Wikidata item?

No. Search for an existing item first. Create or edit an item only when the subject meets Wikidata’s notability policy and the statements can be supported by serious, publicly available references. Do not use Wikidata as a promotional directory.

Which identifiers matter most for a company?

Use identifiers that genuinely apply and can be verified—such as a company-registration number, LEI, DUNS number, or ISO 6523 identifier. Never invent one or copy one from a similarly named business.

Can structured data correct wrong information elsewhere?

It provides a clear official statement, but does not overwrite independent databases or force Google to prefer it. Correct records you control and use platform feedback processes where available.

Does a knowledge panel prove that all its facts are correct?

No. Google says inaccuracies can occur and provides feedback mechanisms. Panels are automatically generated from changing sources, so even a genuine panel should be checked like any other compiled record.

The practical takeaway

Entities are how machine systems move from text matching toward identity; knowledge graphs store those identities as connected facts. Structured data, identifiers, Wikidata, and consistent records answer a narrow but consequential question: which thing does this information describe?

The strongest entity strategy is disciplined identity management: define the objects correctly, state their relationships accurately, attach the right identifiers, preserve their history, and make the public evidence agree. Platforms will make their own decisions about representation and use, but clear evidence leaves them less ambiguity to resolve.

References

1. Google. Introducing the Knowledge Graph: Things, Not Strings. May 16, 2012.
2. Google. Google’s Knowledge Graph and Knowledge Panels. May 20, 2020.
3. Google Search Help. About Knowledge Panels.
4. Google Search Central. Organization Structured Data.
5. Google Search Central. Creating Helpful, Reliable, People-First Content.
6. Google Cloud. Enterprise Knowledge Graph Overview.
7. Google Cloud. Google Knowledge Graph Search API.
8. Schema.org. Organization.
9. Wikidata. Wikidata: Introduction.
10. W3C. RDF Primer.
11. Binette, Olivier, and Rebecca C. Steorts. “(Almost) All of Entity Resolution.” Science Advances 8(12), 2022.
12. Wikidata. Notability Policy.