Person schema is the schema.org type used to describe an individual human as an entity, published as JSON-LD on the page that is primarily about that person. Its main practical use on content sites is the author entity: a single Person node with a stable identifier, referenced by the author property of every article that person wrote, instead of a bare name string repeated across hundreds of pages.

The properties worth using

Person inherits everything on Thing and adds a large set of its own. The ones that carry weight for authors and personal brands are these.

Naming. name is the full name as normally written. givenName and familyName split it, which matters for non-English name orders and for consumers matching against records that store the parts separately. additionalName holds a middle name. alternateName covers pen names, maiden names, handles, and the form used in bylines when it differs from the legal name. honorificPrefix holds “Dr” or “Prof” and honorificSuffix holds “PhD” or “MD”; putting either inside name makes the name harder to match.

Location on the web. url is the person’s canonical page, normally the author profile on the site publishing the markup. image is a photograph of the person. sameAs links to reference pages that identify them, which is the subject of sameAs schema.

Work and expertise. jobTitle is a plain string. worksFor takes an Organization and is the current employer. affiliation takes an Organization and covers looser attachments: a research group, a professional body, an advisory board. alumniOf takes an educational organization. knowsAbout states subject expertise and accepts text, a URL, or a Thing, so a claim of expertise can point at a Wikidata item rather than a keyword. award holds recognitions, hasOccupation takes an Occupation where a structured job description is useful, and memberOf covers memberships.

Description. description is a short biography in one or two sentences. Long-form biography belongs in the visible page, not the markup.

Three properties are frequently added and rarely earn their place. birthDate and nationality are personal data with no bearing on an author entity in most cases. And there is no property for a credibility score, an authority rating, or an expertise level, because schema.org does not define one.

The author-entity pattern

Most sites emit author as a string:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Writing data contracts that hold up",
  "author": "Jane Doe"
}

That is valid and nearly useless. It says the article was written by something named “Jane Doe” and provides no way to tell which Jane Doe, no route to anything else she wrote, and nothing to attach expertise or identifiers to. Every article restates the string, and a consumer that wants to know who the author is has to resolve the name from scratch.

The pattern that does work declares the person once, at their profile URL, and references that node everywhere else:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://example.com/authors/jane-doe/#person",
      "name": "Jane Doe",
      "givenName": "Jane",
      "familyName": "Doe",
      "honorificSuffix": "PhD",
      "url": "https://example.com/authors/jane-doe/",
      "image": "https://example.com/assets/authors/jane-doe.jpg",
      "description": "Jane Doe is a data engineer who writes about data quality and graph modelling.",
      "jobTitle": "Principal Data Engineer",
      "worksFor": { "@id": "https://example.com/#organization" },
      "alumniOf": {
        "@type": "CollegeOrUniversity",
        "name": "Northgate University",
        "url": "https://university.example.edu/"
      },
      "knowsAbout": ["Data quality", "Knowledge graphs", "SPARQL"],
      "sameAs": [
        "https://orcid.org/0000-0000-0000-0000",
        "https://www.linkedin.com/in/janedoe/",
        "https://github.com/janedoe"
      ]
    },
    {
      "@type": "Article",
      "@id": "https://example.com/blog/data-contracts/#article",
      "headline": "Writing data contracts that hold up",
      "datePublished": "2026-04-02",
      "dateModified": "2026-05-19",
      "author": { "@id": "https://example.com/authors/jane-doe/#person" },
      "publisher": { "@id": "https://example.com/#organization" }
    }
  ]
}

Three details make this work. The @id uses a fragment, #person, because the profile URL identifies a web page while the fragment identifies the human being. The @id never changes, even if the slug does, or the site creates a second author. And the Person node itself is declared in full only on the profile page; article pages carry the reference alone, since consumers merge blocks and resolve identifiers across a site. The mechanics are set out in JSON-LD, and the same referencing discipline applies to the publisher node in organization schema.

The Article block above uses author with an object reference. Where a fuller inline object is preferred on article pages, repeat only @id, @type, name, and url, and keep the complete property set on the profile page. Google’s article documentation asks for an author value with a name, and adding url or sameAs alongside it gives the crawler a route to the profile.

Author profile pages

Markup describes a page; it does not substitute for one. An author Person node pointing at a URL that renders a name and a two-line stub is a claim with nothing behind it. The profile page that supports the markup carries the biography, the credentials, the list of published work, and outbound links to the identifiers in sameAs, all of it visible to a reader.

That page is the person’s entity home on the site: one canonical URL, one node, one place where the facts live. Bylines link to it, the markup identifies it, and external profiles point back at it. Entity SEO covers the entity home idea in general, and what is an entity covers why identity has to be anchored somewhere.

Author markup and credibility signals

