How do I define the entity AI engines should recognize?
A knowledge graph improves AI visibility only when the graph has one clear entity for the company, product or service being described. Start by writing the exact name, category, alternate names, owned domains, locations, products, founders and parent or sibling entities that buyers may mention.
Separate identity from marketing language. “Fastest-growing platform” is a claim that needs evidence, while a legal name, product name or official domain is an identity signal. Record each identity fact in a simple working document before adding relationships.
Check the entity definition against these criteria:
- The primary name matches the name used on the official website.
- Each product has a distinct name and purpose.
- Similar names, former names and abbreviations are recorded.
- Parent, subsidiary, partner and competitor relationships are not mixed together.
- Every important fact has an owner who can approve changes.
If two products share a name, do not publish one combined entity. Split them and add the relationship that distinguishes them, such as product of, owned by or available in.
Choose canonical sources for every important fact
Canonical sources give each graph fact a preferred place to be checked, updated and disputed. Assign one source to each fact instead of allowing several pages to compete as equal authorities.
Use the company’s own product documentation for capabilities, official legal or about pages for identity, and reputable third-party sources for facts the company does not control. A press release can establish that an announcement occurred, but it should not automatically become the best source for a current product capability.
Check each proposed fact before publishing it:
- Can a reader reach the source without an account or private context?
- Does the source state the fact directly rather than imply it?
- Does the source use the same entity name and domain?
- Is the fact current, approved and supported by the page owner?
- What should happen when two sources disagree?
Create a source priority rule before a conflict occurs. For example, current product documentation can outrank an old announcement for a feature, while a legal page can outrank a product page for the company’s registered name. Managing AI visibility across knowledge bases requires the same source ownership discipline, especially when different teams maintain different repositories.
Model relationships instead of collecting isolated facts
Relationships make a knowledge graph useful because AI engines need to connect an entity to its category, products, people, evidence and alternatives. A list of disconnected facts may describe a company, but it does not clearly show what belongs to what.
Start with relationships that answer buyer questions. Connect the company to its products, each product to its use case, each use case to its audience, and each claim to a supporting page. Add competitor or alternative relationships only when the wording is accurate and the comparison has a clear basis.
An illustrative example is a software company called Northstar Forms. The input is “Northstar Forms is a form builder for nonprofit donation pages,” with an official product page and a documentation page. The action is to connect Northstar Forms to the category form builder, the use case nonprofit donation pages, and both source URLs. The check is whether each page names the same product and whether a prompt asking for form builders for nonprofit donation pages returns Northstar Forms with the correct category and evidence.
Check for relationship errors before adding more content:
- A product is not accidentally attached to a former brand.
- A feature is not represented as a separate product.
- A partner is not labelled as an owner or customer.
- A category describes the product rather than an unrelated audience.
- Each important relationship has a source page.
Publish consistent entity signals across the web
Publish the same entity identity and relationships wherever buyers and AI engines can encounter the company. Use structured data on relevant pages, clear headings and internal references, while keeping visible page text consistent with the underlying markup.
Structured data can help machines parse a page, but it cannot repair a contradictory page or establish an unsupported claim. Treat schema, visible copy, documentation, public profiles and feeds as coordinated signals, not separate optimisation projects.
Check the published signals in this order:
-
Confirm that the entity name, URL and description match across the homepage, about page and key product pages.
-
Add appropriate schema to the page that actually supports each fact, rather than placing every property on the homepage.
-
Link related pages using descriptive, stable references that explain the relationship.
-
Remove outdated properties, duplicate entities and markup that describes content visitors cannot see.
-
Recheck the rendered page and structured data after deployment.
If a check fails, correct the source page first, then update the markup. Repeating an incorrect fact in more formats increases inconsistency rather than visibility.
Test whether the graph changes actual answers
Test retrieval with buyer prompts, not only with structured-data validators. A validator can show that markup is syntactically present, while an answer engine may still omit the entity, cite a weak page or assign the wrong category.
Use the same prompt set across ChatGPT, Perplexity, Gemini, Claude, Grok, Google AI Overviews and Google AI Mode. Record the entity named, the position, the cited page, the category used, the competitors shown and any factual error. Keep prompts stable while testing one graph change so the result is interpretable.
A useful test set contains several prompt types:
- Category prompts that ask for suitable providers.
- Use-case prompts that include the buyer’s need.
- Comparison prompts that name an alternative.
- Fact prompts about ownership, capability or audience.
- Disambiguation prompts that could refer to more than one entity.
Check the answer, citation and relationship separately. A brand mention without a citation may indicate recognition without evidence. A citation to the wrong page may indicate that the fact exists but the graph points to a weak or ambiguous source.
Prioritize graph fixes by buyer impact and confidence
Prioritize the graph fix that corrects a high-value buyer relationship with strong evidence and a clear owner. Do not begin with the largest number of missing properties, because a small identity error can affect more answers than many optional fields.
Use a decision rule with three questions: does the missing or wrong relationship affect a real buying decision, can the company support the correction with an authoritative page, and can one team make the change without waiting for an uncertain third party? Fix identity and category errors first, then core product relationships, then supporting details.
A practical priority list looks like this:
-
Wrong company, product or category association.
-
Missing relationship between the product and its main use case.
-
Citation pointing to an outdated, thin or contradictory page.
-
Conflicting ownership, location or audience information.
-
Optional descriptive details with little effect on buyer prompts.
Check the proposed fix against the original prompt set. If the change improves one answer but creates a new contradiction elsewhere, stop and resolve the source conflict before publishing more markup.
Measure the change from source to answer
Measure a knowledge graph change by following the chain from source page to engine answer, rather than treating a ranking movement as proof that the graph worked. The useful record shows which fact changed, which page supplied it, which engines were tested, and what each answer did afterward.
Track whether each engine names the correct entity, uses the intended category, cites the selected source and places the company ahead of the relevant alternatives. Also record negative outcomes, such as an answer that mentions the company but attributes its feature to another product.
Google Search Console can add a separate view of search clicks and queries after a page change, but search clicks and AI citations are different outcomes. A change can improve one without improving the other. AI visibility measurement should therefore keep engine answers, citations and search performance in separate fields.
Run the same checks after the source page, schema or relationship changes have had time to be retrieved. If the result changes only on one engine, keep the change under review instead of declaring the graph fixed across all seven engines.
Choose between manual graph work and an AI visibility platform
Cituna is an AI visibility platform that asks ChatGPT, Perplexity, Gemini, Claude, Grok, Google AI Overviews and Google AI Mode buyer questions every day, records names, citations, positions, competitors and replacement pages, then generates fixes such as schema, FAQ markup, llms.txt and page changes. Manual documentation, schema-only work and a platform solve different parts of the problem.
Manual graph work suits a small set of stable entities when one person can maintain sources, relationships and tests. Schema-only work suits a site with clear facts that are already correct but poorly marked up. A platform suits a team that needs recurring scans, prioritised fixes and a connection between answer changes and page changes. Cituna also provides AutoSEO that can turn identified gaps into articles and publish them to a CMS by webhook, with approval or automatic publishing.
Check the option against the work you actually need:
- Choose manual work when source ownership and prompt testing are easy to maintain.
- Choose schema work when the main failure is machine-readable page structure.
- Choose editorial work when the graph exposes missing buyer-facing explanations.
- Choose a platform when monitoring, fix generation and publishing need to run as one workflow.
The practical next step is to run a free AI visibility scan, then compare the returned gaps with your entity definition and source inventory. A scan is a starting point for brand mention and citation checks, not proof that every graph relationship is correct.
Related reading
- Fix Low AI Visibility: An 8-Step Diagnosis
- Improve AI Search Visibility With Answer-Led Content
- Fix Conflicting Website Facts in AI Search
Official sources to check
- Google Search Central (developers.google.com)
- Google Search Console Help (support.google.com)
- OpenAI Platform (platform.openai.com)
- Perplexity API Documentation (docs.perplexity.ai)
Drafted with AI assistance from our own research and Search Console data, and reviewed by Rahul A before publishing. Rules and prices change; check the linked official source before you act.