AI can read your website. Can it tell who you are?

Ask an AI assistant to recommend a consultancy, explain a product or compare two companies. The answer may look effortless. Names appear, descriptions follow, and a few sources make the whole thing feel reassuringly settled.

But there is a question underneath all that fluent writing: which company, person or product is the answer actually talking about?

A familiar name is not always enough. Two businesses can share it. An author can appear under different versions of their name. A service can sound like a software product. And a website can describe all three without explaining how they belong together.

This is where entities become useful for GEO, or Generative Engine Optimisation: the work of improving how your content and business appear in AI generated answers.

The interesting part is not adding another layer of jargon to SEO. It is making your identity easier to resolve, your claims easier to check and your relationships easier to follow.

Here is what I want to unpack:

1. What an entity actually is.
2. Why AI systems benefit from clear identities.
3. What Schema.org and JSON-LD contribute.
4. Where Wikidata fits, and where it does not.
5. How to turn all this into useful work on a real website.

1. An entity is a particular thing, not just a phrase

Think of an entity as something you can identify distinctly and describe through attributes and relationships.

An organisation has a name, a website and perhaps a location. A person has a professional role and affiliations. A product has a manufacturer and specifications. A place has a location. A concept has a meaning and connections to other concepts.

These are the five families illustrated in the conference slide that inspired this article: organisations, people, products, concepts and places. Services also belong in the picture, although their description needs to reflect what they actually are.

Take a fictional consultancy called Northstar Analytics. Its founder, Alex Morgan, is one entity. The consultancy is another. Its GEO audit service is a third. Barcelona, where it is based, is another again.

You can put those names on a page. Or you can explain the relationships: Alex works for Northstar; Northstar provides the audit; the business is based in Barcelona.

The second version tells a reader much more. It also provides clearer material for a system trying to connect the facts.

That distinction matters when you move from matching words to identifying the thing those words refer to.

2. Why this matters when the answer is generated

An AI answer about a business needs to keep the subject straight. If it mixes two companies with the same name, even an elegant explanation becomes unreliable.

The complication is that “the AI” is rarely one simple mechanism. Depending on the product and query, an answer may draw on model knowledge, retrieved pages, search results or other connected information. Those routes do not all process websites in the same way.

LLMs can recognise named entities in ordinary text, as research on named entity recognition demonstrates. Recognising a name and resolving which real world entity it refers to are different tasks. A model does not universally require a Wikidata entry or JSON-LD block before it can recognise a company. Claiming otherwise would oversell the technology.

My practical inference is narrower: explicit identity and relationships reduce the ambiguity in the material available to these systems. Whether a particular product uses that material, and whether the resulting answer improves, still needs checking.

On Northstar's website, “we help ambitious brands win” leaves most of the useful questions unanswered. “Northstar Analytics is a consultancy based in Barcelona that provides analytics and GEO audits” gives both readers and machines something more concrete.

The same principle applies to an author page. Give Alex a real biography, a defined role and links to their work. A name under an article is a start; a connected professional identity is more informative.

There is also an editorial benefit. Writing the entity clearly often exposes the vague positioning that was hiding behind the marketing language.

Imagine a comparison question: “Which Barcelona consultancies offer GEO audits, and who leads the work?” A page that clearly connects the organisation, service, location and expert contains the ingredients for a relevant answer. A page containing those four words somewhere in its copy may still leave their relationship unclear. That does not guarantee selection, but it explains why entity work is useful before you start measuring it.

3. Schema.org supplies the vocabulary. JSON-LD carries it

These two names are often bundled together, but they do different jobs.

Schema.org supplies shared terms for describing things and their relationships: Organization, Person, Service, Article, author, publisher and many more. JSON-LD is a format for expressing linked data, commonly placed on a web page inside a script block. Schema.org's introduction and the W3C JSON-LD standard explain the distinction.

You are making the meaning more explicit. This is an organisation. This person works for it. This service has that organisation as its provider.

There is a documented search use here: Google says structured data helps it understand page content, and its organisation documentation specifically describes disambiguating businesses. That supports the case for clearer identity; it does not establish a universal AI citation boost. Google's structured data introduction and organisation guidance.

For Northstar, a small JSON-LD graph might look like this:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://northstar.example/#organisation",
      "name": "Northstar Analytics",
      "url": "https://northstar.example/"
    },
    {
      "@type": "Person",
      "@id": "https://northstar.example/team/alex/#person",
      "name": "Alex Morgan",
      "worksFor": {
        "@id": "https://northstar.example/#organisation"
      }
    }
  ]
}

Fictional example using a reserved example domain; adapt it to facts visibly described on the relevant page.

The organisation gets a stable @id. The person refers to that identifier through worksFor. The two descriptions are connected rather than floating separately. An @graph can group the nodes, while identifiers let them refer to one another. W3C on node identifiers.

