The shipping policy page Merchant Center expects and mo...

The Mega Analyzer row reads Shipping Policy (for physical-goods sellers), and it sits in the Trust + Conversion completeness card under the sub-heading "Product- / service-specific legal pages (flagged per detected type)". What it is really asking is simpler than the title: does the page you are auditing link to a shipping policy at all? Not whether the policy is any good, not whether it agrees with your Merchant Center settings, only whether a buyer standing on this page can find one. On the small stores I audit the answer is usually no. The terms live in a checkout step that the buyer, Google's reviewers and every crawler reach late or never.

What the check actually tests

Two inputs, one boolean.

The first input is the link scan. The analyzer fetches the page's HTML and parses it with a DOM parser (no scripts run), collects the raw href attribute of every <a> that has one, and tests each one against a case-insensitive pattern that wants a slash, then a segment spelled exactly shipping, shipping-policy or delivery, then either another slash or the end of the string. /shipping/, /pages/shipping, /help/delivery/ and Shopify's default /policies/shipping-policy all match. So does an external link, since the pattern runs against the whole href string and never checks the host: a footer link to a carrier's /shipping/ page passes this row just as well as your own. What does not match is the more useful list. /shipping-info, /shipping-and-returns, /shipping.html, /faq#shipping and /shipping?ref=footer all fail, because the segment is followed by something other than a slash or nothing. A footer rendered by client-side JavaScript fails too, since the parser never runs it.

The second input is the type walk. Every <script type="application/ld+json"> block is parsed and every @type at any depth is collected, so a Product nested inside an ItemList counts the same as one at the root. If any collected type contains Product, matched case-insensitively (so ProductGroup, ProductModel and IndividualProduct qualify), the gate is open. Microdata and RDFa are not read, so a store whose only product markup is an itemtype attribute never opens the gate.

The row shows as met when the link scan finds a match or the gate stays closed. That second half matters: a page with no Product JSON-LD at all gets a green check whether or not a shipping page exists. The green means "not applicable," not "found." The row shows as unmet only when Product schema is present and no matching link exists, and then the detail reads: "Physical-goods sites need a shipping policy covering timing, carriers, international, and lost-package process. Google Merchant Center requires it to approve listings."

Two things the detector does not do. It does not fetch the linked page, so a /shipping/ that returns a 404 or says "coming soon" passes. And it does not tell physical goods from digital ones, despite the title. An ebook store with Product schema and no shipping link sees the blue row, and the honest response there is to ignore it (more on that below). The judgment about physical versus digital lives in the Product schema section instead, where the shippingDetails on offers (physical goods only) row fires only when a Product carries a physical signal (a gtin, mpn, isbn, productID or itemCondition, dimensions, a physical category, or a product-page URL shape with a priced offer) and neither its ancestors nor any other type on the page falls in the Service, LocalBusiness, Store or OfferCatalog family.

Severity is info. The unmet state is a blue marker, not a red one, and in the cross-tab rollup it is filed under the collapsible "Info / optional signals" section rather than counted as an issue. It moves no score. That is the analyzer being polite about a row that, for a physical-goods store, is closer to a listing requirement than to an optional signal, which is why it gets its own article.

Why it matters

Google's Shopping ads policies, the set that governs Merchant Center, include a Misrepresentation policy, and its list of practices that are not allowed names "Missing merchant terms and conditions or shipping information" and "Failure to clearly and noticeably disclose all related conditions before and after purchase." The consequences on the same page are not subtle: products that don't comply "may be disapproved and won't be eligible to serve," and accounts can be "suspended upon detection and without prior warning." The shipping attribute documentation adds the practical version of the rule: submit complete and correct shipping information including speed and cost, match or overestimate what the buyer will pay, and if you skip a region you ship to, "your product or account could be disapproved." A store with Product schema and no visible shipping terms is arguing with that list, not with a nicety.

In the US there is also a rule that predates the web. The FTC's Mail, Internet, or Telephone Order Merchandise Rule (16 CFR Part 435) makes it an unfair or deceptive practice to solicit an order unless the seller has "a reasonable basis to expect that it will be able to ship any ordered merchandise to the buyer" within the time it stated, or "within thirty (30) days after receipt of a properly completed order" when no time was stated (fifty days if the buyer applied to the seller for credit). When the seller cannot meet that, it must offer the buyer, "clearly and conspicuously and without prior demand, an option either to consent to a delay in shipping or to cancel the buyer's order and receive a prompt refund." A prompt refund means within seven working days (one billing cycle when the seller is itself the creditor). The rule does not say you must publish a shipping page. It says that every delivery promise you make, on the page or by staying silent, has a clock attached, and the page is where you decide what you are promising.

