How to Audit Merchant Center Shipping Settings

Export or record every active shipping policy with its country, currency, products, shipping labels, source, delivery-time method, cost method, status, visibility, last update, and owner. Add the product-data fields that can affect the result, including shipping label, shipping weight, dimensions, and any offer-level shipping attribute. The first goal is lineage: for a given product and destination, which configuration is supposed to win? Without that map, a manual edit can appear correct in one screen while an API or product feed replaces it later.

Google explains that Merchant Center supports account shipping settings, product-level shipping data, and API-managed configurations. It also notes that product-level shipping price and delivery-time values can override account settings when the required price sub-attribute is present, and automated API updates can overwrite manual Merchant Center edits. Mark each policy as console-managed, feed-managed, platform-managed, or API-managed. If ownership is unclear, freeze the edit and identify the upstream system before changing the visible row.

Segment the catalog by the conditions that actually change shipping: destination country or region, warehouse, product size or weight, service level, free-shipping threshold, restricted destination, and any required shipping label. Confirm that every in-scope product is attached to at least one applicable policy and that exclusions are intentional. Do not compare rates until scope matches. A correct flat rate on the wrong product group is still a configuration defect, and a complete policy for one country does not cover a second country merely because the same products are sold there.

Google says shipping labels can associate shipping information with specific product groups, while weight and dimension attributes are needed for weight-based or carrier-calculated costs. It also documents country-specific behavior and separate policy choices for all products or selected labels. Build a matrix with one row per representative segment. Include a normal parcel, an oversized or heavy product when applicable, a free-shipping threshold case, a destination exclusion, and each active warehouse or region. The matrix should show expected policy, expected charge method, expected delivery method, and the source field that selects it.

For each matrix row, test the product page and checkout using the same destination used in Merchant Center. Record the store's shipping charge, service name, handling promise, transit promise, cutoff, business days, free-shipping threshold, and destination restrictions. Then compare those values with the Merchant Center policy. Use a timestamp and screenshot or export reference because checkout logic and carrier rates can change. If the store cannot produce a stable charge until late in checkout, document the limitation instead of inventing a precise value upstream.

Google instructs merchants to keep submitted shipping costs close to the online store and says slightly overestimating is preferable when an exact match is unavailable. It also separates handling time from transit time and allows manual or carrier-based speed methods. Treat cost and speed as two audits. A policy can show the right charge but an impossible arrival range, or the right delivery time with an incomplete surcharge. Include handling, delivery, processing, logistics, or carrier charges that the customer pays, while keeping taxes and government fees in their proper systems.

When a test fails, use a precedence worksheet instead of editing every available surface. Record product ID, destination, expected result, observed Merchant Center result, store result, applicable account policy, product-level shipping value, shipping label, upstream API or platform owner, and last update. Then identify the narrowest conflicting source. For example, an account policy may correctly cover the catalog while one product-level override supplies an older charge for a subset. The fix belongs in that override or its upstream feed, not in a second account policy that masks the conflict.

Merchant Center's shipping policy table shows policy source, country, delivery source, cost method, product count, status, and visibility. Google notes that advanced API-managed policies may not be editable in the interface and must be changed through the Merchant API. Use those fields to route the issue to the owning system. Do not convert an API-managed row to a manual workaround merely because the interface exposes a nearby edit button. Preserve the previous payload or policy export, make one source change, and wait for the documented surface to refresh before judging the result.

Test the proposed change on the smallest product or policy scope the current setup permits. Preserve the original policy, feed row, or API payload; record the owner, change time, affected products, destinations, and rollback value; then rerun every representative destination in the matrix. Verify Merchant Center status and visibility as well as the store checkout. A policy marked complete is useful evidence, but it does not prove every product and destination receives the intended result. Keep the change pending until the affected examples agree across source, policy table, and storefront.

Close the audit with counts by disposition: matched, missing scope, precedence conflict, cost mismatch, speed mismatch, hidden policy, API-owned change required, and insufficient evidence. Assign each open row to the system that owns it. Recheck after feed or API refresh and keep the original test matrix for regression use. If a rollback is needed, restore the explicit prior configuration rather than creating another overlay. The practical outcome is a shipping promise that can be traced from product and destination through Merchant Center to the charge and delivery range a customer sees.