Blog · Machine readability

sameAs and the identity links engines check

Published 8 October 2026 · Updated 12 October 2026 · 8 min read

sameAs and the identity links engines check
Photograph: Karine Avetisyan / unsplash

The short answer: sameAs is a property you put on your Organization markup that lists other web pages describing the same organisation. Schema.org defines it as a reference page that unambiguously indicates the item's identity, and Google's Organization documentation asks for pages carrying more information about your organisation. It proves nothing on its own. It is a claim pointing outward, and on the evidence below it does most of its work when the pages it points at agree with you, link back, and can be fetched by the agent answering the question.

In the audits we run, the usual sameAs array is a social footer turned into JSON: a row of profile links and nothing in it that resolves an identity. We have not counted that across a published sample, so read it as what we keep seeing rather than a rate. That version is harmless and it is also close to inert.

Two definitions, and the gap between them

Schema.org is narrow about this. Its own definition of sameAs, in version 30.1 dated 16 September 2026, reads: "URL of a reference Web page that unambiguously indicates the item's identity. E.g. the URL of the item's Wikipedia page, Wikidata entry, or official website." The word doing the work there is *unambiguously*. A reference page. Something a machine can resolve against.

Google's Organization structured data page, updated 8 September 2026, says something looser: a URL of a page on another website with more information about your organisation, for example a profile on a social media or review site. Same property, two readings. One asks for identity grade references, the other invites your social accounts.

The practical consequence is an ordering problem rather than a contradiction. Put the identity anchors first and the social accounts after them, because the first kind resolves a question and the second kind only adds colour. If you are building the Organization node from scratch, Organization schema done properly covers the rest of the required shape, and Structured data for AI search: what to mark up first covers the order to do it in.

The fetchability problem nobody tests

Here is the part that gets skipped. A sameAs link is worth more at answer time if the agent writing the answer can open it. Several of the profiles people list most proudly tell exactly those agents to stay out.

We read these files on 8 October 2026 and re-read them on 12 October 2026, unchanged both times. LinkedIn's robots.txt runs to 4,862 lines and ends with a blanket User-agent: * followed by Disallow: /. Inside it, GPTBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot and Perplexity-User each get their own group, and each of those groups is a flat Disallow: /. OAI-SearchBot and Claude-SearchBot get narrower rules that block the personal profile paths. OpenAI's crawler documentation describes ChatGPT-User as the agent that may visit a page in response to a question someone puts to ChatGPT, and the same page notes that because those actions are user initiated, robots.txt rules may not apply to them. So the LinkedIn line is a stated preference, not a proven block: we cannot see from outside whether a given fetch happens. What the file does show is that LinkedIn asks each of these agents to stay out, and OpenAI's page points site owners at OAI-SearchBot, not ChatGPT-User, for managing search opt outs.

Crunchbase reads the opposite way. Its robots.txt carries an explicit tier for answer agents, naming OAI-SearchBot, ChatGPT-User, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User and Meta-ExternalFetcher, and allowing them every path, with a comment saying the reason is citations. GitHub is narrower than it first looks: its opening group names GPTBot, OAI-SearchBot, ClaudeBot, anthropic-ai and PerplexityBot with a one second crawl delay and no blanket disallow, while ChatGPT-User and Claude-User are not named there and fall through to the User-agent: * group, which also leaves organisation profile paths readable. On wikidata.org, robots.txt names no AI agent at all, so nothing there is aimed at them either way.

None of this means a blocked profile is worthless. Engines can also work from search indexes and from training data, and a well maintained company page still feeds those. What a robots.txt gives you is not a ranking signal, it is one thing about the array you can read for yourself.

What an identity anchor actually is

An anchor is a record with a stable identifier that other records already point at. Wikidata is the clearest case: its statistics page reported 123,612,534 items when we read it on 12 October 2026, a live counter rather than a dated release, and each item carries a Q number that other datasets reuse as a join key. When your organisation has a Wikidata item, you have given every system a single token to agree on instead of a string to match.

After that, in rough order of resolving power: a Wikipedia article if one legitimately exists, a national company register entry, GitHub for anything with an API, then the directories, then the social accounts. Review platforms sit oddly in the middle. They turn up often in the comparison answers we read during audits, and they are weak as identity proof.

