AI Search Author Schema Specification

AI-search author markup uses schema.org Person with stable identifiers (sameAs to Wikidata, ORCID, LinkedIn), credentials via hasCredential, and a knowsAbout topical-authority list, so AI engines can disambiguate the author and weigh expertise signals when deciding to cite the page.

TL;DR

AI answer engines weigh author expertise when deciding whom to cite. A bare "author": "Jane Doe" string is the weakest possible signal. A complete author schema is a Person object with a stable @id, multiple sameAs identifiers (Wikidata, ORCID, LinkedIn, GitHub, university page), a jobTitle, a worksFor organization, hasCredential entries for verifiable credentials, and a knowsAbout array describing topical authority. This spec defines the required and recommended fields, the JSON-LD shape, and the validation rules.

Why author schema matters for AI search

Google's E-E-A-T guidelines (Experience, Expertise, Authoritativeness, Trustworthiness) put author identity at the center of quality assessment (Google Search Quality Rater Guidelines). AI answer engines inherit and reinforce this pattern: when multiple pages contain a similar answer, the engine that can identify a credentialed expert tends to cite that source.

More concretely, structured author data delivers three measurable benefits:

Disambiguation. Two writers named "Jane Doe" become different entities once each has a sameAs Wikidata or ORCID identifier.
Topical-authority weighting. knowsAbout and hasCredential give AI engines explicit expertise signals.
Cross-citation graph. AI engines that connect the author to other pages they have written treat the new page as part of a topical body of work.

Search Engine Land's coverage of schema for AI search summarizes the underlying behavior: AI engines weight "entity disambiguation, relationships between entities, and machine-readable structure" (How schema markup fits into AI search).

Required fields

Every author schema in JSON-LD must include the following.

Field	Required	Notes
@type	yes	Must be Person (or a subtype like Physician for regulated content)
@id	yes	Stable URI for the author across all pages — use the author's profile URL
name	yes	Full display name
url	yes	Canonical author profile page on the publisher's site
image	yes	Headshot URL (square, ≥ 256px)
jobTitle	yes	Current role
worksFor	yes	Organization object with @id, name, url

Missing any of these reduces the author's identifiability. AI engines fall back to the name string only, which is the weakest disambiguation signal.

Recommended fields

These fields are not strictly required but materially lift authority signals.

Field	Purpose
sameAs	Array of canonical identifiers — see the next section
hasCredential	Verifiable credentials, degrees, certifications
knowsAbout	Topical-authority array of subjects the author covers
alumniOf	Educational institutions with @id linkable to Wikidata
award	Notable awards or recognitions
description	One-paragraph bio focused on expertise, not personality
birthDate	Helpful for disambiguation in regulated domains

The sameAs field: identifier ladder

sameAs is the single highest-leverage field. It links your author entity to canonical external identifiers AI engines already trust. Aim for at least three entries from the following ladder, in this priority order:

