Person Schema

TL;DR — Person schema is a small block of code that tells search engines who a page is about — usually the author of an article. It uses the schema.org Person type to spell out a name, a link to a bio, a job title, and links to that person’s other profiles. Its main job is helping engines figure out that the “Jane Smith” here is the same Jane Smith elsewhere on the web. It does not make you rank higher, and it does not hand you “expertise points.”

What Person schema is

When a person’s name appears in a byline, you know who they are from context. A search engine just sees text. Person schema labels it in code: it tags a name as a person, and adds machine-readable details like their bio URL, job title, employer, and links to their social profiles.

It uses the shared schema.org vocabulary — the same one behind product prices, review stars, and breadcrumbs. The specific type is Person, and you most often attach it as the author of an article. You can also use it on an “about me” or bio page to say “this whole page is about this person.”

Why it exists: telling people apart

The real reason to add it is disambiguation. There are a lot of people who share a name. Person schema — especially the sameAs property, which lists your other profiles (LinkedIn, a personal site, X) — helps an engine connect the dots: the author here is the same individual as those other profiles. That consistent identity is what search engines and, increasingly, AI systems are trying to build.

The thing most people get wrong

Person schema does not boost your rankings, and it does not create “E-E-A-T.” That’s the big myth. You’ll see guides claiming that adding a jobTitle or a bunch of sameAs links makes Google trust you more. It doesn’t work that way. Google’s own people have said, plainly, that E-E-A-T isn’t a direct ranking factor and that anyone can call themselves an expert in markup — which means nothing on its own.

What Google does care about is visible authorship: real bylines and bio information a reader can actually see on the page. The schema is a machine-readable mirror of that visible byline — not a substitute for it, and not a magic trust switch.

Two beginner rules:

• Put only the name in the name field. Don’t write “Jane Smith, Senior Editor” — Google says use the separate jobTitle property for the title.
• Match the markup to what’s visible. If your code claims a job title or employer that isn’t anywhere on the page, that’s a problem, not a bonus.

Want the property-by-property version, the Article-vs-ProfilePage distinction, and the exact rep quotes? Switch to the Advanced tab.

TL;DR — Person schema (schema.org/Person) marks up an individual — most often as an article’s author, sometimes as the mainEntity of a ProfilePage. Its job is entity disambiguation, primarily through sameAs: reconciling one identity across bylines, bios, and profiles. It is not a ranking factor and does not confer E-E-A-T — Sullivan has said E-E-A-T isn’t a direct ranking factor and self-declaring an expert “means nothing,” and Mueller has said structured data won’t make a page rank better. Article-author Person markup and ProfilePage Person markup recommend different property sets. And the markup must reflect the visible byline — hidden credentials in JSON-LD are the opposite of what Google actually encourages.

Where Person schema is used

Three common homes, and they aren’t interchangeable:

1. Article author. The author property of an Article/BlogPosting, typed as Person. Google’s own example includes name, jobTitle, and url.
2. ProfilePage mainEntity. A dedicated bio/about page where the Person is the primary subject. Google’s ProfilePage docs describe it as being for sites “where creators (either people or organizations) share first-hand perspectives.”
3. Inside Organization markup — a founder or employee mentioned on a company page.

This is a sibling topic to Organization schema (the business itself) and LocalBusiness schema (a physical-location business), and all three sit under the broader entity and identity hub. Person is the individual-level piece of that same entity-graph puzzle.

Why it exists: disambiguation, not ranking

Person schema’s real function is to let engines identify a person consistently and connect their content across a site and across the web. The connective-tissue property is sameAs — you point at the other URLs that represent the same individual, and you’re effectively saying “these are all me.”

