Article schema with author: the Person markup and the bio page behind it

Google lists no required Article properties, but author is the one worth doing properly. Working BlogPosting and ProfilePage JSON-LD, Google's own author rules, and what the markup can't do.

· Updated 11 min read

If your Article markup says "author": "Jane Doe", replace the string with an object:

{
  "author": {
    "@type": "Person",
    "name": "Jane Doe",
    "url": "https://example.com/authors/jane-doe"
  }
}

That one change is what most sites are missing. It follows Google's Article structured data documentation: give the author a type, put only the name in name, and add a url (or sameAs) that leads somewhere describing the person. The url should open a real author page, which is the second half of the job and has its own markup.

What Google requires, and what it only recommends

Less than most guides claim. Google's documentation says: "There are no required properties; instead, add the properties that apply to your content." It then recommends five:

  • author, with author.name and author.url
  • headline
  • image
  • datePublished
  • dateModified

Leaving any of them out doesn't make the markup invalid. @context and @type are a different matter: without them the block isn't schema.org at all.

publisher, mainEntityOfPage and description are valid schema.org and harmless to include, but they aren't on Google's recommended list and nothing flags their absence. If your CMS emits them, leave them. If you're writing markup by hand, spend the time on author and image first.

Google describes the payoff modestly: Article markup "helps Google display better title text, images, and date information" for the page. That isn't a visual snippet like review stars, so most of the value you can add sits in the author field.

Google's author rules

The Article documentation has a short list of author best practices. They're worth following exactly, because they're the part most implementations get wrong:

  1. Use Person for a person and Organization for an organization.
  2. Put only the name in author.name. No job title, no "Dr.", no publisher name.
  3. List co-authors as separate Person objects in an array, not as "Jane Doe and John Roe" in one name.
  4. Add url or sameAs pointing to the author's page or profiles.
  5. Include every author who is shown on the page.

A complete BlogPosting example

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to validate JSON-LD schema markup",
  "description": "Checking structured data with the Rich Results Test and the Schema Markup Validator.",
  "image": [
    "https://example.com/images/validate-schema-16x9.jpg",
    "https://example.com/images/validate-schema-4x3.jpg",
    "https://example.com/images/validate-schema-1x1.jpg"
  ],
  "datePublished": "2026-05-11T10:00:00-03:00",
  "dateModified": "2026-08-13T09:00:00-03:00",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://example.com/blog/validate-schema"
  },
  "author": {
    "@type": "Person",
    "@id": "https://example.com/authors/jane-doe#person",
    "name": "Jane Doe",
    "url": "https://example.com/authors/jane-doe",
    "sameAs": [
      "https://www.linkedin.com/in/jane-doe-example",
      "https://github.com/jane-doe-example"
    ]
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example Media",
    "url": "https://example.com",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}

Three details in it are deliberate:

  • image is an array. Google recommends several high-resolution images in 16x9, 4x3 and 1x1 ratios rather than one.
  • The Person has an @id. The author page can describe the same node in full (photo, bio, job title), so the article doesn't need to repeat it on every post.
  • One placeholder domain throughout. Copy-pasted examples with two domains are a common source of url values that point at someone else's site.

The author page needs ProfilePage markup

The url in the author object should open a page about that person, and that page has its own structured data type. Google's supported feature for it is ProfilePage, whose listed use cases include "An author page on a news site" and "An 'About Me' page on a blog site". The only required property is mainEntity, and inside it only name. Google recommends adding description, image, sameAs and alternateName to the Person.

{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "dateModified": "2026-10-01T09:00:00-03:00",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://example.com/authors/jane-doe#person",
    "name": "Jane Doe",
    "alternateName": "janedoe",
    "description": "Technical SEO editor at Example Media. Writes about structured data and site migrations.",
    "jobTitle": "Technical SEO editor",
    "image": "https://example.com/images/jane-doe.jpg",
    "sameAs": [
      "https://www.linkedin.com/in/jane-doe-example",
      "https://github.com/jane-doe-example"
    ]
  }
}

The @id matches the one in the article, so both blocks describe one person. The visible page matters as much as the markup. It should say who the author is and why they can write on these topics, show a real photo (the one in image), link to every profile in sameAs so the references run both ways, and list the author's articles on your site.

Google added one more piece in 2026. Search profiles launched in the US on 5 June 2026 as claimable profiles for creators and publishers, and on 16 September Google published a guide to adding a Search profile badge to a website (documentation updates log). If you can claim one, link it from the author page alongside your other profiles.

Why a string isn't enough

