Wealth · Merchant Center Dropshipping Guide

Article 2 of 5

Prepare Product Pages, Policies, and Contact Information for Merchant Center

Audit a dropship store's product pages, checkout, shipping and return policies, and support details before submitting products to Google.

Merchant Center can read a feed only as well as a shopper can use the store behind it. A feed may say an item is available for $29, while the landing page defaults to a different variant, checkout adds an unexpected fee, and the footer contains an unworkable return policy. That mismatch is a customer problem before it becomes a diagnostic.

Make the product page, checkout, store identity, shipping terms, and return process tell the same story. Test them as a buyer in the target country, on mobile as well as desktop. For a dropship store, verify that the supplier can support each promise before publishing it.

This is part two of the Merchant Center Dropshipping Guide. Start with eligibility for dropship stores. The next part will map this store experience into product data attributes. The AliExpress listing guide gives additional help with claims and variant evidence.

Audit one complete purchase path

Select a real, vetted product and a supported destination. Open its page without logging in. Choose the exact variant, add it to cart, proceed to checkout, view the final amount and delivery terms, and complete a test purchase if possible. Note every change in product name, image, price, availability, shipping cost, tax, and estimated date.

The product landing page should be usable without a popup that blocks the item or a requirement to create an account just to see the price. Google’s landing-page and store URL requirements expect a direct purchase path on the merchant’s site. If clicking the product sends the buyer to another retailer or AliExpress checkout, the page is not functioning as the store offer you submitted.

Do the same walk-through from a phone-sized screen. A return-policy link that is visible on desktop but hidden behind a broken mobile menu is not meaningfully accessible. Test with a normal browser session, including a private window, because a merchant’s logged-in view can hide errors seen by new shoppers.

Make the product page specific

The page should identify the exact item, variant, quantity, dimensions, material and included accessories as supported by your sample and records. Show current price and availability near the purchase control. Use images of the actual approved product or imagery you have permission to use and have checked against a sample. Do not make a blanket compatibility, safety, or material claim that the supplier has not substantiated.

If one page contains several variants, ensure the selected variant changes the visible image, price, and availability where those facts differ. A feed item for a blue medium bag should not land on a red small bag with a different price. If the buyer cannot select the advertised option, remove that feed item or fix the page. Avoid preselecting a cheaper variant merely so the feed price appears on the first view while the advertised variant costs more.

Keep the URL stable and accessible. Google’s editorial and professional requirements identify unavailable pages, broken links, and placeholder content as issues. A product page should return a valid response, load essential content, and remain reachable after a feed update. When an item is permanently discontinued, follow the store and feed’s removal process rather than leaving a dead link in Google.

Check price, checkout, and payment

The advertised price should match the product page and checkout for the target shopper. Currency, promotions, minimum-order conditions, and mandatory add-ons all affect that match. If a discount needs a code or membership, represent it according to the current product data rules instead of submitting a lower price available only to a subset of buyers.

Google’s checkout requirements emphasize consistency between product data, landing page, and checkout. Inspect the cart total before the buyer enters payment information. Shipping and taxes can vary by destination, but their nature and amount should be presented according to the applicable program and local requirements. A checkout that cannot calculate a supported address is not ready to advertise to that address.

Use a conventional secure payment method. Complete a test payment or a documented checkout test so you know whether the order confirmation, payment statement, and fulfillment record agree. The customer should know which business charged them. If a third-party fulfillment service is used, it should not replace the merchant identity in the buying experience.

Write a delivery policy that matches operations

State which places you serve, what processing time means, the delivery methods or estimated windows, shipping charges, and any relevant customs or border-charge terms. Separate supplier processing from carrier transit. A supplier’s display estimate for one route cannot support a universal promise across all destinations.

Configure Merchant Center shipping settings to match the real store offer. Google’s shipping and return configuration guidance emphasizes consistency between the account and website. If a product needs a different shipping cost or service window, use a supported product-level or service setting rather than letting the account’s default understate the actual charge.

