A shopper finds your product in Google. The price looks right. The photo looks good. Then the same two questions show up: “When will it arrive?” and “Can I return it?”
If Google can’t find those answers, your listing may look incomplete next to a competitor that clearly shows free shipping, delivery timing, or a 30-day return window.
Until recently, many small stores assumed that getting these details into Google required a configured Google Merchant Center account. That’s no longer true. Google now allows websites it identifies as online merchants to submit shipping and return policies directly in Search Console. Stores can also publish the information through organization-level structured data on their own sites, according to the Google Search Central announcement.
This is a small technical update with a useful business outcome. You can make fulfillment terms clearer in Google without building a product feed first. Here’s how to choose the right method and implement it without creating conflicting data.
What Google changed
Google expanded the “Shipping and returns” area in Search Console beyond merchants with a configured Merchant Center account. The feature is available to sites that Google identifies as online merchants and provides a form-based way to send policy information to Google, according to Google Search Central.
Google also introduced organization-level shipping policy markup. Instead of repeating the same shipping rules in the structured data for every product, a store can define a general policy once under its Organization, OnlineStore, or LocalBusiness markup. Product-specific shipping data can still override the general policy when an item has different terms.
Return policies follow a similar model. Google supports MerchantReturnPolicy nested under Organization markup and says the data can describe the return window, permitted item condition, method, fees, refund type, and other details. Google may use the information beside products and in knowledge panels, according to its return policy structured data documentation.
The phrase “may use” matters. Valid data makes a page eligible. It does not guarantee that Google will show the information for every search or product. Google says search result enhancements appear at its discretion and can change over time in its Product structured data guide.
Why shipping and return details belong in your SEO work
This isn’t about adding code for the sake of passing a test. Shipping cost, delivery time, and return terms are part of the offer.
Google says product structured data can make products eligible to show price, availability, ratings, shipping information, and more in Search, Google Images, and Google Lens. It also recommends sharing shipping costs, especially free shipping, so shoppers can understand total cost. Return markup can communicate fees and the number of days available for a return, as described in Google’s Product structured data documentation.
For a small retailer, clearer search listings can do three practical jobs. They can answer an objection before the click, distinguish your offer when competitors sell a similar product, and reduce the chance that a shopper arrives expecting terms you don’t provide.
The policy page itself matters too. A vague paragraph that says “most orders ship quickly” is not useful to a customer or a machine. A useful policy states where you ship, what shipping costs, when orders are processed, which days count as business days, and how long delivery usually takes. The markup should describe those visible rules, not invent a better offer than the page provides.
Choose Search Console or structured data
Most small stores should begin with the method they can maintain reliably.
Use Search Console when the policy is simple
Search Console is the easier choice when one shipping policy and one return policy cover most of the catalog. There is no code deployment, and a business owner or marketer can update the settings without waiting for a developer.
Open the verified Search Console property for the store, go to Settings, and look for “Shipping and returns.” If the section is missing, Google may not yet identify the site as an online merchant, the feature may not be available for that property, or your account may lack the required permissions. Google says the feature applies to websites it identifies as online merchants in its launch announcement.
Enter only policies that match what customers can read on the website and what the checkout actually charges. Google states that settings configured in Search Console take precedence over structured data on the site. That makes Search Console convenient, but it also creates a maintenance risk if someone changes the website policy and forgets to update the setting.
Use structured data when the website is the source of truth
Structured data makes more sense when policies are managed in the site’s code or commerce platform, when different destinations have different terms, or when developers already maintain Organization and Product schema.
Google recommends putting general shipping markup on the page that describes the shipping policy, nested under Organization markup. For an ecommerce business, Google recommends the more specific OnlineStore subtype. A local retailer can use LocalBusiness, according to the organization-level shipping policy guide.
The same pattern works for the general return policy. Google recommends placing the return information on one page that describes the business policy. You don’t need to repeat organization-level return markup on every page, according to the MerchantReturnPolicy technical guidelines.
Use product-level rules for exceptions
A general policy breaks down when one item ships by freight, another can’t be returned, or a made-to-order product needs ten handling days.
Google says product-level shipping information takes priority over organization-level shipping policy for that item. It makes the same distinction for nonstandard return policies, which can be added under the product’s Offer markup using the supported product-level properties. This priority model is documented in Google’s shipping announcement and return policy guide.
That gives you a clean structure: one default policy for the store, then exceptions only where they are real.
What your policy pages need to say
Before touching schema, fix the customer-facing pages. Structured data can’t rescue unclear operating rules.
Your shipping page should clearly state:
- Destinations served and any excluded regions
- Shipping charges, free-shipping thresholds, and currency
- Order cutoff time, handling time, transit time, and business days
- Whether pickup, delivery, or other fulfillment options apply
- Products or conditions that use different shipping terms
Google’s ShippingService documentation supports details such as destination, order value, shipping cost, handling time, transit time, cutoff time, and business days. Its published example shows different rules by country and order value, including a free-shipping threshold, in the merchant shipping policy specification.
Your return page should answer the questions customers ask before buying: how many days they have, when the clock starts, what condition the item must be in, how to initiate a return, who pays return shipping, whether returns can happen by mail or in store, and whether the customer receives a refund, exchange, or store credit.
Google’s supported organization-level return properties include the applicable country, return window, return method, return fees, refund type, item condition, and seasonal overrides. The exact supported fields and allowed values are listed in the MerchantReturnPolicy documentation.
Do not copy a code example until the business rules are settled. If your policy says customers have 14 days but the markup says 30, you’ve created a contradiction that can disappoint buyers and make the data harder to trust.
A safe implementation workflow
Treat this as a short operations project, not an SEO trick.
First, assign one owner. For a small store, that might be the owner, ecommerce manager, or operations lead. That person confirms the real policy with whoever handles fulfillment and customer service.
Second, update the visible policy pages. Use plain language and specific terms. Link them from the footer and checkout so customers can find them without hunting.
Third, choose one primary submission method. If you use Search Console, record the settings in your website change log. If you use structured data, have the website produce it from the same configuration that controls customer-facing policy text when possible.
Fourth, add product-level exceptions only to affected items. Freight, final-sale, perishable, oversized, custom, and preorder products are common exceptions. Make the exception visible on the product page before marking it up.
Fifth, validate and inspect. Google tells site owners to validate structured data with the Rich Results Test, fix critical errors, deploy the markup, and use Search Console’s URL Inspection tool to see how Google reads the page. The policy page must be crawlable and not blocked by robots.txt, a noindex directive, or a login requirement, according to Google’s structured data implementation steps.
Finally, check the live listing and Search Console after Google recrawls the page. Valid markup does not promise a visible enhancement, so judge the project first on data accuracy and eligibility, not on whether one test search immediately shows a shipping label.
Mistakes that create more work later
The first mistake is configuring Search Console and schema separately, then forgetting that Search Console wins. If both are present, build a reminder into every policy change so the two sources stay aligned.
The second is putting the general policy on every product manually. That creates hundreds of copies to update. Organization-level policy markup exists specifically to reduce that maintenance burden when one rule covers most items, as Google explains in its shipping policy announcement.
The third is marking up terms that customers can’t see. Google’s general structured data rules require markup to represent visible page content and warn against misleading or irrelevant data in its structured data guidelines.
The fourth is assuming that a plugin has handled everything. Ecommerce plugins can output schema, but stores often have custom shipping tables, app-based returns, or theme overrides. Read the rendered JSON-LD and compare it with the actual policy. A green test only confirms that the format is valid. It doesn’t confirm that your business terms are correct.
The fifth is treating the policy as permanent. Carrier rates change. Holiday windows change. New products introduce exceptions. Review policy pages and submitted data before peak seasons and after any fulfillment change.
The 60-minute version for a small store
You don’t need a month-long schema project to make progress.
Spend 15 minutes comparing your shipping page, return page, checkout, and customer service answers. Spend another 15 minutes rewriting any vague or conflicting terms. Use the next 15 minutes to configure Search Console or brief your developer on organization-level markup. Use the final 15 minutes to test the policy URLs, record the setup, and schedule a quarterly review.
If your catalog has exceptions, handle the top-selling products first. Confirm that final-sale, oversized, custom, and backordered products state their special terms on the page. Then add product-level data in a controlled second pass.
Shipping and returns are not glamorous SEO work. They are buyer-confidence work that Google can now understand more clearly. Make the real policy easy for customers to read, give Google the same facts through one maintainable source, and keep exceptions attached to the products they affect.
Need help cleaning up ecommerce schema, Search Console, or policy pages without breaking the rest of your store? Start a practical website project with Your Web Team.
