Person Schema
How to implement schema.org/Person for authors and profiles, which properties Google recommends, and why it disambiguates identity rather than boosting E-E-A-T or rankings.
Person schema (schema.org/Person) marks up an individual — most often an article's author, sometimes the subject of a ProfilePage. Its real job is entity disambiguation: helping Google, and increasingly AI crawlers, recognize that the byline here is the same person as your LinkedIn, personal site, and other bylines, via the sameAs property. It is not a ranking factor and it does not create E-E-A-T — Danny Sullivan has said E-E-A-T isn't a direct ranking factor and self-declaring an expert 'means nothing,' and John Mueller has said structured data won't make a page rank better. What Google actually encourages is visible authorship — accurate bylines and background readers can see — not credentials buried in markup. Google's Article-author guidance formally recommends only name and url (or sameAs) — jobTitle shows up in Google's own example but isn't a listed recommended property; ProfilePage separately requires mainEntity and name, and recommends alternateName, sameAs, and description. Don't treat either as a jobTitle/worksFor checklist. My take: use Person schema to help engines identify you consistently, not as a shortcut to authority.
TL;DR — Person schemaPerson 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. 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
Persontype 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.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. vocabulary — the same one behind product prices,
review stars, and breadcrumbsBreadcrumbs are a secondary navigation trail (Home > Category > Page) that shows where a page sits in a site's hierarchy. They create internal links that pass PageRank, and when marked up with BreadcrumbList structured data they can drive the path Google shows in desktop search results.. 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
jobTitleproperty 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 schemaPerson 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. (
schema.org/Person) marks up an individual — most often as an article’sauthor, sometimes as themainEntityof aProfilePage. Its job is entity disambiguation, primarily throughsameAs: 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 dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. 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-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. are the opposite of what Google actually encourages.
Where Person schema is used
Three common homes, and they aren’t interchangeable:
- Article author. The
authorproperty of anArticle/BlogPosting, typed asPerson. Google’s own example includesname,jobTitle, andurl. - ProfilePage
mainEntity. A dedicated bio/about page where thePersonis the primary subject. Google’s ProfilePage docs describe it as being for sites “where creators (either people or organizations) share first-hand perspectives.” - Inside Organization markupOrganization schema (schema.org/Organization) is structured data that describes the business or entity itself — name, logo, official URL, social profiles, contact info, and identifiers — rather than a page's content. Google says it can help disambiguate your brand and some properties can influence visual elements like Knowledge Panel/attribution; it has no required properties and doesn't guarantee a Knowledge Panel. — a founder or employee mentioned on a company page.
This is a sibling topic to Organization schemaOrganization schema (schema.org/Organization) is structured data that describes the business or entity itself — name, logo, official URL, social profiles, contact info, and identifiers — rather than a page's content. Google says it can help disambiguate your brand and some properties can influence visual elements like Knowledge Panel/attribution; it has no required properties and doesn't guarantee a Knowledge Panel. (the business itself) and LocalBusiness schemaLocalBusiness schema (schema.org/LocalBusiness) is structured data — usually JSON-LD — that describes a physical business to search engines: its name, address, phone, hours, geo-coordinates, and price range. Google requires only name and address, consumes about a dozen recommended properties, and treats it as a corroborating signal, not a substitute for a Google Business Profile. (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 cruxChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., 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.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. 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
- anyone could self declare someone to be an expert, and that means nothing and
- 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 theauthor.nameproperty, 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 treatssameAsas an accepted alternative tourlfor 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 ofname. Appears in Google’s example only.worksFor— anOrganizationobject 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 asworksFor: schema.org vocabulary, not in Google’s Article recommended table.sameAs— the disambiguation lever, and the one alternative Google’s own docs name alongsideurl. 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 wrongsameAsbreaks 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):
Article author (Person) | ProfilePage mainEntity (Person) | |
|---|---|---|
| Primary purpose | Attribute the article to a person | Declare a page is about a person |
| Required by Google | Nothing formally required — Google says add what applies | mainEntity, and the entity’s name (alternateName can stand in when name isn’t available) |
| Recommended by Google | name, url (sameAs accepted as an alternative to url) | alternateName (handle), sameAs, description (byline/credential), image, dateCreated/dateModified |
jobTitle / worksFor | Appear in Google’s worked example only — not a recommended-table row | Not documented for ProfilePage at all |
name guidance | Name only | Real name in name, handle in alternateName |
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 PanelThe Knowledge Graph is Google's database of entities — people, places, organizations, and things — and the factual relationships between them. It's separate from any single website's structured data: your schema markup is one of many possible inputs to the graph, not the graph itself. 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 LLMsA large language model (LLM) is a deep-learning model trained on massive text corpora to predict the next token and generate human-like text. LLMs use the transformer architecture and power AI search features like Google's AI Overviews (Gemini) and Bing Copilot (GPT-4). and AI searchAI search uses large language models and retrieval-augmented generation (RAG) to synthesize an answer from multiple sources rather than returning a ranked list of links. Examples include Google AI Overviews, ChatGPT Search, and Perplexity. 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 markupSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. will impact LLM output, because current AI crawlersAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. 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/Personmarks up an individual — most often an article’sauthor, sometimes aProfilePage’smainEntity, or a founder inside Organization markupOrganization schema (schema.org/Organization) is structured data that describes the business or entity itself — name, logo, official URL, social profiles, contact info, and identifiers — rather than a page's content. Google says it can help disambiguate your brand and some properties can influence visual elements like Knowledge Panel/attribution; it has no required properties and doesn't guarantee a Knowledge Panel.. 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). Pointauthor.urlat one canonical bio page — “reconciliation.” - NOT a ranking factor, NOT E-E-A-T: Mueller — structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. 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 schemaPerson 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. 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
nameandurl(sameAsaccepted as an alternative tourl);jobTitleappears in Google’s example only, andworksFor/imagearen’t in Google’s Article docs at all. ProfilePage:mainEntityandnameare required;alternateName,sameAs,description,imageare recommended. Google does not listjobTitle/worksForfor ProfilePage either. namerule: only the name inname; the role goes injobTitle(“Jane Smith, Editor” is wrong).- Knowledge PanelsThe Knowledge Graph is Google's database of entities — people, places, organizations, and things — and the factual relationships between them. It's separate from any single website's structured data: your schema markup is one of many possible inputs to the graph, not the graph itself.:
sameAsis a hint, not a generator; Google needs independent corroboration. - AI searchAI search uses large language models and retrieval-augmented generation (RAG) to synthesize an answer from multiple sources rather than returning a ranked list of links. Examples include Google AI Overviews, ChatGPT Search, and Perplexity.: entity infrastructure, not a switch that changes AI output today.
- Match markup to visible content; mismatched or broken
sameAsbreaks disambiguation rather than helping.
Official documentation
Primary-source documentation from the search engines.
- Article structured data — the
authorproperty (Person/Organization), theauthor.name“name only” rule, and the recommendedauthor.url. - Profile page (ProfilePage) structured data —
mainEntity,name/alternateName,sameAs, anddescription(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.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. type, including
Personwhere 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 dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. and JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal..
- 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
Relayed via Search Engine Roundtable / Search Engine Land coverage of Sullivan’s X thread on E-E-A-T. There appear to be two related Sullivan statements (one circa 2019, one circa 2024); confirm which date this exact wording belongs to, and grab the original post, before treating the phrasing as final.“having an expert write things doesn’t magically make you rank better, because
- anyone could self declare someone to be an expert, and that means nothing and
- 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 dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. 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.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. 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.nameproperty, 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 schemaPerson 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. 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 dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. 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-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. 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 PanelThe Knowledge Graph is Google's database of entities — people, places, organizations, and things — and the factual relationships between them. It's separate from any single website's structured data: your schema markup is one of many possible inputs to the graph, not the graph itself..
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/LLMsA large language model (LLM) is a deep-learning model trained on massive text corpora to predict the next token and generate human-like text. LLMs use the transformer architecture and power AI search features like Google's AI Overviews (Gemini) and Bing Copilot (GPT-4). say about you today. Current AI crawlersAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. 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-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal..
Person schema: which path applies?
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.nameshould contain nothing but the name. -
jobTitleis a separate property, added only when that role is genuinely visible on the page. -
author.urlpoints 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. -
imagematches the headshot actually shown on the page. -
sameAsonly 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-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal..
- ProfilePage subjects use the ProfilePage property set, not the Article-author one:
name,alternateName(handle),sameAs,description— skipjobTitle/worksForthere. - Markup validates in the Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. Test or the Schema MarkupSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. 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
| Situation | Model |
|---|---|
| Article author | Article author points to a Person with stable @id |
| Dedicated profile | ProfilePage mainEntity is the Person |
| Organization relationship | Use worksFor or affiliation only when accurate |
| External identity | sameAs links to pages that unambiguously represent that person |
| Multiple articles | Reuse the same stable Person identity instead of creating disconnected entities |
| No public evidence | Omit unsupported credentials, awards, or identity links |
Person markup disambiguates an entity; it does not manufacture expertise, rankings, or a Knowledge PanelThe Knowledge Graph is Google's database of entities — people, places, organizations, and things — and the factual relationships between them. It's separate from any single website's structured data: your schema markup is one of many possible inputs to the graph, not the graph itself..
Test yourself: Person Schema
Five quick questions on what Person schemaPerson 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. 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.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor./Person structured-data type you use to mark up an individual — usually as JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal.. 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 crawlersAI crawlers are bots from AI companies that fetch web pages to train language models, build AI-search indexes, or answer live user questions. They come in three categories, each with its own user-agent tokens and its own robots.txt controls. 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 dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. 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
Build-time retrieval analysis plus live signals for this exact article. The automatic chunk report includes a deterministic readiness score and is ready without a model download.
Search Console
sampleGA4 traffic (28d)
sampleCloudflare traffic (7d)
sampledCrUX field data (28d, phone)
sampleGoogle NLP entities
localChangelog
Updated Jul 18, 2026.
Editorial summary and recorded change details.Summary
Corrected attribution inflation: jobTitle/worksFor/image were presented as Google-recommended Article-author properties when Google's recommended table lists only name and url (sameAs as an alternative); jobTitle appears in Google's example only, worksFor/image aren't documented at all. Added ProfilePage's actual required properties (mainEntity, name).
Change details
-
Rewrote the Core properties section to separate Google's two formally recommended Article-author properties (name, url/sameAs) from schema.org properties that appear in Google's example only (jobTitle) or aren't documented for Article author at all (worksFor, image).
-
Rebuilt the Article-author vs. ProfilePage comparison table with a required-vs-recommended row, adding that ProfilePage's mainEntity and name are required (not just recommended) per Google's live docs.
-
Corrected the ai-summary, anti-patterns (two entries), decision-tree, and quiz question 4 to match the corrected property-status language instead of calling jobTitle/worksFor Google recommendations.
-
Removed Bing from the frontmatter tldr's disambiguation claim since Bing-specific Person guidance remains unverified (its help pages 404/403'd during research).
Full comparison unavailable — no prior snapshot was archived for this revision.