What Is ShippingOrigin in Shipping Schema?

ShippingOrigin identifies the geographic region from which a shipment is expected to begin.

Its value is a DefinedRegion, not a warehouse name, street address, carrier, or destination. The property can appear on OfferShippingDetails and ShippingConditions. It matters when fulfillment location changes which rate, transit time, restriction, or service applies.

A merchant shipping every order from one US facility may need only one stable origin. A marketplace, drop-ship catalog, or multi-warehouse store needs origin-specific logic because the same customer address can produce different outcomes depending on the facility that owns inventory.

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 the real dispatch region.
• Keep origin separate from destination.
• Use origin only where it changes the promise.

Start URL discovery with the free backlink checker when auditing linked product and policy pages.

Primary specification: Schema.org definition for shippingOrigin.

ShippingOrigin is useful when the physical starting region materially controls the shipping result.

ShippingOrigin can be used on OfferShippingDetails for an Offer-specific route or on ShippingConditions for a reusable service condition.

Placement determines scope. OfferShippingDetails is suitable when one product, variant, seller, or vendor ships from a different region than the catalog default. ShippingConditions is suitable when a ShippingService has a reusable origin-based rule covering many eligible offers.

Do not attach shippingOrigin to Product as an isolated fact. A product can be stocked at several facilities, and its country of manufacture is not necessarily its shipment origin. The property needs the shipping entity that explains what the region changes.

• 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 source of the shipping promise.
2. Determine whether the rule is shared or Offer-specific.
3. Attach the origin to the narrowest truthful parent.
4. Connect rate, time, and destination conditions.
5. Test the complete entity graph.

Compare the parent models in OfferShippingDetails and ShippingConditions.

Correct placement makes the origin govern only the offers and services it actually fulfills.

Define shippingOrigin with a DefinedRegion using the country and, when needed, state, province, postal code, prefix, or postal range that identifies the dispatch area.

Country-level scope is enough when every facility inside that country produces the same shipping outcome. Add a state or postal boundary when carrier zones, taxes, service availability, or handling operations differ within the country. Preserve postal codes as text so leading zeros remain intact.

A DefinedRegion expresses geographic membership, not a warehouse label. Internal codes such as WH-04 can remain in operations systems, but the public shipping graph should expose the region needed to explain the route without leaking private facility details.

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 two-letter country codes consistently.
• Keep state codes tied to their country.
• Retain leading zeros in postal data.
• Avoid publishing a street address unless another property truly requires it.

See DefinedRegion in shipping schema for region construction.

The best origin region is the least detailed geography that still explains the real shipping rule.

ShippingOrigin describes where the parcel starts, while shippingDestination describes where the customer receives it; together they define a route.

Swapping the two reverses the route and can attach a rate or delivery time to the wrong market. A California origin and New York destination is not equivalent to a New York origin and California destination. Inventory, carrier zones, cutoff times, weather exposure, and product restrictions can differ.

Audits should evaluate the pair rather than checking either property alone. A valid region in both fields can still create a false promise when the operational route does not exist or the selected warehouse cannot fulfill the product.

• 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 a real fulfillment origin.
2. Choose a test destination.
3. Resolve the matching service condition.
4. Compare the rate and time with checkout.
5. Repeat the test in the reverse direction only if that route exists.

A route must be interpreted in one direction from dispatch to delivery.

Origin and destination are complementary, directional facts whose pairing controls the shipping outcome.

Model multi-warehouse origins as separate rules when each facility region can produce a different rate, delivery time, restriction, or product eligibility decision.

Do not publish every warehouse merely because it exists. Include an origin only when it can fulfill the Offer or service represented by that entity. Inventory routing may change hourly, so static markup should not claim a precise facility if the page cannot keep pace with allocation.

For stable regional networks, group facilities that produce identical outcomes into one origin region. Separate East Coast and West Coast conditions when their transit bands differ. Vendor-direct products should follow the vendor fulfillment region rather than the merchant headquarters.

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.

• Group origins only when outcomes are equivalent.
• Exclude facilities that cannot fulfill the item.
• Keep vendor and merchant inventory distinct.
• Refresh rules when the network changes.

Multi-origin coverage should describe dependable choices, not every theoretical inventory location.

A multi-warehouse model is accurate when each published origin maps to a currently fulfillable route and promise.

Shipping origin affects rates and delivery time by changing route distance, carrier zone, service availability, handling operation, and the cutoff that begins fulfillment.

The origin itself does not state a price or duration. It selects the ShippingConditions or OfferShippingDetails context in which shippingRate and transit or delivery periods are evaluated. Two origins may reach the same ZIP with different costs and dates.

Handling time may also differ by facility. One warehouse can dispatch the same day while another needs two business days. Keep rate, transit, and handling facts aligned with the origin condition rather than combining the fastest timing from one facility with the cheapest rate from another.

• 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. Select a product and origin.
2. Resolve its eligible service.
3. Calculate handling before transit.
4. Apply destination and calendar rules.
5. Compare the final promise with checkout.

Keep each rate and time bound to the same route evidence.

Origin-aware promises remain truthful when price, handling, and transit all come from one coherent fulfillment route.

Origin-specific exclusions should block only the origin, destination, product, and cart combination that cannot ship while preserving valid routes from alternative facilities.

A hazardous product may be barred from air service at one origin but available by ground from another. A destination could be unsupported from a vendor facility yet reachable from merchant stock. A broad negative rule can erase valid availability if it ignores origin.

Use doesNotShip within a narrowly defined condition when the matched route is unavailable. Then test both the blocked case and the neighboring allowed case. If every origin is blocked, the customer-facing product availability and checkout experience should tell the same story.

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.

• Match the exact origin before blocking.
• Preserve alternative fulfillment routes.
• Test product and cart boundaries.
• Remove stale exclusions after network expansion.

Read doesNotShip in shipping schema for negative-rule precedence.

Origin-specific exclusions are safe when they remove one impossible route without suppressing another valid fulfillment path.

Common shippingOrigin mistakes include using a street address or warehouse label instead of DefinedRegion, confusing manufacture with dispatch, reversing origin and destination, and publishing facilities that cannot fulfill the Offer.

Other defects include country-only origins that hide materially different state rules, duplicated conditions with conflicting outcomes, leading-zero loss in postal codes, and stale warehouse coverage after a closure. Valid JSON-LD does not prove that the origin is operationally true.

A corporate office is not a shipping origin unless parcels actually begin there. Likewise, countryOfOrigin describes where a product originates in a manufacturing or national sense; it does not substitute for the location used to dispatch a customer order.

• 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 shippingOrigin value and parent.
2. Validate DefinedRegion shape.
3. Map each origin to eligible inventory.
4. Find conflicting route outcomes.
5. Verify live checkout cases.

Repair the authoritative fulfillment source before regenerating markup.

ShippingOrigin quality depends on operational route truth, not merely correct property names and syntax.