What Is Merchant Shipping Policy Schema?

Merchant shipping policy schema is structured data that describes a store’s standard delivery services, conditions, costs and timing in a machine-readable format.

For an online merchant, shipping promises are part of the offer - not decoration. Organization-level markup connects an Organization or OnlineStore to a ShippingService through hasShippingService. Each service can then carry one or more ShippingConditions records for destinations, order thresholds, rates and delivery periods. The visible policy page remains the customer-facing source; JSON-LD should encode the same rules without adding unshown promises. This markup may help eligible product information display more complete shipping context, but valid markup never guarantees a special search appearance. Treat it as a precise data contract, not a ranking shortcut.

1. Frame the decision raised by What Is Merchant Shipping Policy Schema.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Publish a clear shipping policy page.
• Encode standard services at organization level.
• Reserve product markup for genuine exceptions.

A reliable implementation starts with one written policy and mirrors only rules customers can verify.

The decision for What Is Merchant Shipping Policy Schema should rest on live, traceable evidence and a verified follow-up check.

Shipping policy schema works by matching an applicable destination and order condition to a shipping rate and delivery period.

A store may offer standard, expedited and collection-point services. Within each service, conditions can segment orders by country, region, order value, item count, weight or dimensions when those distinctions are real. A crawler reads the graph, selects conditions applicable to the product and shopper context, and can associate the rate with its corresponding speed. Ambiguous or overlapping conditions weaken the model because multiple records may appear applicable. Build conditions from the same source used by checkout, then test boundary values such as exactly $50, one ounce over a weight band and excluded ZIP codes. The markup should never claim worldwide delivery simply because a destination was omitted accidentally.

• Evidence for How Does Shipping Policy Schema Work: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. List each real shipping service.
2. Split mutually exclusive conditions.
3. Attach rates and timing.
4. Test boundary and exclusion cases.

The schema works only when every condition resolves to the same answer the buyer sees at checkout.

The decision for How Does Shipping Policy Schema Work should rest on live, traceable evidence and a verified follow-up check.

Use organization-level ShippingService for the standard policy and offer-level OfferShippingDetails only when a specific product needs an exception.

This separation prevents thousands of product pages from repeating a policy that belongs to the merchant. A global service can express richer business rules and becomes easier to maintain on one policy page. An individual Offer may use shippingDetails when a bulky product, hazardous item, preorder or special destination follows different terms. Offer-level support is narrower, so do not copy every organization property into it. If a product follows the default, let the default remain authoritative. Pair the model with accurate Organization Schema and Product Schema rather than creating disconnected entities.

1. Frame the decision raised by Organization-Level vs Offer-Level Shipping Data.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Keep standard rules on the policy page.
• Use stable @id references where appropriate.
• Document why each product override exists.

Choose the narrowest override that reflects reality while keeping the default policy centralized.

The decision for Organization-Level vs Offer-Level Shipping Data should rest on live, traceable evidence and a verified follow-up check.

The most important properties identify the service, define its conditions, state where it applies and connect each rate to realistic handling and transit time.

At minimum, a useful model needs shippingConditions. Descriptive fields such as name and description help humans maintain multiple services, while fulfillmentType separates delivery from collection-point fulfillment. Conditions carry operational facts: shippingDestination, shippingOrigin, orderValue, numItems, weight or dimensional constraints, shippingRate, transitTime and doesNotShip. Include only supported properties that correspond to actual rules. More properties do not automatically create better data; complete, non-conflicting coverage is more valuable than an oversized graph with invented precision.

• Evidence for Which Shipping Properties Matter Most: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Map each property to an owner.
2. Confirm its visible equivalent.
3. Remove unsupported or speculative values.
4. Schedule change monitoring.

Prioritize properties that checkout can prove and that operations can keep current.

The decision for Which Shipping Properties Matter Most should rest on live, traceable evidence and a verified follow-up check.

Model destinations as explicit regions and rates as the exact fixed amount, percentage or supported calculation that applies to each condition.