Google’s documentation frames the author URL the same way. It added a recommended author.url property specifically, and describes it as a link “that uniquely identifies the author” — an about page, a bio page, or a social profile. The point is reconciliation: pick one canonical bio page and point every article’s author.url at it, rather than scattering different URLs per post. (John Mueller has described author identification as this kind of reconciliation process and recommended a centralized profile page, though I’d treat the exact phrasing as paraphrase from secondary coverage rather than a verbatim quote.)

The record: it’s not a ranking factor, and it’s not E-E-A-T

This is the crux, because nearly every competing guide gets it wrong. Two separate, well-documented positions from Google:

Structured data isn’t a ranking boost. John Mueller has said structured data won’t make a site rank better — it’s for the search features documented in the gallery, and using it for other schema.org types is fine but unlikely to produce a visible change in Search. So adding a Person block is not a rank lever.

E-E-A-T isn’t a direct ranking factor — and self-declared expertise means nothing. Danny Sullivan, Google’s Search Liaison, put it directly:

“having an expert write things doesn’t magically make you rank better, because

1. anyone could self declare someone to be an expert, and that means nothing and
2. we don’t somehow try to check and say ‘Yes, that’s an expert.’”

That is exactly what Person schema is: a self-declaration. Writing jobTitle: "Senior SEO Expert" and a stack of sameAs links doesn’t cause Google to award “E-E-A-T points.” E-E-A-T is a quality-rater framework, not a markup checklist.

What Google does encourage is the visible version. Its guidance strongly encourages adding accurate authorship information, such as bylines, where readers would expect it — framed as helping readers understand how content was produced. The takeaway: put the credentials on the page where people can see them; the schema mirrors that, it doesn’t replace it.

Core properties

Google’s Article structured-data guide doesn’t publish a “required properties” table at all — it says to add whatever properties apply to your content. Its recommended properties table for author lists exactly two:

• name — the name and only the name. Google is explicit: “In the author.name property, only specify the name of the author. Don’t add any other piece of information.” No “Jane Smith, Editor.”
• url — a single canonical page that uniquely identifies the author (a bio or about page, ideally on-domain). Google’s best-practices guidance treats sameAs as an accepted alternative to url for this same disambiguation job.

Beyond those two, Google’s worked example for Article author also includes jobTitle — but that’s example content, not a separate row in the recommended properties table. Treat these as legitimate schema.org properties worth adding when they’re accurate and already visible on the page, not as a Google-mandated checklist:

• jobTitle — the role, kept out of name. Appears in Google’s example only.
• worksFor — an Organization object for the employer. Not called out in Google’s Article documentation at all (neither the recommended table nor the example) — this is schema.org vocabulary, useful for professional context, but don’t present it as something Google recommends.
• image — a headshot. Same status as worksFor: schema.org vocabulary, not in Google’s Article recommended table.
• sameAs — the disambiguation lever, and the one alternative Google’s own docs name alongside url. Priority candidates: LinkedIn, the personal site, Wikipedia/Wikidata if they exist, X, GitHub for technical authors, ORCID for researchers. Every link must genuinely be the same person — a wrong sameAs breaks the disambiguation rather than strengthening it.
• Optional: description, alumniOf, knowsAbout.

Article-author Person vs. ProfilePage Person

Most guides blur these, and it causes over- or under-marking. Google documents different status for the two page types — and even labels properties differently within each (required vs. recommended vs. example-only):

The mistake is assuming every Person property belongs on both, or that appearing in an example means Google “recommends” it. On a ProfilePage, Google’s actual required/recommended properties are mainEntity, name, alternateName, sameAs, description, image, and the date fields — it does not list jobTitle/worksFor there, and it doesn’t list them as a formal Article-author recommendation either, even though they show up in Google’s example.

A minimal Article-author example

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How search engines crawl the web",
  "author": {
    "@type": "Person",
    "name": "Willow Lane",
    "jobTitle": "Journalist",
    "url": "https://www.example.com/staff/willow-lane"
  }
}

Note name carries only the name and jobTitle carries the role — that’s the distinction Google’s docs insist on.

