sameAs: The Most Underrated Line in Your Markup

Most Person schema in the wild is a name, a job title and a URL. The property that does the actual heavy lifting, the one that merges your fragmented online presence into a single machine-readable identity, is usually missing or filled with junk.

What does the sameAs property actually do?

The official schema.org definition is precise: sameAs is the "URL of a reference Web page that unambiguously indicates the item's identity." Translated out of standards language: it is a machine-readable claim that the entity described on this page and the entity described at that URL are one and the same thing.

To understand why that claim matters, you need to understand the problem engines face. A crawler encounters your name on your site, on LinkedIn, in a podcast show-notes page, in a conference speaker list, and in an old guest post. Nothing in raw HTML says these mentions belong to one person. The engine has to perform entity resolution: a probabilistic merge, where it weighs name similarity, bio overlap, mutual links and co-occurring facts, then decides how confident it is that these fragments are one entity.

sameAs converts part of that guesswork into a declaration. Instead of the engine inferring "this website's author is probably the same person as this LinkedIn profile," the site states it outright, in a vocabulary the engine was built to parse. The engine still verifies, because anyone can claim anything in markup. But a declared, verifiable identity link is a very different input than a statistical hunch.

Why one line carries this much weight

Three mechanisms stack on top of each other.

1. It collapses ambiguity

Every professional exists as multiple weakly-connected profiles until something binds them. We covered the fragmentation problem in depth in Structure Your Identity for Machines: a signal the engine cannot attribute to one identity is a signal that does not count. sameAs is the single cheapest instrument for that binding. It is the difference between five profiles that might be you and five profiles that declare themselves to be you.

2. It compounds confidence

Entity resolution is not binary. Engines hold confidence scores. When your site says "this person is the same as this LinkedIn profile," and that LinkedIn profile links back to your site, and both carry the same name form and the same one-line bio, each corroboration raises the score. High confidence is what lets an engine attach a fact it found in one place to the entity it shows in another. Low confidence makes it hedge, and hedging engines do not recommend people.

3. It routes attribution

Say a respected industry publication profiles you. That mention is a trust signal, the kind we broke down in The Network Signal. But the signal only pays if the engine attributes the profiled person to your entity. A well-built sameAs array is the routing table that makes third-party proof land on your name instead of evaporating into an unresolved mention.

What belongs in your sameAs array?

Not everything with your name on it. Think in three tiers, ordered by how much identity weight each URL carries.

Tier 1: canonical identifiers

• Wikidata item, if one exists for you. It is the closest thing the open web has to a person registry, and engines consume it directly.
• Wikipedia article, if you genuinely have one. Never link someone else's.
• Registry-grade profiles for your field: ORCID for researchers, IMDb for film work, Crunchbase for founders, a bar or medical register profile where public.

Tier 2: major active profiles

• LinkedIn, the profile most engines cross-check first for professionals.
• X, GitHub, YouTube, Instagram, whichever you actually maintain, with a bio that matches your canonical story.

Tier 3: authored presence

• Author archive pages on publications where you have a byline.
• Speaker pages on conference sites, podcast host or guest pages with a stable URL, book listings under your author name.

Before any URL enters the array, run it through this five-point quality checklist:

1. Public. The page is readable without login. A crawler that hits an auth wall verifies nothing.
2. Stable. The URL has not changed in the last year and is not likely to. Dead sameAs links are contradictions waiting to happen.
3. Exclusive. The page is about you alone, not a shared team page or a multi-author archive without your own segment.
4. Consistent. The name form and title on the page match your canonical form. A profile under a nickname weakens the merge instead of strengthening it.
5. Alive or intentionally archival. Either you maintain it, or it documents something finished, like a book. Abandoned half-profiles with stale bios belong in cleanup, not markup.

What to leave out

The failure mode is stuffing. People paste every directory listing, every dormant social account, every scraped aggregator profile into the array, on the theory that more is more. It is not. Every URL in sameAs is a claim the engine may verify, and every claim that fails verification, a dead page, a mismatched name, a bio contradicting your site, taxes the confidence you were trying to build. Leave out login-walled pages, shared accounts, profiles you have not touched in years and cannot be bothered to fix, and any auto-generated aggregator page you do not control. If a page would embarrass you in a due-diligence check, it will not help you in an entity check.

