2026-08-03 · Jack Stovell

Person schema markup: a copy-paste JSON-LD example

Person schema is JSON-LD structured data that tells machines exactly who a page is about: name, role, canonical URL, and which other profiles on the web belong to the same person. The strongest pattern for a personal page is a ProfilePage that wraps a Person as its main entity, placed in a single script tag in the page's HTML. Below is a complete, valid example you can copy and adapt.

What does complete Person JSON-LD look like?

Like this — swap the example values for your own and it is ready to paste:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "dateModified": "2026-08-03",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://samwright.example/#person",
    "name": "Sam Wright",
    "url": "https://samwright.example/",
    "jobTitle": "Freelance Product Designer",
    "description": "Freelance product designer in Bristol, UK, working with early-stage startups on web and mobile products.",
    "knowsAbout": ["Product design", "Design systems", "UX research"],
    "worksFor": {
      "@type": "Organization",
      "name": "Sam Wright Design",
      "url": "https://samwright.example/"
    },
    "sameAs": [
      "https://github.example/samwright",
      "https://www.linkedin.example/in/samwright"
    ]
  }
}
</script>

The fields doing the heavy lifting:

Before shipping it, check the JSON actually parses. A single trailing comma or an unescaped quote makes the whole block invalid, and parsers do not partially recover — they skip the entire thing silently, so the page looks fine to you and carries no markup at all for machines. Any JSON validator catches this in seconds.

Person vs ProfilePage: which do you use?

Both, in one block: ProfilePage describes the page, Person describes you, and mainEntity connects them. Use this combined shape on the one page that is canonically about you — an about page or a profile page. Use a bare Person object when you appear on a page that is not primarily about you, for example as the author of an article. What you should avoid is scattering full Person markup across every page of a site; one canonical, complete statement beats many partial ones. Which fields machines demonstrably pay attention to — and which are decorative — is covered in the Person and Organization schema AI actually uses.

Where do you put the script tag?

In the head of the page, though parsers accept it in the body too. The non-negotiable part is that the block must be present in the HTML your server actually sends. Most AI crawlers do not execute JavaScript, so markup injected client-side by a framework or a tag manager may never exist as far as they are concerned. If your site is client-rendered, open the raw page source and look for the block; the same problem that hides your content from crawlers hides your schema, and semantic HTML for AI readability covers how to fix it.

What do AI systems actually do with this?

The honest answer: schema markup is machine-readable identity, not a ranking lever. Search engines document how they consume structured data; AI assistants publish no equivalent detail, and nobody can truthfully promise that Person markup gets you cited. What it observably does is remove ambiguity. A system that fetches your page finds an explicit, parseable statement of who you are and which accounts are yours, instead of inferring both from prose — and disambiguation is precisely the job. Every hilyt profile emits this markup automatically, alongside a plain-text card like the live one at i.hilyt.it/jack/llm.txt.

What this won't do: valid JSON-LD on an unreadable page achieves nothing, and complete markup on a readable page only makes you legible. Schema is one layer of a readable identity, not a shortcut past the others — retrieval, ranking and model behaviour decide the rest.

Create your AI-readable profile

Related guides


All guides · Free AI visibility checker · hilyt.it