Google Merchant Center feed audit checklist

1Freeze the evidence before editing

Keep the original export unchanged. Record the export time, source system, target country and language, currency, feed format, and the Merchant Center message exactly as shown. Work on a copy whose checksum or file size is recorded.

This prevents a common failure: correcting one symptom while losing the input needed to prove what changed.

2Validate the file before validating products

First establish that the data can be parsed deterministically. For CSV/TSV, check encoding, delimiter, quoting, headers and row width. For XML, check well-formedness, namespace use and whether every item closes correctly.

CSV preflight
[ ] UTF-8 decoding succeeds
[ ] delimiter is consistent
[ ] every row has the same logical field count
[ ] headers are unique after trimming
[ ] no accidental spreadsheet formula or hidden newline splits a field
[ ] item count before and after parsing matches

Do not “repair” malformed quoting by silently dropping rows. Emit the row number and a safe excerpt, then stop or quarantine the row.

3Check required and conditionally required attributes

Evaluate requirements against the actual destination and product type, not a generic column list. Google’s product data specification is the primary reference for attribute rules and supported values.[10]

A blank value, an invalid value and an inapplicable attribute are three different states. Keep them distinct in the report.

4Test identifiers without inventing them

Normalize surrounding whitespace, then test uniqueness and format. Duplicate IDs are defects even when titles differ. GTINs should be validated structurally and against the product; a syntactically valid number can still belong to another item.[10]

• If the manufacturer assigned a GTIN, submit the correct GTIN.
• If no GTIN exists, do not create one to make a warning disappear.
• Treat identifier_exists as a factual claim, not a suppression switch.
• For variants, keep a stable item ID per variant and a shared grouping value only where appropriate.

5Compare price and availability across surfaces

For each sampled item, compare the feed with the public landing page at the same time and for the same country, currency and variant. Google requires submitted price and availability to match the corresponding landing-page and checkout information.[11][12] When present, compare visible content and structured data too. Record redirects and the final URL.

Before changing the feed, determine which surface is authoritative and whether a scheduled export, storefront cache, currency conversion or variant-selection rule explains the gap.

6Inspect links, redirects and images

Google requires the submitted product URL to use the verified domain, remain crawlable, and work on desktop and mobile.[13]

• Resolve every sampled product URL and record status, redirect chain and final canonical URL.
• Confirm that the landing page represents the same product and variant as the row.
• Check mobile rendering and whether essential price/availability content exists without an interaction that a crawler cannot reproduce.
• Confirm images are fetchable, product-relevant and not placeholders.
• Do not expose staging, admin, customer-specific or tokenized URLs in a feed.

A successful HTTP response proves accessibility only. It does not prove crawl, indexation, approval or conversion quality.

7Find duplicate, variant and stale-row defects

Group rows by normalized landing URL, image, title and variant attributes. Flag exact duplicates separately from legitimate variants. Then compare IDs across consecutive exports to identify churn and stale products.

Useful invariants
unique(item_id) == row_count
variant IDs remain stable across exports
one row does not claim mutually exclusive availability states
removed products do not silently remain in scheduled exports
variant URL + attributes resolve to the offered variant

8Produce a repair report, not a pile of warnings

For every finding, retain: rule, severity, affected item count, safe example ID, source evidence, proposed correction, confidence, dependency and verification step. Separate:

• feed defect confirmed — reproducible from the supplied data;
• cross-surface mismatch — feed and public page disagree;
• account-only evidence required — cause cannot be established publicly;
• policy or business decision — not a mechanical data repair.

After a targeted correction, compare the output with the frozen input, rerun the same checks, and preserve unresolved items. A clean local validation does not guarantee approval by Google.

Sources:

10. Google Merchant Center product data specification
11. Google Merchant Center price attribute guidance
12. Google Merchant Center availability attribute guidance
13. Google Merchant Center link attribute guidance

References accessed 24 September 2026. Requirements can change; use the current official specification for the target country and destination.