E-commerce Product Image SEO Guide

Start with crawlable image markup and a page that clearly represents the item.

Make the product image discoverable

Use an HTML <img> element with a real src URL. If you use <picture> to offer alternate formats or crops, keep an <img> fallback with its own src. Google says it can find images referenced by img elements and does not index CSS background images as image content. Use a Search-supported format such as JPEG, PNG, WebP, AVIF, SVG, BMP, or GIF. [1]

Choose a clear, relevant image that represents the product shown on the page. Use the highest-resolution original that is practical, then deliver a size suited to the display. Place the image near accurate product context so its subject is clear to both shoppers and search systems. [1]

An image sitemap can expose image URLs that might otherwise be missed, especially when images are hosted on a CDN. Discovery is not indexation: Google says a sitemap is a hint, not a guarantee that a URL will be crawled or indexed. A product or image must be eligible and indexed before it can appear in Search. [1][12]

• Check the rendered source

  Confirm the product photo appears in an <img src> or as the fallback <img> inside <picture>; do not rely on a CSS-only background for the product image. [1]

• Check the destination page

  Make sure the page is crawlable and its visible name, selected variant, and image all describe the same item. [1]

Treat filenames and alt text as accurate descriptions, not keyword containers.

Name files and describe what each photo shows

Use short, descriptive, lowercase filenames separated with hyphens, such as navy-wool-cardigan-front.jpg. Google describes filenames as a light clue and recommends concise, descriptive names; it advises against generic names and keyword stuffing. [1]

Write alt text for the information this specific photo adds. For product images, that may include a shopper-relevant material, color, cut, finish, or gallery angle when those details are actually visible or otherwise confirmed. A concise target of about 125 characters is a secondary accessibility guideline, not a Google rule or a reason to omit useful meaning. [1][9]

If a photo is informative, provide an alt attribute. If an image is purely decorative and adds no information, use alt="" so assistive technology can skip it. Avoid repeating the product title or adding search phrases that the image does not support. [1][17]

A stable URL is useful when the exact same photograph appears on more than one page, including pages for variants that share that photo. Use a different image and URL when the visible product or selected variant genuinely changes. [1]

<img src="navy-wool-cardigan-front.jpg" width="1200" height="1200" alt="Navy wool cardigan with ribbed cuffs, front view">

• Differentiate variants

  If one page shows navy and another shows rust, describe the color that the actual image displays. Do not reuse navy alt text on a rust photo.

• Differentiate gallery views

  Give the front, back, material close-up, and closure detail their own useful descriptions instead of repeating the same alt text on every gallery frame.

• Keep the example honest

  The sample alt text is appropriate only when the pictured item visibly is a navy wool cardigan with ribbed cuffs shown from the front. If fiber content is not known or visible, omit “wool.”

• Set image dimensions

  Set explicit width and height to the source image’s pixel dimensions, or reserve its correct aspect ratio in CSS. The browser can then reserve space before the bytes arrive and reduce layout shifts. [16]

Keep enough detail for shoppers while reducing bytes transferred to the page.

Choose a format, then compare the actual result

For a white-background product photograph, the supplied research snapshot suggests JPEG export quality around 80–85 as a starting point on the exporter’s own scale. For transparent edges or overlays, compare WebP and PNG; WebP supports transparency and may be smaller. A <picture> element can offer WebP and retain a JPEG fallback for other clients. [6][1][13]

The snapshot reports WebP as roughly 25–35% smaller than JPEG; Google’s WebP documentation reports 25–34% smaller for comparable JPEG images at equivalent SSIM quality. Cloudinary’s comparison estimates AVIF can be around 30–50% smaller than JPEG at similar perceived quality. These are measured or estimated comparisons, not guaranteed savings for your image set. [6][7][13]

The snapshot also estimates that 75–85% quality settings can look visually indistinguishable while reducing file sizes by 60–80%. The excerpt provides no bibliography, test images, encoder, or method for that claim, so it is an unverified trial range—not a universal result. “Quality” scales vary between tools and formats. [13]

<picture><source srcset="cardigan-front.webp" type="image/webp"><img src="cardigan-front.jpg" width="1200" height="1200" alt="Navy cardigan, front view"></picture>

• Keep photographic detail

  Compare JPEG, WebP, and—where your delivery stack supports it—AVIF at the same rendered size. Inspect fabric texture, edges, color, small labels, and shadows before choosing the smaller file. [6][7]

• Preserve transparency

  Use PNG or transparent WebP when the image actually needs an alpha channel. Check that transparent edges remain clean against the storefront background. [6]

• Measure your own catalog

  Export representative light, dark, textured, and transparent products. Record dimensions, format, byte size, and a visual quality check; keep a fallback when your delivery path needs one.

Responsive candidates avoid sending a desktop original to every small screen.

Send the browser an image sized for its display

Provide image candidates in srcset and describe the rendered slot with sizes. The browser uses those hints along with viewport width and pixel density to select a suitable file. Match sizes to the actual product-gallery layout; a 400-pixel candidate is a practical mobile example, while a 1600-pixel candidate can serve a large Retina desktop slot when the display width calls for it. [8][16]

Lazy-load product photos that start below the fold so the browser can defer work the visitor may not reach. Do not lazy-load the main image visible above the fold when it may be the page’s LCP candidate; loading that image late can delay LCP. Give it an ordinary discoverable src and let it begin loading promptly. [10][16]

