What Is shippingDestination in Shipping Schema?

shippingDestination identifies one or more DefinedRegion values where a shipping offer, condition, or rate applies.

The destination can describe a country, state or province, exact postal code, textual postal prefix, or bounded postal range. It defines geographic membership; it does not independently state availability, cost, delivery time, carrier, or product eligibility.

A US-wide destination is broad. California is narrower, and one exact ZIP is narrower still. Choose the least detailed region that remains operationally true, then attach the rate, timing, service, or exclusion to the surrounding shipping entity.

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.

• Model where the parcel may arrive.
• Use DefinedRegion values.
• Keep geography separate from the outcome.

Use the free backlink checker to identify linked commerce pages before changing destination coverage.

Primary specification: Schema.org definition for shippingDestination.

shippingDestination is accurate when its region exactly matches where the surrounding shipping promise applies.

shippingDestination can be used on OfferShippingDetails, ShippingConditions, and ShippingRateSettings, with DefinedRegion as its expected value.

The correct parent follows scope. OfferShippingDetails suits an Offer-specific destination and legacy-style rate or time. ShippingConditions suits a reusable service rule constrained by destination, cart, product, or route. ShippingRateSettings can bind a calculated rate configuration to destination regions.

Do not place shippingDestination directly on Product, Offer, ShippingService, or Organization without the supported parent path. A valid region attached to the wrong entity loses the relationship that explains what the destination controls.

• 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 shipping outcome.
2. Choose the supported parent.
3. Add one or more DefinedRegions.
4. Attach rate, time, or exclusion.
5. Validate the graph.

Compare OfferShippingDetails and ShippingConditions.

Correct placement binds destination geography to the precise shipping promise it controls.

Define shippingDestination with a DefinedRegion using addressCountry and, when needed, addressRegion, postalCode, postalCodePrefix, or postalCodeRange.

Country supplies the postal-system context. State narrows administrative coverage. Exact code handles isolated exceptions, prefix handles a verified textual code family, and range handles a continuous inclusive interval. Do not mix unrelated codes into one string.

Choose geography from the same coverage model used by checkout. A shorter region is not better if it adds false addresses, and a highly detailed list is not better if a state rule expresses identical outcomes more safely.

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.

• Start with operational membership.
• Select the simplest exact representation.
• Preserve codes as Text.
• Test boundaries and exceptions.

Use the hub guide for DefinedRegion to design geographic values.

A destination region is well designed when its implied address set equals live shipping coverage.

Multiple shipping destinations should be represented as separate DefinedRegion values or separate shipping entities when their rates, times, services, or restrictions differ.

US and Canada can share one condition if the complete shipping outcome is identical. Alaska and Hawaii should be separated from a continental US cohort when rates or delivery times differ. Do not place a comma-separated country or state list inside one Text value.

Grouping reduces duplication only after outcome equality is proven. If two regions share geography but offer standard and expedited options, separate shipping entities can represent the distinct price-and-time combinations.

• 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 every destination separately.
2. Compare complete outcomes.
3. Group equivalent regions.
4. Separate rate or time choices.

Multiple destinations stay clear when every region and every shipping option remains independently testable.

US destination coverage should distinguish nationwide service from contiguous-state, Alaska, Hawaii, territory, military-address, remote-ZIP, and product-specific exceptions.

A country-wide US region is broader than the continental United States. If checkout excludes Alaska or applies a Hawaii surcharge, broad national markup needs narrower conditions or exclusions. Territory and APO/FPO behavior must come from actual carrier and fulfillment evidence.

Sample addresses across regions and product cohorts. One successful mainland ZIP cannot prove national coverage. Oversized, hazardous, perishable, or vendor-direct offers may need Offer-level destination rules even when ordinary products use a shared policy.

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 what US coverage means.
• List non-contiguous exceptions.
• Test territories and military addresses.
• Check restricted product cohorts.

US destination markup is truthful when broad national language and every narrower operational exception agree.

A specific doesNotShip destination should defeat a broader allowed destination for the same Offer, service, route, product, and cart when that matches checkout.

A US rule may allow standard delivery while a Hawaii heavy-item condition blocks shipping. Another Hawaii condition may allow lighter products at a special rate. The destination alone is not enough; every matched product and cart constraint participates in the decision.

Document geographic and conditional specificity. Do not rely on array order to resolve contradictions. Test the blocked address, a neighboring allowed address, and a similar product or cart that should remain eligible.

• 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. Enumerate matching conditions.
2. Apply documented specificity.
3. Resolve one outcome.
4. Test blocked and adjacent allowed cases.
5. Add regression coverage.

Review doesNotShip in shipping schema for negative-rule design.

Destination exclusions are safe when they remove one impossible match without suppressing valid neighboring routes.

shippingDestination affects rates and delivery times by selecting the surrounding condition or detail that contains the applicable price and timing promise.

The property itself contains no money or duration. A local destination can select same-day delivery, a standard zone can select a base rate, and a remote region can select a surcharge and longer transit range. One destination may also have several service options.

Keep geographic matching, rate, handling time, and transit time tied to one coherent route. Do not combine the cheapest rate from one destination condition with the fastest timing from another. Compare final results with checkout.

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.

• Resolve the destination region.
• Select one eligible service.
• Apply rate and timing together.
• Compare with checkout output.

Destination-aware promises remain accurate when geography, cost, and delivery time come from one matched shipping option.

Common mistakes include using Text instead of DefinedRegion, missing country context, overly broad national coverage, malformed state or postal values, comma-separated regions, conflicting overlaps, stale zones, and checkout mismatches.

Other defects include confusing destination with shippingOrigin, treating a business address as coverage, and attaching Offer-specific restrictions to the entire catalog. Syntactically valid JSON-LD cannot prove that a destination is serviceable.

A shared destination generator can affect thousands of pages. Repair the authoritative geography and policy source rather than patching each page, then verify that narrower exceptions survive regeneration.

• 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 destination and parent.
2. Validate DefinedRegion shape.
3. Find overlaps and conflicts.
4. Compare checkout cohorts.
5. Repair the source.

shippingDestination defects require entity, geography, precedence, and operational validation together.