Google Knowledge Graph: How Entities Connect in Search

The Google Knowledge Graph is a massive semantic database that organizes real-world entities, attributes, and relationships to deliver direct answers in search results. Instead of treating queries as sequences of characters, the Knowledge Graph maps queries to distinct people, places, and objects. This graph structure powers search features, answers factual questions, and improves semantic search relevance.

What Is the Google Knowledge Graph?

Search engines originally operated by matching text characters on web pages against words typed into search bars. If a user entered “Leonardo da Vinci,” the indexer searched for web pages that repeated those specific letters. The engine could not distinguish between Leonardo da Vinci the Renaissance polymath, Leonardo DiCaprio the actor, or a local Italian restaurant named da Vinci.

In May 2012, Google introduced the Knowledge Graph to solve this problem. Google described the shift as moving from “strings to things.” A string is an arbitrary sequence of characters, whereas a thing is an entity. An entity is a unique, distinguishable person, place, organization, creative work, or concept in the physical world.

The Knowledge Graph is not a traditional flat index. It is a graph database. In computer science, a graph consists of nodes connected by edges:

• Nodes: Represent distinct entities, such as “Albert Einstein” or “Theory of Relativity.”
• Edges: Represent directed relationships between entities, such as “developedBy” or “bornIn.”
• Attributes: Key-value data points attached to nodes, such as birth dates, official websites, or geographical coordinates.

By structuring information as a connected network, Google can answer factual questions directly on search results pages. When a user asks “How tall is the Eiffel Tower?” Google does not need to rank ten web pages. It queries the Knowledge Graph node for the Eiffel Tower, inspects the height property, and returns “330 meters” in an instant answer box.

Today, the Knowledge Graph contains hundreds of billions of facts covering billions of entities. It forms the backbone of Google Search, Google Assistant, voice queries, and semantic query parsing.

The Origin: Freebase, Metaweb, and “Things, Not Strings”

The foundation of the Google Knowledge Graph began outside Google. In 2005, a technology company named Metaweb began building an open, shared database of world knowledge called Freebase. Freebase aimed to structure human knowledge using collaborative editing, similar to Wikipedia, but stored as machine-readable graph data.

Google acquired Metaweb in July 2010. At the time of acquisition, Freebase contained roughly 12 million entities. Google engineers used Freebase as the core scaffolding for what became the Knowledge Graph. They merged Freebase records with other trusted structured databases:

• Wikipedia: Article text, categories, and reference links.
• Wikidata: Structured community data and shared entity identifiers.
• CIA World Factbook: Geographic, economic, and demographic data on sovereign nations.
• Library of Congress: Authoritative records on books, authors, and historical figures.

In May 2012, Amit Singhal, then Senior Vice President of Search at Google, announced the launch of the Knowledge Graph. At launch, the graph contained 500 million entities and 3.5 billion relationship facts.

The Evolution of Google Knowledge Repositories:

[2005: Metaweb creates Freebase]
                |
                v
[2010: Google acquires Metaweb]
                |
                v
[2012: Launch of Knowledge Graph (500M entities, 3.5B facts)]
                |
                v
[2014: Knowledge Vault project fuses extracted web text with graph data]
                |
                v
[2016: Freebase retired; data transitioned to Wikidata and internal KG]
                |
                v
[Present: Over 800 billion facts across 5 billion+ entities]

Google eventually decommissioned Freebase in 2016, migrating its open data to the Wikimedia Foundation’s Wikidata project. However, the internal Knowledge Graph continued to grow independently, ingesting live web data and proprietary extraction pipelines.

Graph Architecture: Nodes, Edges, and Semantic Triples

To understand how the Knowledge Graph works, you must understand graph data modeling. Traditional relational databases use rows and columns inside rigid tables. When data models require complex relationships between millions of disparate categories, relational databases become slow and difficult to scale.

