Merchant Center Feed Audit: A Practical Checklist

A Merchant Center feed audit should prove whether the submitted product data is complete, current, accurate, and consistent with the catalog, landing pages, inventory, price, shipping, and checkout. Start with Google’s product data specification, then inspect feed processing and item-level diagnostics. A successful fetch is not proof that every product is eligible, correctly priced, available, correctly grouped, or represented by the right page.

This page is educational and does not guarantee approval, traffic, or sales. Merchant Center interfaces, supported attributes, policy interpretation, and feed requirements change; verify current official documentation before making changes. Use Google Shopping feed optimization for improvement work and Google Ads account monitoring for campaign and commerce context. Do not change catalog, stock, price, shipping, policy-sensitive content, or customer data without the responsible owner’s approval.

Define the audit contract

State what the audit must establish: a general feed-health baseline, a named diagnostic remediation, a launch readiness check, a market migration, a primary-to-supplemental source reconciliation, or a price and availability investigation. Record Merchant Center account, primary and supplemental sources, product population, markets, languages, currencies, date range, fetch schedule, source systems, catalog owner, policy or data authority, freshness requirement, reviewer, recipients, severity, and permitted changes.

Keep feed processing, item diagnostics, website content, structured data, inventory, pricing, shipping, tax, orders, and campaign delivery separate. Store source timestamps, product IDs, variant keys, item-group relationships, diagnostic references, and last valid state. An audit finding should be reproducible from a named source and population.

Determine the audit population

An account-wide feed audit can hide a problem in one category, market, language, variant, source, or launch cohort. Define the population and exclusions before reading the results. If the owner requests a sample, record how the sample was selected and what it can prove; a representative sample does not automatically prove an account-wide condition.

Inspect sources, processing, and diagnostics

List every primary source and supplemental source, its owner, key, update method, schedule, last successful watermark, effective market and language, and fallback. Record feed fetch status, processing time, item counts, warnings, disapprovals, and affected products. Use diagnostics as evidence of a named issue, not as a complete explanation of business performance.

Check source precedence and failures

For each attribute, record which system owns it: catalog, pricing, inventory, web, shipping, tax, legal or compliance, or the feed integration. If supplemental data can override a primary value, document the key, precedence, effective period, and fallback. Test a matching key, missing key, duplicate key, stale row, intentional blank, and failed source. A source failure must be visible as missing or partial evidence, not filled with zero.

Google’s supplemental feed documentation describes supplemental data applied to an existing primary source. Confirm current Merchant Center or Merchant API behavior before relying on a particular interface or update method.

Audit product identity and variants

Check unique id values, stable catalog keys, brand, GTIN, MPN, item-group relationships, and variant attributes against the product system and landing page. Do not invent identifiers or copy one product’s GTIN to another. If global identifiers are unavailable, follow the current product data specification for the applicable fields.

For variants, confirm that each submitted option is selectable or clearly represented on the page, with matching URL, price, availability, image, size, color, material, or other relevant attributes. Look for duplicate variants, collapsed options, stale item groups, missing attributes, and a generic URL that hides the submitted selection.

Audit the product population

Reconcile total source items, eligible items, disapproved items, warnings, excluded items, and intended campaign items. Keep the counts tied to a date, source version, market, and query. Do not call a feed healthy because the total count is stable; a material category or variant can fail inside a stable total.

Audit titles, descriptions, and categories

Review whether titles and descriptions describe the actual product, include accurate differentiators, agree with the landing page, and avoid unsupported claims or keyword stuffing. Check product type, category, material, compatibility, size, color, and other attributes against the source catalog. Use the official specification for accepted values rather than a generic ecommerce convention.

Keep transformation rules, before and after values, affected IDs, reviewer, and authority. A title suggestion is not proof of improved relevance. Do not change regulated or product-safety language merely to increase keyword coverage.

Reconcile price, sale, and availability