Wikidata (https://www.wikidata.org/wiki/Q…) — highest weight; use the author's Wikidata Q-ID if it exists.
ORCID (https://orcid.org/0000-…) — academic and scientific authors.
LinkedIn profile URL.
GitHub profile (for technical authors).
Publisher staff page on a recognized organization (university, news outlet).
Twitter/X, Mastodon, or Bluesky verified handles.
Personal domain (only when the domain has its own authority).

Do not pad with low-authority links. Three high-quality identifiers outperform ten weak ones.

The hasCredential field: verifiable credentials

hasCredential accepts an EducationalOccupationalCredential object. Each credential should be specific, verifiable, and dated.

"hasCredential": [
  {
    "@type": "EducationalOccupationalCredential",
    "name": "PhD in Computer Science",
    "credentialCategory": "degree",
    "recognizedBy": {
      "@type": "Organization",
      "name": "Carnegie Mellon University",
      "sameAs": "https://www.wikidata.org/wiki/Q190080"
    },
    "dateCreated": "2018"
  }
]

For regulated domains (medical, legal, financial), use the matching schema.org subtype where it exists — Physician for clinicians, with medicalSpecialty and usNPI fields.

The knowsAbout field: topical authority

knowsAbout accepts strings or Thing objects with @id. Prefer Wikidata-anchored Things over bare strings.

"knowsAbout": [
  {
    "@type": "Thing",
    "name": "Generative Engine Optimization",
    "sameAs": "https://en.wikipedia.org/wiki/Generative_engine_optimization"
  },
  {
    "@type": "Thing",
    "name": "Answer Engine Optimization",
    "sameAs": "https://en.wikipedia.org/wiki/Answer_engine_optimization"
  },
  "AI search ranking signals"
]

Keep the list focused (5-10 items). Padding with unrelated subjects dilutes the signal.

Full example

{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://geodocs.dev/authors/jane-doe",
  "name": "Jane Doe",
  "url": "https://geodocs.dev/authors/jane-doe",
  "image": "https://geodocs.dev/authors/jane-doe.jpg",
  "jobTitle": "Principal Researcher",
  "worksFor": {
    "@type": "Organization",
    "@id": "https://geodocs.dev/#organization",
    "name": "Geodocs",
    "url": "https://geodocs.dev"
  },
  "sameAs": [
    "https://www.wikidata.org/wiki/Q123456789",
    "https://orcid.org/0000-0002-1234-5678",
    "https://www.linkedin.com/in/janedoe",
    "https://github.com/janedoe"
  ],
  "hasCredential": [
    {
      "@type": "EducationalOccupationalCredential",
      "name": "PhD in Information Retrieval",
      "credentialCategory": "degree",
      "recognizedBy": {
        "@type": "Organization",
        "name": "Stanford University"
      },
      "dateCreated": "2017"
    }
  ],
  "knowsAbout": [
    "Generative Engine Optimization",
    "Answer Engine Optimization",
    "Retrieval-Augmented Generation",
    "AI search ranking signals"
  ],
  "alumniOf": {
    "@type": "CollegeOrUniversity",
    "name": "Stanford University",
    "sameAs": "https://www.wikidata.org/wiki/Q41506"
  },
  "description": "Researcher focused on how AI answer engines retrieve and cite web content."
}

Embedding the author in an Article

Reference the author entity by @id from the article schema rather than re-declaring the full Person object. This keeps the entity graph clean.

{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "What Is AEO?",
  "author": { "@id": "https://geodocs.dev/authors/jane-doe" },
  "publisher": { "@id": "https://geodocs.dev/#organization" }
}

The full Person object lives on the author's profile page; every article references it by @id.

Validation

Validate JSON-LD with the schema.org Validator and Google's Rich Results Test.
Confirm sameAs URLs resolve and reference the same person.
Spot-check Wikidata identifiers by clicking through and verifying biographical data matches.
Re-run validation after every author profile edit; staleness in worksFor or hasCredential is the most common error.

Common mistakes

Using a string "author": "Jane Doe" instead of a Person object.
Omitting @id, so each article re-declares a separate, unconnected author entity.
sameAs URLs that 404 or redirect to a different person.
knowsAbout padding (15+ unrelated topics).
Credentials that are not verifiable ("AI Expert" with no recognizing organization).
Embedding the full Person object on every article page instead of referencing by @id.
Mismatch between the author bio paragraph and the structured description.

How to apply: implementation checklist

[ ] Every page with an author renders a Person object in JSON-LD
[ ] Each author has a stable @id reused across all their articles
[ ] sameAs includes at least three high-authority identifiers (Wikidata, ORCID, LinkedIn preferred)
[ ] hasCredential lists verifiable degrees and certifications with recognizedBy
[ ] knowsAbout lists 5-10 focused topics, ideally with Wikidata sameAs
[ ] Author profile page exists at the url and is canonical
[ ] Articles reference the author by @id, not by re-declaring the full Person
[ ] Markup validates in schema.org Validator and Rich Results Test
[ ] Author headshot served at ≥ 256px from a stable URL
[ ] Re-validation runs as part of CI on every author profile change

FAQ

Q: Do I need a Wikidata entry for every author?

No, but it is the highest-weight sameAs value when one exists. For authors without a Wikidata entry, ORCID (academic) or LinkedIn (professional) are strong substitutes. If your authors are notable enough to have public bibliographies, creating Wikidata entries is a high-leverage one-time investment.

Q: How is this different from generic Person schema?

The generic Person schema works, but AI-search-optimized author schema specifically emphasizes sameAs, hasCredential, and knowsAbout because these are the fields AI engines use for expertise weighting. A minimal Person object with only name and url is technically valid but provides almost no AI-search lift.

Q: Should I include birthDate?

Only when it materially helps disambiguation (common name, regulated domain). Privacy-conscious publishers can omit it; year-only birthDate is a reasonable middle ground.

Q: What if an article has multiple authors?

Use an author array of Person objects, each referenced by @id. The first entry should be the primary author. Avoid Organization as the sole author for journalistic content; AI engines weight named-individual authorship higher.

Q: Does this affect Google rich results?

Google does not currently expose author schema as a rich result, but it documents author markup as a relevance signal for E-E-A-T evaluation. The primary value is AI-search citation lift, not SERP appearance.

Q: How often should I update author profiles?

On every meaningful change (job title, credential, new topical focus) and at minimum annually. Stale worksFor or jobTitle is the most common audit finding.