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.
Enter your details to generate a decision-ready output.
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 mattersBulk 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.
ExampleIf 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.
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.