Selling into the EU adds a pre-contract disclosure. Directive 2011/83/EU Article 6(1) requires the trader to give the consumer, "before the consumer is bound by a distance or off-premises contract," the total price with "all additional freight, delivery or postal charges," "the arrangements for payment, delivery, performance, the time by which the trader undertakes to deliver the goods," and whether the consumer bears the cost of returning goods on withdrawal. Article 18 sets a default delivery deadline of "not later than 30 days from the conclusion of the contract" unless the parties agree otherwise. A shipping page linked from the product page is the ordinary way a small store meets the "before" part.

Then there is the buyer. Google's own shipping documentation states that "Shipping speed and cost are the most common reasons for abandoned orders by users." A shipping cost that appears for the first time at the payment step is exactly that surprise.

The machine readers are newer. Google's merchant listing structured data has a recommended shippingDetails property on Offer, and Google now documents an organization-level hasShippingService policy with a stated precedence order: Content API account settings first, then Merchant Center or Search Console settings, then product-level markup, then organization-level markup. OpenAI's product feed spec carries optional shipping_price and shipping fields (the second a country:region:service_class:price tuple), and UCP's checkout and order-management capabilities cover status updates, shipment tracking and returns. Each of those is a place a program reads your shipping terms as data. The human page is where a buyer, a reviewer or an agent verifies that the data was true, and when the page and the data disagree you have not published a policy, you have published a contradiction.

How to fix it

1. Write the page. Publish it at /shipping/ or /shipping-policy/, server-rendered, and cover these in this order: processing time in business days and the order cutoff; carriers and service levels; domestic rates or the free-shipping threshold; delivery estimates by region; whether you ship internationally, and who pays duties and taxes when you do; tracking and how it is sent; address changes and the point after which they are no longer possible; the lost, damaged or stolen package process with a contact and a response window; and a last-updated date. Two sentences are enough for most of these. What the FTC clock cares about is that the processing and transit times are ones you can actually hit.

2. Link it where the buyer is. The footer gets it found; the product page, near the price, gets it read; the checkout page puts it in front of the person at the moment the cost appears. Use a plain anchor so the detector, and every other crawler, sees it in the served HTML:

<a href="/shipping/">Shipping policy</a>

3. Mirror the terms in structured data. Google recommends a global policy on the Organization node with per-offer overrides only where a product differs. The per-offer shape, which the Merchant Listings Audit checks for, nests inside each Offer:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Example product",
  "sku": "EX-100",
  "offers": {
    "@type": "Offer",
    "price": "49.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "shippingRate": {
        "@type": "MonetaryAmount",
        "value": "5.99",
        "currency": "USD"
      },
      "shippingDestination": {
        "@type": "DefinedRegion",
        "addressCountry": "US"
      },
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": {
          "@type": "QuantitativeValue",
          "minValue": 1,
          "maxValue": 2,
          "unitCode": "DAY"
        },
        "transitTime": {
          "@type": "QuantitativeValue",
          "minValue": 3,
          "maxValue": 5,
          "unitCode": "DAY"
        }
      }
    }
  }
}

The numbers here have to be the numbers on the page, and both have to be the numbers in Merchant Center, because Merchant Center settings outrank the markup in Google's precedence order, and a shopper who sees one figure in the listing and another at checkout is the case the Misrepresentation policy describes. If you ship free above a threshold, Google's organization-level shape expresses it as a ShippingConditions node with an orderValue range and a shippingRate of 0. At the offer level there is no documented threshold field, so state the threshold in the page copy. schema.org does define freeShippingThreshold on ShippingRateSettings, reachable through shippingSettingsLink, but Google's documentation does not mention it.

4. Draft, then audit. Legal Pages Generator with "E-commerce, physical goods" selected emits the Refund / Return Policy for the same store from the same business name, address, contact and jurisdiction inputs. It does not currently emit a standalone shipping policy, so use those same inputs and the section list in step 1 to write the shipping page, and keep the two documents consistent on who pays return postage. Then run Legal Pages Audit: it probes for the refund and return page and reports whether that page mentions shipping or restocking fees at all. It does not compare the two documents, so the consistency read is yours. Finally re-run the Mega Analyzer on a product page. The row turns green the moment a matching link is in the served HTML.