Compare submitted price and sale price with the product page and checkout for the same market, currency, language, variant, and time. Check regular price, sale price, effective dates, promotion terms, tax treatment, shipping, and payment. Compare availability with inventory, page selection, and checkout outcome. Record the source watermark and the delay between each system.

Investigate mismatch classes

Distinguish a feed value that is stale, a page that is stale, an inventory-system error, a market or currency mismatch, a variant-selection issue, a scheduled sale transition, and a policy or format problem. These need different owners. Do not fix a source mismatch by changing only the feed to a value that is untrue on the page.

If a product is unavailable, preserve the true state and follow the owner’s policy for how it should be represented. Do not make stock appear available to increase exposure. If a price is planned to change, record the plan and effective time rather than treating the transition as an unexplained incident.

Check pages, images, shipping, and structured data

Open product URLs in the target market and language. Verify the submitted product is visible, the option is selectable, price and availability agree, the page is reachable, and the checkout path is coherent. Check image URLs and variant images for the exact item; a technically reachable image can still depict the wrong product.

Review shipping and tax sources by destination and currency. Keep delivery promises, store pickup, online availability, and local inventory distinct where the program requires them. Google’s structured data documentation for ecommerce explains how product markup can help Google understand product details; use it as a cross-source check, not a reason to let page and feed values diverge.

Review policy and data-quality findings

Group diagnostics by issue type, affected population, first seen, last seen, source, owner, and planned or unplanned state. Separate policy findings from missing attributes, formatting issues, price or availability mismatches, page failures, and connector failures. Preserve the raw issue reference and the audit interpretation.

Do not infer that an item is permanently disapproved from a transient diagnostic, and do not infer that a product is approved for every surface from one status. Follow the current official policy and product-data guidance for the exact issue.

Keep sensitive data out of the audit

Product and order systems may expose customer identifiers, payment details, addresses, support notes, or confidential commercial information. Audit only what is necessary, assign an access class, restrict recipients, and use references instead of copying sensitive records into broad reports.

Produce an auditable audit record

Store audit ID and version, run timestamp, account, source names and versions, product population, market, language, currency, feed fetch and processing watermarks, diagnostics, item and variant keys, before and after values, page and checkout checks, source owner, authority, reviewer, severity, status, recommended review, approval, effective time, and verification result. Keep the last valid state when a new source is incomplete.

Use states such as normal, informational, review, blocked by missing data, acknowledged, action approved, verified, superseded, and expired when the project contract requires them. Use idempotent run IDs so retries do not duplicate findings. A blank field is missing evidence, not a healthy value.

Use a Merchant Center audit matrix

These are audit prompts, not universal pass thresholds. The owner, population, authority, freshness, response, and access boundary determine whether a finding requires action.

Validate remediation and close the loop

Before changing a source, capture the current valid values and the affected population. Apply the smallest approved correction, record the version and owner, and reprocess or refetch through the supported workflow. After processing, review diagnostics, page content, price, availability, and checkout. Compare the result with the original finding and mark it fixed, partial, unresolved, or superseded.

Keep catalog editing, feed transformation, Merchant Center submission, campaign configuration, and performance analysis separate. A feed audit does not authorize a budget, bid, campaign, inventory, price, shipping, or customer-data change. If a finding reveals a wider issue, record it as a separate claim with its own proof.

Establish the audit routine

Start with one product population, one market, one source owner, one diagnostics review, and one verification period defined by the business. Expand after primary and supplemental precedence, product identity, page agreement, price, availability, shipping, and access are clear. Use Google Shopping feed optimization for improvement work and Google Ads account monitoring when campaign and commerce evidence must be reviewed together.

A Merchant Center feed audit is complete when the intended population is defined, every material finding has source and authority context, missing evidence is visible, the responsible owner is named, remediation is scoped, and the next processing result is verified. A successful upload is one observation; it is not the entire audit conclusion.