What Is doesNotShip in Shipping Schema?

DoesNotShip is a Boolean shipping property set to true when a specified shipping route or matched order condition is unavailable.

It creates a negative rule rather than a rate or delivery promise. Inside ShippingConditions, it can combine origin, destination, weight, item count, and order value. Inside OfferShippingDetails, it can identify a destination where the specific Offer cannot be shipped.

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.

• Set the value as Boolean true.
• Define the excluded match set precisely.
• Keep visible checkout restrictions aligned.

Use the free backlink checker while reviewing important commerce URLs.

Primary specification: Schema.org definition for doesNotShip.

DoesNotShip is accurate when one precise negative condition matches the orders checkout truly cannot fulfill.

DoesNotShip belongs on ShippingConditions for reusable service rules or on OfferShippingDetails for a destination exclusion specific to one Offer.

The correct placement follows scope. A merchant-wide hazardous-goods route restriction belongs in the policy condition that defines the product class or operational rule. An oversized product that alone cannot ship to Hawaii needs an Offer-level exception. Do not place the Boolean on Product without the shipping context it negates.

• 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 whether the restriction is global or product-specific.
2. Choose policy or Offer scope.
3. Add the relevant origin and destination.
4. Add cart constraints when needed.
5. Test the complete matching rule.

Review ShippingConditions and OfferShippingDetails for the two parent models.

Correct placement keeps a negative rule as narrow as the business restriction it represents.

ShippingOrigin and shippingDestination define the blocked route, so the same destination can be excluded from one warehouse while remaining available from another.

A destination-only rule may be sufficient when all origins share the restriction. Multi-warehouse merchants should model route-level capability because carrier contracts, inventory, customs, or product handling can differ by origin. DefinedRegion supplies exact country, state, or postal membership.

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 DefinedRegion for both ends.
• Do not confuse warehouse location with customer market.
• Test multi-origin inventory routing.
• Preserve postal exclusions as text.

The negative rule should follow the origin that actually fulfills the item, not a generic corporate address.

Route exclusions remain truthful when origin selection and destination membership match the live fulfillment path.

Weight, numItems, and orderValue narrow doesNotShip so only orders matching the restricted combination are blocked.

An ordinary product may ship to Hawaii while a 100-pound order cannot. Mexico orders under $50 may be excluded while larger orders qualify for a special service. Every constraint participates in the match, so omission broadens the negative 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. Define each range and unit.
2. Document inclusive boundaries.
3. Combine only constraints used by checkout.
4. Generate boundary-value carts.
5. Confirm eligible carts remain allowed.

Review MonetaryAmount for order-value range semantics.

Cart-based exclusions are safe when their ranges block exactly the restricted orders and no others.

Model Alaska, Hawaii, and territories as explicit destination regions when they are excluded, and ensure the negative rules override any broader US shipping condition.

A country-wide US rule is broader than “contiguous United States.” Without explicit precedence, one address can match both an allowed national rule and a state exclusion. Territories and APO/FPO addresses need their own operational evidence rather than being silently grouped with states.

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.

• Translate “contiguous US” into exact region membership.
• Use explicit state codes.
• Document territory handling.
• Test broad-positive and specific-negative overlap.

If a separate paid service exists, represent that service instead of marking the destination universally unavailable.

US exclusions work when specific regional truth overrides marketing shorthand and broad country coverage.

A specific matching doesNotShip rule should defeat a broader allowed rule for the same service, route, product, and cart, with deterministic precedence shared by markup and checkout.

Negative rules are dangerous when precedence is implicit. A broad US condition may provide a rate, while a narrower Hawaii condition blocks heavy items. The policy engine must decide based on specificity and all matched constraints. Publishing both without a consistent decision can create contradictory customer promises.

• 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. List all rules matching the same test cart.
2. Rank policy and Offer specificity.
3. Apply the negative rule where intended.
4. Verify the same checkout decision.
5. Add regression tests for intersections.

Precedence should be a documented data rule, not an accident of array order.

Positive and negative conditions are coherent when every test cart resolves to one deterministic fulfillment outcome.

Product-specific restrictions should use a narrowly scoped Offer-level shipping exclusion when the general merchant service remains valid for other products.

Oversized furniture, lithium batteries, perishables, regulated goods, and vendor-shipped items can have different destinations from the catalog default. The exception should follow the exact Offer and variant. A parent product restriction should not automatically block smaller or compliant children.

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 dimensions and weight accurate.
• Map category restrictions to real carrier rules.
• Validate each variant independently.
• Do not expose unsupported compliance claims.

A product exception should override only the shared policy facts that are false for that Offer.

Offer-level exclusions protect the general shipping policy by isolating real product and variant exceptions.

Common mistakes include omitting destination scope, using the string “true” inconsistently, blocking all products for one exception, ignoring origin, creating contradictory allowed rules, and leaving stale exclusions after service expands.

Another defect is publishing doesNotShip false as though it proves universal availability. A negative Boolean alone cannot establish a rate, transit time, or eligible route. Syntax validation also cannot confirm that checkout rejects or accepts a real address.

• 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 every negative rule and parent.
2. Compute its exact match set.
3. Find competing positive rules.
4. Repair source and precedence.
5. Verify real address outcomes.

One source policy should drive visible restrictions, markup, and checkout.

DoesNotShip errors require match-set and precedence analysis, not only Boolean validation.