Graph databases solve this by storing data as networks of connected points. The atomic unit of storage in the Knowledge Graph is the semantic triple. A semantic triple follows the standard Resource Description Framework (RDF) model of Subject, Predicate, and Object:

Standard Semantic Triple Structure:

[Subject Node] --------(Predicate Edge)--------> [Object Node]

Consider how the Knowledge Graph stores the biography of author George Orwell. Each factual statement translates into a directed edge between distinct nodes:

Knowledge Graph Triple Representation:

Triple 1:
[Subject: George Orwell] ----(hasProfession)----> [Object: Novelist]

Triple 2:
[Subject: George Orwell] ----(authored)---------> [Object: 1984]

Triple 3:
[Subject: 1984] ---------(publishedIn)------> [Object: 1949]

Triple 4:
[Subject: George Orwell] ----(bornIn)-----------> [Object: Motihari]

Triple 5:
[Subject: Motihari] ---------(locatedIn)--------> [Object: India]

In this model:

• The Subject is an entity node.
• The Predicate is a directed relationship edge defining the nature of the connection.
• The Object can either be another entity node (such as “Motihari”) or a literal value (such as the integer 1949 or a string).

Triples allow Google to execute multi-hop graph traversals. If a user asks “Which books were written by authors born in India?” the search engine does not need an article containing that exact sentence. The engine traverses the graph:

1. Locate all city nodes where the predicate locatedIn points to the entity India.
2. Locate all author nodes where the predicate bornIn points to those cities.
3. Locate all book nodes where the predicate authored links to those authors.
4. Return the list of books, including 1984 and Animal Farm.

This graph traversal capability enables true question answering rather than simple document retrieval. Instead of parsing web page text at query time, the system reads verified relationships directly from the graph.

Entity Identification and Machine IDs (kgmid)

In natural language, names are ambiguous. Two people can share the same name, and one company can operate multiple brand lines. If a search engine relies on text labels, its graph quickly degrades due to naming collisions.

To prevent confusion, the Google Knowledge Graph assigns every entity a permanent, unique machine identifier called a kgmid (Knowledge Graph Machine Identifier). A kgmid is an opaque string that begins with /m/ (for legacy entities imported from Freebase) or /g/ (for modern entities generated directly by Google algorithms).

Sample Knowledge Graph Machine Identifiers:

Entity Name:          Entity Type:      Knowledge Graph Machine ID (kgmid):
-----------------------------------------------------------------------------
Google LLC            Corporation       /m/045c7b
Larry Page            Person            /m/014639
Sergey Brin           Person            /m/0175b_
Alphabet Inc.         Corporation       /g/11b6v_9_z2
Mountain View, CA     City              /m/0r6c0

When search algorithms process a query or index a web page, they map text phrases to these machine IDs. For example, the text mentions “Google,” “Google Inc,” “Google LLC,” and “Google Search” all resolve to /m/045c7b.

Machine identifiers decouple the concept from human language. The entity for Paris, France (/m/05qtj) remains identical whether a user searches in English (“Paris”), Japanese (“パリ”), Russian (“Париж”), or Arabic (“باريس”). The machine ID acts as the universal key connecting alternate names, multilingual labels, and relationship edges.

You can view an entity kgmid directly in Google search URLs. When you click on a Knowledge Panel or use the Google Knowledge Graph Search API, the parameter kgmid appears in the query string, specifying the exact entity requested.

How Entities Enter the Knowledge Graph: Ingestion and Reconciliation

An entity does not appear in the Knowledge Graph by accident. Google uses automated data pipelines to discover, verify, and reconcile entity candidates before adding them to the production graph.

The Entity Ingestion and Reconciliation Pipeline:

+---------------------------------------------------------------+
| 1. Multi-Source Data Collection:                              |
|    - Structured databases (Wikidata, Schema.org markup)       |
|    - Unstructured web crawl text and news publications        |
+---------------------------------------------------------------+
                                |
                                v
