ProfilePage Schema for Author Bios

An author bio that a human reads as authoritative is invisible to a machine unless you describe it in structured data. ProfilePage is the schema.org type Google names specifically for pages that exist to present one person or organization, and the author archive is the textbook case. Marking it up turns a byline into an addressable entity that Google, Bing, and AI answer engines can connect to credentials, publications, and off site profiles.

What ProfilePage actually declares

ProfilePage is a page level type. It says this URL is the canonical description of a subject, and the subject sits inside mainEntity. For author bios that subject is a Person. The distinction matters: you are not adding Person schema in isolation, you are declaring that the whole page is a profile of that Person. That framing is what lets an answer engine treat the URL as the identity record for the author rather than as just another content page.

Use it on any page whose primary purpose is describing an individual: a WordPress author archive at /author/jane-doe/, a standalone contributor bio, or a forum member profile. Do not put a full ProfilePage on each article. On articles you reference the Person, you do not redescribe the page as a profile.

The minimal valid markup

Embed this JSON-LD on the author archive template. Every field maps to something a reader can already see on the page, which is the rule that keeps you inside Google structured data policy.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "@id": "https://example.com/author/jane-doe/#profilepage",
  "url": "https://example.com/author/jane-doe/",
  "dateModified": "2026-07-21",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://example.com/#person-jane-doe",
    "name": "Jane Doe",
    "jobTitle": "Senior Editor",
    "description": "Twelve years auditing local and technical SEO.",
    "url": "https://example.com/author/jane-doe/",
    "image": "https://example.com/img/jane-doe.jpg",
    "knowsAbout": ["Local SEO", "Structured Data", "Site Audits"],
    "sameAs": [
      "https://www.linkedin.com/in/janedoe",
      "https://orcid.org/0000-0002-1825-0097"
    ],
    "worksFor": { "@id": "https://example.com/#organization" }
  }
}
</script>

The @id on the Person is the load bearing detail. It is a stable identifier you reuse everywhere the author appears. Define it once here, then point at it from articles instead of pasting a second copy of the profile.

Wiring the author into every Article

On each post, your Article schema should not embed a fresh Person block. It should reference the canonical Person by @id, so search engines resolve one entity across the whole site:

"author": {
  "@type": "Person",
  "@id": "https://example.com/#person-jane-doe"
}

This is the difference between a site that has fifty disconnected author snippets and a site that has one consolidated author entity cited by fifty articles. The second pattern is what builds a durable authorship signal and what feeds a Knowledge Graph style understanding of who stands behind your content.

Property reference

Populate these fields on the Person inside mainEntity. The right column is where most implementations quietly break.

sameAs is where trust is earned or lost

The sameAs array is your verification chain. Each URL should be a profile the author controls and that ideally links back to your site, closing the loop. A LinkedIn profile, an ORCID record, a personal site, a verified X account, or a Google Scholar page are strong entries. A random Pinterest board or a dead link is noise that weakens the entity. Before you ship, open every sameAs URL and confirm it resolves and belongs to the right person, because broken sameAs targets are the single most common silent failure in author markup.

Rendering and placement

The JSON-LD must be present in the server rendered HTML of the author URL. If your theme injects it only after client side hydration, some crawlers and most lightweight AI fetchers will miss it. Confirm by viewing source, not by inspecting the live DOM. Keep the markup in a single <script type="application/ld+json"> block and let your SEO plugin handle sitewide Organization so you can reference it by @id rather than duplicating it.

Validation workflow

Run the author URL through the Google Rich Results Test and confirm the Person parses with zero errors and zero warnings on the required fields. Then do the manual pass that automated testers skip: check that name equals the byline, that url is the canonical author archive and not a redirect, and that every sameAs entry returns a live page for the correct person. Re run the test after any theme or plugin update, since author templates are a frequent casualty of updates.

Common mistakes to avoid

Do not mark up a Person who does not appear visibly on the page. Do not stuff knowsAbout with twenty keywords, keep it to the handful of topics the author truly covers. Do not let two plugins each emit a Person for the same author, which creates conflicting entities. And never invent credentials in jobTitle or description, since fabricated expertise is both a policy risk and a trust failure once a reader cross checks it.

Where this fits in your entity strategy

ProfilePage is one node in a larger machine readable identity for your brand and its people. For the wider picture of how entities, sameAs, and Knowledge Graph signals fit together, see our guide to entity HTML and becoming a machine readable brand, our broader schema and structured data resources, and our walkthrough on how to become a cited source in AI answers, where verifiable authorship carries real weight.

Frequently asked questions