Google Ads guide

Google Shopping Feed Optimization Checklist for Online Stores

Use this Google Shopping feed optimization checklist for an online store before activating a product source or diagnosing a variant issue. The pass condition is that the exact sellable item survives from catalog source through export, processed feed, selected landing page, and checkout: stable keys, option values, image, price, availability, market, shipping, and page state all agree. A connector sync or clean processing result alone is not proof.

This page is educational and does not promise Google approval, traffic, conversion, or a particular ecommerce-platform feature. Start with Google’s product-data guidance, then involve catalog, platform, export or channel, inventory, pricing, fulfillment, market, and compliance owners. Related setup is in how to optimize a Google Shopping feed for online stores and best Google Shopping feed settings for online stores.

1. Confirm account and source scope

Record account, domain, country or region, language, currency, channel or export method, destination, online or local program, product population, source type, schedule, version, freshness, reviewer, and rollback. State whether the source is a native channel, app, API, custom feed, supplemental source, or combination.

Name owners for product and variant identity, options, titles, images, structured data, inventory, pricing, fulfillment, market values, page behavior, and regulated or claim wording. A reviewer should be able to reproduce which account, market, export boundary, and product population the checklist covered. Freeze the source snapshot or record its timestamp before comparing values; otherwise a changing catalog can make an apparent mismatch impossible to reproduce.

2. Verify product and variant identity

For representative rows, confirm:

  • stable product ID, variant ID, parent relation, SKU, identifier, handle, and URL;
  • brand, product name, product type, category, title, description, and option values;
  • variant image, size, color, material, flavor, pack, weight, capacity, model, or compatibility;
  • price, sale state, currency, availability, quantity, shipping, market, and destination;
  • selected page option, structured data, add-to-cart, subscription, and checkout.

Do not let a parent handle or title stand in for a material variant distinction. A default page child can differ from the submitted row even when the product URL and export look correct. Record the family key and sellable child key separately so a later packaging, option, or inventory change does not silently create a new offer or overwrite an existing one.

Test the selected variant

Open default and non-default options on desktop and mobile. Confirm that product and variant keys, title, image, price, stock, structured data, shipping, and checkout describe the same child after selection and reload. Preserve the exact URL or selection state used in the test; “the product page works” is too broad to prove that the submitted variant works.

3. Review titles, categories, and source fields

Read the title for brand, product name or type, model, material or key attribute, variant option, size or quantity, and other facts that distinguish the offer. Use Shopping feed title optimization for order and clarity, but keep SKU, collection, campaign, audience, routine, and temporary promotion separate from product identity.

Check that product type and Google product category match the item actually sold; product and variant fields are mapped to the right level; and images, option values, dimensions, ingredients, materials, compatibility, and included quantity are supported. Price, sale state, currency, inventory, shipping, and market values should have named sources and timestamps. Claims, certifications, health, safety, or regulated wording need an appropriate review path.

Do not infer a value from a tag, collection, metafield, app label, or parent description when the variant or page source does not support it. Keep original and normalized values visible so a reviewer can tell whether the feed changed a source value or merely copied it.

Check the export boundary

Compare catalog source, app or channel export, processed feed, and rendered page. Record changed, rejected, unmatched, and unchanged values. A sync confirmation is an export result, not proof that the rendered page selects the intended variant. When a transformation changes a title, URL, category, image, price, or availability, retain the before and after values and the rule that caused the change.

4. Match images, structured data, and online-store pages

Confirm that the main image represents the exact child when color, material, size, pack, or configuration changes the offer. Add supporting images for package quantity, dimensions, included components, compatibility, or labels. Lifestyle imagery is context, not a substitute for product evidence. If the store intentionally uses a family image, document why that image still represents the submitted child.

For each row compare:

  1. product ID, variant ID, handle, URL, and selected option;
  2. title, description, product type, category, image, and structured product data;
  3. size, color, material, pack, quantity, ingredients, compatibility, and included items;
  4. price, sale state, currency, availability, shipping, and delivery context;
  5. add-to-cart, subscription, inventory, and checkout behavior.

Test default and non-default variants on mobile, reload the URL, and inspect the rendered page rather than only the export. Confirm that image, title, structured data, price, stock, and checkout change together. A page that displays the right title but submits a different child is still a failed row.

5. Verify price, inventory, and lifecycle

Compare price, sale price, currency, condition, quantity, availability, handling, and delivery with authoritative store and fulfillment sources and record timestamps. Use Google’s availability guidance for in stock, out of stock, preorder, and backorder. A warehouse, supplier, or inventory-location state is not automatically an online offer in the selected market.