A fuller example with affiliation and sameAs

{
  "@type": "Person",
  "name": "Willow Lane",
  "jobTitle": "Senior Journalist",
  "url": "https://www.example.com/staff/willow-lane",
  "image": "https://www.example.com/img/willow-lane.jpg",
  "worksFor": {
    "@type": "Organization",
    "name": "Example Media",
    "url": "https://www.example.com/"
  },
  "sameAs": [
    "https://www.linkedin.com/in/willowlane",
    "https://x.com/willowlane",
    "https://www.wikidata.org/wiki/Q00000000"
  ]
}

Every sameAs here must resolve to a profile that is actually this person. Broken or mismatched sameAs is worse than none.

Person schema and Knowledge Panels

sameAs is a disambiguation hint, not a panel generator. It doesn’t guarantee a Knowledge Panel or “prove” identity to an algorithm — Google still needs corroboration across independent, trusted sources before it creates or updates a panel. Consistent Person/Organization markup helps that recognition; it doesn’t force it.

The AI-search angle — set expectations

Person schema is often pitched as a lever for how LLMs and AI search describe you. Be skeptical. I’ve pushed back publicly on the SEO habit of assuming schema directly shapes LLM output — on LinkedIn I asked, in as many words, why SEOs think schema markup will impact LLM output, because current AI crawlers aren’t confirmed to factor structured data into their answers today. That’s a paraphrase of my own LinkedIn post, excerpted, not a verbatim quote. The honest framing: Person schema is entity infrastructure — consistent, machine-readable identity that helps knowledge-graph recognition over time — not a switch that changes what an AI says about you right now.

The bottom line

Use Person schema to help engines identify you consistently and reconcile your content across the web. Match it to the visible byline and bio. Don’t expect it to rank you, and don’t confuse it with E-E-A-T — that record is clear from both Sullivan and Mueller. See the Anti-Patterns tab for the specific mistakes.

AI summary

A condensed take on the Advanced version:

• What it is: schema.org/Person marks up an individual — most often an article’s author, sometimes a ProfilePage’s mainEntity, or a founder inside Organization markup. It’s the individual-level piece of entity markup (sibling to Organization and LocalBusiness schema).
• Real job — disambiguation: connect one identity across bylines, bios, and profiles. The lever is sameAs (LinkedIn, personal site, Wikidata, X, GitHub, ORCID). Point author.url at one canonical bio page — “reconciliation.”
• NOT a ranking factor, NOT E-E-A-T: Mueller — structured data won’t make a site rank better. Sullivan — E-E-A-T isn’t a direct ranking factor; self-declaring an expert “means nothing.” Person schema is a self-declaration, so it can’t award “expertise.” (Rep quotes are via reputable secondary reporting; confirm wording against originals.)
• What Google does encourage: visible authorship — accurate bylines and background readers can see, not credentials hidden only in markup.
• Article-author vs. ProfilePage: different documented status, not one checklist. Article-author: Google formally recommends only name and url (sameAs accepted as an alternative to url); jobTitle appears in Google’s example only, and worksFor/image aren’t in Google’s Article docs at all. ProfilePage: mainEntity and name are required; alternateName, sameAs, description, image are recommended. Google does not list jobTitle/worksFor for ProfilePage either.
• name rule: only the name in name; the role goes in jobTitle (“Jane Smith, Editor” is wrong).
• Knowledge Panels: sameAs is a hint, not a generator; Google needs independent corroboration.
• AI search: entity infrastructure, not a switch that changes AI output today.
• Match markup to visible content; mismatched or broken sameAs breaks disambiguation rather than helping.

Official documentation

Primary-source documentation from the search engines.

Google

