Article Author Schema: Connecting People, Publishers and Editorial Pages

A practical guide to modelling genuine authorship across Article, Person and publisher entities, with stable identifiers, truthful profile pages and production validation.

Author markup is often implemented as an isolated Person object in an article template. That may produce valid JSON-LD, but it can leave the more important relationships unclear: who wrote the article, which page identifies that person, which organisation published it and whether those entities remain consistent across the site.

The implementation problem is therefore larger than adding an author property. A publisher needs a small, maintained identity graph that reflects the visible editorial model and remains resolvable when names, roles, URLs or CMS records change. This guide sets out that model, explains where judgement is required and provides a production validation workflow. It does not treat schema as a ranking lever, a substitute for visible authorship or proof of expertise.

Begin with the editorial relationships

An article page needs to answer two different questions:

• Who authored or contributed to this article?
• Which entity published it?

Schema.org permits an article’s author to be a Person or an Organization, and its publisher to be an Organization or a Person. See the definitions for Article and publisher. Those options describe what the vocabulary can represent; they do not determine which model is truthful for a particular publishing workflow.

In a conventional editorial setup, a named journalist or subject specialist is the author and the publishing company is the publisher. They should normally be represented as separate nodes because they answer different questions. An organisation should not replace a named person merely because it owns the website. Equally, a founder or prominent employee should not replace the publishing organisation simply because they are more recognisable.

There are legitimate exceptions. An article may carry an editorial-desk byline, be produced by an organisation or be published without a named author. The correct response is to model the actual process, not to invent a Person node to fill a template field.

The minimum useful author graph

For a named article, a practical baseline is:

• Article identifies the editorial page.
• author points from the Article to a Person.
• The Person has a consistent name and, where one genuinely exists, a url pointing to the author’s profile or editorial page.
• The Person has a stable @id that can be reused on other articles and on the author page.
• publisher points from the Article to the publishing Organization.
• The Organization has its own stable @id, name and relevant identifying details.

Google’s Article structured-data documentation supports Article, NewsArticle and BlogPosting types. It recommends properties including the author’s name, author URL, publication date and modification date where they apply. Google’s documentation lists no required properties for the Article feature, so the graph above is an implementation baseline for consistency and governance, not a Google compliance checklist.

JSON-LD provides a way to identify and reconnect nodes. The JSON-LD specification defines @id as an IRI identifying a node. A stable identifier pattern is therefore a sound production recommendation, although the exact URL structure is a site-governance choice rather than a documented Google ranking or rich-result requirement.

A synthetic example

The following example is illustrative. It does not represent Plus IQ client data.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://example.com/features/urban-tree-canopy#article",
      "url": "https://example.com/features/urban-tree-canopy",
      "headline": "How cities measure urban tree canopy",
      "author": {
        "@id": "https://example.com/authors/maya-patel"
      },
      "publisher": {
        "@id": "https://example.com/#publisher"
      },
      "datePublished": "2025-02-10",
      "dateModified": "2025-02-12"
    },
    {
      "@type": "Person",
      "@id": "https://example.com/authors/maya-patel",
      "name": "Maya Patel",
      "url": "https://example.com/authors/maya-patel",
      "sameAs": [
        "https://www.example-professional-network.test/maya-patel"
      ]
    },
    {
      "@type": "Organization",
      "@id": "https://example.com/#publisher",
      "name": "Example Review",
      "url": "https://example.com/"
    }
  ]
}
</script>

The important feature is not the number of properties. It is that the article, author page, Person node, publisher and identifiers agree. The article refers to a reusable Person node rather than describing a slightly different version of Maya Patel each time. The publisher is a separate entity, and the author URL resolves to the page that identifies the person.

Whether a site uses an @graph, nested objects or a combination of both is an implementation decision. The governance requirement is more durable: establish one identifier policy and apply it consistently across templates.

When an author-page URL is justified

Google recommends an author URL linking to a page that uniquely identifies the author. Its documentation also explains that author URLs or sameAs information can help with author disambiguation. That is identity guidance, not evidence that author markup improves rankings or guarantees authorship attribution.

Create an internal author page when the site genuinely presents the person as an author or contributor and can maintain truthful, useful information about them. A meaningful page might include:

• the person’s name as it appears in the byline;
• their editorial role or area of contribution, where this can be verified;
• a concise biography that the publisher can maintain;
• a list of relevant articles or contributions;
• links to external identity pages that have been checked;
• clear information about whether the person is a current contributor, former contributor or guest author.

The page does not need to make expansive claims about qualifications. A precise editorial description is often more defensible than a generic statement of authority. If the site cannot maintain a truthful profile, it should not create an author page merely to populate the author.url field.

Google’s ProfilePage documentation describes qualifying profile pages as pages primarily focused on one affiliated person or organisation, with the main entity representing that profile. A thin contributor index, a page containing only a name and a list of links or a generic team directory should not automatically be treated as a qualifying profile page.

Not every legitimate contributor needs an internal indexable profile. An external contributor may have a maintained profile on another site, while an anonymous or organisational byline may be better represented through the actual editorial entity. If there is no reliable identity page, prefer a limited, accurate model over a fabricated profile.

Identity evidence does not establish expertise

A Person node answers an identity question: which person is associated with this byline? It does not, by itself, establish qualifications, professional experience, affiliations, subject-matter authority, editorial review or first-hand knowledge.

This distinction matters because structured data can make an unsupported claim look official. Adding jobTitle, an affiliation or a list of credentials does not make the claim true. Represent those details only when the publisher can verify them and the visible page supports them. Google’s structured-data policies require markup to represent visible, relevant and non-misleading page content.

It is useful to govern the two categories separately:

• Identity evidence: a consistent name, a maintained author page, a stable internal identifier and carefully verified external references.
• Expertise evidence: truthful qualifications, roles, affiliations, experience, editorial responsibilities and other claims supported by the visible page and the publisher’s records.

This separation is an implementation judgement based on the limits of the vocabulary and Google’s content policies. It prevents a site from treating a successful identity match as proof of authority.

Stable identifiers, cautious sameAs links

Names alone are weak identity keys. Author-name disambiguation is a recognised entity-resolution problem, and incorrect identity links can merge distinct people or organisations. Research on entity resolution in linked data, such as this study of entity-resolution approaches, is not evidence of a Google-specific ranking effect. It does, however, support a practical warning: an incorrect equivalence assertion can be worse than an incomplete one.

Use a stable internal identifier for each maintained person record. An author URL is often a practical choice because people and systems can inspect it, but the URL must remain under change control. If a person changes their display name, do not casually replace the identifier if it still represents the same person. If two CMS records are found to represent different people, they must not be merged simply because their names match.

sameAs should be treated as a verified identity reference, not a list of plausible links. Schema.org defines sameAs as a reference page that unambiguously indicates the identity of the item; see the Schema.org Person definition. A matching name on a social network, a generic directory listing or a high-authority domain is not sufficient on its own.

Before adding a sameAs link, confirm that:

• the external page identifies the same individual;
• the person’s name, role or other details are consistent;
• the page is current and publicly accessible;
• the publisher has a legitimate basis for associating the page with the author;
• the link can be reviewed or removed when the person’s circumstances change.

A small set of strong references is safer than a large set of weak ones. Do not add links simply because they might help a search engine find a more prominent entity.

Keep author and publisher governance distinct

The publisher entity usually changes less frequently than an individual author, but it still needs a canonical identifier, name and URL policy. Decide which organisation is represented when a site contains a parent company, a consumer-facing brand, a newsroom and a legal publisher. The answer should follow the visible publishing relationship and the organisation responsible for the article, not whichever name is most convenient in the template.

Define how the site handles:

• multiple authors;
• guest contributors;
• editorial desks and department bylines;
• reviewers and fact checkers;
• commissioning editors;
• departed contributors and archived profiles;
• pseudonyms or anonymous publication.

Schema.org can describe a relationship, but it is not a complete editorial-provenance system. It does not by itself resolve ghostwriting, contribution percentages, authorship disputes, temporal employment relationships or the difference between an author and a reviewer. If the CMS currently exposes only one author field, do not silently assign every participant to author. First decide which relationships the editorial policy actually supports.

Validate the graph in production

Validation should test more than whether a JSON-LD block parses. A technically valid graph can still contain a broken author URL, a duplicated Person identifier or an unsupported profile claim.

