What Is ShippingService Schema?

ShippingService is a Schema.org StructuredValue representing the criteria used to determine whether and how an Offer can be shipped to a customer.

It organizes fulfillmentType, handlingTime, shippingConditions, and validForMemberTier around one fulfillment option. An OfferShippingDetails or Organization can connect to it through hasShippingService.

The type is in Schema.org's new area, so teams should validate the vocabulary graph, the target consumer's support, and live checkout behavior independently. A valid entity is not automatically a selectable or accurate shipping option.

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 a real checkout service.
• Assign a stable entity identity.
• Add handling behavior.
• Attach complete conditions.
• Verify consumer and checkout.

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

Primary specification: Schema.org definition for ShippingService.

ShippingService is correct when one entity reproduces one real fulfillment option with the same availability, price, and timing as checkout.

ShippingService is connected through hasShippingService from OfferShippingDetails for Offer-specific context or from Organization for a genuinely merchant-wide service.

Offer-level placement can preserve product, seller, dimension, weight, and market differences. Organization-level placement can reduce duplication for a service that is truly shared, but its ShippingConditions and tier rules must prevent overreach.

Keep stable @id values when the same service entity is reused. Do not create accidental duplicates on every product page, and do not merge materially different services merely because they have the same visible name.

• 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. Choose policy scope.
2. Create a stable service identity.
3. Connect through hasShippingService.
4. Verify every dependent Offer.

See hasShippingService schema and OfferShippingDetails.

A ShippingService relationship is well scoped when reuse reduces duplication without broadening the service beyond its real Offer cohort.

fulfillmentType describes the fulfillment mode applicable to a ShippingService and should match the option shoppers can actually choose.

Delivery and on-site pickup have different operational paths. Delivery typically needs destination, rate, handling, and transit rules, while pickup needs preparation timing and location or availability context supported by the implementation.

Do not infer fulfillment type from a service name. A service called Local may mean local delivery, store pickup, or courier. Use the authoritative checkout configuration and a supported FulfillmentTypeEnumeration value.

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.

• List selectable fulfillment modes.
• Map each to a supported value.
• Separate materially different modes.
• Test availability by Offer.

fulfillmentType is accurate when it names the operational mode rather than repeating a marketing label.

handlingTime in ShippingService should use ServicePeriod to represent the delay from order receipt until goods leave the warehouse or are prepared for pickup.

ServicePeriod can combine duration, cutoffTime, and businessDays. This structure preserves the calendar logic that a bare one-day value misses. The cutoff also needs a time zone and an explicit exact-boundary rule in the commerce source.

Handling is separate from carrier transit. Test orders before, at, and after cutoff; on Fridays, weekends, holidays, warehouse closures, preorder dates, and multiple-origin products.

• 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. Capture order timestamp and zone.
2. Apply cutoff rule.
3. Count valid business periods.
4. Apply exceptions.
5. Compare dispatch or pickup-ready time.

handlingTime is trustworthy when the same order context produces the same operational readiness timestamp as fulfillment systems.

ShippingConditions define the constraints, price, availability, and transit behavior that apply to a ShippingService, and all conditions specified within one condition set must be met.

A condition can use destination, origin, order value, item count, weight, dimensions, seasonal overrides, doesNotShip, shippingRate, and transitTime. Separate entities can model alternate scenarios such as contiguous-US standard, remote-region surcharge, or oversized freight.

Resolve availability prohibitions before selecting rates. Do not combine incompatible alternatives into one condition record or allow a broad free-shipping rule to erase a narrow paid or unavailable outcome.

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.

• Group facts that apply together.
• Separate alternate scenarios.
• Resolve unavailable routes first.
• Select the narrowest valid condition.
• Compare checkout.

Review ShippingConditions schema.

ShippingConditions define a service correctly when their complete constraint set selects the same outcome as checkout.

Standard, express, and pickup should be separate ShippingService entities when their fulfillment mode, handling, price, timing, destination, or eligibility differs.

Standard may use a lower rate and longer transit window; express may have an earlier cutoff and higher price; pickup may have no carrier transit but require store preparation. Shoppers should see the same distinct options in the graph and checkout.

Avoid excessive fragmentation for cosmetic labels. If two names resolve to the identical service, conditions, and checkout option, one stable entity may be enough. If any material customer outcome differs, keep them separate.

• 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. Inventory checkout options.
2. Compare material criteria.
3. Create distinct stable IDs.
4. Attach accurate conditions.
5. Test each option.

Service granularity is right when entity boundaries match the choices and outcomes a customer experiences.

validForMemberTier limits a ShippingService to the membership tiers that actually receive it, preventing a private benefit from appearing universal.

A merchant can expose a free members service alongside a paid public service. Tier identity should use the same stable membership graph as the Offer and program. Destination, product, seller, and fulfillment exceptions can still limit the benefit.

Test signed-out shoppers, each eligible tier, ineligible tiers, expired accounts, trials, excluded products, and unsupported destinations. A zero rate without correct tier scope is a false shipping promise.

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 authoritative tier IDs.
• Connect eligible services only.
• Keep public alternatives.
• Preserve condition exceptions.
• Test account states.

Member-tier shipping is accurate when entitlement, conditions, and checkout availability agree for every account state.

Common mistakes include creating empty service entities, using names as policy, merging fulfillment modes, attaching wrong handling types, mixing handling and transit, omitting tier scope, duplicating identities, and widening Organization-level services.

Other defects include orphaned ShippingConditions, conflicting availability, missing currencies, stale calendars, destination overlap, rate formulas that disagree with checkout, and validating syntax without proving that a shopper can select the option.

Repair the authoritative commerce and fulfillment sources. Shared services can affect large Offer cohorts, so map dependencies, stage changes, keep entity IDs stable, and retain regression carts.

• 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. Crawl every service entity.
2. Resolve identities and dependents.
3. Inspect handling and conditions.
4. Compare checkout choices.
5. Repair shared sources.

ShippingService defects require entity, mode, timing, condition, entitlement, and checkout validation together.