Missing Product Images Finder

What an empty images array actually means

Every product in the public feed carries an images array. Normally it holds one entry per uploaded photo, with a CDN source URL, a position, and the variant IDs the photo is attached to. When the array is empty, nothing has ever been uploaded against that product.

There is no partial state and no ambiguity here, which is what makes this check different from most storefront audits. Alt text can be missing on some images and present on others. Variant assignment can be half done. A product either has photos or it does not, and the feed says which without any interpretation from us.

What the shopper sees depends on the theme. Most themes fall back to a grey Shopify placeholder tile, some render an empty box that collapses the layout, and a few show the collection card with nothing in it at all. On a search results page or a Google Shopping feed the same product usually just disappears, because a feed entry with no image link gets rejected at validation.

So the cost of a genuinely imageless product is not subtle. It cannot be merchandised, it cannot be advertised through a product feed, and a shopper who lands on it has nothing to look at. If it is real and it is for sale, it needs a photo. If it is not for sale, it should not be published to the online store in the first place, and that is a different fix entirely.

The false alarm this tool refuses to raise

Here is the finding that changed how this scanner works, and you can reproduce it yourself in about thirty seconds.

On 8 August 2026 we read the first 250 products from the public feed on brooklinen.com. Fifty of them came back with an empty images array. A tool that stops at the detection would report fifty broken products on a well run catalogue and be wrong about forty nine of them, because forty nine of those fifty have a handle that starts with content-. Forty five of those forty nine also carry a product type of Content, and four leave the product type blank. That is exactly why either signal counts on its own here: requiring both would have missed four of them, including content-bath-mats. They are page building blocks: content-back-to-campus-plp, content-tencel-towels, content-bath-mats. Every one of them is a container for a merchandising block, published on purpose, with no photo because a photo would make no sense on it.

The fiftieth had the handle shop-the-color, no content- prefix, and a product type of Content. Same class of object, different naming. That single leftover is why the tool checks the product type as well as the handle rather than the prefix alone.

Reading two pages of that same catalogue, 461 products, gives the ratio the whole tool turns on. Fifty eight products came back with no image. Fifty five were page building blocks. Three were real: ordinary listings with ordinary product types, published back in 2018, that simply have no photo on them. Three is a list somebody can act on before lunch. Fifty eight is a list nobody opens twice.

So the scan sorts zero image products into three groups and prints the reason on every row. Two of the three signals are strong enough to move a product out of the fault count. The third is not, and it is treated differently for that reason:

• Handle begins with content-. The strongest of the three. This is the naming we have seen on stores that use a page builder, and it is what all 54 of brooklinen's content blocks carry, while not one of the 403 products on that store that do have photos carries it. That is one store, so treat it as a convention worth checking rather than a law.
• Product type is literally Content. Same idea, expressed in a different field. Added after the prefix rule left an obvious pseudo product behind on the very store the rule came from.
• No product type at all. Far too weak to clear a product, so it does not. Plenty of ordinary merchants never fill in product type, which means an imageless product with a blank type is just as likely to be a broken listing as a page block. These get their own group, they are still counted in the headline as products missing an image, and the group carries its own warning. This one is a sorting aid, not a verdict.

That last distinction is the one worth being pedantic about, because getting it wrong produces the single worst output an image scanner can produce: a green all clear over a catalogue that really is missing photos. A store that leaves product type blank as a matter of habit would get exactly that if a blank type were treated as proof of anything. So it is not. Only the handle prefix and a product type of Content move a product out of the fault count, and the headline says so when the blank type group is not empty.

Two more things follow. First, none of these rules touch products that do have images, because an empty product type is far too common to use as a filter anywhere else. Second, if your store uses a different naming convention for its page furniture, the tool will not know, and those products will show up in bucket 1. Look at the handles before you conclude anything. A column of near identical handles with a shared prefix is your own convention staring back at you.

The three buckets, and what each one costs you

The buckets are ordered by how confident the scan is, not by how many products land in them. Bucket 1 is a fact. Buckets 2 and 3 are prompts.

Bucket 3 needs the honest caveat, and it is the same caveat that applies to every variant image audit ever written. If the only option on the product is Size, one photo carrying nine variants is the correct setup, because a medium shirt looks exactly like a small one and nobody expects nine photographs of the same garment. If the option is Colour, one photo carrying nine variants means eight colours are showing a picture of the ninth. Identical numbers, opposite verdicts. The table prints the option names next to each row so you can tell the two apart at a glance, and that is as far as this tool goes into variant territory.

