Home/Guides

Free authority resource

Merchant Center & Product Feed Health Checklist

A 40-point review framework covering the product-data chain from source ownership and identifiers through Merchant Center diagnostics, attribute rules, landing-page consistency and ongoing QA.

PDF version

Keep the 40-point checklist for your own audit.

The full checklist is free to use on the website. Enter your details to unlock the six-page PDF version. We store the enquiry in FifteenFold's private lead queue so it can be moved into a CRM later.

Direct senior support

Get the 40-point feed health checklist

The checklist covers source data, identifiers, titles, price, availability, diagnostics, rules and landing-page consistency.

Or email hello@fifteenfold.co.uk.

Prefer the six-page PDF version?

The full checklist remains available on this page. Enter your details above to unlock the downloadable PDF and keep a copy for your audit.

Get the PDF checklist

How to score it

Use 2 = healthy, 1 = partly controlled, 0 = missing / unreliable. The score is only a prioritisation aid, not a Google quality score. One critical eligibility problem can matter more than ten minor optimisation opportunities.

1. Source data & ownership

A clear system of record exists for core product facts.

Know which platform owns title, brand, GTIN, MPN, price, availability, taxonomy, variant data and channel-specific enrichment.

Source fields have named owners.

Incorrect values should have an accountable owner instead of being permanently patched downstream.

Product IDs are stable.

Offer IDs should not change casually; ID migrations need deliberate planning.

Update frequency matches the business.

Price, stock and time-sensitive attributes need a refresh model that reflects catalogue volatility.

Source changes are traceable.

Teams should be able to connect a field/mapping change to downstream impact.

2. Identifiers & product identity

GTINs are present where the manufacturer has assigned them.

Do not omit known GTINs and do not invent them for products that genuinely have none.

GTINs belong to the exact variant being sold.

Size, colour and other manufacturer variants should not incorrectly share one identifier.

Brand reflects the actual product brand.

Use the retailer name only where it genuinely manufactures/owns the product brand.

MPNs are accurate where available.

Do not fill MPN with arbitrary retailer SKUs for branded goods.

identifier_exists is used only when identifiers genuinely do not exist.

It is not a workaround for data that simply has not been collected.

3. Titles, descriptions & creative data

Titles identify the product clearly before trying to optimise it.

A shopper and a platform should understand the item without decoding marketing language.

Important title details are front-loaded.

The most useful differentiators should survive truncation.

Title logic is category-specific.

Different product families need different information priorities.

Variant details are included when they distinguish the offer.

Use size, colour, capacity or other variant data where it helps identify the exact product.

Descriptions add useful product information.

Avoid keyword repetition and promotional filler.

Images are high quality and consistent with the exact offer.

Avoid placeholders, promotional overlays and wrong-variant imagery.

4. Taxonomy, attributes & variants

Google product category is valid where submitted.

Use current taxonomy values and map deliberately.

Product type reflects a useful retailer hierarchy.

It should support reporting, rules and segmentation rather than act as a catch-all.

Decision-critical attributes are populated consistently.

Examples include colour, size, material, pattern, age group, capacity and dimensions.

Variant relationships are coherent.

Group related offers correctly while preserving accurate variant-level values.

Channel taxonomy does not hide broken onsite taxonomy.

Fix customer-facing catalogue structure where that is the real problem.

5. Price, availability, shipping & landing pages

Feed price matches the visible landing-page price.

Check sale periods, tax treatment, membership logic and exact variant selection.

Availability matches the landing page and checkout reality.

Customers should be able to buy what the listing says is available.

Structured data agrees with visible content and submitted data.

JSON-LD or microdata should not expose stale values.

Price and availability update timing is understood.

Know the lag from source change to feed, submission, processing and page update.

Shipping information reflects the real customer promise.

Settings and product-level exceptions need to be commercially accurate.

Automatic item updates are a safety net, not the operating model.

They do not replace regular accurate product-data updates.

6. Data sources, attribute rules & transformations

Primary and supplemental sources have clear purposes.

Teams know which source adds/removes products and which only enriches them.

Attribute rules are documented.

Important transformations need an owner and a business reason.

Rules adapt data rather than permanently hide source debt.

Shared factual product data should normally be fixed upstream.

Draft rule changes are tested before application.

Preview representative products and edge cases.

Rule order and dependencies are understood.

Cascading transformations can create unexpected outcomes.

7. Merchant Center diagnostics & policy

Needs attention is reviewed by business impact, not just issue count.

Prioritise blockers affecting important products and destinations.

Issue examples are traced back through the data chain.

Compare processed data with source, landing page and structured data.

Policy and data-quality issues are separated.

They often require different owners and review processes.

Reviews are requested only after the cause is fixed.

Keep evidence of the change before asking Google to reassess.

8. Monitoring, QA & operating model

There is a recurring feed and Merchant Center QA routine.

Do not wait for campaign performance to reveal catalogue failure.

Key issue classes and product coverage are trended.

Measure recurrence and usable catalogue coverage over time.

Changes have comparison or rollback evidence.

Keep enough history to understand what changed.

There is a prioritised improvement backlog.

Separate blockers, recurring operational debt, optimisation and architecture work.

Turn the result into four workstreams

WorkstreamExamples
BlockersDisapprovals, broken price/availability, invalid identifiers, required-data failures.
Recurring operationsUpdate timing, monitoring, QA, ownership and errors that repeatedly return.
PerformanceTitles, attribute depth, product types, imagery, segmentation and controlled tests.
ArchitectureSource ownership, PIM/ERP changes, rule debt, feed-platform simplification and data contracts.
FF

Written by FifteenFold

FifteenFold combines senior ecommerce, product-data and Google Shopping experience with practical implementation detail. The aim here is to explain how these problems behave in real operating environments, not just repeat the Merchant Center interface.

Want a second pair of eyes on the actual setup?

Start with the free Merchant Center & Feed Triage. No account access is needed for the first look. Send the website, catalogue size and the symptom and we will tell you where we would investigate first.

More about this route +
40 checksWeb + PDFReviewed September 2026

A clearer next move

Bring us the problem.
We’ll work out the route.

Tell Shahid what you want to improve. We can help you decide what needs changing, what is worth keeping and where to focus next.

Talk to Shahid ↗Pricing & what is included