When to leave it alone

Digital goods. If everything you sell is a download, a license or a course, there is nothing to ship, and the row is blue only because the detector cannot tell. Do not write a shipping page that says "we don't ship"; the refund page is where digital delivery terms belong. Leave it blue.

Product schema on a page that does not sell. A service business that models its offerings as Product nodes inside an OfferCatalog, a review site with Product markup on an item it does not stock, a blog post with a nested Product in a comparison table: none of these ship anything. The shippingDetails row in the Product section skips the OfferCatalog case outright, and the other two as long as the Product node carries none of the physical signals. This row cannot, so read the blue as noise.

Local pickup only. A bakery or a plant nursery with Product schema and no delivery has terms, but they are pickup terms. A short /pickup/ page is the right document, and it will not satisfy the pattern. Name it /delivery/ only if you actually deliver.

And one case in the other direction. If your store already has a shipping page at /shipping-and-returns/ linked from every product, you have what this row wants and the pattern misses the spelling. The fix is a second link at /shipping/ (an alias or a redirect), not a second policy. Change the canonical URL only if a redirect from the old one is part of the change.

Fact-check notes and sources

Source: https://support.google.com/merchants/answer/6149970 establishes the Shopping ads policies (Google Merchant Center Help), the parent policy set for Merchant Center that includes the Misrepresentation policy.
Source: https://support.google.com/merchants/answer/6150127 establishes the Misrepresentation policy text: "Missing merchant terms and conditions or shipping information" and "Failure to clearly and noticeably disclose all related conditions before and after purchase" as prohibited practices, product disapproval, and account suspension "upon detection and without prior warning."
Source: https://support.google.com/merchants/answer/6324484 establishes the shipping attribute guidance ("Submit complete and correct shipping information, including speed and costs," "Match or overestimate the cost users would pay," disapproval when a shipped-to region has no cost) and the statement "Shipping speed and cost are the most common reasons for abandoned orders by users."
Source: https://www.ftc.gov/legal-library/browse/rules/mail-internet-or-telephone-order-merchandise-rule establishes the FTC's summary of the Mail, Internet, or Telephone Order Merchandise Rule (16 CFR Part 435).
Source: https://www.ecfr.gov/current/title-16/chapter-I/subchapter-D/part-435 establishes the rule text: the reasonable-basis requirement, the thirty-day default and the fifty-day credit case in § 435.2(a), the delay notice and consent-or-cancel option in § 435.2(b), and "prompt refund" (seven working days, or one billing cycle where the seller is the creditor) in § 435.1.
Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011L0083 establishes Directive 2011/83/EU Article 6(1)(e), (g) and (i), the pre-contract information on delivery charges, delivery arrangements and time, and return costs, and Article 18(1), delivery not later than 30 days from the conclusion of the contract unless agreed otherwise.
Source: https://schema.org/OfferShippingDetails establishes the type ("information about shipping destinations") and its properties, including shippingRate, shippingDestination, deliveryTime, doesNotShip and shippingSettingsLink, and that Offer.shippingDetails takes it as a value.
Source: https://schema.org/ShippingRateSettings establishes freeShippingThreshold ("A monetary value above (or at) which the shipping rate becomes free") and that the type is reached through shippingSettingsLink on OfferShippingDetails.
Source: https://developers.google.com/search/docs/appearance/structured-data/merchant-listing establishes shippingDetails as a recommended Offer property in merchant listing structured data and Google's recommendation to declare a global policy under Organization first.
Source: https://developers.google.com/search/docs/appearance/structured-data/shipping-policy establishes the precedence order (Content API account settings, Merchant Center or Search Console settings, product-level markup, organization-level markup), the DAY (or d) unit code for handling and transit time, the ShippingConditions plus orderValue shape for free shipping above an order value, and continued support for OfferShippingDetails under Offer.
Source: https://developers.openai.com/commerce/specs/feed establishes the shipping_price and shipping (country:region:service_class:price) fields in the OpenAI product feed specification.
Source: https://ucp.dev/ establishes the Universal Commerce Protocol's core capabilities (catalog, cart, identity, checkout, order management) and its order-stage webhooks for status updates, shipment tracking and return processing.

The shipping policy page Merchant Center expects and most small stores never publish