What Is DefinedRegion in Shipping Schema?

DefinedRegion is a structured-data type that identifies the country, state, territory, or postal area where a shipping rate, delivery time, service, or exclusion applies.

It gives geography a precise home inside shipping rules. A rate without a destination can be misread as universal, while a whole-country destination can overstate coverage when Alaska, Hawaii, territories, or remote postal codes differ. DefinedRegion should mirror the same zones the commerce and logistics systems use.

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.

• Always establish country context.
• Choose a state-based or postal-based zone.
• Keep rate and time attached to the same region.

Use the free backlink checker while reviewing important commerce URLs.

Primary specification: Schema.org definition for DefinedRegion.

DefinedRegion is useful when it translates a real logistics zone into an unambiguous structured destination.

DefinedRegion normally appears as shippingDestination or shippingOrigin inside OfferShippingDetails, connecting a geographic area to one Offer's rate and delivery rules.

The type can also support reusable shipping services and settings, but scope must remain clear. A destination answers where a customer can receive the offer. An origin answers where fulfillment begins. Reversing them can distort transit logic, and placing a region directly on Product separates it from the commercial rule it qualifies.

• 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 the Offer.
2. Identify its shipping rule.
3. Create the appropriate destination region.
4. Attach rate and time at the same scope.
5. Validate the rendered entity graph.

See OfferShippingDetails schema for the enclosing delivery option.

Correct placement keeps geography tied to the shipping rule and Offer where it changes price or delivery.

Use addressCountry with a two-letter ISO 3166-1 alpha-2 country code such as US, CA, AU, or GB, not a country name, currency, or language tag.

The country establishes the namespace for state and postal rules. “CA” is ambiguous without context because it can mean Canada as a country or California as a region. Inside a US DefinedRegion, addressCountry is US and addressRegion is CA. Currency remains a separate commercial field.

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.

• Maintain a controlled ISO country list.
• Separate country, currency, and locale fields.
• Validate region codes within their country.
• Reject names copied from display labels.

A whole-country rule can stop at addressCountry only when rate and timing truly apply to the entire country.

Country context is the foundation that makes every state and postal-code definition interpretable.

Use addressRegion for state or subdivision zones and postalCode for postal-based zones, but do not mix both methods inside the same DefinedRegion instance.

Choose the geographic method used by the shipping engine. State rules are easier to maintain when every address in a state shares a service. Postal rules are more precise for remote areas, local delivery, or carrier zones that cross administrative boundaries. If both are needed, create separate coherent region entities or normalize the logistics model first.

• 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. Read the source shipping-zone definition.
2. Choose state or postal granularity.
3. Normalize values to supported formats.
4. Detect overlap with neighboring rules.
5. Test addresses at zone boundaries.

A mixed region can be syntactically elaborate yet operationally impossible to match consistently.

Choose one geographic method per DefinedRegion and make it match the source system's actual zone logic.

Model the contiguous United States separately from Alaska and Hawaii whenever rates, services, or delivery times differ, rather than treating addressCountry US as one universal rule.

A whole-US rule includes states and destinations that many commerce teams informally exclude when they say “continental shipping.” Create explicit state-based zones or exclusions based on the capabilities of the implementation. Territories, military addresses, and remote areas may need additional treatment.

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.

• Do not use “US” when only contiguous states qualify.
• Keep rate and timing separate for Alaska and Hawaii.
• Document territory treatment.
• Test military-address behavior independently.

Marketing phrases must be translated into exact logistics regions before they become structured claims.

US shipping markup is trustworthy only when every included state and territory receives the published option.

Postal code ranges use PostalCodeRangeSpecification with postalCodeBegin and postalCodeEnd to represent a bounded sequence of codes within one country.

Ranges are compact but dangerous when postal formats are not purely numeric, leading zeros disappear, or carrier zones contain gaps. A numeric interval can accidentally include ZIP codes the business does not serve. Preserve postal values as text and compare the range with the source zone definition.

• 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. Export the authoritative postal-zone list.
2. Preserve codes as strings.
3. Compress only truly contiguous spans.
4. Check begin and end ordering.
5. Test boundary and excluded postal codes.

Compression should never change the membership of the shipping zone.

Postal ranges are safe only when their text values, boundaries, and membership exactly preserve the underlying delivery area.

Use a DefinedRegion with doesNotShip when a clearly identified destination is excluded, while ensuring broader positive rules do not create an unresolved contradiction for the same address.

An exclusion should be deliberate and visible. A product may not ship to California because of regulation, or an oversized item may exclude Alaska. The negative rule must apply to the same Offer and be more specific than any broad country rule. Checkout should reject the same addresses before payment.

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.

• Pair every exclusion with a DefinedRegion.
• Define precedence between broad and specific rules.
• Keep customer-facing restrictions visible.
• Test excluded addresses safely at checkout.

Do not publish doesNotShip without explaining which region it negates.

Exclusion markup works only when a specific negative region consistently overrides broader positive shipping coverage.

Common mistakes include omitting addressCountry, mixing state and postal methods, using full names instead of codes, overlapping zones with different rates, and treating all US destinations as identical.

Another error is confusing origin with destination. A warehouse in Texas does not mean shipping applies only to Texas. Static region lists also become stale after carrier or warehouse changes. Syntax validation cannot determine which rule checkout selects for 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 DefinedRegion.
2. Normalize country and region codes.
3. Compute zone intersections.
4. Repair the source shipping map.
5. Test representative addresses.

Fixing the logistics-zone source prevents the same geographic defect from appearing across thousands of Offers.

Region errors require geographic reconciliation with the commerce system, not only valid property names.