If you sell products online without using Merchant Center, Google does not have to infer your delivery charges, delivery expectations, or return terms from scattered pages. You can now provide shipping and return policy information through Search Console or site markup.
The implementation is only reliable when the data matches checkout, customer-service rules, and the policy customers can read. Before touching JSON-LD, decide which rules are your store-wide defaults, which products are exceptions, and which system owns each value.
Write down the operational policy before you encode it
Structured data compresses a policy into machine-readable fields. It cannot resolve an unclear policy for you. If your shipping page, checkout, support team, and warehouse operate from different assumptions, markup will publish one of those inconsistencies more efficiently.
Build a policy matrix with one row for every market whose terms materially differ. Record the answers to these questions:
- Where do you ship?
- Which shipping service does the policy describe?
- What does the customer pay, and in which currency?
- How long can handling take before the parcel enters the carrier network?
- How long can transit take after handoff to the carrier?
- Which countries are covered by the return policy?
- Is the return window finite, unlimited, or unavailable?
- If the window is finite, what event starts it: purchase, dispatch, delivery, or another event stated in your customer-facing terms?
- Which return methods are allowed?
- Who pays the return cost?
- Which products or conditions are excluded?
Keep handling time separate from transit time. Handling is under the merchant’s control; transit begins after carrier handoff. Combining them into an attractive but unsupported delivery promise creates a mismatch precisely where a shopper is looking for certainty.
Use the policy customers can actually claim, not an aspirational service level. A lower shipping charge, faster delivery estimate, longer return window, or broader free-return promise can affect purchase decisions. If checkout or support will not honor it, do not publish it in structured data.
Choose Search Console or Organization markup deliberately
Search Console and structured data are two publishing routes for the same operational truth. Your choice should be based on ownership and maintainability, not on which route appears more technical.
| Publishing route | Best fit | Main control to establish |
|---|---|---|
| Search Console | You want a no-code route and have a straightforward store-wide policy. | Name the person responsible for updating the settings whenever operations or terms change. |
| Organization JSON-LD | Your team already manages structured data through code, a CMS, or a schema layer. | Keep the values version-controlled or otherwise traceable to the policy owner. |
| Merchant Center | Your shopping program already treats its account or feed data as the commercial source of truth. | Do not add a separately maintained policy unless you can guarantee that the systems remain aligned. |
Search Console is often the smaller change when you do not use Merchant Center and do not want to alter templates. Organization JSON-LD is usually easier to audit alongside other website releases. Neither route improves a weak policy, and neither should become a forgotten copy of information maintained elsewhere.
Avoid entering one version in Search Console while a plugin emits another version in the page source. Google may encounter both, but you should not assume it will resolve the conflict in the way you intended. Pick a primary owner, document any secondary output, and update both in the same change workflow if both must exist.
Map your policy to the JSON-LD concepts
At the Organization level, the conceptual structure has two branches. Shipping information is expressed through shippingDetails using OfferShippingDetails. Return information is attached through hasMerchantReturnPolicy using MerchantReturnPolicy.
The following map is more useful than copying a generic snippet because it forces every machine-readable value back to an operational answer:
| Business question | Structured-data concept | What to verify |
|---|---|---|
| Where does this shipping rule apply? | shippingDestination | The destination matches an area that checkout actually serves. |
| What does shipping cost? | shippingRate | The value and currency describe the selected service without hiding a condition that changes the charge. |
| How long before carrier handoff? | handlingTime | The range reflects normal fulfillment commitments rather than the fastest observed order. |
| How long after carrier handoff? | transitTime | The range belongs to the destination and service represented by this shipping rule. |
| Where does the return policy apply? | applicableCountry | The country is covered by the customer-facing terms. |
| What kind of return window applies? | returnPolicyCategory | The category agrees with whether returns are finite, unlimited, or unavailable. |
| How long is a finite window? | merchantReturnDays | The duration matches the policy page and the event from which your published terms calculate it. |
| How can an item be returned? | returnMethod | The encoded method is genuinely available to customers in the covered market. |
| Who bears the return cost? | returnFees | The value reflects the ordinary case and does not erase important conditions or deductions. |
Use the defined Schema.org value expected by a category, method, or fee field rather than inserting promotional prose such as “easy returns.” JSON-LD describes the rule; the visible policy page explains qualifications, procedures, deadlines, item condition requirements, refund timing, and exceptions.
Connect the policy to your existing canonical Organization entity instead of creating unrelated Organization objects in several plugins. A stable @id helps the graph refer to the same business, but it does not excuse conflicting values. Inspect the final rendered source because the output seen by a crawler can differ from what a CMS form displays.
Do not let a store-wide default erase product exceptions
An Organization-level policy works as a default. It becomes misleading when a substantial set of offers follows different rules. Customized goods, clearance inventory, oversized products, subscriptions, perishable items, and digital products can all require different treatment depending on how your business operates.
Do not encode the most generous policy as universal merely because it produces the cleanest markup. Decide how each exception should be handled:
- If a different rule applies to a market, represent that market separately rather than blending incompatible destinations, currencies, charges, or delivery estimates.
- If a product class has a different return rule, do not allow the organization default to make an unconditional promise that the product page later withdraws.
- If your implementation supports properly scoped offer-level information, use it for genuine product exceptions and keep it synchronized with the offer.
- If you cannot represent an exception accurately, narrow or omit the affected machine-readable claim instead of publishing a false universal rule.
- Explain detailed conditions on a crawlable customer-facing policy page. Do not expect a compact structured-data object to carry the entire contract.
Pay particular attention to conditional free shipping and conditional free returns. A rate that depends on basket value, membership, location, product class, or selected service is not simply a universal zero-cost rate. Encode only the condition your implementation can represent faithfully, and leave the full qualification visible before purchase.
Validate the output and the promise
Syntax validation is necessary, but it only proves that a machine can parse the data. A valid object can still describe the wrong destination, currency, service, timing, fee, or return window.
- Open the rendered page or server response that contains the Organization data. Confirm that the expected JSON-LD is present for an ordinary crawler and is not merely visible inside an administration screen.
- Parse the JSON-LD with a structured-data validator. Fix malformed JSON, unsupported value shapes, missing relationships, and duplicate entities.
- Compare every emitted value with the shipping page, returns page, checkout calculation, and current support instructions.
- Test representative destinations and product exceptions. A default that is correct for the easiest order may be wrong for the rest of the catalog.
- Check Search Console after publication for the status Google exposes, but do not treat the absence of an error as proof that the policy will be displayed.
- Add shipping and return data to your release checklist. Changes to carriers, fulfillment locations, service levels, charges, destinations, or return terms should trigger the same review.
Structured data makes information eligible for machine use; it does not command a particular Search appearance or guarantee rankings. Judge the deployment first by accuracy, consistency, and maintainability. Any additional visibility is downstream of those basics.
Key takeaways
- You can provide shipping and return policy information through Search Console or website markup without using Merchant Center for the task.
- Define destination, charge, handling, transit, return window, method, fees, and exceptions before encoding anything.
- Use Organization-level data for a genuine default, not as a shortcut that conceals product or market differences.
- Choose one operational source of truth and prevent Search Console, Merchant Center, plugins, templates, checkout, and policy pages from drifting apart.
- Validate both the JSON-LD structure and the commercial promise represented by every value.
Start with the policy matrix, assign an owner, and publish the smallest accurate default through the route your team can maintain. Once that default survives a comparison with real checkout scenarios and known exceptions, you have markup worth exposing to Google.
Leave a Reply