Person structured data for professional websites

Describe a person without manufacturing authority

Person structured data identifies an individual and describes supported facts about them. On a professional website, useful applications include a profile, an article’s author and a relationship to a genuine publishing organisation. The graph should make those roles clearer, not turn a short biography into a collection of unsupported credentials.

Start with the public identity the person actually uses. Verify the profile destination, byline and approved description before adding qualifications or affiliations. A claim can be technically valid JSON-LD and still be false. Terms such as expert, accredited or award-winning need evidence in the content and appropriate review; a schema property cannot supply that evidence.

The structured data overview explains the distinction between vocabulary and search features. There is no universal enhanced search appearance unlocked by adding a standalone Person node. Choose the model because it accurately represents the site’s authorship and identity, while avoiding promises of rankings, indexing, knowledge panels or AI citations.

Prepare a public identity evidence checklist

Collect the approved name, public profile URL, representative bylines, appropriate portrait and confirmed external profiles. Record the source and owner for each proposed qualification, job title or affiliation. Where information is historical, distinguish it from a current relationship. A previous employer should not silently remain the person’s present employer after a biography edit.

Keep the evidence checklist specific: identity record, visible supporting text, external destination checked, review date and publication approval. Verify same-name ambiguity. A social profile with a matching name but no clear relationship to the professional is not enough to assert identity. Review profile destinations directly rather than relying on search snippets.

Exclude private personal information unless there is an explicit, appropriate public purpose and approval. A professional profile does not need a date of birth, private telephone number or home address to be useful. The fact that Schema.org provides a property is not a reason to publish it. Omission is often the correct modelling decision.

Give the person a stable identity separate from the page

Use a stable absolute @id for the person and a separate identifier for the page where helpful. A profile URL with a #person fragment is one possible convention. Reuse that person identifier in article author references when the same individual wrote the content. Do not derive a new identity from every article headline.

The url property can point to the public profile page that helps readers identify the individual. The person and that document remain separate concepts. Distinguish the publisher as well: an organisation publishing the article is not automatically the author, and a personal site does not automatically imply a separate incorporated business.

Use organisation modelling guidance for that boundary. If two people share a name, keep distinct identifiers and verified profiles rather than merging by display text. If a person changes their public name, preserve identity continuity where appropriate and update supported public facts without retaining an inaccurate name merely for keyword consistency.

Apply ProfilePage only when the page has that purpose

ProfilePage describes a page whose primary focus is one person or organisation. Google’s guide requires that entity to be affiliated with the overall website and gives author pages, employee pages and an about-me page as relevant examples. A general service landing page or a multi-person directory does not automatically meet that purpose.

For an applicable profile, mainEntity identifies the person the page is about. Google’s requirements include identification of that entity through name, with an alternateName fallback in the documented circumstances. Review the current guide rather than copying every social-platform statistic into a professional biography. Only include information relevant to the actual profile.

Treat dates carefully. A profile modification date should reflect a genuine relevant update, not automatically reset whenever the website is rebuilt. Do not add default portraits or placeholder images where no suitable profile image exists. The model should describe the published profile faithfully, without using unrelated assets or fabricated activity to make it appear more complete.

Connect genuine authorship and external identity carefully

Article author data should agree with the visible byline and point to the intended person. If several people genuinely authored the piece, represent them accurately rather than assigning every guide to a site-wide default. Editorial review and authorship are different contributions; use relationships that match the actual publishing process.

Use sameAs for external pages that identify the same person. A company homepage, conference category or topic archive does not automatically identify an individual. Keep verified links current and remove destinations that have changed ownership or no longer represent the person. More links do not inherently create a stronger identity claim.

Generate shared identity facts from one approved record and page-specific authorship from the article record. The JSON-LD implementation guide covers references and encoding. Avoid importing an entire external profile into the graph without review. Public availability of a statement elsewhere does not establish that it is current, accurate or appropriate to republish on the professional site.

Illustrative worked example: profile and guide author

This example uses the fictional professional Morgan Ellis at a reserved example domain. It demonstrates the separation between a profile document and its subject, not a full feature guarantee or a real client implementation. The visible about page contains Morgan’s approved public name and biography.

{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "@id": "https://example.com/about/#profile",
  "url": "https://example.com/about/",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://example.com/about/#person",
    "name": "Morgan Ellis",
    "url": "https://example.com/about/"
  }
}

A guide genuinely written by Morgan references https://example.com/about/#person as its author identity and visibly links the byline to the profile. Acceptance checks both records, their distinct identifiers and the correspondence with published attribution. No employer, award or external identity link is added without evidence. A passing graph demonstrates the intended relationship; it does not prove professional authority or an external system’s recognition of that person.

Investigate wrong identity and missing detection systematically

If an author appears to be associated with the wrong person, consider an identifier collision, incorrect profile URL, default template assignment or ambiguous external link. Compare the approved author record with the visible byline and all emitted nodes. Do not respond by adding several speculative sameAs links in the hope that an external system chooses the right one.

If a Google test detects no relevant item, consider tool scope, page purpose and delivery before concluding that Person is invalid. A standalone vocabulary node and a supported ProfilePage implementation are different tests. Inspect raw and rendered output when a client application may retain the previous route’s author.

Use layered validation to preserve these distinctions. Confirm whether the actual profile meets the relevant content guidance, not just the property list. A page containing the person’s name among many unrelated offers may fail the intended profile purpose even when its JSON parses. Keep technical detection separate from factual and editorial approval.

Set acceptance criteria for identity and attribution

Require the correct person identifier, approved public name and intended profile destination across every tested template. All authorship references must match actual contributions and visible bylines. Every credential or affiliation needs a documented source. Missing optional fields should be omitted cleanly rather than replaced with placeholders or invented biographical detail.

For a ProfilePage implementation, check the current required relationships and identification fields, then verify the page’s primary purpose and website affiliation. Test a normal profile, an author with limited optional information and two authors sharing a name. These cases expose default assignment and merge problems that a single fully populated record will not show.

Confirm deployed output after navigation and cache changes where relevant. Compare profile modification dates with genuine content updates. The acceptance record should explain excluded fields and unresolved identity ambiguity. A release should not publish a guessed external link or qualification simply because an automated validator cannot distinguish it from an accurate value.

Maintain identity through profile changes and migrations

Preserve a mapping of person identifiers, profile URLs and article references before migrating author pages. Redirect document URLs appropriately where needed and update the graph coherently. An identifier migration is a modelling decision that requires deliberate reference updates; it should not occur accidentally because a template starts using a different path field.

If a release assigns the wrong author or publishes unsupported claims, correct the source record or restore the responsible generator. Recheck the public page and all affected bylines. An old biography may contain outdated employment or contact information, so blindly restoring a previous data version can create another factual error even if its syntax is valid.

Use structured data deployment QA to retain identity fixtures and rollback evidence. Keep the person’s public profile accurate as their work changes. Person markup cannot certify expertise, replace substantive authorship or guarantee a search feature. Its defensible purpose is a maintained, truthful description of who the site says created or represents its content.