My product image is ready. Why does Merchant Center still show pending?

Identify which system is waiting

Open the affected product in Merchant Center and record the destination, item ID, issue text, submitted image URL and time of your last change. Check the image history rather than relying on the thumbnail in your store. The history can reveal whether Google has inspected the new file at all. Compare that time with your own publication record.

A generation task marked complete in CartVisual only establishes that a creative file was returned. It does not submit a feed or monitor Google approval. Conversely, a pending external review does not prove the generator failed. Keep the approved file while you diagnose the external state.

Build a timeline with four separately labeled events: the approved file version, the connector submission, the last image crawl shown for this item, and the current issue observation. Use the same item ID and destination throughout. A source sheet saved at 10:00 is not proof that the connector submitted it at 10:00; keep an unknown submission time as unknown.

Use a state-based decision

Google describes processing delays and possible use of an older approved image during replacement. Those periods are guidance rather than a deadline promise for your particular account. Do not delete and recreate products merely to force a new thumbnail.

Keep one change interpretable

For an illustrative ceramic-mug listing, first verify that the newly submitted URL opens the intended mug image without sign-in. If it does, leave that URL stable and record the check. If it redirects to an expired download, publish a durable public asset and correct the feed reference. Changing the prompt, file, product ID and feed source together makes the result harder to diagnose.

Use the Merchant image diagnosis CSV as a manual record. Its sample row is fictional. Replace it with your own authorized evidence; the worksheet does not connect to or change any external account.

Fictional exercise: a mug master M2 is ready, but the processed item still names M1. First reconcile the connector’s exported image value. If the processed value is M2 but the latest crawl predates its submission, inspect access and review processing. If a later crawl fetched M2 and reports a specific overlay issue, assess M2 against that issue. These three records lead to different repairs even though the seller describes each as “the new image is pending.”

The downloadable worksheet contains one FICTIONAL-EXAMPLE mug row. Its 600 × 600 dimensions are a specimen, its response and AI source type are NOT_CHECKED, and its final status is NOT_APPROVED. Replace those values with actual observations in a copy; opening the CSV does not check an account.

Know when to escalate

If the image is accessible but the status remains unresolved beyond the guidance shown for the issue, collect the item ID, timestamps and image history for platform support. Exclude credentials from screenshots. Treat a rejection as a concrete repair request: an overlaid discount calls for a clean export; an inaccessible URL calls for delivery work. A prettier scene is not evidence that either problem was fixed.

Close each affected destination independently. Record “image approved, item still blocked by another issue” where that is what the account shows. Keep the exact remaining issue and assigned owner. Do not mark the whole listing ready merely because one image status changed. For a browser-versus-crawler mismatch, use the direct resource diagnostic before changing the creative.