Author Schema Markup for Blogs in 2026: Step-by-Step Setup

Author schema markup is structured data (usually JSON-LD) that tells search engines which real person wrote a blog post. The standard pattern is a BlogPosting object with an author property pointing to a Person object. Done right, it links every post to a consistent author entity, supports E-E-A-T, and helps Google build a knowledge panel for your name.

This guide covers the actual JSON-LD code you need (with copy-paste examples), how to handle WordPress with Yoast or Rank Math, what to do for multi-author and guest post scenarios, and the validation steps that catch the mistakes most people miss.

The minimum-viable author schema (copy this)

The smallest valid JSON-LD block that gives Google what it needs for author plus article markup looks like this. Drop it inside a <script type="application/ld+json"> tag in your page head:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Your Post Title Here",
  "datePublished": "2026-05-05",
  "dateModified": "2026-05-05",
  "image": "https://example.com/featured-image.jpg",
  "author": {
    "@type": "Person",
    "name": "Jane Doe",
    "url": "https://example.com/author/jane-doe/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Site",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  }
}

That’s the floor. Everything below builds on it. If you only ship this much, you’re already ahead of most blogs.

What author schema actually does

Author schema does three concrete things:

• It tells Google who wrote the post in machine-readable form. Your visible byline tells humans; schema tells crawlers.
• It links every post by the same author into one entity. Consistent name and url values across an archive let Google understand “Jane Doe wrote 47 posts on this site,” which feeds knowledge graph profiles.
• It feeds entity-level signals for E-E-A-T scoring. Author credentials, work history (worksFor), expertise areas (knowsAbout), and verified profiles (sameAs) all become structured data Google can use.

Schema doesn’t boost rankings on its own. There’s no “+5 SEO points for adding schema.” Its value is removing ambiguity. When a query is borderline, Google has more reason to trust pages where author identity is unambiguous, and rich results (which schema is required for) do drive higher click-through rates.

Person vs Organization vs the @type “Author” question

One of the most common questions: should the author be a Person, an Organization, or something else? Here’s the decision in plain terms:

• Real human writer with a public identity: use Person. This is the right answer 90% of the time.
• Brand-authored content with no individual byline (e.g. company blog post that says “By Acme Team”): use Organization. But a real human author is almost always better for E-E-A-T.
• Multi-author posts: use an array of Person objects (covered below).
• Pseudonyms or pen names: still use Person, but use the pen name in name and the author bio page in url. Don’t list both real and pen names.

Schema.org technically has a generic author property that accepts either, but Google’s documentation strongly prefers Person for individual writers. If you want one rule of thumb: if a real human can stand behind the post, use Person, even on a company blog.

The recommended author schema (with sameAs, jobTitle, and knowsAbout)

The minimum-viable version works, but a stronger setup signals more about who the author is. This is the version I use for most blog posts:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/author-schema-guide/#article",
  "mainEntityOfPage": "https://example.com/blog/author-schema-guide/",
  "headline": "How to Set Up Author Schema Markup",
  "datePublished": "2026-05-05",
  "dateModified": "2026-05-05",
  "image": [
    "https://example.com/featured-1200x630.jpg",
    "https://example.com/featured-1200x900.jpg"
  ],
  "author": {
    "@type": "Person",
    "@id": "https://example.com/author/jane-doe/#person",
    "name": "Jane Doe",
    "url": "https://example.com/author/jane-doe/",
    "image": "https://example.com/authors/jane-doe.jpg",
    "jobTitle": "Senior SEO Writer",
    "worksFor": {
      "@type": "Organization",
      "name": "Example Site",
      "url": "https://example.com"
    },
    "knowsAbout": [
      "Search engine optimization",
      "Content marketing",
      "Technical SEO"
    ],
    "sameAs": [
      "https://www.linkedin.com/in/janedoe",
      "https://twitter.com/janedoe",
      "https://www.wikidata.org/wiki/Q12345678"
    ]
  },
  "publisher": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example Site",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png",
      "width": 600,
      "height": 60
    }
  }
}

Notes on each field:

