Merchant Return Policy Schema Generator — Set Expectations Clearly

Generate MerchantReturnPolicy JSON‑LD that declares your return window, method, fees, and in‑store options. Attach to Offer, ProductGroup, or Organization.

Try the Return Policy Generator

Why many product pages underperform

Pain points we solve

• Return terms are buried in legal pages and unclear in structured data.
• Shoppers abandon carts when return windows/fees aren’t transparent.
• Policies vary by product/brand but markup isn’t scoped to the right entity.
• Manual JSON‑LD for policies is error‑prone across catalogs.

How SwiftSchema helps

Solution

The return policy generator guides the essentials: `returnPolicyCategory`, optional `merchantReturnDays`, `returnMethod`, `returnFees`, and `returnShippingFeesAmount` (MonetaryAmount).

Attach the policy under `hasMerchantReturnPolicy` on the appropriate object: Offer (per SKU), ProductGroup (variants), or Organization (brand‑level).

How it works

How it works

1. Choose MerchantReturnPolicy in the generator below.
2. Select `returnPolicyCategory` (finite window, unlimited, or not permitted) and set `merchantReturnDays` if applicable.
3. Set `returnMethod` (mail, in‑store, kiosk) and `returnFees` (free, restocking, customer responsibility).
4. Add `returnShippingFeesAmount` as a MonetaryAmount with value and currency if needed; set in‑store returns offered when applicable.
5. Copy JSON or Script and attach under `hasMerchantReturnPolicy` on Offer/ProductGroup/Organization. Validate in the Rich Results Test.

Generate Return Policy JSON‑LD

Attach at Offer, ProductGroup, or Organization. Validate.

What is MerchantReturnPolicy structured data?

MerchantReturnPolicy is a reusable object that describes how customers can return or exchange products: the window, method, fees, whether in-store returns are allowed, and any shipping costs. You attach it to Offers, ProductGroups, or the Organization using

. By publishing this schema, you tell Google Shopping, product carousels, and AI assistants exactly how you treat returns — reducing surprises for shoppers and reinforcing that your product pages aren’t thin or deceptive.

Why transparent return markup matters

• Conversion confidence: Clear, machine-readable policies increase shopper trust, especially for high-ticket items. Hidden policies trigger cart abandonment.
• Regulatory compliance: Some regions require merchants to display return rights prominently. Structured data helps prove you comply.
• Catalog management: Brands often have different policies by category or vendor. Schema lets you scope policies precisely to the relevant offers.
• Automation & QA: Once policies are structured, you can programmatically audit them across thousands of SKUs to catch mismatches or expired promos.

Essential properties to include

• returnPolicyCategory
  (required): Choose one of:
  • MerchantReturnFiniteReturnWindow
  • MerchantReturnUnlimitedReturnWindow
  • MerchantReturnNotPermitted
• merchantReturnDays
  : Integer for finite windows. Ensure it matches the copy on the page (e.g., 30 days).
• returnMethod
  :
  ReturnByMail
  ,
  ReturnInStore
  ,
  ReturnAtKiosk
  , etc. Use arrays for multiple methods.
• returnFees
  :
  FreeReturn
  ,
  RestockingFee
  ,
  OriginalShippingFee
  , or
  ReturnShippingFee
  . If you require customers to pay shipping, pair it with
  returnShippingFeesAmount
  .
• returnShippingFeesAmount
  : MonetaryAmount with
  value
  and
  currency
  . Useful for flat fees (“USD 7.95”).
• inStoreReturnsOffered
  : Boolean.
• returnEligibilityCondition
  : Free-text or structured description (e.g., “Items must be unused with original tags”).
• itemCondition
  : When returns only apply to certain conditions (e.g., new), list them.
• applicableCountry
  /
  applicableTerritory
  : Localize policies by region when needed.

Preparing policy content before generating schema

