Author schema: how to attach an article to a real person

Author schema is the one property that attaches an article to a named human instead of to nobody. You write a Person object with a name, a URL that resolves to a page about that person, and a short list of profiles they control. It takes twenty minutes. It does not move rankings, and it is not the reason anyone gets cited.

Read this first

This chapter covers one property and the entity sitting behind it. The organisation-level version of the same job — getting an engine to describe the company correctly — is entity SEO for AI search. That chapter is about a company. This one is about a person, and the two use different types for a reason.

Keep two words apart while you read. Being mentioned is your name turning up in an answer. Being cited is your page being handed over as the source. What earns the second one is covered in what makes content citable by AI, and it is not markup.

Why author schema is an identity problem, not a formatting problem

A byline is a design decision. It renders under the headline, it looks like attribution, and a parser gets nothing from it except a run of characters sitting where every article on the internet puts one. Structured data changes what kind of thing that string is. It stops being text on a page and becomes a typed value: a Person, which schema.org defines as "A person (alive, dead, undead, or fictional)", attached to the article through the author property.

schema.org defines author as "The author of this content or rating" and expects one of exactly two types: Organization or Person. There is no third option, and that constraint is the point. You are being made to commit to whether a human or a company wrote this. Most sites commit to neither, which is not a middle position — it is an absence.

The part that does real work is the URL. Google describes author.url as "A link to a web page that uniquely identifies the author of the article. For example, the author's social media page, an 'about me' page, or a bio page." The load-bearing word is uniquely. The same page adds that "Google can understand both sameAs and url when disambiguating authors" — disambiguating is Google's verb, not ours, and it tells you what the property is for. Read 2026-09-01 at Google's Article structured data documentation; the type definitions are at schema.org/Person and schema.org/author, both read the same day.

A machine cannot recognise an author. It can only match a string, and the one it trusts is the string that comes back identical from every place you sent it.

What the documentation actually says

Eight rules, all from the pages named above, all read on 2026-09-01. Nothing in this table is inferred, and the right-hand column is the wording as published.

One more from the same page, because it decides what you do with a two-author post: "Make sure that all the authors that are presented as authors on the web page are also included in markup." If a name is visible on the page as an author, it belongs in the markup. That is a matching requirement, and it is the only place Google's wording ties the rendered page to the JSON-LD.

Do this in five steps

Shipping author schema is mostly bookkeeping, so each step below has a check you can run. If the check does not pass, the step is not done, however finished the code looks.

1. Choose one string for the person's name and write it in a file. This is the only decision in the whole chapter; everything after it is copying. Done when you have one line of text you will not renegotiate later.
2. Build the page that author.url will point at — a bio page, an about-me page, or a profile on a platform the person controls. Done when curl returns 200 and the name is in the delivered HTML rather than injected after load.
3. Add the author array to the article's JSON-LD with @type, name and url. Done when Google's Rich Results Test parses the page against Article with no errors.
4. Add sameAs entries only for profiles the person can log into. Done when each URL returns 200 to an anonymous request and the display name on it matches, character for character.
5. Fix the visible byline last, because it is the one a human will notice. Done when the same string appears twice in the delivered HTML: once in the byline, once in the markup.

Step four is where most of the time goes, and it is the step people skip. A profile you cannot log into is a page whose display name can change without you hearing about it.

The deliverable: the block itself

Put this in the <head> of the article page. Replace every value. Delete any sameAs line that fails the anonymous fetch from step four.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How we cut our lead time to nine days",
  "datePublished": "2026-09-01T09:00:00+08:00",
  "dateModified": "2026-09-01T09:00:00+08:00",
  "author": [
    {
      "@type": "Person",
      "name": "Mara Voss",
      "jobTitle": "Production manager",
      "url": "https://www.acmewidgets.com/about/mara-voss",
      "sameAs": [
        "https://www.linkedin.com/in/maravoss",
        "https://github.com/maravoss"
      ]
    }
  ],
  "publisher": {
    "@type": "Organization",
    "name": "Acme Widgets",
    "url": "https://www.acmewidgets.com"
  }
}
</script>

Two authors means two objects in that array, each with its own name and its own url. The company never appears inside author; it appears once, in publisher, and a site that puts the same string in both has told a parser that a company is a person.

The deliverable: seven places the name must match

Run this list once per author, not once per article. Every row is a place a machine can reach on its own, which is exactly why a mismatch is expensive.

The last row is the one that quietly undoes the other six. A writer published as "M. Voss" for two years and "Mara Voss" since the redesign is two candidate people, and no amount of correct markup on this month's posts merges them.

Three ways this goes wrong

All three pass code review. Two of them look like extra care, which is why they survive.

1. The company name in author.name. Google lists the publisher name first among things not to put there and gives you publisher for it. Spot it by comparing the two values: if author.name and publisher.name are the same string, you have declared that a company wrote the article. That is valid markup and a true statement about plenty of sites. It also means there is no person for anything to accumulate around.
2. Two people in one field. The wording is blunt — "Don't merge multiple authors in the same author field" — and the counter-example is a single name holding two names separated by a comma. Spot it by searching your own output for a comma, an ampersand or the word "and" inside author.name. The result is one entity with a name no human has.
3. Everything except the name, in the name. Titles, honorifics, "posted by", the department. Google names a property for each of the first two and simply rules out the third. Spot it by reading author.name aloud: if it would not fit on a passport, trim it until it would.

There is a fourth that we file as our reading rather than a rule: pointing author.url at a tag archive that lists the person's posts and says nothing about them. Google's three examples of an acceptable target are a social media page, an about-me page and a bio page. A paginated list of headlines is none of the three.

Where this chapter stops

Google's own summary of what Article structured data does is narrow: it "can help Google understand more about the web page and show better title text, images, and date information for the article in search results". Author is not in that list of appearances. The same documentation says plainly that "Google does not guarantee that features that consume structured data will show up in search results". Both read 2026-09-01.

What the AI engines do with author schema, we do not know. None of them document whether they parse the property, and none publish what a Person would change if they did. There is no number here, and anyone who offers you one is guessing. We are not writing an unmeasured effect up as a benefit.

So the honest scope is small. This work will not get you cited and it will not get you mentioned; those are two separate outcomes and markup buys neither. What it removes is one specific failure — an article no machine can attach to anybody. Whether removing that failure pays off downstream is the part nobody has published, including us.

Checking that those seven strings still agree six months and one CMS migration later is part of what QueryWin is being built to do.

Common questions

Does author schema help SEO?

Not in any way Google documents. The Article page describes the effect as better title text, images and date information, and author is not among them. Treat it as identity plumbing, not as a ranking lever.

Can the author be a company?

Yes. author accepts Organization as well as Person, and Google shows an example linking to the organisation's home page. You then have an article written by a company, with no person attached, which is a legitimate choice and a different outcome from the one this chapter is about.

What is the difference between author and publisher?

The author wrote it. The publisher put it out. Google's own example keeps them apart in the same block — Person objects in author, one Organization in publisher — and explicitly tells you to move the publisher name out of author.name.

Do I need a separate page for every writer?

You need something for author.url to resolve to, and it does not have to live on your domain. A profile the person controls works. What does not work is a page that exists only as a list of their posts.

Does this affect whether AI engines cite my page?

Unknown, and we would rather say so than fill the gap. No engine has published how it treats the property. Being described accurately and being used as a source are separate problems, and only the first one is even partly addressable with markup.