Image Sitemaps for Product Discovery: Merchant Guide

What an image sitemap does and does not do

A regular XML sitemap lists page URLs. An image sitemap adds, under each page entry, the image URLs that page displays. The crawler reads it, learns that /products/oak-desk-lamp is associated with four specific JPEGs, and can queue those images for crawling and indexing even if they are lazy-loaded, swapped in by a variant picker, or referenced only inside a JavaScript gallery component.

That is the whole job: discovery. It is worth being clear about what it does not do.

• It does not guarantee indexing. Google still evaluates each image's quality, page context and duplication before deciding whether to keep it.
• It does not replace alt text, descriptive filenames or structured data. Those tell Google what the image is; the sitemap only tells it the image exists.
• It does not boost rankings on its own. An indexed image that competes with better-shot, better-described alternatives will still lose.

The practical model is a funnel. Discovery is the top. If a photo never enters the funnel, nothing else you do to it matters, which is why the sitemap is the first thing to check when product images are missing from image search.

Those limits come from the sitemaps protocol and Google's own documentation. A catalog with 8,000 products and six photos each is 48,000 image references across 8,000 URL entries, which fits in a single file. Larger catalogs split across several files linked from a sitemap index, and most platforms handle that split automatically.

Why product images go undiscovered in the first place

If Google crawls your product pages, why would it miss the images on them? Four patterns account for almost every case we see in merchant audits.

The last two rows matter. A sitemap cannot override a robots.txt disallow, and it cannot make Google index a 300-pixel thumbnail or the ninth near-identical angle of the same white-background shot. Check both before assuming a sitemap will solve a discovery gap.

What each image entry should contain

Google simplified the image sitemap schema in 2022. The <image:caption>, <image:title>, <image:geo_location> and <image:license> tags are now ignored, so the only field that carries weight is <image:loc>. A minimal, correct entry looks like this:

<url>
  <loc>https://www.example.com/products/oak-desk-lamp</loc>
  <image:image>
    <image:loc>https://www.example.com/cdn/oak-desk-lamp-brass-front.jpg</image:loc>
  </image:image>
  <image:image>
    <image:loc>https://www.example.com/cdn/oak-desk-lamp-brass-side.jpg</image:loc>
  </image:image>
</url>

Because the descriptive tags are gone, the filename and the on-page alt text carry all the semantic weight. That makes two habits far more valuable than they used to be:

• Descriptive filenames at upload time. oak-desk-lamp-brass-front.jpg tells Google something; IMG_4471.jpg or 1788568779347-final-v2.jpg tells it nothing. Filenames are hard to change after upload on most platforms without breaking the URL, so set them before the image goes live.
• Alt text that matches the filename's intent. The two should agree on what the product is. Our guide to alt text, file names and schema for product images covers the pattern in detail.

Two more rules that trip up merchants:

• List the full-resolution or largest displayed version of each image, not the thumbnail. Google prefers to index the largest available rendition and will pick the one you tell it about.
• Only list images that actually appear on that page. Listing a product's photos under the collection page URL, or listing the same image under twelve different pages, dilutes the association and can look like manipulation.

What each platform generates for you

Most hosted platforms emit an image sitemap without configuration. The quality varies, and the gaps are consistent enough to summarise.

The Shopify row deserves a closer look because it is the most common setup and the most often misread. Shopify's sitemap index links to sitemap_products_1.xml (and further numbered files for large stores). Each product entry includes image:image blocks for the product's media. In practice we have seen stores where only the featured image was listed, which traces back to how the theme or an app had attached media. If your store relies on variant-specific images, open the products sitemap and confirm the secondary photos are actually there before assuming they are.

For headless builds, generate the image sitemap from your product database rather than by crawling your own rendered pages. The database knows every image attached to every SKU; a crawler of your own site inherits exactly the JavaScript blind spots you are trying to fix.

How discovery connects to conversion

It is easy to treat image indexing as a vanity metric. It is not. Image search is a meaningful acquisition channel for physical products, and the visual results that Google inserts into standard search (product carousels, image packs, the visual matches in Lens) all draw on the image index. If the photo is not indexed, the product does not appear in any of them.

There is a second-order effect that matters more for most merchants. Google's image index is also how it decides which thumbnail to show next to your product in ordinary web results and in free product listings. If only your featured image is indexed, that is the only candidate. If all six angles are indexed, Google can pick the one that best matches the query, which is often a detail or in-use shot rather than the default front view.

This is where image quality feeds back into discovery. Google is selective about what it keeps in the index, and low-resolution, poorly-lit or near-duplicate images are exactly what gets dropped. A catalog where every product has a clean, consistent, high-resolution set (the kind of output tools like Retouchable are built to produce at volume) indexes more completely than one with a mix of studio shots and phone snaps, even with an identical sitemap. Our post on image quality and conversion rates covers the on-page half of that equation.

Verifying the sitemap is working

Submitting a sitemap is not the same as it working. Three checks, in order:

1. Search Console sitemap report

Under Indexing → Sitemaps, confirm the file (or index) shows Success and a recent "last read" date. A status of "Couldn't fetch" or a stale date means Google is not reading it at all, which is usually a robots.txt block, a redirect chain on the sitemap URL, or a file that exceeds the size limit.

2. Image-specific indexing counts

Search Console does not break out image indexing per URL, but you can approximate it. Run a site:yourdomain.com query in Google Images and compare the result count against the number of images in your sitemap. A large gap points to a quality or duplication problem rather than a discovery one, because the sitemap has already told Google the images exist.

3. Spot-check individual products

Pick ten products across price points and categories. For each, search Google Images for the product name plus your brand. Note how many of the product's photos appear. If you consistently see one per product, revisit the variant-image question from the platform section above.

Re-run the spot check four to six weeks after any fix. Image indexing lags page indexing, and a newly-discovered image can take a month to appear in results even when everything is configured correctly.

A maintenance routine that scales

The sitemap is only accurate if it reflects the current catalog. Three habits keep it that way without turning into a project.

• Name images before upload, every time. Once a filename is live, changing it means a new URL, a redirect, and a re-crawl. Build the descriptive name into whatever step produces the final image, whether that is a retoucher's export or an automated pipeline pushing to your store.
• Replace, do not accumulate. When you reshoot a product, remove the old images rather than appending new ones. Sitemaps that list twelve images for a product with four current photos leak crawl budget and invite duplicate-content suppression.
• Audit quarterly, not continuously. Pull the sitemap, count image:loc entries per product, and flag anything with zero or one. On a store of a few thousand SKUs this is a ten-minute script and it catches theme or app changes that silently drop images from the file.

If you also sell through Google Merchant Center, remember that its image requirements are enforced separately: a product image can be perfectly indexed for organic image search and still be disapproved in a Shopping feed. The two systems share images but not rules.

The payoff for all of this is unglamorous but real. Every product photo you paid to shoot or generate is an asset that can bring traffic on its own. An image sitemap is how you make sure the search engine knows each one exists, and the naming and quality habits around it are how you make sure it stays in the index once found.