• Article structured data — the author property (Person/Organization), the author.name “name only” rule, and the recommended author.url.
• Profile page (ProfilePage) structured data — mainEntity, name/alternateName, sameAs, and description (byline/credential).
• Creating helpful, reliable, people-first content — Google’s guidance on adding accurate authorship information, such as bylines, where readers expect it.
• Rich Results Test — validate Article/ProfilePage markup.
• Schema Markup Validator — validates any schema.org type, including Person where no rich result is produced.
• schema.org — Person — the vocabulary reference: every Person property.

Bing / Microsoft

• Bing Webmaster Guidelines — Bing’s support for schema.org structured data and JSON-LD.
• Bing Webmaster Tools — inspect how Bing reads your markup.

Quotes from the source

On-the-record statements from Google reps. The single verbatim quote below is the one the brief could tie to specific wording; the rest of this topic’s rep positions are paraphrased because they reach me through secondary reporting, and I won’t put quote marks around wording I can’t tie to an original.

Danny Sullivan, Google Search Liaison — self-declared expertise

“having an expert write things doesn’t magically make you rank better, because

1. anyone could self declare someone to be an expert, and that means nothing and
2. we don’t somehow try to check and say ‘Yes, that’s an expert.’”

Danny Sullivan — E-E-A-T is not a direct ranking factor (paraphrase)

• Sullivan has said E-E-A-T is not a ranking factor in the sense of a single technical thing Google measures directly (the way it can measure speed); Google instead uses a variety of signals as a proxy for whether content matches how a human would assess E-E-A-T. Paraphrased from secondary reporting; not quoted verbatim pending a primary-source pull.

John Mueller, Google — structured data and ranking (paraphrase)

• Mueller has said structured data won’t make a site rank better — it’s used to make pages eligible for the documented search features, and using it for other schema.org purposes is fine but unlikely to produce a visible change in Google Search. He has also described author identification as a reconciliation process, recommending the author URL point to a single centralized profile page. Paraphrased from Search Engine Journal / Search Engine Roundtable coverage of Mueller’s Bluesky/X posts; confirm against the originals before quoting as exact.

Google docs — the author.name restriction (from Google’s live docs)

• “In the author.name property, only specify the name of the author. Don’t add any other piece of information.” Article structured data

What not to do with Person schema

The mistakes that show up over and over, and why each one fails.

Expecting Person schema to boost E-E-A-T or rankings. This is the headline error. Person schema is a self-declaration, and Sullivan’s point is that self-declaring an expert “means nothing” to rankings — Google doesn’t check and certify experts. Mueller’s point is that structured data doesn’t make a page rank better. Add Person markup for identity and eligibility; do not add it expecting a rank lift or “E-E-A-T points.”

Confusing author markup with sameAs profile-linking. author (attributing an article to a person) and sameAs (declaring which external profiles are the same person) do different jobs. sameAs is the disambiguation lever; the author object is the attribution. You need both to do what people think one of them does — and mismatched sameAs values (a link to the wrong person’s profile) actively break disambiguation.

Treating jobTitle/worksFor as Google requirements instead of optional enrichment. jobTitle shows up in Google’s own Article example; worksFor doesn’t appear in Google’s Article documentation at all. Neither is a recommended-table property — Google’s formal Article-author recommendation is just name and url (or sameAs). Adding accurate affiliation can still help on multi-author sites where two authors share a name, but don’t market it as something Google’s guidance requires or scores.

Hiding credentials only in markup instead of visible bylines. Google encourages visible authorship — bylines and background readers can actually see. Stuffing a job title, employer, and credentials into JSON-LD while the page shows a bare name is backwards. Worse, markup that claims things not present in the visible content violates Google’s structured-data guidelines (markup must reflect visible content). Put it on the page first; mirror it in schema second.

Stuffing the job title into the name field. Google is explicit: only the name goes in author.name — “Jane Smith, Senior Editor” is wrong. Use the separate jobTitle property.

