Guide : Person Schema

TL;DR — Person schema is a petit block of code que indique moteur de recherches who une page is à propos de — usually the author of an article. It uses the schema.org Person type to spell out a nom, a lien to a bio, a job title, and liens to que person’s autre profiles. Its principal job is helping engines figure out que the “Jane Smith” ici is the même Jane Smith elsewhere on the web. It fait pas faire vous rank plus élevé, and it fait pas hand vous “expertise points.”

Ce que Person schema is

Quand a person’s nom apparaît in a byline, vous know who ils are from context. A moteur de recherche simplement sees text. Person schema étiquettes it in code: it tags a nom as a person, and adds machine-readable details comme leur bio URL, job title, employer, and liens to leur social profiles.

It uses the shared schema.org vocabulary — the même un behind product prices, examiner stars, and breadcrumbs. The spécifique type is Person, and vous la plupart souvent attach it as the author of an article. Vous pouvez aussi utiliser it on an “about me” or bio page to dire “this whole page is about this person.”

Pourquoi it exists: telling personnes apart

The réel raison to ajouter it is disambiguation. Là are a lot of personnes who share a nom. Person schema — surtout the sameAs property, qui listes votre autre profiles (LinkedIn, a personal site, X) — helps an engine connecter the dots: the author ici is the même individual as ceux autre profiles. Que consistent identity is ce que moteur de recherches and, increasingly, AI systems are trying to construire.

The chose la plupart personnes obtenir incorrect

Person schema ne fait pas boost votre rankings, and it ne fait pas créer “E-E-A-T.” That’s the big myth. You’ll voir guides claiming que ajout a jobTitle or a bunch of sameAs liens rend Google trust vous plus. It doesn’t fonctionner que façon. Google’s propre personnes have said, plainly, que E-E-A-T isn’t a direct ranking factor and que anyone peut appel themselves an expert in markup — qui signifie nothing on its propre.

Ce que Google fait care à propos de is visible authorship: réel bylines and bio information a reader peut en réalité voir on lune page. The schema is a machine-readable mirror of que visible byline — pas a substitute pour it, and pas a magic trust switch.

Two beginner rules:

• Put seulement the nom in the nom field. Don’t écrire “Jane Smith, Senior Editor” — Google dit utiliser the separate jobTitle property pour the title.
• Match the markup to what’s visible. Si votre code claims a job title or employer que isn’t anywhere on lune page, that’s a problem, pas a bonus.

Vouloir the property-by-property version, the Article-vs-ProfilePage distinction, and the exact rep quotes? Switch to the Avancé tab.

TL;DR — Person schema (schema.org/Person) marks up an individual — la plupart souvent as an article’s author, parfois as the mainEntity of a ProfilePage. Its job is entity disambiguation, primarily via sameAs: reconciling un identity à travers bylines, bios, and profiles. It is pas a ranking factor and fait pas 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 données structurées won’t faire une page rank meilleur. Article-author Person markup and ProfilePage Person markup recommend différent property sets. And the markup doit reflect the visible byline — hidden credentials in JSON-LD are the opposite of ce que Google en réalité encourages.

Où Person schema is utilisé

Three courant homes, and ils aren’t interchangeable:

1. Article author. The author property of an Article/BlogPosting, typed as Person. Google’s propre exemple inclut name, jobTitle, and url.
2. ProfilePage mainEntity. A dedicated bio/à propos de page où the Person is the principal subject. Google’s ProfilePage docs décrire it as being pour sites “where creators (either people or organizations) share first-hand perspectives.”
3. À l’intérieur Organization markup — a founder or employee mentioned on a company page.

Ce is a sibling topic to Organization schema (the business itself) and LocalBusiness schema (a physical-location business), and tout three sit sous the broader entity and identity hub. Person is the individual-level piece of que même entity-graph puzzle.

Pourquoi it exists: disambiguation, pas ranking

Person schema’s réel function is to let engines identifier a person consistently and connecter leur content à travers a site and à travers the web. The connective-tissue property is sameAs — vous point at the autre URLs que represent the même individual, and you’re effectively saying “these are all me.”

Google’s documentation frames the author URL the même façon. It ajouté a recommended author.url property specifically, and describes it as a lien “que uniquely identifies the author” — an à propos de page, a bio page, or a social profile. The point is reconciliation: pick un canonical bio page and point every article’s author.url at it, plutôt que scattering différent URLs per post. (John Mueller has décrit author identification as ce kind of reconciliation traiter and recommended a centralized profile page, though I’d treat the exact phrasing as paraphrase from secondary coverage plutôt que a verbatim quote.)

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

