What matters
- Create one main fact list before you make JSON-LD.
- Give key people and groups stable IDs and connect pages to them.
- Every key schema fact should be public and easy to support.
- Outside sources are proof. sameAs links only show a connection.
Start with a fact list
Before you write JSON-LD, list the public facts that must match. Include the main name, other names, current role, group, role dates, place, degrees, contact details, verified profiles, services, and key work.
For each fact, save its source link, owner, check date, safe words, and claim limits. Fix conflicts on public pages first. Schema cannot fix two bios that disagree.
Here is a compact matched example from this site:
| Visible fact | Matching JSON-LD field |
|---|---|
| Bob Bodily | Person.name |
| Co-Founder and CTO at SageCreek AI | Person.jobTitle and organization link |
| Bob’s LinkedIn, GitHub, and Google Scholar records | Person.sameAs links |
The visible About page is the human record. The JSON-LD repeats those facts for software. Neither record proves that Bob is the best consultant.
Use stable identifiers
A small graph can reuse identifiers such as:
https://example.com/#person
https://example.com/#organization
https://example.com/#website
https://example.com/article/#webpage
https://example.com/article/#articleA page can name the person as its subject. An article can name that person as its author. The site can name the person or group as its publisher. Reusing one ID is clearer than making many copies with different facts.
Match the visible page
If JSON-LD lists a degree, job, service, price, or place, readers should be able to check it. Put it on the page or link to a clear source. Do not add reviews, awards, offices, or results only to impress a machine.
Google’s schema rules explain who may get a search feature. They do not promise one or a rank. False schema can cost the feature or lead to a manual action.
Connect, then corroborate
sameAs can connect a person to a verified LinkedIn, GitHub, scholar, or company page. This helps tools know which person you mean. It does not make every claim on those pages true.
Stronger proof comes from outside sources that own their claims. Examples include a school record, reviewed paper, client case, trusted interview, event program, or public code project.
Choose types that match the page
| Page | Useful vocabulary | Boundary |
|---|---|---|
| Biography | ProfilePage, Person |
Degrees and roles must be public and current |
| Article | Article, WebPage, Person author |
Dates and author URL must match the page |
| Case study | Article, named subject, proof links |
Schema does not prove what caused the result |
| Consulting page | Service, Organization, Offer when exact |
A service area does not prove there is a local office |
| Navigation | BreadcrumbList |
Match the links people can see |
| Dataset | Dataset when real data is public |
Do not label a text summary as a data file |
Use the clearest correct type. Do not add types just to have more schema.
Validate three ways
- Test the JSON as code and check every linked ID.
- Compare each key field with the page and main fact list.
- Use each platform’s test tool. A pass does not predict rank.
For Google-supported search features, use the Rich Results Test. For general Schema.org syntax and vocabulary, use the Schema.org validator. Then compare the output with the visible page and your entity fact register.
Run these checks in each live build. Schema made from one set of content data is easier to keep in sync than code copied into each page.
Sources
- Structured data general guidelines, Google Search Central
- Profile page structured data, Google Search Central
- Person, Schema.org