Entities and the knowledge graph

Lesson 46 of 50Module 9 · The future of link building6 min read

By Bill Hartzer · Hartzer Consulting · 25+ years in search, domains and expert witness work

Strings, things, and why the distinction is practical

When Google launched the Knowledge Graph it described the shift as “things, not strings.” The phrase has been worn smooth by repetition, but the underlying distinction is genuinely useful and most sites still fail it.

A string is a sequence of characters. Apple is a string. It might mean the fruit, the technology company, the record label, or a village in Ontario. A retrieval system reading a document containing that string has to guess which one, from context.

An entity is a resolved thing with an identifier, a type, a set of properties and a set of relationships. Once a system has decided that this document is about the company rather than the fruit, everything it already knows about the company becomes available — what it sells, who runs it, what it has been in the news for, which other entities it is connected to.

The practical consequence: if a system cannot resolve your name to an entity, every mention of you is a guess. Coverage that should be accumulating into one strong association is scattered across several weak ones, or attributed to a different organization with a similar name. I have watched businesses spend a year on digital PR while their coverage was quietly split between two spellings of their own company name. Fixing that costs nothing and is worth more than the next ten links.

This lesson is the most actionable in the module, and the least speculative. Entity resolution is not a prediction about the future. It is how these systems work now, and the work is available to you today.

Pick one name and use it everywhere

Start here, because it is free and almost everyone gets it partly wrong.

Choose one canonical form of your organization name — the exact string you want to become the entity — and use that string, character for character, in every one of these places:

• The <title> and the visible header of your site
• Your Organization structured data name property
• Your About page, footer and copyright line
• Your social profiles, on every network
• Your business listings and directory entries
• Your press releases, media kit and boilerplate
• The byline and attribution line you ask journalists to use

Decide, deliberately, what to do about the legal suffix. Acme and Acme Ltd are different strings. Pick the one you want to be known as, use it as the primary name, and record the other as an alternate rather than mixing them at random. Structured data has a alternateName property for exactly this.

Do the same for people. If your founder is quoted as Bob Smith in one outlet, Robert Smith in another and Bob Smith, CEO of Acme in a third, you have made resolution harder than it needs to be. Give journalists a standard attribution line and use it consistently in your own bylines. Personal entities matter more than they used to, because expert attribution is one of the things generative answers reach for.

sameAs: the cheapest entity work there is

sameAs is a schema.org property whose whole job is disambiguation. It says: this entity, the one described here, is the same thing as the entity at these other URLs. It is how you connect the scattered accounts of yourself into one identity that a machine can follow.

Put Organization markup on your homepage or a single canonical page, with sameAs pointing to profiles you actually control and actually use:

• Your primary social profiles
• Your company registry or regulator listing, where one exists publicly
• Your Crunchbase, GitHub, industry association or professional body page
• Your Wikidata item and Wikipedia article, if you legitimately have them

Then the same treatment for people, with Person markup: author profiles, a personal site, speaker pages, an ORCID if the person is an academic.

Three mistakes I see constantly. Pointing at profiles you abandoned — a dormant account with a different logo and an old description is a contradiction, not a corroboration. Pointing at profiles you do not control, including third-party listing pages about you; sameAs is an identity claim, not a link-building opportunity, and stuffing it does nothing. Markup that contradicts the page — structured data saying one thing while the visible content says another is a reliable way to have all of it discounted.

Keep it small, accurate and consistent. Five correct sameAs values beat thirty padded ones.

Wikidata, Wikipedia, and honesty about notability

Wikidata is an open, structured, machine-readable knowledge base. Every item has a stable identifier, typed properties and references. It is queryable by anybody, it is used as a source by many downstream systems, and unlike Wikipedia it does not require an article to have been written about you — it requires that you be identifiable and that claims be sourced.

Two honest cautions before you go and create an item.

Wikidata has notability rules and an active editor community. Items created for promotional reasons, with no independent sources, get deleted, and a pattern of that behavior gets accounts blocked. If your organization is genuinely covered by independent sources, an accurate item with proper references is defensible and useful. If it is not, creating one is spam and will be treated as such.

Wikipedia is not a link building tactic and never was. Its links are nofollowed, its conflict-of-interest rules are strict, and editing an article about your own company is the fastest way to have the whole entry scrutinized. If you meet the notability bar, someone will eventually write it. If you do not, no amount of pushing changes that.

What you can do without touching either: make it easy for a human or a machine to establish the basic facts about you. A clear About page with founding date, location, leadership, and what the organization does. Consistent facts everywhere those facts appear. Independent coverage that repeats them. That is the raw material every knowledge base is built from.

Structured data that actually helps

Structured data is not a ranking trick and I would not sell it as one. Its value is that it removes ambiguity — it states, in a form nobody has to parse out of prose, what this page is about and who published it.

The set worth having, in priority order:

1. Organization on a canonical page, with name, url, logo, description, sameAs, and founder or employee linking to Person entities.
2. Person for named authors and spokespeople, with jobTitle, worksFor and sameAs.
3. Article or BlogPosting with a real author reference to that Person, not a bare string.
4. Type-appropriate markup for what you actually publish — Product, Course, FAQPage, LocalBusiness.

The connective tissue is what matters. An Article whose author resolves to a Person who worksFor an Organization with sameAs links out to corroborating profiles is a small, self-consistent graph. Four disconnected blocks of markup are four assertions with nothing joining them.

This site does the same thing one level up. AdvancedLinkTraining.com publishes an EntityMap at /entitymap.json, following the entitymap.org v1.0 specification — a machine-readable document naming every tactic, concept and module covered here, with stable identifiers and the URL that defines each one. It is linked from every page and declared in robots.txt. I did not add it as a demonstration. I added it because I believe the argument in this module, and publishing an explicit map of what a site is about is the logical thing to do if you believe it.