The Google Knowledge Graph is Google’s internal knowledge base of entities and the relationships between them, used to interpret queries, assemble knowledge panels, and supply facts to features across Search and other Google products. Google announced it on 16 May 2012 in a post titled “Introducing the Knowledge Graph: things, not strings”, describing a shift from matching query strings against document text to identifying the things a query refers to. It is a private graph: there is no dump, no public SPARQL endpoint, and no documented path for a publisher to write to it.

Things, not strings

The phrase in the 2012 announcement names a specific technical change. A string-based index treats “taj mahal” as a sequence of characters to match against pages. An entity-based system resolves it to one of several distinct things, the monument in Agra, the musician, or a restaurant of that name, and can then return facts about the resolved thing and disambiguate among the candidates. Google’s launch post described the graph as containing more than 500 million objects and more than 3.5 billion facts about and relationships between them. In a May 2020 post reintroducing the graph, Google described more than 500 billion facts about 5 billion entities.

The underlying structure is the one described in what is a knowledge graph: nodes for entities, typed edges for relationships, and a schema constraining which edges are meaningful for which types. The distinctive property of Google’s implementation is not the data model but the resolution layer, the machinery that maps a piece of text or a query to the right node. That process is covered generally in entity linking, NER and extraction.

From Metaweb and Freebase to the Knowledge Graph

The Knowledge Graph did not start from nothing. In July 2010 Google acquired Metaweb, the company behind Freebase, a collaboratively edited graph of structured facts with an open license and a public API. Freebase supplied both a large seed dataset and the identifier scheme Google still uses.

The timeline that follows matters because it explains why practitioners keep encountering Freebase artifacts in current systems:

• 2010. Google acquires Metaweb and with it Freebase.
• May 2012. The Knowledge Graph launches publicly, initially in English for US users, with panels appearing beside search results.
• December 2014. Google announces that Freebase will be retired and that it will work with the Wikidata community to move the data across.
• 2015. Freebase goes read-only, and the Freebase-to-Wikidata transfer work proceeds, including a tool for proposing Freebase-derived statements to Wikidata editors for review.
• 2016. The Freebase site and API are shut down. Final data dumps remain downloadable, but nothing is maintained.

The migration toward Wikidata was not a wholesale import. Wikidata requires sourced statements and applies its own notability rules, so Freebase content was proposed to editors rather than loaded directly, and a substantial part of it was never accepted. The practical result is that Wikidata inherited some Freebase content and became the leading open reference base, while Google kept its own graph and its own identifiers.

Entity identifiers: MIDs and KG IDs

Every entity in Google’s graph carries an opaque identifier. Most that appear publicly take the form /m/0dl567, a Freebase machine ID, usually shortened to MID. Newer entities appear with a /g/ prefix instead, such as /g/11b6t0kqhx. Both are opaque strings: nothing in them encodes the type or name of the entity, and they are stable across name changes, which is the whole point of an identifier.

In the Knowledge Graph Search API, these appear as JSON-LD @id values with a kg: prefix, so the API returns kg:/m/0dl567 where the underlying identifier is /m/0dl567. The prefix belongs to the API response format rather than to the identifier itself.

MIDs also surface in other Google products. They appear in Google Trends topic URLs for entities, and the Natural Language API has exposed MID values for entities it recognizes. Practitioners use these appearances to confirm that Google holds an entity for a given thing.

A MID is not something a site can request, mint or assert. A publisher can only assert its own identifiers, using @id for a stable in-site URI and sameAs for links out to identifiers other systems already hold. That is the linked data approach applied to search, and it is covered tactically at sameAs schema.

Where the data comes from

Google describes its knowledge sources in general terms rather than as a ranked list. The categories it has documented include publicly available sources such as Wikipedia and Wikidata, data licensed from providers in specific domains such as sports, film and music, information supplied directly by verified entity representatives through the knowledge panel claiming process, business data submitted through Google Business Profile, and facts extracted from the open web.

Two points are worth stating carefully, because both are frequently overstated. Google does document that Wikipedia and other public sources feed the graph. Google does not document any threshold, weighting or trigger, so claims that a Wikipedia article or a Wikidata item causes an entity to enter the graph are practitioner inference rather than documented behavior. The observable pattern is correlation: entities with strong independent coverage tend to be represented, and the mechanism behind that is not published.

What the public Search API does and does not expose

The only official read interface is the Knowledge Graph Search API at https://kgsearch.googleapis.com/v1/entities:search. It requires an API key, accepts a text query or an entity ID, and returns a JSON-LD document whose itemListElement array holds members carrying a result object and a resultScore. The result objects expose a small, fixed set of fields: @id, name, @type, description, detailedDescription, image and url.

curl -s "https://kgsearch.googleapis.com/v1/entities:search?query=Marie+Curie&types=Person&limit=3&indent=true&key=YOUR_API_KEY"

