Person Schema: Marking Up Authors and Experts

Person schema is structured data that describes a human being on your site: who they are, what they do, where else they appear online and which organization they belong to. You use it in three places: inside an Article to name its author, on a dedicated author or profile page, and on an About or team page to describe founders and experts. The properties you pick matter less than where the markup lives and whether every copy of it points back to the same identity.

Most implementations fail on the second half. Sites paste a thin author object into every article, fill it with slightly different values each time, and never connect it to the Organization that publishes the work. The result is valid markup that says nothing consistent. This guide covers which Person and ProfilePage properties to use, which page should carry which markup, and how to link people to an Organization with stable identifiers. Writing the visible author bio itself is a separate job; here the subject is the machine-readable layer beneath it.

What Person Schema Actually Does

Person is a type from the schema.org vocabulary. Marking a page up with it does not create a rich result the way Recipe or Product markup can. There is no special Person snippet in search results that you earn by adding it. What it gives you is a clean statement of fact for systems that read structured data: an entity with a name, a role, a set of profiles elsewhere and relationships to other entities.

That statement is useful for two reasons. First, Google documents author markup inside its Article structured data guidance, so naming the author in a machine-readable way is an expected part of a well-formed article. Second, search engines and other systems that assemble knowledge about people and organizations have to decide whether the John Smith on your blog is the same John Smith with a LinkedIn profile and a conference talk. Markup that carries consistent identifiers and profile links makes that decision easier. It does not guarantee a knowledge panel, a byline treatment or any ranking benefit, and anyone promising one is selling something.

Author Inside an Article Versus a Standalone Person

There are two different jobs, and mixing them up is the most common structural mistake. The first job is attribution: an Article or BlogPosting needs to say who wrote it. The second is description: one page, usually the author archive or profile, needs to describe the person in full.

Inside an article, keep the author object short. Google's Article documentation asks for the author's name and, where possible, a url that points to a page about that person, such as their profile page on your site. It also asks for one author object per person, and for the name field to contain only the name, not a job title, a credential or a string like 'Written by'. If an article has two authors, use an array of two Person objects rather than one object named 'Anna and Tomas'.

On the profile page, do the full description. That is where jobTitle, image, sameAs, knowsAbout and the employer relationship belong. Repeating all of those inside every article bloats the page and multiplies the places where a stale value can hide. A short author reference in the article plus a complete entity on one canonical page is easier to maintain and easier for a parser to reconcile.

Properties Worth Including on a Profile Page

Google has a structured data feature for profile pages that uses ProfilePage with a Person (or Organization) as its main entity. It is meant for pages whose primary content is about one creator or member, such as an author page or a community profile. The page is marked up as a ProfilePage and the person goes in mainEntity. Check Google's current documentation for which properties are required versus recommended, because that list changes; the following are the ones that do real work in practice.

• name: the person's real name as it appears in bylines. Use exactly one spelling across the site. If the person publishes as 'Dr. Ana Ruiz' in one place and 'Ana Ruiz' in another, choose one and use it everywhere.
• alternateName: a handle, nickname or alternate spelling that people genuinely use, for example a username on a platform. Leave it out if there is nothing real to put there.
• url: the canonical URL of the profile page itself, so the entity has a stable home address on your domain.
• image: a real photo of the person, at a URL that crawlers can fetch and is not blocked by robots.txt. Use the same image people see on the page.
• jobTitle: the role, as a plain string like 'Head of Engineering'. This belongs here, never inside name.
• description: one or two plain sentences that match the visible bio. Markup should describe what a visitor can read, not something extra.
• sameAs: URLs of profiles that belong to the same person, such as a professional network page, a publisher author page, a conference speaker page or a Wikipedia or Wikidata entry if one genuinely exists.
• knowsAbout: topics the person has real expertise in. Keep it short and specific, and make sure the page content backs it up.
• worksFor: a reference to the Organization they work for, covered in its own section below.

Keep sameAs Honest and Short