Choose a promise with evidence from supplier tests and recent fulfillment, then monitor it. A shipping-policy page written once can become stale after a supplier changes routes. Update the policy and Merchant Center together. If a target country cannot be served reliably, stop targeting it until the fulfillment path is fixed.

For U.S. online orders, the FTC’s shipment-timing guide describes requirements for reasonable shipment promises and handling delays and refunds. Google policy and consumer law are separate obligations. A feed approval does not make an unsupported shipping promise lawful or workable.

Make the return and refund policy executable

Publish a dedicated policy page that anyone can open without signing in. State the return window, qualifying conditions, how to start a return, return method and address or process, who pays return shipping, fees, refund timing, and how wrong or damaged items are handled. Your supplier’s dispute window is not automatically the customer’s policy. The buyer bought from your store.

Google’s return-policy setup guidance asks for clear, conspicuous information that matches between Merchant Center and the website. It also says the policy should cover general cases, not only defective goods, and be accessible without login or personal-information entry. If you do not accept a type of return where that is allowed, state it clearly and check the current legal and platform rules for the destination.

Test the policy against a real case: a $20 item arrives broken from an overseas supplier. Can the customer understand whether they must send it back, to whom, at whose cost, and when they receive a refund? Can your support team perform the steps? A policy that requires a $30 international return for a low-value item may be economically and practically unworkable even if the page is grammatically complete.

Link the policy from the footer, product page or checkout where it informs the purchase, and order confirmation. Check that the link works on mobile. If you update terms, ensure old orders are handled under the terms applicable when they were placed and preserve a dated record.

Show a verifiable business and support path

Customers need a reliable way to ask about an order. Show the business name, contact method, response expectation, and other business information required for your market. Google’s business information guidance asks merchants to provide basic, verifiable information, while its editorial requirements identify missing or contradictory contact details as a problem.

Test the email address or form. Send a message from an account you do not use for administration and confirm it arrives, receives an acknowledgment if promised, and can be answered. A phone number printed on the site but never staffed can be worse than a working email address with a clear response time. Use consistent business identity on the site, in Merchant Center, on receipts, and in customer support.

Do not copy a supplier’s office address or company name into your store’s contact page to appear more established. Be accurate about who is selling. If the product ships from another country, do not imply local inventory merely because your business is local. Google’s misrepresentation policy addresses hidden or false information about a business or offer.

Check trust details without inventing authority

A clear About page, accessible policies, consistent branding, and functioning support help buyers evaluate the store. Trust should come from real information. Do not use fake reviews, invented certifications, unsupported “official dealer” badges, or a false countdown. Verify any award or association before displaying it.

Avoid copied supplier text that describes features your variant lacks. Original, sample-based descriptions are more useful for a buyer and for search systems trying to identify the product. Provide concise answers to practical questions: what arrives, how it differs from alternatives, what it fits, what it costs to receive, and what happens if it is wrong. That supports both ordinary search and answer-oriented discovery.

Check accessibility basics: descriptive link text, image alt text for meaningful product images, form labels, visible focus, and readable policy text. A buyer should be able to complete the purchase and locate support without relying on a particular device or perfect vision. These checks also catch hidden UI problems before feed submission.

Use a publication checklist

Before adding a product to Merchant Center, verify:

  1. The exact variant is purchasable on the submitted URL.
  2. The product, images, material claims, and included items match the approved sample.
  3. Price, currency, availability, and any sale terms match checkout.
  4. Shipping cost, destinations, processing, and delivery estimates are supported.
  5. Return and refund policy is public, specific, and executable.
  6. Business identity and contact method work and match the account.
  7. Mobile purchase and customer-support paths work without a login wall.

Record the date and tester. Recheck after a supplier change, store redesign, policy edit, or diagnostic. The next article converts this verified store offer into product data that Google can read without contradicting the page a buyer sees.