In a previous note about entity disambiguation, I covered how Google figures out which “Apple” you mean: the disambiguation systems, the patents behind them, and why ambiguous entities are a real problem for machines trying to understand pages. And in my note on custom schema, I mentioned briefly that schema lets you skip the guesswork by declaring your entities outright, and promised a fuller note on it later.
This is that note. Entity grounding is the practice of linking the entities in your schema markup to the knowledge bases Google and AI systems already trust, so nothing about your site has to be inferred. It’s the part of schema almost everyone skips, it costs nothing but care, and it’s one of the few things you can do that helps you with Google and with AI systems in the same stroke.
Why Bother
Three real benefits, none of them hype.
First, you remove ambiguity. The disambiguation note covered how much machinery Google runs to figure out which entity a page means. Grounding solves that problem from your side. When your markup says your article is about project management software, and points at the exact Wikidata entry for project management software, there’s nothing left to guess.
Second, it supports how Google builds its picture of you. Knowledge panels, brand entities, and Knowledge Graph consolidation all depend on Google connecting the mentions of you across the web into one stable entity. Your sameAs links are you raising your hand and saying: this website, this Wikipedia page, this Wikidata entry, this LinkedIn profile are all the same thing.
Third, AI systems benefit from the same clarity. A model deciding whether your page covers a topic well enough to cite has an easier job when the page declares its subject in machine-readable form and anchors it to a knowledge base the model already knows.
To be clear about what this is not: it is not a ranking hack. Nobody jumps three positions for adding sameAs links. It’s clarity, and clarity compounds quietly across everything that reads your site.
The Four Properties and What Each One Claims
Entity grounding runs through four schema properties, and each one makes a different claim. Using the right one matters.
sameAs says this node IS that entity. It’s an identity claim. Your Organization node is the same thing as this Wikidata company entry, this Wikipedia page, this LinkedIn profile. Your author Person is this specific human. Use it on nodes that represent real-world things: the organization, the author, the place.
about says this page’s subject is that concept. An article about entity disambiguation carries an about pointing at the entity for named-entity disambiguation. One or two about entries, for the genuine central topic. Not five.
mentions says the page substantively discusses these related concepts. Not every noun on the page. The concepts a reader would agree the page actually covers.
knowsAbout says your organization’s expertise is this field, and this is the one almost everyone misses. Most sites that ground anything link their brand identity and stop. But sameAs on your Organization only establishes who you are. knowsAbout establishes what you know. A law firm whose Organization node carries knowsAbout pointing at family law and divorce is telling every system that reads it what the firm’s expertise actually is, which is precisely the kind of signal that matters in a world where topical authority and expertise keep gaining weight.
The practical minimum for a typical page: the page’s central topic gets an about, your organization’s field gets a knowsAbout, and the page’s main subjects get grounded via sameAs or mentions. If you do only that, you’re ahead of nearly everyone.
What a Grounded Page Looks Like
Here’s a compact example: a consultancy’s article about project management software, with the publisher’s expertise and the article’s subject both grounded.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Consulting",
"url": "https://example.com/",
"sameAs": [
"https://www.wikidata.org/entity/Q00000001",
"https://www.linkedin.com/company/example-consulting"
],
"knowsAbout": [
{
"@type": "Thing",
"name": "Project management",
"sameAs": "https://www.wikidata.org/entity/Q179012"
},
{
"@type": "Thing",
"name": "Project management software",
"sameAs": "https://www.wikidata.org/entity/Q167035"
}
]
},
{
"@type": "Article",
"@id": "https://example.com/pm-software-guide/#article",
"headline": "Choosing Project Management Software",
"author": { "@id": "https://example.com/#organization" },
"publisher": { "@id": "https://example.com/#organization" },
"about": {
"@type": "Thing",
"name": "Project management software",
"sameAs": "https://www.wikidata.org/entity/Q167035"
},
"mentions": [
{
"@type": "Thing",
"name": "Kanban",
"sameAs": "https://www.wikidata.org/entity/Q180591"
},
{
"@type": "Thing",
"name": "Gantt chart",
"sameAs": "https://www.wikidata.org/entity/Q192847"
}
]
}
]
}
The Organization’s placeholder Q-number would be your company’s real entry if one exists (more on that below). Everything else in this example is a real, verified Wikidata entity. Note the shape of it: identity via sameAs, expertise via knowsAbout, subject via about, supporting concepts via mentions. Four claims, four properties, no ambiguity anywhere.
Where to Link
Wikidata is the workhorse. Nearly every concept, place, organization, and notable person has an entry, each with a stable Q-number. Use the entity URI form: https://www.wikidata.org/entity/Q167035. This is the identifier form rather than the wiki page form, and it’s what knowledge systems resolve.
Wikipedia when a page exists. Wikipedia coverage is thinner than Wikidata’s, but when your entity has a page, include it. Google’s own entity systems were built on Wikipedia from the start.
Official profiles for identity. LinkedIn, Crunchbase, and your social profiles belong in your Organization’s sameAs. They’re not knowledge bases, but they corroborate identity, and consistency across them is exactly the kind of stable picture you want machines to assemble.
Google’s Knowledge Graph mid, with a caveat. If your brand has a knowledge panel, it has a machine ID (a string like /m/0xxxxx), and some SEOs include a Google search URL referencing it. Fine if you have it, but mids are hard to independently verify, so treat this one as optional rather than required.
How to Find and Verify a Q-Number (and the Traps)
Finding a Q-number is easy: search Wikidata for the concept, or check the “Wikidata item” link on the entity’s Wikipedia page. Verifying you have the right one is where people get burned. Four traps, all of which I’ve hit personally.
Never trust an ID from memory or from an AI without checking. AI tools will confidently invent plausible-looking Q-numbers. While building my schema skill, the model handed me a wrong ID for Bethesda, Maryland, formatted correctly, entirely plausible, pointing at the wrong thing. That’s the worst kind of error, because it looks fine in your markup and quietly tells every system that reads it that your page is about something it isn’t. Every ID gets checked against the live Wikidata entry before it ships. No exceptions.
Read the description and the “instance of” statement, not just the label. Wikidata is full of same-name entities. Search “anger management” and you’ll find the therapy concept, the Adam Sandler film, the TV series, and an Eminem concert tour. The label matches in all four cases. The description and the instance-of statement (is this a “form of psychotherapy” or a “2003 film”?) are what tell you which one you’re holding.
The company-versus-product trap. This one bites constantly with software and brands. Search Wikidata for “Basecamp” and the obvious match is the company entity, the business formerly known as 37signals, not the software product. Workfront and ClickUp resolve to company entities too. Some products have separate entries for the company and the software (Wrike has both), and which one you want depends on what your page actually means. Linking a product review to the corporate entity is a subtle mismatch that defeats the precision you’re doing all this for. Check the instance-of: “business” versus “project management software” tells you immediately.
When no clean entity exists, don’t force it. Plenty of small companies, local businesses, and niche concepts have no Wikidata entry, and the wrong response is grabbing the nearest similar-sounding one. A wrong grounding is worse than none. Fall back to official profiles for identity, or leave the entity ungrounded and move on.
The Typing Rule That Keeps Your Markup Valid
One technical rule will save you a failed validation, and I learned it from a Rich Results Test run that lit up red.
When you ground entities you’re referencing (everything in about, mentions, and knowsAbout), type them as plain Thing with a sameAs. Do not type them as SoftwareApplication, Product, Recipe, Event, or any other rich-result type, even when that’s literally what the entity is.
The reason: rich-result types carry required-property validation. SoftwareApplication requires at least two of offers, aggregateRating, applicationCategory, and operatingSystem, and Google’s Rich Results Test throws a critical error for each one that falls short. I found this out testing markup that referenced a dozen software products as SoftwareApplication mentions: every single one errored with “two or more properties required,” because a page mentioning a competitor doesn’t have that competitor’s prices and ratings, and shouldn’t invent them.
Typing the reference as Thing with a verified sameAs sidesteps all of it, and you lose nothing: the Wikidata entry already says what the entity is. Save the rich types for the page’s actual primary subject, where you genuinely have the data the type requires.
Restraint
Ground the central topic, the publisher’s field, and the page’s main subjects. Then stop.
A page where every noun carries a Wikidata link isn’t better grounded, it’s noisier. The signal you’re sending with about and knowsAbout works because it’s selective: these few things are what this page and this organization are actually about. Fifty mentions entries dilute that claim to nothing, the same way a page targeting fifty keywords targets none. If you wouldn’t tell a colleague “this page is about X” with a straight face, X doesn’t get grounded.
If You’d Rather Not Do This by Hand
Everything in this note, the entity identification, the property selection, the Q-number lookups, the verification against live entries, the Thing typing, is exactly what the free Claude Schema Builder skill I released does automatically. It won’t output an entity link it couldn’t verify, which, after the Bethesda incident, is not a feature I consider optional.
And as of this week, there’s a ChatGPT version too. It’s built as a custom GPT with a direct connection to the Wikidata API, so when it verifies a Q-number, it queries the actual database rather than hoping a web search surfaces the right page. Same rules as the Claude skill: nothing unverified gets into the output.
But even if you use the skill, knowing what it’s doing matters, because you’re the one who has to catch the company-versus-product judgment calls and decide what your organization genuinely knows about. The tool handles the lookups. The claims are yours.