+---------------------------------------------------------------+
| 2. Candidate Entity Extraction:                               |
|    - Named Entity Recognition identifies potential entities   |
|    - Attribute triples extracted with probability scores      |
+---------------------------------------------------------------+
                                |
                                v
+---------------------------------------------------------------+
| 3. Entity Reconciliation (Deduplication):                     |
|    - Algorithmic matching against existing graph nodes        |
|    - Machine learning resolves aliases, websites, locations   |
+---------------------------------------------------------------+
                                |
                                v
+---------------------------------------------------------------+
| 4. Verification and Confidence Thresholding:                  |
|    - Cross-reference facts across independent sources         |
|    - Entities passing high confidence threshold entered into  |
|      the production Knowledge Graph                           |
+---------------------------------------------------------------+

The process consists of four primary stages. Each stage refines raw data into verified graph relationships:

1. Multi-Source Ingestion

Google collects data from two distinct environments: structured repositories and unstructured text. Structured sources provide clean, pre-verified triples. Unstructured sources require natural language processing algorithms to extract facts from billions of crawled web pages.

2. Candidate Extraction

When extraction algorithms encounter an entity candidate, they generate a list of candidate properties. For example, an article might mention a new software company, its founder, its headquarters, and its founding date.

3. Entity Reconciliation

The reconciliation engine must determine whether the candidate entity is genuinely new or merely an alternate name for an existing node. If the candidate shares an official website, phone number, executive staff, or address with an existing kgmid, the engine merges the new facts into the existing node. This deduplication process prevents the graph from fragmenting into duplicate records.

4. Confidence Thresholding

Google enforces strict confidence thresholds before publishing facts to search users. If only one personal blog claims that an author was born in 1975, while multiple university archives and publisher catalogs state 1978, the algorithm filters out the unverified claim. Facts must achieve consensus across independent, authoritative sources.

Knowledge Panels: Surface Representation of Graph Entities

A Knowledge Panel is the visual display of a Knowledge Graph entity on Google search engine results pages. On desktop devices, Knowledge Panels typically appear in the right-hand column. On mobile devices, they appear prominently near the top of the search results.

+-------------------------------------------------------+
|  KNOWLEDGE PANEL DISPLAY                              |
+-------------------------------------------------------+
|  [Image Gallery]                                      |
|                                                       |
|  Alan Turing                                          |
|  English Mathematician and Logician                   |
|                                                       |
|  Alan Mathison Turing was an English mathematician,   |
|  computer scientist, logician, and cryptanalyst.      |
|                                                       |
|  Born: June 23, 1912, Maida Vale, London, UK          |
|  Died: June 7, 1954, Wilmslow, United Kingdom         |
|  Education: King's College, Cambridge (1931-1934)     |
|  Known for: Turing machine, Turing test, Cryptanalysis|
|  Awards: Order of the British Empire (1945)           |
|                                                       |
|  Profiles: [Wikipedia] [Wikidata] [IMDb]              |
|                                                       |
|  People also search for:                              |
|  [Ada Lovelace]  [John von Neumann]  [Claude Shannon] |
+-------------------------------------------------------+

Knowledge Panels synthesize data from multiple entity edges into a concise summary card. They allow users to inspect verified entity details without visiting external websites:

• Entity Title and Subtitle: The canonical name and primary category.
• Summary Overview: Typically sourced from Wikipedia, Wikidata, or official corporate descriptions.
• Key Attributes: Structured key-value pairs (dates, locations, measurements).
• Official Profiles: Verified social media accounts and authoritative directories.
• Related Entities (“People also search for”): Sourced by following relationship edges to neighboring graph nodes that share high contextual affinity.

Claiming and Verifying Knowledge Panels

Organizations and individuals can claim ownership of their Knowledge Panels. Google provides a verification process that requires logging into an official digital asset associated with the entity, such as:

• The domain’s Google Search Console account.
• Verified official YouTube channels.
• Verified social profiles linked to the entity.

