Person Schema Generator
Content editors adding author bylines, SEO specialists connecting E-E-A-T signals to real people, and dev teams templating author markup across an article CMS all need the same thing: a Person node that names the human, points at their page and photo, and links out to profiles that describe them. This tool builds that node in your browser from the fields you actually fill, nests the employer and the street address as their own objects, and warns you when the result is too thin to carry weight. Output switches between graph and flat with one select, and the copy button hands you the finished block.
One or two sentences, written for readers rather than crawlers.
One URL per line. Only pages that describe this exact person.
Office address only. It becomes a PostalAddress.
One entry per line.
One entry per line. Topics they cover or handle.
Graph wraps the node in @graph. Flat puts the same properties beside @context.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Person",
"name": "Maya Okonkwo",
"alternateName": "M. Okonkwo",
"jobTitle": "Lead Site Reliability Engineer",
"url": "https://acme.dev/authors/maya-okonkwo",
"image": "https://acme.dev/authors/maya-okonkwo.jpg",
"description": "Maya Okonkwo runs platform reliability at Acme and has written about observability and on-call design for nine years.",
"sameAs": [
"https://www.linkedin.com/in/maya-okonkwo",
"https://github.com/mokonkwo",
"https://mastodon.social/@maya"
],
"worksFor": {
"@type": "Organization",
"name": "Acme Corp",
"url": "https://acme.dev"
},
"address": {
"@type": "PostalAddress",
"streetAddress": "114 Harbour Road, Cape Town"
},
"knowsLanguage": [
"English",
"Yoruba"
],
"knowsAbout": [
"Observability",
"Incident response",
"Kubernetes"
]
}
]
} How the Tool Builds and Checks Person Markup
The builder reads a field, trims it, and drops the key when you leave it empty, so a half-filled form still yields valid JSON-LD instead of rows of blank strings. sameAs, knowsLanguage, and knowsAbout arrive as one entry per line and are split on newlines, and sameAs lines that do not parse as http or https addresses are filtered out before the array is written. When the employer name is set, the tool nests an Organization built from name plus employer URL under worksFor, and a street address becomes a PostalAddress with streetAddress. Graph mode wraps the node in a @graph array under @context; flat mode spreads the same properties directly beside @context, and both forms describe the same entity.
A warning pass then runs over the raw input before anything is copied. A missing name is an error, and so are url, image, or sameAs values that are not full addresses. Warnings cover fewer than two profile links, a missing photo, and a missing description, while info rows note a public email address, an empty jobTitle and worksFor pair, and a sameAs list that is ready to publish. Each message is escaped and shown with a severity badge, and the JSON-LD below is rebuilt on the same event, so what you copy matches what was checked.
Where Person markup goes
Put the full node on the author page or the author archive, where it stands alone as the description of that person. Article pages should reference the same entity instead of redeclaring it: the author property points at a stable @id such as https://site/authors/jane-doe/#person, or repeats name, image, and sameAs values exactly as they appear on the author page. Keep one canonical Person per site. When a job title or a profile link changes, edit that single node and every article pointing at it follows.
Corroboration beats self-description
sameAs only helps when the linked page really is that person: a LinkedIn profile, a GitHub or Mastodon account, a Wikipedia entry, a staff directory. The photo should be a stable, indexable, roughly square file on a path you keep for years, because a broken image weakens the node at crawl time. Consistent names across those profiles matter more than a long property list, since a person spelled three different ways on three platforms is harder to match, not easier.
Before and after: a bare name versus a linked entity
The first block is what most author markup ships: a name and nothing else. It parses cleanly, yet no other page or property confirms who that person is. The second block adds a job title, a canonical page, a photo, three profile links, and an employer, which is what lets a crawler tie the byline back to pages outside your own site.
{
"@context": "https://schema.org",
"@type": "Person",
"name": "Jane Doe"
}{
"@context": "https://schema.org",
"@type": "Person",
"name": "Jane Doe",
"jobTitle": "Senior Editor",
"url": "https://example.com/authors/jane-doe",
"image": "https://example.com/authors/jane-doe.jpg",
"sameAs": ["https://linkedin.com/in/janedoe", "https://github.com/janedoe", "https://mastodon.social/@janedoe"],
"worksFor": { "@type": "Organization", "name": "Example Media" }
}Use Cases
| Who | Where it lands | What the markup does |
|---|---|---|
| Content editor writing an author bio | Author archive page | Publishes one Person node with name, jobTitle, photo, and sameAs links |
| SEO specialist mapping E-E-A-T signals | Article page with a byline | author resolves to the canonical Person through a shared @id |
| Dev team templating an article CMS | Reusable author component | Every post renders the same Person shape from stored author records |
Common Mistakes
- Declaring two different Person nodes for the same human. The archive lists one name and one set of profiles while the articles list another, and a crawler has no way to tell which copy is real.
- Pasting relative paths into url or image. A path such as /photos/jane.jpg has no host, so validators reject it; write the full https address instead.
- Listing every social account, including shared, abandoned, or team pages. Fifteen weak links dilute the two or three profiles that actually describe the person.
- Leaving image and description empty. A bare name with no photo and no bio gives the entity nothing to hold onto, and the warning box flags both before you copy.
- Shipping a personal email address or a home address. This output becomes public page source the moment the page is served, and it stays there in every cached copy.
- Copying the block into every template and editing it by hand. One stale job title later, two conflicting claims about the same person sit side by side on your own site.
Best Practices
- Give the Person a stable @id, for example https://site/authors/jane-doe/#person, and point every Article author property at that same id.
- Keep one canonical copy of each field: name, jobTitle, image, and sameAs should read the same on the byline, the author page, and the linked profiles.
- Choose two to five sameAs links that a stranger can confirm describe the same person in under a minute.
- Serve the photo from a permanent URL you control, roughly square and at least 300 pixels on each side, and keep the path across redesigns.
- Nest the employer through worksFor with an Organization name and URL, so the person and the company resolve as two linked nodes rather than one string.
- Re-run the warning box after a profile rename, a job change, or a site migration, then check the page again in the Rich Results Test.
Frequently Asked Questions
What is the difference between Person schema and Organization schema?
Person describes one human being, such as an author, a reviewer, or a named employee. Organization describes a company, publication, or nonprofit that keeps existing without any one person. The two fit together rather than compete: a Person names its employer through worksFor, and an Organization can list people through member or employee properties. Article pages usually need both, with the Organization as publisher and the Person as author, so the byline resolves to a real entity.
Where do I paste the Person JSON-LD on the page?
Place it in one script block of type application/ld+json, either in the page head or right after the article body. One copy per page is enough; on an author archive, declare it once on the archive instead of repeating it under every post. Do not ship two copies of the same Person on one page, since mismatched name or sameAs values leave crawlers unsure which node describes the human. If the page already carries Article markup, keep both nodes in one @graph so they can reference each other.
Does passing a validator mean I will get a rich result?
No. Validators such as the Rich Results Test and the schema.org validator check syntax, recognized properties, and required fields, and they only report that your markup parses. Person alone has no guaranteed rich result type, so a clean test means the entity data is well formed rather than a promise of extra search space. The real value of Person markup is entity clarity: it states who wrote the page and which outside profiles back up that claim. Treat a passing test as the baseline, then judge the rest by whether bylines and author pages match the node.
Which sameAs links belong in a Person node?
List pages that unambiguously describe that one person: a LinkedIn profile, a GitHub account, a Mastodon profile, a personal site author page, or a Wikipedia entry. Skip generic profile URLs shared by other people, vanity redirects that land on a homepage, and accounts you do not control, because a link to the wrong identity is worse than no link at all. Two to five strong links beat fifteen weak ones, since crawlers look at whether the pages agree on name, photo, and bio. Recheck these links after a profile rename or a platform move, and update the node when they change.
What image should I use for an author?
Use a direct URL you control that returns a real photo, roughly square, at least 300 by 300 pixels, and stable over time. A headshot on your own domain at a permanent path beats a signed CDN link that expires next week or a query-string URL that changes on every request. Relative paths such as /images/author.jpg fail validators, because the crawler needs a full http or https address. Keep the file reachable without a login and without a script that hides it from crawlers.
How do I link the author on Article pages?
Point the Article author property at the same Person node with @id, for example author: {"@id": "https://site/authors/x/#person"}, and give that Person node the same @id wherever you declare it. When your CMS cannot emit @id, repeat the same name, image, and sameAs array on the Article author object so the two descriptions clearly match. The goal is one resolvable entity: the byline, the author page, and the profile links should all resolve to the same person. Mixing a bare name on articles with a full Person node on the archive works against that.
Is it safe to include address, email, and telephone?
Business contact data is fine: a published office address, a general contact number, and a role inbox can go in without trouble. A home address, a personal mobile number, and a private mailbox should stay empty, because everything in this node ships as public page source that anyone can read. The email field triggers a note in the warning box for exactly that reason. When the person has not agreed to publish direct details, point url at a contact page instead.