• @id on Person is a stable, unique identifier for the author entity. Use the same @id across every post so Google understands it’s all one person. The #person fragment is convention, but any unique IRI works.
• @id and mainEntityOfPage on the BlogPosting tell Google which URL is the canonical home for this article and tie the article to the rest of your schema graph.
• knowsAbout is an array of topical authority signals. You can pass plain strings or, for stronger entity linking, point to Wikipedia or Wikidata URLs (e.g. https://www.wikidata.org/wiki/Q156128). Keep entries honest; three to five is a good range.
• jobTitle plus worksFor signals professional context. Especially valuable for YMYL niches (health, finance, legal).
• image as an array of multiple aspect ratios (1:1, 4:3, 16:9 at 1200px wide minimum) is recommended by Google for Article rich result eligibility. The headline should also stay under 110 characters.
• Logo dimensions on the publisher: Google recommends including width and height, and the logo should fit within a 600×60 area. It’s not strictly required anymore, but logos with dimensions render more reliably.

Multi-author and guest post handling

For posts with two or more authors, use an array. Don’t smush names into one name field, and don’t pick one author as “primary” if both contributed:

"author": [
  {
    "@type": "Person",
    "name": "Jane Doe",
    "url": "https://example.com/author/jane-doe/"
  },
  {
    "@type": "Person",
    "name": "John Smith",
    "url": "https://example.com/author/john-smith/"
  }
]

For guest posts, the author should be the actual guest writer, not the site owner. If the guest doesn’t have a bio page on your site, create one. A guest author with no author archive page on your site looks weak to Google and weaker to readers.

For AI-assisted content, the author should be the human editor or writer who reviewed and approved it. Google doesn’t ban AI-generated content, but the search guidelines explicitly recommend that a human take editorial responsibility. Listing “AI” or “ChatGPT” as the author bypasses E-E-A-T entirely and is a bad signal even when it’s technically the truth.

Author schema in WordPress (Yoast, Rank Math, AIOSEO)

If you run WordPress, you almost certainly don’t need to write JSON-LD by hand. The major SEO plugins output it automatically. The catch is that they only output as much as your WordPress user profile contains, and the default user profile is anemic.

Yoast SEO

Yoast outputs Person schema for each post’s author automatically, regardless of your Site representation setting. The Site representation setting (Yoast SEO → Settings → Site basics) controls who the publisher is. Set it to “Person” if you run a personal blog where you are the brand, or “Organization” if your site has its own brand identity. The post-level author is always pulled from whichever WordPress user is assigned to the post.

Yoast pulls these fields from each WordPress user profile:

• name → Display name in WP profile
• url → Website field, or the user’s author archive
• image → Gravatar (this is where most bloggers fall short)
• sameAs → The social profile fields Yoast adds (Twitter, Facebook, Instagram, LinkedIn, etc.) inside each user’s profile page
• description → Biographical info field

To get the strongest output: fill out every social field in each author’s WP profile, set a real (non-default) Gravatar, and write a 2-3 sentence bio. That alone makes Yoast’s auto-generated schema close to the recommended setup above.

Rank Math

Rank Math has explicit author schema controls under Titles & Meta → Authors. Toggle “Author Schema Entity” on and Rank Math outputs a Person object pulled from each user’s profile, similar to Yoast. The plus side: Rank Math gives you a separate Schema Generator on each post where you can override or add fields per-post.

The free version handles the basics well. Rank Math’s per-post Schema Generator lets you add fields like knowsAbout manually if you want them on a specific post.

AIOSEO

AIOSEO outputs Person schema as part of its Article schema by default. The fields it pulls are similar to Yoast. Configuration lives under Search Appearance → Authors, and like Rank Math, AIOSEO offers a per-post schema override for cases where the default isn’t right.

What WordPress schema plugins won’t fix

WordPress user profiles are missing fields like jobTitle, knowsAbout, and a structured sameAs beyond the default social links. Two ways to fill the gaps:

• Advanced Custom Fields (ACF) + a small filter that injects extra fields into your SEO plugin’s schema graph. Best for technical bloggers.
• Co-Authors Plus if you publish guest posts and need full author profiles for non-WP users (people without WordPress accounts on your site).

If you’re publishing AI-assisted blog content with RightBlogger and pushing posts to WordPress with our WordPress plugin, your author schema gets generated by Yoast/Rank Math/AIOSEO at publish time using whichever WordPress user the post is assigned to. Make sure that user’s profile is filled out before you bulk-publish.

Don’t forget the author archive: ProfilePage schema

Author schema on individual posts gets most of the attention, but the author archive page itself (e.g. /author/jane-doe/) deserves its own schema. Use ProfilePage with the same Person object as mainEntity:

{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://example.com/author/jane-doe/#person",
    "name": "Jane Doe",
    "url": "https://example.com/author/jane-doe/",
    "image": "https://example.com/authors/jane-doe.jpg",
    "jobTitle": "Senior SEO Writer",
    "knowsAbout": ["SEO", "Content marketing"],
    "sameAs": [
      "https://www.linkedin.com/in/janedoe",
      "https://www.wikidata.org/wiki/Q12345678"
    ]
  }
}

