Delivery and Returns Are Missing From Your Structured Data

In some categories, the thing holding the sale up has nothing to do with the product. Frozen food, ceramics, oversized furniture, live plants: the customer already wants it. What they don't know is whether it will survive the trip, what freight costs to their postcode, and what happens if it arrives broken. Most stores answer those questions properly, on a shipping page, an FAQ, sometimes a dedicated cold-chain explainer they're clearly proud of. Almost none answer them in the one place machines read, the structured data on the product page. Five years ago that gap barely mattered. Now that Google folds shipping and returns information into merchant listings and AI agents read product markup when deciding what to recommend, it's a real hole. In fulfilment-sensitive categories it's the biggest one on the page.

The fields exist, and they're almost always empty

Shopify themes and the common SEO apps generally produce respectable Product and Offer markup: name, image, price, currency, availability. Across the stores we audit, it nearly always stops there. Two optional properties on the Offer carry the whole fulfilment story, and both are usually missing.

The first is shippingDetails, which points to an OfferShippingDetails object. Inside it: shippingRate, the cost as a MonetaryAmount; shippingDestination, a DefinedRegion, which for most Australian merchants is simply addressCountry set to AU; and deliveryTime, a ShippingDeliveryTime object that splits the wait into handlingTime (order to dispatch) and transitTime (dispatch to door). Each of those takes a minValue and maxValue in days. That structure lets you state, in a form software can parse: dispatched within one business day, delivered in two to four.

The second is hasMerchantReturnPolicy, pointing to a MerchantReturnPolicy. The fields that do the work are returnPolicyCategory (for most stores, MerchantReturnFiniteReturnWindow), merchantReturnDays, which is required when you use that finite-window category, returnMethod (ReturnByMail or ReturnInStore), returnFees and refundType. applicableCountry scopes the policy to the countries it covers.

None of this is exotic. The vocabulary has been in schema.org for years, and Google documents both types in its merchant listing guidance. But the fields are optional, so they don't ship by default, and nobody goes back to add them.

Why it matters most where fulfilment is the hesitation

For a store selling pantry staples, shipping markup is a nice-to-have. For a frozen range, transit time is the purchase decision. A two-day cold-chain window isn't logistics trivia, it's the product claim, and if it only exists as a sentence on a policy page then the systems comparing you to competitors can't see it. Oversized goods have the same shape: the unanswered freight question is a large part of why carts die at the shipping step, and a shippingRate in the markup is the earliest place in the journey the answer can appear. For fragile and perishable goods the return policy is the reassurance. A returnFees value that says the merchant pays is worth more than a paragraph of friendly copy the buyer never finds, because it can surface before the click, not after it.

There's a second audience now, and it's the one growing. When an AI shopping agent fields "frozen dog food delivered to Brisbane", the store whose markup carries a delivery window and a return policy hands the agent something concrete to repeat. The store whose shipping detail lives three clicks deep in an accordion hands it nothing. We've written before about whether an AI agent can actually buy from your store; this is the quieter version of the same problem. The information exists. It just isn't anywhere a machine looks.

"The information exists. It just isn't anywhere a machine looks."

One policy site-wide, overrides where it counts

Worth knowing before you brief a developer: Google now also accepts fulfilment policy at the organisation level. You can publish one site-wide shipping and returns policy, in Organization markup or through Search Console settings, and override it per product where reality differs. That's exactly the shape a mixed catalogue wants. The pantry line inherits the site default; the frozen line carries its own OfferShippingDetails with the shorter, stricter window; the oversized line carries its own freight rate. On Shopify the practical route is metafields feeding your theme's structured-data snippet, or a schema app that exposes the shipping and returns fields. Either way it's a contained piece of work, because the policies are already written. Someone did that thinking when they built the shipping page. This is transcription, not strategy.

"Someone did that thinking when they built the shipping page. This is transcription, not strategy."

Two cautions. The markup has to match what the page and policy actually say, because Google checks the visible content against the data, and a claimed two-to-four-day window against a shipping page saying five to seven is worse than no markup at all. And keep it maintained: when the courier contract changes or the summer cold-chain rules kick in, the structured data is now part of the policy surface you update, same as the shipping page itself.

Go and look at your own markup

Paste your best seller's URL into Google's Rich Results Test and expand the merchant listing result. Look for shipping details and has Merchant Return Policy under the Offer. Then open your own shipping page and count the answers written there: cost, dispatch time, transit time, return window, who pays return freight. Every answer that appears on the page but not in the data is the gap this piece is about. For most stores the count in the data is zero. If yours is one of them and fulfilment is the hesitation in your category, this is about the cheapest visibility fix available to you.