schema.org/ProfilePageNo rich result
ProfilePage schema
A page whose subject is one person or organisation, rather than a topic.
Where to use it
Author pages, team member pages.
A complete example
Valid as written, with every required property and the recommended ones that carry real information.
profile-page.json
{
"@context": "https://schema.org",
"@type": "ProfilePage",
"mainEntity": {
"@type": "Person",
"name": "A Real Person",
"url": "https://www.seoforsolos.com/about"
},
"url": "https://www.seoforsolos.com/example",
"name": "Acme Reference",
"dateModified": "2026-07-27T00:00:00.000Z"
}Properties
| Property | Status |
|---|---|
mainEntity | Required |
url | Recommended |
name | Recommended |
dateModified | Recommended |
The three mistakes this type attracts
- 01mainEntity as a string rather than a Person node.
- 02Using it for a page that is not primarily about one entity.
- 03Omitting dateModified on a profile that changes.
Related types
Where this appears in the playbook
- Structured data: what each type is for and which ones earned their place.
- The schema graph: composing types into one graph with stable identifiers.
- One JSON-LD script per page, holding one @graph
- Stable @id anchors that cross-reference rather than duplicate
- Optional fields are omitted, never emitted as empty strings
Questions
What is the ProfilePage schema type for?
A page whose subject is one person or organisation, rather than a topic. Use it on: author pages, team member pages.
Which ProfilePage properties are required?
ProfilePage requires one property: mainEntity. It also recommends 3: url, name, dateModified.
Does ProfilePage produce a rich result?
ProfilePage does not produce a Google rich result. It is still worth shipping, because its value is entity resolution and answer extraction rather than search result presentation.
What is the most common ProfilePage mistake?
The most common ProfilePage mistake is: mainEntity as a string rather than a Person node.