Knowledge Graph

The structured web of entities that AI uses to understand the world.

// The Concept

A knowledge graph is a structured database of entities — people, places, organizations, concepts, products — and the relationships between them. Unlike a traditional database that stores records in flat tables, a knowledge graph represents information as a web of interconnected nodes and edges. Each node is an entity. Each edge is a relationship. The result is a machine-readable map of how things in the world relate to each other.

Google's Knowledge Graph, launched in 2012, contains billions of entities and tens of billions of relationships. When you search "Guerin Green" and see a panel with bio, company affiliation, and related entities — that is the Knowledge Graph surfacing structured entity data. It is not built from keywords. It is not built from page titles. It is built from structured entity data, cross-references between authoritative sources, and verified relationships that Google's systems have reconciled from across the web.

The concept extends far beyond Google. Wikidata is an open knowledge graph with over 100 million items. Facebook's Social Graph maps relationships between people. Amazon's product graph connects items, categories, and purchase patterns. Every major AI company maintains knowledge graphs that their models use for entity resolution, fact verification, and grounding. When an LLM needs to answer "Who is the CEO of Tesla?" it does not search for that string in its training data. It queries an entity graph where "Elon Musk" is connected to "Tesla" via a "CEO" relationship edge.

The shift from keyword search to entity search is fundamentally a shift from string matching to graph traversal. Traditional search matched your query string against document strings. Entity search resolves your query to a node in the knowledge graph, then traverses relationships to find the answer. This is why entity presence in the graph — not just keyword presence on a page — is the foundation of AI-era visibility.

// How It Works

Knowledge graphs are built on triples: subject-predicate-object statements that encode relationships between entities. Each triple is a single fact expressed in a form that machines can store, query, and reason over. The entire graph is composed of millions or billions of these triples, and the power comes from how they connect.

// Knowledge Graph triple structure // Subject → Predicate → Object "Guerin Green"worksFor"Novel Cognition" "Novel Cognition"offers"Hidden State Drift" "Guerin Green"jobTitle"AI Strategy Consultant" "Guerin Green"sameAs"novcog.com/#guerin-green" // Entity resolution via graph traversal: query("Who runs Novel Cognition?") → resolve "Novel Cognition" → entity node Q7834291traverse edge: hasFounder | hasLeaderreturn "Guerin Green" // entity node Q1192834 // Disambiguation via context edges: query("Apple") + context: "CEO"Apple Inc. // Q312 + context: "fruit"Apple // Q89 + context: "music"Apple Music // Q20056882 // Sources that feed the graph: Wikipedia/Wikidata // primary open knowledge base Schema.org markup // structured data on web pages Authoritative DBs // government records, patents, etc. Cross-platform refs // LinkedIn, GitHub, official sites

Sources feed the graph from multiple directions. Wikipedia and Wikidata provide the canonical open knowledge base that most AI systems reference. Schema.org markup on websites provides structured declarations — when you add Person schema with @id, you are proposing a node and its properties to the graph. Authoritative databases (government records, patent filings, academic registries) provide verified facts. Cross-platform references (LinkedIn profiles, GitHub accounts, official company pages) provide corroborating signals.

The graph resolves ambiguity through context edges. "Apple" alone is ambiguous. But "Apple" connected to "CEO" via a query context edge resolves unambiguously to Apple Inc. This is why schema markup with @id is so powerful — it explicitly declares which entity you are, bypassing the ambiguity resolution step entirely. You are not waiting for Google to figure out who you are. You are telling Google who you are, in a format it can directly ingest into its graph.

Entity reconciliation is the process by which the graph merges signals from multiple sources into a single canonical entity node. When "Guerin Green" appears on novcog.com with Person schema, on agenticseo.agency with sameAs references, on hiddenstatedrift.com with consistent credentials, and on 14 other domains with matching entity data — Google's reconciliation systems recognize these as the same entity and merge them into a single, stronger node. Each consistent cross-reference is evidence. Each inconsistency is noise.

// Why It Matters for Search

The Knowledge Graph is the backbone of entity SEO. Knowledge Panels, rich results, AI Overviews, and LLM citations all draw from it. If your entity is not in the graph — or is poorly represented with sparse, inconsistent data — you are invisible to entity-aware systems. And increasingly, all systems are entity-aware.