1. Compare the byline with the markup

Check that the visible article byline, author-page name, Person.name and author URL refer to the same person. If the page says “Maya Patel” but the markup names someone else or points to a generic team page, the graph is not truthful even if a validator accepts it.

2. Inspect source and rendered HTML

If structured data is generated with JavaScript, inspect both the initial source and the rendered output. Google’s JavaScript SEO guidance explains why the final rendered page can differ from the server response. A template that looks correct in source may produce incomplete or inconsistent markup after rendering.

3. Parse the JSON-LD

Use the Schema.org Validator to extract the graph and identify vocabulary or syntax problems. Confirm that the expected Article, Person and Organization nodes exist, that references resolve to the intended nodes and that no duplicate identifiers represent the same person.

4. Resolve every important URL

Test the article URL, author URL, publisher URL and external identity references. Check redirects, canonical destinations, access restrictions, accidental noindex rules and pages that return a success status while displaying an error or empty profile. A URL is not a useful identity reference if it no longer identifies the entity it claims to represent.

5. Check Google-specific processing separately

Use Google’s Rich Results Test where relevant, and use URL Inspection when you need to examine a production URL in Search Console. These tools address Google-specific processing or eligibility questions. They do not prove that the content is truthful, that every property will be used or that a search feature will appear.

A useful QA sample should include newly published articles, articles with multiple authors, older articles, pages with changed profiles, JavaScript-rendered templates and organisational or anonymous bylines. The sample size should reflect publishing volume and deployment risk.

For a broader operational approach to monitoring structured-data changes, see the structured-data drift and production QA framework. The author-identity checks here are narrower: they focus on the relationship between people, pages and publishers.

Common failure modes

• Invented authors: a default Person is added to every article even when no real contributor exists.
• Inconsistent names: the byline, profile page and structured data use different names without a clear reason.
• Reused identifiers: several people share one @id, often because a CMS template uses a fixed value.
• Broken author URLs: the URL redirects to a team page, returns an error or no longer identifies the named contributor.
• Publisher and author conflation: the organisation is assigned as the author because it owns the site, or an individual is assigned as the publisher because they are prominent.
• Unsupported sameAs links: social or directory pages are added without confirming that they represent the same person.
• Invisible entities: markup describes qualifications, profiles or authors who are not represented on the visible page.
• Source-only validation: the initial HTML passes inspection, but the production-rendered graph is missing or different.

These are governance failures as much as coding failures. A static schema template cannot decide whether a contributor has left, whether two CMS records should be merged or whether a biography remains accurate.

Definition of done

For a named article, the implementation is ready when:

• the visible byline agrees with the Article author relationship;
• the author is represented by the correct Person or, where appropriate, organisational entity;
• the author page exists only where the publisher can maintain truthful information;
• the Person identifier is stable, unique and reused consistently;
• the publisher is represented separately with its own identifier;
• every author and publisher URL resolves to the intended page;
• sameAs references have been individually verified;
• the rendered JSON-LD parses successfully;
• the markup does not assert credentials or relationships absent from the visible page;
• the page has been checked with relevant Google tools; and
• an owner is responsible for profile, identifier and role changes.

Monitoring should focus first on implementation correctness: broken URLs, duplicate identifiers, byline mismatches, missing nodes, rendered-output differences and changes to author or publisher records. Eligibility signals and search-feature processing can be tracked where relevant, but they should not be treated as guaranteed outcomes.

The practical boundary of author schema

Structured data can help describe relationships between an article, its author, the author’s page and the publishing organisation. It cannot manufacture a genuine contributor, verify a qualification that the publisher has not checked or force a search engine to display an enhanced result.

Google states that structured data can make pages eligible for richer search appearances, but does not guarantee that an appearance will be shown. See its guidance on structured data and structured-data policies. The available evidence does not support treating author schema alone as a ranking intervention, a source of E-E-A-T, a guarantee of authorship attribution or a route to knowledge-panel inclusion.

The useful objective is more concrete: build a truthful, maintainable identity graph that agrees with the editorial page and survives production change. If the organisation needs to resolve wider entity and site-architecture questions, the related guide to entity optimisation for SEO provides broader context.