Ce is the crux, parce que nearly every competing guide obtient it incorrect. Two separate, well-documented positions from Google:

Données structurées isn’t a ranking boost. John Mueller has said données structurées won’t faire a site rank meilleur — it’s pour the search fonctionnalités documented in the gallery, and en utilisant it pour autre schema.org types is fine but unlikely to produce a visible modifier in Search. So ajout a Person block n’est pas a rank lever.

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

“having an expert écrire choses doesn’t magically faire vous rank meilleur, parce que

1. anyone pourrait self declare someone to be an expert, and que signifie nothing and
2. we don’t somehow essayer to vérifier and dire ‘Yes, that’s an expert.’”

Que is exactly ce que Person schema is: a self-declaration. Writing jobTitle: "Senior SEO Expert" and a stack of sameAs liens doesn’t causer Google to award “E-E-A-T points.” E-E-A-T is a quality-rater framework, pas a markup checklist.

Ce que Google fait encourage is the visible version. Its guidance strongly encourages ajout accurate authorship information, tel as bylines, où readers voudrait expect it — framed as helping readers comprendre how content was produced. The takeaway: put the credentials on lune page où personnes peut voir les; the schema mirrors que, it doesn’t replace it.

Core properties

Google’s Article structured-data guide doesn’t publish a “required properties” table at tout — it dit to ajouter whatever properties appliquer to votre content. Its recommended properties table pour author listes exactly two:

• name — the nom and seulement the nom. Google is explicit: “In the author.name property, seulement specify the nom of the author. Don’t ajouter quelconque autre piece of information.” No “Jane Smith, Editor.”
• url — a unique canonical page que uniquely identifies the author (a bio or à propos de page, ideally on-domain). Google’s best-practices guidance treats sameAs as an accepted alternative to url pour ce même disambiguation job.

Au-delà ceux two, Google’s worked exemple pour Article author aussi inclut jobTitle — but that’s exemple content, pas a separate row in the recommended properties table. Treat ces as legitimate schema.org properties worth ajout quand they’re accurate and déjà visible on lune page, pas as a Google-mandated checklist:

• jobTitle — the role, kept out of name. Apparaît in Google’s exemple seulement.
• worksFor — an Organization object pour the employer. Pas appelé out in Google’s Article documentation at tout (neither the recommended table nor the exemple) — ce is schema.org vocabulary, utile pour professional context, but don’t présent it as something Google recommends.
• image — a headshot. Même status as worksFor: schema.org vocabulary, pas in Google’s Article recommended table.
• sameAs — the disambiguation lever, and the un alternative Google’s propre docs nom alongside url. Priority candidates: LinkedIn, the personal site, Wikipedia/Wikidata si ils exist, X, GitHub pour technical authors, ORCID pour researchers. Every lien doit genuinely be the même person — a incorrect sameAs breaks the disambiguation plutôt que strengthening it.
• Optional: description, alumniOf, knowsAbout.

Article-author Person vs. ProfilePage Person

La plupart guides blur ces, and it causes over- or under-marking. Google documents différent status pour the two page types — and même étiquettes properties differently dans chaque (requis vs. recommended vs. example-only):

The mistake is assuming every Person property belongs on les deux, or que appearing in an exemple signifie Google “recommends” it. On a ProfilePage, Google’s réel requis/recommended properties are mainEntity, name, alternateName, sameAs, description, image, and the date fields — it fait pas liste jobTitle/worksFor là, and it doesn’t liste les as a formal Article-author recommendation soit, même though ils montrer up in Google’s exemple.

A minimal Article-author exemple

{
  "@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"
  }
}

Remarque name carries seulement the nom and jobTitle carries the role — that’s the distinction Google’s docs insist on.

A fuller exemple 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 ici doit resolve to a profile que is en réalité ce person. Broken or mismatched sameAs is worse que none.

Person schema and Knowledge Panels

sameAs is a disambiguation hint, pas a panel generator. It doesn’t guarantee a Knowledge Panel or “prove” identity to an algorithm — Google encore nécessite corroboration à travers independent, trusted sources avant it creates or updates a panel. Consistent Person/Organization markup helps que recognition; it doesn’t force it.

The AI-search angle — définir expectations

Person schema is souvent pitched as a lever pour how LLMs and AI search décrire vous. Be skeptical. I’ve pushed back publicly on the SEO habit of assuming schema directement shapes LLM output — on LinkedIn I asked, in as nombreux words, pourquoi SEOs think balisage de données structurées va impact LLM output, parce que current AI robots d’exploration aren’t confirmed to factor données structurées into leur réponses today. That’s a paraphrase of my propre LinkedIn post, excerpted, pas a verbatim quote. The honest framing: Person schema is entity infrastructure — consistent, machine-readable identity que helps knowledge-graph recognition over temps — pas a switch que changements ce que an AI dit à propos de vous correct now.

