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, which is how catalogs end up listing the same shoe repeatedly with different photos. The image problem is downstream of the identifier problem, and it cannot be solved before it.

Once the rows are keyed correctly, picking becomes a ranking exercise rather than a guess: prefer the largest, prefer a known-good host, prefer a product shot over a lifestyle shot, and 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 degrades 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 have taken a dependency 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 reach. It also makes caching and sizing your own decision rather than the supplier's.

A worked example

A European sneaker price-comparison catalog such as HYPEIBIZA inherits exactly 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 rather than linking the retailers' CDNs, which is why its product pages keep their pictures when a retailer reorganises.

The visible consequence of doing this properly is boring, which is the point: pages load their photographs, and a product with no usable image says so plainly instead of showing a broken frame. The visible consequence of skipping it is a catalog that 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. The honest handling is an explicit empty state — a labelled placeholder that says no photograph is available — rather than a stretched logo or a broken image icon. It reads as deliberate, and it tells the next person looking at the record that the gap is known rather than unnoticed.

It is also worth recording why a product has no image, because the reasons are actionable in different ways. 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 is carried by 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 not choosing between six photographs of one shoe — you are scattering six shoes across six pages.

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