Author Schema Explained: How Person, expertise, and Article relationships are represented
“Author schema” is not a Schema.org type. It is an informal name for structured data that connects an Article or another CreativeWork to a Person or Organization through the author property. Expertise is represented through accurate identity, visible biography, relevant work, and corroborating links around that relationship—not through a magic expertise field or markup that makes an unsupported claim true.
Model authorship as a relationship
Schema.org defines author as a property whose expected values include Person and Organization. Article is a type under CreativeWork, so it can use that inherited property. The basic graph is:
Article --author--> Person
or, when the accountable author is genuinely an organization:
Article --author--> Organization
That distinction corrects a common implementation error. A page does not receive an Author type. It declares an Article entity and supplies an author value. The author value can be a nested entity or an identifier that resolves to the same entity described elsewhere.
Keep four layers consistent
An author relationship works only when several representations agree:
| Layer | What it should say | Control question |
|---|---|---|
| Visible byline | The accountable person’s or organization’s name | Can a reader see who owns the article? |
| Article structured data | author pointing to the same entity | Does the machine-readable relationship match the byline? |
| Author profile | Role, biography, relevant work, disclosures, and review responsibility | Can a reader inspect why this author is relevant? |
| Entity references | Stable internal URL and carefully chosen external identity links | Do identifiers resolve to the same entity rather than a namesake? |
Google’s Article structured-data documentation recommends author name and a URL or sameAs value that identifies the author. The purpose is disambiguation. A URL should not be added merely because it mentions someone with the same name.
Use one canonical internal author URL where possible. If several articles point to slightly different Person nodes—one with a shortened name, one with a job title as the name, and one with an unrelated social URL—the graph becomes ambiguous. Stable identifiers help machines and editors refer to one entity, but the underlying content must still be correct.
Expertise is evidence, not a declared result
Schema.org’s Person vocabulary includes many descriptive properties. A publisher may also use knowsAbout where it accurately describes topics associated with a person. None of these declarations independently proves expertise, and Google’s Article documentation does not promise a ranking benefit from an expertise label.
Represent expertise through an evidence chain:
- a visible biography states the person’s current role and relevant domain;
- the article’s subject falls within that disclosed domain;
- cited work, credentials, publications, or professional records are linked only when verified;
- the article itself provides sources, qualifications, and a current review record; and
- material conflicts, affiliations, or AI assistance are disclosed under editorial policy.
Structured data can make a claim legible to machines. It cannot make an inaccurate biography, borrowed credential, or fictitious author true.
Google’s general structured-data policies require markup to represent relevant visible content and warn against misleading data. Correct syntax is therefore the last check, not the first. Identity verification and editorial accountability precede encoding.
Use ProfilePage for the page whose main subject is the author
An author biography page can use ProfilePage when its main focus is one person or organization. Google’s ProfilePage documentation uses mainEntity to identify that subject. The Article page and profile page then express complementary relationships:
Article --author--> Person
ProfilePage --mainEntity--> Person
Both should point to the same Person identity. ProfilePage is not required merely because an author URL exists, and it should not be applied to a staff directory whose main subject is a collection of people. Choose the type that matches the visible page.
Organization authorship needs the same care. Use an Organization when the content is truly produced and owned collectively under an institutional editorial process. Do not use a company name only to avoid naming the human reviewer when individual accountability matters. The visible byline, editorial policy, and structured data should tell the same story.
Validate syntax, eligibility, and truth separately
Three tests answer different questions:
- Syntax: does the JSON-LD parse and use valid types and values?
- Search-feature eligibility: does the page follow the supported properties and policies documented by the search engine?
- Editorial truth: do the visible page, identity records, sources, and review workflow support every declared fact?
A schema validator can help with the first. Google’s Rich Results Test and Search Console can help observe the second for supported features. Neither tool performs a background check or confirms that an author wrote or reviewed the work.
Google also states that correct structured data does not guarantee a rich result. Search systems choose features according to multiple conditions. Avoid reporting a successful validation as a promised display, ranking improvement, or AI citation outcome.
Govern changes as identity changes, not page decorations
Author data can become stale when a person changes role, a profile URL moves, a credential expires, or an article receives a new reviewer. Record an owner and review triggers for:
- a byline or responsible organization change;
- an author profile URL or canonical identifier change;
- a role, credential, affiliation, or disclosure change;
- a substantive article revision that changes required expertise; and
- a structured-data specification or search-feature update.
Do not silently transfer old articles to a new author for consistency. Preserve the original authorship record and add review or update accountability according to the editorial policy. If the publisher cannot verify who wrote or reviewed an article, say so internally and repair the record rather than inventing a Person node.
Common questions about author schema
Is Author a Schema.org type?
No. author is a property. Its value can be a Person or Organization connected to an Article or another supported CreativeWork.
Which author properties does Google recommend for Article?
Google documents the author’s name and recommends a URL or sameAs identifier. Apply only the properties relevant to the visible, verified author.
Can author schema prove expertise?
No. It can represent identity and relationships. Expertise remains an editorial and evidentiary claim that must be supported outside the markup.
Does valid author markup guarantee a rich result or higher ranking?
No. Google explicitly says correct structured data does not guarantee display. This source set provides no verified ranking uplift benchmark.
Sources
Continue the evidence path
Related reading
Related
Entity SEO: Make Brand, Product, and Method Relationships Explicit
Connect Author Schema Explained: How Person, expertise, and Article relationships are represented with Entity SEO: Make Brand, Product, and Method Relationships Explicit to compare two AI Citation Structuring decisions without collapsing their different evidence and implementation boundaries.
Related
Knowledge Graph SEO Explained: Entity signals, relationships, and the role of consistent evidence
Connect Author Schema Explained: How Person, expertise, and Article relationships are represented with Knowledge Graph SEO Explained: Entity signals, relationships, and the role of consistent evidence to compare two AI Citation Structuring decisions without collapsing their different evidence and implementation boundaries.