Why many product pages underperform

How SwiftSchema helps

How it works

What is OfferShippingDetails structured data?

OfferShippingDetails describes shipping regions, rates, and delivery timing for an Offer. Use one object per region or policy to keep options clear and maintainable across your catalog.

Eligibility & Status

This type supports clarity and consistency for commerce but isn't a standalone rich result. Correct modeling helps Product/Offer eligibility and user expectations.

Why shipping markup matters

• Clarity at scale: Customers see accurate costs and timelines per region, reducing checkout friction.
• Policy enforcement: Structured delivery times ensure your on-page messaging mirrors logistics data.
• Automation: Region-specific objects let teams update shipping policies without touching every product page.
• Merchandising: Free-shipping thresholds and labels can be surfaced consistently in feeds.

Essential properties to include

• shippingDestination
  (
  DefinedRegion
  ): Always set
  addressCountry
  ; add
  addressRegion
  /
  postalCodeRange
  when needed.
• shippingRate
  (
  MonetaryAmount
  ): Provide
  value
  +
  currency
  ; set to 0 for free tiers.
• deliveryTime
  (
  ShippingDeliveryTime
  ): Include
  handlingTime
  and
  transitTime
  QuantitativeValues with min/max and
  unitCode=DAY
  .
• freeShippingThreshold
  (
  MonetaryAmount
  ): Order value that unlocks free shipping.
• shippingLabel
  : Text label to identify each shipping method.

Preparing shipping data before generating schema

1. Audit policies: Gather current rates, zones, and SLA windows from logistics.
2. Segment regions: Decide how granular you need (country, state, postal range).
3. Confirm currencies: Ensure rates use valid ISO currency codes.
4. Document thresholds: Capture free-shipping minimums or promotional rules.
5. Plan labels: Align labels (Standard, Express) with storefront messaging.
6. Sync with ops: Establish who updates schema when fulfillment rules change.

Implementation workflow inside SwiftSchema

1. Select Offer (or Product > Offer) in the generator.
2. Add
   shippingDestination
   for the region this policy covers.
3. Set
   shippingRate
   and optional
   freeShippingThreshold
   .
4. Provide
   deliveryTime
   with handling/transit ranges (
   unitCode=DAY
   ).
5. Add
   shippingLabel
   or notes for each method.
6. Repeat per region/policy and attach each object under
   Offer.shippingDetails
   .
7. Validate via the Rich Results Test.

Troubleshooting & QA

• Missing units: Always specify
  unitCode=DAY
  (or other ISO codes).
• Mixed regions: Keep one object per region/postal range.
• Threshold confusion: Pair
  freeShippingThreshold
  with clear on-page messaging.
• Incorrect nesting: Place objects under
  Offer.shippingDetails
  , not directly on Product.
• Stale data: Update schema when rates or transit windows change; scripts can compare schema to logistics tables.

Maintenance and governance

• Update shipping entries whenever logistics teams adjust policies.
• Audit quarterly to ensure schema matches storefront shipping tables and merchant feeds.
• Coordinate promotions—when running free shipping, adjust thresholds and revert afterward.
• Keep
  lastReviewed
  metadata current and note ownership for shipping schema updates.

Common Errors & Fixes

• Missing units: add
  unitCode=DAY
  for handling/transit time ranges.
• Mixed regions: provide separate objects per region or postal range.
• Unclear free shipping: add
  freeShippingThreshold
  MonetaryAmount and reflect policy in page content.
• Incorrect nesting: ensure the object sits under
  Offer.shippingDetails
  .

On-page parity checklist

• Shipping table on-page matches each
  shippingLabel
  ,
  shippingRate
  , and
  freeShippingThreshold
  .
• Regions shown to shoppers align with
  shippingDestination
  (country/region/postal ranges).
• Handling/transit times displayed match
  deliveryTime
  ranges; units are clear (days).
• When shipping is free over a threshold, the same threshold is stated in copy and applied at checkout.
• Only shipping methods you actually offer on-page are present in schema.

Content depth (avoid thin policy pages)

• Describe carriers/methods (Standard via USPS/UPS, Express, Same-day) and cutoff times.
• Explain exclusions (PO boxes, territories) and surcharges (oversize, hazardous).
• Provide packaging or sustainability notes (recyclable, minimal packaging) if relevant.
• Link to your returns policy and clarify how shipping fees are handled on returns.

Modeling multiple methods and carriers

• Use separate OfferShippingDetails objects for Standard vs. Express; include distinct
  shippingLabel
  values.
• For multi-country catalogs, localize currency/thresholds and keep per-country objects scoped via
  addressCountry
  .
• If transit times differ by carrier, reflect the longest/most conservative window unless you can route by carrier on-page too.

QA and governance

• Centralize shipping rules in a single data source that feeds both storefront and schema to prevent drift.
• Add automated checks to compare rendered shipping tables to JSON-LD values before deployment.
• Revalidate after promotions (free shipping weekends) and roll back thresholds when promos end.
• Audit quarterly to retire outdated regions, expired thresholds, or deprecated carriers.
• Keep
  lastReviewed
  updated after each logistics change and note the owner (ops/merchandising) responsible for shipping schema.
• When adding new carriers or service levels, document cutoff times and weekend/holiday behavior so
  deliveryTime
  remains accurate.
• If you surface ETA badges on PDPs, ensure they use the same handling/transit ranges as
  deliveryTime
  so customers see consistent promises.
• Document blackout regions (e.g., PO boxes, remote territories) in content and match them to
  shippingDestination
  exclusions.