How to Add Person Schema for Executives and Authors: ProfilePage, Author Markup and a JSON-LD Template

What Is Person Schema?

Person schema is schema.org markup, usually written as JSON-LD, that describes a specific person — their name, job title, employer, photo, profile URL and other official profiles — in a form search engines can parse.

schema.org defines Person as “A person (alive, dead, undead, or fictional)” (schema.org/Person). Google uses Person markup in two documented places that matter for executives and authors: as the mainEntity of ProfilePage structured data on a bio or author page, and as the author of Article structured data. This guide covers both and how to connect them to your company's Organization markup.

What Person Schema Does and Does Not Do

Person markup states who someone is; it does not make Google show anything. Google's documentation supports these points (all read October 7, 2026):

• It helps Google understand creators and authors. Google says ProfilePage markup “helps Google Search understand the creators that post in an online community”, and that for Article authors “Google can understand both sameAs and url when disambiguating authors” (ProfilePage; Article, both last updated September 8, 2026).
• It does not guarantee any search feature. “Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly according to the Rich Results Test” (General structured data guidelines).
• It does not create a knowledge panel. Google's Knowledge Panel Help says information in a panel “generates automatically based on public information on the web” and that Google's current policy “doesn't manually create or delete Knowledge Panels” (Knowledge Panel Help). For what you can do once a panel exists, see how to claim and update your Google knowledge panel.
• It is not required for AI features. For AI Overviews and AI Mode, Google says “There's also no special schema.org structured data that you need to add” (AI features and your website). No markup guarantees that an AI system mentions an executive.
• It is not E-E-A-T. Markup can label an author; it cannot supply experience or expertise. Our explainer What is E-E-A-T? covers what Google actually says about that concept.

How to Add Person Schema at a Glance

Time: 30–60 minutes per person once the bio page exists (our estimate). Tools: CMS or template access, a text editor, the Rich Results Test, the Schema Markup Validator, Google Search Console. Cost: none. Skill level: beginner to intermediate.

What You Need Before Starting

• A page on your own site for each person: a leadership bio, an author page or an “About” page.
• The person's real name as they want it shown, current job title, and a short factual description.
• A real headshot at a public URL (Google says not to use a placeholder if there is no image).
• URLs of profiles the person controls or that clearly identify them: LinkedIn, a Wikidata item or Wikipedia article if one exists, an official social account, a personal site.
• Your company's name and home page URL, ideally with existing Organization schema markup.
• Edit access to your article template if the person writes bylined content.
• A verified Search Console property for Step 7.

Step 1: Create One Profile Page per Person

Create a dedicated bio page for each executive or author, at a stable URL such as /leadership/jane-doe or /authors/jane-doe. Google's ProfilePage content guidelines say “The primary focus of the page must be a single person or organization that is affiliated with the overall website.” Its listed valid use cases include “An author page on a news site”, “An ‘About Me’ page on a blog site” and “An employee page on a company website”.

Why: a page about one person is the page Google describes for ProfilePage, and it gives your article bylines a single URL that identifies the author. Expected result: one URL per person. How to verify: the page would still make sense if every other person were removed from it. Common mistake: marking a team page that lists ten executives as one ProfilePage; that page has no single primary focus. See how to choose where to place it for team pages.

Step 2: Put the Facts on the Visible Page

Write the name, job title, photo, short bio and profile links into the page that readers see before writing any markup. Google's general guidelines say “Don't mark up content that is not visible to readers of the page” and that structured data “must be a true representation of the page content” (General structured data guidelines).

Why: markup that describes facts the page does not show is a policy problem, not a shortcut. Expected result: every value you plan to put in JSON-LD appears on the page. How to verify: read the page with the markup removed; nothing in your template should be new information. Common mistake: listing awards, credentials or past employers in markup that the bio never mentions.

Step 3: Add ProfilePage JSON-LD With a Person as mainEntity

Add a ProfilePage block whose mainEntity is a Person. Google lists mainEntity as the only required ProfilePage property and name as the only required Person property; dateCreated, dateModified, alternateName, description, identifier, image, sameAs and interaction statistics are recommended (ProfilePage structured data). schema.org adds properties Google does not list but that describe an executive accurately, such as jobTitle (“The job title of the person”), worksFor (“Organizations that the person works for”) and url (schema.org/Person).

A template for a company leadership page (replace every example value):

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "dateCreated": "2025-03-01T09:00:00-05:00",
  "dateModified": "2026-10-07T09:00:00-04:00",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://www.example.com/leadership/jane-doe#person",
    "name": "Jane Doe",
    "jobTitle": "Chief Executive Officer",
    "description": "Chief Executive Officer of Example Company since 2021.",
    "image": "https://www.example.com/images/people/jane-doe.jpg",
    "url": "https://www.example.com/leadership/jane-doe",
    "worksFor": {
      "@type": "Organization",
      "name": "Example Company",
      "url": "https://www.example.com/"
    },
    "sameAs": [
      "https://www.linkedin.com/in/janedoe-example",
      "https://www.wikidata.org/wiki/Q00000000",
      "https://x.com/janedoe_example"
    ]
  }
}
</script>

Property notes from the source documents:

Why: ProfilePage tells Google the page is about this person; Person says who they are. Expected result: one JSON-LD block in the page's HTML. How to verify: view the page source and confirm the script is present in the served HTML. Common mistake: putting the job title or “Dr” inside name; Google's author guidance says to use jobTitle and honorificPrefix instead.

Step 4: Add sameAs Links to Official Profiles

List, in sameAs, the external URLs that identify this same person. schema.org's examples are “the URL of the item's Wikipedia page, Wikidata entry, or official website” (schema.org/sameAs); Google's ProfilePage definition is “other external profiles or home pages for the profile”.

