If you've ever searched your own brand name and wondered why Google shows a confident knowledge panel for one competitor but not for you, you've run into the same question this tracker is built to answer: how strongly does Google's Knowledge Graph associate a name with the right entity?
With Claude’s help, I created a Knowledge Graph Score Tracker that queries Google's Knowledge Graph Search API on a schedule, logs a relevance score for each entity you're tracking, and flags anything that looks off.
This article walks through setup, how to read the output, and how to fold it into an SEO workflow.
What does the tracker measure?
The Knowledge Graph API doesn't return a single "confidence" number for an entity in the abstract. It returns a relevance score (Google calls resultScore) for how well your search term matches a specific result — and that score only exists when you search by name/text.
If you query by KGMID (the entity's permanent ID) instead of a search term, the API just confirms the entity exists; there's no matching to score, so no confidence number comes back.
That's why the tracker always runs the name-based search first — that's the only mode that produces a real number. KGMID, when you have one on file, is used as a second check: does the top name-match result actually resolve to your entity, or to a different one that happens to share the name?
And about the score itself - I usually consider it from a relative perspective. An absolute number.
A note on the score itself: the score tells you nothing by itself. That’s why I usually compare the results against other entities, such as benchmarking to your past score to see how it moves over time or comparing against your competitors.
The tracker's Confidence label (Very Low → Very High) is also just a scannable bucket built on top of that raw number.
How to set up the tracker
1. Get an API key. In the Google Cloud Console, enable the Knowledge Graph Search API and generate a key. Paste it into the API Key field on the Settings tab.
2. Set your defaults.
- Results per Query — how many candidate matches to pull back per entity (max 500, default 10). Higher isn't automatically better; see the section on multiple results below.
- Language — a BCP-47 code (en, fr, de, etc.) to scope results to a language.
3. Build your entity table. Each row needs:
- Label — your own nickname for the entity, used for grouping in the Results sheet.
- Search Term — the name you'd actually search, e.g. "HubSpot" or "Acme Consulting Chicago."
- KGMID (optional) — the entity's permanent ID (e.g. /m/045c7b), used purely to verify the name search is landing on the right entity, not to generate a score.
If you don't know your KGMID yet, leave it blank. Run a lookup, find your entity in the results, copy its KG ID value into the KGMID column, and future runs will start verifying against it automatically.
4. Run it. Use the menu to run a lookup on demand, or schedule a recurring run. Either way, results append to the Results sheet — nothing gets overwritten, so you build a history over time.
How to under the results?
- Confidence: A plain-language bucket (Very Low → Very High) derived from the raw relevance score. N/A (ID lookup) means this row came from a KGMID-only search with no score to report.
- Verification: Whether the name search's top result matches your stored KGMID.
- ✅ Verified = correct entity.
- ⚠️ Mismatch = the name is currently resolving to something else.
- Unverified = no KGMID on file to check against.
- Result Score: The unrounded number Confidence is based on. Useful for tracking small movements over time that a bucket label would hide.
- Result Count: How many candidate matches came back for that search, at the limit you set.
- Flag: Set to ⚠️ No Results when the search returned nothing at all — usually the most urgent thing to check.
What to do when a search returns multiple results
This is one of the most common points of confusion, so it's worth addressing directly.
A multi-result response isn't a malfunction — it means your search term is ambiguous from Google's side, even if it feels unambiguous to you. Common causes:
- A shared name. "Delta" the airline, "Delta" the faucet brand, and "Delta" the Greek letter are all legitimate entities. A generic or short brand name is more likely to collide with something else in the graph.
- Multiple legitimate representations of the same underlying thing — a company and its product line, a person and the organization they founded, a local business and its parent brand.
- A near-duplicate or stale entity — sometimes the graph has two entries for what's really the same thing, often after a rebrand, merger, or an old Wikipedia redirect that hasn't fully consolidated.
How to handle it:
- Look at the Type(s) and Description columns for each result. This is usually enough to tell which one is actually you.
- Once you've identified the correct entity, copy its KG ID into the KGMID column for that row. From then on, the tracker's Verification column will tell you immediately if the name search drifts to a different result — which is exactly the scenario multiple results puts you at risk of.
- If your actual entity isn't in the top results at all, that's a more serious signal than ambiguity — it means Google's Knowledge Graph doesn't yet associate your brand name strongly enough with your entity to surface it. That's a disambiguation and entity-building problem, not a tracker problem (more on this below).
- Don't just raise the Results-per-Query limit to "catch" your entity further down the list and call it solved. If your entity is only showing up at position 8 or 15, a low relevance score is a symptom — the fix is strengthening the entity's signals (structured data, consistent naming, authoritative citations), not widening the query window.
The result score is stable, don't expect daily movement
The relevance score reflects how the Knowledge Graph has indexed and weighted an entity, which is built from structured data, sameAs links, Wikipedia/Wikidata associations, and citation patterns across authoritative sources. That underlying graph doesn't get rebuilt every day, and Google has been explicit that this API isn't a real-time, production-grade service — it's a reflection of a graph that updates on its own, comparatively slow cadence.
Practically, that means:
- A flat score for weeks is normal, not a sign the tracker is broken.
- Small day-to-day fluctuations (a few points either way) are typically noise, not signal — don't overreact to them.
- Meaningful movement usually follows a real-world trigger: new or updated schema markup, a fresh Wikipedia article or major edit, new authoritative backlinks/citations, a rebrand, or Google reprocessing the graph after a data refresh. These take time to propagate — expect weeks, not hours.
- A sudden drop to zero or a Flag is a different category of event and worth investigating immediately (see Troubleshooting).
Given that, running this daily mostly tells you "nothing changed" — which still has value as a monitoring baseline, but a weekly cadence is often the more useful default. Save daily runs for periods right after you've made a deliberate change (new schema, a PR push, a Wikipedia edit) and want to watch for the graph catching up.
How to use the result in your SEO workflow?
1. Track entity health alongside keyword rankings
Traditional rank tracking tells you where you show up in search results. This tells you whether Google's systems actually understand who you are — which increasingly matters for knowledge panels, AI Overviews, and answer-engine citations, all of which lean on entity recognition rather than plain keyword matching.
2. Validate structured data changes
After adding or updating Organization, Person, or Product schema markup, add the entity to your tracker and watch for the score to firm up over the following weeks. It's a lightweight way to confirm the markup is actually being picked up and trusted, not just validating without errors.
3. Monitor brand disambiguation risk
If you operate under a name that's shared with something else (a common word, a similarly named competitor, a legacy brand), track both your entity and the conflicting one side by side.
A ⚠️ Mismatch is an early warning that searchers — and AI systems pulling from the graph — might be getting confused between the two.
4. Watch competitors' entity strength
Add competitor names to the tracker (without a KGMID, since you're not verifying anything, just observing) to see whether their Confidence sits meaningfully higher than yours.
If it does, it's often a sign they have stronger Wikipedia presence, more consistent citations, or more mature structured data — all things you can benchmark against.
5. Catch entity drift after major changes.
Rebrands, domain migrations, and M&A activity can all cause your name to briefly (or not-so-briefly) resolve to an outdated or incorrect entity in the graph. Running the tracker through and after these events gives you an early signal if the graph hasn't caught up with reality.