Use Google Merchant Center Issue Decoder when a store decision needs a clear next step instead of a vague note.
Free ecommerce tool
Google Merchant Center Issue Decoder
Turn confusing Merchant Center language into a practical fix queue before you touch the product feed.
Quick answer
Paste the exact Merchant Center message, then separate likely causes by feed field, landing page, policy, shipping, and review state. The useful output is not just a guess; it is a safer first fix and a record of what to check before bulk editing.
Paste the issue or disapproval text, Destination, Approximate product count
A plain-language result, practical caveats, and follow-up actions the team can save or share.
Enter your details to generate a decision-ready output.
The moment this tool is for
Store-team scenario
The stressful version of a Merchant Center issue starts with a vague warning and a campaign that is still spending. Someone wants to edit the feed immediately because the warning names an attribute. Someone else wants to pause spend because they do not know whether the affected products can still show. Both reactions are understandable, but neither one is enough.
The useful move is to turn the warning into a small investigation. First, identify the affected items. Then decide whether the likely cause lives in feed data, a landing page, account settings, policy language, or review timing. That sequence keeps the team from treating every warning like a spreadsheet problem.
How to read the output
The generated result should be read like a triage note, not like a final diagnosis. If the tool says the issue is probably an identifier problem, that means the next action is to verify product identity before changing values. If the tool points to price or availability, the next action is to compare the feed, the page, schema, and the timing of any sale or stock change.
This is also why the fix log matters. A store that records the warning, owner, suspected cause, and review result builds a memory of its own feed behavior. The next time the same warning appears, the team can compare evidence instead of starting from scratch.
What this tool is actually doing
Merchant Center warnings usually look short, but the fix is rarely just one field. The same warning can come from the feed value, the landing page, structured data, shipping settings, policy language, or a stale product crawl.
| Warning language | Likely area | First check |
|---|---|---|
| missing value [gtin] | Identifiers | Confirm whether the item has a manufacturer-assigned GTIN before changing identifier_exists. |
| price mismatch | Offer data | Compare feed price, sale price, currency, tax, and landing-page price. |
| availability mismatch | Inventory and crawl timing | Check product feed availability, page schema, preorder/backorder language, and recent stock changes. |
| shipping issue | Account or product shipping settings | Compare Merchant Center shipping services with product-level overrides and checkout policy language. |
| policy warning | Trust, claims, restricted products | Review the page copy, checkout path, return policy, contact details, and claim support. |
A better triage order
- Copy the exact warning text and export the affected item IDs before editing anything.
- Group affected products by warning type, product type, brand, and feed source.
- Fix a small sample first. If the sample clears, apply the same rule in bulk.
- Record the field changed, the owner, the date shipped, and the review result.
- If the warning returns, compare the new affected product set with the original export.
Why this matters
Bulk feed edits can create new disapprovals if the real problem is landing-page mismatch, policy language, or account-level shipping configuration.
When not to touch the feed first
Do not start with a feed rewrite when the issue is tied to checkout availability, shipping policy, unsupported claims, or a landing page that shows different data than the feed. In those cases the feed can be technically correct and still fail review.
Example
If Merchant Center reports a price mismatch after a flash sale, the feed may still contain the sale price while the page has returned to regular price. The fix may be feed refresh timing, not the product cost field.
Reference rules
Sample fix-log row
| Warning | Affected set | Suspected cause | First fix | Review note |
|---|---|---|---|---|
| missing value [gtin] | 42 branded accessory SKUs | Supplier UPC missing from barcode field | Verify UPC from supplier catalog and update a five-SKU sample | If sample clears, apply by vendor import rule. |
| mismatched value [availability] | Winter boots variants | Theme shows preorder while feed says in_stock | Align product page language and feed availability | Check after next crawl before editing all variants. |
Methodology and limits
The decoder uses warning language, destination, and catalog size to create a triage note. It cannot see your Merchant Center account, so treat the result as a starting ticket and confirm it against the affected item export.
For disapprovals tied to policy, restricted products, medical claims, financial claims, or account suspensions, use the output to prepare evidence but rely on the channel's current policy review process.
Reusable download
Use the related CSV as a working file for the calculation, checklist, or planning step covered on this page.
Common questions
Should I change every affected product at once?
Usually no. Fix a small sample first so you can tell whether the warning is caused by the feed, the page, a shipping rule, or a policy issue.
What should go in the fix log?
Save the exact warning, item IDs, suspected root cause, field or page changed, owner, date changed, and review result.
What if the same warning returns?
Compare the new affected products with the original export. Recurring warnings often point to a mapping rule, import job, theme change, or promotion timing issue.