What Is isUnlabelledFallback in ShippingRateSettings?

isUnlabelledFallback is a Boolean property that marks unlabelled ShippingRateSettings as the fallback intended to apply across the same merchant's OfferShippingDetails context.

A true value expresses default behavior, not merely a convenient label omission. The vocabulary describes it for settings that are unlabelled and historically referenced through shippingSettingsLink. Because shippingSettingsLink is now retired, teams must distinguish the property's meaning from the compatibility mechanism used by a particular consumer.

The property does not set a shipping price, destination, threshold, delivery speed, or exclusion. Those outcomes still come from the rate settings and related shipping entities. A fallback is only as accurate as the rate policy it points toward.

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 Boolean values.
• Keep true settings unlabelled.
• Validate the merchant and Offer scope.
• Test the actual shipping outcome.

Use the free backlink checker to identify linked pages before changing a shared shipping fallback.

Primary specification: Schema.org definition for isUnlabelledFallback.

isUnlabelledFallback is correct only when an unlabelled settings node genuinely represents the merchant's default shipping-rate policy.

isUnlabelledFallback can be used on ShippingRateSettings, while its definition also discusses analogous unlabelled DeliveryTimeSettings behavior.

For this article's rate intent, place the property on the ShippingRateSettings entity that contains or resolves the default rate logic. Do not attach it directly to Product, Offer, OfferShippingDetails, ShippingConditions, DefinedRegion, or MonetaryAmount.

A correctly typed parent helps crawlers and internal auditors preserve entity boundaries. It also prevents a broad default flag from being mistaken for a Product-level promise or a destination-level rule.

• 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. Locate the settings entity.
2. Confirm it models rates rather than transit time.
3. Attach one Boolean value.
4. Preserve stable entity identifiers.

Start with ShippingRateSettings and OfferShippingDetails.

Correct placement keeps a fallback declaration attached to reusable settings rather than to the products, Offers, or monetary values that use them.

Set isUnlabelledFallback to true only when the unlabelled settings are deliberately intended as the merchant-wide fallback for matching OfferShippingDetails that lack a more specific settings selection.

A true value should trace to an authoritative commerce rule: for example, the merchant's default contiguous-US standard rate when no product, service, membership, marketplace seller, or destination-specific policy supersedes it. Absence of a label by accident is not evidence of fallback intent.

The default must remain safe for every Offer cohort it may reach. If oversized, hazardous, refrigerated, vendor-direct, subscription, digital, or international products need different behavior, a single broad fallback may be too coarse without deterministic exception handling.

• 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 policy owner.
2. Document the intended default cohort.
3. Enumerate all exceptions.
4. Prove specific rules win where required.
5. Only then publish true.

A true fallback is defensible when default intent is explicit and every exception keeps its more specific checkout result.

A true isUnlabelledFallback value should not be combined with shippingLabel because the property is specifically defined for unlabelled settings.

A label selects or distinguishes a particular settings set, while a fallback covers the absence of that specific selection. Combining both creates contradictory semantics: the same entity claims to be selected by a label and to serve as the unlabelled default.

The same logic applies to transitTimeLabel when the property appears in the DeliveryTimeSettings context described by the vocabulary. Current audits must also record that shippingLabel and transitTimeLabel are retired terms, so removal or migration should follow consumer evidence rather than assumption.

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.

• Extract fallback values and labels.
• Flag every true-plus-label combination.
• Split specific and default policies where needed.
• Retest entity matching.

A fallback remains semantically clear when true identifies an unlabelled default and never doubles as a labelled, specifically selected policy.

The current definition still describes matching through shippingSettingsLink, but shippingSettingsLink, shippingLabel, and transitTimeLabel are retired vocabulary terms, so implementations need an explicit compatibility and migration audit.

Retired does not mean that every existing consumer immediately ignores every historical graph. It does mean a new architecture should not assume that retired cross-references are the durable path forward. Record which parser, platform, export, feed, or internal service consumes the settings before changing production markup.

Separate three questions: what the fallback property means, how a current consumer discovers the settings, and what checkout actually charges. A vocabulary page can define semantics while a consumer supports only a subset or a different integration path.

• 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. Inventory every retired term.
2. Map each consumer and version.
3. Capture rendered graphs before migration.
4. Test a controlled cohort.
5. Keep rollback evidence.

Retirement-safe work preserves the fallback's intended meaning while replacing unsupported dependencies only after real consumer and checkout tests.

Specific shipping rules should take precedence over the unlabelled fallback whenever a product, destination, service, seller, membership tier, or exception has a narrower authoritative policy.

A fallback is a last applicable rate, not permission to flatten the shipping matrix. A contiguous-US standard default must not overwrite express prices, Alaska or Hawaii rates, international exclusions, freight charges, hazardous-material restrictions, or seller-specific fulfillment.

Make precedence deterministic in the commerce source before generating markup. One useful order is availability prohibition, product or seller exception, destination and service-specific rule, qualifying promotion, then fallback. The exact order must reproduce checkout rather than follow a generic template.

• 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. Resolve non-shipping outcomes.
2. Apply product and seller exceptions.
3. Match destination and service.
4. Evaluate promotions.
5. Use fallback only last.

Model geography with shippingDestination and preserve unavailable outcomes before applying a rate.

A fallback is safe when every narrower rule wins predictably and the remaining default cohort matches checkout.

isUnlabelledFallback selects default settings behavior; shippingRate, freeShippingThreshold, orderPercentage, and weightPercentage determine the monetary result inside those settings.

Do not treat true as a zero-cost signal. The fallback may contain a fixed maximum rate, a percentage component, a free-shipping boundary, or a combination supported by the merchant's implementation. Currency, weight units, eligible subtotal, and service scope remain independent requirements.

At checkout, first determine whether specific settings apply. Only then use fallback settings and calculate the rate in the documented order. Threshold equality, discounts, excluded items, and mandatory freight can all change the final result without changing the fallback flag.

• 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. Select specific or fallback settings.
2. Resolve exclusions and service.
3. Calculate eligible monetary inputs.
4. Apply threshold or rate formula.
5. Compare the final checkout charge.

Compare freeShippingThreshold and shippingRate.

Fallback selection and rate calculation stay accurate when they are modeled as separate decisions and verified together.

Common mistakes include using true as a substitute for a missing label, combining true with a label, attaching the property to the wrong entity, assuming it means free shipping, ignoring exception precedence, and relying blindly on retired links.

Other defects include multiple competing true fallbacks for the same merchant and cohort, false values that are treated as active defaults, Boolean strings emitted inconsistently, and fallback settings that differ from checkout after promotions or catalog changes.

Repair the policy source rather than patching individual pages. Shared settings defects can affect thousands of Offers, so preserve the affected cohort, compare live outcomes, stage the change, and keep a rollback path.

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.

• Find every true value.
• Group by merchant and cohort.
• Detect labels and duplicate defaults.
• Compare exceptions and checkout.
• Repair the authoritative configuration.

Fallback defects are resolved only when entity placement, Boolean meaning, uniqueness, precedence, consumer compatibility, and checkout outcome all agree.