Author and publisher as entities, not strings

Four properties do the work. name, exactly the name and nothing else. @id, a stable fragment on the page that describes this person. url, that page. And sameAs, the off-site profiles that let somebody who does not trust you check the claim.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://example.com/authors/jane-doe#person",
      "name": "Jane Doe",
      "url": "https://example.com/authors/jane-doe",
      "jobTitle": "Principal data engineer",
      "description": "Eleven years building ingestion pipelines, six of them here.",
      "image": "https://example.com/img/jane-doe.jpg",
      "worksFor": { "@id": "https://example.com/#organization" },
      "knowsAbout": ["Data pipelines", "Postgres", "Change data capture"],
      "sameAs": [
        "https://www.linkedin.com/in/janedoe-example/",
        "https://github.com/janedoe",
        "https://orcid.org/0000-0000-0000-0000"
      ]
    },
    {
      "@type": "ProfilePage",
      "@id": "https://example.com/authors/jane-doe#page",
      "url": "https://example.com/authors/jane-doe",
      "mainEntity": { "@id": "https://example.com/authors/jane-doe#person" }
    }
  ]
}
</script>

That block belongs on the author page. Every article she writes then references the identifier rather than repeating any of it, which is the second half of the fix and the section after next.

Three rules about name that account for a large share of broken author markup.

• No decoration.Google's documentation is explicit that the value is the name alone. By Jane Doe is wrong, so is Jane Doe, Principal Data Engineer, and so is Jane Doe | Northwind. The role goes in jobTitle. Templates that interpolate the rendered byline straight into the property produce all three.
• Two authors are two objects. An array of Person nodes, not one string containing the word and. A single entity called Jane Doe and Amir Khan is a person who does not exist.
• Check what your CMS put there before you check anything else. A default install writes whatever the account is called, which is why a measurable slice of the web publishes articles authored by admin, editor or the name of an agency that stopped working there in 2022. It validates cleanly.

urlshould point at a page about the person on your site, with enough on it to be worth landing on. Pointing it at the article's own URL, or at an archive listing that is just their last ten posts with no biography, satisfies the syntax and wastes the property.

publisher has the same string problem and a worse version of it, because publisher data is longer, so people copy more of it into more places. The pattern to avoid is every article carrying a full Organization object with a name, a URL and a logo object nested inside it.

It validates. What it means is that each article declares its own publisher, and a consumer reading four hundred of your posts has no way to know it is the same publisher four hundred times rather than four hundred organisations with matching names. Then someone rebrands, the old value stays in a cached template, and now there are two.

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/cdc-without-tears#article",
  "author": { "@id": "https://example.com/authors/jane-doe#person" },
  "publisher": { "@id": "https://example.com/#organization" },
  "mainEntityOfPage": { "@id": "https://example.com/blog/cdc-without-tears" }
}

Two identifiers, no duplicated data, one place to edit when anything changes. The identifiers have to resolve to nodes a consumer can actually reach, which in practice means the organisation block is emitted site-wide by your layout and the person block sits on the author page, both with identifiers that never change.

One legitimate case for a non-person author: work that genuinely has no individual byline, a documentation page or a policy, can name the organisation as author. That is honest and it is better than inventing a staff writer. What is not fine is attributing an opinion piece to a company because filling in a person felt like work.

Nothing breaks. That is the honest starting point and it is why this cannot be Critical: a page with a string author is indexed, ranked and served exactly as it would be otherwise, and the block it sits in remains valid. There is no error to see and no feature withdrawn.

What is lost is the value of work already done. Somebody wrote the biography, somebody hired the expert, and the markup hands a consumer a name it cannot connect to either. Paying for substance and then encoding it in a form that discards the connection is a bad trade, and unlike most bad trades in markup it costs nothing to reverse.

It sits at Important rather than lower because the fix touches one property in one template and improves every article at once, and because the alternative to an identifier is name-matching, which fails on married names, transliterations and any newsroom with two people called James. Where each rating sits relative to the others is spelled out on the page that lists the checks.

Start with the identifier, because that is where the silent duplication lives. Pull the author identifier out of several articles by the same person and confirm you get one distinct value back rather than several near-identical ones.

for path in /blog/post-a /blog/post-b /blog/post-c; do
  curl -s "https://example.com$path" \
    | grep -o '"author":[^}]*}' \
    | head -1
done

# the author page has to actually serve the Person node
# those articles are pointing at
curl -s https://example.com/authors/jane-doe \
  | grep -c '#person'

Then read the rendered byline and the markup side by side. The name in the JSON should be the name on the page with the word by and any job title stripped off, the person's page should exist and load, and each profile URL should be a live page that names the same employer your markup does. A profile listing a job they left two years ago is a contradiction you have published about your own staff.

Do the same for the publisher identifier across a handful of templates. If your article properties are otherwise incomplete, the dates and the headline are the next thing to look at, since author is usually discovered while fixing those.