Free Merchant Return Policy Schema Generator

Why many product pages underperform

How SwiftSchema helps

How it works

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 hasMerchantReturnPolicy. 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
  • MerchantReturnUnlimitedWindow
  • 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, RestockingFees, OriginalShippingFees, ReturnShippingFees, or ReturnFeesCustomerResponsibility. 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.
• itemCondition: the condition items must be in to be returned (for example NewCondition). Put other eligibility rules (original tags, receipt) on the policy page.
• itemCondition: When returns only apply to certain conditions (e.g., new), list them.
• applicableCountry / returnPolicyCountry: the countries the policy applies to and where returns are sent.

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; use itemCondition for the item-condition rule.
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. Keep exclusions (e.g., “Final sale on clearance styles”) on the policy page; MerchantReturnPolicy has no free-text eligibility property.
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 lastReviewed 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.