Author Schema: Connect Articles, People, and Expertise
Author schema is not a Schema.org type called “Author.” It is the relationship created when an Article or other CreativeWork points through the author property to a Person or Organization. Implementing it means building that small graph, aligning it with the visible byline and profile, and testing its syntax separately from the editorial claims it carries.
Build the Article-to-author edge first
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 value can be a nested entity or an identifier that resolves to the same entity described elsewhere; the choice changes representation, not the relationship.
Schema.org defines the author edge and its Person or Organization values separately from the Article and Person types. Schema.org’s Article and Person definitions explain that the vocabulary describes the asserted relationship; it does not authenticate the entity or its qualifications.
Reconcile the graph across four identity layers
The graph is only one representation of authorship. A reviewer should be able to follow the same identity through four layers without resolving contradictions by guesswork:
| 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. This layer’s job is disambiguation: stable identifiers let machines and editors follow references back to one entity rather than a namesake.
Substantiate expertise outside the markup
Once the identity is unambiguous, a different question remains: why is this person relevant to the subject? Schema.org’s Person vocabulary includes many descriptive properties, and a publisher may use knowsAbout where it accurately describes topics associated with a person. Those declarations make a claim legible; they do not independently prove expertise, authenticate the person, or create the ranking benefit that Google’s Article documentation never promises.
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. Stable identifiers do not relax that requirement: the biography and underlying identity record still have to be correct. Identity verification and editorial accountability therefore precede encoding, with syntax checked after the claims are supportable.
Use ProfilePage to complete the page-to-person topology
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 edges should terminate at 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. This decision is about page topology: choose the type that matches the visible page’s actual subject.
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.
Run three acceptance tests, in order
Implementation, feature eligibility, and editorial verification have different evidence. Run all three without allowing a pass in one column to substitute for another:
- 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. The third needs the publisher’s identity records and editorial workflow; neither technical 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. According to Google Search Central’s structured-data guidelines, its policies explicitly do not guarantee a search feature.
Maintain authorship as a governed record
Passing the three tests is a point-in-time result. Author data can later 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. Use the graph to represent identity and relationships; support expertise through the visible biography, verified records, relevant work, article evidence, and review history.
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.
Ship the smallest complete author graph: connect the Article to the accountable Person or Organization, reconcile the visible byline and profile, resolve every identifier to that entity, then retain separate receipts for code validation and editorial verification.
Frequently asked questions
How should multiple authors be represented in Article markup?
Represent each visible author as a separate Person or Organization object in the author array rather than combining several names into one name value. Google’s Article structured-data documentation uses one object per author, which preserves a distinct URL or sameAs identifier for each contributor.
Is the author property required for Google Article structured data?
Google currently lists no required properties for Article eligibility, but it recommends author, author.name, and an identifying author.url or sameAs because they help disambiguate who created the work. Treat “recommended” as an implementation priority rather than relabeling it as a syntax requirement; the current distinction appears in Google’s Article structured-data documentation.
How should credentials and job titles appear in author markup?
Keep author.name to the person’s name: put a role in jobTitle, an honorific in honorificPrefix or honorificSuffix, and the employing organization in worksFor when those visible facts are verified. Google’s author markup guidance specifically warns against placing a company or job title inside the name field.