Build an entity graph
of your own site
Engines do not read your site page by page. They resolve it into things: people, products, organisations, topics, and the connections between them. Moose builds that graph from the pages already crawled on your machine, and labels which connections your site states and which he worked out. Once it is built, he can read it in any later chat.
SamPremium
On it, Sam. Let's map how Fathom's entities connect across the site.
I can build an entity graph for this project. Choose how deep the run should go, then start it below.
Hi, Moose maps the people, products, places, and topics across this project's crawled pages, plus how they connect.
Chief desk supervisor. Resolves as one entity, firmly related to the sofa and to lunch. A cleaner graph than most websites manage.
An engine does not see pages. It sees things, and how they relate.
Before an engine can recommend you, it has to know what you are. A product, made by an organisation, founded by a person, in a category, competing with these others. That resolution happens whether you help it or not.
If your site never states the connections, the engine infers them from third parties or leaves you as a floating name it cannot place. That is how you end up mentioned but never recommended, or described using a competitor's category.
One card, and two exports
It is built from the pages already crawled for this project, so every number traces back to a URL you own.
People, organisations, products, services, places, events and topics, each with the number of pages it appears on, plus a count by type. That count alone tells you whether your site reads as a product or as a pile of articles.
A score per entity, weighted by where the name shows up. Structured data counts for more than a title, and a title counts for more than a subheading. The entity at the top is rarely the one on the homepage.
The connections your pages state, the ones that keep appearing on the same pages, and the ones whose names sit close in meaning. The card splits the count across all three, so you can see how much of the graph your own site wrote.
Entities with their type, aliases, page count, score and up to three source URLs each. Relations with their kind, source and confidence. The PDF is the one you forward, the CSV is the one you sort.
Quick first, Full when it earns it
Both run against the crawl already on your machine, and both map the connections at the end. The difference is whether a model reads your body text.
Reads the JSON-LD on your pages plus the things named in your titles and headings. Seconds on most sites, no model involved, nothing leaves the machine.
Pick the top 100, 250, 500 or 1,000 pages, ranked by Search Console clicks where you have it connected. A model reads the body text and pulls the things you name in prose but never mark up. It runs on your local model, your OpenRouter key, or your monthly allowance on a paid plan.
The counts are the finding
You are not reading the list. You are reading a handful of numbers, and each one points at a different piece of work.
Where the validator-and-whiteboard route goes wrong
You know how this normally goes: a validator, a crawl export, a whiteboard diagram nobody updates, and a firm opinion about schema from someone who read a blog post in 2019. It is slow, but slow is the smaller problem. These four are why the output does not survive contact with an engine.
A validator checks syntax on one page. It cannot tell you that your product and your company are two disconnected entities across the whole site.
Spreadsheets count text. Deciding that two spellings are the same organisation, and that a third is a different one, needs a resolution step nobody does by hand consistently.
Whiteboard graphs describe how the brand wishes it were structured. Engines read what is on the pages, which is usually thinner and messier.
A hand-built audit is a one-off, so nobody ever proves the schema change worked. Rebuilding here takes seconds, which is what makes the before and after worth having.
Ask once, read the shape, publish the fix
The pages are already on your machine from the site crawl, so the graph is built from your own site rather than a third-party index of it.
Site Monitoring crawls the project and keeps the pages locally. The graph runs on those pages, so it waits until one crawl has finished.
Ask for an entity graph, pick it from the Tools menu, or use the button on a new chat. Same card either way: choose Quick or Full, then start.
Which type dominates, which entity carries the salience, and how many connections your pages state themselves. Take the CSV or PDF into the schema work, or just ask: Moose keeps the graph and can read it in any later chat.
Quick reads your local crawl, and the connection mapping is local too, including the similarity pass, which uses a small embedding model on your own hardware. Full is the one that sends page text out, and only to the model you picked. Choose a local model and that stays on the machine as well.
Three kinds of connection, never blended
A graph that quietly invents relations is worse than no graph, because you would ship markup asserting things your site never said. So every connection carries its kind, and the card counts them separately.
Founder, publisher, brand, works for, part of. Quick takes these from your JSON-LD and follows the @id references inside it. Full adds the ones a model finds stated in your prose. If no page says who founded the company, there is no founder relation.
Entities that repeatedly appear on the same pages, labeled "appears with" and carrying the number of pages they share. That is evidence of a pattern on your site, not a claim about the world.
A small embedding model runs on your machine, compares your entity names, and keeps the strongest few per entity above a similarity floor. Labeled "related to" and scored. This is the layer that still gives a site with no markup a usable graph.
Case, punctuation and a trailing Inc or Ltd fall away, so "NinjaOne, Inc." and "Ninjaone inc" become one entity. Two different types stay two entities, which is why a brand can appear as both a product and an organization. That split is a finding, not a bug.
Where a name appears counts as much as how often. Structured data outweighs a title, a title outweighs a subheading, and the score is compressed so one page repeating a word cannot run away with the ranking.
The table and the exports carry the top 2,000 entities and 2,000 relations, with the true totals on the card. If the AI pass gets skipped, stopped or fails, the card says so instead of passing a Quick graph off as a Full one.
From the graph to the markup
The graph stays with the project after the card, and Moose reads it himself. You do not paste numbers back at him. You ask what to do about them.
Questions people ask
What is an entity graph, in plain terms?
A list of the things your site talks about, and the connections between them. Not keywords, and not pages. An engine builds one of these about you whether you look at it or not, so the useful move is to see yours and decide whether it says what you meant.
Why are most of my relations shared-page or semantic?
Because those two are the ones Moose can work out on his own. Labeled relations come from your markup, plus anything the Full pass reads out of your prose, and on most sites the markup stops at the article template. So the labeled number starts low. Raising it is the point of running this.
Do I need schema markup for this to work?
No. Without it you still get entities from your titles and headings, and connections from shared pages and name similarity. What you will not have is a single labeled relation, which is itself the finding.
What does the Full pass cost?
Nothing beyond time on a local model. On a cloud model it spends your OpenRouter key, or your monthly allowance if you are on a paid plan. You choose how many pages it reads: 100, 250, 500 or 1,000. Quick needs no model at all and is free on every plan.
What do I need before I can build one?
A project with a website, and one site crawl that finished. The graph reads pages already stored on your machine, so if no crawl has run the card sends you to Site Monitoring first.
Can Moose use the graph after he builds it?
Yes. The graph stays with the project, and Moose can read it in any later chat. Ask him which internal links to add, how the site should be organised, or which schema gap to close first, and he pulls the answer from the graph rather than from memory. He keeps what your pages state separate from what he inferred, so he will not tell you to fix markup that never existed. And if the project has no graph yet, he offers to build one.
How is this different from a coverage check?
Coverage answers whether you have written about a topic. The graph answers what your site says you are. You need both: one stops you writing duplicates, the other stops engines describing you as a category you do not sell in.
More things to ask Moose
All use casesAsk before you brief, and get the pages, the verdict and what is missing.
Ask why traffic moved and get an answer with the tables under it.
The searches Google writes for itself before it answers, and who it cites.
Twelve searches behind one prompt, including the ones naming brands it trusts.
One question, five real engines, about a minute. Free on every plan.
The full list, and what Moose does step by step in each one.
See the version of you
an engine can read.
Download Hi, Moose, crawl your site once, and build the graph in seconds. Quick runs on the free plan.