If you publish under your own name across more than one domain, you have probably run into this: your personal site, your company site, your GitHub, and the three articles you wrote on other platforms all describe the same human being, and nothing in the markup says so. Each page ships its own Person object. Each one is an island.
Search engines and, increasingly, LLM-based answer systems have to decide whether those islands are one person or five. Left to guess, they often guess wrong, especially if your name is common or you publish in more than one language. Mine is Allan Oliveira, which in Brazil is roughly the local equivalent of John Smith, and I publish in both Portuguese and English. So I had a reason to solve this properly.
There is a cheap structural fix: give the entity one stable @id and reference it from everywhere. Below is the exact setup I run, with real values.
This is the part people get wrong first. In JSON-LD, @id is an IRI that identifies a node. It is not required to resolve to anything. Nothing fetches it.
What it does is let consumers of your markup merge nodes. Two Person objects on two different domains with the same @id are, by the rules of the data model, the same node. Their properties combine into one description.
So the @id should be: Stable. You will never change it. Not when you redesign, not when you migrate frameworks. On a domain you control. Preferably the one you consider the canonical home of the entity. Fragment-based. Use a fragment so it never collides with an actual page URL.
That string is now the permanent name of the entity. Everything else references it.
On the home domain, publish the full description once. I put it in the root layout so it ships on every page.
sameAs means "is the same entity", and people abuse it. Every URL in that array has to be a page representing you, not a page about you and not something you made. A profile qualifies. An article about you does not, that is subjectOf. A paper you wrote does not, that is authorship. I had a deposited PDF sitting in my sameAs for a while, which is just wrong: the record is a document, I am a person. Moving it out and modeling it as authorship instead is strictly more correct and strictly more informative.
Not all sameAs entries are equal. A persistent identifier from an institution that verified something about you, like an ORCID iD or a DOI-bearing record, is a stronger disambiguation signal than another social profile, because those namespaces enforce uniqueness and are widely referenced. Social profiles confirm the handle, not the person. Put the identifiers first, and mirror the important ones into identifier with a PropertyValue so the ID is machine-readable as an ID and not just as a link.
alternateName is the honest home for a title or a nickname. If you go by something other than your legal name, that is the property. Do not stuff it into name and do not invent a jobTitle out of it.
knowsAbout is where you declare topical scope. It is one of the few places you get to state, in machine-readable form, what your entity is about rather than what it is. Keep it to things you can actually evidence with published work.
description should read like a sentence someone would quote. Write it as a standalone claim with the name in subject position. If an extractive system pulls one sentence about you, this is the one you want it pulling.
Work you produced belongs in the graph as work, linked to you as author. Here is a deposited document of mine, modeled correctly:
The author reference is the whole point. The document node and the person node are different entities with a stated relationship between them, which is more information than jamming the URL into sameAs and hoping something infers the rest.
On every other domain you control, do not repeat the whole thing. Publish a minimal node with the same @id plus whatever that domain uniquely adds.
The @id match means this node merges into the canonical one instead of creating a competing Person. The url pointing back at the home domain reinforces which property is the entity's primary web presence.
The subjectOf says: this article, on this other domain, is about that entity. That is the part that turns a scattered mention into a structured claim. Do it in both directions. The article carries about pointing at the person @id, and the person node carries subjectOf pointing at the article. One-directional works, bidirectional is unambiguous.