<img src="cardigan-800.webp" srcset="cardigan-400.webp 400w, cardigan-800.webp 800w, cardigan-1600.webp 1600w" sizes="(max-width: 600px) 400px, 800px" width="800" height="800" alt="Navy cardigan, front view">

• Verify the slot size

  Use browser developer tools to confirm the selected file matches the layout and device pixel ratio. Avoid downloading a 1600-pixel file for a small thumbnail when a smaller candidate is available. [16]

• Keep layout stable

  Include explicit width and height that reflect each source image’s aspect ratio, then use responsive CSS to scale it. Do not stretch a square thumbnail into a different crop without checking the product details. [8]

• Defer offscreen images only

  Lazy-load product and gallery images that start below the initial viewport. Leave the above-fold main product image eager, and do not lazy-load other images that are also visible immediately. The dispatch snapshot’s shorter “all except the main image” rule should be applied only when the remaining images are offscreen; lazy-loading an LCP image creates avoidable request delay. [10][16][13]

Relate file bytes and loading order to what shoppers see first.

Check image weight against Core Web Vitals

Core Web Vitals measure real-world loading performance, interactivity, and visual stability; Google includes them in its page-experience guidance for Search. Largest Contentful Paint measures when the largest content element—often a prominent image or text block—renders in the viewport. On an image-heavy product page, oversized files, poor responsive candidates, and delayed image discovery can slow that visible element. [2][10]

Use PageSpeed Insights to evaluate a specific page on mobile and desktop. Its report includes lab and real-user field data when available and offers performance suggestions. It is an evaluation tool; do not treat it as a service that produces ready-to-deploy compressed product files. [3]

Review the actual LCP candidate and its request timing, then check its dimensions, transfer size, format, priority, and responsive selection. Compare similar templates and devices over time. Image optimization can improve delivery conditions, but it does not promise rankings, traffic, or conversion changes. [2][3]

• Record a baseline

  Choose a representative product URL, device class, selected LCP element, image bytes, and report date before changing the template.

• Change one delivery choice at a time

  Resize the candidate, change the format, or adjust loading priority, then recheck the rendered product and performance report under comparable conditions.

Help discovery where useful, and keep markup separate from Search requirements.

Use image sitemaps and structured data carefully

An image sitemap can include each image with an <image:image> element and its URL in <image:loc>. This can help Google discover images that are harder to find through ordinary links, including images served from another domain. Keep the page URL and image URL current; sitemap submission still does not guarantee indexing. [1][14][12]

The supplied snapshot also reports a secondary practice of describing high-value images with Schema.org ImageObject. Treat this as optional metadata, not an official requirement for standard Google Search or a substitute for an HTML img element. Schema.org defines ImageObject and properties such as contentUrl, but the snapshot’s specific recommendation to prioritize “high-value” photos had no bibliography to verify. [11][1][13]

Product structured data is a separate page-level feature. When it accurately matches visible product facts, it may make a page eligible for richer results, including annotated product images in Google Images and information such as price, availability, and review ratings. Google decides whether to show an enhancement, so it is not guaranteed. Product markup is not required just to index a standard product image. [4]

Keep the Merchant Center image-size dates in their own lane: Google’s product data specification update dated April 14, 2026 says warnings began April 14, 2026 and enforcement of a 500 × 500 pixel minimum for image_link and additional_image_link starts January 31, 2027. A separate current Google Merchant Center help page gives July 2026 as the warning start, so Google’s pages differ on rollout timing; check the Needs attention view in your account for current status. This is a dated Merchant Center product-feed requirement, not a general Google Search image rule. [5][15]

• Image sitemap

  Add an <image:image> block for a product image and put that image’s actual URL in <image:loc>; do not submit placeholder or stale CDN URLs. [1][14]

• ImageObject

  Use only when the additional image description is useful and accurate. It remains a secondary implementation choice, not a standard-search requirement. [11][13]

• Product data

  Describe only the product, price, availability, and reviews actually visible and current on the page; eligibility is not a promise of a rich result. [4]

• Merchant Center feed

  Review the product-feed image_link and additional_image_link separately from the site’s ordinary image SEO checks, including the dated 500 × 500 policy timeline. [5]

Turn the guidance into a repeatable pass for the catalog and its image templates.

Run the same review across a representative product set

Sample products with different colors, materials, image backgrounds, gallery sizes, and variant behavior. Check a main photo, one alternate angle, and a transparency case if the catalog uses one. Record actual product facts from the source catalog rather than inferring them from a filename.

Repeat the review after changes to the image CDN, theme, product feed, or gallery component. A correct image record should stay accurate when a shopper changes variants, opens a gallery view, or loads the page on a small screen.

• Discovery

  The page is crawlable, the image is in HTML image markup, the format is supported, and important photos can be reached through normal links or an image sitemap. [1][12]

• Description

  The filename is descriptive; each informative view has accurate alt text; decorative images use empty alt text; variant and gallery descriptions match what is shown. [1][9][17]

• Delivery

  The image has explicit dimensions, responsive candidates, an appropriate format and tested compression, and lazy loading only when it starts below the fold. [16][6][10]

• Measurement

  The main image is not delaying the likely LCP candidate; a mobile and desktop PageSpeed Insights report has been reviewed as a diagnostic, not as a ranking forecast. [2][3]