What Is member Schema?

member is the Schema.org property that identifies a Person or Organization belonging to an Organization or represented by a ProgramMembership.

The property points from the membership container to the member. A trade association can name a member company, while a ProgramMembership can identify the person who holds that loyalty relationship. The subject can be Organization or ProgramMembership, and the value can be Person or Organization. This is different from the program, tier, account number, or hosting organization. Accurate direction and type choices prevent one membership graph from confusing who belongs with who offers the program.

• Use member on Organization or ProgramMembership.
• Use Person or Organization as the value.
• Keep program, host, tier, and identifier relationships separate.

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 member.

member identifies who belongs; it does not identify the program, membership number, or organization offering benefits.

member is used on Organization and ProgramMembership, with Person or Organization values.

On Organization, it can represent individual or organizational membership when publication is appropriate. On ProgramMembership, the membership is typically associated with an individual, although the vocabulary permits Organization as a value. The page must support the relationship visibly and ethically. A public directory may have permission to name members; a private loyalty account generally does not justify exposing a customer identity in public structured data. Domain and range validity are only the starting point.

1. Identify whether the subject is Organization or ProgramMembership.
2. Confirm the member is a Person or Organization.
3. Check consent, authorization, and page visibility.
4. Add the relationship only when the page actually establishes 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 the property where both the entity relationship and the disclosure context are accurate.

member and memberOf are inverse directions: an Organization or ProgramMembership points to its member, while a Person or Organization points to the group or membership it belongs to.

A public association page may list organizations through member. Each member organization can point back through memberOf when its own page discusses that affiliation. A Person can similarly point to an Organization or ProgramMembership. Both directions are optional, but when both are published, canonical ids must agree. A person pointing to Membership A while Membership B names that person creates a contradiction even if each block is structurally valid.

1. Choose canonical ids for both sides.
2. Publish member from the container where useful.
3. Publish memberOf from the member where useful.
4. Compare reciprocal references in rendered output.

• 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

The inverse pair is valuable only when it describes one evidence-backed relationship from both sides.

On ProgramMembership, member identifies the Person or Organization holding that specific membership relationship.

The membership can separately connect to MemberProgram through program, Organization through hostingOrganization, tier through validForMemberTier, points through membershipPointsEarned, and an account code through membershipNumber. None of those replaces member. In most loyalty contexts the holder is a Person, but business purchasing clubs or partner programs may support organizational members. Avoid creating a ProgramMembership simply to repeat a public biography; the page should genuinely describe a membership relationship.

• member answers who holds the membership.
• program answers which MemberProgram is involved.
• hostingOrganization answers who offers it.
• validForMemberTier answers which tier applies.
• membershipNumber is a private identifier, not member identity.

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 clean ProgramMembership gives every relationship one job and keeps identity separate from program and account facts.

For B2B structures, an Organization can use member to identify a member company, nonprofit, institution, chapter, or other Organization when the relationship is current and public.

Examples include chambers, trade associations, purchasing cooperatives, standards bodies, and partner networks. Do not confuse membership with parentOrganization, subOrganization, department, funder, sponsor, vendor, customer, or affiliate relationships. A logo wall or partner page may use “member” informally even when the legal or contractual relationship is sponsorship. Review the organization’s membership criteria, directory language, terms, and reciprocal pages before modeling the edge.

1. Define what membership means in the organization.
2. Verify the member’s current status.
3. Distinguish membership from ownership and partnership.
4. Use stable Organization ids for both sides.
5. Remove relationships when membership ends.

• 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

B2B member markup should follow an actual membership relationship, not a broad marketing use of the word partner.

Person membership should stay private whenever disclosure is not clearly public, authorized, expected, and necessary for the page.

Loyalty accounts, travel clubs, health groups, professional associations, unions, subscriber programs, and community memberships can reveal habits, status, beliefs, location, or identity. Authenticated display does not automatically justify adding machine-readable Person details. Public marketing pages should model the program rather than its customers. Public directories should use member only when membership is intentionally published and the individual has appropriate control or authorization.

• Do not publish customer lists for SEO.
• Minimize Person fields on authenticated pages.
• Respect directory visibility and consent settings.
• Avoid member ids, emails, balances, and reservation details.
• Test analytics, logs, caching, and client state.

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 member edge should never expand a person’s exposure beyond the relationship they intended to make public.

Migrate from the superseded members property to member by preserving the same verified relationships, updating every emitter, and testing downstream consumers before removing legacy output.

The older property may remain in stored templates, feeds, microdata, emails, and partner integrations. Inventory all sources before switching. During a brief coexistence window, derive both outputs from one authoritative relationship set to avoid differences. Do not use the migration to bulk-publish private records or to convert every contact into a member. Once verified consumers accept member, remove members and add a guard against its return.

1. Search templates, serializers, feeds, and stored content.
2. Classify each relationship and its disclosure status.
3. Emit member from the authoritative membership source.
4. Test consumers and rendered entity graphs.
5. Remove members after verified migration.
6. Add a regression check for superseded output.

• 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

A safe migration changes the property without changing who is publicly identified as a member.

Common mistakes include reversing the relationship, using unsupported value types, publishing private people, confusing membership with employment or ownership, and keeping superseded members output.

Teams may place member on Person instead of using memberOf, point to ProgramMembership as the value, or add plain Text names instead of Person or Organization entities. Templates can also expose every loyalty customer or CRM contact. In B2B graphs, parent companies, sponsors, vendors, and directory listings are often mislabeled as members. Validation can catch type problems but not consent, current status, or relationship truth.

• member placed on Person instead of Organization or ProgramMembership.
• Text or ProgramMembership used as the value.
• Customer roster published from account data.
• Partner or subsidiary mislabeled as member.
• Expired memberships left active.
• Superseded members property still emitted.

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.

Technical correctness, relationship truth, currency, and privacy all belong in the same quality check.