That is the entire surface. The API returns no relationships between entities, no property values beyond those fields, and no way to traverse from one entity to its neighbors. Google positions it as a lookup against entities in the Knowledge Graph, created in part as a successor path for developers who had used the Freebase API. It queries a subset of the graph, and it is not the pipeline that generates knowledge panels: an entity can be absent from API results while a panel exists, and a resultScore is a relevance value for that query, not a measure of the entity’s standing in Search. Treating the score as an entity strength metric is a common error, and Google does not document it as one. The Knowledge Graph Search API page works through the request parameters and response handling in detail.

Knowledge Graph vs knowledge panel

The two terms are routinely swapped and refer to different things. The Knowledge Graph is the data. A knowledge panel is one user interface built on top of it, shown when Search judges a query to be about an entity it holds with enough confidence and enough material to display. An entity can exist in the graph and never produce a panel, which is why “getting into the Knowledge Graph” and “getting a knowledge panel” are different objectives with different evidence available for each.

For developers

For anything requiring graph structure, the Google API is the wrong tool and the Wikidata Query Service is usually the right one, because it exposes the full graph over SPARQL with properties, qualifiers and references intact. A common pipeline uses Google’s API only for one job it does well: resolving a free-text name to a candidate entity with a description that a human or a model can check, then carrying that resolution forward against an open base where the actual facts live.

Note the identifier mismatch. Google MIDs and Wikidata Q-IDs are separate schemes. Wikidata does hold a Freebase ID property for many items, which supports reconciliation for older entities, but there is no complete crosswalk and newer /g/ identifiers are largely absent from open data. Build for partial matching rather than assuming a join key.

For SEOs

Three things are within a publisher’s control, and the rest is not.

Emit a clear entity on the site. One Organization or Person node, one stable @id, the same name and description everywhere, published as JSON-LD on a page that reads as the entity’s home rather than as a marketing landing page.

Link identifiers outward. Point sameAs at profiles and records that genuinely describe the same entity: an official Wikipedia article if one exists, a Wikidata item, verified social profiles, an ORCID for a researcher, an official register entry for a company.

Get corroborated. Independent sources repeating the same facts is the pattern that distinguishes represented entities from unrepresented ones. Press coverage, directory entries, conference bios, industry databases and publications a site does not own all serve this purpose.

What is outside control: which entities Google holds, what its descriptions say, whether a panel appears, and how long any change takes to propagate. No amount of markup obliges Google to create an entity. The broader program is described at entity SEO, and the specific sequence at how to get a knowledge panel.

Common misconceptions

“Adding schema markup puts a business in the Knowledge Graph.” Markup makes claims legible and consistent. Google decides what to hold. Markup is a necessary input in practice and not a sufficient one.

“A Wikidata item guarantees inclusion.” Wikidata is one documented source among several. Creating an item for a subject that fails Wikidata notability guidelines results in deletion, which helps nothing.

“resultScore shows how strong an entity is.” It is a per-query relevance value in an API response. Comparing scores across different queries measures nothing meaningful.

“The Knowledge Graph is Google’s index.” They are separate systems. The index holds documents; the graph holds entities. Search uses both, and a page can rank without any entity association at all.

Related pages

• Google Knowledge Graph Search API
• Google knowledge panel
• Wikidata
• What is a knowledge graph?
• What is an entity?
• Entity SEO

FAQ

What is the Google Knowledge Graph?

The Google Knowledge Graph is Google’s private database of entities such as people, places, organizations and creative works, together with the relationships and facts connecting them. Google announced it in May 2012 and uses it to interpret queries, disambiguate names, populate knowledge panels, and supply facts to features across Search. It is not publicly downloadable or editable.

How do I find a Google Knowledge Graph ID?

Query the Knowledge Graph Search API at kgsearch.googleapis.com with an entity name and an API key; each result carries an @id such as kg:/m/0dl567, where /m/0dl567 is the machine ID. MIDs also appear in Google Trends topic URLs and in some other Google product interfaces. You can’t request a specific identifier for an entity.

Is Freebase still part of the Google Knowledge Graph?

Freebase supplied the original seed data and the /m/ machine ID scheme that Google still uses, so its legacy is visible. Freebase itself was announced for retirement in December 2014, went read-only in 2015, and its site and API were shut down in 2016, with data proposed to Wikidata editors for review rather than imported wholesale.

Can a website add itself to the Google Knowledge Graph?

No. No submission form and no write API. What a site can do is publish consistent structured data with a stable @id, link out with sameAs to identifiers such as a Wikidata item or verified profiles, and build independent third-party coverage that repeats the same facts. Google decides what enters its graph.

Sources and further reading

• Google. Introducing the Knowledge Graph: things, not strings (16 May 2012). https://blog.google/products/search/introducing-knowledge-graph-things-not/
• Google. A reintroduction to Google’s Knowledge Graph (May 2020). https://blog.google/products/search/about-knowledge-graph-and-knowledge-panels/
• Google Developers. Knowledge Graph Search API. https://developers.google.com/knowledge-graph
• Google. Knowledge panel help center. https://support.google.com/knowledgepanel
• Wikidata. WikiProject Freebase. https://www.wikidata.org/wiki/Wikidata:WikiProject_Freebase
• Google Search Central. Introduction to structured data markup. https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data