Person Schema Markup: A Complete Working Example, Property by Property

Below is the full example, copy-ready and valid. Everything after it explains why each property is there, how the Person object connects to the rest of your schema graph, and which mistakes quietly cancel the whole effort. This page maps to Vector 6: Structure, the part of our methodology concerned with markup that machines read with high confidence.

The complete person schema example

This is a Person entity for a fictional structural engineer. Swap the values for your own author and the structure holds for any professional: a lawyer, a dentist, a shop owner writing buying guides. Paste it into a <script type="application/ld+json"> tag on the author's bio page.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://example.com/#jane-morrow",
  "name": "Jane Morrow",
  "jobTitle": "Structural Engineer",
  "worksFor": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Morrow Engineering Ltd."
  },
  "url": "https://example.com/about/jane-morrow/",
  "image": "https://example.com/assets/team/jane-morrow.jpg",
  "description": "Licensed structural engineer with 14 years of residential foundation assessment experience in Ontario.",
  "knowsAbout": [
    "structural engineering",
    "foundation assessment",
    "Ontario Building Code compliance",
    "residential renovation"
  ],
  "alumniOf": {
    "@type": "CollegeOrUniversity",
    "name": "University of Waterloo"
  },
  "sameAs": [
    "https://www.linkedin.com/in/janemorrow",
    "https://github.com/janemorrow",
    "https://x.com/janemorrow"
  ]
}

Run it through Google's Rich Results Test or the Schema.org validator and it passes clean. Now the property-by-property reasoning, because copying markup you do not understand is how sites end up with schema that contradicts itself.

What each property is actually doing

Two of these do most of the work. The @id is the anchor that lets a whole site reference one Person without duplication, and sameAs is the verification layer that separates a real author from an invented one. Get those two right and the rest is decoration; get them wrong and the rest is noise.

A note on knowsAbout versus sameAs, since they get confused: sameAs answers "is this the same person as the one on LinkedIn?", while knowsAbout answers "what subjects is this person credible on?". Disambiguation and expertise are different questions, and engines score them separately. Keep the knowsAbout array honest and specific: four to eight real subject areas beats twenty aspirational ones, because a declared expertise list that does not match the person's actual published work reads as keyword stuffing in entity form.

Why author entities matter more than they did two years ago

Google's quality rater guidelines have asked "who wrote this?" for a decade. What changed is enforcement. The May 2026 core update runs Gemini-based quality models, and AI Overviews now appear on roughly 48% of queries. Generative engines answer questions by picking sources they can attribute, and attribution requires a resolvable entity: a name that connects to a role, an organization, a topic history, and corroborating profiles elsewhere on the web. An anonymous article competes for citations with one hand tied.

This is the operational meaning of E-E-A-T. Experience and expertise are qualities of a person, not a domain, so engines need a machine-readable way to know which person stands behind the words. Person schema is that mechanism. Our full breakdown of how the framework gets evaluated in practice is in E-E-A-T explained for 2026, but the short version for this page: markup does not create expertise, it makes existing expertise legible to the systems deciding whom to cite.

In Matt's testing across Formative Digital's own byline pages, the pattern that moved the needle was not any single property. It was agreement. Before the entity cleanup, different AI assistants described his role three different ways, one of them borrowing details from an unrelated Matt Griffin. After the Person object went in with a stable @id, a knowsAbout array matched to published topics, and sameAs pointing at LinkedIn, the descriptions converged within a few crawl cycles. One entity, consistently declared, beats ten scattered signals.

Connecting Person to your Article bylines

The Person object earns its keep when your articles reference it. The wrong way is pasting a full Person block into every article's schema, usually with small differences that accumulate into contradictions. The right way is a reference by @id:

{
  "@type": "Article",
  "headline": "How to Read a Foundation Assessment Report",
  "author": {
    "@type": "Person",
    "@id": "https://example.com/#jane-morrow",
    "name": "Jane Morrow"
  },
  "publisher": { "@id": "https://example.com/#organization" }
}

The article carries just enough to identify the author (the @id plus the name for engines that do not dereference), and the canonical definition stays in one place. When Jane earns a new designation, you update one file and every byline on the site inherits it. Fifty articles with fifty slightly different embedded Person blocks is the opposite: an entity that disagrees with itself fifty times.

The full Article structure this plugs into, headline rules, image requirements, publisher references, is covered in our article schema example. The pairing is the point: Article markup tells engines what the content is, Person markup tells them who is accountable for it, and the @id is the wire between the two.

Connecting Person to Organization founder markup

The same referencing pattern applies at the company level. If your author founded or leads the business, the Organization schema should say so through the founder or employee property, again by @id:

{
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Morrow Engineering Ltd.",
  "founder": { "@id": "https://example.com/#jane-morrow" }
}

Now the graph closes a loop: the Person worksFor the Organization, the Organization names the Person as founder, and both agree because each side points at the other's @id. That mutual reference is a stronger signal than either declaration alone, since a fabricated affiliation rarely gets confirmed from both directions. The company side of this setup, logo, address, telephone, sameAs for the business, is documented in our organization schema example.

This page's own source demonstrates the pattern, and you are welcome to view source and check: the Article names Matt Griffin as author by @id, the Organization names him as founder by the same @id, and his bio page holds the canonical definition. We do not publish markup patterns we have not shipped on our own site first.

One author entity across the web

Search engines and LLMs build their picture of a person from every mention they can find, not just your markup. So the entity you declare has to match the entity the rest of the web describes. Practically, that means auditing four surfaces for agreement:

