What Is hasTiers Schema?

hasTiers is the Schema.org property that connects a MemberProgram to one or more MemberProgramTier entities.

It expresses the program’s tier architecture rather than describing a tier in isolation. A retailer can use it to connect a loyalty program with Silver, Gold, and Platinum entities, each carrying its own benefits, requirements, points rate, URL, and stable identity. The value must be MemberProgramTier. Plain strings may look readable, but they cannot support the same entity relationships or reuse across offers, shipping rules, and return policies.

• Place hasTiers on MemberProgram.
• Use one MemberProgramTier entity per real tier.
• Assign stable @id values that remain consistent across pages.

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

hasTiers creates the program-to-tier map; tier properties then explain what each level means.

hasTiers is used on MemberProgram and its values are MemberProgramTier entities.

That narrow domain is important. It should not be placed directly on Organization, Product, Offer, ProgramMembership, or Person. An Organization can point to its program with hasMemberProgram; the program then points to tiers with hasTiers. Offers and policies can reference a tier through validForMemberTier. Keeping each relationship on the correct type produces a graph that is easier to validate, reuse, and audit than a flat block containing unrelated fields.

1. Create or reference the Organization.
2. Connect it to MemberProgram with hasMemberProgram.
3. List each tier from MemberProgram with hasTiers.
4. Reference applicable tiers from commercial entities where appropriate.

• 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 hasTiers only on MemberProgram and let adjacent properties carry the surrounding relationships.

hasTiers and isTierOf express the same program-tier relationship in opposite directions.

A MemberProgram uses hasTiers to enumerate its tiers, while a MemberProgramTier can use isTierOf to identify its parent program. Sites may publish either direction where it matches the page subject, or both when they need a strongly connected entity graph across separate URLs. The critical rule is agreement: every tier listed by a program should point back to that same program if isTierOf is also present. Conflicting @id values create ambiguity even when each individual block passes basic syntax validation.

1. Choose canonical @id values for the program and tiers.
2. Emit hasTiers on the program page.
3. Emit isTierOf on dedicated tier pages when useful.
4. Compare both directions during every structured-data audit.

• 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 properties are most useful when both directions resolve to the same canonical entities.

Model every materially distinct loyalty level as a separate MemberProgramTier value inside the program’s hasTiers collection.

Do not compress several tiers into one text sentence or create one generic Tier node with changing names. Each tier should have a stable @id, clear name, visible supporting URL when available, and properties matching the current program terms. Free entry levels still deserve their own entities when they grant distinct benefits. Invitation-only or card-linked levels may also qualify, provided the page accurately explains their existence and requirements. Ordering in a JSON array can mirror the customer journey, but identity must not depend on array position.

• Represent each real level once.
• Keep tier names aligned with customer-facing terms.
• Use separate @id values even when benefits overlap.
• Remove retired levels or clearly distinguish historical pages.

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 useful tier graph mirrors real customer choices without inventing distinctions the program does not make.

Each MemberProgramTier should carry only the properties that truthfully describe that tier, such as name, hasTierBenefit, hasTierRequirement, and membershipPointsEarned.

The hasTiers property merely connects the entities; it does not replace detailed tier modeling. Benefits can identify loyalty prices, points, shipping, or other supported benefit values. Requirements can describe spending thresholds, recurring fees, eligible cards, or explanatory text. Points earnings may be a Number or QuantitativeValue. Keep monetary amounts paired with currency and do not translate marketing promises into precise structured values unless the page provides the same facts.

• Use name for the customer-facing tier label.
• Use hasTierBenefit for supported benefits.
• Use hasTierRequirement for qualification rules.
• Use membershipPointsEarned for the stated earning rate.
• Use url and @id to maintain a durable 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.

Connect tiers with hasTiers, then describe each one with current, visible, and correctly typed facts.

A hasTiers JSON-LD implementation should place MemberProgramTier objects or references inside a MemberProgram node.

Inline tier objects work well on a complete program overview because readers can see the tier comparison on the same page. References by @id work well when tiers also have dedicated landing pages or appear elsewhere in a larger graph. Both approaches are valid if each reference resolves to one consistent entity. Avoid nesting an Organization where a tier is expected, copying an Offer as a tier, or emitting empty objects simply because a template expects a fixed number of levels.

1. Declare the MemberProgram node.
2. Add hasTiers as an array when multiple levels exist.
3. Create each MemberProgramTier with a stable @id.
4. Add only properties supported by rendered content.
5. Validate the final rendered JSON-LD, not just the template.

• 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

Good JSON-LD makes each tier reusable, resolvable, and consistent with what customers can read.

Offers, shipping services, prices, and return policies should reference tier entities through validForMemberTier rather than duplicating the program’s hasTiers list.

This separation lets one canonical MemberProgram define its available levels while individual commercial rules identify which levels qualify. A Gold-only price can point to the same Gold @id already listed in hasTiers. A free-shipping rule can reference several tier entities without redefining their names or requirements. Reusing identities reduces drift when benefits change and makes it possible to audit every commercial promise connected to a tier.

1. Build the canonical tier list on MemberProgram.
2. Assign stable @id values to every tier.
3. Reference those ids from eligible offers or policies.
4. Compare structured eligibility with visible checkout and policy language.

• 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

Define tiers once through hasTiers and reuse those identities wherever commercial eligibility applies.

Common hasTiers errors include using text values, placing the property on the wrong type, duplicating tier identities, and publishing stale program levels.

Template-driven sites may also emit blank tier objects, reuse one @id for every level, or mismatch hasTiers with isTierOf. Mergers and redesigns often leave old tier URLs alive while a new program graph creates replacement nodes. A validator can identify structural errors, but it cannot confirm whether Gold still exists or whether a stated threshold matches the current program. Content, policy, account, and checkout evidence must be checked together.

• Plain strings instead of MemberProgramTier entities.
• hasTiers attached to Organization or Offer.
• One @id reused for multiple tier names.
• Retired tiers left in live markup.
• Benefits and requirements that contradict visible terms.

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.

Passing syntax is not enough; the complete tier graph must remain accurate across every customer surface.