What Is businessDays in Shipping Schema?

businessDays identifies the days of the week when a merchant typically operates for a shipping timing period.

The property can use DayOfWeek or OpeningHoursSpecification and appears on ServicePeriod and ShippingDeliveryTime. It helps determine which days count while handling or transit duration advances.

businessDays does not by itself prove holiday openings, temporary closures, warehouse capacity, or carrier service. Those operational exceptions still need an authoritative source and must be reflected in the final checkout 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.

• Identify the operating authority.
• Choose a supported value type.
• Connect the calendar to its timing period.
• Test final dates.

Use the free backlink checker to identify linked pages before changing a shared shipping calendar.

Primary specification: Schema.org definition for businessDays.

businessDays is accurate when only the merchant's real operating days advance the relevant preparation or delivery period.

businessDays can be used on ServicePeriod and ShippingDeliveryTime, with DayOfWeek or OpeningHoursSpecification values.

A ServicePeriod can combine businessDays with duration and cutoffTime for handling or transit timing. ShippingDeliveryTime can also carry the property in a total-delivery structure.

Do not attach businessDays directly to Product, Offer, ShippingService, ShippingConditions, ShippingRateSettings, or Organization. Those entities may contain or connect to the timing structure, but they are not listed parents for this property.

• 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 the timing parent.
2. Use supported calendar values.
3. Keep service and condition relationships intact.
4. Validate the rendered graph.

Review ServicePeriod and ShippingService.

Correct placement attaches the calendar to the exact period whose duration it controls.

Use DayOfWeek for a straightforward operating-day list and OpeningHoursSpecification when the source needs structured opening hours for those days.

A warehouse that processes orders Monday through Friday with one daily schedule may use weekday values. A pickup store whose preparation window depends on opening and closing hours may need OpeningHoursSpecification to preserve more context.

Choose the smallest model that reproduces the real policy. Extra hours are harmful when guessed, while a weekday-only list is incomplete when time-of-day availability changes whether an order can be prepared.

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.

• Inspect the operational source.
• Decide whether hours affect behavior.
• Choose the minimal complete type.
• Test representative orders.

The right businessDays value type is the simplest one that preserves every operational distinction affecting the timing promise.

For handlingTime, businessDays determines which merchant operating days count from order receipt until dispatch or pickup readiness.

An order received Friday after cutoff may not begin handling until Monday for a Monday-through-Friday warehouse. A store open Saturday may prepare pickup sooner. The result depends on the service, origin, cutoff, and local calendar together.

Apply cutoff classification before advancing the handling duration, then count only valid operating days. Do not count carrier transit at the handling stage or apply the same calendar twice.

• 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. Resolve order timestamp and cutoff.
2. Select the origin calendar.
3. Advance handling duration.
4. Produce dispatch or pickup-ready time.

See handlingTime in ShippingService.

businessDays supports handling correctly when its counted days produce the same readiness timestamp as fulfillment operations.

For transitTime, businessDays determines which service operating days count after dispatch until the goods reach the customer.

Carrier calendars can differ from warehouse calendars. A warehouse may operate Saturday while the selected carrier service does not, or a scheduled delivery service may have destination-specific delivery days.

Keep handling and transit ServicePeriod calendars separate whenever their authorities differ. Start transit only after dispatch and apply the calendar of the chosen route and service.

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.

• Calculate dispatch first.
• Select carrier and service calendar.
• Apply route and destination rules.
• Calculate arrival window.

Compare transitTime in ShippingConditions.

Transit business days are accurate when they follow the selected carrier service rather than inheriting a merchant warehouse calendar.

Holidays and temporary closures should come from the authoritative operational calendar and adjust calculated dates even when the regular businessDays pattern remains unchanged.

A Monday-through-Friday schedule describes typical weekdays, not every exception. Federal holidays, local holidays, inventory counts, severe-weather closures, peak-season extensions, and carrier embargoes can change processing or transit.

Do not claim that a regular weekday list encodes all holidays. Maintain exception dates in the fulfillment system, regenerate customer promises, and test closures separately from the structured regular schedule supported by the target consumer.

• 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. Maintain regular schedules.
2. Maintain dated exceptions.
3. Apply both in calculations.
4. Update promises and caches.
5. Retest affected cohorts.

Holiday handling is honest when regular markup and operational exceptions combine into the same date shown at checkout.

Each warehouse, pickup store, marketplace seller, and carrier service may require a separate businessDays calendar because operating days and hours differ.

A universal merchant calendar can make a West Coast warehouse, franchised store, or seller appear to process orders when it is closed. Multi-origin carts may produce separate readiness and arrival windows.

Resolve seller, inventory location, origin, service, and pickup location before selecting the calendar. Preserve stable entity identities so a crawler can connect the right ServicePeriod to the right fulfillment source.

• 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. Resolve seller and stock.
2. Resolve origin or pickup location.
3. Select its calendar.
4. Calculate each shipment.
5. Combine per checkout policy.

Multi-source calendars are correct when each package or pickup uses the schedule of the entity that actually fulfills it.

Common businessDays mistakes include using the wrong parent or value type, assuming Monday through Friday for every service, sharing one calendar across origins, mixing warehouse and carrier days, ignoring cutoff order, and treating regular weekdays as complete holiday coverage.

Other defects include duplicate or empty weekday lists, invalid opening-hour relationships, stale pickup schedules, mismatched time zones, double-counted days, and valid markup that produces a different delivery date than checkout.

Repair operational calendars and structured-data generation together. Shared calendar errors can affect large Offer cohorts, so stage changes and retain date-based regression scenarios.

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 calendar value.
• Validate parent and type.
• Map authority, origin, and service.
• Calculate boundary dates.
• Repair shared sources.

businessDays defects require structure, authority, calendar, cutoff, exception, and checkout evidence together.