• Name form. Pick one and hold it. "Jane Morrow" on the site, "Jane E. Morrow" on LinkedIn, and "J. Morrow" in a trade directory are three weak entities instead of one strong one.
• Job title. The jobTitle in your schema, the headline on LinkedIn, and the bio line in guest posts should describe the same role. Minor wording differences are fine; contradictions are not.
• Topic history. The knowsAbout array should be defensible from the person's actual publication record. Engines can read both.
• Profile links. Every URL in sameAs must be live, public, and actually about this person. A dead link or a locked-down profile contributes nothing; a profile for a different person with the same name actively damages disambiguation.

Timing expectations belong in the plan too. Entity signals consolidate on crawl and retraining cycles, not on your deploy schedule, so changes you ship today typically show up in AI assistant descriptions over weeks rather than days. Ontario service businesses we have worked with usually see engine descriptions stabilize a month or two after the external profiles and the on-site markup finally agree; your timeline will vary with how often your sector gets crawled and how much conflicting information already exists about your people. Budget the reconciliation work once, then hold the line: the maintenance cost after agreement is minimal.

Common-name authors need this discipline most. If your expert shares a name with an athlete or an academic, the sameAs array and the worksFor reference are what stop engines from merging the two into one confused entity. This cross-surface reconciliation is the bulk of the work in our entity optimization service; the markup itself takes an afternoon, while getting every external surface to agree can take a quarter.

What not to fabricate, ever

Structured data is a claims format, and claims can be checked. As AI engines cross-reference entities against external sources by default, invented details stop being harmless embellishment and start being detectable contradictions. Hard lines:

• No invented credentials. Do not mark up a degree the author does not hold, a licence number that does not resolve, or a professional designation that a regulator's public register will not confirm. For regulated fields (health, law, engineering, finance) this is the fastest way to convert markup from asset to liability.
• No fictional authors. A persona with a stock photo, a fabricated bio and an empty sameAs array is a pattern quality systems have seen at scale since the AI-content flood began. If the business has one real expert, publish one real expert.
• No borrowed authority. Do not add sameAs links to profiles the person does not control, and do not claim worksFor relationships with organizations that would not confirm them.
• No inflated knowsAbout. Declaring expertise in subjects the person has never published on dilutes the topics where the expertise is real.

Google's spam policies treat structured data that misrepresents page content as a violation, and the site-wide trust cost lands on every other page you publish. The honest ceiling is the useful one: mark up everything true, and nothing else. A modest, verifiable author entity outperforms an impressive fake because verification is the whole game.

Five mistakes that quietly break person schema

These are the failures we find most often when auditing sites that already "have schema":

1. No @id at all. Each page mints an anonymous Person object, so engines see many similar entities instead of one referenced entity. This is the most common failure and the cheapest to fix.
2. @id values that drift. #jane-morrow on one page, #author on another, an absolute URL with a trailing slash difference on a third. The @id only works as an anchor if the string is byte-identical everywhere.
3. Markup that disagrees with the visible page. A jobTitle in schema that never appears anywhere a reader can see it. Since the May 2026 update tightened validation between structured data and visible content, treat the rule as absolute: if it is in the markup, it should be on the page.
4. sameAs rot. Profiles get renamed, deleted, or abandoned. Audit the array twice a year; a 404 in sameAs is worse than a shorter list.
5. Person defined only in a plugin. Many CMS SEO plugins emit a minimal Person with name only, and site owners assume the job is done. Name-only markup disambiguates nothing. Check what your stack actually outputs before assuming.

Where the markup should live: the ProfilePage pattern

Google's structured data documentation recommends a dedicated profile page whose main entity is the person. In practice: give each real author a bio page at a stable URL, mark that page up as ProfilePage with the Person as mainEntity, and make it the home of the canonical Person definition. The bio page should visibly show what the markup claims: photo, role, credentials, links to the same profiles listed in sameAs, and a list of the author's articles on your site.

That last element matters more than it looks. Internal links from every byline to the bio page, and from the bio page back to the articles, build the same person-to-content association in your link graph that the @id builds in your schema graph. Machines get the claim twice, through two independent structures, which is exactly the redundancy that makes an entity resolvable. Static sites like ours have an advantage here: the markup ships in the initial HTML with no client-side rendering step, so every crawler and every LLM retrieval pipeline sees it without executing JavaScript.

A 15-minute implementation checklist

• Create or confirm a bio page for each real author at a permanent URL.
• Write the full Person object there with a stable @id, using the example above as the template.
• Fill knowsAbout with subjects the author has genuinely published on, nothing aspirational.
• Add sameAs links only to live, public profiles the author controls.
• Reference the @id from every Article's author property and from the Organization's founder or employee property where true.
• Verify the visible bio page states everything the markup claims.
• Validate with the Rich Results Test, then re-check the sameAs array every six months.

Results caveat, because this is a spend-decision topic: entity markup improves how reliably machines identify your experts, and identification is a precondition for citation, not a promise of it. How much visibility follows depends on your competition, your content quality, and how much corroboration the wider web already gives your people. Anyone quoting a guaranteed timeline for Knowledge Panel or AI-citation outcomes is guessing on your budget.

Prefer to talk it through first? Get in touch and tell us who your experts are; wiring real people into a schema graph properly is faster than most owners expect, and it is work that compounds across every article they will ever publish. More of our published methodology lives in the research library.