sameAs is the most misused property in structured data. I've watched it tank a
site's trust signals, and the cause is almost always the same: someone treated it
as a place to stuff links.
Here is the rule, stated plainly: sameAs is for the entity's own profiles. Only
those. Nothing else.
What belongs in sameAs
For a person: your Wikidata item, ORCID, GitHub, the LinkedIn profile that is
actually yours, your verified social accounts, your Crunchbase, your scholar
profiles. For an organization: its Wikidata item, its LinkedIn company page, its
Crunchbase org, its verified business listings. These are all the same entity,
elsewhere. That is the literal meaning of the property — "this is the same thing
as that."
What does NOT belong in sameAs
- Backlink URLs you'd like to count. A page that links to you is not you.
- Article URLs that mention you. A write-up about you is not a profile of you.
- GitHub repository or pull-request URLs. A repo is a work product, not an identity.
- A competitor's or a partner agency's URL. Obviously not you.
- A sibling brand's marketing homepage as a raw link (use the sibling's
schema
@idand a real relationship likeparentOrganization/subOrganizationinstead).
When you put non-identity URLs in sameAs, you're telling search engines and AI
models that those URLs are the entity. The reconciliation engine tries to merge
you with things that aren't you, your entity gets muddier, and the trust signal
you were trying to inflate deflates instead. I've seen exactly this produce a
measurable trust drop on a real site — the fix was deleting the junk entries, not
adding more.
How to model relationships correctly
The reason people abuse sameAs is usually that they're trying to express a
relationship — "this brand is part of that studio." sameAs is the wrong tool.
Use the relationship properties schema.org actually provides:
-
parentOrganization/subOrganizationfor a brand network. -
worksFor/founder/employeefor people-to-org. -
memberOf,brand,publisherwhere they fit.
Anchor both ends with a stable @id (e.g. https://example.com/#org) and point
the relationship at that @id. Now the graph is reciprocal and machine-readable
without a single misused sameAs.
A quick audit you can run today
Open your JSON-LD, find every sameAs array, and ask of each URL: is this a
profile of the exact entity this node describes? If the answer is "no, but it's
related," move it to a relationship property. If the answer is "no, it's a
mention/backlink/repo," delete it.
I keep a set of canonical structured-data references — the full sameAs pattern, the
relationship properties, and worked org-network examples — at
ThatDevPro's reference library. The
patterns are boring on purpose. Boring is what survives an algorithm update.
---
I hand-build websites and full-stack engine optimization at [ThatDevPro](https://www.thatdevpro.com/) and [ThatDeveloperGuy](https://thatdeveloperguy.com/) — a service-disabled veteran-owned studio in Cassville, Missouri.
Top comments (0)