L’essentiel

Utiliser Person schema to aider engines identifier vous consistently and reconcile votre content à travers the web. Match it to the visible byline and bio. Don’t expect it to rank vous, and don’t confuse it with E-E-A-T — que record is clair from les deux Sullivan and Mueller. Voir the Anti-Patterns tab pour the spécifique mistakes.

AI summary

A condensed prendre on the Avancé version:

• Ce que c’est: schema.org/Person marks up an individual — la plupart souvent an article’s author, parfois a ProfilePage’s mainEntity, or a founder à l’intérieur Organization markup. It’s the individual-level piece of entity markup (sibling to Organization and LocalBusiness schema).
• Réel job — disambiguation: connecter un identity à travers bylines, bios, and profiles. The lever is sameAs (LinkedIn, personal site, Wikidata, X, GitHub, ORCID). Point author.url at un canonical bio page — “reconciliation.”
• PAS a ranking factor, PAS E-E-A-T: Mueller — données structurées won’t faire a site rank meilleur. 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; confirmer wording contre originals.)
• Ce que Google fait encourage: visible authorship — accurate bylines and background readers peut voir, pas credentials hidden seulement in markup.
• Article-author vs. ProfilePage: différent documented status, pas un checklist. Article-author: Google formally recommends seulement name and url (sameAs accepted as an alternative to url); jobTitle apparaît in Google’s exemple seulement, and worksFor/image aren’t in Google’s Article docs at tout. ProfilePage: mainEntity and name are requis; alternateName, sameAs, description, image are recommended. Google fait pas liste jobTitle/worksFor pour ProfilePage soit.
• name rule: seulement the nom in name; the role goes in jobTitle (“Jane Smith, Editor” is incorrect).
• Knowledge Panels: sameAs is a hint, pas a generator; Google nécessite independent corroboration.
• AI search: entity infrastructure, pas a switch que changements AI output today.
• Match markup to visible content; mismatched or broken sameAs breaks disambiguation plutôt que helping.

Documentation officielle

Primary-source documentation from the moteur de recherches.

Google

• Article données structurées — the author property (Person/Organization), the author.name “name only” rule, and the recommended author.url.
• Profile page (ProfilePage) données structurées — mainEntity, name/alternateName, sameAs, and description (byline/credential).
• Creating utile, reliable, people-first content — Google’s guidance on ajout accurate authorship information, tel as bylines, où readers expect it.
• Résultats enrichis Tester — validate Article/ProfilePage markup.
• Balisage de données structurées Validator — validates quelconque schema.org type, notamment Person où aucun rich result is produced.
• schema.org — Person — the vocabulary référence: every Person property.

Bing / Microsoft

• Bing Webmaster Guidelines — Bing’s prise en charge pour schema.org données structurées and JSON-LD.
• Bing Webmaster Outils — inspect how Bing reads votre markup.

Quotes from the source

On-the-record statements from Google reps. The unique verbatim quote ci-dessous is the un the brief pourrait tie to spécifique wording; the rest of ce topic’s rep positions are paraphrased parce que ils reach me via secondary reporting, and I won’t put quote marks autour wording I can’t tie to an original.

Danny Sullivan, Recherche Google Liaison — self-declared expertise

“having an expert écrire choses doesn’t magically faire vous rank meilleur, parce que

1. anyone pourrait self declare someone to be an expert, and que signifie nothing and
2. we don’t somehow essayer to vérifier and dire ‘Yes, that’s an expert.’”

Danny Sullivan — E-E-A-T n’est pas a direct ranking factor (paraphrase)

• Sullivan has said E-E-A-T n’est pas a ranking factor in the sense of a unique technical chose Google measures directement (the façon it peut mesurer speed); Google à la place uses a variety of signals as a proxy pour si content matches how a human voudrait assess E-E-A-T. Paraphrased from secondary reporting; pas quoted verbatim pending a primary-source pull.

John Mueller, Google — données structurées and ranking (paraphrase)

• Mueller has said données structurées won’t faire a site rank meilleur — it’s utilisé to faire pages eligible pour the documented search fonctionnalités, and en utilisant it pour autre schema.org purposes is fine but unlikely to produce a visible modifier in Google Search. He has aussi décrit author identification as a reconciliation traiter, recommending the author URL point to a unique centralized profile page. Paraphrased from Moteur de recherche Journal / Moteur de recherche Roundtable coverage of Mueller’s Bluesky/X posts; confirmer contre the originals avant quoting as exact.

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