Why: Google says it can use sameAs and url “when disambiguating authors”, which matters most when the executive shares a name with someone else. Expected result: an array of absolute URLs, each of which loads and plainly refers to this person. How to verify: open each link in a private window. Common mistake: linking to a namesake's Wikipedia article, a search results page, or a profile the person no longer uses. If the person has no Wikidata item, do not invent one for the markup; our founder authority footprint guide covers building real third-party profiles first.

Step 5: Connect the Person to Your Company and Their Articles

Link the Person to the company with worksFor, and link every article the person writes back to the bio page with author.url. For articles, Google's author markup best practices say:

• “Make sure that all the authors that are presented as authors on the web page are also included in markup.”
• List each author in their own author entry; don't merge names into one field.
• “[W]e strongly recommend using the type and url (or sameAs) properties.”
• In author.name, “only specify the name of the author” — no publisher name, job title, honorifics or “posted by”.
• “Use the Person type for people, and the Organization type for organizations.”

Google adds that if author.url is an internal profile page, “we recommend marking up that author using profile page structured data” — which is the page from Step 3. In the article's JSON-LD:

"author": [{
  "@type": "Person",
  "name": "Jane Doe",
  "jobTitle": "Chief Executive Officer",
  "url": "https://www.example.com/leadership/jane-doe"
}]

Why: the byline, the bio page and the company markup then describe one consistent person. Expected result: every bylined article's author.url points to the same bio URL. How to verify: test two or three articles and check the author URL in each. Common mistake: ghost-written posts marked up with an executive's name that the page does not show. Our Article structured data guide covers the rest of the article block, and author and expert bylines covers why named authorship matters.

Step 6: Test in the Rich Results Test and Schema Markup Validator

Paste the bio page's URL or code into Google's Rich Results Test, then into the Schema Markup Validator. Google's ProfilePage guide says to “Validate your code using the Rich Results Test and fix any critical errors”, and that fixing non-critical issues “isn't necessary to be eligible for rich results”.

Why: the Rich Results Test checks what Google supports; the Schema Markup Validator checks properties such as jobTitle and worksFor against schema.org generally. Expected result: a profile page item detected with no critical errors, and the Person with all your properties parsed. How to verify: expand the detected item and check that name, image and sameAs values are exactly what you intended. Common mistake: treating a clean test as a promise of display; Google says a correctly marked-up page still may not show structured-data features.

Step 7: Deploy and Inspect the Live URL

Publish the page, then inspect it with the URL Inspection tool in Search Console. Google says to deploy a few pages first and make sure the page is “not blocked by a robots.txt file, the noindex tag, or login requirements”, and to allow time: “it may take several days after publishing a page for Google to find and crawl it.”

Why: markup on a page Google cannot crawl or index does nothing. Expected result: the live test shows the page can be indexed and lists the detected structured data. How to verify: see How to verify it worked. Common mistake: bio pages set to noindex by a CMS default for “author archives”.

How to Verify It Worked

• Rich Results Test: the live URL shows a detected profile page item with no critical errors.
• URL Inspection (live test): the page is reported as indexable, and the rendered HTML contains your JSON-LD block.
• Schema Markup Validator: the Person node shows name, jobTitle, worksFor, image, url and sameAs with no errors.
• Article pages: two or three tested articles show the author as a Person whose url is the bio page.
• Over time: Google says to look for issues in “the relevant Rich result status report” in Search Console after indexing; ideally valid items increase and invalid items do not.

What you will not see is a confirmation that Google has “accepted” the person as an entity. No Google tool reports that.

How to Choose Where to Place Person Schema

schema.org defines founder as “A person or organization who founded this organization” and employee as “Someone working for this organization” (schema.org/Organization).

Common Problems and Fixes

What Not to Do

• Don't mark up a person the page does not show. Consequence: markup that misrepresents the page can lead to a structured data manual action, which removes rich-result eligibility. Correction: put the facts on the page first (Step 2).
• Don't stuff name. “Jane Doe, CEO, Example Company” breaks Google's author guidance. Correction: name in name, title in jobTitle, employer in worksFor.
• Don't add sameAs links that point to someone else or to unofficial pages. Consequence: you assert the wrong identity. Correction: only profiles that clearly refer to this person.
• Don't use ProfilePage on the home page or a multi-person team page. Google lists “The main home page of a store” as an invalid use case. Correction: individual bio pages.
• Don't promise executives a knowledge panel or AI mention from markup. Google documents neither outcome. Correction: treat markup as accurate labelling, and build the third-party coverage that public information comes from.
• Don't leave stale titles. An executive who changed roles but still shows the old jobTitle in markup sends a contradictory signal. Correction: update the page and dateModified together.

Frequently Asked Questions

Sources and Methodology

We read each source below on October 7, 2026 and quoted it directly. We did not run a test site or measure the effect of Person markup on search results; the time estimate is ours. Google changes structured data documentation often, so check the “last updated” date on each Google page. The example names and URLs in the templates are placeholders.

1. official Google Search Central, Profile page (ProfilePage) structured data, last updated September 8, 2026. Read October 7, 2026.
2. official Google Search Central, Article structured data, including author markup best practices, last updated September 8, 2026. Read October 7, 2026.
3. official Google Search Central, General structured data guidelines. Read October 7, 2026.
4. official Google Search Central, AI features and your website, last updated December 10, 2025. Read October 7, 2026.
5. official Knowledge Panel Help, Submit feedback on content about you. Read October 7, 2026.
6. official Search Console Help, URL Inspection tool and Rich Results Test. Read October 7, 2026.
7. official schema.org, Person, sameAs and Organization. Read October 7, 2026.
8. official Schema Markup Validator. Referenced October 7, 2026.