Google’s guidance on people-first content asks who wrote a page, what their expertise is, and whether the site makes that clear, and its quality rater guidelines describe experience, expertise, authoritativeness, and trustworthiness as things raters assess. Those documents describe an evaluation approach. There is no E-E-A-T score, no field in any Google tool that reports one, and no property in schema.org that sets one. Markup cannot assert credibility; a site can only make verifiable facts about an author explicit and consistent, and let independent sources corroborate them.

Within that limit, Person markup does useful work. It makes the author’s identity machine-readable rather than inferred from a byline. It ties the author to an employer and an institution through worksFor and alumniOf, both of which are checkable. It states subject scope with knowsAbout. And through sameAs it connects the author to identifier systems outside the site, such as ORCID for researchers or a library authority record for published writers. Where those external records agree with the markup, the entity resolves. Where they do not exist at all, the markup remains an unsupported claim, which is the same corroboration problem described in linked data.

Knowledge panels for people

Individuals do get knowledge panels, and the ones that do are usually people with substantial independent coverage: authors with published books, academics with citation records, executives written about in the trade press. The panel is generated from an entity in the Google Knowledge Graph, and that entity is built from sources Google holds and trusts, not from a site’s own markup. Person markup contributes by making a site’s identity statements unambiguous and consistent with those sources.

The honest version of the advice is that panel eligibility for a person tracks how much verifiable, independently published information exists about them. Markup, a clean entity home, and consistent identifiers make an existing entity easier to match. They do not create notability. The sequence, including the Wikidata question, is worked through in how to get a knowledge panel and Google Knowledge Panel.

Personal brands and consultants

For a sole trader, consultant, or creator, the person and the business are often the same commercial entity but not the same kind of thing. Model both and connect them rather than collapsing them: a Person node for the individual and an Organization or LocalBusiness node for the practice, joined by founder on the organization and worksFor on the person. Each keeps its own identifiers, since a company registration number is not a personal identifier and an ORCID is not a company’s.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://example.com/#person",
      "name": "Dana Reyes",
      "url": "https://example.com/",
      "jobTitle": "Independent Data Consultant",
      "knowsAbout": ["Data governance", "Metadata management"],
      "sameAs": ["https://www.linkedin.com/in/danareyes/"]
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Reyes Data Consulting",
      "url": "https://example.com/",
      "founder": { "@id": "https://example.com/#person" }
    }
  ]
}

For developers

Generate the Person node from the same author record the CMS uses to render the byline, so the two cannot diverge. Author data is exactly the kind of content that gets edited in one place and not the other.

Because the markup is RDF, author identity can be tested rather than reviewed. A crawl that extracts every author value across the site and groups them by @id will surface the common failures immediately: two identifiers for one person, one identifier used by two people, articles still emitting a bare string, and profile URLs that return 404. A SHACL shape requiring every Article to have an author that resolves to a Person with a name and a url turns that into a build check.

For SEOs

Person markup produces no visual change in search results on its own. There is no author rich result to earn, and nothing here is a ranking factor. What it does is give a search engine one identifier per author, which is the prerequisite for any downstream use of authorship.

The audit is short. Confirm each author has exactly one profile URL and one @id. Confirm every article references it rather than restating a name. Confirm the properties in the markup match what the profile page says, and that the sameAs targets are profiles the person actually controls. Then check whether external identifiers exist, because that is usually the binding constraint, not the markup.

Related pages

• sameAs schema
• Organization schema markup
• JSON-LD
• Entity SEO
• Google Knowledge Panel
• Structured data testing tools

FAQ

What is Person schema used for?

Person schema describes an individual as a machine-readable entity, giving their name, profile URL, image, job title, employer, education, subject expertise, and external identifiers. On content sites, its main use is the author entity: one Person node with a stable @id that every article references through its author property, rather than a plain name string repeated on each page.

Should author be a Person object or a string?

An object. A string names something without identifying it, so nothing can be attached to it, and no consumer can tell one same-named author from another. Declaring a Person node with a stable @id on the author profile page and referencing that @id from each article’s author property gives every article a route to one identifiable person.

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

There is no E-E-A-T score to improve. Experience, expertise, authoritativeness, and trustworthiness describe how Google’s guidelines frame quality assessment, not a metric any tool reports. Person markup helps by making verifiable facts about an author explicit and consistent with independent sources such as ORCID, a university page, or a professional profile. It cannot assert credibility on its own.

Can Person schema get someone a knowledge panel?

No. Panels are generated from entities in the Google Knowledge Graph, built from independent sources rather than from a site’s own markup. Person markup makes a site’s identity claims unambiguous, which helps Google match the site to an existing entity, but eligibility tracks how much verifiable published information exists about the person. Markup does not create notability.

Sources and further reading

• schema.org, Person: https://schema.org/Person
• schema.org, Organization: https://schema.org/Organization
• Google Search Central, Article structured data: https://developers.google.com/search/docs/appearance/structured-data/article
• Google Search Central, Creating helpful, reliable, people-first content: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
• Google Search Central, Knowledge panels: https://developers.google.com/search/docs/appearance/knowledge-panel
• ORCID: https://orcid.org/