The sameAs Property: How to Link Your Brand Entity

sameAs is the schema.org property that tells a search engine “this external profile and this organisation are the same thing.” It is how you connect the entity described on your site to the entity described on LinkedIn, Wikidata, Crunchbase or Companies House — so the engine can merge that evidence into one confident record instead of several uncertain ones.

It is also the most casually misused property in entity markup. This page covers what belongs in it, what does not, and why the instinct to list everything is exactly wrong.

What it does

Search engines assemble your entity from many sources. The hard part is knowing which sources are about you. A LinkedIn company page for “Ambeltek” and a website at ambeltek.com might be the same organisation, or might be two unrelated things that share a name.

sameAs removes that guess. It is a first-party assertion of identity, published in structured form, that says: these URLs and I are one entity. Combined with a stable @id, it is what lets the engine build a single node rather than a scatter of partial ones. Schema.org documents the property here.

That is the whole job. It is not a ranking mechanism, and expecting position changes from it will only produce disappointment.

Where it goes

On the entity it describes — which means separate lists for your company and for the people in it.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Studio",
      "url": "https://example.com/",
      "sameAs": [
        "https://www.linkedin.com/company/example-studio/",
        "https://www.crunchbase.com/organization/example-studio",
        "https://www.wikidata.org/wiki/Q000000"
      ]
    },
    {
      "@type": "Person",
      "@id": "https://example.com/about/#founder",
      "name": "Jane Example",
      "worksFor": { "@id": "https://example.com/#organization" },
      "sameAs": [
        "https://www.linkedin.com/in/janeexample/",
        "https://scholar.google.com/citations?user=abc123"
      ]
    }
  ]
}

Note what is happening structurally: two entities, two sameAs lists, and an explicit worksFor relationship joining them. Putting the founder’s personal LinkedIn on the Organization node would tell the engine the company is the person, which is precisely the ambiguity you are trying to remove.

For the full graph these nodes sit inside, see Organization schema for AI search and Person schema and author entities.

What belongs in it

The test is simple: would a careful human agree this URL is officially about this exact entity?

Include	Why
Wikidata item	Structured, licensed, directly feeds knowledge systems
Wikipedia article	Highest-trust corroboration where one exists
Official LinkedIn company page	Verified, actively maintained, widely cross-referenced
Crunchbase / industry databases	Structured records engines already ingest
Official social accounts you actually post to	Confirms an active, consistent presence
Company registry entries	Authoritative legal identity

Wikidata deserves particular emphasis. It is machine-readable, openly licensed, and consumed directly by knowledge systems — which makes it disproportionately valuable per link. Getting an item is not automatic though, and the notability rules matter; Wikidata for brands covers the honest version.

What does not belong

This is where most implementations go wrong.

• Profiles you abandoned. A Twitter account last posted to in 2021 corroborates nothing and suggests the entity is stale.
• Pages about a similarly named company. Actively harmful. You are asserting you are them.
• Low-quality directory listings. Auto-generated aggregator pages add noise, not evidence.
• Your own other pages. sameAs is for external references. Internal URLs belong in url or @id.
• Partner, client or vendor links. These are relationships, not identity. Schema has other properties for them.
• Anything unverifiable. If a human could not confirm the page is officially yours, an engine will not weight it either.

The underlying principle: sameAs is evidence, and evidence is weakened by dilution. Eight solid links beat thirty mixed ones, because contradictory or ambiguous entries force the engine to lower its confidence in the whole set.

The collision problem

There is one situation where sameAs does real damage, and it is not obvious.

If your brand name is close to an established entity, and you list a profile that the engine already associates with that entity, you are supplying first-party evidence that you are the same thing. Instead of separating yourself, you have argued for the merge.

Before building a sameAs list, check whether your name actually resolves cleanly. If it does not, disambiguation comes first — adding identity assertions to an unresolved entity makes the confusion more confident, not less. Entity disambiguation covers how to check and what to do.

Implementation checklist

1. Inventory every external profile that is genuinely official and current.
2. Cut anything abandoned, ambiguous, auto-generated or merely related.
3. Split the survivors between the Organization node and each Person node.
4. Use canonical URLs — the profile’s real address, not a shortened, tracked or redirecting one.
5. Cross-link back where the platform allows it. A LinkedIn page linking to your site while your site links to the LinkedIn page is mutual confirmation; a one-way assertion is just a claim.
6. Validate the JSON-LD parses and the nodes reference each other correctly.
7. Keep it current. A sameAs list is a maintenance commitment. Prune when you abandon a platform.

Step 5 is the one most often skipped and does the most work. Reciprocity is what turns an assertion into corroboration.

Where this sits

sameAs is one signal among several, and it is the cheap one — an afternoon’s work that raises the value of everything else you do. It cannot substitute for having facts stated clearly on your own site, and it cannot manufacture corroboration that does not exist.

The full sequence is in the entity SEO guide, and the procedural version is the knowledge graph optimization checklist. If you would rather have it built and validated for you, that is part of our schema markup service.