Person Schema: The Complete JSON-LD Guide for Your Name

Machines do not read your about page the way a client does. They parse it, guess at it, and sometimes guess wrong. Person schema is how you stop them guessing.

What is Person schema markup?

Person schema is a vocabulary defined at schema.org/Person for describing a human being in structured form: their name, job title, employer, education, expertise, image, and the web addresses that belong to them. You publish it as JSON-LD, a small <script type="application/ld+json"> block in the head or body of your page. Visitors never see it. Crawlers read it before they read anything else, because it is the one part of your page with zero ambiguity: no layout to interpret, no prose to parse, just labeled facts.

Google documents its handling of this markup in its profile page structured data guidelines, and the same declarations feed the wider ecosystem of systems that build entity records about people. That is the point of the exercise. Everything you earn online, mentions, citations, bylines, interviews, only counts if the machine can attribute it to one specific person. Schema is where you state, on your own property and in the machine's own language, which person that is. It is the formal half of the consolidation work described in structuring your identity for machines.

The complete Person JSON-LD, copy and adapt

Here is a full, realistic block for an independent professional. Replace the facts with yours, delete any property you cannot fill truthfully, and place it on your about page:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://janeokafor.com/#person",
    "name": "Jane Okafor",
    "alternateName": "Jane A. Okafor",
    "jobTitle": "Data Privacy Consultant",
    "description": "Independent data privacy consultant who
      helps healthcare companies pass HIPAA audits. Author of
      The Audit-Ready Playbook (2024).",
    "url": "https://janeokafor.com/",
    "image": "https://janeokafor.com/img/jane-okafor.jpg",
    "worksFor": {
      "@type": "Organization",
      "name": "Okafor Privacy Advisory"
    },
    "alumniOf": {
      "@type": "CollegeOrUniversity",
      "name": "University of Texas at Austin"
    },
    "knowsAbout": [
      "HIPAA compliance",
      "healthcare data privacy",
      "privacy audits",
      "vendor risk assessment"
    ],
    "sameAs": [
      "https://www.linkedin.com/in/janeokafor",
      "https://x.com/janeokafor",
      "https://github.com/janeokafor",
      "https://janeokafor.substack.com/"
    ]
  }
}
</script>

Two structural choices in that block do more work than they appear to. First, the outer ProfilePage type tells engines this page exists to describe this person, which is exactly what Google's profile page documentation asks for. Second, the @id gives your Person entity a permanent address you can reference from every other page on your site, which is what turns a pile of markup into one coherent entity.

Which Person schema properties actually matter?

schema.org lists dozens of Person properties. Most are noise for this job. These are the ones that carry weight, in rough order:

A note on knowsAbout, because it is the property people most often skip: it is your chance to state your expertise as topics rather than hoping engines infer them from prose. Keep the list short and honest, five to eight entries, phrased the way buyers actually search. "HIPAA compliance" earns retrieval; "synergistic regulatory excellence" earns nothing. The entries should match the subjects you actually publish about, because a knowsAbout claim with no supporting body of work is just an adjective in JSON.

sameAs deserves its own essay, and it has one coming in sameAs: the most underrated line in your markup. The short version: every URL you list is a thread the engine can pull to confirm that the LinkedIn profile, the author page and the personal site are one human, and cross-confirmation is how entity records solidify. How those records get built and connected is its own subject, covered in how machines connect facts about people.

Where should the markup live?

The pattern that works is declare once, reference everywhere:

1. Declare the full entity once, on your about page (or homepage), inside a ProfilePage wrapper, with the @id set.
2. Reference it from everything else. On every article you publish, the author field of your Article or BlogPosting schema should point at that @id rather than repeat the whole block.
3. Never fork the facts. If your about page says one job title and an article's author block says another, you have created two weak versions of yourself where one strong one should be.

The reference pattern in practice looks like this, on any article you write:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to Survive a Surprise HIPAA Audit",
  "datePublished": "2026-05-14",
  "author": { "@id": "https://janeokafor.com/#person" }
}
</script>

One line in the author field, and every article you ever publish accrues to the same entity instead of spawning a new anonymous one. The same trick works off-site wherever you control the markup, and it is the cheapest compounding asset in this whole discipline: the hundredth article strengthens the same record the first one started.

How do I validate Person schema markup?

Never ship markup you have not tested. The routine takes five minutes:

• Paste the page URL or the raw code into the Schema Markup Validator at validator.schema.org. It checks the JSON-LD against the schema.org vocabulary and shows you the entity tree exactly as a parser sees it. Confirm one Person appears, with every property attached to it.
• Run Google's Rich Results Test if you care about Google surfaces specifically. Person markup alone does not produce a rich result, so do not panic at "no items detected"; you are checking that the page parses without errors.
• Re-test after every site redesign. Template migrations are where schema silently dies. The page still looks fine to humans, and the JSON-LD block is gone.

Five mistakes that quietly waste the markup

1. Schema that contradicts the visible page. If the markup says "consultant" and the page says "fractional CMO", you taught the machine to distrust both. The block must describe the page it sits on.
2. Aspirational facts. Titles you want, awards you almost won, employers from a planned future. Structured lies are still lies, and they surface verbatim in embarrassing places.
3. sameAs links to dead or wrong profiles. An abandoned account or, worse, a same-name stranger's profile actively pollutes your entity. Audit the list twice a year.
4. A new anonymous Person block on every page. Without an @id, ten pages produce ten disconnected person-shaped fragments. Declare once, reference by @id.
5. Set-and-forget. You changed roles in March; your schema still says the old title in November. Stale markup is contradiction with a timestamp. Put it on the same review calendar as your LinkedIn headline.

Why bother, if schema is not a ranking factor?

Because the payoff is attribution, and attribution is upstream of everything that pays. Consider the moment that matters, the one the three signals AI uses to recommend a person breaks down in full: a buyer asks an engine who to hire, the engine retrieves eight candidate pages, and three of them mention someone with your name. If your entity is clean, declared once, confirmed by a dense sameAs web, consistent with every visible page, the engine can attribute all three mentions to one person and weigh them together. If your entity is fuzzy, the mentions fragment across maybe-you records and each fragment is individually too weak to matter. Same earned reputation, different machine-readable packaging, different answer.

There is also a defensive payoff that only becomes visible when things go wrong. People with common names, or names shared with someone notorious, discover that engines blend them into composite biographies. Explicit markup is one of the few tools that lets you draw the boundary yourself: this name, at this URL, with these profiles and these credentials, is a distinct person. It will not win every collision, but going without it means the machine draws the boundary for you, using whichever pages happen to surface that day.

Ten minutes of honest work with a text editor, a validator tab, and the copy-paste block above puts you ahead of the overwhelming majority of professionals, who have no structured identity at all. That asymmetry will not last forever. It is real right now.

What schema can and cannot do for you

Be clear-eyed about the mechanism. Person schema does not make engines like you, and no amount of JSON-LD substitutes for coverage, citations and work worth naming. What it does is close the attribution gap: it ensures that when an engine encounters your name in the wild, it can resolve that mention to one entity with high confidence, instead of splitting your reputation across several maybe-you fragments. SEO ranks pages, GEO promotes brands, PEO names you, and schema is the naming layer's grammar. Ship the block, validate it, keep it truthful, and then go earn the signals it exists to catch. When you want the whole stack built and monitored for you, that is what our services are for.