Bucket 2 has its own weakness worth stating plainly. The word temp also appears inside template, temperature and contemporary, and default shows up in perfectly deliberate filenames. The scan prints the actual filename in the row for exactly that reason. If it flagged contemporary-oak-frame.jpg, you can see the mistake and dismiss it in a second, which beats a scanner that hides its reasoning behind a confidence score.

Fix, hide, or delete: three honest paths

Once you have a list of genuinely imageless products, there are only three things you can do with each one, and choosing badly is expensive in different directions.

Fix it. Upload a photo. This is the right answer whenever the product is real and still sells. If the missing photos exist somewhere already, on a shared drive, in a supplier pack, sitting in a folder from the last shoot, the job is transfer rather than photography.

Doing that one product at a time in the admin is fine for a handful. At two hundred it stops being realistic, which is what CS Smart Bulk Image Upload takes hundreds of images into Shopify in one pass is built for: drag and drop, a Google Drive folder import, and SKU based matching that reads the filename and routes each image to the product carrying that SKU. That last part matters more than the bulk upload itself, because renaming files to match SKUs is a job you can hand to anybody, while clicking through two hundred admin pages is not.

Hide it. If the product is not ready, unpublish it from the Online Store sales channel or set it to draft. It leaves the public feed immediately and it stops appearing in collections and search. The part people miss is that this is reversible: the product record is untouched, so the handle, the history, the inventory and the reviews all stay, and everything comes back the moment you publish it again.

What is not preserved while it is hidden is the public URL. A product that is not published to the Online Store is not served on the storefront, so inbound links, ad destinations and bookmarks pointing at that handle stop landing on a product page for exactly as long as it is hidden, which is the same thing a delete does to them. Reversible in the admin does not mean invisible to the outside world. Hiding is still the right holding move when you are unsure, but a hide you never come back to should be treated the way you would treat a removal.

Delete it. Sometimes the right call. A discontinued line, a test product from three migrations ago, a batch that was imported twice. But read this before you touch it: deleting a Shopify product is not reversible. There is no undo and no trash you can fish it back out of. The product record goes, and with it the variant IDs, the inventory records and the metafields. Reviews may go too, because review apps generally key on the product ID, so check with your review app before you delete rather than assuming either way. Any order that contained the product keeps its line item, but the link back to the product breaks. Shopify does not create a redirect for you either, so the old URL starts returning a 404 and every inbound link, ad destination and bookmark pointing at it is wasted until you write one.

Now the sequence, which is the opposite of what most people assume. Shopify's own documentation says you can redirect only from broken URLs, and that if the URL still loads a valid webpage then the redirect will not work. A redirect written against a live product URL sits there doing nothing, which is worse than having no redirect at all, because you think you are covered. So: confirm the product is really dead, export a copy of the product data, save the handle, delete or unpublish so the URL actually breaks, and write the redirect after that.

The handle is the thing you have to capture in advance, not the redirect. Build the file up front with the Redirect CSV Generator while the handles are still in front of you, then upload it once the products are gone. Once you have made those decisions for a long list, CS Bulk Delete Products removes a reviewed list in one run, with filters for collection, vendor, tag, date and inventory level, a preview screen before anything happens, scheduled deletes, and a soft delete option so the destructive version is not the default. It still cannot undo a permanent delete, because nothing can.

Three paths, and the ranking between them is not close. Hide when unsure. Fix when it sells. Delete only when you have already decided, and only with the handles saved for the redirects you will write afterwards.

This tool is product level. Its sibling is variant level.

Two different questions get muddled together constantly, so here is the split in one table.

Run this one first. A product with zero images cannot have a variant image problem, because there is nothing to assign, so fixing the product level gap has to come before the variant level one. Once every product has photos, the Variant Image Coverage Checker is the natural next step and it will tell you whether those photos actually reach the right colours. For a single product with the full per variant table laid out, use the Variant Image Checker instead.

One more distinction that saves people a wasted afternoon. If your colours are separate products rather than variants of one product, neither of those two tools is the lever. Separate colour listings are a grouping question, and the Product Grouping Planner works out how they should be joined up for the shopper.

How to work the CSV

The export button appears with the results and builds the file in your browser. Nothing is sent anywhere. The nine columns are bucket, handle, title, product_type, images, variants, options, storefront_url and why_it_was_flagged, and every group on the page is in the file, page building blocks included, so nothing is quietly dropped between the screen and the spreadsheet.

