How I Use Knowledge Graphs on Content Sites

Applying Knowledge graph + SEO for a content site comes down to three working parts: a closed vocabulary of the people, companies, and concepts you cover, an entity tag on every page, and a generated hub page per entity. That trio turns a stream of posts that lose traffic in days into assets that compound for years. And it also builds trust that machines can verify. I run this system on my own projects, from the SEO community graph I publish at SEO Baza and the entity pages here on Fajela to enterprise projects. If you need more prominent public cases, the New York Times has run it at 1.8-million-article scale since before Google existed. This post is the how, step by step, with the mistakes I paid for so you don’t have to.

How the New York Times runs content on an entity graph

The New York Times has tagged every story against a controlled vocabulary since 1851, when library scientists kept it as a paper index. Today the archive holds over 1.8 million articles, more than 1.5 million of them hand-tagged with terms from a closed list of exactly five types: people, organizations, locations, subjects, and creative works. The pipeline, described by the NYT to the IPTC, splits the work in the following way: software suggests tags with relevancy scores, an editor confirms, and a dedicated Taxonomy Team reviews every new-term request daily, writing disambiguation rules so John Adams the composer never merges with John Adams the president.

In his analysis of NYT topic pages, SEO consultant Chris Long counts almost 10,000 of them, all assembled from those tags, and estimates that the Facebook topic page alone brings around 1.1 million visits a month. His numbers are outside estimates, not the NYT’s own reporting, but they show what a hub built from tags can carry: the article dies, the hub keeps the traffic. Everything below is that same machine, scaled down to a site you and I can run.

Why the graph work builds trust

Trust is the actual product of all this tagging, and we know because Google published the research. Xin Luna Dong’s team built Knowledge Vault, a web-scale base of facts extracted from pages and weighted by probability, and on top of it Knowledge-Based Trust, a way to score a source by the factual accuracy of its content instead of its links. Dong walks through the mechanics in her Stanford seminar: facts get extracted from your pages and checked against the consensus of the knowledge base. Sources whose statements verify earn a trust signal backlinks cannot buy, and in Google’s own experiments some heavily linked gossip sites scored terribly on factual accuracy while small, precise sites scored near the top.

How does it work in our AI era? Dong’s later work at Meta, the Head-to-Tail benchmark, measured how much factual knowledge language models actually hold: ChatGPT answered 29.4 percent of questions about famous (head) entities correctly, 21.9 percent for mid-popularity ones, and 9.5 percent for tail entities. Almost every expert, tool, and company a niche site covers lives in that tail, which means the models do not know those facts and have to retrieve them from somewhere. A site with a clean entity layer is built to be the somewhere. Most of the 52 experts in the Fajela knowledge graph are exactly such tail entities: an answer engine cannot recall them from training, so the structured Fajela profile is what it retrieves.

Retrieval alone does not close the gap either. Dong’s team went on to build CRAG, a benchmark where question-answering systems get simulated web search and knowledge graph APIs to work with, and even then straightforward RAG setups answered fewer than 44 percent of questions accurately, while the most advanced industry systems reached only about 63 percent without hallucination. That is why answer engines lean on knowledge graphs alongside search results instead of choosing between them, and why the structured facts a site publishes feed both channels at once.

The implication for a content project

A machine can only verify what it can extract, so unambiguous names, stable aliases, markup, and shared identifiers are what make your site checkable at all. Every step below either makes your facts easier to extract or harder to get wrong. I can watch this play out in Fajela’s own reporting: I track the share of AI answers my projects get by joining Gemini grounding data with Search Console queries, and the entity-clean pages are the ones that keep surfacing.

Step 1: Build the vocabulary your knowledge graph stands on

Start the vocabulary from your best content: list every entity worth its own page, with a type, a canonical name, a two-sentence description, and aliases. Five or six types cover a content site: person, organization, tool, concept, event.

Start small. The Fajela knowledge graph is scoped to the industry I cover, currently 52 SEO and digital-marketing experts plus 38 companies and tools, each with its own page on fajela.com. And when I want to test a graph design quickly, I map a single event: I did that with the SEO Vibes 2026 conference, turning it into a graph of speakers, talks, tracks, and topics. One event is enough to force every design decision that matters: what counts as an entity, what the edge types are (SPEAKS_AT, WORKS_AT, COVERS_TOPIC), and what a record must contain.

For person entities I use a fixed field contract: name, current role, organization, short bio of 80 to 150 words, specialties, notable work, sameAs profile links, and Wikidata plus Google Knowledge Graph IDs where they exist. Put real effort into aliases: every spelling, nickname, and transliteration, and if you publish in an inflected language like Ukrainian, the case forms too, or your matching misses half the mentions.

Step 2: Tag every page and guard the entity list

Entity tagging only works as a constraint. Authors pick from the vocabulary, and adding a new entity means making an editorial decision and updating the list. In WordPress that is a custom taxonomy, on a static site a frontmatter field, and in both cases the publish process should reject any tag that is not in the vocabulary.

