Use Google Merchant Center Fix Log when a store decision needs a clear next step instead of a vague note.
Ecommerce template
Google Merchant Center Fix Log
Turn feed cleanup into a repeatable operating record.
Quick answer
A Merchant Center fix log records warning text, affected items, suspected cause, field or page changed, owner, date, review request, result, and recurrence notes.
Topic, affected product or campaign, current issue, and the decision the team needs to make
A clearer explanation, reusable decision frame, and links to related tools or templates.
Why a fix log changes the work
Merchant Center cleanup often happens under pressure. A warning appears, campaigns are affected, and the fastest person in the account makes a change. That can solve the immediate issue, but it also leaves the team with no record of what happened. When the warning returns, nobody knows whether the previous fix changed a feed field, a page template, a shipping rule, or a review request.
A fix log turns those small decisions into operating memory. It captures the warning, the affected set, the suspected cause, the change, and the result. Over time, the log reveals recurring sources of trouble: one import rule, one product family, one feed app override, one promotion workflow, or one policy detail that keeps drifting.
When the log is complete
A row is not complete when someone says the feed was fixed. It is complete when another teammate can read the row, understand what changed, see the review result, and know what to check if the issue appears again.
Fix-log fields
- Warning text
- Affected item IDs
- Likely root cause
- Field or page changed
- Owner
- Date changed
- Review requested
- Review result
- Recurring issue notes
Why it matters
A fix log turns feed cleanup from guesswork into an operating record. If the warning returns, you can compare what changed instead of starting over.
Decision note
Record the exact field changed, not just 'fixed feed.' If a price mismatch returns, the team needs to know whether the prior fix changed sale_price, price, schema, feed refresh timing, or the product page.
Review cadence
- Review open warnings daily during active feed cleanup.
- Review recurring warnings weekly until root causes stop returning.
- Review feed-app mapping rules after catalog, price, or theme changes.
- Archive resolved warnings with enough detail to repeat the fix.
Copyable fix-log rows
| Warning | Affected items | Root cause | Action | Owner | Date changed | Review requested | Result | Recurrence note |
|---|---|---|---|---|---|---|---|---|
| Missing value [gtin] | Brand A accessories | Supplier UPC not imported | Verify UPC and update barcode field | Catalog | 2026-06-15 | Yes | Sample pending | Check whether supplier import overwrites barcode field. |
| Price mismatch | June sale items | Sale ended on site before feed refresh | Align sale end and feed schedule | Ecommerce | 2026-06-15 | No | Cleared after feed refresh | Add sale end date to promo QA checklist. |
| Shipping issue | Oversized products | Product override missing | Update shipping profile and policy note | Ops | 2026-06-16 | Yes | Monitoring | Recheck after shipping app rule change. |
Methodology and limits
Create one log row per warning family or affected product group. Use SKU-level rows when the issue is specific to a small set of products.
The log does not replace account review. It preserves team memory and evidence so fixes can be repeated and audited.
Reusable download
Use the related CSV as a working file for the calculation, checklist, or planning step covered on this page.
Common questions
Why log before fixing?
The pre-fix state is the evidence you need if the warning returns or a bulk edit causes a new issue.
Who should own the log?
The person accountable for feed health should own it, with input from merchandising, paid media, and the feed app owner.
When can I close a row?
Close it after the fix is live, the warning clears or is explained, and recurrence notes are complete.