What Is affiliation Schema?

affiliation is the Schema.org property that connects a Person to an Organization with which that person is affiliated.

It can represent a relationship with a school, university, research institute, club, team, professional body, or another organization when the page and evidence support that description. The subject must be Person and the value must be Organization. affiliation is a subproperty of memberOf, but it has its own narrower meaning and does not automatically state employment, alumni status, ownership, leadership, or a current formal membership.

• Place affiliation on Person.
• Use Organization as the value.
• Describe only an evidence-backed affiliation.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Primary specification: Schema.org definition for affiliation.

affiliation links one person to one organization while leaving employment, alumni, and corporate roles to more precise properties.

affiliation is used on Person and expects an Organization value.

It should not be placed on Organization to list people, on Organization to describe partner companies, or on a CreativeWork to name its publisher. If the organization wants to list members, member may fit. If a work identifies its author, use author. If a person works for a company, worksFor may be more precise. Correct subject and value types make the relationship understandable across profile, article, author, research, medical, sports, and institutional pages.

1. Identify the Person entity.
2. Create or reference the affiliated Organization.
3. Confirm the page states the affiliation.
4. Choose a more specific property when the relationship requires it.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Use affiliation only from Person to Organization and model other directions with their own relationship properties.

affiliation is a narrower subproperty of memberOf for a Person’s organizational affiliation, while memberOf covers broader membership for both Person and Organization subjects.

memberOf can point to Organization, ProgramMembership, or MemberProgramTier. affiliation only points from Person to Organization. A public professional relationship may be described as an affiliation even when formal membership is not the clearest framing. Conversely, a trade association membership, loyalty membership, or tier status may fit memberOf better. Choose based on what the page claims, not on which property appears more broadly recognized.

• Use affiliation for a supported Person–Organization affiliation.
• Use memberOf for explicit membership or program/tier belonging.
• Do not use affiliation for Organization subjects.
• Keep reciprocal member markup only where formal membership exists.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

affiliation is the focused Person–Organization edge; memberOf remains the broader membership vocabulary.

worksFor states an employment relationship, while affiliation can describe a broader institutional connection that is not necessarily employment.

A full-time employee, contractor whose public role is employment-like, or staff profile may use worksFor. A visiting researcher, external fellow, advisory participant, clinical affiliate, team participant, or institute-associated author may fit affiliation if that wording matches the source. Do not weaken a clear employer relationship into affiliation merely to avoid maintaining dates or roles, and do not turn every conference appearance or customer relationship into an affiliation.

1. Read the person’s current role wording.
2. Check the organization’s profile or directory.
3. Use worksFor when employment is explicit.
4. Use affiliation when the institutional connection is broader.
5. Omit the relationship when evidence is ambiguous.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Choose worksFor for employment and affiliation for a genuine broader institutional connection.

alumniOf identifies an organization a Person attended or graduated from, while affiliation usually represents a current or otherwise stated institutional association.

A former student relationship should not be kept as a current affiliation unless the person also holds a present role, fellowship, club membership, or another active connection. Alumni status can coexist with worksFor or affiliation when the person later joins the same institution in a different capacity, but each edge must describe its own truth. Dates and OrganizationRole may help when the timeline materially matters.

• Use alumniOf for past education or alumni status.
• Use affiliation for a current supported association.
• Use worksFor for current employment.
• Model multiple relationships separately when they truly coexist.
• Remove or update stale profile language.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Past education, current employment, and broader affiliation are separate facts and should remain separate edges.

Author and expert profiles should use affiliation only when the organization relationship is current, relevant, publicly supported, and connected to the correct Person identity.

Editorial systems often copy a bio into many articles. A stale affiliation can therefore spread across hundreds of pages after a person changes roles. Centralize the Person and Organization entities, reuse stable @id values, and maintain the current relationship in one governed profile record. Do not infer affiliation from an email domain, article topic, quoted title, conference badge, or a third-party biography without current first-party evidence from the person or organization.

1. Resolve the canonical Person identity.
2. Resolve the canonical Organization identity.
3. Verify the current affiliation from an authoritative profile.
4. Update shared author data rather than article copies.
5. Retest all templates that emit the Person node.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Centralized, evidence-backed profile data keeps affiliation consistent across every page that reuses the person entity.

A Person can have multiple affiliation values when each organization relationship is independently accurate, current or clearly dated, and appropriate to publish.

Researchers, clinicians, advisors, athletes, and creators may hold several roles. Do not collapse all organizations into one text string or assume equal importance. Reuse canonical Organization ids and, when necessary, model roles and dates separately rather than forcing them into the affiliation property. A secondary connection should not overwrite the primary employer, and an old affiliation should not remain current merely because an article is still live.

• Create one Organization entity per affiliation.
• Reuse stable ids across author and profile pages.
• Keep employment in worksFor where appropriate.
• Use role and date modeling for time-bound context.
• Retire or mark historical relationships accurately.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Multiple affiliations are valid when each relationship keeps its own identity, scope, and lifecycle.

Common mistakes include using the wrong subject or value type, confusing affiliation with employment or alumni status, copying stale bios, inventing relationships, and duplicating identities.

Teams may put affiliation on Organization, use Text instead of Organization, infer it from article topics, or treat clients and partners as personal affiliations. Shared author templates can preserve a former employer indefinitely. Localized sites may create a new Organization @id per language, fragmenting one institution. Basic validation catches type mistakes but cannot prove currency, authorization, or relationship meaning.

• affiliation placed on Organization or CreativeWork.
• Text used instead of an Organization entity.
• Employer modeled as affiliation without reason.
• Former institution left as current.
• Customer, sponsor, or event host treated as affiliation.
• Duplicate Person or Organization ids across templates.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

A valid affiliation must also be current, specific, authorized, and tied to stable Person and Organization entities.