Free Offer Shipping Details Schema Generator

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.
• Free shipping: set shippingRate.value to 0. OfferShippingDetails has no threshold property; order-value rules belong in Organization-level shipping policy markup (ShippingConditions with orderValue).
• 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 (use 0 for free shipping).
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: State any free-shipping minimum clearly on the page; describe it in Organization-level ShippingConditions (orderValue) rather than on the offer.
• 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: set shippingRate.value to 0 where shipping is free, and state any minimum order value on the page.
• Incorrect nesting: ensure the object sits under Offer.shippingDetails.

On-page parity checklist

• Shipping table on-page matches each shippingLabel and shippingRate.
• 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.