iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Use the same stable, absolute IRI as the @id for a person wherever your sites describe that same person. Put identity-bearing profile links—such as an appropriate ORCID record—in sameAs. The two properties do different jobs: @id identifies the Person node in your data; sameAs links to reference pages that identify that person.
What do @id and sameAs mean for a person?
JSON-LD uses @id to identify a node with an IRI or a blank node identifier. The W3C JSON-LD 1.1 Recommendation explains that it is used to “uniquely identify things that are being described in the document.” In a cross-domain setup, a shared absolute IRI lets your markup refer to the same Person node on each site. W3C: JSON-LD 1.1, Node Identifiers.
A JSON-LD context maps compact terms such as name and sameAs to vocabulary IRIs. The @id value is the node’s identifier; it is not automatically the page URL or an external identity profile. You may deliberately choose a profile URL as the identifier, but make that choice with persistence and meaning in mind.
Free tools Windows power users keep installed
One-click scans. No signup required.
Schema.org’s Person type describes a person and is equivalent to foaf:Person. Its sameAs property means a URL for a reference page that unambiguously indicates the item’s identity. That makes an authoritative profile a possible sameAs value, not a substitute for reusing the Person node’s @id. Schema.org: Person · Schema.org: sameAs.
How should you choose a portable Person identifier?
For properties you control, choose one persistent, absolute IRI that identifies the person—not merely a role, organization, or individual page. A useful approach is to use a stable identity domain and publish an identity page at the chosen URL if you can. For example, the following IRI is illustrative only:
https://identity.example/people/jane-doe#personThe fragment identifier is permitted; there is no required Schema.org URL pattern. What matters for cross-domain reuse is that the complete IRI remains identical wherever you describe that person. Consider these factors before settling on it:
- Persistence: Can you keep the IRI stable through a redesign, CMS replacement, or domain migration?
- Control and access: Can you maintain the identifier and, ideally, provide a useful identity page there? JSON-LD notes that dereferencing an IRI can let applications retrieve more information; that does not make a retrievable page a universal requirement.
- Specificity: Does the identifier refer to the individual rather than an author role, team, or page that might later change?
- Evidence: Do any external profiles you add genuinely and unambiguously refer to this person?
- Scope: Is each external identity system appropriate for this person and use case?
What does the markup look like across domains?
This example uses fictional values. Replace them with accurate information, and use the exact same @id in the Person node on each site describing this person.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://identity.example/people/jane-doe#person",
"name": "Jane Doe",
"url": "https://www.example.com/about/jane-doe",
"sameAs": [
"https://orcid.org/0000-0000-0000-0000",
"https://www.linkedin.com/in/jane-doe/"
]
}The shared identifier belongs to the Person node. The url property points to a page about the person, while sameAs lists external identity references. Use only references that actually identify the same individual. A page on each domain may include the full Person node, or refer to it by the shared identifier where appropriate; in either case, the structured data must accurately reflect that page’s visible content.
Rank #3
Why is #person alone not portable?
A fragment is interpreted relative to a base IRI. As a result, a local identifier such as #person on https://site-a.example/article resolves to a different full IRI than #person on https://site-b.example/article. Reusing the same fragment text across different hostnames does not, by itself, identify one global Person node.
Likewise, a homepage or social-profile URL can technically be used as an IRI, but that does not automatically make it a good long-term node identifier. If you choose one, ensure you control its stability and that it identifies the intended person rather than just a changeable profile page.
Should you use ORCID or another profile in sameAs?
Use an external identity page when it is authoritative and clearly refers to the person you describe. ORCID is especially relevant for researchers. Google Search Central’s dataset documentation specifically recommends an ORCID ID in Person.sameAs to uniquely identify individual dataset creators. That is guidance for dataset documentation; it does not establish a requirement to add ORCID to every author page. Google Search Central: Dataset structured data.
Recommended Free Tools
A publisher-controlled IRI and an ORCID record are not interchangeable options: the publisher-controlled IRI identifies your Person node, while an ORCID URL can serve as an external identity reference in sameAs. Other official profiles may be suitable when they identify the same individual, but do not turn sameAs into a loose list of related sites.
Best Value
How do you maintain the identifier during a site migration?
- Choose and record the canonical Person IRI. Confirm that it is absolute, identifies the individual, and can remain stable independently of the site’s page URLs.
- Use the same value on every controlled domain. Check the complete
@id, not just its fragment or final path segment. - Keep identity references accurate. Verify names, affiliations, profile URLs, and any
sameAsdestinations against the person’s real identity. - Preserve the identity page where possible. If the site or identity domain moves, retain ownership and redirect the old URL appropriately rather than silently replacing the identifier across properties.
- Audit after deployment. Inspect representative pages on each domain for changes in the Person IRI, profile links, or claims that the page’s visible content does not support.
What does a shared Person @id not guarantee?
Structured data expresses facts and relationships; it is not proof that those claims are true. Consistent identifiers can support interoperable linked data, but the cited guidance does not show that reusing a Person @id forces Google or another search engine to merge entities, create a Knowledge Panel, or improve rankings. Google’s ORCID recommendation is specific to identifying dataset creators, not a promise of a search outcome.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
