How to Create ProfilePage Schema

Author pages are where E-E-A-T work usually stops one step short. The bio is written, the headshot is uploaded, the Person markup is in place, and the page still does not function as an authority node because nothing declares what the page is for.

That declaration is ProfilePage, and it is a different kind of statement from Person. Person says a human exists and here are their attributes. ProfilePage says this URL is the canonical place where that human is described. Search engines resolving an author entity need the second one to know which of the forty pages mentioning a name is the authoritative one.

Google maintains profile page structured data documentation for exactly this, and the type is missing from most author pages we audit.

ProfilePage Versus Person

The relationship is a page type wrapping an entity, and getting it backwards produces markup that describes nothing coherent.

Person is the entity. It carries the name, job title, employer, credentials, and links. It can appear anywhere: as an author on an article, as a founder in an organisation graph, as a speaker on an event page.

ProfilePage is the page. It carries no personal attributes of its own. Its job is to state that this URL is about one primary subject, and to name that subject through mainEntity.

Why the wrapper changes anything comes down to disambiguation. Consider the ways one person appears across your site: bylines on 30 articles, a mention in an about page, a quote in a case study, and 1 dedicated bio page. All 32 of those can carry Person markup. Only 1 is the profile, and without ProfilePage nothing in your markup says which.

An engine trying to build a confident author entity is looking for a canonical description to anchor to. Give it 1 and your bylines all resolve to a single node. Give it 30 partial Person objects and it has 30 competing fragments.

When to Use It

Use ProfilePage on any URL whose purpose is to describe one person or organisation.

• Author and contributor pages on a publication or blog.
• Team and leadership bio pages, one per person rather than a combined team page.
• Practitioner pages on a professional services site, such as an attorney, doctor, or advisor profile.
• Creator profiles on a platform where users have their own pages.
• Expert or reviewer pages backing YMYL content.

Do not use it in three situations that get confused with the above.

A combined team page listing twelve people is not a ProfilePage, because there is no single mainEntity. It is a CollectionPage or AboutPage containing multiple Person references, each ideally pointing at that person's own profile.

An article written by somebody is not their profile. It is an Article with an author. The author property should reference the profile, not restate it.

An organisation's about page is usually an AboutPage rather than a ProfilePage, though ProfilePage is technically valid for a page describing a single organisation. Where both apply, AboutPage is the closer fit for a company narrative.

The Properties That Matter

ProfilePage itself is thin, and almost all the value sits in the Person inside it.

On the page wrapper, three properties do the work. mainEntity names the subject and is the only genuinely required one. dateCreated states when the profile came into existence, which Google's documentation highlights for creator surfaces because it separates an established contributor from an account made last week. dateModified states when it was last updated.

On the nested Person, the property set falls into four groups.

Identity is the baseline: name, alternateName for a professional or maiden name, jobTitle, and description carrying the bio.

Affiliation establishes standing: worksFor pointing at the organisation, alumniOf for education, and memberOf for professional bodies. Each should reference a real entity rather than a bare string where one exists.

Expertise makes the claim specific: knowsAbout naming actual subject areas, and hasCredential carrying licences, certifications, and qualifications with the issuing body named.

Corroboration is sameAs, which is important enough to get its own section.

Two properties worth adding on creator profiles. interactionStatistic with an InteractionCounter can carry follower counts, which is a genuine authority signal on platforms where audience matters. And image should point at a real headshot, since a profile with no face is weaker corroboration than one with a photo that appears consistently across the person's other listed profiles.

A Complete Working Example

This is an author profile for a publication contributor with real credentials.

{
  "@context": "https://schema.org",
  "@type": "ProfilePage",
  "@id": "https://example.com/authors/priya-raman",
  "url": "https://example.com/authors/priya-raman",
  "dateCreated": "2019-03-11T00:00:00-05:00",
  "dateModified": "2026-08-12T00:00:00-04:00",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://example.com/authors/priya-raman#person",
    "name": "Priya Raman",
    "jobTitle": "Senior Technical Editor",
    "description": "Priya Raman has covered database infrastructure since 2014 and has run production Postgres at two companies. She writes the storage and replication coverage here.",
    "image": "https://example.com/img/authors/priya-raman.jpg",
    "worksFor": {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Publishing"
    },
    "alumniOf": {
      "@type": "CollegeOrUniversity",
      "name": "University of Illinois Urbana-Champaign"
    },
    "knowsAbout": [
      "PostgreSQL replication",
      "Database sharding",
      "Write-ahead logging",
      "Connection pooling"
    ],
    "hasCredential": {
      "@type": "EducationalOccupationalCredential",
      "credentialCategory": "Certification",
      "name": "AWS Certified Database Specialty",
      "recognizedBy": {
        "@type": "Organization",
        "name": "Amazon Web Services"
      }
    },
    "sameAs": [
      "https://orcid.org/0000-0002-1825-0097",
      "https://github.com/priyaraman",
      "https://www.linkedin.com/in/priyaraman"
    ]
  }
}

