Person schema is the machine readable version of your bio: a block of structured data on your home page that says this page is about a person, here is who they are, and here are the other pages that are about the same person. Done right, it is a single node with a stable address that your media kit, your company's site, Wikidata and every interview can point at. Done the usual way, it is a half filled template that names you twice and links to nothing.
This post is about what goes in it. The web's secret graph explains why it exists, and JSON-LD, explained with one example you can copy shows the syntax.
The identifier comes first
Every Person node needs an @id, a permanent address for the node itself, not for the page. The convention is your home page address plus a fragment: https://yourdomain.com/#person, or a slug like #janedoe. It never changes, even if you redesign the site. It is what your media kit's WebPage points at as its main entity, what your company's site uses when it names you as founder, and what a Wikidata entry can reference. Pick it once.
The properties that do the work
| Property | What to put | Why it matters |
|---|---|---|
| name | Your one exact name form | The same string must appear everywhere, including the title tag, the h1 and the footer |
| alternateName, additionalName | Maiden name, middle name, the form on a book cover | Lets the machine connect variants to you without you using them |
| description | One plain sentence that disambiguates | "Founder of X, based in Y, author of Z" beats "visionary leader" |
| image | The headshot file, with width and height | The photo you use on every profile, so the panel picks it |
| jobTitle, worksFor | Current role and an Organization node | worksFor links to an entity, not a string |
| alumniOf | Each school as an Organization, with its own identifier where it has one | Education is one of the first attributes panels show |
| birthPlace, nationality, homeLocation | As Place and Country entries | Only if the home page states them in prose; schema cannot cite what the page does not say |
| knowsAbout | Three to five subjects | Supports the expertise signal; do not list twenty |
| sameAs | Every profile you control | See below |
| identifier | Knowledge Graph ID and Wikidata Q number, once they exist | Tells Google and Wikidata you know which entity you are |
Every Organization you reference gets its own node, with its own @id, on your domain if you do not own the company and on the company's domain if you do. Google wants a raster logo on Organization nodes, so a PNG, not an SVG.
sameAs, the line that matters most
sameAs is a list of other pages that are about the same thing as this node. For a person it is how the machine learns that your LinkedIn, your X account, your YouTube channel, your Crunchbase entry, your author page and your Wikidata item are one human.
Rules that save trouble:
- Only pages that are about you. Your company's site is not about you; it is worksFor. A podcast you appeared on is not about you; it is an appearance.
- Only profiles you control or that are unambiguously yours. A directory listing someone else created with your name on it does not belong, because you cannot guarantee it stays accurate.
- Full canonical addresses, with https and without tracking parameters.
- Every address must resolve. A dead link in sameAs is a wrong fact about you.
- The same list, in substance, on every page that references you, so there is nothing for the machine to reconcile.
Working through a real set of decisions
The table tells you what the properties are. The decisions come when your life does not fit neatly into them.
You have changed your name. Use the current form as name, the former as alternateName, and make sure any work published under the former name is attached to you in schema (a Book node with author pointing at your @id) and in prose. The machine will not connect "Julie Davis Tittenhofer" on a book cover to "Julie Anne Davis" unless something tells it to.
You have two companies. Each gets an Organization node. The one with its own website gets its @id on that domain; the one without gets a node on yours. Your Person has worksFor for the primary role and a second relationship, such as founder, from each Organization back to you. Do not list a company you merely advise under worksFor; put that in the prose and, if you must, under affiliation.
You were born somewhere you would rather not advertise. Leave it out. Schema should carry what the page states and nothing the page does not; privacy is a reason to leave a fact off the page, and the schema follows.
You have credentials. They go after the name in prose (Jane Doe, MD) and in a property such as hasCredential if you want to be thorough, never inside the name string. A name with letters bolted on is a different string from the one on your LinkedIn.
You share a name with someone. Lean on description: one sentence that says the field, the city and the company. Lean on sameAs: every profile you can claim. The more typed, consistent evidence attaches to your identifier, the easier the resolution.
A checklist of what breaks it
- Two Person nodes on one domain. The commonest error and the most damaging.
- An @id that changes with each redesign, so every external reference now points at nothing.
- sameAs entries that go to a login wall, a 404, or someone else's profile with your name.
- worksFor pointing at a string rather than an Organization node.
- Facts in schema that the page does not state in prose, which the machine treats as unsupported.
- A photo in image that is not the photo on your profiles, so the panel picks a different one.
- A template's default Organization or WebSite block left in place alongside yours, describing a different thing.
- dateModified never updated, which tells the machine the page is stale even when it is not.
One node per site
The most common error is two Person blocks on one domain: one the template added to the home page, one the media kit template added to its own page. To the machine that is two people with the same name on one site, which is exactly the duplicate signal you are trying to kill.
The rule is one Person node, on the home page. The media kit carries a WebPage node whose mainEntity is the home page's Person @id, plus an ImageObject for the headshot download. The press page, the speaking page, the writing page: all WebPage, all pointing at the one node. None of them repeats the biography.
How to test it without being a developer
Paste your home page address into Google's Rich Results Test and read the parsed items, not the verdict. You are looking for exactly one Person, with the @id you chose, and no errors. Then paste the address of your media kit and confirm it shows a WebPage whose mainEntity is that same @id and no Person of its own. Then open the Schema Markup Validator at validator.schema.org, which is stricter about the vocabulary, and fix anything it flags in red; yellow warnings about optional properties can be ignored. Finally, in Search Console, check the page is indexed and that no structured data errors appear under Enhancements over the following weeks. Ten minutes a quarter keeps it honest.
Checklist
- One @id, decided once. https://yourdomain.com/#person or a slug. Written down where the next person to touch the site will find it.
- Name in one form, with variants declared. name, alternateName, additionalName. Credentials after the name, never inside it.
- Facts in prose first, then in schema. Birthplace, education, roles. If the page does not say it, the schema does not either.
- Organizations as nodes, with raster logos. Current employer, former employers, schools, your own companies on their own domains.
- sameAs complete and clean. Every profile you control, full addresses, every one resolving.
- Every other page points at the node. WebPage with mainEntity. No second Person anywhere on the domain.
- Identifiers added when they exist. Knowledge Graph ID and Wikidata Q, as identifier PropertyValue entries.