Skip to content
siterank.info
Sign in Start free

GEO

Entity Clarity: Helping Machines Understand Who You Are

One name, one URL, one identity, expressed consistently in prose and in markup. What is standard, what is emerging, and what is guesswork.

By ankitkumarvig@gmail.com Published September 9, 2026 Last reviewed September 9, 2026 Sources verified September 9, 2026 9 min read

An entity is a named thing a machine can hold onto: an organisation, a person, a product, a place. Entity clarity is the degree to which a site makes it unambiguous which entity it is talking about and which entity it is. Most sites are worse at this than their owners think, because a human reader resolves "we", "the company", "Acme", "Acme Ltd" and "Acme Group" to the same thing without noticing the effort. A machine does not get that for free. This article covers what to fix, and — importantly — how much of it is documented versus assumed.

The failure mode, concretely

A mid-sized consultancy runs a site where:

  • The homepage title says Acme Advisory.
  • The footer copyright says Acme Advisory Group Ltd.
  • The About page opens "Founded in 2014, Acme has…".
  • The Organization schema, emitted by an SEO plugin, has name: "Acme" and url: "http://acme.co" while the canonical site is https://www.acme.co.
  • LinkedIn says Acme Advisory Group; Companies House says ACME ADVISORY GROUP LIMITED; a directory listing says Acme Consulting.
  • No sameAs anywhere.
  • Blog posts are bylined "Admin".

Nothing here is a violation of anything. Every one of these is normal. Collectively, they mean that any system attempting to resolve "Acme Advisory" to a single entity is doing reconciliation work, and every reconciliation step is a chance to merge you with something else or split you into two. That is the problem entity clarity solves.

Layer one: consistency in prose

The cheapest and least glamorous fix, and it is EMERGING PRACTICE — widely practised, mechanically plausible, and not tied to any documented outcome by any provider.

Pick one canonical name and use it. Decide whether you are "Acme Advisory" or "Acme Advisory Group Ltd" in ordinary prose, and use the legal name only where the legal name belongs — terms, invoices, the legalName schema property. Do not alternate.

State the identity in the first paragraph of the About page. "Acme Advisory is a UK employee-benefits consultancy founded in 2014 in Bristol." One sentence, containing the name, the category, and enough qualifiers to disambiguate you from the other Acmes. This is the sentence a retrieval system has the best chance of using, because it is self-contained — the same reason passage-level structure matters generally.

Do not bury identity in a logo. If the only place your full name appears is an image, it is not text.

Name yourself rather than saying "we". Not in every sentence — that reads badly — but at least once per substantive page. A passage extracted out of context that says "we help clients reduce costs" identifies nobody.

Layer two: pages that exist to establish identity

Google's helpful-content guidance is the closest thing to first-party support here, and it is worth being precise about what it says. It asks whether it is self-evident to visitors who authored the content, whether pages carry a byline where one might be expected, and whether bylines lead to further information about the author. It recommends presenting background information through links to an author page or a site's About page, and it states that Google strongly encourages adding accurate authorship information such as bylines where readers might expect it. It frames the goal as demonstrating experience, expertise, authoritativeness and trustworthiness — noting that trust is the most important of the four.

That is OFFICIAL PROVIDER GUIDANCE for conventional Search quality. It says nothing about AI answer engines, and it should not be quoted as if it did.

Page What it should establish Tier
About Canonical name, what the organisation does, when and where it was founded, who runs it OFFICIAL PROVIDER GUIDANCE (as a trust signal for Search)
Contact A real, reachable route — address where applicable, not only a form OFFICIAL PROVIDER GUIDANCE
Author pages Real people, with genuine background and links to their real profiles OFFICIAL PROVIDER GUIDANCE
Editorial policy How content is produced, reviewed and corrected EMERGING PRACTICE

The editorial-policy page sits lower because no provider documents it as a factor. It is a reasonable expression of the "How" question in Google's Who/How/Why framing, and plenty of credible publishers have one, but calling it a signal would be overclaiming.

The prohibition that matters most

Do not manufacture any of this. Invented authors, invented credentials, invented founding dates, invented awards, invented review counts — these are fabricated trust signals, and they are prohibited outright under our editorial rules, regardless of whether any engine detects them. Google's structured data guidelines separately prohibit using markup to deceive or mislead users and to impersonate any person or organisation. If a fact is unknown, the field stays empty and somebody asks the client. A tool that fills in a plausible author name is not helping.

Layer three: markup

Schema.org gives you a vocabulary for saying explicitly what the prose implies. The vocabulary is an ESTABLISHED STANDARD; Google's documented use of it is OFFICIAL PROVIDER GUIDANCE; the claim that it improves AI citation is HYPOTHESIS.

Google's Organization documentation states there are no required properties — you add the properties that apply to your organisation — and recommends placing the markup on the home page, or on a single page that describes the organisation such as the About page. You do not need it on every page.

