Person Schema Markup: What Google's Docs Actually Say

Type "person schema markup" into a dozen SEO blogs and you'll read the same two promises. Add a Person block, and Google rewards you with a Knowledge Panel. Add sameAs links to your social profiles, and you've built E-E-A-T. Neither claim shows up in Google's own documentation. What does show up is narrower and less exciting. Google documents three specific places where it reads Person data, one definition of sameAs that has nothing to do with knowledge panels, and a content guideline that recommends visible bylines, not JSON-LD. This is what Person schema actually does, checked against Google's current docs instead of the folklore stacked on top of them. The general point that markup makes a feature possible, not guaranteed applies here too, but Person schema has a sharper problem: for its two most-repeated benefits, there's no documented mechanism to be eligible for at all.

Where Person schema is actually consumed

There's no standalone Person rich result, and if you've gone searching Search Central for a page called "Person structured data" the way there's one for Article or Product, you're wasting your time: it doesn't exist. No Search feature is documented as triggered by a bare Person object on its own. Wherever you use Person data, it plays a supporting role inside something else.

Start with authorship, since it's the case you'll hit most often. Google's Article structured data documentation, last updated September 8, 2026, says plainly: "Use the Person type for people, and the Organization type for organizations," and recommends author.name plus author.url (or sameAs as an alternative) so Google can understand who wrote the piece. If you're adding a byline to a blog post, a BlogPosting with an author property pointing at a Person block, name plus URL, is the most common way you'll use Person schema.

ProfilePage comes second, and it's the type to reach for if your site runs individual author pages or staff bios. Google's ProfilePage structured data documentation, same update date, defines mainEntity as "the person or organization that this profile page is about," using Person or Organization. It's built for the page where you're sharing one creator's first-hand perspective: an author page, a reviewer profile, a staff bio you maintain yourself.

Embedding rounds out the list. Schema.org's Organization vocabulary lets founder, employee, legalRepresentative, funder, and sponsor all take a Person value, and that part is real and works. Google's own Organization structured data documentation never mentions founder at all, though: schema.org lets you nest a person inside an organization's founder property, but Google's guide has never once said it does anything with that property once it's there. Don't count on it showing up anywhere you can see.

The Knowledge Panel myth, corrected

If you've been told that stacking sameAs links onto a Person object earns you a Knowledge Panel, you can stop looking for the mechanism: there isn't one. Google's Organization docs define sameAs in a single sentence: "The URL of a page on another website with additional information about your organization, if applicable." That's the whole definition. It's a pointer, not a trigger.

Check your own Person block against that definition before you add another URL to it. Every sameAs entry should answer one question: does this link tell Google more about who this person is? Pad the list with directories or aggregator pages just because they exist, and you're not building a stronger entity. You're building a longer array that does the same job as one well-chosen link.

Picture yourself building a Person block with sameAs pointing at LinkedIn, Crunchbase, GitHub, and a personal site, every URL correct and matching the same name. That's reasonable groundwork for entity disambiguation: more signals for Google to connect you across the web. It's still not a documented switch that produces a Knowledge Panel. Panels are Google's own editorial call, built from signals nobody outside Google has published in full, and your Person schema block is at most one input among many, never a guaranteed one.

Does Person schema help E-E-A-T?

Ask Google directly and you get a clearer answer than most SEO advice gives you. Its Creating Helpful, Reliable, People-First Content documentation, updated December 10, 2025, discusses E-E-A-T at length and recommends content that includes "clear information about the author... such as links to an author page." Search the whole page for the word "schema" and you'll come up empty. It never mentions schema, structured data, or JSON-LD. Not once.

Sit with that for a second: the recommendation is for visible, human-readable authorship, not a script tag. If your author bio is something a reader can actually see and click, a name, a role, a link to more about that person, you're already meeting the guidance Google wrote. If that same information sits only inside a <script type="application/ld+json"> block, invisible on the page itself, you're not, because the page itself never says that content came from anyone.

You'll see the same pattern in a different rich-result myth already covered here: claims widen the longer nobody checks the source. Structured data being unrelated to rankings isn't a guess either, so don't expect an exception for Person. Google's General Structured Data Guidelines, updated July 10, 2026, state that markup "enables a feature to be present, it does not guarantee that it will be present." John Mueller put it more bluntly in April 2025: "Structured data won't make your site rank better," reported by Search Engine Journal. Person schema gets no carve-out.

What's actually worth doing

None of this makes Person schema pointless. It makes it a narrower, more mechanical job than most guides describe: tell Google, in a format it can parse, who wrote or founded or works for something, using exactly the properties the three documented consumption points above actually read.

Our Person Schema Generator implements a deliberately small field set, matching what the documented use cases actually need rather than the full schema.org spec:

Schema.org's full Person type has far more properties than this, knowsAbout and hasCredential among them. Schema.org will happily let you declare all of it; Google's Search features have never once asked. The generator leaves those extra fields out rather than pad a form with properties that don't move anything Google reads.

Two rules separate markup that does its job from markup that just sits there. Point sameAs at accounts you actually control, a real LinkedIn or GitHub profile, not an aspirational list assembled to look thorough. And put a visible byline on the page first: for a small site with one or two writers, "Written by [Name], [role]" linking to an author page already satisfies Google's helpful-content guidance. Person schema earns its place once that author has a BlogPosting, a ProfilePage, or a spot in an Organization's founder or employee list, built with our Organization Schema Generator.

Run the finished JSON-LD through our free Schema Validator before publishing: the same syntax check that catches a missing bracket regardless of which schema type produced it.

Frequently asked questions