Person schema markup is a block of JSON-LD that tells search engines and other machines who a person is, what they do and which profiles belong to them. For a founder or expert, it does one specific job: it connects your name to your company, your articles and your public profiles, so your expertise is attributed to the right person instead of floating as a string of text in a byline.
That connection matters more every year. Google’s guidance on helpful content asks whether a page makes it clear who wrote it, and AI assistants answer “who is the founder of” questions by stitching together whatever sources describe you. Person markup is the one source you fully control. Here is how to build it, field by field, with a template at the end.
Why a byline is not enough
A byline that says “By Jane Doe” gives a reader a name. It gives a machine almost nothing. There may be hundreds of Jane Does with public profiles, and a parser reading your article has no way to know which one wrote it unless you tell it.
Google’s Article structured data documentation addresses this directly. It recommends including the author property with the author’s name and a url that links to a page uniquely identifying the author, such as an author bio page or a social profile. It also asks that the name field hold only the name, without job titles or prefixes. Those two small rules are the start of what we call the Author Proof Chain.
The Author Proof Chain is a four-link sequence we use at Instant Press when we set up founders and executives for search and AI visibility. Link one is the Page, an article or interview carrying a byline. Link two is the Person, a Person object with a stable @id on a bio page. Link three is the Organization, the company the person works for or founded, also with an @id. Link four is the Profiles, the sameAs URLs that confirm the person is who the markup says. Each link points to the next. When all four hold, a machine can travel from any article to the person, from the person to the company, and from both to independent confirmation.
Most sites have link one and nothing else. Some have link one and a bio page with no markup. Very few have the full chain, which is why so many founders get described in vague terms or confused with someone else when an assistant is asked about them.
The 11 fields, in the order we fill them
Schema.org’s Person type supports dozens of properties. For founder-focused person schema markup, you need about eleven. Here they are in the order we fill them, with the reason each one earns its place.
The first field is @id, a URL on your site that serves as the person’s permanent identifier, such as https://www.example.com/about/jane-doe/#person. Every article she writes can then reference that @id instead of duplicating her details.
The second is name, written exactly as it appears in bylines and on LinkedIn. If you publish as “Jane A. Doe” in one place and “Jane Doe” in another, pick one and make the other an alternateName.
The third is url, the bio page itself. The fourth is image, a crawlable headshot with a stable URL. Use a real photo of the person, not a logo or an illustration.
The fifth is jobTitle, such as “Founder and CEO.” The sixth is worksFor, which should reference your Organization object by @id. That single reference is what connects link two to link three.
The seventh is sameAs, an array of the person’s profile URLs: LinkedIn, an X or Bluesky account if active, a Wikidata entry if one exists, a Crunchbase person page, an author page on a publication they write for and a speaker profile. Include only profiles that are clearly the same person and are kept up to date.
The eighth is description, one or two sentences that summarize who the person is in plain language. Write it the way you would want an AI assistant to describe them. The ninth is knowsAbout, a short list of the topics the person is an expert in. Keep it to topics they have actually published or spoken on.
The tenth is alumniOf, the universities or notable programs they attended, each as an EducationalOrganization or Organization object. The eleventh is award, a plain-text list of honors they have received, if they are real and verifiable.
Teams with several experts face a scaling question. Give each person who publishes or speaks for the company their own bio page and their own Person object, each with a unique @id. Do not put five Person objects on one team page and call it done, because a team page is about the team, not about any one person. A team page can list everyone and link to each bio, and each bio carries the full markup.
Guest contributors need care too. If an outside expert writes for your blog, their author field can point to a short contributor page on your site with their own Person object, and that object’s sameAs array should point to their profiles, not yours. Never set a guest’s worksFor to your company unless they work there. Getting that wrong ties someone else’s identity to your brand in a way neither of you intended.
Add ProfilePage to the bio page
Google documents a page type called ProfilePage for pages whose main focus is a single person or organization. Its ProfilePage structured data guide describes using it on profile and bio pages, with the person as the mainEntity. For a founder bio or author page, wrapping your Person object in ProfilePage tells search engines that this page is the canonical description of the person, not just a page that mentions them.
The guide also lists optional properties such as dateCreated and dateModified for the page, and interaction statistics for creator profiles on forums and social sites. A company bio page will not need the interaction fields. The date fields are worth adding, because they show the bio is maintained.
This is the difference between a byline that points somewhere and a byline that points to a definitive source. When a Person object sits inside a ProfilePage on a dedicated URL, and every article’s author field references that Person’s @id, the chain holds from end to end.
Copy this JSON-LD and edit it
Paste this on the person’s bio page, replace every example value and delete any field you cannot fill truthfully.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "ProfilePage",
"dateModified": "2026-10-01",
"mainEntity": {
"@type": "Person",
"@id": "https://www.example.com/about/jane-doe/#person",
"name": "Jane Doe",
"url": "https://www.example.com/about/jane-doe/",
"image": "https://www.example.com/images/jane-doe-headshot.jpg",
"jobTitle": "Founder and CEO",
"worksFor": { "@id": "https://www.example.com/#organization" },
"description": "Jane Doe is the founder of Northwind Analytics and writes about revenue forecasting for SaaS finance teams.",
"knowsAbout": ["revenue forecasting", "SaaS metrics", "financial planning"],
"alumniOf": { "@type": "CollegeOrUniversity", "name": "University of Texas at Austin" },
"award": "Example Business Journal 40 Under 40, 2025",
"sameAs": [
"https://www.linkedin.com/in/janedoe/",
"https://www.crunchbase.com/person/jane-doe",
"https://www.wikidata.org/wiki/Q00000000"
]
}
}
</script>Then, on every article Jane writes, set the author field to reference the same @id:
"author": {
"@type": "Person",
"@id": "https://www.example.com/about/jane-doe/#person",
"name": "Jane Doe",
"url": "https://www.example.com/about/jane-doe/"
}Including name and url alongside the @id keeps the article’s markup readable on its own, while the @id connects it to the full profile. For the Organization object that worksFor points to, see our guide to organization schema markup for AI search.
The mistakes that break the chain
We audit person schema markup on client sites every month, and the same errors come up again and again.
The most common mistake is putting a job title inside the name field, such as “Jane Doe, CEO.” Google’s documentation asks for the name alone, and the title belongs in jobTitle. The second is using a different spelling of the name in markup than in the byline. The third is linking sameAs to a profile that is not the same person, such as a namesake’s LinkedIn page that came up first in search. Check every URL by hand.
The fourth mistake is writing a description that does not match the visible bio. If the page says Jane spent ten years at a bank and the markup says she spent ten years at a consultancy, a machine now has two stories. The markup should summarize what the page says, not add facts the page leaves out.
The fifth is letting the markup go stale. People change titles, companies and cities. Set a calendar reminder to review every Person object twice a year, and update dateModified when you do.
There is also a strategic mistake worth naming. Some founders try to fill knowsAbout with every topic they would like to be known for. That list should reflect what the person has published, spoken about or been quoted on. A long list of aspirational topics with no supporting content gives a machine claims it cannot verify, and unverifiable claims do not build the kind of trust you want.
Back up the markup with real signals
Person markup works best as a summary of evidence that exists elsewhere. The strongest evidence is third-party: articles in credible publications that quote the person by name and title, podcast and conference appearances listed on the host’s site, and bylined pieces on outlets that keep their own author pages. Each of those is a candidate for the sameAs array and a source an AI assistant may read directly.
The second layer is consistency. Use the same headshot, the same title format and the same one-line description across LinkedIn, speaker bios, podcast show notes and your own site. When an assistant compares sources and finds the same facts phrased the same way, it has an easier time describing the person confidently.
The third layer is internal linking. Link every byline to the bio page with a visible link, not just in markup. Link the bio page to the person’s best articles. A reader who wants to know who wrote something should be able to find out in one click, and a crawler follows the same path.
You can check progress the same way you would for a company. Ask a few AI assistants who the person is, what they are known for and which company they lead, and save the answers with the date. Wrong titles, wrong companies or confusion with a namesake are the symptoms this work treats.
None of this requires a developer for most sites. A content management system that allows custom code in the page head, or a schema plugin that accepts custom JSON-LD, is enough. Validate each page with Google’s Rich Results Test and the Schema Markup Validator after you publish.
Start today with one page. Pick the founder or expert whose name matters most to your business, build their bio page with the ProfilePage template above, connect three articles to it by @id, and rerun those assistant questions in three months.