What Is addressCountry in DefinedRegion?

addressCountry identifies the country that contains a DefinedRegion used for shipping coverage or shipment origin.

The property accepts Country or Text. A consistent two-letter country code such as US provides a compact country-level region and supplies context for state, postal code, prefix, or range values nested in the same DefinedRegion.

addressCountry defines geographic membership; it does not state a rate, delivery time, carrier, tax, or customs treatment. Those outcomes belong to the surrounding shipping entity. Country scope is truthful only when the represented outcome applies across the entire country or narrower exceptions are modeled explicitly.

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 one controlled country vocabulary.
• Keep state and postal values country-qualified.
• Verify the full national match set.

Use the free backlink checker to find linked commerce pages before changing their country coverage.

Primary specification: Schema.org definition for addressCountry.

addressCountry is accurate when the declared country scope matches the complete operational shipping rule.

addressCountry belongs on DefinedRegion for shipping coverage and on PostalAddress for a physical address, while those two intents require different parent entities.

A shippingDestination or shippingOrigin reaches it through DefinedRegion. A merchant, customer, or facility address can reach it through PostalAddress. Country coverage does not require a street address, and a headquarters country does not prove nationwide shipping.

Do not attach addressCountry directly to Product, Offer, ShippingService, or ShippingConditions without the appropriate region or address path. The parent tells consumers whether the country is eligibility, dispatch geography, or an entity 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 the geographic intent.
2. Choose DefinedRegion for coverage.
3. Add the country value.
4. Connect the shipping property.
5. Validate the complete graph.

Review DefinedRegion in shipping schema for the parent model.

Correct placement prevents a business location from being mistaken for country-wide shipping coverage.

Use one consistent two-letter ISO 3166-1 alpha-2 country-code vocabulary, such as US, across shipping data whenever that representation fits the source system.

The property can also accept a Country object, three-letter codes for backward compatibility, or full country names, but mixing US, USA, United States, and United States of America creates duplicate regions and unreliable joins. Normalize in the authority rather than only in templates.

Preserve source evidence during audits, map known synonyms to one canonical key, and reject values that are not recognized countries. Case normalization should be deterministic. A code must never be guessed from currency, language, domain suffix, or customer IP.

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.

• Choose one canonical code set.
• Map known legacy values.
• Require explicit country evidence.
• Reject currency and locale guesses.
• Test rendered output.

Country codes are dependable when one explicit vocabulary is shared from source policy through checkout and markup.

Use country-level coverage when every address in the country receives the same represented shipping availability, rate, time, and product treatment.

A national rule is compact for uniform services, but the United States often has meaningful differences for Alaska, Hawaii, territories, remote ZIPs, military addresses, oversized products, or vendor fulfillment. A broad US region without exceptions can create false promises.

Acceptance of a country in the checkout selector does not prove universal service. Sample mainland states, Alaska, Hawaii, territories, rural ZIPs, and known product restrictions before declaring national coverage. Use narrower DefinedRegions where outcomes differ.

• 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. Verify national membership.
2. Find state and postal exceptions.
3. Compare product eligibility.
4. Choose the least detailed truthful region.

Country-level coverage is appropriate only when every important subregion is covered or explicitly excepted.

Multi-country coverage should use multiple DefinedRegion values or separate conditions so every country remains machine-distinguishable and tied to the correct outcome.

Do not combine US, CA, and MX into one comma-separated addressCountry string. Countries can share a service condition only when their complete rates, times, customs handling, exclusions, currencies, and product eligibility are equivalent.

Cross-border routes frequently differ, so grouping should follow verified outcome equality rather than marketing labels such as North America. When one country changes policy, split it from the cohort without creating duplicate conflicting conditions.

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 countries independently.
• Compare complete route outcomes.
• Group only equivalent countries.
• Split cohorts when one rule changes.

Multi-country rules remain clear when each country is explicit and every grouped member shares the same shipping promise.

A narrower addressRegion, postalCode, postalCodePrefix, or postalCodeRange rule should resolve predictably against a broader addressCountry rule using documented specificity.

A US default may provide standard ground service while Alaska uses a special rate, Hawaii has product restrictions, and one remote ZIP is excluded. Without precedence, the same destination can match contradictory availability, price, or delivery time.

Treat country scope as the default only when checkout does the same. Test every exception and neighboring locations that should retain the country outcome. Array position is not a durable precedence rule; the matching system needs explicit geography and condition logic.

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

See addressRegion and exact postalCode for narrower rules.

Country and subregion rules work together when every address produces one deterministic outcome.

addressCountry affects cross-border shipping by selecting a destination or origin country whose surrounding rule supplies service availability, rate, timing, and restrictions.

The value itself does not describe duties, taxes, customs documents, de minimis thresholds, or who pays import charges. Do not infer those promises from a country code. Visible policy and checkout must explain any customer-facing cross-border costs separately.

A route from US origin to CA destination differs from CA origin to US destination. Product category, warehouse, carrier, cart value, and season can change eligibility. Model route-specific conditions and test representative addresses without completing transactions.

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.

• Identify origin and destination countries.
• Resolve product and cart rules.
• Apply rate and timing evidence.
• Compare checkout output.

Review shippingOrigin for the dispatch side of the route.

Cross-border country markup is truthful when it describes a verified route without inventing customs or duty promises.

Common mistakes include mixing country formats, inferring countries from locale or currency, omitting country context around state and postal values, assuming nationwide coverage, confusing headquarters with shipping scope, and leaving stale cross-border rules.

Another defect is using one country region for all products when regulated, oversized, vendor-direct, or perishable offers have narrower eligibility. Syntax validation cannot prove that a country is active in checkout or that every address receives the promised outcome.

Broad country errors can affect an entire catalog. Repair the shared policy authority and regenerate markup rather than patching product pages individually. Preserve narrower state and postal exceptions during the repair.

• 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 each country and parent.
2. Normalize for analysis.
3. Find duplicate and conflicting rules.
4. Sample subregions.
5. Repair the source.

addressCountry defects require vocabulary, geographic, route, product, and checkout validation together.