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.

How JSON-LD parsing actually works

It helps to understand what happens to this block after you paste it in, because that mechanism explains most of the rules that follow. A <script type="application/ld+json"> tag is not rendered. Browsers skip over it when painting the page, so visitors never see it and it never affects layout, fonts, or colors. What reads it is a separate process: a crawler fetches the raw HTML, finds the script tag by its type attribute, and hands the text inside straight to a JSON parser.

That is the whole trick. The parser does not care where the tag sits in the document, head or body, top or bottom, because it is not interpreting the page visually at all, only extracting one block of text and checking whether it is valid JSON. If it is, the parser builds an object tree and matches its keys against the schema.org vocabulary. If it is not, most parsers fail silently on that block: no error shown to the visitor, no console warning most people will ever see, just a Person entity that quietly does not exist as far as any machine is concerned. A single missing comma, a stray trailing comma after the last property, or an unescaped quotation mark inside a description string is enough to break the entire block. This is exactly what the schema.org validator is checking when you paste in a URL: it is running the same parse-then-match routine a crawler runs, and showing you the result instead of hiding it.

One practical consequence: you can have more than one JSON-LD script tag on a page, and engines will read all of them. That is useful when your Person entity lives in one block and your Article or Organization entity lives in another, rather than forcing everything into a single nested object.

Nesting Person inside other schema types

Person schema rarely stands entirely alone in a mature setup. Once you have declared the entity with an @id, that same object can be referenced as a property value inside several other schema types, which is how one declared identity ends up threaded through a whole site instead of copy-pasted everywhere.

The most common case, an Article or BlogPosting's author field, is covered above. Two other placements are worth knowing. An Organization can list you as an employee, which matters if you run a one-person company and want the business entity and the human entity to stay distinct but connected rather than one absorbing the other, a mistake covered from the other direction in sameAs: the most underrated line in your markup. A Review can carry your Person entity in its author field too, if you are the one leaving the review rather than receiving it. The shape looks like this:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Okafor Privacy Advisory",
  "employee": { "@id": "https://janeokafor.com/#person" }
}

Notice the pattern repeats exactly: reference the @id, do not restate the object. Every additional place you nest that reference is one more context in which the engine encounters the same, single, already-resolved entity, rather than a fresh ambiguous mention it has to work out from scratch. This nesting habit is also what keeps a machine-readable presence coherent as your site grows, a subject covered end to end in building a machine-readable about page.

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:

Ranked roughly by how much disambiguation weight each property carries when an engine tries to resolve your name to one entity.

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.

Handling name collisions inside your own markup

Schema alone cannot make you the only Jane Okafor on the internet, but it is the single most direct tool you have for drawing a boundary around which Jane Okafor you are. When an engine encounters your name and finds two or more plausible people behind it, the properties in your Person block are what it uses to decide which facts belong to you and which belong to someone else entirely. The dedicated breakdown of this problem lives in name collisions in Person Engine Optimization; here is how the schema side of that fight actually works.

Each step narrows the candidate pool an engine has to choose from when your name alone is not enough to disambiguate you.

A worked example: building the block field by field

Seeing the reasoning behind each decision is more useful than staring at a finished block, so walk through how the example earlier in this guide actually got built, field by field.

Starting with what is non-negotiable

@type, name, and url come first, because without them there is no entity to attach anything else to. The @id is chosen next, and it should be a URL fragment on your own domain that will not move, typically your homepage or about page plus a stable anchor like #person.

Filling the description honestly

The description field is not marketing copy stretched to fit a box. Write the one paragraph you would want an engine to repeat verbatim if a buyer asked who you are, then check it against your actual site content. If the schema says something the visible page does not support, you have created the contradiction problem covered in the mistakes list below before you have even finished the block.

Choosing knowsAbout last, not first

It is tempting to list knowsAbout topics aspirationally, the expertise you want rather than the expertise your published work demonstrates. Build this list only after auditing what you have actually written and spoken about. An engine that cross-checks a knowsAbout claim against your visible content and finds nothing supporting it is not persuaded; it is, if anything, slightly less confident in the rest of the block.

Closing with sameAs

sameAs goes last because it depends on everything else being settled first: your name form needs to be locked before you can confirm every listed profile uses it consistently. Building the array is its own discipline, detailed in full in sameAs: the most underrated line in your markup.

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.