Broken Product Image URLs: Find and Fix Them

Why product image URLs break in the first place

Almost every broken image traces back to one of a small number of causes, and none of them are exotic. They are ordinary operational events that nobody thought to treat as breaking changes.

Notice how many of these break external consumers while leaving your own storefront looking perfectly healthy. Hotlink protection is the classic example: you add a rule to stop competitors leeching bandwidth, your site keeps rendering images from same-origin requests, and three days later Merchant Center disapproves several thousand products for "image could not be fetched." Nothing on your site looks wrong, so nobody investigates until sales drop.

The second pattern worth flagging is the re-upload. Most modern platforms and CDNs append a content hash to filenames. Replacing a product photo with a corrected version does not update the file at the old address — it creates a new address. If any system cached the old one, that system is now pointing at a tombstone.

What a broken image actually costs

The conversion impact of a missing hero image is close to total: a product detail page with no visible image converts at a rate that rounds to zero, because the shopper has no way to evaluate the item. But the storefront is usually the smallest part of the loss.

Consider the chain of consequences from a single purged asset. The Merchant Center item is disapproved, so the Shopping ad stops serving and the free listing disappears. The Meta catalog entry fails validation, so the dynamic retargeting ad for that product goes dark. The marketplace listing gets suppressed pending a compliant main image. The abandoned-cart email renders a broken image icon in every inbox it reaches. And an AI shopping agent crawling the page finds no usable visual data and scores the listing as low-confidence against competitors who serve a clean, fetchable image.

This is also why image breakage is disproportionately expensive relative to how easy it is to prevent. The fix costs an afternoon of engineering; the detection gap costs a week of ad spend against listings that cannot convert.

How to find every broken image URL in your catalog

You cannot fix what you have not enumerated. The audit is mechanical: extract every image URL your business publishes, request each one, and record the status code. The important discipline is to check them the way an outside consumer would, not the way your browser does.

1. Extract the full URL set. Pull image URLs from three places, not one: your product database or platform API, your generated product feed (the Merchant Center or Meta XML/CSV), and your rendered sitemap pages. These three lists diverge more often than people expect, and the diff between them is itself a finding.

2. Request each URL as an anonymous client. Send an unauthenticated HEAD request with a generic user agent, from outside your own network. Do not run this from a machine that is allowlisted or logged in — that is precisely the blind spot that let hotlink protection through. Record the status code, the content type, and the content length.

3. Flag more than 404s. A URL can be reachable and still be broken in practice.

The soft-404 case — an HTML "not found" page returned with a 200 status — is the one that defeats naive checkers. Always validate the content type, never just the status code.

4. Reconcile against your platform's own diagnostics. Merchant Center and Meta Commerce Manager both publish item-level error reports that name the offending URL. Treat those as a second, independent crawl of your catalog that someone else is running for free. If your audit is clean and their report is not, the difference is almost always an access rule rather than a missing file. Fold this into your regular product image catalog audit rather than treating it as a one-off incident response.

Designing image URLs that stay stable

Finding broken URLs is remediation. The durable fix is a URL scheme where the events that normally break images cannot break them. Three rules cover most of it.

Treat the image URL as a public contract. Once a URL has been emitted in a feed, an email, a marketplace listing or a sitemap, it belongs to the public. It can be updated in place, but it must never simply disappear. If it must move, it gets a permanent redirect that outlives the migration — not a redirect you clean up next quarter.

Key the URL to the SKU, not the file. A path that encodes stable business identity survives re-uploads; a path that encodes file identity does not.

Slot-based naming has a useful side effect: it makes gallery position explicit and auditable, which matters because image order drives conversion and marketplaces enforce rules about which image occupies the main slot.

Separate the canonical asset from its rendered variants. Store one high-resolution master per slot at a stable address, and generate thumbnails, WebP versions and marketplace-sized crops as derived transforms of it. When you need a new size for a new channel, you derive it — you do not re-upload and re-key the original. This also keeps your CDN and delivery layer a pure caching concern rather than a source of truth you can accidentally purge.

Monitoring so it never silently breaks again

Every audit you run manually is a snapshot of a system that changes daily. The goal is to move image integrity from a periodic project into a standing check that fires within hours of a break rather than after the next quarterly review.

A workable monitoring setup has four parts:

• A nightly external crawl of every published image URL, run from outside your network, checking status code and content type. Alert on any non-200 or non-image response — not on a percentage threshold, because a handful of dead hero images on your best sellers matters more than a hundred on discontinued SKUs.
• A pre-publish gate. No product goes live, and no feed regenerates, without every referenced image URL returning a valid image. This catches the majority of breakage before it ever reaches a channel.
• A deploy-time diff. Any change to asset paths, CDN configuration, WAF rules or hotlink protection triggers an immediate spot-check of a sample of URLs from an external client. These configuration changes are the single largest source of catalog-wide breakage.
• Feed error ingestion. Pull the item-level disapproval reports from Merchant Center and Meta into the same alerting channel as everything else, so an external fetch failure lands in front of a human on the same day.

Route all four to one owner. Image integrity tends to fall between merchandising, engineering and paid media, which is exactly why it goes unowned and unmonitored for months.

What to do when you find a break

Triage by revenue exposure, not by count. A sensible order of operations:

Restore the URL before restoring the image. If the asset still exists at a different address, add a permanent redirect from the old URL immediately. That single change often revives feed listings and email rendering within a crawl cycle, while you work out the underlying data fix. It is faster than updating every downstream reference and it repairs consumers you have forgotten about.

Fix the reference, then remove the redirect debt. Once the product record and feed point at the correct stable URL, the redirect becomes a safety net rather than the mechanism. Keep it; redirect chains for images are cheap compared to the alternative.

Force a re-fetch. External platforms cache aggressively. After a fix, resubmit the feed or request re-review in Merchant Center rather than waiting for the next scheduled crawl — otherwise the disapproval persists long after the URL is healthy.

Regenerate what cannot be restored. Sometimes the source file is genuinely gone, the product is discontinued from the original shoot, and there is no master to recover. This is the case where AI product photography earns its place operationally: regenerating a clean, on-brand image for an existing SKU is a matter of hours rather than scheduling a reshoot, which is often the difference between relisting this week and leaving the SKU suppressed. Tools like Retouchable exist for exactly this gap between "the catalog needs an image now" and "the studio is booked in three weeks."

Write the postmortem into the URL scheme. Every break should answer one question: what configuration or workflow allowed a published URL to stop resolving? If the answer is "someone re-uploaded a file," the scheme is wrong, not the person. If it is a replatform, fold the redirect map into your migration checklist so the next platform move does not repeat it.

Why this matters more as agents do the browsing

Historically, a broken product image was a human problem: a shopper saw a grey box, felt uncertain, and left. The failure was visible and, in principle, recoverable — the shopper might still read the description.

Agent-mediated shopping removes that recovery path. When an AI assistant compares products on a shopper's behalf, it works from structured, machine-readable signals: feed attributes, structured data, alt text, and a fetchable image at a stated URL. A listing whose image returns 403 to an anonymous crawler does not present as "a product with a temporary image issue." It presents as a product with incomplete data, and incomplete data is a ranking penalty — one that applies before any human ever sees the listing.

Traffic from generative AI sources to US retail sites has grown by orders of magnitude over the past two years, and the consistent finding across that shift is that agents reward clean, complete, consistently structured product data and quietly deprioritize everything else. Image URL health is the least glamorous component of that data, and the one most likely to be silently wrong.

For the broader picture of what agents look for in a product listing, see our guide to product images for AI shopping agents.