Treating Person and ProfilePage as the same checklist. The two page types have different documented status. Article-author Person: Google recommends name and url (sameAs as an alternative); jobTitle is example content, not a recommendation. ProfilePage mainEntity Person: mainEntity and name are required; alternateName, sameAs, description, and image are recommended; jobTitle/worksFor are not called out there either. Applying one checklist to both over- or under-marks the page.

Assuming sameAs alone builds a Knowledge Panel. It’s a hint among many signals, not a panel generator or an identity “proof.” Google needs independent corroboration before creating or updating a panel.

Expecting Person schema to change what AI/LLMs say about you today. Current AI crawlers aren’t confirmed to factor structured data directly into their answers right now. Treat Person schema as entity infrastructure for the long game, not a switch that rewrites AI output this week.

Which Person markup do I need?

Article-author markup and ProfilePage markup call for different property sets — this walks through which one applies before you write any JSON-LD.

Person schema implementation checklist

Work through this before publishing Person markup on an author byline or a ProfilePage.

• Name field has only the name. No “Jane Smith, Senior Editor” — Google is explicit that author.name should contain nothing but the name.
• jobTitle is a separate property, added only when that role is genuinely visible on the page.
• author.url points at one canonical bio/about page — the same URL on every article by that author, not a different link per post.
• worksFor (Organization) is set when the employer is visible and relevant to the byline.
• image matches the headshot actually shown on the page.
• sameAs only lists profiles verifiably belonging to this person (LinkedIn, personal site, Wikidata, X, GitHub, ORCID as applicable) — a wrong link breaks disambiguation instead of strengthening it.
• Every marked-up detail is visible on the page. Job title, employer, and bio in the schema should mirror what a reader can actually see, not add credentials that exist only in JSON-LD.
• ProfilePage subjects use the ProfilePage property set, not the Article-author one: name, alternateName (handle), sameAs, description — skip jobTitle/worksFor there.
• Markup validates in the Rich Results Test or the Schema Markup Validator.
• Expectations are set correctly: this is an identity/eligibility improvement, not a ranking or E-E-A-T lever — don’t measure it against rank changes.

Person schema quick reference

Person markup disambiguates an entity; it does not manufacture expertise, rankings, or a Knowledge Panel.

Test yourself: Person Schema

Five quick questions on what Person schema does — and doesn’t — do. Pick an answer for each, then check.

Person Schema

Person schema (schema.org/Person) is structured data that marks up an individual — most often an article's author, but also founders, staff, or the subject of a bio page. It helps search engines disambiguate which person an identity refers to and connect their content across the web; it is not a ranking factor and doesn't itself confer E-E-A-T.

Related: Schema Markup, Entity & Identity Schema, Organization Schema, LocalBusiness Schema

Person Schema

Person schema is the schema.org/Person structured-data type you use to mark up an individual — usually as JSON-LD. Its most common home is the author property on an article ("@type": "Person"), but it also describes founders, staff bios, or the subject of an about page (as the mainEntity of a ProfilePage). Core properties are name, url, image, jobTitle, worksFor (an Organization), and sameAs (links to other profiles that represent the same person), with optional description, alumniOf, and knowsAbout.

Think of it as a machine-readable version of a byline and bio. Its real job is entity disambiguation — helping Google, Bing, and AI crawlers recognize that the “Jane Smith” who wrote this piece is the same “Jane Smith” behind a LinkedIn profile, a personal site, and other bylines, and to reconcile that identity across the web. Google recommends pointing author.url at a single canonical bio page, and says to put only the name in author.name (use the separate jobTitle property for a title).

Person schema is not a ranking factor and does not itself create or prove E-E-A-T. Google’s Danny Sullivan has said E-E-A-T is not a direct ranking factor and that self-declared expertise “means nothing” to rankings; John Mueller has said structured data won’t make a page rank better. What Google does encourage is visible authorship — accurate bylines and background readers can actually see — not credentials hidden only in markup.

Related: Schema Markup, Entity & Identity Schema, Organization Schema, LocalBusiness Schema

Changelog