The properties Google documents include name, alternateName, url, logo, sameAs, address, contactPoint, email, telephone, legalName, description, foundingDate, numberOfEmployees, and identifier properties such as iso6523Code, taxID, vatID, duns, naics and leiCode.

A worked example, with every value corresponding to something visible on the page:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.acme.co/#organization",
  "name": "Acme Advisory",
  "legalName": "Acme Advisory Group Limited",
  "alternateName": "Acme Advisory Group",
  "url": "https://www.acme.co/",
  "description": "UK employee-benefits consultancy founded in 2014.",
  "foundingDate": "2014",
  "logo": "https://www.acme.co/assets/acme-logo.png",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "14 Queen Square",
    "addressLocality": "Bristol",
    "postalCode": "BS1 4NT",
    "addressCountry": "GB"
  },
  "sameAs": [
    "https://www.linkedin.com/company/acme-advisory-group/",
    "https://www.wikidata.org/wiki/Q00000000"
  ]
}

Three details do most of the work.

@id is the identity anchor. A stable, absolute, site-wide @id is what lets every other entity on the site — each Article, each Person, each WebPage — point at this organisation rather than redeclaring a similar one. Google's structured data guidelines note that linking related items via @id helps it understand the connections between them. Change the @id and you have created a second organisation.

alternateName is where variants belong. If people genuinely call you "Acme Advisory Group", say so once, in the right property, instead of letting the variation leak into page titles.

sameAs is the disambiguation property. Schema.org defines it as the URL of a reference web page that unambiguously indicates the item's identity — the example given is the item's Wikipedia page, Wikidata entry, or official website. Google frames it more loosely as a URL on another site with additional information about your organisation, such as a profile on a social media or review site. Both framings point the same way: sameAs links to identity-bearing pages you control or that authoritatively describe you.

Two rules for sameAs that are routinely broken. First, only list profiles that are genuinely yours and genuinely active; a dead 2016 Twitter account is noise. Second, do not list a competitor's or a partner's page because it mentions you — sameAs asserts identity, not association.

Where markup goes wrong

  • Two Organization entities. The SEO plugin emits one and a theme or a second plugin emits another, with different @ids and different names. This is the most common defect on real WordPress sites, and it makes identity worse than having no markup. Inspect before you emit; see structured data for AI and search.
  • url pointing at a non-canonical variant. http:// instead of https://, or the bare domain when the canonical host is www..
  • Author as a bare string. "author": "Admin" is not an entity. A linked Person with a real @id, a real profile page, and real sameAs links is.
  • Marked-up facts not on the page. An address in the schema that appears nowhere in the visible content violates Google's guideline that content marked up must be visible to readers.

What not to assume

That entity clarity is an AI ranking factor. It is not documented as one, and Google states there are no additional requirements or special optimisations for its AI features. The strongest honest claim is that ambiguity is a plausible obstacle to any system that has to resolve you to something, and reducing it is cheap and harmless. That is EMERGING PRACTICE.

That a knowledge panel or a Wikidata entry can be manufactured. They are outcomes of external recognition, not fields you fill in. Adding a sameAs to a Wikidata item that does not describe you is a false identity claim.

That mentions equal understanding. A model that produces your name may have no stable representation of you at all. Being mentioned is not being cited, and neither implies the system has resolved you correctly. If you want to know how you are described, observe it — repeatedly, with intervals — rather than inferring it. That is what /methodology/ sets out.

That consistency means never changing. If you rebrand, change everything at once: prose, titles, schema, profiles, and alternateName to carry the old name. A half-finished rename is worse than either name.

An audit you can run today

  1. Grep your rendered pages for every variant of your organisation name. Count the distinct strings. More than two is a finding.
  2. Fetch the homepage and count "@type": "Organization" occurrences across all JSON-LD blocks. More than one is a defect.
  3. Check that the url in schema exactly matches your canonical homepage, scheme and host included.
  4. Check that every sameAs target resolves, is current, and actually describes you.
  5. Check that every post has a byline resolving to a real author page.
  6. Read your About page's first sentence out loud. If it does not name you, say what you do, and locate you, rewrite it.

SiteRank's GEO audit runs the machine-checkable parts of this — name variance across the corpus, duplicate or conflicting Organization entities, missing About and Contact pages, authorship transparency — each finding tagged with its tier, and the HYPOTHESIS-tier items excluded from any status band rather than counted as failures.

Key takeaways

  • Entity clarity is one canonical name, one canonical URL, one identity, expressed identically in prose and markup.
  • Authorship transparency, About and Contact pages are OFFICIAL PROVIDER GUIDANCE for Search quality, not for AI citation.
  • Schema.org Organization with a stable @id, honest alternateName, and real sameAs links is ESTABLISHED STANDARD vocabulary used the way Google documents.
  • Duplicate Organization entities from competing plugins are the common real defect and actively harm identity.
  • Never invent an author, a credential, a date, or a sameAs target. Unknown fields stay empty.

Official sources & further reading