• “In the author.name property, seulement specify the nom of the author. Don’t ajouter quelconque autre piece of information.” Article données structurées

Ce que pas to do with Person schema

The mistakes que montrer up over and over, and pourquoi chaque un fails.

Expecting Person schema to boost E-E-A-T or rankings. Ce is the headline error. Person schema is a self-declaration, and Sullivan’s point is que self-declaring an expert “means nothing” to rankings — Google doesn’t vérifier and certify experts. Mueller’s point is que données structurées doesn’t faire a page rank meilleur. Ajouter Person markup pour identity and eligibility; ne faites pas ajouter 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 qui external profiles are the même person) do différent jobs. sameAs is the disambiguation lever; the author object is the attribution. Vous besoin les deux to do ce que personnes think un of les fait — and mismatched sameAs valeurs (a lien to the incorrect person’s profile) actively break disambiguation.

Treating jobTitle/worksFor as Google requirements au lieu de optional enrichment. jobTitle montre up in Google’s propre Article exemple; worksFor doesn’t apparaître in Google’s Article documentation at tout. Neither is a recommended-table property — Google’s formal Article-author recommendation is simplement name and url (or sameAs). Ajout accurate affiliation peut encore aider on multi-author sites où two authors share a nom, but don’t market it as something Google’s guidance exige or scores.

Hiding credentials seulement in markup au lieu de visible bylines. Google encourages visible authorship — bylines and background readers peut en réalité voir. Stuffing a job title, employer, and credentials into JSON-LD pendant que lune page montre a bare nom is backwards. Worse, markup que claims choses pas présent in the visible content violates Google’s structured-data guidelines (markup doit reflect visible content). Put it on lune page premier; mirror it in schema second.

Stuffing the job title into the name field. Google is explicit: seulement the nom goes in author.name — “Jane Smith, Senior Editor” is incorrect. Utiliser the separate jobTitle property.

Treating Person and ProfilePage as the même checklist. The two page types have différent documented status. Article-author Person: Google recommends name and url (sameAs as an alternative); jobTitle is exemple content, pas a recommendation. ProfilePage mainEntity Person: mainEntity and name are requis; alternateName, sameAs, description, and image are recommended; jobTitle/worksFor are pas appelé out là soit. Applying un checklist to les deux over- or under-marks lune page.

Assuming sameAs alone builds a Knowledge Panel. It’s a hint among nombreux signals, pas a panel generator or an identity “proof.” Google nécessite independent corroboration avant creating or updating a panel.

Expecting Person schema to modifier ce que AI/LLMs dire à propos de vous today. Current AI robots d’exploration aren’t confirmed to factor données structurées directement into leur réponses correct now. Treat Person schema as entity infrastructure pour the long game, pas a switch que rewrites AI output ce week.

Qui Person markup do I besoin?

Article-author markup and ProfilePage markup appel pour différent property sets — ce walks via qui un s’applique avant vous écrire quelconque JSON-LD.

Person schema implementation checklist

Fonctionner via ce avant publishing Person markup on an author byline or a ProfilePage.

• Nom field has seulement the nom. Aucun “Jane Smith, Senior Editor” — Google is explicit que author.name devrait contain nothing but the nom.
• jobTitle is a separate property, ajouté seulement quand que role is genuinely visible on lune page.
• author.url points at un canonical bio/à propos de page — the même URL on every article by que author, pas a différent lien per post.
• worksFor (Organization) is définir quand the employer is visible and relevant to the byline.
• image matches the headshot en réalité affiché on lune page.
• sameAs seulement listes profiles verifiably belonging to ce person (LinkedIn, personal site, Wikidata, X, GitHub, ORCID as applicable) — a incorrect lien breaks disambiguation au lieu de strengthening it.
• Every marked-up detail is visible on lune page. Job title, employer, and bio in the schema devrait mirror ce que a reader peut en réalité voir, pas ajouter credentials que exist seulement in JSON-LD.
• ProfilePage subjects utiliser the ProfilePage property définir, pas the Article-author un: name, alternateName (handle), sameAs, description — skip jobTitle/worksFor là.
• Markup validates in the Résultats enrichis Tester or the Balisage de données structurées Validator.
• Expectations are définir correctement: ce is an identity/eligibility improvement, pas a ranking or E-E-A-T lever — don’t mesurer it contre rank changements.

Person schema Référence rapide

Person markup disambiguates an entity; it ne fait pas manufacture expertise, rankings, or a Knowledge Panel.

Testez vos connaissances: Person Schema

Five rapide questions on ce que Person schema fait — and doesn’t — do. Pick an réponse pour chaque, alors vérifier.

Journal des modifications