Test new product, new variant, packaging change, price change, sale period, seasonal item, subscription, refill, bundle, preorder, backorder, discontinued variant, out-of-stock child, local-only inventory, and unchanged control. Preserve stable product and variant IDs and record content changes. Check whether the page sells one unit, case, pair, bundle, refill, or subscription; quantity and cadence can change the meaning of price and availability.

Do not mark every variant available because one location has stock. If an item should not appear in a destination, use the approved product or destination process rather than a false availability value. When the store changes price or stock during a test, record both timestamps and rerun the page comparison instead of treating the first export as current evidence.

6. Check market, shipping, and localization

Record target country or region, language, currency, unit system, domain or market context, shipping service, handling time, tax or delivery context, pickup, and exclusions. An online store can have different inventory, price, translation, and delivery by market. Test at least one market boundary when the catalog is international; a globally successful row can still be wrong for a specific destination.

Review localized product and option wording, ingredients, materials, claims, sizes, units, pricing, availability, returns or delivery language, and structured data. Do not copy global tags, certifications, health, safety, or shipping promises into every market without evidence. Separate online, local, warehouse, and tester inventory, and keep the market that was actually tested beside every exception.

7. Audit transformations, rules, and diagnostics

Document the primary catalog, export or channel, app or API transformation, supplemental source, inventory source, pricing source, fulfillment source, market source, and page source. Include matching key, target field, condition, precedence, market, language, version, effective period, freshness, and rollback. Product feed rules may normalize approved values, but they must not invent product identity, variant options, ingredients, compatibility, price, inventory, shipping, or claims.

Retain original, transformed, processed, and rendered values for changed, rejected, unmatched, and unchanged rows. Route product and variant identity and option issues to catalog; claims, ingredients, or regulated wording to the responsible reviewer; stock to inventory; price to pricing; delivery to fulfillment; export, selector, or structured-data problems to commerce; and account issues to the Merchant Center owner. Use Merchant Center diagnostics to locate issues, then reproduce the selected-market page path.

An actionable alert identifies product ID, variant ID, market, source timestamp, issue reference, observed export and page values, and permitted next action. “Processed successfully” does not prove that the submitted option, image, price, or availability is what the shopper can purchase. Keep the failed evidence attached to the row until the owner closes the exception.

8. Run a representative test matrix

Select products with one variant, many variants, size and color options, material or flavor options, pack or quantity options, bundles, subscriptions, refills, accessories, replacement parts, and market-specific offers. Include products whose default page option differs from the submitted child. Vary price, sale state, inventory location, language, currency, image, and shipping.

Include new product, new variant, package change, price change, sale period, seasonal item, subscription, refill, bundle, preorder, backorder, discontinued variant, out-of-stock child, local-only inventory, and unchanged control. Compare source product and variant, export, processed feed, selected page, image, title, options, structured data, price, availability, shipping, add-to-cart, and checkout. Retain changed, rejected, unmatched, and unchanged results; all-success testing cannot demonstrate exception handling.

Test the deciding store field

For size or color, verify option value, image, price, and URL. For a bundle or pack, verify included quantity. For a subscription, verify cadence and recurring offer. For a market, verify currency, language, inventory, delivery, and structured data. For an app or API transformation, verify the rendered page, not only the export result.

Common online-store checklist failures

Do not count these as optimization:

  • one parent product row represents every variant offer;
  • handle, collection, SKU, or title is used instead of a stable variant key;
  • a material size, color, material, flavor, pack, compatibility, or subscription option is hidden in the parent;
  • the default page variant differs from the submitted child;
  • one image, price, inventory, or shipping value is applied to every variant without evidence;
  • every child is marked available because one location or supplier has stock;
  • tags, metafields, claims, ingredients, certifications, or market values are copied into every product;
  • an app export, channel sync, or processing confirmation is treated as proof of page and checkout correctness;
  • a shared transformation is changed without reviewing the affected product and variant population.

Final online-store sign-off

The checklist is complete when product and variant keys are stable; titles, categories, options, images, structured data, price, inventory, market, shipping, and page state agree; export transformations are traceable; and sources, rules, diagnostics, ownership, freshness, review, and rollback are documented.

Hold a row when the variant key, option, page state, quantity, price, inventory, market, or delivery cannot be proven. A trustworthy online-store feed preserves the actual catalog semantics from source to selected page without making a connector appear more authoritative than the rendered customer path. Record the evidence, owner, next action, and retest condition for every held row before activation.