This signals to Google that the page is the author’s profile, not just a list of their posts. The @id on the Person should match the @id you use on every BlogPosting they wrote. That consistency is what builds the entity graph for that author across your site.

For YMYL niches, you can also add reviewedBy to your BlogPosting if a different person reviewed the content for accuracy. This is increasingly cited as a useful E-E-A-T signal in medical, legal, and financial verticals.

For AI-coded sites: a drop-in prompt for Claude Code, Codex, or Cursor

If you built your blog with an AI coding agent (Claude Code, Codex, Cursor, Windsurf, Aider, v0), adding author schema is one of the easier prompts you can hand off. The agent already knows your stack and can wire it into your existing layout or template files. Paste this prompt into your agent of choice and adjust the bracketed values:

When you hand this to an agent:

• Tell the agent your stack. The placement of the <script> tag and how to access post/author data depends entirely on your framework. Next.js App Router uses generateMetadata or a Layout, Astro uses frontmatter and SSR components, Hugo uses partials, etc. The agent will get this right if you tell it the framework.
• Make sure schema renders server-side. Many AI agents will default to a client-side useEffect injection if you don’t specify. Googlebot does render JavaScript now, but server-side rendered schema is more reliable and gets indexed faster. The prompt above asks for this explicitly.
• Audit the output before merging. Agents will sometimes hardcode fallback values. Inspect the generated JSON-LD on at least three different post URLs (different authors, different dates) before you ship.
• Add a test. Ask the agent to write a snapshot or unit test that asserts the JSON-LD includes the expected author fields. This catches silent regressions when someone changes the author data structure later.

If your site is on a managed CMS (WordPress, Ghost, Webflow, Squarespace), you don’t need a coding agent. The plugin or built-in schema feature is faster. The AI-coded path is for static site generators, custom Next.js or Astro sites, headless setups, and anything self-rolled.

The sameAs strategy: more than just LinkedIn

Most guides treat sameAs as “list your LinkedIn and Twitter.” It’s worth more than that. sameAs is how Google disambiguates your author entity from every other person with the same name. The more authoritative profiles you can point to, the stronger that disambiguation becomes.

A reasonable hierarchy, strongest to weakest:

1. Wikidata: the strongest entity signal you can give Google. If you don’t have a Wikidata entry, you can create one (it’s open). This single line of sameAs often does more than five social links combined.
2. Wikipedia: rare but powerful for established authors.
3. Crunchbase / Muck Rack / IMDb: high-trust verified profiles for relevant niches.
4. LinkedIn, GitHub, Stack Overflow: solid professional signals.
5. Twitter/X, Mastodon, Bluesky: useful but lower weight; only include actively maintained accounts.
6. Personal website: useful only if it’s distinct from your url field.

Don’t pad sameAs with dead profiles. Every link should resolve, be active, and clearly identify the same person. A broken Twitter link is worse than no Twitter link.

Validate it works (and keep it working)

Three tools cover the validation layer:

