If the engine describes you accurately but omits you from lists, you have a content problem. If it confuses you with another company or cannot describe you at all, you have an entity problem.
Two questions separate them in about four minutes, and getting it wrong costs a quarter, because the two fixes have almost nothing in common.
These are the two most commonly confused failures in AI visibility, and they present almost identically from the outside: you ask about your category and you are not in the answer. Underneath, one is a problem of identity and the other is a problem of evidence, and work on the wrong one produces nothing.
What is the difference?
Cannot describe you, describes you vaguely, or attaches facts belonging to a company with a similar name. The engine has no stable idea of you to attach anything to.
Describes you accurately and specifically, then names four competitors when asked to recommend. The identity is fine; the comparative evidence is not.
How do you tell them apart?
Two questions, in a clean memoryless session, asked in this order. The order matters because the first answer tells you how to read the second.
Read for specificity and correctness. A good answer names your category, your buyer and something real about what you do. A bad one hedges, generalises, or describes a different company.
Vague or wrong here ends the diagnosis. It is an entity problem and nothing downstream matters yet.Your name appears nowhere in this one. Run it three times and record which brands come back each time.
Accurate in step 1 and absent here is a content problem, confirmed.What do the four outcomes mean?
| Step 1 answer | Step 2 answer | Diagnosis | First action |
|---|---|---|---|
| Vague or wrong | Absent | Entity problem | Consistent naming and description everywhere, then sameAs |
| Accurate | Absent | Content problem | Third-party comparative evidence |
| Accurate | Present | Neither, on this engine | Widen the prompt set before concluding anything |
| Wrong company | Either | Entity problem, severe | Disambiguation is urgent; nothing else will hold |
The last row is worth pausing on. Being confused with another company is not a milder version of being unknown. It is worse, because every piece of evidence you build risks attaching to the wrong entity, and you can spend a quarter improving somebody else’s visibility.
Why does entity work come first?
Because everything else attaches to a resolved entity, and an unresolved one has nothing to attach to.
Identity in this world is established externally rather than declared. The sameAs property on schema.org’s Organization type exists precisely for this: it is defined as a URL that “unambiguously indicates the item’s identity”, pointing at a Wikipedia page, a Wikidata entry or an official website. You are not asserting who you are; you are tying yourself to identifications that already exist elsewhere.
Google’s site names documentation describes the same principle mechanically: the process is automated, WebSite structured data is “most important”, and it also considers og:site_name, title elements, headings, and references to the site across the web. Your own signals count, and so does what everyone else says.
And the bar for external confirmation is set by whether anyone independent has written about you. Wikidata admits an item that can be “described using serious and publicly available references”, which is a fair summary of what an engine is implicitly testing too.
What does each fix actually involve?
One canonical description used identically on your site, your profiles, your press and your directory listings. Organization markup with sameAs pointing only at references that exist. Weeks, not quarters, and mostly free.
Review platforms, directories, independent comparison pages, genuine community presence. A quarter at best, and it is the layer that actually moves recommendation lists.
The entity fix has a detail people miss: consistency beats improvement. A description rewritten every quarter never accumulates the agreement across sources that makes an entity resolvable. Picking a slightly worse sentence and keeping it for two years outperforms picking the perfect one and revising it four times.
What does an entity problem look like in the wild?
Four patterns, and recognising them is faster than reasoning from first principles each time.
The generic description
“A software company that helps businesses with their operations.” Technically about you and true of four thousand others. The engine is padding because it has nothing specific.
Entity
The near-miss
Facts belonging to a company with a similar name, or a similar name in a different market. The most damaging version, because it looks like an answer.
Entity, severe
The historical version
Accurate about what you were two pivots ago. The corpus agrees about you; it agrees about an older you.
Entity, stale
The hedge
“I do not have detailed information about this company.” Honest, and the clearest signal available that nothing retrievable exists.
Entity
Note what none of these are. None of them is an engine judging your product, and none is fixed by writing more about yourself. They are all failures of external agreement about what you are.
Can you have both at once?
Frequently, and the sequencing rule is the same either way: entity first, always.
Building third-party evidence for a company an engine cannot resolve is spending on a layer that has nothing to attach to. Worse, if you are being confused with another company, some of that evidence lands on them. Fix identity, wait for the description in step 1 to firm up, and then start the slow work.
A brand with an entity problem and a large evidence budget is the most expensive failure mode in this discipline, because the money is being spent correctly on the wrong layer.
How do you know the entity fix worked?
Re-run step 1 across three engines, three times each, a fortnight after the changes land. You are looking for the description to become more specific and more consistent between runs, not for it to become flattering.
Two cautions. Answers vary between identical runs, so a single improved answer is not evidence. And changes have to be recrawled before they reach an answer at all, so a same-week re-test mostly measures your own impatience.
Why does this get misdiagnosed so often?
Because the test people run by default only exercises one half of it.
The instinctive check is to ask the buying question, see that you are absent, and conclude the engine does not know you. That skips step 1 entirely, and step 1 is the one that separates the two failures. Absence from a list is compatible with the engine knowing you perfectly well, and without asking you cannot tell which world you are in.
The second reason is that entity work is more legible internally. It is a project with tasks, markup and a finish line, so it is easier to propose than a quarter of asking other people to write about you. A team that has not run step 1 will reliably choose the fix that sounds more like work they know how to do.
If both checks come back clean and you are still absent from recommendation lists, the diagnosis has moved on: see why your SaaS doesn’t appear in AI recommendations for the evidence work, or the four-cause diagnostic if you would rather rule out the other two causes first.