Knowledge Graph

What a knowledge graph actually stores

A knowledge graph stores things, not strings. Where a relational database gives you a row with columns fixed in advance, a graph stores a subject, a relation and an object: a company, operates, a set of media. Repeat that pattern a few billion times and the relations become first-class data, queryable exactly like the entities they connect. That inversion is the whole point. In a relational schema, the relationship between two records hides inside a join key and nowhere in the data model itself. In a graph, the relationship is the data.

Three pieces make the structure work. Entities are the nodes: a person, a brand, a city, a molecule, a football club. Relations are the typed edges between them, and their direction matters, since founded_by and founded are not the same statement. Attributes hang off the nodes as literal values: a date, a postal code, a revenue figure. Add an ontology on top, which declares what types exist and which relations are legal between which types, and you get formal semantics: a machine can now infer that if a node is a subsidiary of a company headquartered in France, the parent is a French organization, without anyone writing that fact down.

That inference capability is what separates a knowledge graph from a large table of triples. It is also why the term gets abused. A CSV of products loaded into Neo4j is a graph database, not a knowledge graph. Without a schema that carries meaning and without provenance on each statement, you have adjacency lists with good marketing. The distinction matters the moment two sources disagree about the same fact, which in practice is constantly.

How Google's graph works in 2026

Scale first, because it frames everything else. As of May 2024, Google's Knowledge Graph held more than 1.6 trillion facts about 54 billion entities, per Search Engine Land's coverage. The interesting number is not the size but the trajectory: Search Engine Land reports growth of only +2.79% in entity count between May 2024 and May 2025, followed by two updates on June 13 and June 20, 2025 that removed billions of entities. Person entities took the heaviest hit, continuing a cleanup of weakly supported profiles that started around 2023.

Read that as a policy change, not a maintenance job. For a decade the graph accumulated. Now it prunes. An entity that exists on the strength of one directory listing and a self-declared schema block is a candidate for deletion, and deletion is much harder to recover from than absence, because the system has already evaluated the evidence and found it thin. Consistency across independent sources, stable sameAs profiles and structured data that agrees with the visible page are no longer optimisations, they are the conditions of existence.

Under the hood, Google's graph is RDF-shaped in spirit: subject, predicate, object, with globally unique identifiers so that two systems can talk about the same thing without ambiguity. That is why schema.org markup, which serializes to RDFa or JSON-LD, is the practical interface between your site and the graph. Adoption is broad but shallow: Wikipedia's schema.org article notes that over 45 million domains had implemented schema markup by 2024, which Amra & Elma's 2025 statistics put at roughly 12.4% of registered domains. Broad enough that markup alone differentiates nothing, shallow enough that correct, entity-linked markup still does.

The other 2026 shift is where graph data surfaces. AI Overviews rolled out broadly in the United States in May 2024 and Google's AI Mode is now available in 200+ countries and territories. Overviews frequently appear above or alongside knowledge panels on entity queries, synthesizing from multiple sources rather than reproducing one panel. Meanwhile W3Era's 2026 guide cites SparkToro's 2024 study finding 58.5% of US and 59.7% of EU searches end with zero clicks. The graph decides what gets said about you in a surface that increasingly does not send traffic at all.

Knowledge graphs, LLMs and RAG

The lazy take is that language models made knowledge graphs obsolete: the model already knows the facts, so why maintain a structure? That gets it backwards. A language model stores statistical associations between tokens with no notion of provenance and no way to answer «where did this come from». A graph stores discrete, attributable statements. The pairing exists precisely because each covers the other's failure mode: the graph grounds the model, the model reads the messy text the graph cannot parse.

In a retrieval pipeline this shows up as the difference between vector search and graph traversal. Vector search finds passages that resemble the question, which is excellent for fuzzy semantic matching and useless for multi-hop reasoning. Ask which suppliers of a company's suppliers operate in a sanctioned country and no embedding will assemble that chain, while a graph query answers it in one traversal. Hybrid retrieval, sometimes marketed as RAG 2.0, runs both: embeddings to find candidate context, graph edges to constrain and verify it. Hallucination rates drop not because the model got smarter but because the retrieval step now returns statements with identifiers attached.

