A knowledge graph is a structured store of real-world things and the relationships between them, held separately from the text of any web page. Answer engines consult one before answering because it resolves what a name refers to, and a system that cannot work out which company you are will hedge rather than recommend you.
The phrase that explains it best came from Google itself when it launched the idea, and it is still the clearest four words on the subject.
An intelligent model, in geek-speak a graph, that understands real-world entities and their relationships to one another: things, not strings.
Amit Singhal, Introducing the Knowledge Graph, May 2012
A string is the characters in your brand name. A thing is your company, with a founding date, a category, a set of competitors and a location. That distinction was fourteen years old before most people started worrying about AI search, and it is the part of the machinery that decides whether an answer can name you with confidence.
What was actually launched, and at what scale
The Knowledge Graph went live in May 2012 with more than 500 million objects and over 3.5 billion facts about and relationships between them. Those numbers matter less as a measure of size than as a signal of intent. Google stopped treating a query as text to be matched and started treating it as a question about things.
Google described the graph as doing three jobs, and each one has a direct consequence for whether your company gets named.
| What the graph does | What it means for you |
|---|---|
| Disambiguates a query with several possible meanings | If your name collides with something better documented, this step resolves away from you |
| Summarises the key facts about a thing | Whatever the graph holds about you is what gets stated, accurate or not |
| Connects a thing to related things | Determines which competitive set you are placed in, and whether you appear in it at all |
Whether the second row is working correctly for your company is a five-minute check and most companies have never run it. Ask any assistant what your company is, and if the summary is wrong or hedged, the free visibility check covers the entity diagnosis and tells you which part is failing.
The distinction that actually matters: public graphs and private ones
This is the part usually left out, and it changes what you can realistically do.
A public graph is one you can read, query and verify. Wikidata is the obvious example, assigning a stable identifier to each entity and publishing everything it holds. You can look yourself up in about a minute and see exactly what it says.
A private graph is one you cannot inspect at all. Every large search and AI company operates one, none of them publish the contents, and there is no interface for reading your own record or correcting it. You are working blind.
The practical consequence is that you cannot edit the graph that matters. What you can do is control the evidence it is built from, which means the facts on your own site, the structured data expressing them, and the third-party records that corroborate both. Consistency across those three is the whole mechanism, and it is slower and duller than editing a record directly.
Why an answer engine checks a graph before it writes
A retrieval system pulling passages about a company faces an immediate problem. Passages are text, text contains names, and names are ambiguous. Before it can assemble anything, it needs to decide which entity the question is about, so that it retrieves passages about the right thing.
A graph answers that cheaply. It gives a canonical identity, a set of attributes to check retrieved passages against, and a map of related entities to draw comparisons from. Without one, a system is guessing from context alone, and guessing wrong about a company is the kind of error these systems are tuned hard to avoid.
Which is why hedging is the default when identity is unclear. Not naming you costs the engine almost nothing. Naming the wrong company costs it a great deal.
What a graph holds about a company, and what it will not
Graphs store facts that are stable, checkable and expressible as a relationship between two things. They do not store judgements. That boundary explains a lot about which of your claims survive into an answer and which evaporate.
| Held in a graph | Not held in a graph |
|---|---|
| Founded in 2019 | The fastest growing platform in its category |
| Headquartered in Manchester | Trusted by industry leaders |
| Sells contract review software | Built for teams who care about accuracy |
| Competes with these four named companies | The obvious choice for mid-market legal |
| Founded by this named person | Award-winning and best-in-class |
This is why the exercise of writing your entity facts is so often uncomfortable. Strip a homepage down to statements a graph could hold and a surprising amount of the page turns out to be adjectives. That is not an argument against the adjectives, which do real work on human readers, and it is an argument for making sure the checkable facts exist somewhere as well.
Finding out what is actually held about you
You cannot read the private graphs. You can read the public ones, and you can probe the private ones indirectly, which together tell you most of what you need in about fifteen minutes.
- Look yourself up in the public graph. Search Wikidata for your company name. Either a record exists, in which case read every statement on it, or it does not, which is itself the finding.
- Ask an assistant to list facts, not opinions. Ask when your company was founded, where it is based and what it sells. Errors here are graph-level problems rather than content problems.
- Ask who your competitors are. The answer reveals which set the system has placed you in, and being put in the wrong set is a specific and fixable failure.
- Compare across engines. Consistent facts across four engines suggests a well-resolved entity. Four different answers suggests they are each inferring from your prose because no reliable record exists.
Step three catches more real problems than the others combined. A company that gets listed against competitors it does not actually compete with is not suffering a visibility problem. It is being understood as the wrong kind of thing, and every downstream answer inherits that error.
What a graph is built from, in order of how much you control it
- Structured data on your own pages. Fully under your control, and the cheapest thing on this list. This is where you state your identity in a form requiring no interpretation, using the RDF family of standards that this whole layer of the web sits on.
- Explicit identity links. Also fully controlled. Pointing from your entity to authoritative records of the same entity elsewhere, which is the single most neglected signal available.
- Third-party records and profiles. Partly controlled. Registries, directories and databases where you can correct what is held about you if you go and do it.
- Independent coverage and discussion. Barely controlled. What other people write about you, which carries the most weight precisely because you did not write it.
The ordering is deliberate. Most companies spend on the fourth and skip the first two, which are free, fast and sitting there untouched.
Why this is slower to fix than it looks
Graphs are conservative by design. A record built from years of accumulated evidence does not update because you published a new about page last Tuesday, and that stability is a feature rather than a bug, since a graph that changed every time somebody edited a website would be useless.
The practical consequence is a lag. Corrections take effect over months, and the more evidence exists supporting the old version, the longer it takes. A company that rebranded two years ago is still fighting every article, profile and directory entry carrying the previous name.
Which argues for doing the cheap parts early rather than at the point you need the result. Structured data and identity links cost an afternoon and start accumulating evidence immediately. Waiting until an answer engine describes you wrongly means starting the clock at the moment the problem is already expensive.
There is a version of this problem that has no fix worth attempting, and it is worth recognising early. If your company shares a name with something enormously better documented, a bank or a city or a widely used common noun, you will not win that resolution contest by publishing better markup. What you can do is make sure every other signal disambiguates hard, and accept that questions using your name alone will stay unreliable while questions pairing it with your category work fine.
Graphs are slow to change and worth understanding before you spend anything on them, because most of what moves one sits outside your own website.
We publish our entity and graph audits as we run them, including the ones where the finding was that a client had no record anywhere. The newsletter is where those go out.
Related reading
- Mention, citation, recommendation. Being named, being sourced and being chosen are three outcomes that need three different fixes.
- AEO vs SEO. Why the unit changed from a page to a passage, and the prize from a click to a mention.
Shaban runs answer engine optimisation for B2B SaaS companies at Uncited Brands. He works the unglamorous end of the problem, mostly crawler access, retrieval diagnostics and measurement baselines, and publishes the tests that do not go his way alongside the ones that do.