Where does sameAs go, and how do you verify it?

The property lives inside your Person schema, which belongs on the page that canonically describes you: usually your about page, often mirrored on your homepage. A minimal illustrative shape looks like this:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "Alex Rivera",
  "jobTitle": "Independent Pricing Strategist",
  "url": "https://alexrivera.example.com",
  "sameAs": [
    "https://www.linkedin.com/in/alexrivera",
    "https://www.wikidata.org/wiki/Q00000000",
    "https://industryjournal.example.com/author/alex-rivera"
  ]
}

Then verify, in this order. First, run the page through the schema.org validator to confirm the JSON-LD parses and the Person entity carries the array. Second, check Google's structured data documentation for how it treats the markup: Google states plainly that structured data helps it understand the content and entities on a page, which is exactly the job here. Third, close the loop manually: open every profile you listed and make sure its website field or bio points back to your canonical domain. sameAs is formally one-directional, but engines corroborate from both ends, and a bidirectional link is far harder to fake than a one-way claim.

The four failure patterns we see in real markup

Audit enough personal sites and the same sameAs mistakes repeat with almost mechanical regularity. Worth naming them, because each one is cheap to fix and expensive to keep.

1. The empty array. Person schema exists, name and jobTitle filled, sameAs absent entirely. The site asserts an identity but connects it to nothing, so the entity floats alone. This is the most common state on the web and the easiest upgrade available.
2. The Organization graft. The consultant's about page carries Organization schema for their one-person company, with the social profiles hung off the business entity instead of the human. Engines dutifully build a company node while the person, the thing buyers actually ask about, stays unstructured. If you sell as a person, you need a Person entity, with the Organization related to it through worksFor, not substituting for it.
3. The alias mix. The array points to a Twitter handle under a nickname, a LinkedIn under the full legal name, and a byline page under a hyphenated variant. Each URL is genuinely yours, but the surface evidence disagrees, so the declaration fights itself. Fix the profiles first, then declare them.
4. The one-way street. A clean array pointing at profiles whose bios mention no website at all. Nothing contradicts the claim, but nothing corroborates it either, and unverifiable claims earn the weakest weighting an engine can assign.

One more placement note: your about page is not the only host. Wherever your articles carry Article or BlogPosting schema, the author property can hold the same Person entity, id-referenced or repeated, which quietly stamps every piece of content with your consolidated identity. That is how a body of work accrues to a single node instead of scattering across orphaned author strings.

Does sameAs matter for AI engines, or just Google?

Honest answer: no AI engine publishes its weighting for any markup, so nobody can promise you a citation because of a schema property. But the mechanism argues for it anyway. Assistants that browse or retrieve pull from search indexes built by crawlers that read structured data. Models trained on web crawls ingest pages where your identity is either coherent or scattered. And the knowledge graphs that ground factual answers about people, which we take apart in Knowledge Graphs: How Machines Connect Facts About People, are assembled by exactly the kind of entity resolution sameAs feeds. You are not optimizing for one algorithm. You are building consistency infrastructure that every doorway into an AI answer happens to pass through.

Remember the layer this work lives on. SEO ranks pages, GEO promotes brands, PEO names you, and naming requires the engine to know, with high confidence, which single entity your name refers to. sameAs is the property most directly aimed at that requirement, which is why it is strange how often it ships empty.

The thirty-minute implementation

1. List every URL that describes you online. Score each against the five-point checklist above.
2. Fix or retire the failures: update stale bios, standardize your name form, delete what you will never maintain.
3. Write the Person schema on your about page with the survivors in sameAs. Ten clean URLs is a strong array. Six is fine.
4. Add your canonical site URL to every listed profile.
5. Validate, then recheck quarterly. Profiles move, publications restructure archives, and a sameAs array full of redirects ages badly.

If you want the full markup picture beyond this one property, the complete field-by-field walkthrough lives in Person Schema: The Complete JSON-LD Guide for Your Name. And if you would rather have the whole identity layer engineered for you, that is literally what our services exist to do.