Person Schema: How to Tell Google Who You Are

Why most Person markup does nothing

Here is the schema I find on most consultant and founder sites:

{
  "@type": "Person",
  "name": "Jane Smith",
  "jobTitle": "Marketing Consultant",
  "image": "https://example.com/jane.jpg"
}

Technically valid. Practically useless. Three problems, in order of severity:

1. No identifier. This block appears on twelve pages, so Google sees twelve unlinked mentions of somebody called Jane Smith rather than one person mentioned twelve times.
2. No corroboration hooks. Nothing points at a profile anyone else controls, so there is no way to confirm the claim.
3. No relationships. Jane is not connected to her company, her work, or a page that describes her.

Everything below is about fixing those three, in that order. Adding more descriptive properties to the block above does not help; it just makes twelve vague mentions more detailed.

Start with the identifier

An @id is a stable URI that names the node. It does not have to resolve to a page — a fragment on your domain is the conventional choice:

"@id": "https://example.com/#jane"

Two rules. Use the same @id on every page — that is what merges the mentions into one node. And never change it — changing the @id creates a new entity and discards whatever confidence the old one had accumulated.

Once the node has an identifier, every other schema block on the site can point at it by reference instead of redeclaring the person:

"author": { "@id": "https://example.com/#jane" }

This is the single highest-leverage change in this article. One node with an @id, referenced everywhere, beats a fully-described Person block copy-pasted onto every page.

The eight properties that earn their place

Two more are worth adding when genuinely true: knowsAbout for subject expertise, and address or homeLocation when location is part of how you are found. Both are easy to over-claim, so keep them narrow.

alternateName: the field people abuse

alternateName means other names this thing is genuinely called. That includes:

• Platform handles that differ from the display name — @janesmithdesign, jane_smith.
• Spelling variants forced by usernames — a one-word form of a two-word brand.
• Former names, maiden names, transliterations.
• A shortened form people actually use.

It does not include search queries. These are all misuse:

"alternateName": [
  "best marketing consultant london",   <-- a query
  "affordable SEO expert",              <-- a query
  "Jane Smith Marketing Consultant UK"  <-- a title tag
]

The reason to care is not that Google punishes it specifically. It is that alternateName is an identity signal, and filling it with non-names dilutes the one field whose entire job is telling Google what this thing is called. If every string in the list is a name, the list is evidence. If half of them are marketing copy, the list is noise.

Connecting the person to the brand

For a person-led business you want the relationship stated in both directions, so each node reinforces the other:

// on the Person
"worksFor": { "@id": "https://example.com/#brand" },
"brand":    { "@id": "https://example.com/#brand" }

// on the Organization
"founder":  { "@id": "https://example.com/#jane" },
"employee": { "@id": "https://example.com/#jane" }

worksFor alone reads as employment — true but incidental. brand is the property that says this organisation is this person’s brand, which is the actual relationship in a solo practice. Using both is not redundant; they describe different facets.

Then say it in prose as well. Put a sentence in the description of each node that names the other one. Structured data states the relationship formally; the description states it in the language a model reading your page will actually quote.

One ProfilePage, not several

ProfilePage is the page type for a page that is primarily about one person or organisation. The rule is simple and frequently broken: one per entity.

The common failure is typing both the homepage and the about page as ProfilePage for the same person. Both then claim to be the page about that person, and Google has to pick. Make the about page the ProfilePage, leave the homepage as a plain WebPage, and point at the profile from everywhere:

// on the Person, on every page
"mainEntityOfPage": { "@id": "https://example.com/about/#profilepage" }

// on the about page only
{
  "@type": "ProfilePage",
  "@id": "https://example.com/about/#profilepage",
  "isPartOf":   { "@id": "https://example.com/#website" },
  "mainEntity": { "@id": "https://example.com/#jane" }
}

Watch isPartOf — it takes a WebSite, not an Organization. Pointing it at your brand node is a type error that validators will not always flag.

Person schema on articles

On a blog post, do not describe the author again. Reference the node:

"author": { "@id": "https://example.com/#jane" }

If you want the author’s name to appear in the article block for readability, adding name alongside the @id is harmless — matching values merge cleanly. What you must not do is give the same @id conflicting values for the same property across pages. One page saying the job title is “Consultant” and another saying “Director” leaves Google holding two contradictory facts about one node.

The other half of author markup is the part schema cannot do: a visible byline, linking to the profile page, with the author’s name as the anchor text. Markup declares authorship; the link is what a crawler follows.

What to leave out

• Anything unverifiable. Awards, client lists, credentials, founding dates you cannot point at on the page. A contradiction costs more than the property gains.
• aggregateRating on a Person. Not a valid use, and a well-known source of manual actions when faked.
• Dead sameAs URLs. Audit them periodically. A 404 in sameAs is a failed corroboration attempt.
• Properties that duplicate name. givenName and familyName are fine and mildly useful; legalName on a Person is not a thing.
• Contact details you do not want scraped. Schema is public. Use a role address, not a personal one.

The standard to hold yourself to: every property in your Person schema should be something a human could confirm by reading your website. If they could not, it is not entity clarity — it is decoration with downside.

FAQ