What Is hasShippingService Schema?

hasShippingService is a Schema.org property that connects an OfferShippingDetails or Organization entity to a ShippingService offered by the organization.

Its expected value is ShippingService. The service can organize fulfillment type, handling time, shipping conditions, and member-tier eligibility into a coherent entity instead of scattering unrelated shipping facts across a page.

The term is in Schema.org's new area, so implementation feedback and adoption can still shape its definitions. Treat vocabulary validity, consumer support, and checkout truth as three separate checks before scaling it across a US ecommerce catalog.

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.

• Use a supported parent.
• Point to a ShippingService entity.
• Preserve stable identity.
• Test the target consumer and checkout.

Use the free backlink checker to identify linked product pages before changing a shared shipping-service graph.

Primary specification: Schema.org definition for hasShippingService.

hasShippingService is accurate when the connected service represents the same fulfillment option and conditions a shopper can actually select.

hasShippingService can be used on OfferShippingDetails for Offer-level shipping context and on Organization for services offered across the merchant.

Choose placement from the policy scope. An Offer-specific service belongs with the relevant OfferShippingDetails. A genuinely merchant-wide service may be declared from Organization, but its conditions must still prevent it from overreaching into excluded products, sellers, markets, or membership cohorts.

Do not attach the property directly to Product, Offer, ShippingConditions, ShippingRateSettings, or MonetaryAmount. Those entities play different roles in the graph even when they participate in the same checkout outcome.

• 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

1. Identify policy scope.
2. Choose Offer or merchant parent.
3. Create one stable service entity.
4. Attach conditions beneath the service.

Review OfferShippingDetails before selecting the Offer-level path.

Correct placement keeps service ownership explicit without turning a narrow shipping option into a universal merchant promise.

ShippingService represents the criteria used to determine whether and how an Offer can be shipped to a customer.

It is a StructuredValue that can carry fulfillmentType, handlingTime, shippingConditions, and validForMemberTier. The service is therefore more than a carrier name: it organizes the operational rules that define an available fulfillment option.

Give each material service a stable identity and a human-readable name, but do not infer conditions from the name. Standard, Express, Pickup, and Members Free Shipping still need explicit timing, price, destination, eligibility, and exception data.

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.

• Identify the actual fulfillment option.
• Assign stable identity.
• Add handling behavior.
• Add complete conditions.
• Add tier scope when real.

A ShippingService entity is complete when its identity and operational criteria reproduce one selectable fulfillment option.

shippingConditions attaches one or more ShippingConditions policies whose specified constraints must all be met for that condition set to apply to the ShippingService.

Conditions can constrain destination, origin, order value, item count, weight, dimensions, seasonal periods, availability, transit time, and rate. Multiple condition entities can represent standard versus exceptional routes without mixing every rule into one ambiguous record.

Treat each condition as a conjunction within its own scope. If a cart misses one required boundary, that condition should not supply its price or timing. Model alternate eligible scenarios as separate deterministic conditions.

• 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

1. List all required constraints.
2. Group facts that apply together.
3. Separate alternative policies.
4. Resolve prohibitions before rates.
5. Test boundary carts.

See ShippingConditions schema.

ShippingConditions stay reliable when every applicable constraint is satisfied before their rate or transit time is used.

Within ShippingService, handlingTime should use ServicePeriod so duration, cutoff time, and business days can describe the order-to-dispatch process together.

Handling time starts when the order is received and ends when goods leave the warehouse or are prepared for pickup. It is separate from transit time, which begins after dispatch and ends at customer arrival.

Preserve the local cutoff zone, exact boundary behavior, weekday schedule, holidays, warehouse closures, preorder delays, and origin-specific calendars. A generic one-day value can be false for orders placed after cutoff or on non-business days.

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.

• Record order timestamp and zone.
• Apply cutoff boundary.
• Count valid business periods.
• Add exceptions.
• Compare dispatch promise.

handlingTime is accurate when identical order timestamps produce the same dispatch or pickup-ready time as fulfillment operations.

Model standard, express, pickup, and other materially different fulfillment options as distinct ShippingService entities with their own handling, conditions, rates, timing, and eligibility.

A cheap slower option and a fast expensive option should not share one service identity if their operational criteria differ. Pickup should not inherit shipping destinations or carrier transit rules that do not apply to on-site fulfillment.

At the same time, avoid duplicating entities for cosmetic names alone. Use one service identity when the underlying policy is truly identical, and separate it when checkout exposes a distinct option or different condition matrix.

• 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

1. List selectable checkout options.
2. Compare fulfillment criteria.
3. Create stable service identities.
4. Attach distinct conditions.
5. Test each option independently.

Service modeling is appropriately granular when every checkout option has one matching entity and no entity invents a choice shoppers cannot select.

Membership-specific shipping services can use validForMemberTier, but the benefit must remain limited to the exact tiers and Offers that receive it at checkout.

An Organization may expose members-free and paid-standard services, while an OfferShippingDetails entity can have its own tier-scoped option. A free rate without tier eligibility can turn a private benefit into a universal public promise.

Use stable tier identifiers that match the membership program graph. Test signed-out shoppers, every eligible tier, ineligible tiers, expired memberships, trial states, excluded products, and destination exceptions.

• 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

1. Identify authoritative tier IDs.
2. Attach only eligible services.
3. Keep public alternatives.
4. Test auth and exception cohorts.

Tier-scoped shipping is honest when only eligible members receive the service and every public shopper retains the correct alternative.

Common mistakes include using the wrong parent or value type, attaching empty ShippingService entities, treating service names as policy, mixing standard and express conditions, omitting member scope, combining handling and transit time, and widening merchant-level services too far.

Other defects include duplicate service IDs, orphaned conditions, conflicting rates, destinations with both available and unavailable outcomes, stale calendars, missing currencies, and graph structures that validate but disagree with checkout.

Fix the commerce and fulfillment sources rather than patching one rendered page. A shared Organization-level service can affect a large catalog, so quantify reach, stage changes, and retain regression carts for every important condition cohort.

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.

• Crawl every relationship.
• Validate parent and entity identity.
• Inspect conditions and eligibility.
• Compare selectable checkout options.
• Repair shared sources.

hasShippingService defects require relationship, service, condition, eligibility, timing, and checkout validation together.