What Is addressRegion in DefinedRegion?

addressRegion identifies the state, province, or comparable first-level administrative division inside a DefinedRegion.

Its value may be Text or AdministrativeArea. In US shipping markup, a two-letter state code such as CA or NY gives a concise state-level region when paired with addressCountry US. The DefinedRegion can then act as a shipping destination or origin.

The property defines geographic membership; it does not state a rate, delivery time, or service. Those outcomes belong to the surrounding shipping detail or condition. Use state scope only when the outcome truly applies across the entire state.

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 the region with its country.
• Use consistent region codes.
• Verify statewide operational coverage.

Use the free backlink checker to locate linked product and policy pages before editing shipping coverage.

Primary specification: Schema.org definition for addressRegion.

addressRegion is accurate when one first-level division shares the represented shipping outcome.

addressRegion belongs on DefinedRegion for shipping coverage or on PostalAddress for an actual address, and the two intents should not be confused.

A shipping Destination or origin reaches the property through DefinedRegion. A customer, seller, or facility address can use it through PostalAddress. Publishing a state-level coverage rule does not require a street address, locality, or private warehouse details.

Do not attach addressRegion directly to Product, Offer, ShippingService, or ShippingConditions without the appropriate region or address parent. Correct nesting allows consumers to distinguish geographic eligibility from a physical mailing location.

• 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 coverage or address intent.
2. Choose DefinedRegion for shipping scope.
3. Add country and region.
4. Connect the shipping entity.
5. Validate the graph.

Review DefinedRegion in shipping schema for the geographic parent.

Correct placement keeps state-level coverage separate from a business or customer address.

US shipping regions can use Text, but one consistent two-letter state-code vocabulary is usually easier to validate, join, deduplicate, and compare with checkout.

Mixing CA, California, and Calif. creates separate strings for the same state. A controlled code set reduces ambiguity and supports direct comparisons with carrier and tax data. Whatever representation is chosen must remain paired with addressCountry US.

Do not assume a two-letter value is globally unique. CA can be misread without country context. Normalize in the source system, preserve the original evidence during audits, and prevent templates from emitting multiple synonyms for one region.

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.

• Select one canonical vocabulary.
• Map known synonyms.
• Require country context.
• Reject unknown codes.
• Test rendered values.

A US state representation is reliable when it is consistent, country-qualified, and shared with the shipping engine.

Use state-level coverage when every address in that state receives the same shipping availability, rate, timing, and product treatment under the represented rule.

State scope is compact and maintainable for broad domestic services. It becomes false when remote ZIPs, islands, metro-only delivery, carrier zones, or product restrictions create exceptions inside the state. In those cases, add narrower postal rules or split the shipping conditions.

Do not publish a state simply because the checkout form accepts the state name. Acceptance is not proof that every ZIP is serviceable. Test representative urban, rural, border, remote, and known-exception postal codes.

• 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. Confirm statewide membership.
2. Find ZIP-level exceptions.
3. Compare rates and times.
4. Choose the least detailed truthful region.

State-level coverage is appropriate only when no important in-state address contradicts the promise.

Multi-state coverage should use multiple DefinedRegion values or clearly grouped conditions when several states share the same shipping outcome.

Do not combine state codes into one comma-separated addressRegion string. Each region value should remain machine-distinguishable. States can share one service condition when their rates, times, restrictions, and product eligibility are equivalent.

If one state later receives a surcharge or slower transit time, separate it from the cohort rather than adding contradictory duplicate rules. Grouping is a maintenance decision after geographic truth, not a reason to hide operational differences.

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.

• List each state independently.
• Compare complete shipping outcomes.
• Group only equivalent states.
• Split cohorts when policy changes.

Multi-state rules are coherent when each state is explicit and every grouped member shares the same outcome.

A specific postalCode, postalCodePrefix, or postalCodeRange rule should resolve predictably against a broader addressRegion rule using documented precedence.

A state may receive standard ground shipping while one remote ZIP has a surcharge, one postal interval has slower transit, and another code cannot ship. Without specificity rules, the same destination can match several contradictory conditions.

Treat the state as the default and narrower postal membership as an exception only when that matches checkout. Test the exception and neighboring ZIPs that should retain the state outcome. Array order alone is not a durable precedence system.

• 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 all matching regions.
2. Rank documented specificity.
3. Resolve one outcome.
4. Test exception boundaries.
5. Add regression cases.

Compare exact postalCode, postalCodePrefix, and postalCodeRange.

State and postal rules work together when every address resolves to one deterministic shipping promise.

addressRegion affects shipping by selecting the state-level DefinedRegion whose surrounding condition provides the applicable rate, delivery time, service, or exclusion.

The state value itself carries no price or duration. Alaska may use a different service than California, while neighboring states can share one ground-delivery band. Keep every outcome tied to the same active rate and fulfillment authority used by checkout.

When state policy changes, test several ZIPs across the state rather than one capital-city address. Also test any narrower exception rules. This prevents a broad update from erasing remote surcharges, local delivery areas, or product restrictions.

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 state membership.
• Apply the surrounding condition.
• Test in-state samples.
• Compare final checkout output.

Use shippingOrigin when the state describes dispatch rather than delivery.

State-level shipping promises remain truthful when rates and timing are verified across the whole represented region.

Common mistakes include missing country context, mixed state names and codes, invalid abbreviations, assuming statewide coverage, confusing a PostalAddress with a DefinedRegion, conflicting postal exceptions, and stale service areas.

Another defect is treating territories as ordinary states without checking the actual fulfillment rule. APO and FPO addresses also require carrier-specific evidence. Syntactically valid Text cannot prove that a state code is correct or that every address in that state is eligible.

Broad state errors can affect thousands of product pages. Repair the shared geographic source rather than patching rendered entities one by one, then verify that narrower postal 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 state values and parents.
2. Normalize for analysis.
3. Find duplicate and conflicting rules.
4. Sample statewide ZIPs.
5. Repair the source.

addressRegion defects require vocabulary, geography, precedence, and checkout validation together.