What Is ShippingDeliveryTime Schema?

ShippingDeliveryTime is a structured-data type that represents the delay from order receipt to customer delivery by separating handling time from carrier transit time.

It normally appears inside the deliveryTime property of OfferShippingDetails. The model can also describe business days and an order cutoff. It does not replace a delivery date promised for a specific checkout session; it publishes a defensible range for a defined offer, destination, and 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.

• Keep handling and transit separate.
• Use non-negative whole-day ranges.
• Match the visible delivery promise.

Use the free backlink checker while auditing important commerce destinations.

Primary specification: Schema.org definition for ShippingDeliveryTime.

ShippingDeliveryTime is accurate when its complete timing model reproduces the delivery window customers can reasonably receive.

ShippingDeliveryTime belongs inside OfferShippingDetails, which connects to the Product Offer that owns the destination, shipping rate, and delivery option.

The nesting preserves scope. A Product can have several Offers, and each Offer can support several regions or services. Economy delivery to California may not share timing with expedited delivery to Alaska. Placing one delivery time at Product level would erase those commercial differences.

• 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. Map the Product and its Offers.
2. Separate destinations and shipping methods.
3. Create one coherent shipping-details entity per rule.
4. Nest the delivery time in that rule.
5. Validate the full rendered graph.

See OfferShippingDetails schema for the surrounding rate and destination model.

Correct nesting keeps every delivery estimate attached to the rate, region, and Offer where it is actually valid.

Handling time measures warehouse processing before carrier handoff, while transit time measures carrier movement from handoff to final delivery.

Combining the two hides operational causes and produces weak estimates. A same-day handling operation with five-day ground transit is different from a three-day made-to-order process with two-day air service, even though both can total five days. Separate ranges let teams update the component that changed.

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.

• Measure processing from order acceptance.
• End handling at actual carrier handoff.
• Start transit at the same handoff event.
• Do not double-count an intermediate day.

Warehouse cutoffs and carrier pickup schedules can shift the boundary, so the operational definition should be documented.

Separating handling from transit creates a delivery model that can be measured, owned, and repaired component by component.

Represent handlingTime and transitTime as QuantitativeValue objects with non-negative whole-number minValue and maxValue values plus the unitCode DAY or d.

A range should describe typical defensible performance, not the fastest marketing example. The minimum cannot exceed the maximum, and negative values have no business meaning. When same-day handling is possible, zero is valid. If service varies widely, create separate shipping rules rather than one range so broad that it stops helping.

• 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. Measure historical handling and carrier durations.
2. Select a defensible minimum and maximum.
3. Normalize units to DAY or d.
4. Keep values as numbers.
5. Revalidate after service-level changes.

The range should be narrow enough to inform and broad enough to remain honest under ordinary variation.

A useful QuantitativeValue range is ordered, non-negative, whole-day, and grounded in normal fulfillment evidence.

Business days define which weekdays count toward handling and delivery, preventing weekends or closed operating days from being treated as ordinary processing days.

A Friday order with one-day handling does not necessarily leave Saturday. OpeningHoursSpecification can identify the operational weekdays, but the structured schedule must match warehouse and carrier behavior. Different services may operate on different calendars, and Sunday delivery in some postal zones does not mean the warehouse also processes Sunday.

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.

• Define warehouse operating days.
• Define carrier delivery days separately.
• Do not assume a national calendar.
• Review seasonal weekend operations.

Business-day markup should support the visible ETA engine rather than create a second calendar maintained only for SEO.

Delivery ranges stay credible when their counted days follow the real operating calendars of fulfillment and transit.

CutoffTime should represent the daily order-processing boundary with a precise timezone or offset so the same order instant is classified consistently across US markets.

A 2:00 PM cutoff is ambiguous without knowing whether it is Eastern, Central, Mountain, Pacific, warehouse local time, or customer local time. Daylight-saving transitions add another source of error. The checkout ETA, visible product message, order-management system, and structured data should all use the same rule.

• 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 the operational cutoff authority.
2. Store its timezone identifier.
3. Render an unambiguous time or offset.
4. Test before and after the daily boundary.
5. Retest daylight-saving changes.

A cutoff affects when handling starts, so a one-minute error can move delivery by an entire business day.

CutoffTime is reliable only when one timezone-aware rule drives both the customer ETA and structured delivery data.

Holiday closures and peak-season delays should be reflected in the operational ETA source and published ranges, because ordinary business-day patterns alone cannot represent exceptional calendars.

ShippingDeliveryTime does not replace a full holiday scheduling engine. The safest architecture calculates realistic ranges upstream and renders the result consistently. If Thanksgiving week, Christmas cutoffs, weather disruptions, or warehouse shutdowns change delivery, static year-round markup can become false during the highest-traffic period.

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.

• Maintain a shared holiday calendar.
• Monitor carrier service advisories through operational sources.
• Schedule seasonal range changes.
• Remove temporary overrides after the event.

Do not fabricate precise delivery certainty when operations can only support a wider current range.

Seasonal delivery markup must follow live operational calendars and retire temporary assumptions when normal service returns.

Common mistakes include combining handling and transit, reversing minimum and maximum values, omitting units, ignoring cutoffs and weekends, and copying one delivery window across different regions or services.

Another failure is publishing the carrier's transit promise as the total customer delivery time. Warehouse processing still occurs before handoff. Static ranges can also survive after fulfillment centers, carriers, or service levels change. Syntax validation cannot prove an ETA is operationally achievable.

• 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. Extract each deliveryTime entity.
2. Trace handling and transit to separate sources.
3. Fix range, calendar, and timezone logic.
4. Regenerate affected Offers.
5. Verify representative destinations.

A source-level timing fix prevents the same optimistic estimate from returning across the product catalog.

Delivery-time errors require reconciliation with real fulfillment and carrier evidence, not only valid JSON-LD syntax.