Use the same organisation identifier consistently when other pages refer to that business. A service can connect through provider; an article can connect through author and publisher. Choose the type that describes the subject, rather than the one that seems most fashionable.

4. Wikidata gives some entities a shared public identity

Your website can describe your business. Wikidata offers something different: a public, collaborative knowledge base in which an entity can have an identifier shared across languages and descriptions.

Items use identifiers beginning with Q. For example, Q312 identifies Apple Inc., rather than the fruit or another business called Apple.

Labels, aliases, descriptions and statements sit around that identifier. Different language labels can refer to the same item, which is useful when a name varies between markets. Wikidata also records references and links to other databases. Wikidata's introduction.

That makes it a useful identity reference when the item is accurate and genuinely describes the entity in question. It does not mean every AI assistant consults Wikidata for every answer, or that an item automatically gets its subject recommended.

For a multilingual website, this distinction is especially practical. An English page and a Spanish page can describe the same organisation with different wording while retaining the same identity reference. You still need accurate translations and consistent facts. The identifier helps say “this is the same subject”; it does not do the translation or establish that the surrounding claims are true.

There is another limit that deserves more attention: Wikidata is a community knowledge project, not a promotional business directory.

An entity does not necessarily need a Wikipedia article to qualify. The notability policy also allows routes based on serious public references or a structural need. But eligibility must be assessed against those rules; wanting more GEO visibility is not an entitlement to an item. Wikidata's notability policy.

For a small consultancy, the sensible starting point may simply be a clear website, accurate professional profiles and credible external coverage. If a suitable Wikidata item already exists, verify it. If one does not, establish whether creating it serves the knowledge base before thinking about marketing benefits. Wikidata's own guidance warns against creating items for promotional purposes. Help with items.

5. A local identifier and sameAs are not interchangeable

This is a small technical distinction with a large practical consequence.

Your @id identifies a node in your website's data. A sameAs link points to another page that unambiguously identifies the same thing. Schema.org explicitly includes Wikidata entries among its examples. The sameAs definition.

If you were describing Apple Inc., the verified Wikidata URL for Q312 could be an identity reference. It would not be appropriate for Northstar Analytics merely because the consultancy works with Apple products.

Likewise, an article about GEO is not the same entity as the concept of GEO. A founder is not the same entity as their company. Association does not make two things identical.

Use a relationship suited to the claim: author for authorship, worksFor for employment or about for a work's subject. Reserve sameAs for identity.

The same care applies to names. A legal name, trading name and translated brand name can legitimately differ. Explain how they relate instead of forcing every label to match character for character.

A technically valid block can still describe the wrong company. Passing a validator tells you something about the code; it does not certify the truth of every statement inside it.

6. What I would actually change on a website

I would begin with the visible pages.

Can a visitor understand who owns the site, what the business provides, who writes its content and where it operates? Are the important services individually described? Do author biographies explain relevant experience without inflating it?

Then I would map a small set of entities and relationships. For Northstar, that means the organisation, relevant people, services, articles and location. It does not require marking up every noun on every page.

Next comes implementation: stable identifiers, appropriate types and properties, and references that connect the right nodes. Check existing plugins before adding another block; two tools can easily publish conflicting descriptions of the same business.

The markup must remain faithful to the visible content. Do not use it to slip in expertise, awards, reviews or affiliations that the page cannot substantiate. Google's policies require structured data to represent the page accurately. Structured data guidelines.

Then look outside the website. Correct obsolete profiles, clarify ambiguous descriptions and seek credible evidence for the claims you want others to repeat. Repeating your own claim across ten profiles is not the same as independent corroboration.

Finally, check access and measure the result. Can relevant crawlers reach the pages? Can the content be retrieved? When you test questions, does the answer identify the right business and attribute the right services and people to it?

Track mentions, linked citations and factual accuracy separately. A brand can be named without being cited, or cited with an incorrect description. Record the prompts, language, platform, date and failed requests so the comparison has a meaningful baseline.

A change in a small test sample is an observation, not proof of overall market visibility or a causal effect from JSON-LD. Other changes in content, retrieval and the platform itself may affect the result.

7. My view on the GEO promise

I think entity work earns its place when it makes a business easier to understand and its information easier to maintain.

That is a solid reason to invest in it. The weaker pitch is that adding schema and a Wikidata identifier unlocks an AI recommendation system.

Google is unusually clear on this point for its own AI search features: there is no special Schema.org markup required to appear in them. Its guidance keeps the emphasis on established SEO foundations and useful, accessible content. This is a statement about Google's features, not every AI product. Google's AI features guidance.

Wikidata can supply a valuable public reference. Schema.org JSON-LD can express a coherent description on your site. Neither creates expertise, independent evidence or a useful answer where those things are missing.

So I would put the ambition this way: make it easy to identify the right entity, understand what it does and verify why it belongs in the answer. Then test whether the systems you care about actually use that information.

That is less spectacular than a guaranteed GEO shortcut. It is also a much more defensible foundation for the work.