Two properties sit next to sameAs and get confused with it. Use url for your own homepage, because Google's Organization documentation says that property helps Google uniquely identify your organisation. Use @id to give the Organization node one identifier, something like https://example.com/#organization, and reference that same @id from every other page's markup.

The five failures we keep finding

Many organisations instead of one. Every template emits its own Organization object, each with no @id and a slightly different sameAs list. A parser that cannot join them has no reason to think they are one company. One node, one identifier, referenced everywhere.

Dead and redirected targets. Profiles get renamed. A sameAs URL that 301s to a different slug, or 404s, is a link into a dead record, and a chain of redirects costs the fetcher time it may not spend.

No reciprocity. The claim runs one way only. If the directory entry does not link back to your exact canonical host, the pair is unconfirmed. Match the scheme and the host exactly, including the www decision.

Contradicting facts. Founded year on one profile, a different one on another, two spellings of the city. We cannot see what an engine does with the conflict. What we see in audit outputs is vaguer, more hedged descriptions of companies whose records disagree, and a hedge reads to a buyer as absence.

Padding. A long array of mostly abandoned accounts. We have not found documentation from Google, OpenAI, Anthropic, Perplexity or Microsoft saying this is penalised, and ranking internals are not visible from outside. What it plainly does is dilute a signal you were trying to concentrate.

A test you can run in ten minutes

Pull every URL out of your sameAs array and check four things per URL.

  1. Status. curl -sI -L -o /dev/null -w "%{http_code} %{url_effective}\n" <url>. Anything

    2. that is not a 200 landing on the URL you declared gets fixed or dropped.

  2. Robots. Fetch the target host's robots.txt and search it for ChatGPT-User, OAI-SearchBot,

    3. PerplexityBot and the Claude agents. Note which of your links are closed to live fetching.

  3. Reciprocity. Open the target and confirm it links back to your canonical domain, spelled

    4. the way you spell it.

  4. Agreement. Compare the founded year, the city and the legal name against your own about

    5. page. One source of truth, mirrored.

Then do the half of the job that markup cannot do, which is ask the engines what they currently believe. How to check what engines say about you, properly sets out how to run that repeatedly rather than once, and Why five engines give five different answers about you explains why the same identity work lands at different speeds on different systems. If you want a shorter version to try this afternoon, the self-check lists ten tests of this kind with no tooling involved.

Honest limits

What this post establishes is narrow: what four robots.txt files said on the dates we read them, and what two specification pages say about one property. It does not establish that a given engine fetches, or declines to fetch, any profile at answer time, and OpenAI's own documentation warns that robots.txt may not govern a user initiated ChatGPT-User request, so the LinkedIn finding is a stated preference rather than a proven block. We also cannot show a clean curve from a repaired sameAs array to more mentions, because identity fixes ship alongside everything else and the engines change underneath the measurement. The effect we report from our own work, that descriptions get more specific and hedge less once the records agree, is a qualitative impression from client audits with no sample frame, no control group and no count, so treat it as a direction and not a rate. And we have not found public documentation from Google, OpenAI, Anthropic, Perplexity or Microsoft on how heavily sameAs weighs against an engine's own entity graph, which is why we call the property cheap to get right rather than a lever with a known multiplier.

FAQ

Does sameAs help if I have no Wikidata item? Yes, less. Without an anchor you are asking engines to join your records on a name string, which is fragile for any brand whose name is also a word. Get the directory entries consistent first, then look at whether you meet the notability bar for an item at all.

Should my own homepage go in sameAs? Schema.org permits it and Google uses url for that job, so fill in url and keep sameAs for pages on other sites. A separate about page or grounding page on your own domain is better pointed at with mainEntityOfPage.

How many links belong in the array? Enough to resolve you and no more. Five strong records beat twenty weak ones. Every link should be a page you would be happy to have quoted.

Do I need sameAs on every page? No. Put the full Organization node on one canonical URL, give it an @id, and have other pages reference that @id rather than repeating the array with variations.

Is a blocked profile worth listing? Usually yes, because search indexes and training sets can still reach it. Just do not assume it will be opened and read during a live answer, and make sure something fetchable sits above it.

Sources

Related reading

Structured data for AI search: what to mark up firstOrganization schema done properlyHow to check what engines say about you, properlyWhy five engines give five different answers about youWhat an agent-readable page looks likeYour API and MCP server as a visibility surface