Person Schema: The Full Property Guide

Person schema is how you tell a search engine or AI system that a real, identifiable individual — not an anonymous byline string — is behind a piece of content. As structured data, done properly it's the technical foundation of E-E-A-T signals a machine can actually verify. Done as a bare name field with nothing else, it's barely more useful than plain text.

This guide covers the properties that matter, how Person schema connects to Organization and Article schema, and the specific pattern that turns a Person block from a decorative addition into a verifiable identity.

A byline that just says a name as a text string on a page tells a reader who wrote it, but tells a search engine or AI system nothing verifiable — the name could belong to anyone, or no one real at all. Person schema, implemented with a stable @id and a real sameAs array, changes that: it connects the name on the page to a specific, externally verifiable identity with a professional history a search engine can independently check. That verification step is exactly what underpins machine-readable E-E-A-T — expertise and trust a system can confirm rather than simply take on faith from the page's own claims about itself.

name should match exactly how the individual is identified elsewhere — their LinkedIn profile, other bylines, speaker bios. Inconsistent name variants (with or without a middle name, different capitalization, a nickname on one platform and a full name on another) create the same disambiguation problem inconsistent organization names do.

url typically points at a personal site, an About page, or an author bio page — somewhere with more context than the schema itself provides.

image should be a real photo, ideally as a full ImageObject with dimensions, not a placeholder or generic avatar — stock or placeholder images undermine the same verification the schema is meant to support.

jobTitle should be specific and accurate — "Technical SEO Consultant" tells a system something concrete; "Digital Marketing Professional" tells it almost nothing.

worksFor should reference the Organization by @id rather than repeating an inline Organization object, connecting the Person to the Organization node the same way every other cross-referenced schema type should.

sameAs is where Person schema earns its value. It's an array of URLs to the individual's verified profiles elsewhere on the web — LinkedIn, a verified X/Twitter account, published bylines on other authoritative sites, Crunchbase, speaker profiles from real conferences, a Wikipedia or Wikidata entry if one exists. Each URL in that array is a claim a search engine can independently verify: does this LinkedIn profile actually exist, does it actually describe the same person, does it corroborate the expertise the page is claiming.

A sparse or fabricated sameAs array does active harm rather than nothing — a link to a dead profile, a mismatched name, or someone else's account is a disambiguation failure a system can detect, and it undermines trust in the rest of the schema on the page. Only include URLs you can personally verify are live, correctly named, and actually about the same individual.

The pattern that turns isolated schema blocks into a real entity graph: give the Person a stable @id (typically a URL fragment like https://example.com/#person), reference that same @id from every Article's author property instead of repeating an inline Person object, and reference the same Organization @id from the Person's worksFor property. This is the exact @id and @graph pattern that applies across schema generally — one canonical Person node, referenced everywhere the individual is credited, rather than the same facts duplicated with drift-prone inline copies scattered across every article.

knowsAbout is an underused property that lists the subjects or concepts the person has genuine expertise in, ideally as Thing entities linked to Wikipedia or Wikidata rather than bare strings. This is one of the more direct ways to hand a search engine or AI system an explicit expertise signal rather than leaving it to infer subject-matter authority from content alone — particularly valuable for individual practitioners whose expertise might otherwise only be evident from reading a large volume of their published work.

A person schema generator or general schema markup generator can produce a syntactically valid starting template quickly, and there's no harm in using one to avoid hand-typing JSON-LD structure from scratch. But generic schema generator tools — the same kind used for an article schema generator or an event schema generator — tend to produce isolated, disconnected output: a Person block with no @id, no sameAs array prompt, and no awareness that it should be referenced from an Article's author property rather than duplicated. Structured data produced this way passes basic validation and still fails at the actual job Person schema is meant to do, which is disambiguation through connection, not just syntactically correct markup sitting in isolation. Use a generator for the skeleton if it saves time, then manually add the @id, the full sameAs array, and the cross-references to Organization and Article schema before treating it as finished.

Person schema alone doesn't generate a rich snippet the way Product or Review schema can — there's no dedicated "Person rich result" in the way there's a star-rating rich result. Its value shows up indirectly: correctly connected Person schema markup is one of the inputs that can support Article rich results, Knowledge Panel eligibility for the individual, and AI Overview and AI system citation confidence. Don't implement Person schema expecting a standalone visual result in the SERP — implement it for what it actually contributes: verifiable identity data other structured data and other systems can build on.

Sites with more than one contributing author need one Person node per author, each with its own @id, rather than a single generic "staff" or "editorial team" Person block covering everyone. A shared generic author entity defeats the disambiguation purpose entirely — it tells a system nothing about who specifically wrote what, which is precisely the information Person schema exists to provide. Where content genuinely has no individual named author (a company blog post written collectively, for instance), it's more honest to omit a Person author and use only Organization as the author than to invent a fictional named author for schema's sake.

The most frequent error is a Person block with name and little else — no sameAs, no @id, no connection to the Article or Organization it's meant to support. A close second is duplicating a full inline Person object on every article by the same author instead of referencing one @id, which both bloats every page's markup and creates the same drift risk covered in Organization schema. Using a stock photo or no image at all is a smaller but real issue — image is one of the fields most likely to render directly in a search result or Knowledge Panel-style feature, and a missing or generic one undercuts the verification the rest of the schema is trying to establish.

Run any page carrying Person schema through the Schema.org validator and Google's Rich Results Test, then manually click through every sameAs URL to confirm it resolves to a live, correctly-attributed profile. As with Organization schema, this is a type that's easy to get syntactically correct and factually wrong — automated validation only catches the first kind of error.