For search specifically, this rewires what visibility means. ClickRank's 2026 guide describes AI Overviews using Knowledge Graph data as a trusted foundation for their answers, and the citation data backs the shift: BlckAlpaca's 2026 analysis compiles an Ahrefs 2026 finding that roughly 38% of AI Overview citations now come from the organic top 10, down from about 76%, alongside BrightEdge data showing rank overlap between AI Overviews and classic results rising from 32.3% to 54.5% over sixteen months. Being cited is no longer downstream of ranking. The same analysis reports Semrush's 2026 Ghost Citations study finding around 62% of AI citations are unlinked, which is the uncomfortable part: you can win the mention and receive nothing measurable in analytics.

Building a graph you control

Most SEO teams never need to run a graph database, and building one to «do entity SEO» is a category error. The cases where it earns its keep are narrower: large catalogues where product, attribute and use-case relations drive internal linking; publishers mapping their own coverage to find where a cluster of related pages has a hole in the middle; agencies modelling client, site, media and placement relations across hundreds of campaigns. In each case the value comes from queries you could not write against a relational schema without six joins and a headache.

The build sequence is unglamorous. Define the questions before the schema, because a graph designed without a query workload becomes an expensive diagram. Write the ontology next, keeping the type list short: most useful graphs run on a dozen node types, not eighty. Extraction and reconciliation is where the real work sits, since the same organization arrives as five different strings across your sources and entity resolution, not modelling, will consume the budget. Only then does loading matter, and by then the choice between an RDF triple store and a property graph like Neo4j resolves itself: RDF when you need shared vocabularies, federation across external datasets and SPARQL, property graphs when the priority is traversal speed and rich attributes on the edges themselves.

One rule survives every implementation we have seen: keep provenance on every statement. A triple without a source is unfalsifiable, and the first time two feeds disagree you will need to know which one to trust. Google does exactly this, which is why corroboration across independent sources determines what stays in its graph and what disappeared last June.

Where this lands in a netlinking operation

There is no submission endpoint for the Knowledge Graph. Anyone selling entity insertion is selling schema markup plus a Wikidata edit plus optimism. What actually moves the needle is corroboration: the same set of facts about your organization, stated consistently, on sources that Google already trusts and that are not yours. Structured data declares the claim. Third-party editorial confirms it. Only the second one carries weight, because the first is testimony from the defendant.

This is why editorial placement outperforms link acquisition framed as volume. A paragraph in a real article that names your brand alongside its sector, its founders and its market gives the graph co-occurrence signals in natural language, which is what its extraction pipeline was built to read. An exact-match anchor pointing at a homepage from a page about nothing in particular gives it almost nothing on the entity side. When we plan placements across the French editorial media we operate in-house, the brief matters more than the metrics of the host: the article has to sit in the semantic neighbourhood where the brand belongs, which is the same discipline that builds recognised authority on a subject rather than a scattered link profile. That is also the practical argument for commissioning an article on a media that already covers your field instead of buying a slot wherever one is free.

Search Engine Land's 2025 review of core updates observed that pages recovering after March 2024 tended to show clear topical structure and explicit entity relationships rather than keyword-targeted pages, which lines up with what we see when auditing sites that survived. The operational translation is a linking plan built around entities and their relations, on-site and off-site, rather than around a keyword list. Reviewing the catalogue of media you can browse without an account against the thematic neighbourhood you need, rather than against a raw authority score, is the version of that plan that survives contact with a real budget.

What we see go wrong

The most common failure is treating schema.org markup as the deliverable. A site ships perfect Organization and Person JSON-LD, waits, and nothing happens, because markup is a claim and the graph runs on corroboration. Fix the sameAs profiles, get two or three independent sources stating the same founding date and the same legal name, then the markup starts doing work.

Second failure: chasing a knowledge panel as a KPI. Panels have become more accessible for companies, and DigitalApplied's 2026 guide notes that corporate panels became significantly more available from early 2025, after a period dominated by individuals. The same source points out Google increasingly generates panel descriptions from multiple sources rather than defaulting to a Wikipedia opening line. So the panel can appear and say something you did not choose. ReputationX's 2026 guide reports internal client data showing branded search CTR gains of 30 to 40% on properly maintained panels, which is worth having, but it is a brand-query effect and not a discovery channel.

Third: inconsistency that nobody owns. Legal name on the invoices, trading name on the site, a third variant on LinkedIn, an old address in three directories. Every mismatch is a reason for the graph to keep two weak entities instead of one strong one, and that is precisely the profile the June 2025 cleanup deleted.

Last, the budget mistake. Entity work is cheap in tooling and expensive in editorial, and teams routinely invert that ratio: a five-figure graph platform, no budget for the articles that would corroborate anything. If you are arbitrating between the two, our own published rates per media give a usable reference point for what corroboration actually costs before you commit to infrastructure.