Three deliberate choices in that example.

knowsAbout names four specific technical subjects rather than saying databases. Specificity is what lets an engine match the author to a topic, and a broad label matches nothing in particular.

hasCredential names the certifying body. A credential with no issuer is an unverifiable claim, and the issuer is what makes it checkable.

The description states experience rather than only expertise. She has run production systems, which is the Experience half of E-E-A-T and the half most bios omit entirely.

Connecting Articles to the Profile

The profile only pays off if every article points at it, and the mechanism is @id reference rather than repetition.

The wrong pattern restates a partial Person on each article: a name, maybe a job title, no credentials, no sameAs. Your 30 articles then produce 30 thin entities that may or may not be recognised as the same human.

The right pattern is one canonical Person node on the profile page, referenced by @id from every byline.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Connection pooling in Postgres 18",
  "author": { "@id": "https://example.com/authors/priya-raman#person" },
  "publisher": { "@id": "https://example.com/#organization" }
}

That single reference does three things. It consolidates all authorship into one entity, it lets the full credential set travel to every article without duplication, and it means updating a credential is one edit rather than a site-wide find and replace.

One more detail worth honouring. Link the byline visibly to the profile page in the HTML, not only in the markup. Engines read visible content as well as structured data, and a byline that is plain text with markup underneath is weaker than one that is an actual link a reader can follow. Our post on author authority and byline optimisation covers how those signals are evaluated together.

Getting sameAs Right

sameAs is the highest-value property on the whole object, and it is almost always used badly.

Schema.org defines it as the URL of a reference page that unambiguously identifies the item. The operative word is unambiguously, and it is what separates a useful target from a decorative one.

The targets worth including, roughly in descending order of value.

• Independent registries and identifier systems. ORCID for researchers, a state bar or medical board record for licensed professionals, a professional body membership listing. These are third-party verified and cannot be self-asserted.
• Wikidata or Wikipedia, if the person genuinely has an entry. Do not create one for SEO reasons.
• Platform profiles where the work is visible. GitHub for an engineer, Google Scholar for an academic, SEC filings for an executive.
• LinkedIn, which is useful because it carries employment history a third party could dispute.
• Other social accounts, which are the weakest category because anybody can create one under any name.

The common failure is a sameAs array of 4 social profiles and nothing else. That corroborates that somebody registered 4 usernames. It does not corroborate that your author holds the expertise your page claims.

Two rules. Only list profiles that are actually the same person and actually live, since a dead link is a broken corroboration. And do not pad the array, because a short list of authoritative targets is stronger than a long list of weak ones.

Our guide to creating Person schema covers the entity in more depth, and our post on E-E-A-T in the age of AI covers why this corroboration has become load-bearing.

Validation and Common Errors

Validate with both the Rich Results Test and the Schema.org validator, then check the practical question the validators cannot answer: does an engine resolve this author to one entity?

Six errors account for most of the problems.

• Person with no ProfilePage wrapper. The entity exists but nothing declares which URL is canonical for it.
• ProfilePage with no mainEntity. The wrapper is empty and describes nothing.
• Multiple mainEntity values. A profile page has one subject. A page with several people is a CollectionPage.
• Articles restating Person instead of referencing @id. Produces competing duplicate entities.
• sameAs pointing only at social accounts. Weak corroboration for an expertise claim.
• knowsAbout listing broad categories. Marketing or Technology matches nothing. Name the actual subjects.

One further check that catches real problems. Search your author's name and see what Google currently associates with it. If the knowledge panel or the results resolve to somebody else with the same name, your markup has a disambiguation job to do, and that is precisely what stronger sameAs targets fix.

Frequently Asked Questions

Do I need ProfilePage if I already have Person markup?

Yes, on the author page itself. Person describes the human and can appear anywhere, while ProfilePage declares that this specific URL is the canonical description of them. Without the wrapper, nothing distinguishes the profile from the thirty other pages carrying the same name.

Can I use ProfilePage for a team page with several people?

No. ProfilePage has one mainEntity. A page listing several people is better marked as a CollectionPage or AboutPage containing Person references, each pointing at that individual's own profile page.

What does dateCreated do on a profile page?

It states when the profile came into existence, which Google's documentation highlights for creator and contributor surfaces. It separates a contributor with a seven-year history from an account created last month, and that distinction is a genuine authority signal.

Which sameAs links actually help?

Independent, third-party verified ones. ORCID, a licensing board record, a professional body listing, or Wikidata carry real weight because they cannot be self-asserted. A list of social accounts corroborates username registration and little else.

Should every article repeat the full author markup?

No. Define the Person once on the profile page with an @id, then reference that @id from every article. Restating partial copies creates competing entities and makes a credential update a site-wide edit.