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.

Schema.org defines author as a property, Article as a CreativeWork type, and Person as an entity type. The vocabulary describes relationships; it does not verify that the supplied identity or qualifications are true.

Keep four layers consistent

An author relationship works only when several representations agree:

LayerWhat it should sayControl question
Visible bylineThe accountable person’s or organization’s nameCan a reader see who owns the article?
Article structured dataauthor pointing to the same entityDoes the machine-readable relationship match the byline?
Author profileRole, biography, relevant work, disclosures, and review responsibilityCan a reader inspect why this author is relevant?
Entity referencesStable internal URL and carefully chosen external identity linksDo 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:

  1. Syntax: does the JSON-LD parse and use valid types and values?
  2. Search-feature eligibility: does the page follow the supported properties and policies documented by the search engine?
  3. 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.

Google documents author identifiers for Article, mainEntity for ProfilePage, and visibility and relevance requirements across structured data. Its policies explicitly do not guarantee a search feature.

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.

The decision
Represent the smallest truthful graph: the Article points to the real accountable Person or Organization, the visible byline agrees, the profile supplies verifiable context, and every identifier resolves to the same entity. Validate the code, but govern the truth.

Sources

  1. Schema.org, “authorSupports: author is a Schema.org property; The property's expected values include Organization and Person; The property can apply to CreativeWork and Rating. Checked 2026-08-24.Limitation: Schema.org vocabulary definitions do not guarantee search-engine features or validate the truth of supplied values.
  2. Schema.org, “ArticleSupports: Article is a CreativeWork type; Article can use inherited CreativeWork properties including author. Checked 2026-08-24.Limitation: The vocabulary is broader than the properties a specific search feature may consume.
  3. Schema.org, “PersonSupports: Person is a Schema.org type with identity and relationship properties; Properties can connect a person to pages and other entities. Checked 2026-08-24.Limitation: A declared Person property is descriptive data, not independent verification of identity or expertise.
  4. Google Search Central, “Article structured dataSupports: Google documents author markup for Article pages; Google recommends author name and a URL or sameAs value that identifies the author; Correct properties can help Google understand article pages. Checked 2026-08-24.Limitation: Google does not guarantee display of a search feature, and its supported-property guidance is a subset of Schema.org.
  5. Google Search Central, “ProfilePage structured dataSupports: ProfilePage applies when a page's main focus is one person or organization; The mainEntity relationship identifies the profiled entity. Checked 2026-08-24.Limitation: ProfilePage eligibility and valid markup do not independently authenticate a person's claims.
  6. Google Search Central, “General structured data guidelinesSupports: Structured data must represent the page and should not mislead users; Markup should describe visible, relevant content; Correct markup does not guarantee a rich result. Checked 2026-08-24.Limitation: The policies govern Google search features and do not replace legal, identity, or editorial verification.

Continue the evidence path

Run your growth team from one screen.

Invite only