What Is ShippingConditions Schema?

ShippingConditions is a structured-data type that groups the destination, origin, cart characteristics, shipping rate, transit time, exclusion, and seasonal validity for one shipping rule.

It acts as the matching layer inside a ShippingService. The condition answers both “when does this rule apply?” and “what cost and delivery outcome follow?” A merchant can publish several conditions for different regions, order values, weights, quantities, or seasonal periods.

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.

• Make each condition internally coherent.
• Separate rules when cost or speed changes.
• Match the same logic used by checkout.

Use the free backlink checker while reviewing key commerce pages.

Primary specification: Schema.org definition for ShippingConditions.

ShippingConditions is valuable when one entity fully describes the inputs and outcome of a real shipping rule.

ShippingConditions belongs under shippingConditions inside a ShippingService, which can be connected to an Organization as the merchant's reusable shipping policy.

This organization-level model differs from product-specific OfferShippingDetails. A standard service can describe rules shared across most products, while an oversized or restricted product may override those defaults at Offer level. Choosing the wrong scope can duplicate policy data or hide exceptions.

• 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 rules shared across the catalog.
2. Create the merchant ShippingService.
3. Split its conditions by meaningful differences.
4. Use Offer-level details for exceptions.
5. Validate shared references and rendered pages.

Review Merchant Shipping Policy schema and OfferShippingDetails for scope decisions.

Place reusable conditions under ShippingService and reserve Offer-level markup for genuine product exceptions.

A complete ShippingConditions rule can combine shippingOrigin, shippingDestination, orderValue, weight, numItems, shippingRate, transitTime, doesNotShip, and seasonalOverride.

Not every rule needs every property. A nationwide flat rate may need destination, rate, and transit. A free-shipping tier may add an order-value range. A bulky-item exclusion may add weight and doesNotShip. Omitted properties broaden applicability, so every omission must be intentional.

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.

• Document the intended match set.
• Use only governed source fields.
• Do not add irrelevant constraints.
• Test what omitted properties allow.

The model should be minimal without accidentally becoming universal.

When more than one condition can match, the policy needs deterministic precedence that the structured representation and checkout evaluate the same way. A broad national rule and a specific Alaska rule must not leave the rate to chance. Likewise, a free-shipping order-value band should not compete with a paid default at the exact threshold. Build explicit tests for the intersection of geography, weight, item count, and order value. Record which rule should win, which cost and transit window it returns, and why. If precedence cannot be described clearly, split or repair the source rules before publishing them.

Choose properties by the exact inputs that select the rule and the outcomes checkout returns.

OrderValue uses MonetaryAmount with currency and a minimum, maximum, or both to define the cart-value band where a shipping condition applies.

This use of MonetaryAmount describes eligibility, not shipping cost. A condition for orders from $0 through $74.99 can charge $7.95, while a second condition starting at $75 can charge zero. The bands must use the same subtotal basis and currency as checkout.

• 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. Define the subtotal basis.
2. Choose currency and inclusive boundaries.
3. Build non-overlapping value bands.
4. Attach the appropriate rate and transit.
5. Test just below, at, and above thresholds.

Do not confuse a $75 threshold with orderPercentage; ShippingRateSettings describes a cost formula, not the eligible cart band.

Order-value conditions are correct when their currency, boundaries, and subtotal basis match checkout exactly.

Weight and numItems use QuantitativeValue ranges to select shipping rules based on shipment weight or product quantity.

Weight requires a consistent unit and a clear basis: product weight, packaged weight, or billable dimensional weight. Item count requires a definition for bundles and multi-quantity lines. Gaps or overlap at boundaries can cause two rates or no rate to match.

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 consistent unitCode values.
• Define inclusive and exclusive edges operationally.
• Validate bundle and quantity semantics.
• Test dimensional-weight products separately.

Condition ranges should partition intended carts without relying on hidden precedence.

Weight and item-count rules are reliable when units, count semantics, and adjacent boundaries are explicit and complete.

Each ShippingConditions entity should keep its origin, destination, rate, and transit time together so no region inherits the cost or speed of another route.

A $5 three-day rule for the contiguous United States cannot describe Alaska if its actual rate is $20 and transit is seven days. Multiple conditions should represent those routes. A DefinedRegion gives each destination exact geographic scope, while transitTime describes carrier travel after dispatch.

• 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 each origin-destination route.
2. Attach its exact rate.
3. Attach its transit range.
4. Separate materially different services.
5. Test representative and boundary addresses.

Use DefinedRegion and ShippingDeliveryTime to keep geography and timing precise.

A shipping condition must preserve the rate and speed of one real route instead of mixing best values across regions.

DoesNotShip marks a matched condition as unavailable, while seasonalOverride limits a temporary condition to a validFrom and/or validThrough date period.

Exclusions need destination and cart context so they do not block more orders than intended. Seasonal overrides can represent holiday deadlines, temporary surcharges, or peak transit windows. At least one validity boundary is needed, and temporary rules must be removed or allowed to expire cleanly.

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.

• Make negative regions specific.
• Use ISO 8601 dates.
• Define override precedence.
• Schedule post-season verification.

A seasonal condition should describe a real operational interval, not a permanent rule with decorative dates.

Exclusions and overrides are safe when their matching scope, priority, and validity period are explicit.

Common mistakes include overlapping bands, uncovered carts, missing destinations, mixed currencies, reversed ranges, unbounded exclusions, and seasonal rules that remain active after their end.

Another defect is combining the cheapest rate from one condition with the fastest transit from another. A validator can confirm property shape but cannot prove checkout selects the same condition. Rule evaluation must be tested with representative inputs.

• 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. Normalize every rule into inputs and outcomes.
2. Compute overlap and gap sets.
3. Fix the authoritative policy map.
4. Test checkout cases safely.
5. Recrawl the rendered policy.

A source-level correction prevents the same policy defect from reaching every linked product.

Shipping-condition errors require rule-set analysis, not isolated validation of individual objects.