Why your catalog ad still shows the old image, and when that is on purpose

You changed a price, a sale started, or you uploaded a new logo, and the ads still show the old image. Before you rebuild anything, it helps to know that catalog images move through three separate schedules: your store’s feed, the service that draws the images, and the ad platform’s fetch. A delay in any one of them looks the same from the outside. Here is how to tell them apart.

1. The ad platform has not fetched your feed since the change

Meta and Snapchat read your catalog feed on the schedule you set in the catalog, not when your store changes. If the schedule is daily, a change made at 10:00 may not reach the catalog until the next morning.

How to tell: in Commerce Manager, open Catalog → Data sources and look at the last upload time. In CatalogBadge, the store’s Overview shows when Meta last fetched each feed.

Fix: set the schedule to hourly, and use Upload now when you need a change sooner.

2. The image URL did not change, so the platform did not download it again

Meta downloads a product image again only when its URL changes. If a tool overwrites a new image at the same address, the catalog keeps the copy it already has, sometimes for days.

How to tell: open the product under Catalog → Items and compare the image address with the one in your feed.

Fix: make sure every new image gets a new address. CatalogBadge builds each image URL from a fingerprint of everything on the image (price, offer, title, photo, template, brand settings), so when anything on it changes, the URL changes with it, and an unchanged product keeps its URL.

3. The new image is not drawn yet, and the feed is showing your own photo on purpose

When a price, sale price, sale date, title, photo or offer line changes, the old branded image is no longer true. Until the new one exists, the feed points at your original product photo rather than an image with an old price on it.

How to tell: the product shows your plain photo, not the old branded image. That is the safety net working.

Fix: none needed. It switches to the new image on the next fetch after it is drawn. A change that only affects the look, such as a new logo or colour, keeps the previous image until the new one is ready, because the previous one still shows the right price.

4. The supplementary feed rows do not match your catalog’s ids

If your catalog is filled by a platform integration and you added a supplementary feed for the images, Meta matches each row by id. A row whose id is not in the catalog is ignored without an error on the product.

How to tell: the supplementary feed’s upload succeeds, but the products keep the platform’s images. Compare an id in the file with the id Meta shows for the same product.

Fix: use the id field your platform sends to Meta. Some platforms send a variant id, others a product id or SKU.

5. The new feed was held back because it looked wrong

A feed that suddenly loses many products usually means a broken export, not a store that sold out overnight. Publishing it would empty part of your catalog. So a new CatalogBadge feed replaces the old one only after it passes checks: it was written completely, it still holds at least 80% of the previous product count, and every image in it was made for your store. Otherwise the previous feed stays live and you get an email.

How to tell: your dashboard shows the last run as held, with the reason.

Fix: correct the export at the source; the next update publishes normally.

A quick way to diagnose

What you see in the catalog	Most likely cause
Old branded image, old price	No fetch since the change (1) or same URL reused (2)
Your plain product photo	New image still being drawn (3)
The platform’s image, never ours	Supplementary ids do not match (4)
Nothing changed for many products	Feed held back by a check (5)

The input feeds documentation lists every field we read and the health report that flags problems before they reach your catalog.