Handle is the column that matters, because it is the key Shopify itself uses. A product CSV import matches on handle, a URL redirect is written against a handle, and the admin search finds a product by handle faster than by title. Sort by bucket, add a decision column with fix, hide or delete in it, and you have a work order that somebody else can execute without needing to understand the scan.

Two small mechanical notes. The file is written with a UTF-8 byte order mark so Excel opens accented product titles correctly instead of mangling them. And any cell that starts with an equals sign, a plus, a minus or an at sign gets a leading apostrophe, because spreadsheets treat those as formulas and a product genuinely titled +1 Sizing Kit should not execute when the file is opened.

If you are about to re-upload photos in bulk, pull your existing image library down first so you know what you already own. CS Export Product Images exports the library as a ZIP, filtered by collection, vendor or tag, with a metadata CSV alongside it. Comparing that export against this scan usually shows that a good share of the missing photos already exist and were simply never attached.

What the scan can and cannot see

Being straight about the boundary is more useful than overselling the coverage.

• Published products only. The public feed returns what the Online Store sales channel serves. Drafts, archived products and anything unpublished are invisible, so a product you already hid will correctly not appear here.
• It stops at 2,500 products. That ceiling is ours, not the platform's. The feed keeps paging well past it. We cap the run because each request is fired at a store that never opted into being scanned, and 2,500 products is ten requests at the normal page size, twenty five if the feed is heavy enough that the scan has to drop to smaller pages. When the ceiling is reached the results say so at the top, and print the page size actually used, rather than quietly reporting a partial catalogue as a whole one.
• Paste a collection URL to get past the cap. Shopify publishes the same feed per collection, so example.com/collections/knitwear scans that collection only and you can work a big catalogue in slices.
• It cannot see a password protected store. If the storefront is locked there is no public feed to read and the scan fails with an error rather than a fabricated result.
• Headless storefronts are hit and miss. A custom frontend may not serve the endpoint on the domain you typed. The underlying myshopify.com domain usually still does.
• It does not judge photo quality. A product with one blurry, badly cropped, wrongly coloured photo counts as having an image. Presence is all this checks. For quality, alt text and filenames, use the Product Image Audit.
• It reads the default market. The feed returns products as your primary storefront serves them, so region specific catalogue differences will not show up.

Fetched pages are also cached for a few minutes on our side to stay polite to the store being scanned. Fix something and re-run within that window and you may see the previous result, so give it a moment before concluding the fix did not work.

If the product count this scan reports does not match what your admin shows, unpublished items are almost always the explanation. The Store Analyzer gives you the same public catalogue total alongside the theme and collection counts, which is a quick way to confirm the number rather than assume the scan missed something.

Common mistakes when auditing product images

• Treating the raw zero image count as a bug count. This is the big one, and the brooklinen numbers above show how far off it can be. Read the page building block group before you panic, and read the no product type group before you relax, because only the first of those two is left out of the headline.
• Deleting first and thinking second. Hiding is reversible and delete is not. If the only thing wrong with a product is that nobody photographed it, deleting is the most expensive possible response to a missing JPEG.
• Fixing in catalogue order. Your traffic is concentrated in a small number of products. Cross reference this list against your analytics and fix what people actually land on first. A product with no photo and no visitors costs you nothing today.
• Shooting new photography before checking what exists. A surprising share of missing images are uploaded somewhere already and were never attached to the product. Export your library and check before you book a studio.
• Assuming a thin gallery is a defect. One photo across nine sizes is correct. One photo across nine colours is not. Same number, and the option name is the only thing that separates them.
• Running the audit once. Image gaps come back with every bulk import, every supplier feed sync and every product duplicated from a template. Put it on a monthly reminder and the number stays small. Checking the import file before it goes in helps too, and the Product CSV Validator reads a Shopify product CSV and reports the row level problems it finds.
• Writing the redirect before the delete. It will not take. Shopify only applies a redirect to a URL that is already broken, so a redirect created while the product is still live does nothing at all. Save the handles first, delete, then write the redirects.
• Losing the handles. That is the part you genuinely cannot recover after a delete. Export this scan's CSV before you remove anything, because the handle column is what every redirect is written against.

Related Tools

• Variant Image Coverage Checker: the variant level version of this question, showing which option values have no photo of their own.
• Product Image Audit: a checklist covering alt text, filenames, dimensions and file weight on the images you do have.
• Bulk Image Renamer: rename a folder of photos to a consistent product, colour and angle pattern before a bulk upload.
• Redirect CSV Generator: build the redirect file from the handles while you still have them, ready to upload once the products are gone.
• Variant Image Checker: the single product view, with every variant and its assigned image listed out.