Once verified, authorized representatives can suggest edits to factual attributes, propose featured image changes, and review entity information directly through the Google Search interface. These user suggestions undergo automated and manual review before appearing live in the Knowledge Panel.

Beyond Hand-Curated Data: The Knowledge Vault and Machine Learning

Relying solely on human-curated databases like Wikipedia or Wikidata imposes strict limits on graph growth. Wikipedia contains millions of articles, but human editors cannot document every local business, book, scientific theorem, or consumer product on Earth.

To scale beyond human curation, Google developed the Knowledge Vault in 2014. The Knowledge Vault is an automated system designed to extract entity triples directly from unstructured web text at web scale.

The table below contrasts the original Knowledge Graph approach with the automated Knowledge Vault system. Examining both models reveals how search engines evolved from manual curation to automated knowledge fusion.

The Knowledge Vault uses machine learning models to calculate a probability score for every extracted fact. The algorithm combines two distinct probabilities:

1. Extraction Probability: How reliably the natural language sentence asserts the fact.
2. Prior Graph Probability: How mathematically probable the fact is given existing graph connections.

For example, if an extraction model reads a sentence claiming that a person born in 1990 graduated from medical school in 1994, the prior graph probability identifies that a four-year-old child cannot earn a medical degree. The system rejects the extracted triple despite the text mention.

Through probabilistic knowledge fusion, Google continually expands its internal entity database with billions of automated facts while filtering out spam and hallucinations. This continuous ingestion ensures that emerging companies, products, and cultural events enter the graph rapidly.

Programmatic Access: Querying the Knowledge Graph Search API

Google provides developers and researchers with programmatic access to its entity repository through the Google Knowledge Graph Search API. This RESTful API allows applications to search for entities using standard HTTP requests and receives responses formatted in JSON-LD. The API uses Schema.org vocabulary specifications and returns the entity name, canonical type, machine ID (@id), and description.

Developers query the service using standard HTTP GET parameters. The following request queries the Knowledge Graph API for the entity “Ada Lovelace”:

GET https://kgsearch.googleapis.com/v1/entities:search?query=Ada+Lovelace&key=YOUR_API_KEY&limit=1&indent=True

The API evaluates the query string and returns matching entity records. The server formats the result as a structured JSON-LD object:

{
  "@context": {
    "@vocab": "https://schema.org/",
    "goog": "http://schema.google.com/",
    "resultScore": "goog:resultScore",
    "kg": "http://g.co/kg"
  },
  "@type": "ItemList",
  "itemListElement": [
    {
      "@type": "EntitySearchResult",
      "result": {
        "@id": "kg:/m/0d3p1",
        "name": "Ada Lovelace",
        "@type": [
          "Person",
          "Thing"
        ],
        "description": "English mathematician",
        "image": {
          "contentUrl": "https://upload.wikimedia.org/wikipedia/commons/ada_lovelace.jpg",
          "url": "https://en.wikipedia.org/wiki/Ada_Lovelace"
        },
        "detailedDescription": {
          "articleBody": "Augusta Ada King, Countess of Lovelace was an English mathematician and writer, chiefly known for her work on Charles Babbage's proposed mechanical general-purpose computer, the Analytical Engine.",
          "url": "https://en.wikipedia.org/wiki/Ada_Lovelace",
          "license": "https://en.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License"
        },
        "url": "http://www.computerhistory.org/babbage/adalovelace/"
      },
      "resultScore": 482.63
    }
  ]
}

Notice the key fields returned in this response:

• @id: Displays the unique machine identifier (kg:/m/0d3p1).
• name: The canonical text label for the entity.
• @type: The Schema.org entity categories (Person, Thing).
• resultScore: A numerical relevance score indicating how strongly this entity matches the query string.

By understanding the Knowledge Graph architecture, web developers can optimize their sites for entity-based search. Deploying clean Schema.org structured data, maintaining consistent entity references across web properties, and establishing clear semantic relationships helps search engines index your brand as a recognized node.