A NAME, NOTHING TO CHECK"author": "Jane Doe"A string. Nothing to follow:· no page describing who this is· no profile to cross-reference· no type: person or company?Valid JSON-LD. Says very little.A CHECKABLE CLAIM"@type": "Person""url": "/authors/jane-doe""sameAs": [ … ]Each link can be followed:· an author page with real content· profiles that describe the same personAnyone can check it from outside your site.

A string asserts a name. A Person object with a working url and sameAs asserts the name and gives a reader, a reviewer or a crawler somewhere to check it. The value of the extra fields depends entirely on what's at the other end of those links: an author page that 404s, or a LinkedIn profile describing a different job, undercuts the claim the markup makes.

Does any of this help with AI citations?

Google's answer is direct. Its guide to optimizing for generative AI features (May 2026, updated July) says: "Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add." It adds that structured data is still worth using for rich-result eligibility.

Independent research points the same way with a small qualification. Cyrus Shepard's review of AI citation ranking factors (Zyppy, May 2026) scored structured data 5.6 out of 10 and noted that studies consistently find a small positive relationship between schema and AI citations. None of them isolates schema as the cause.

The reason to care about authorship goes beyond markup. Ahrefs' study of 75,000 brands (May 2025) found brand mentions in AI Overviews correlated with web mentions at 0.664 and with backlinks at only 0.218. Google's May 2026 guide also warns that "seeking inauthentic 'mentions' across the web isn't as helpful as it might seem", so the lesson is about earned reputation, not a tactic. Our view, which is a hypothesis rather than a measurement: a consistent, linked author identity is how earned mentions of a person attach to that person's work. The markup is a small part of that; the author page and the profiles are most of it.

Dates

Give datePublished and dateModified a full timestamp with a time zone. Google's byline date guidance says "the dates must describe the publication or update date of the page", so change dateModified when the content materially changes (new sections, corrected facts, replaced examples) and not for typo fixes or template changes. Show the updated date visibly too, so the markup matches what readers see.

Mistakes to check for

  1. Author as a string. Valid, and the most common gap.
  2. Job titles or honorifics in author.name. Google asks for the name only; put the role in jobTitle on the author page.
  3. Co-authors merged into one name. Use an array with one Person per author.
  4. An author.url that 404s, or one generic About page for several writers. Each author needs their own page.
  5. A stock photo as the author image. Use a real photo or none; a stock image undermines the identity claim the markup is making.
  6. Markup injected only by client-side JavaScript. Google can read JSON-LD added in the browser, but Vercel's crawler study found GPTBot, ClaudeBot and PerplexityBot don't execute JavaScript. Render it on the server and confirm it in view-source.
  7. Profiles in sameAs that disagree with the author page. A reader who follows the links should find the same person, with the same role.

How to check an implementation

  1. Rich Results Test, by URL. Paste the live URL rather than the code, so Google fetches and renders the page as it would in Search. Article (and ProfilePage, on the author page) should be detected with no errors.
  2. Schema Markup Validator. It checks against schema.org itself and catches type and property errors Google's tool ignores.
  3. Click through by hand. Open the author URL. Open every sameAs profile. Confirm the photo, the role and the name agree. No validator does this part.

Start with the byline on your top pages

Pick your ten most visited articles and look at the author value in each. Bare strings and missing author pages are the most common gaps and the cheapest to close. A single-page check is quick with the tool below (the first three issues are shown free; the full report unlocks with an email).

AI
Free tool · No signup
Free Schema Validator
Paste any URL → find the structured data your page is missing, with ready-to-paste JSON-LD fixes.
Check your schema →

The wider question of which markup still produces anything in Google is covered in schema markup and AI Overviews; the trail markup that sits alongside Article on every post is in BreadcrumbList JSON-LD in Next.js.

FAQ

Should I use Article, BlogPosting or NewsArticle?
Use the most specific type that is true. BlogPosting suits blog posts, NewsArticle suits news reporting, and plain Article works whenever you're unsure. All three are Article subtypes in schema.org and Google's documentation treats them the same way, so the author field matters far more than the choice of subtype.
Can the author be an Organization instead of a Person?
Yes, when an organization genuinely wrote the piece, such as unsigned reports or wire copy. Google's documentation allows Organization as the author type. For an article written by a named person, use Person: claiming an organization as author when a person wrote it hides exactly the information the field exists to carry.
What if my site doesn't have named authors?
Organization authorship is valid, but it gives readers less to check. For finance, health and legal topics, a named author is strongly advisable, because Google's quality rater guidelines weigh who created that kind of content heavily. Elsewhere, unsigned content can still compete on depth and original information; it just starts without the identity signal.

Sources cited in this piece

Updated October 1, 2026: corrected Google's Article requirements (it lists no required properties), added ProfilePage markup for author pages, and removed claims we couldn't source.