How to use this checklist
This is an implementation and release checklist for an ecommerce product feed. It is designed to answer: is the submitted catalogue complete, compliant, current and measurable? It is not a list of adjectives to add to titles.
Work from the source system outward: ecommerce or ERP data → feed transformation → Merchant Center processed product → Google Ads product membership → landing page. Keep an export before every material change so you can identify what the transformation altered and roll it back.
1. Record the feed contract
Before editing fields, document the data source, owner, update method, schedule, target countries, languages, marketing methods and override order. Merchant Center can combine uploaded files, platform integrations, supplemental sources, rules and manual edits. If the team does not know which source wins, fixes will be overwritten.
- Identify the system of record for price, availability, identifiers and variants.
- Record how quickly a source change reaches Merchant Center.
- List transformations and any manual overrides.
- Choose a rollback export and retain stable product IDs.
2. Check required and conditionally required fields
Use Google’s current product data specification for the actual market and product. Requirements vary. The common baseline includes ID, title, description, link, image link, availability and price; condition is required for used or refurbished products, while apparel, variants, multipacks and regulated categories add other conditions.
| Check | Failure example | Acceptance test |
|---|---|---|
| Stable ID | ID changes when title changes | Same sellable variant retains the same ID |
| Variant grouping | All sizes share one ID | Each variant has its own ID and common item group ID |
| Price and currency | Feed sends ex-VAT price | Submitted price matches the purchasable landing-page price |
| Availability | Parent marked in stock when selected size is sold out | Exact submitted variant can be purchased |
| Identifiers | Invented GTIN | Manufacturer-assigned identifiers submitted accurately |
Never invent a GTIN or reuse one from a similar product. If a product genuinely has no assigned unique product identifier, follow the specification for that product rather than filling the field with an internal SKU.
3. Verify titles, descriptions and taxonomy
The title is required and limited to 1–150 characters. Google may truncate it, so lead with the product identity and distinguishing attributes. Follow the title requirements: accurately describe the product, match the landing page, distinguish variants and avoid promotional text, excessive capitals and keyword stuffing.
For each major category, define a title order from real decision attributes. Example: Brand + product type + model + material/feature + colour + size. A valid hypothetical result is “Northstar Women’s Alpine Down Jacket, 700 Fill, Navy, UK 12”. Check that the selected landing-page variant is navy and UK 12.
Descriptions should contain product facts in natural language and match the page. Product type should use the retailer’s own hierarchy, such as Home > Lighting > Floor Lamps. Google product category uses Google’s taxonomy. They serve different purposes; do not replace one with the other.
Want the feed checked from source to ad?
Upscale audits product data, Merchant Center processing and campaign inclusion, then prioritises fixes by commercial impact.
Book My Free Ad Audit4. Check images
Confirm the primary image shows the submitted product and variant, uses a crawlable stable URL and has no prohibited promotional overlay. Inspect additional images for alternate angles and useful detail. Test image URLs without a logged-in session and confirm robots rules do not block Googlebot or Googlebot-Image.
Do not replace every image URL on each feed refresh; Google recommends stable image URLs and changing the URL when the image itself changes. Spot-check crops on mobile Shopping placements, where an otherwise good product can become indistinguishable against a busy background.
5. Synchronise price, stock and sale data
For a sample of fast-changing items, compare source, submitted value, processed value, visible landing-page value, structured data and checkout. The supported availability values include in_stock, out_of_stock, preorder and backorder; Google’s availability specification explains the corresponding page requirements.
If sale price is submitted, verify the shopper can actually buy at that price and that date handling is correct. Enable automatic item updates as a safeguard where appropriate, but increase source frequency when mismatches recur.
6. Check shipping, returns and landing pages
Reconcile shipping services with the countries and regions targeted by the feed. Test representative baskets: low-value item, bulky item, free-shipping threshold and remote postcode. The price and availability must remain consistent through checkout; the exact product must be purchasable without redirecting to a generic category page.
Use Google’s landing-page requirements as the baseline. Verify business contact information, return terms and payment methods are visible and functional. A technically valid feed cannot compensate for a product page that blocks the crawler or changes price by IP location.
7. Add commercial control fields
Use product type and custom labels to make the catalogue reportable. Labels are optional; they should represent decisions such as margin band, stock position, lifecycle or test cohort. Each of the five custom-label fields accepts one 1–100 character value per product, with up to 1,000 unique values per field account-wide.
Count products by each controlled value and reconcile to the source. Blank labels on 12% of the catalogue may be intentional, or they may show that the transformation failed for a category. Make the difference explicit.
8. Run pre-release QA
- Validate the file or API payload and compare total item count with the active catalogue.
- Diff changed fields by item ID; investigate unexpected mass changes.
- Inspect one processed product from every category and variant type.
- Confirm required destinations and countries are present.
- Review Needs attention after processing; download new issues.
- Confirm listing/product-group membership in Google Ads.
- Keep the previous working feed available for rollback.
Release during a monitored window, not immediately before a weekend or major promotion. Large title or taxonomy changes can affect matching even when products remain approved.
9. Measure the release
Use a change cohort. Record the affected item IDs and compare them with similar unchanged products where possible. Eligibility work should be measured by approved items, approved revenue coverage and recovered impressions. Title work should use item impressions, CTR and post-click quality. Identifier and taxonomy work may take longer and should be assessed across matching, coverage and conversion quality.
Hold bids, price and promotions stable when the goal is to isolate feed impact. If that is impossible, annotate the confounders. Report absolute volume alongside rates: a 30% CTR improvement on ten impressions is not a commercial result.
10. Validate a complete variant family
Choose a family with several colours and sizes. Confirm every sellable combination has a unique stable ID and that siblings share the correct item group ID. Compare each processed title, image, colour, size, price, availability and landing-page selection. Test an unavailable variant and a higher-priced variant rather than only the default option.
A common failure is parent-level availability: the feed marks all sizes in stock because one size can be purchased. Another is a landing page that always opens the cheapest variant while the submitted item represents a more expensive size. Both can create a poor experience and mismatch risk.
11. Check failure modes after processing
| Observed result | Likely cause | Next check |
|---|---|---|
| Item count falls sharply | Source filter, parse error or deleted IDs | Diff source and previous successful submission |
| Products approved but lose impressions | Title/taxonomy change, campaign membership or demand | Processed values and item-level inclusion |
| Manual correction disappears | Primary source overwrites it | Source precedence and transformation owner |
| Price issues recur | Feed latency or variant/structured-data mismatch | Timestamp each system and test exact offer |
| Labels do not appear in groups | Processing delay, spelling variant or unique-value breach | Processed label and account vocabulary |
12. Create an acceptance report
The release is accepted only when the source processed successfully, active item count reconciles, high-priority products are eligible, sampled values match the page, campaign groups contain the intended IDs and no material new issue family appears. Record exceptions and owners rather than silently accepting them.
For a hypothetical 5,000-item title release, the report might show: 4,986 active items expected and processed; 14 intentionally excluded; 120 title changes sampled across 12 categories; no ID changes; two punctuation defects rolled back; eligibility stable at 98.7%; and a 600-item measurement cohort retained for 28 days.
Use the product-title guide for category formulas and the disapproval guide when the release creates product-status issues.
Archive the acceptance report with the source file or API version, rule configuration and Merchant Center issue export. If performance moves six weeks later, the team should be able to reconstruct exactly which product values changed. For recurring releases, automate item-count reconciliation, ID churn, blank critical fields, unexpected label values and high-priority approval coverage.
A failed acceptance check should have a predetermined response. Stop and roll back when IDs change unexpectedly, offer data is inaccurate or material products lose eligibility. Log and continue only for understood low-impact exceptions with owners and deadlines. This prevents launch pressure from turning known feed defects into permanent production data.