sameAs is the property that does the most disambiguation work, and it is the one people abuse. Its meaning is narrow: each URL should be a page that is about the same person and could be mistaken for no one else. A personal profile qualifies. A company page does not. A page that merely mentions the person, such as an interview where they were quoted, does not either.

Two or three well-chosen, accurate profile links beat a list of fifteen. Every link you add is a claim you have to keep true, and dead or repurposed profiles are a quiet source of wrong associations. Audit them when someone leaves, changes handle or deletes an account. For a founder with a Wikipedia article, link that; for most authors, a professional network profile plus a publisher or speaker page is plenty.

Where the Markup Lives and How to Connect It

The technique that ties everything together is the @id property. An @id is a URL-shaped identifier that names a node in your structured data so that other nodes can refer to it without repeating it. The convention is to use the canonical page URL plus a fragment, for example the profile address followed by #person. The fragment is just a label; it does not have to resolve to anything separate.

Here is the shape of a working setup. The profile page contains a ProfilePage whose mainEntity is a Person with @id set to the profile URL plus #person, along with all the descriptive properties. An article by that person contains an Article whose author is a Person with the same @id, the same name and the same url. A parser that sees both pages can merge the two references into one entity because they share an identifier, and it does not have to guess from the name alone.

Put the JSON-LD on the page it describes. The person's full description goes on the profile page, the short author reference goes on each article, and the organization's description goes on the home or About page. Do not place a person's full markup on a page where that person is not a subject, such as the footer of every page on the site. Markup should reflect the content of the page that carries it.

Linking a Person to an Organization

Relationships between people and companies are where Person schema becomes most valuable for founders and experts. There are two directions, and you typically want both.

From the person's side, use worksFor on the Person and point it to the Organization's @id, for example the home page URL plus #organization. From the organization's side, use founder for the people who started it, and optionally employee or member if you publish a team page. Each of those references should be just an @id or a short object, not a repeated full description.

The Organization itself is described once, usually on the home page or About page, with name, url, logo and its own sameAs profile links. A separate guide on LocalBusiness markup covers the extra properties for physical businesses, so this section does not repeat it. What matters here is consistency: the name in worksFor must match the name on the Organization node, and the publisher property on your articles should reference the same Organization @id. That way article, author and publisher form one connected graph rather than three disconnected snippets.

A Worked Example and Common Mistakes

Suppose a company has a founder, Marta Okafor, who writes about logistics. Her profile lives at example.com/authors/marta-okafor. That page carries a ProfilePage with mainEntity set to a Person whose @id is that URL plus #person, with name, jobTitle of Founder and CEO, an image, a short description, two sameAs links and worksFor referencing example.com plus #organization. The home page carries the Organization node with founder referencing Marta's @id. Each article she writes carries an author reference with the same @id, name and url, and a publisher reference to the Organization.

The mistakes are predictable once you have audited a few sites.

• Putting a job title or credential in the name field, which turns the name into something no other system will match.
• Generating a new @id per article, so the same author becomes hundreds of unrelated entities.
• Using Organization as the author for everything while a real person wrote the piece, or the reverse, attributing company content to one employee.
• Marking up a fictional or composite author to appear more authoritative. Fake bylines are a trust problem whether or not schema is involved.
• Copying a competitor's template wholesale, including their sameAs links and their description.
• Leaving markup in place after a person leaves, with a worksFor that is now false.

Testing and Maintaining the Markup

Validation has two layers. Use the Schema.org validator to check that the vocabulary is used correctly, and Google's Rich Results Test to check the types Google documents, which for this case includes the profile page and article author fields. Neither tool tells you whether the graph makes sense as a whole, so add a manual step: fetch the profile page and two articles, and confirm that the @id, name and url for the person match exactly.

Then maintain it as content changes. Person data ages faster than most markup because people change employers, titles and handles. Drive the JSON-LD from the same record that powers the visible bio, so there is one place to edit. When an author leaves, decide deliberately whether the profile stays as an archive of their work, in which case drop worksFor and the present-tense title, or is redirected.