Person JSON-LD Across Domains: One Stable ID?

Yes, you can reuse one stable ID for a person across multiple domains in JSON-LD, but the ID itself must be a globally unique, absolute URL (or a sameAs reference) that you control or that resolves to a canonical profile. Simply repeating the same string in different places does not make it a stable ID; the value must be a dereferenceable URI that consistently identifies the same person.

Background: Why Person IDs Matter in Structured Data

JSON-LD (JavaScript Object Notation for Linked Data) is a standard format for expressing entities and their relationships in machine-readable form. Search engines, knowledge graphs, and content aggregators use it to understand who is who on the web. Without a stable identifier, the same person might be treated as multiple distinct entities across different sites, fragmenting their online presence and diluting the authority of their profiles.

The core problem is entity resolution: when a crawler sees “John Smith” on three different domains, it needs a way to know they are the same person. A stable ID provides that link. The @id property in JSON-LD is the standard mechanism for this, and it should be an absolute IRI (usually an HTTPS URL) that uniquely names the person.

How JSON-LD Person IDs Work

In JSON-LD, you can define a person like this:

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/profiles/alice",
  "name": "Alice Johnson",
  "url": "https://example.com/alice"
}

The @id is the canonical identifier. When another domain wants to reference Alice, they can use the same @id value, or they can use a sameAs property to point to that canonical URL. For example, a blog post on a different site might include:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/profiles/alice"
  }
}

This tells the crawler that the author of the post is the same entity as the one on example.com. The key is that the ID must be a URL that actually resolves to a page describing that person (or at least a stable reference), not a random string like “alice123”.

How to Choose a Stable ID Strategy

There are several approaches, each with trade-offs:

• Own a dedicated profile page – Create a page on your own domain (e.g., https://yourdomain.com/people/alice) and use that URL as the @id. This is the most reliable because you control the content and can ensure it stays available.
• Use an existing authoritative URL – If the person has a well-known profile (e.g., a Wikipedia page, a professional network profile), you can use that URL as the ID. However, you don’t control it, and it might change.
• Use a hash or UUID in a URL – Some systems use a URL like https://yourdomain.com/person/9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d. This is stable but not human-readable; it works as long as the URL resolves.
• Use sameAs instead of @id – You can keep your own local ID (e.g., a database primary key) but include a sameAs property that points to a canonical URL. This is useful when you cannot change your internal system.

Whatever you choose, the ID must be:

• Globally unique (not just within one domain).
• Stable over time (don’t change it unless absolutely necessary).
• Dereferenceable (ideally, it returns a 200 OK with a page describing the person).
• Consistent across all your own pages and across any third-party pages that reference the person.

Common Problems and Misconceptions

Misconception: You can just use the person’s name as the ID. No – names are not unique. Even full names with middle names can collide. The ID must be a URI, not a plain string.

Problem: The ID URL changes. If you move your website or change your URL structure, all the @id references break. Use a redirect (301) to point the old URL to the new one, or better, use a domain you control for the long term.

Problem: The ID does not resolve. If you use @id with a URL that returns a 404, search engines may not trust it. They might still parse the JSON-LD, but the entity resolution is weaker.

Misconception: You must use the same @id on every page. Actually, you should use the same canonical ID for the same person, but you can also include additional sameAs properties to link to other profiles. For example, a person might have an @id on your site, but also a sameAs to their Twitter and LinkedIn.

Comparison with Other Identity Systems

JSON-LD’s @id is similar to other identity systems but has its own nuances:

• Schema.org url property – This is just the person’s website, not necessarily a canonical identifier. It can be used in conjunction with @id but is not a substitute.
• ORCID iD – A persistent digital identifier for researchers. You can use an ORCID URL as the @id for a researcher, which is excellent because it is globally unique and stable.
• DOI for publications – Similar concept, but for documents, not people.
• Facebook / Twitter / LinkedIn URLs – These are often used as sameAs values, but they are not ideal as @id because they are not under your control and can be taken down.

For most practical purposes, a URL on your own domain is the best choice for @id, because it is both stable and controllable.

Practical Implementation Tips

When implementing across multiple domains, follow these steps:

1. Decide on a canonical domain (e.g., profiles.example.com) that will host the person profiles.
2. Create a page for each person at a stable URL, e.g., https://profiles.example.com/alice.
3. On every page that references the person, use that URL as the @id in the JSON-LD.
4. If you need to use a different ID internally, add a sameAs property pointing to the canonical URL.
5. Ensure the canonical URL returns a 200 status and includes the person’s basic info (name, image, etc.) in HTML and/or JSON-LD.
6. Monitor your site for broken links or changes in URL structure.

Also consider using @id in combination with @type and other properties to fully describe the person. For example, include givenName, familyName, jobTitle, and affiliation to help disambiguate.

Frequently Asked Questions

Q: Can I use a relative URL as the @id?
No. The @id must be an absolute IRI (usually a full URL starting with http or https). Relative URLs are resolved against the document base, which can lead to different IDs on different pages.

Q: What if the person has no website? Can I still use a stable ID?
Yes. You can create a profile page on your own domain, even if it’s minimal. Alternatively, you can use a third-party profile URL (like a social media page) as the ID, but that is less reliable. The ID does not have to be the person’s own website; it just needs to be a stable reference.

Q: Does Google require a specific format for Person @id?
Google’s documentation does not mandate a specific format, but they recommend using a URL that is unique and stable. They also support sameAs for linking to other profiles. There is no special syntax beyond standard JSON-LD.

Q: Can I use the same @id for two different people?
No. That would merge them into one entity in a knowledge graph, which can cause serious errors. Each person must have a unique @id.

Q: What is the difference between @id and url in a Person schema?
The @id is the canonical identifier for the entity, while url is the person’s own website (which could be different). They often point to the same URL, but not always. For example, a person might have a personal blog at alice.example.com, but the canonical ID might be profiles.example.com/alice.

Q: How do I test if my JSON-LD is correctly using the stable ID?
You can use Google’s Rich Results Test or the Schema.org validator. These tools will show you how the entity is parsed and whether the @id is recognized. Also, you can check if the URL returns a valid response and contains the expected content.

Related

• Cheap Mechanical Keyboards: What to Know Before Buying
• 1Password vs Keeper: Which Password Manager Wins?
• Midnight Blizzard Breach: Why Identity Trust Failed