What Is PostalCodeRangeSpecification Schema?

PostalCodeRangeSpecification is a structured value that defines an inclusive range from postalCodeBegin through postalCodeEnd.

Both boundary properties expect Text. The type is most useful inside a DefinedRegion through postalCodeRange, where it can describe a shipping origin or destination more precisely than a country or state alone. A range does not state a rate, time, or service; it defines geographic membership used by another shipping rule.

For US shipping, a five-digit ZIP range can group a continuous operational area. It should come from the same geographic logic used by checkout. Arbitrary numeric compression can include ZIP codes the merchant does not serve.

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.

• Store endpoints as text.
• Treat both endpoints as included.
• Use ranges only for continuous coverage.

Use the free backlink checker to find linked commerce pages before changing their shipping regions.

Primary specification: Schema.org definition for PostalCodeRangeSpecification.

PostalCodeRangeSpecification is accurate when one inclusive interval matches the region checkout actually recognizes.

PostalCodeRangeSpecification belongs as the value of postalCodeRange on a DefinedRegion, which can then serve as a shipping origin or destination.

It should not be attached directly to Product, Offer, ShippingService, or Organization. Those entities reach it through a shipping property whose value is DefinedRegion. This nesting preserves meaning: the country and state supply geographic context, while the postal range narrows membership.

A range without country context can be ambiguous because postal systems overlap across countries. A US range should sit inside a DefinedRegion with addressCountry set to US, and addressRegion when the operational rule requires state-level containment.

• 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 the shipping entity.
2. Add its origin or destination DefinedRegion.
3. Set country and optional state context.
4. Add postalCodeRange.
5. Validate the whole graph.

Review DefinedRegion in shipping schema for the parent type.

Correct nesting turns a raw code interval into an interpretable shipping region.

Yes, postalCodeBegin and postalCodeEnd define inclusive boundaries, so both endpoint postal codes belong to the range.

An interval from 90001 through 90010 includes 90001, 90010, and every valid code between them according to the merchant's comparison logic. Boundary mistakes commonly remove the first or last serviceable ZIP, especially when application code uses half-open intervals.

Test the code immediately below the beginning, the beginning itself, one interior code, the end itself, and the code immediately above the end. This five-point pattern exposes off-by-one defects without testing every ZIP.

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.

• Document inclusivity in the source system.
• Test both endpoints in checkout.
• Keep comparison behavior consistent across services.
• Retest after range merges or splits.

A schema validator can confirm property names but cannot prove live boundary behavior.

Inclusive endpoints are trustworthy only when the first and last codes receive the same outcome in markup and checkout.

Postal code endpoints must be stored as Text so leading zeros, letters, spaces, and country-specific formatting are preserved.

Converting US ZIP code 00501 to a number produces 501 and changes the identifier. Numeric storage also fails for Canadian and UK-style codes. Even when a range looks numeric, its members are codes, not quantities, and arithmetic does not define universal postal geography.

Normalize only according to the authoritative shipping system. If checkout removes hyphens from ZIP+4 or uppercase letters in another country, the structured region should follow a documented compatible representation rather than an SEO-only transformation.

• 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 endpoints as strings.
2. Preserve leading zeros.
3. Apply country-aware normalization.
4. Reject unintended numeric coercion.
5. Round-trip values through rendering.

Text storage protects identity even when comparison logic later uses a controlled ordering rule.

A postal endpoint remains accurate when serialization preserves every meaningful character from the source system.

Use a postal range when every code in one continuous interval receives the same shipping outcome; use individual codes or multiple ranges when coverage has gaps.

Range compression is efficient but risky. US ZIP assignments are not a simple guarantee that every number between two endpoints is active, belongs to one state, or shares one delivery capability. The question is operational equality, not whether the endpoints look close.

If a carrier table lists scattered ZIPs, preserve those discontinuities. Split one broad interval into several ranges or exact postalCode values. Never bridge an excluded island merely to reduce markup size.

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.

• Compare every implied member with service coverage.
• Split ranges around excluded ZIPs.
• Prefer state scope when outcomes are truly statewide.
• Measure payload size after correctness.

Compact markup is valuable only after geographic truth is preserved.

Choose a range for continuous operational coverage, not merely for shorter code.

Multiple postal ranges can describe separate included intervals within one DefinedRegion, allowing a shipping rule to cover disjoint areas without falsely filling the gaps.

Each range needs its own PostalCodeRangeSpecification with a beginning and end. The collection behaves as included blocks for the surrounding region. Keep the country and state context consistent unless separate DefinedRegion objects make the rule clearer.

Overlapping ranges should be merged when they yield identical outcomes, because duplicates complicate audits. Adjacent ranges may also be merged if the boundary has no exception. When rates or transit times differ, preserve separate shipping conditions even if the regions touch.

• 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. Sort ranges by normalized beginning.
2. Find overlaps and adjacency.
3. Compare their shipping outcomes.
4. Merge only equivalent coverage.
5. Test preserved gaps.

Region cleanup must never erase a meaningful rate, time, or exclusion distinction.

Multiple ranges work when their union matches coverage and every intended gap remains outside.

Postal ranges affect rates and times by determining which destination or origin region matches a shipping condition; the range itself does not contain the price or duration.

A ZIP can select a remote-area surcharge, same-day zone, standard ground band, or unavailable route. That outcome belongs on the surrounding shipping detail or condition. Reusing the same range across competing rules requires deterministic precedence.

Keep the range source synchronized with carrier zones and checkout tables. A stale boundary can quote a low rate for a remote ZIP or hide a service that has expanded. Test prices and delivery promises at both sides of every changed boundary.

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 region before calculating outcome.
• Use one authority for markup and checkout.
• Test each changed endpoint.
• Preserve timestamped carrier evidence.

Origin-aware audits can use shippingOrigin alongside destination ranges.

Postal ranges support accurate promises when their matched shipping outcome comes from the same live policy as checkout.

Common mistakes include reversed endpoints, numeric coercion, missing country context, broad ranges spanning excluded ZIPs, off-by-one boundaries, overlaps with conflicting outcomes, and stale carrier coverage.

Another mistake is treating lexicographic order as universally meaningful across formatted international codes. The type can carry Text endpoints, but a merchant still needs country-specific evidence that the interval represents a valid operational range.

Duplicate ranges create noisy audits, while a postalCodeBegin after postalCodeEnd is structurally wrong. A syntactically valid interval can still be commercially false if checkout uses a different zone file.

• 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. Validate type and parent path.
2. Compare endpoint order.
3. Detect overlaps and implied gaps.
4. Cross-check operational membership.
5. Test boundary ZIPs in checkout.

Fix range generation at its source rather than patching rendered pages individually.

Postal range errors require structural, geographic, and checkout validation together.