What Is postalCodePrefix in DefinedRegion?

postalCodePrefix is a Text property on DefinedRegion that represents all postal codes sharing one common textual prefix.

It supplies geographic membership for a shipping origin or destination without enumerating each full code. The prefix is part of a DefinedRegion; it does not state a shipping rate, transit time, service, or exclusion by itself.

The property is designed for prefix-based postal systems, especially non-numeric formats. US publishers should use it only when the operational system genuinely treats a ZIP prefix as one coverage set. A familiar first-three-digit grouping does not automatically prove identical service for every five-digit ZIP beneath it.

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.

• Keep the value as Text.
• Include country context.
• Confirm every matching code shares the outcome.

Use the free backlink checker to discover linked commerce URLs before changing their shipping regions.

Primary specification: Schema.org definition for postalCodePrefix.

postalCodePrefix is useful when prefix membership is the actual rule used by the shipping system.

postalCodePrefix belongs directly on DefinedRegion, which can then be used as a shipping origin or destination in the surrounding shipping graph.

It should not be attached directly to Product, Offer, ShippingService, or Organization. Those entities use it only through a property whose expected value is DefinedRegion. This nesting gives the prefix a country and optional state context.

A prefix such as 021 is ambiguous without US context, while alphanumeric text can be meaningless without the relevant postal system. Add addressCountry and, when operationally necessary, addressRegion. Do not substitute a street address or warehouse label for a regional prefix.

• 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 parent.
2. Create a DefinedRegion.
3. Set country context.
4. Add the prefix.
5. Validate the complete entity.

Review DefinedRegion in shipping schema for the parent model.

Correct placement turns a text fragment into a meaningful shipping region.

postalCodePrefix matches a set of codes that begin with the supplied text, while postalCode identifies one complete postal code.

Use an exact code when one ZIP or postal unit has a unique shipping outcome. Use a prefix when every full code beginning with that text shares the same rate, time, or availability rule. Choosing a prefix for convenience can silently broaden coverage.

For example, exact ZIP 02108 describes one code, while prefix 021 would imply a larger family. Before publishing that family, compare every included ZIP with the live checkout region. Preserve leading zeros in both exact values and prefixes.

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.

• Start from operational membership.
• Select the narrowest truthful representation.
• Preserve leading zeros.
• Test matching and nonmatching codes.

A prefix is correct only when its wider match set is intentional and verified.

postalCodePrefix groups codes by shared starting text, while postalCodeRange defines an inclusive interval between postalCodeBegin and postalCodeEnd.

Prefix membership is textual. Range membership depends on ordered inclusive endpoints. A prefix can suit systems such as UK postal sectors, while an interval can suit a continuous US ZIP coverage block. Neither model should be chosen merely because it produces shorter JSON-LD.

A range may express 90001 through 90010 without implying every code beginning with 900. Conversely, a prefix can include codes that are not conveniently represented as one numeric interval. Compare the exact set produced by each representation.

• 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. List the intended codes.
2. Compute the prefix match set.
3. Compute the interval match set.
4. Choose the exact set.
5. Test boundaries and outliers.

See PostalCodeRangeSpecification for inclusive interval behavior.

Prefix and range are alternatives whose generated member sets must match operational coverage.

US shipping regions should use ZIP prefixes only when every ZIP matched by that text receives the same operational outcome.

The first digits of a ZIP are useful for grouping and analysis, but they do not guarantee a clean carrier zone, state boundary, or service area. A three-digit prefix can contain exceptions, inactive codes, unique codes, or locations handled differently by checkout.

For most US policies, addressRegion, exact postalCode values, or verified postalCodeRange blocks may be easier to prove. If a prefix is used, test a representative code from every meaningful subarea plus boundary and known exception cases.

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 infer shipping zones from ZIP digits alone.
• Compare carrier and checkout membership.
• Preserve ZIPs as text.
• Document exceptions before publishing.

A US ZIP prefix is defensible only after its entire implied coverage set is verified.

Normalize alphanumeric postal prefixes with country-aware casing, spacing, and punctuation rules that match the authoritative shipping system.

Text comparison can fail when one system stores spaces and another removes them, or when casing differs. The public value should represent a stable prefix, while internal matching may use a documented canonical form. Never apply one global normalization rule to every country.

Preserve meaningful characters and test round trips through database storage, templates, JSON serialization, and checkout matching. If the source system cannot define whether a space matters, investigate before adding markup rather than inventing an SEO-only format.

• 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 country format.
2. Record the source value.
3. Define canonical comparison.
4. Preserve display truth.
5. Test matching full codes.

Prefix normalization is safe when it preserves the same member set across source, markup, and checkout.

A postal prefix affects rates and delivery times by selecting the DefinedRegion whose surrounding shipping rule contains the applicable price, timing, or availability outcome.

The prefix itself carries no monetary or duration value. One matching region may select local delivery, another a remote surcharge, and another an exclusion. Overlapping prefixes can create conflicting matches if precedence is not deterministic.

Keep prefix regions synchronized with carrier tables and checkout logic. When a rate or delivery rule changes, test a matching code, a neighboring nonmatching code, and any code matching both a broad and narrow prefix. Specific rules should resolve consistently across rendered markup and checkout.

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 geographic membership first.
• Apply one deterministic rule.
• Test nested prefixes.
• Compare final checkout output.

Use doesNotShip only for a verified unavailable match set.

Prefix-based promises remain accurate when every matched code resolves to one verified shipping outcome.

Common postalCodePrefix mistakes include missing country context, numeric storage, leading-zero loss, overly broad prefixes, country-blind normalization, conflicting overlaps, and stale shipping coverage.

Another mistake is assuming that a prefix represents a formal administrative region. It represents a text-based code set, which may cross business or geographic boundaries. Valid syntax cannot prove that all matched postal codes share one shipping rule.

A broad prefix can promise delivery to an excluded address. A narrow outdated prefix can suppress newly available service. Duplicate prefixes with different rates or times require an explicit precedence rule or source 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 prefix and parent.
2. Compute its implied member set.
3. Find overlaps and gaps.
4. Compare checkout outcomes.
5. Repair the source system.

postalCodePrefix errors require geographic and operational validation, not only schema syntax checks.