For a US-focused store, country alone may be too broad if Alaska, Hawaii, territories or particular postal-code ranges differ. Use the most precise supported region representation that matches checkout, and make exclusions explicit instead of silently leaving contradictory coverage. Currency must match the monetary amount. Free shipping is a zero-valued rate, not a missing rate, when zero is genuinely the customer price. Order thresholds need clean, non-overlapping boundaries; a $50 threshold should not leave $49.995 or exactly $50 uncertain. When the rate depends on weight, dimensions or order percentage, verify that the structured formula reproduces live checkout results for representative carts.

1. Frame the decision raised by How Should Destinations and Rates Be Modeled.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Test continental US and excluded regions.
• Check exact threshold values.
• Compare zero, fixed and percentage rates.
• Verify currencies by market.

Destination and price bands are complete when every eligible cart lands in one truthful result.

The decision for How Should Destinations and Rates Be Modeled should rest on live, traceable evidence and a verified follow-up check.

Handling time covers preparation before carrier handoff, while transit time covers movement after handoff; combine them only when your visible delivery promise uses the same logic.

A warehouse may need zero to one business day to pack an order, followed by two to four carrier business days. Represent those as separate periods so a late warehouse handoff is not confused with carrier performance. Use ServicePeriod with a duration range, supported units, business days and a cutoff time where the rule is operationally enforced. Include the UTC offset in a cutoff time so buyers in different zones are not assigned the wrong processing day. Holiday exceptions and disruption notices belong in the visible policy and operational systems; do not pretend a static graph captures real-time exceptions unless your publishing pipeline updates it.

• Evidence for How Should Handling and Transit Times Work: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Measure warehouse preparation ranges.
2. Record service-specific transit ranges.
3. Set business days and timezone-aware cutoffs.
4. Compare calculated totals with checkout.

Separate handling from transit so the delivery estimate remains explainable and maintainable.

The decision for How Should Handling and Transit Times Work should rest on live, traceable evidence and a verified follow-up check.

Shipping policy schema normally does not apply to pure SaaS because software access is delivered digitally rather than shipped as a physical product.

A subscription to SEO software has activation, billing, cancellation and support terms, but it does not have a carrier, destination region or parcel transit time. Adding zero-cost shipping markup to a digital service creates a category error and can confuse product understanding. A company that sells both software and physical merchandise should scope shipping data only to the physical catalog and its store policy. Describe the software with SoftwareApplication Schema, accurate offers and visible subscription terms. Novaverb uses shipping-schema knowledge to help customers audit commerce sites; it does not claim that its own cloud software ships in a box.

1. Frame the decision raised by Does Shipping Policy Schema Apply to SaaS.
2. Confirm its value type and the object it describes.
3. Compare the markup with visible page information.
4. Correct the source data or template without inventing values.
5. Validate the rendered result and monitor future changes.

• Classify physical and digital inventory.
• Exclude pure digital access from shipping rules.
• Scope mixed bundles carefully.

Use shipping markup for physical fulfillment, never as a generic property of every commercial offer.

The decision for Does Shipping Policy Schema Apply to SaaS should rest on live, traceable evidence and a verified follow-up check.

Common shipping schema mistakes include hidden promises, overlapping conditions, missing destinations, incorrect time units and unnecessary product-level duplication.

The most damaging error is disagreement between the graph, policy page and checkout. A markup generator may default to worldwide coverage, copy a single rate across every country or interpret calendar days as business days. Teams also confuse handling and transit time, omit a timezone from cutoff values, or leave old seasonal rates live after checkout changes. Another frequent mistake is nesting types at the wrong level: ShippingService belongs under the organization default, while product-specific data belongs under an offer. Syntax validation will not detect most commercial contradictions, so an audit needs representative carts and human-readable evidence.

• Evidence for What Shipping Schema Mistakes Are Common: the live structured-data entity and property relationship
• The expected value type and any nested object
• Visible page information that supports the structured value
• Related offer or catalog fields needed for interpretation
• A fresh validation result after the page changes

1. Validate JSON-LD syntax.
2. Compare every condition with policy copy.
3. Run representative checkout carts.
4. Remove stale and duplicate rules.

A schema passes the real test when its promise survives comparison with policy text and checkout.

Start with a relevant free SEO check, continue the evidence workflow in Novaverb, and review pricing when comparing continuous monitoring with a one-time manual review.

The decision for What Shipping Schema Mistakes Are Common should rest on live, traceable evidence and a verified follow-up check.