1. Centralize policy data: Pull return terms from your legal/CS team. Note differences by product type, vendor, or geography.
2. Define categories: Map each product category to a policy (e.g., electronics 30-day free returns, clearance final sale). Document which Offers fall under each policy.
3. Clarify methods: Confirm whether customers can return in store, by mail, or via pickup. Document any restocking fees or shipping charges.
4. Write eligibility conditions: Outline requirements (original packaging, receipt, exclusions). Include them in visible copy and schema
   returnEligibilityCondition
   .
5. Plan localization: Some countries mandate longer windows or specific phrasing. Prepare localized versions of the policy object and copy.
6. Coordinate with CX tooling: Ensure the schema matches what your self-service portal, email templates, and printed invoices say. Discrepancies erode trust.

With this prep, each product or offer page can feature a clearly written returns section plus matching structured data, pushing you well above thin-content thresholds.

Implementation workflow inside SwiftSchema

1. Choose MerchantReturnPolicy in the generator.
2. Select the
   returnPolicyCategory
   . If returns aren’t allowed (
   MerchantReturnNotPermitted
   ), still describe why in the visible copy.
3. For finite windows, set
   merchantReturnDays
   ; for unlimited, leave it absent.
4. Choose
   returnMethod
   values and indicate whether in-store returns are offered.
5. Specify
   returnFees
   . If fees exist, add
   returnShippingFeesAmount
   or
   restockingFee
   details so search engines understand the cost.
6. Add
   returnEligibilityCondition
   text that mirrors your policy page (e.g., “Final sale on clearance styles”).
7. Export the JSON-LD and attach it under
   hasMerchantReturnPolicy
   on:
   • Individual
     Offer
     objects (per SKU),
   • ProductGroup
     (variant sets), or
   • Organization
     (sitewide default).
8. Validate via the Rich Results Test. While there’s no dedicated card, the validator ensures the object is parsed correctly.

Troubleshooting and QA

• Mismatch with copy: Ensure the schema mirrors the on-page policy. Google may penalize discrepancies (e.g., schema says free returns but copy says “customer pays shipping”).
• Incorrect scope: Don’t attach a lenient policy to clearance items if they’re final sale. Maintain mappings so each Offer references the right policy object.
• Missing currency: When specifying shipping fees, include ISO currency codes. Without them, validators may flag the policy.
• Localization gaps: If EU regulations require 14-day returns, confirm your localized schema reflects the correct window. Avoid reusing US policies globally.
• No eligibility conditions: When returns have exceptions (e.g., personalized items), mention them in both copy and schema to avoid chargebacks or disputes.
• Unused policies: Remove obsolete policy objects from your CMS to avoid referencing outdated terms.

Automate QA by running scripts that compare schema values to your policy database. Alert merchandising teams when differences arise.

Maintenance and governance

Return policies change with merchandising strategy, supply chain costs, or regional regulations. Build a governance loop:

• Track every policy object in a central spreadsheet (category, scope, return days, fees, last update).
• When the legal/CX team updates terms, regenerate the schema and redeploy to affected pages immediately.
• Review policies quarterly to ensure shipping costs and service options remain accurate.
• During promotions (extended holiday returns), create temporary policies with
  validFrom
  /
  validThrough
  in your product copy and schema, then sunset them afterward.

Keep

metadata current so stakeholders know the schema is freshly audited.

Common Errors & Fixes

• Wrong query category: choose the correct
  returnPolicyCategory
  to avoid misleading shoppers.
• Missing fees: if you charge for returns, document it via
  returnFees
  and
  returnShippingFeesAmount
  .
• Applying policies at wrong level: attach to Offer/ProductGroup when terms vary; use Organization only for true defaults.
• Lack of localization: create separate policies per region if legal requirements differ.
• Copy/schema drift: keep structured data synchronized with the visible return policy text and customer support documentation.

{
  "@context": "https://schema.org",
  "@type": "MerchantReturnPolicy",
  "returnPolicyCategory": "MerchantReturnFiniteReturnWindow",
  "merchantReturnDays": 30,
  "returnMethod": "ReturnByMail",
  "returnFees": "FreeReturn",
  "inStoreReturnsOffered": true
}