This discipline is what separates a knowledge graph from ordinary CMS tags: the vocabulary is closed, entities are typed and described, aliases are tracked, and hubs are real pages. Without it, tags are just folders.

One confusion worth clearing up: a knowledge graph and a graph database are different things. The graph is the knowledge itself, meaning your entities, their descriptions, and the connections between them and your pages. A graph database like Neo4j is one possible place to store it, built for querying millions of nodes. A content site holds hundreds of entities and thousands of pages, and at that size the same graph fits comfortably in a WordPress taxonomy or a folder of structured files. Search engines never see your storage anyway. They see the published pages, the markup, and the links between them, and those look identical whatever sits behind them. I keep a Neo4j copy of the Fajela graph for analysis, counting co-appearances and finding the people who bridge communities, but fajela.com itself is served by plain WordPress.

I know exactly what happens without the guardrails, because I audited fajela.com itself this April and found the damage: the same SEO expert published under two different slugs, and my entity hub linking to a dead URL structure I had abandoned mid-migration. Nothing punished me immediately. That is the trap: the damage stays invisible while every duplicate splits rankings, internal links, and related-content blocks in half. The NYT prevents this with a whole taxonomy department. A small site gets the same protection from a validation script and one naming rule, as long as they run on every publish.

Step 3: Publish entity hubs that earn their rankings

A hub page per entity is where the graph starts paying for itself in search. On Fajela’s own entity pages every profile follows mandatory sections: who the person is and their current role, what they are known for, notable work, talks or videos, and a block of verified profile links assembled from sameAs. The fixed structure exists precisely so no hub goes out as a thin list of links, because an auto-generated link list is doorway spam to modern quality systems.

Two rules I follow that most tutorials skip:

• Release hubs gradually. I learned this one the hard way. In April 2026 I pushed my first batch of about forty entity pages live in a single evening, and followed them with thirty more in one deploy two weeks later. The new pages spent a few months in Crawled, currently not indexed, and the pages that already ranked slid down over the same period. I deliberately changed nothing and watched. I could afford it, and that is the point. Fajela.com is my test bench, where I try everything first, including moves I expect to hurt, because a client’s working website or a site a business depends on is no place for experiments. Now I publish a few at a time, each complete, and let the section grow with real coverage.
• Meaning and statistics beat listings. The hub texts that get quoted and linked state what an edge means (who spoke where, who worked with whom) and what the numbers across the graph show.

The SEO payoff: hubs rank for entity queries (names, brands, concepts) that individual articles never hold onto, and each one is a landing page you did not have to write from scratch. And! It is factually correct and trustworthy.

Step 4: Wire the graph into your internal linking

Internal links come straight from the tags. Hubs link to every tagged article, articles link back to their hubs, and related-content blocks connect pieces that share entities. That is hub-and-spoke architecture, generated from metadata. Every new post automatically strengthens the hubs it touches, and old posts keep receiving fresh links as their entities stay in the news. Anchor text is simply the entity’s canonical name.

Step 5: Mark up entities and join the public knowledge graph

Markup is how your internal graph becomes legible to Google’s systems and to LLMs. Each hub carries structured data for its type (Person, Organization, DefinedTerm) with sameAs links out to Wikipedia, Wikidata, and the entity’s real profiles. Articles reference entities through about and mentions. One syntax per page: on SEO Baza I settled on microdata site-wide, on Fajela the blog runs JSON-LD, and mixing both on one page buys nothing but maintenance. On fajela.com a small custom plugin I built pulls entity data straight from Wikidata, so descriptions and identifiers stay consistent with the public graph.

The external identifiers matter more than they look. The NYT understood this back in 2009, when it began releasing its subject headings as linked open data, around 10,000 tags over time, mapped to Freebase, DBpedia, and GeoNames. Wikidata plays that role today, and I track Google Knowledge Graph IDs (KGMIDs) for the entities in my graphs for the same reason: a shared identifier is what lets a machine say “this page, that panel, and that Wikidata item are the same thing.” I went deeper on the personal-identity slice of this in author profile SEO.

Step 6: Keep world-facts out of the graph

The NYT graph asserts only one kind of fact: we published this story and it covers this entity. That fact has perfect provenance and never expires. The moment your graph starts asserting facts about the world, every edge needs a source, a date, and a review cycle, because the world moves on and stored records do not.

I learned the price on an iGaming database project: of 45 stored claims about which payment methods the sites in the graph supported, only 27 survived manual verification. The other 18 were out of date, and the graph kept serving them as facts. That is precisely the behavior knowledge-based trust punishes: confidently stating facts that no longer verify. Since then every fact-bearing record I keep carries a source and a verified-at date, and anything unverified stays out of published pages. For a content site the cheaper rule is structural: keep prices, features, and availability in your prose, where they carry an author and a date, and keep the graph for content-to-entity edges, which never expire.

The minimum viable version of all this is a spreadsheet-sized vocabulary, one taxonomy, and a handful of complete hub pages released gradually. That is a week of work, and it starts compounding from the day it ships. And if you would rather skip the trial-and-error part, knowledge graph based SEO is exactly what I build at Fajela.