To understand how individual entities are recognized in raw sentences, read our guide on Named Entity Recognition in search. You can also explore semantic search embeddings, examine our breakdown of query processing systems, review how search engines index web content, and study core search algorithms.

Frequently Asked Questions

What is the Google Knowledge Graph?

The Google Knowledge Graph is an entity database that organizes real-world facts, people, places, and organizations. Unlike traditional indexes that match isolated keywords, the Knowledge Graph connects concepts using semantic triples. This graph architecture enables Google to answer factual questions directly and understand topical relevance across search results.

When was the Google Knowledge Graph launched?

Google officially launched the Knowledge Graph on May 16, 2012. The rollout marked Google transition from lexical keyword matching to entity-based semantic search, introducing the design motto “things, not strings.” At launch, the graph contained approximately 500 million entities and 3.5 billion relationship facts.

How does the Knowledge Graph differ from traditional search indexes?

Traditional search indexes use inverted posting lists that map words to web page URLs. In contrast, the Knowledge Graph uses a graph database that maps real-world entities to other entities using relationship edges. This allows algorithms to evaluate facts and answer questions without relying on exact character matches.

What is a Google machine ID (kgmid)?

A Google machine ID, or kgmid, is a permanent alphanumeric identifier assigned to every unique entity in the Knowledge Graph. Prefix codes like /m/ or /g/ ensure that concepts remain unambiguous across different languages, aliases, and regional spellings, acting as a universal primary key for search algorithms.

How does an entity get into the Google Knowledge Graph?

Entities enter the Knowledge Graph when extraction algorithms identify consensus across authoritative sources. Google ingests structured databases like Wikidata, crawls web pages containing Schema.org markup, and extracts factual triples from unstructured text. Once candidate facts pass strict confidence thresholds, the entity is added to the graph.

What is the difference between the Knowledge Graph and a Knowledge Panel?

The Knowledge Graph is the underlying database storing billions of entities, properties, and relationship connections. A Knowledge Panel is the visual user-interface card displayed on search results pages that presents a summarized subset of those graph facts to searchers looking for a specific entity.

Can you edit or claim a Knowledge Graph entity?

You cannot directly edit the Knowledge Graph database itself, but verified representatives can claim the corresponding Knowledge Panel on Google search. Once verified through Google Search Console or official social profiles, representatives can suggest updates to attributes, featured images, and profile links through the search interface.

What is the Google Knowledge Graph Search API?

The Google Knowledge Graph Search API is a public developer interface that allows users to query Google entity database programmatically. It returns entity details, descriptions, machine identifiers, and relevance scores formatted in standard JSON-LD, making it valuable for semantic analysis, entity linking, and data reconciliation projects.

Sources

• Singhal, A. (2012). “Introducing the Knowledge Graph: things, not strings.” Google Official Blog. https://blog.google/products/search/introducing-knowledge-graph-things-not/
• Google Developers. (2024). “Google Knowledge Graph Search API Documentation.” Google Developers. https://developers.google.com/knowledge-graph
• Dong, X., Gabrilovich, E., Heitz, G., Horn, W., Lao, N., Murphy, K., Strohmann, T., Sun, S., & Zhang, W. (2014). “Knowledge Vault: A Web-Scale Approach to Probabilistic Knowledge Fusion.” Proceedings of the 20th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, 601-610. https://research.google/pubs/pub41951/
• Bollacker, K., Evans, C., Paritosh, P., Sturge, T., & Taylor, J. (2008). “Freebase: A Collaboratively Created Graph Database for Structuring Human Knowledge.” Proceedings of the 2008 ACM SIGMOD International Conference on Management of Data, 1247-1250. https://dl.acm.org/doi/10.1145/1376616.1376746
• Vrandečić, D., & Krötzsch, M. (2014). “Wikidata: A Free Collaborative Knowledgebase.” Communications of the ACM, 57(10), 78-85. https://cacm.acm.org/magazines/2014/10/178785-wikidata/fulltext