Person Schema

Element Code: RI-008

Let me set expectations before we start, because Person schema attracts more magical thinking than almost any other markup. There is no E-E-A-T badge. Google does not hand out a ranking bonus because you declared someone an expert in JSON-LD. What Person schema actually does is quieter and, done properly across a whole site, genuinely useful: it turns a byline string into an unambiguous entity that machines can recognize, connect, and trust across every article that entity touches.

What Person schema does

The schema.org Person type describes an individual: their name, job title, employer, credentials, photo, and the external profiles that corroborate all of it. On a publishing site it shows up in two places: nested inside an Article's author property, and as the main entity of the author's profile page.

The job it performs is disambiguation. "John Smith" is a string; thousands of people share it. A Person object with an @id, a jobTitle, a worksFor organization, and sameAs links to a real LinkedIn profile is a specific human being. Search engines build entity graphs, and this markup is how you hand them the edges instead of making them infer everything from prose. Google's own Article structured data documentation asks for exactly this: an author name plus a url or profile links that identify who the author is.

The author entity graph you are building

The @id is the piece most implementations miss. Give the Person one stable identifier, conventionally the author page URL plus a fragment like #person, and reference that same identifier from every article the person writes. Now fifty articles do not carry fifty disconnected author blobs; they all point at one entity whose home is the author page. That consistency is the entire trick.

Why this matters, stated honestly

Google's quality rater guidelines lean hard on understanding who created content, especially for YMYL topics where the author's qualifications are part of the quality judgment. Person schema does not manufacture those qualifications, and Google has been clear that markup is a way to communicate information, not a way to rank better. What it does is remove ambiguity from signals Google is already trying to collect. If your medical reviewer really is a board-certified physician with a professional footprint, the markup makes that connection explicit and cheap to verify instead of leaving it to inference.

The second-order benefits are real too: correctly attributed authors in Google's various author-surfacing features, cleaner knowledge panel associations for writers who have one, and a defensible answer when someone asks how the site demonstrates who is behind its content. My opinion after years of audits: on a multi-author site with genuine expertise, this markup is cheap and worth doing well. On a site with fake personas, no markup will save you, and I have watched exposed fake-author schemes take entire content operations down with them.

Property reference

How to detect the gap

Crawl the site with Screaming Frog with structured data extraction enabled and look at two things. First, author profile pages: do they carry a Person object at all, or are they bare archive templates? Second, article markup: is the author property a full Person object with a url, or just "author": "Jane Smith" as a naked string? The naked string is what most themes and plugins output by default, and it throws away the entity connection entirely.

Spot-check with the Schema Markup Validator, since Person is not a rich result type and the Rich Results Test will mostly shrug at it. And do the human check: click a byline. If it leads nowhere, or to a page with no bio, no photo, and no profile links, the markup gap is the least of the problems; there is no author identity to mark up yet.

How to fix it, step by step

1. Build real author pages first. Photo, bio, credentials, topics covered, links to profiles. The markup describes the page; it cannot substitute for it.
2. Add Person markup to each author page, ideally as the main entity of a ProfilePage, which is a structured data type Google documents specifically for this. Assign the stable @id here.
3. Reference that @id from every article. The Article's author property should resolve to the same entity, either by @id reference or by repeating the Person with the identical @id.
4. Populate sameAs with profiles that are alive. Three current, active links beat eight dead ones. Delete anything that 404s.
5. Align the strings. Byline, author page heading, and schema name should match character for character. "Dr. Jane Smith" in one place and "Jane Smith, MD" in another forces the disambiguation work you were trying to eliminate.
6. Validate and recrawl. Confirm the entity graph resolves: one Person, one @id, many articles pointing at it.

What good looks like

Every author has a substantive profile page carrying Person markup with a stable @id. Every article's author property resolves to that entity instead of a loose string. The sameAs profiles are live and plausibly belong to the same human. Names match everywhere. Validators come back clean. Most importantly, a skeptical stranger, or a quality rater, could land on any article, click the byline, and within thirty seconds understand exactly who wrote it and why they are qualified to. The schema is just that experience made machine-readable.

FAQ