Search and AI systems understand an entity by connecting every mention of a name to one distinct thing with known attributes. Google stores those connections in its Knowledge Graph, and language models learn them from repeated context. Schema.org JSON-LD states your facts in machine-readable form, sameAs links point to your official profiles, and consistent facts across the web confirm that every mention means the same company.
This is part six of our series on how search and AI visibility work. How GEO works showed that a brand must be "known" before it can be recommended. This part explains what being known means mechanically. We have deeper guides on entity SEO, Organization schema and sameAs, knowledge graphs for enterprise brands and which schema matters for AI search. This explainer connects them into one model.
The short version
- Mention A system finds your company name in a page, a query or a prompt.
- Match It lists every known entity that name could refer to.
- Disambiguate It uses context such as category, location, people and links to pick one.
- Attach It connects facts from your site, structured data and other sources to that entity.
- Corroborate It gains confidence when independent sources state the same facts.
- Use The entity powers knowledge panels, site names and the descriptions in AI answers.
Strings versus things: what an entity is
A keyword is a string of characters. An entity is the thing the string refers to. "Mercury" is a planet, an element, a Roman god and several companies. A search engine that treats it as a string cannot answer "Mercury founders". One that resolves it to a specific company can.
Entities have attributes and relationships. A B2B software company has a legal name, a founding date, a headquarters, founders, products, the industries it serves and the systems it integrates with. Each relationship connects to another entity: the founder is a person, the integration partner is a company, the industry is a concept. That network is a knowledge graph.
Google's is the best documented. Its Knowledge Graph Search API documentation describes a graph with millions of entries covering real-world people, places and things, typed with schema.org vocabulary and returned in JSON-LD. Each result includes an identifier, name, type, description and a result score. Google's knowledge panel help says the facts come from a variety of sources that compile factual information, plus licensed data for things like sports scores and stock prices, and that verified representatives can claim a panel and suggest changes.
Language models work differently. They have no explicit table of facts. They learn associations from text: which names appear with which categories, people and products. When they search, retrieval brings current pages into the answer, as explained in how AEO works. Both approaches reward the same thing: a name that consistently appears with the same facts.
How a system turns a mention into an entity, step by step
Step 1: Spotting the mention
Every page, query and prompt contains names. The system first identifies spans of text that likely refer to entities: company names, product names, people. Query understanding systems help here; Google's ranking systems guide describes RankBrain as helping it understand how words relate to concepts, and neural matching as relating concepts in queries to concepts in pages.
Step 2: Generating candidates
The system collects every entity the mention could mean. Short, common or descriptive brand names produce long candidate lists. B2B naming trends make this worse: single dictionary words, and names shared with consumer apps, older firms or places.
Step 3: Disambiguating with context
The system scores candidates against the surrounding context. A mention near "SOC 2", "CISO" and "Series B" points to a security software company, not a restaurant. Context comes from co-occurring words, the page's topic, locations, people named nearby, and links. Structured identifiers help directly: Google's Organization structured data documentation lists administrative properties such as legalName, vatID, duns, leiCode and iso6523Code, and says identifiers like these help distinguish an organization from others.
Step 4: Attaching attributes
Once resolved, facts attach to the entity. Your own site is the natural primary source, especially one page that describes the company fully, often called the entity home. Structured data on that page states the facts explicitly. External records such as Wikidata, business directories, review platforms and press coverage add more.
Step 5: Corroborating
Facts that multiple independent sources agree on are easier to trust. Facts that conflict create doubt: two founding years, three different category labels, an old product name still on a directory listing. Google's knowledge panel policies describe removing information that is demonstrably false or outdated. For AI answers, conflicts tend to produce hedged or blended descriptions. This step is inferred from how these systems are described, not from a published formula, but it matches what we see when auditing B2B brands.
Step 6: Using the entity
A resolved, well-attributed entity shows up in several places: knowledge panels, the site name shown in Google results, disambiguation during retrieval, and the one-line description an assistant gives when a buyer asks "who is this vendor". Google's site names documentation says it decides site names automatically from the home page and references across the web, and that WebSite structured data on the home page is the most important signal of your preferred name.
How schema.org JSON-LD works
Schema.org is a shared vocabulary of types, such as Organization, Person, Product, SoftwareApplication and Service, and properties, such as name, founder and sameAs. JSON-LD is a way of writing that vocabulary as a block of JSON inside the page. Google's introduction to structured data describes it as explicit clues about a page's meaning, supports JSON-LD, Microdata and RDFa, and recommends JSON-LD as the easiest to implement and maintain.
Three rules from Google shape how to use it. Structured data does not guarantee rich results. It must describe information that is visible on the page; do not mark up content users cannot see, even if it is accurate. And for AI features specifically, Google's generative AI guide says structured data is not required and there is no special schema to add. Schema is a clarity layer, not a ranking lever.
A practical point for AI crawlers: markup injected through a tag manager only exists after JavaScript runs, and Vercel's crawler analysis found the major AI crawlers it studied did not execute JavaScript. Put JSON-LD in the server-rendered HTML.
Here is a compact Organization and WebSite graph for a fictional company, placed on its home page:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://www.example.com/#organization",
"name": "Acme Risk Analytics",
"legalName": "Acme Risk Analytics Inc.",
"url": "https://www.example.com/",
"logo": "https://www.example.com/images/logo.png",
"description": "Claims analytics software for mid-market property insurers.",
"foundingDate": "2019",
"founder": { "@type": "Person", "name": "Jordan Lee" },
"address": {
"@type": "PostalAddress",
"addressLocality": "Hartford",
"addressRegion": "CT",
"addressCountry": "US"
},
"sameAs": [
"https://www.linkedin.com/company/example-acme-risk",
"https://www.crunchbase.com/organization/example-acme-risk",
"https://www.g2.com/products/example-acme-risk"
]
},
{
"@type": "WebSite",
"@id": "https://www.example.com/#website",
"name": "Acme Risk Analytics",
"alternateName": "Acme Risk",
"url": "https://www.example.com/",
"publisher": { "@id": "https://www.example.com/#organization" }
}
]
}
</script>The @id values give each entity a stable identifier within your site, so other pages can reference the same Organization from an Article's publisher or a Product's brand instead of redefining it.
Other page types connect to the same graph. A Product page can name the Organization as its brand, an Article can name it as publisher and a Person as author, and a Service page can name it as provider. Each reference should point to the same @id rather than repeating the company's details, so there is one definition to keep current. Validate every change with Google's Rich Results Test and the Schema Markup Validator before it ships.
How sameAs works
Schema.org defines sameAs as the URL of a reference web page that unambiguously indicates the item's identity, giving a Wikipedia page, a Wikidata entry or an official website as examples. Google's Organization documentation describes it as a page on another website with additional information about your organization. In practice, sameAs tells a system: these profiles are all the same entity as this website.
Good sameAs targets are pages about you specifically, ideally ones you control or that are authoritative records: your LinkedIn company page, Crunchbase profile, G2 or Clutch profile, Wikidata item if one exists, official YouTube and GitHub accounts, and partner marketplace listings. Poor targets are news articles, listicles that mention you among others, and anything a stranger could not use to confirm your identity. Each profile should link back to your website and repeat the same core facts, which closes the loop.
Where entity facts live, and how each source is used
| Source | Who controls it | What systems take from it | Common B2B inconsistency |
|---|---|---|---|
| Entity home (About page) | You | Primary description, founders, locations, products | Positioning updated on the homepage but not the About page |
| Organization JSON-LD | You | Explicit name, legal name, identifiers, sameAs links | Old logo URL or a sameAs list pointing to dead profiles |
| WebSite JSON-LD | You | Preferred site name and alternates | Missing, so Google guesses from the title element |
| LinkedIn company page | You | Category, size, headquarters, description | Industry label chosen years ago and never revisited |
| Review platforms | Shared | Category, features, segment, customer sentiment | Listed in the wrong category or under a former product name |
| Crunchbase and directories | Shared | Founding date, funding, founders, location | Conflicting founding year or headcount |
| Wikidata | Community | Structured identifiers and relationships | No item, or an item created without sources |
| Press and analyst coverage | Third parties | Category association and credibility | Describes the company as it was at a past funding round |
Consistency across the web: build an entity fact sheet
The fastest entity work is not markup. It is agreeing internally on the facts, then making every source say them the same way. Write a one-page fact sheet with the legal name, brand name and approved short forms; a one-sentence description; the category label; founding year; headquarters; founders and CEO; products with current names; industries served; key integrations; certifications. Then audit every source in the table above against it and fix differences, starting with the ones you control.
Two cautions on community sources. Wikidata has notability criteria that items must meet, and Wikipedia's conflict of interest guideline discourages editing articles about your own company. Earn coverage first. Our guide to Wikipedia for brands covers the ethical route. Executives are entities too; see author entities and expert bylines.
What you control: the entity and schema checklist
- A written entity fact sheet, owned by marketing, approved by leadership.
- One entity home page that states every fact on the sheet in visible text.
- Organization JSON-LD on the home or About page, with legal name, logo, founding date, address and identifiers you actually hold.
- WebSite JSON-LD on the home page with your preferred name and alternates.
- sameAs links only to official profiles and authoritative records about you.
- Every linked profile repeats the same description and links back to your site.
- JSON-LD served in the initial HTML, validated with the Rich Results Test and the Schema Markup Validator.
- Markup that matches visible content, reviewed whenever positioning or product names change.
- Person markup and author pages for executives and subject matter experts who publish.
- A quarterly check of your knowledge panel, the Knowledge Graph Search API and AI assistant descriptions.
Illustrative example: a name shared with another company
Illustrative example. The company, names and findings below are invented to show the process. They are not a client result.
Acme Risk Analytics sells claims analytics software to property insurers. When prospects ask AI assistants "what is Acme Risk", answers blend it with an older risk consultancy of the same name, citing the wrong founding year and describing consulting services it does not offer. The team works through the mechanism:
- Check the graph. A Knowledge Graph Search API query for "Acme Risk" returns the consultancy as the top entity. The software company does not appear.
- Write the fact sheet. Leadership agrees on one description: "Claims analytics software for mid-market property insurers", with founding year, headquarters and founder.
- Fix the entity home. The About page is rewritten to state every fact in plain text, including the full name "Acme Risk Analytics" and the insurance category in the first sentence.
- Add markup. Organization and WebSite JSON-LD go into the server-rendered home page, with legal name, founder, address and sameAs links to its LinkedIn, Crunchbase and G2 profiles.
- Align the profiles. The LinkedIn industry label, G2 category and Crunchbase description are updated to match the fact sheet word for word, and each links to the website.
- Disambiguate in copy. Key pages use "Acme Risk Analytics, the claims analytics platform" on first mention instead of the short form alone.
- Measure. Each month the team reruns five identity prompts across four engines, with and without search, and records whether the description is correct and whether the consultancy's facts still appear.
Glossary
- @id: a URL-style identifier that lets JSON-LD blocks on different pages refer to the same entity.
- Disambiguation: deciding which of several possible entities a mention refers to.
- Entity: a distinct, identifiable thing such as a company, person, product or place.
- Entity home: the one page on your site that fully describes your organization.
- JSON-LD: a JSON format for linked data, Google's recommended way to add structured data.
- Knowledge Graph: Google's database of entities and the relationships between them.
- Knowledge panel: the information box in Google results that displays facts about an entity.
- sameAs: a schema.org property listing URLs that unambiguously identify the same entity.
- Schema.org: the shared vocabulary of types and properties used in structured data.
- Wikidata: a free, community-edited knowledge base of structured data with its own notability rules.
Next in the series
The final explainer connects everything to revenue: how citations become pipeline, with GA4 setup, influenced pipeline and what to report to a board. For an entity and schema review of your own brand, request a free audit or see our AEO, GEO and SEO service.
