sameAs: which profiles actually help an entity resolve

sameAs is the most misunderstood property in structured data. It is not a place to put every social account the company owns, and it is not a ranking signal. It is a claim of identity: this URL is another page that refers to the same thing the current node describes. The useful version of that claim is short, verifiable and boring. The useless version is long, self-referential and never checked.

This article is about which profiles actually help an entity resolve, which ones are decoration, and how to audit the list you have. It is not a list of platforms to sign up for; it is a filter for the ones worth linking.

What sameAs actually claims

Schema.org defines sameAs as a URL of a reference page that unambiguously indicates the identity of the entity. The word that does the work is unambiguously: the destination has to identify the same thing, not merely mention it or be run by the same person. A link to a company’s own homepage is a self-reference, not corroboration. A link to an unrelated profile with the same name is worse than nothing.

The property is a list of claims, and a claim is only useful when someone can check it. That is why the quality of the destination matters more than the number of links: an engine resolving an entity is looking for independent pages that agree, not for a package of links the entity published about itself.

A hierarchy that is actually useful

The ordering is about independence, not prestige. A small directory that clearly names the product and links to the site can be more useful than a large social account that never mentions it. The test is the same for every row: if a stranger opened the URL, would they know which entity it describes?

What this site does

LLMention’s Organization node lists three profiles: the author’s GitHub profile, the public repository for the scanner, and an AI-agents directory listing. They are in the list because each one exists, names the project, and can be opened and checked. The site deliberately does not list every account or a placeholder profile that has not been created — a link to a page that does not exist is not an identity claim.

The Person node carries its own profile link, and the WebSite and WebPage nodes point back to the Organization with @id references rather than repeating the list. One entity, one list, referenced from the places that need it.

The mistakes that make the list worthless

• Self-reference. sameAs pointing at your own homepage or another page on your own site is circular; it corroborates nothing.
• Profiles that do not mention the brand. A personal account with no reference to the company is not evidence that the company exists. If the profile is personal, attach it to the Person node, not the Organization.
• Fabricated or dead profiles. A 404 or a redirect to an unrelated page is a broken claim. The scanner does not fetch the list, so this passes the check and fails the reader.
• Name drift. The profile says one name, the site says another, and the JSON-LD says a third. Consistency across the three is the whole point.
• Padding. Fifteen links where four would do makes the credible ones harder to find, for a person and for a model.
• The wrong node. A company profile attached to a Personnode (or the reverse) sends the reader to the wrong entity to resolve.

How to audit your own list

Fetch the JSON-LD from the response, extract every sameAs value, and check each one by hand. The commands are deliberately boring; the judgement is the work.

# 1. List the sameAs URLs in the server response
curl -sS https://your-domain.com/ \
  | python -c "import sys,json,re; html=sys.stdin.read(); \
      blocks=re.findall(r'<script[^>]*application/ld\\+json[^>]*>(.*?)</script>', html, re.S); \
      [print(u) for b in blocks for u in re.findall(r'\"sameAs\"\s*:\s*\[?\"([^\"]+)\"', b)]"

# 2. Check every one returns 200 and is not a redirect to somewhere else
#    (run once per URL)
curl -sS -o /dev/null -w "%{http_code} %{url_effective}\n" https://profile.example.com/brand

For each URL that survives, answer three questions: does the page name the entity clearly, is it on a platform the entity does not fully control, and does it link back to the canonical site. Three yeses is a good profile. Two is acceptable. One or zero is a link, not corroboration.

What the scanner scores — and why the score is low

The rule is sameas, worth 2 points in the trust and authority dimension. The condition is only that parsed JSON-LD contains a non-empty sameAs. The rule page is explicit about the limit: the profiles are not fetched, so a list of accounts that no longer exist passes.

That is the right level for a cheap check. Presence is a one-line assertion; verification is work. Treat a pass as a reminder to do the work, not as evidence that the entity has been resolved. The same is true of every markup check on this site: the score describes the page, and the page is only as good as the claims in it.

What it changes, and what it does not

A short, verifiable sameAs list makes entity resolution cheaper: it gives a model or a person a few independent places to confirm that the brand on this site is the same brand on GitHub, in the directory, or in the registry. That reduces a specific kind of error — merging two same-named things, or treating a product and its company as unrelated.

It does not guarantee a citation, a ranking or even correct resolution. Identity is inferred from many signals, and one list is one input. The honest goal is narrower and achievable: make the claim checkable, then keep it true.