Google's AI Overviews do not generate answers from keyword-matched pages. They resolve the query to entities, traverse the knowledge graph for relationships and facts, retrieve supporting documents, and generate a response grounded in the graph. If your entity has a strong graph presence — consistent properties across multiple authoritative sources, verified relationships, schema-declared credentials — you are part of the answer substrate. If your entity is absent from the graph, you are not in the running, regardless of how many keywords your pages rank for.

LLM citation behavior follows the same pattern. When Perplexity.ai answers a query about your topic, it retrieves and cites sources. The retrieval step uses entity-aware indexing — sources with strong entity signals (schema markup, Knowledge Graph presence, consistent cross-domain references) rank higher in the retrieval index. The citation step prefers sources that the model can verify against its internal knowledge graph. If your entity is already known to the model from training data (because it appeared consistently across many authoritative pages), your content gets preferential citation treatment.

Schema markup with consistent @id cross-references is how you propose your entity graph to Google and AI systems. The DAN (Distributed Authority Network) strategy accelerates graph inclusion by presenting the same entity consistently across multiple authoritative domains. Each domain is an additional source of evidence. Each consistent @id reference is an additional reconciliation signal. The graph gets stronger with every confirming node.

// In Practice

Build your entity graph deliberately, not accidentally. Start with Person schema on every page where you are the author or subject. Use @id consistently — the same identifier on every domain. "https://novcog.com/#guerin-green" on your homepage, your blog posts, your client sites, your community properties. Every instance of that @id is a vote for the same entity node in the graph.

Add Organization schema linking person to company. "Guerin Green" worksFor "Novel Cognition." "Novel Cognition" offers "Hidden State Drift." These are not just SEO markup — they are triple declarations that map directly to knowledge graph structure. The closer your schema mirrors actual graph triple format, the more efficiently it can be ingested.

Build your sameAs portfolio: LinkedIn, GitHub, Google Scholar, Skool community, authoritative industry profiles. Each sameAs URL is an edge in the graph connecting your entity node to a verified external presence. Google uses these to cross-validate your identity. The more authoritative platforms that confirm your entity, the higher confidence the graph assigns to your node.

Implement cross-domain @id references across your DAN properties. When the same entity appears on 14+ domains with identical @id, identical credentials, identical sameAs references — the reconciliation algorithm has overwhelming evidence for a single, authoritative entity node. This is the technical mechanism behind the DAN strategy: each domain in the network is a source of confirming triples for the same entity graph.

If you have sufficient notability, create a Wikidata entry. Wikidata is the most directly consumed knowledge graph by AI systems. A Wikidata entry with proper claims (instance of: human, occupation: consultant, employer: Novel Cognition) feeds directly into Google's Knowledge Graph and is referenced by most LLMs during training and inference. It is the single highest-leverage entity action available.

How do I get a Knowledge Panel?

There is no application process. Google builds Knowledge Panels from evidence — consistent entity data across authoritative sources. The key inputs are: schema markup with @id on your owned properties, a Wikipedia or Wikidata entry if you meet notability criteria, a Google Business Profile for organizations, verified social profiles linked via sameAs, and cross-platform consistency in your name, title, and affiliations. The DAN approach accelerates this by multiplying the number of authoritative sources that confirm your entity data. Most entities that get Knowledge Panels have strong signals from at least 5-10 independent authoritative sources.

Is the Knowledge Graph the same as a knowledge base?

A knowledge base stores information — it could be a database, a wiki, a collection of documents, or a structured repository. A knowledge graph specifically structures that information as entity-relationship triples (subject-predicate-object) that can be traversed and queried. The graph structure enables capabilities that flat storage cannot: entity disambiguation (resolving "Apple" to the right entity based on context edges), relationship inference (if A worksFor B and B isLocatedIn C, then A is associated with C), and connected retrieval (find all entities within 2 relationship hops of a given node). Knowledge bases store facts. Knowledge graphs connect them.

Go deeper with practitioners

Join the Burstiness & Perplexity community for entity strategy discussions and implementation support.

Join the Community