In short: Nearly all the entity work you can do yourself is subtraction. One name for one thing, the category in the words the category is actually known by, and relationships stated instead of implied.
None of it is clever and none of it is new. It is unglamorous consolidation work that nothing used to force, because a person reading your material supplies the context that a machine will not.
Do this before schema, before templates, and before any tool. It is the part that makes everything after it legible.
One Name For One Thing
Pick the name. Write it down. Use it everywhere, including the places nobody proofreads: page titles, the footer, invoices, job listings, conference bios, the author line on your blog, your own social profiles.
The test is not whether a person could tell these are the same company. It is whether a system with no context would have any reason to merge them.
Where variants hide: legal entity name against trading name, the name with and without a suffix, the product name with and without the company in front of it, the abbreviation your staff use internally, and the domain used as a name. Count yours rather than estimate them. The count is the finding.
Consolidating does not mean the legal name disappears. It means one form is canonical, is used in every position where a machine reads a name, and the others resolve to it rather than competing with it.
The Category You Are In
Classification decides whether you are a candidate for a question at all, and it works on the words the category is actually known by rather than the words you would prefer.
Invented category language is the most common self-inflicted wound here. "Revenue orchestration platform" is a positioning decision that may be entirely correct for a sales conversation. It is also a category with almost nothing written about it, which means a system has no material with which to place you in it, and no question that arrives in those words.
The rule: say what you are in the words a buyer would use to ask for it, then say what makes you different. Both, in that order, on the page. A page that only does the second is invisible to the question that would have found it.
You can keep the category you wish existed. State it after the one that already exists, not instead of it.
Relationships, Stated
Association is built from material, and material means sentences somebody can point at. A system does not infer that you integrate with a tool because your product technically does. It reads that you do.
Four relationships are worth stating explicitly, in plain sentences, on pages that exist for the purpose:
- Who made thisA named organisation and named people, with identities that lead somewhere
- Who it is forThe role, the size of company, the market, stated rather than implied by tone
- What it competes withThe alternatives a buyer is actually weighing, named. This is the one almost nobody does
- What it works withIntegrations, standards, platforms and formats, named individually
Where To Say It
These statements have to live somewhere durable and readable. An about page with a real organisational description and named people. A page per product that states what it is before what makes it special. Comparison pages that name alternatives. Documentation that names the standards and systems you work with.
All of it in the initial HTML, for the reason the discovery lesson gives: a claim that only exists after JavaScript runs is a claim that many crawlers never see.
Structured Data, Honestly
Mark up the entities you have just made consistent. Organization, Person, Product and BreadcrumbList are the ones that earn their keep, and they should agree exactly with the prose around them.
What schema markup demonstrably does is make entities and relationships explicit rather than implied, and improve how you appear in conventional search, which feeds the retrieval layer. No major AI system has confirmed it as a direct input to answer selection, and it will not rescue a page that fails at extraction.
The mistake worth avoiding is treating markup as the work rather than as the record of the work. Marking up four different names for one company does not consolidate anything. It documents the inconsistency in a machine-readable format.
An Hour That Is Worth Spending
Open a document. List every form of your company name you can find in twenty minutes across your own properties, then pick one. List the category words a buyer would use, then check whether any of them appear on your homepage.
Then write down the four relationships above, and note which of them exists as a sentence somewhere a machine can read.
Whatever you find, none of it requires a developer. That is the whole of this lesson.
Key Takeaways
- Entity work you can do yourself is mostly subtraction: removing variation you introduced.
- Pick one canonical name and use it in every position a machine reads, including the unglamorous ones.
- State the category in the words it is already known by, then state your difference. Inventing a category removes you from the question that would have found you.
- Say who made it, who it is for, what it competes with and what it works with, in sentences rather than by implication.
- Schema records consistency, it does not create it, and it is not confirmed as a direct input to answer selection.
Check yourself
Before you move on
Not scored, not recorded, and not part of the certificate. Both answers are settled by a sentence in this lesson, and the reasoning appears whichever option you pick.
- 01
A company appears across its own properties as Acme, Acme Inc, Acme Software and getacme.com. What has it produced?
- 02
A B2B company describes itself as a revenue orchestration platform. Buyers search for sales engagement software. What does that cost?