• Google’s Rich Results Test parses a URL or raw code and tells you whether Google can use it for rich results. Run this on any post you audit or after any template change.
• Schema.org’s Schema Markup Validator is stricter than Google’s tool and catches spec issues Google’s test ignores. Use it if you’re working with less-common types or properties.
• Google Search Console’s Enhancements report monitors your live site over time. Watch for “valid with warnings” and “invalid” reports across your Article and BlogPosting types.
• Google’s Article structured data docs are the source of truth for what’s required vs recommended. Bookmark them.

What to actually check:

• Errors block rich results. Warnings don’t, but they often signal something to fix.
• Author name in schema matches the visible byline exactly. “Jane Doe” vs “Jane M. Doe” is a mismatch.
• Author URL returns a 200, not a redirect. Stale slugs after a rename are a common silent failure.
• Image URLs are absolute and crawlable. Relative paths break schema.
• Logo dimensions are present. Many implementations break here.

Common author schema mistakes that hurt you

• Fake authors with stock photo bios. Google’s spam policies cover synthetic personas, and a fake byline risks demotion (and looks bad to readers who notice).
• AI-generated author headshots. Same risk. If the photo is fake, careful readers can tell, and the photo provides no real entity signal. Use a real one.
• Inflated credentials in jobTitle or bio. Don’t list yourself as “Senior Editor” on a one-person blog.
• Schema author doesn’t match the visible byline. “Editorial Team” in the byline plus a specific Person in schema is a conflict. Match them, or pick the human and update both.
• Stale sameAs links. A broken Twitter from 2019 actively hurts entity disambiguation. Audit annually.
• Schema injected after page load via JavaScript. Googlebot does render JS, but server-side rendered schema indexes faster and more reliably.
• One author entity reused for multiple real people. This happens when an editor publishes posts under their own login that someone else wrote. Fix it by publishing from the actual author’s WordPress account.

Author schema FAQ

What is author schema?

Author schema is structured data (typically JSON-LD) that identifies the human author of a piece of content using schema.org’s Person type, usually nested inside a BlogPosting or Article object. It tells search engines which real person wrote the post in machine-readable form, separate from the visible byline that humans read.

What’s an example of author schema markup?

The simplest example is a Person object with three fields: name, url (linking to an author bio page), and ideally sameAs (an array of profile URLs on LinkedIn, Wikidata, etc.). See the copy-paste examples earlier in this guide for both minimum-viable and recommended versions.

What’s the difference between Person schema and Author schema?

There isn’t a separate “Author schema” type. author is a property on Article or BlogPosting that takes either a Person or Organization as its value. So when people say “author schema,” they almost always mean a Person object used as the value of an author property.

Does author schema improve rankings?

Not directly. Schema doesn’t have a ranking factor weight. What it does is remove ambiguity, support E-E-A-T signal scoring, and make your content eligible for rich results that improve click-through rate. Over time, those compound. Don’t expect a Monday-launch, Friday-rankings effect.

How do I check if my site already has author schema?

Run any blog post URL through the Rich Results Test. If your site uses Yoast, Rank Math, or AIOSEO, you almost certainly have basic author schema already. Look in the rendered output for an author property with a Person object inside the BlogPosting or Article markup.

Where should I put the JSON-LD on my blog?

Inside a <script type="application/ld+json"> tag in the page <head>. WordPress SEO plugins inject it server-side automatically. If you’re hand-coding, place it in the head, not the body, so it’s easy for Googlebot to parse early in the page lifecycle.

Do I need author schema on every post?

If you show an author byline, yes. Inconsistency across an archive is worse than no schema at all. The whole point is signaling “this person wrote these things” across your site, which only works if every post has the markup.

Wrapping up

Author schema doesn’t make weak content rank, but for sites already publishing real work, it’s one of the cheapest technical changes you can make. Start with the minimum-viable JSON-LD above. Pick Person for any post written by an actual human. Fill out your WordPress user profiles so Yoast or Rank Math can output something useful. Add a real Wikidata entry if you can. Run validation after every template change.

If you’re also working on broader visibility in AI search engines, strong author entities help there too. LLMs use the same entity signals Google does for grounding and citation, so a clean author schema setup pays off in both Google rich results and ChatGPT/Perplexity citations.