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.

First published: Jul 1, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #11 in Structured Data#35 in On-Page#176 in Technical SEO#236 on the site

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.

Evidence for this claim Schema.org defines Person and properties such as name, jobTitle, url, and sameAs. Scope: Vocabulary semantics; using the type is not a ranking guarantee. Confidence: high · Verified: Schema.org: Person Evidence for this claim Google recommends identifying article authors with author markup and linking to an author profile URL when possible. Scope: Google Article structured-data guidance; markup must describe visible page content. Confidence: high · Verified: Google Search Central: Article author markup

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’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 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:

  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 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

  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.

Sullivan’s and Mueller’s statements above are sourced through reputable secondary reporting (Search Engine Roundtable, Search Engine Land, Search Engine Journal) on their X/Bluesky posts; the wording and date pairing should be confirmed against the original posts before treating any phrasing as definitively verbatim.

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):

Article author (Person)ProfilePage mainEntity (Person)
Primary purposeAttribute the article to a personDeclare a page is about a person
Required by GoogleNothing formally required — Google says add what appliesmainEntity, and the entity’s name (alternateName can stand in when name isn’t available)
Recommended by Googlename, url (sameAs accepted as an alternative to url)alternateName (handle), sameAs, description (byline/credential), image, dateCreated/dateModified
jobTitle / worksForAppear in Google’s worked example only — not a recommended-table rowNot documented for ProfilePage at all
name guidanceName onlyReal 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.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.