Product images in a barcode-keyed catalog

Many sources, one product

Any catalog built from more than one supplier ends up holding several pictures of the same item. Six retailers carry a shoe; each publishes its own photograph, at its own angle, on its own background, at its own resolution. None of them is wrong. Only one of them can be the picture on your product page.

That choice is only possible once identity is settled. If the six rows have not been folded onto a single product identifier, you do not have six candidate images for one product. You have six products with one image each. That is how catalogs end up listing the same shoe several times with different photos. The image problem comes after the identifier problem and cannot be solved before it.

Once the rows are keyed correctly, picking is a ranking, not a guess. Prefer the largest image, a known-good host, and a product shot over a lifestyle shot. Fall back in a defined order when the preferred source has nothing.

What makes an image usable

Not every supplied URL is worth storing. The practical filters, in the order they save the most work:

• Does it load at all? A surprising share of supplier image URLs are dead on arrival: the product moved, the CDN changed, the path was templated wrong.
• Does it return an image? Some hosts answer with an HTML error page at HTTP 200. Checking the content type rather than the status code is the difference between a picture and a broken frame.
• Will it load for your visitors? Some retailer CDNs serve their own site happily and return 403 to everyone else. That image works when you test it in a browser tab with their cookies and fails in production.
• Is it the product? Placeholder and "image coming soon" graphics are common in feeds and are worse than no image, because they look like real data.

Hotlinking versus mirroring

The lazy implementation points your <img> at the supplier URL. It works on day one and then fails quietly. The supplier reorganises its CDN and your pages go blank. Or it notices the traffic and blocks you. Or its latency becomes your latency. You now depend on infrastructure you neither control nor monitor.

Mirroring means copying each chosen image once into your own object storage and serving it from a host you own. The cost is storage and a copy job. The benefit is that your product pages stop failing for reasons outside your control. Caching and sizing also become your decision, not the supplier's.

A worked example

A European sneaker price-comparison catalog such as HYPEIBIZA has this problem at scale: many shops, many photographs, one page per colourway. Its catalog picks one image per product and mirrors it onto its own image host. It does not link to the retailers' CDNs. That is why its product pages keep their pictures when a retailer reorganises.

When this is done properly, the visible result is boring, and that is the point. Pages load their photographs. A product with no usable image says so plainly and does not show a broken frame. When it is skipped, the catalog looks fine the week it launches and is full of holes three months later.

When there is no usable image

Some products will have none. Handle it with an explicit empty state: a labelled placeholder that says no photograph is available. Do not use a stretched logo or a broken image icon. The placeholder reads as deliberate, and it tells the next person looking at the record that the gap is known.

Also record why a product has no image, because each reason needs a different action. A dead URL might be fixed by re-picking from another source tomorrow. A host that always 403s should be dropped from selection entirely. A product that no supplier photographed needs a different supplier.

It all ties back to the identifier

Every decision above assumes you can say, without hesitation, which product a given image belongs to. That assumption rests on the identifiers: a GTIN resolved to a product record, or a manufacturer style code shared across the sizes of one colourway. Get that wrong and you are no longer choosing between six photographs of one shoe. You are scattering six shoes across six pages.

If you are building a catalog from identifiers and not from a single supplier feed, the API documentation covers resolving codes to product records. The barcode validation tool keeps malformed values from becoming phantom products with photographs of their own.