AI Summary
Person schema is the structured data implementation that turns an author byline into a machine-resolvable entity. AI engines use it to verify that the person named in your article is a real, credentialed individual whose identity can be confirmed across external sources. Without it, the author is a string of text; with it, the author is a node in the knowledge graph.
This is the implementation guide. The why AI weights author signals and the broader E-E-A-T entity infrastructure are covered in our dedicated E-E-A-T guide. The headshot and visual consistency angle is covered separately. This post owns the schema: which properties, what JSON-LD, where to deploy, how to link author pages to article pages with @id, and the mistakes that produce orphan nodes.
Why Person schema matters for entity resolution
AI retrieval systems face a disambiguation problem at scale. When the same name appears across thousands of pages, the system must decide whether “Jane Doe” on your site is the same person as “Jane Doe” on LinkedIn, in a conference speaker listing, and on a journal byline. Person schema solves this by giving the entity a canonical URL (@id) that other schema blocks can reference. The @id is the anchor for the entire author entity graph.
In our May 2026 study of 153,425 AI citations, 74.9% of cited sentences appeared in the first half of documents. Pages with named, schema-attributed authors whose entity records can be resolved perform better in AI retrieval than pages with generic bylines. The mechanism is entity resolution, not author fame. A resolvable entity with modest external presence outperforms an unresolvable entity with a strong reputation, because the AI engine cannot confirm what it cannot find in the graph.
Schema.org/Person is deployed on 10M+ domains per Google’s May 2026 web index. It is a well-established signal that AI engines actively parse. The properties you choose determine how much of the entity graph the engine can populate from your markup alone.
The properties that matter: verified against schema.org/Person
These are the schema.org/Person properties with the highest signal value for AI entity resolution, verified against the schema.org specification:
| Property | Expected Type | Why it matters for AI |
|---|---|---|
| @id | URL | The canonical identifier for the Person entity. Every Article schema author property should reference this URL. Without @id, you cannot close the entity loop across pages. |
| name | Text | Must exactly match the byline format used across all articles and all external profiles. Inconsistency fragments the entity. |
| url | URL | The author page URL. Should match @id. Points crawlers and entity resolution systems to the canonical author record. |
| image | URL or ImageObject | Feeds the Knowledge Panel image. Enables visual entity corroboration across sources. See our headshot guide for the full consistency playbook. |
| jobTitle | Text or DefinedTerm | A parseable expertise signal. “Director of SEO” tells the knowledge graph what this person knows and what queries they are credible for. |
| worksFor | Organization | Links the Person entity to an Organization entity. The Organization should have its own schema block. This cross-reference builds entity graph depth. |
| alumniOf | EducationalOrganization or Organization | Adds a verifiable credential. AI engines can cross-reference alumni records at universities and professional bodies. |
| knowsAbout | Text, Thing, or URL | Declares topical authority explicitly. Use the specific topics this author covers. Helps query-to-author matching for specialized content. |
| sameAs | URL (array) | The most critical property for entity disambiguation. Links the author record to verified external profiles the engine can check. Covered in detail below. |
Properties to skip
Do not add properties you cannot populate accurately. An empty or placeholder alumniOf or a generic knowsAbout: ["SEO"] adds noise rather than signal. Every property you include should contain a value that an AI engine can verify against an external source.
Full JSON-LD example: author page
Deploy this in a <script type="application/ld+json"> tag in the <head> of the author page. The @id value must be the stable, canonical URL for this author. It must not change after publication.
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://example.com/authors/jane-doe/",
"name": "Jane Doe",
"url": "https://example.com/authors/jane-doe/",
"image": "https://example.com/images/jane-doe.jpg",
"jobTitle": "Director of SEO",
"worksFor": {
"@type": "Organization",
"name": "Example Corp",
"url": "https://example.com"
},
"alumniOf": {
"@type": "EducationalOrganization",
"name": "University of Example"
},
"knowsAbout": [
"Technical SEO",
"AI Search Optimization",
"Content Strategy"
],
"sameAs": [
"https://www.linkedin.com/in/jane-doe/",
"https://orcid.org/0000-0000-0000-0000",
"https://twitter.com/janedoe"
]
}Key implementation notes: the @id uses the author page URL as the canonical identifier. The worksFor block references the Organization by URL so the engine can follow the link and resolve the org entity. The knowsAbout array contains specific topic strings, not vague categories. The sameAs array contains the author’s LinkedIn profile, an ORCID identifier if applicable, and their Twitter/X profile.
Article schema: referencing the author @id
Every article published by this author must carry Article schema with an author property that references the Person @id. This is what closes the entity loop: the Article points to the Person, the Person has a home page, the home page has sameAs links, and the AI engine can traverse the full chain.
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Your Article Title",
"author": {
"@type": "Person",
"@id": "https://example.com/authors/jane-doe/"
},
"publisher": {
"@type": "Organization",
"name": "Example Corp",
"url": "https://example.com"
},
"datePublished": "2026-01-15",
"dateModified": "2026-06-01"
}The author object in Article schema uses only @type and @id. Do not repeat all the Person properties on every article page. The @id reference is sufficient. The engine follows the @id to the author page where the full entity record lives. Repeating properties inconsistently across hundreds of article pages creates entity fragmentation, not reinforcement.
Where to deploy Person schema
Person schema belongs in three places. Each serves a distinct function in the entity graph.
- Author archive pages (/authors/name/). This is the canonical entity home. Full Person schema with all properties goes here. The @id for this author points to this URL. All Article schema author properties on the site reference this URL. Our E-E-A-T author guide covers what the author page must contain beyond schema: bio copy, credential signals, and publication archive.
- Individual article pages. Article schema with the author property referencing the Person @id. Do not embed full Person schema here; only the @id reference. Keep the canonical entity record on the author page alone.
- Organization team or about pages. If your site has a team page listing contributors, each team member listed can carry a minimal Person schema block with name, jobTitle, url (pointing to their author archive), and sameAs. This adds an additional cross-reference point the engine can discover during crawl.
Validate every deployment with the Schema Markup Validator. Errors in JSON-LD (unclosed brackets, wrong property types) silently invalidate the entire block. The validator catches these before they reach the search engine’s parser.
sameAs strategy: which profiles count
The sameAs array is where Person schema does its heaviest disambiguation work. Each URL is a profile the engine can check to corroborate the author’s identity. Our guide on sameAs for entity disambiguation covers the full ranking. For author entities specifically, the priority order is:
- LinkedIn profile URL. The highest-value anchor for professional and B2B contexts. The engine cross-references name, job title, and company affiliation. The LinkedIn bio must match the author page schema exactly; inconsistency creates entity fragmentation.
- ORCID (orcid.org/0000-xxxx). Essential for academic, medical, and scientific authors. ORCID is the globally recognized researcher identifier used by journals and institutions. Skip it for non-academic authors; a placeholder ORCID adds no signal.
- Wikidata entity URL (wikidata.org/wiki/Q…). Directly readable by AI knowledge graphs. Include it if the author has an entry. Do not fabricate one.
- Twitter/X profile. Lower entity-resolution weight than LinkedIn or ORCID. Include only if the account is active and the bio matches the author page.
- Personal site or authoritative profile. A personal domain, GitHub profile (for developer authors), or conference speaker page. Each additional corroboration point reduces identity fragmentation risk.
Do not list every social profile in sameAs. Include only profiles that are active, accurate, and where the bio matches your site. A sameAs link to an abandoned Twitter account with a different job title creates contradictory entity signals, not reinforcing ones.
Common mistakes that produce orphan nodes
In our GEO audits, the same Person schema failures appear repeatedly. Each one produces an orphan node: a Person entity the engine cannot connect to the rest of the graph.
- Missing @id on the Person block. Without @id, the Article schema author property has nothing to reference. You end up with a Person entity that exists on the author page but cannot be linked from any article. Every Article schema on the site then fails to close the author attribution loop.
- Inconsistent name strings across pages. “Jane Doe” on the author page, “J. Doe” in the Article schema author name, and “Jane M. Doe” on LinkedIn are three different entity nodes from the engine’s perspective. Use exactly one canonical name string everywhere: in schema, in bylines, and in all external profiles.
- Full Person schema repeated on every article page instead of @id reference. This creates multiple competing entity definitions. When properties differ between pages (different jobTitle, different sameAs), the engine must choose which version to trust. It frequently resolves this by reducing confidence in the entity, not by picking the best version.
- sameAs pointing to profile URLs that redirect or return 404. A broken sameAs link is worse than no sameAs link. It signals an entity that was once resolvable and no longer is, which reduces entity trust. Audit sameAs URLs quarterly. LinkedIn, in particular, occasionally changes profile URL formats.
- No Article schema on article pages, only Person schema on the author page. The author entity exists but nothing links articles to it. The engine sees a Person node with no associated content. The citation value of the entity is effectively zero for individual articles. Both ends of the link must be implemented for the entity graph to function.
Connecting Person schema to the broader entity stack
Person schema is one layer of a stacked entity signal architecture. The Organization entity in the knowledge graph establishes your brand. The Person entity ties named individuals to that organization. The Article schema on each post attributes content to the Person. All three must be present and cross-referencing each other for AI citation to be consistent rather than occasional. The most common gap we see in audits is a recognized brand entity with articles attributed to “Team” or a first-name byline with no schema. The fix is always the same: build the author page, add Person schema with @id and sameAs, update Article schema on existing posts, and standardize the byline format site-wide.
For founder-led brands, the founder is the highest-leverage author entity investment. The entity SEO guide covers how Person entities interact with the Organization entity for maximum knowledge graph density. Track citation returns using our open-source GEO/AEO Tracker. If the rate is not moving after 4-6 weeks post-implementation, audit the @id linkage first, then sameAs URL validity, then external profile consistency. Our GEO audit includes a full schema markup and entity review as a standard component.