KAZCODE

Technical article

Amazon S3 Storage for WooCommerce Product Images

Use Amazon S3 for WooCommerce product images safely: offload Media Library files, preserve generated sizes, verify delivery, migrate existing products, and avoid confusing public images with protected downloads.

By KAZCODE Published Updated
  • WooCommerce
  • WordPress
  • Amazon S3
  • Media Offload
  • Object Storage

WooCommerce product images are a natural candidate for Amazon S3 offload because they are part of the normal WordPress Media Library. Product pages, category grids, related products, upsells, carts and gallery views can all request different image variants, so a store with a large catalog can accumulate a substantial media footprint and a high volume of image requests.

The key is to offload WooCommerce imagery, not to assume that every WooCommerce file has the same security model. Public product images and protected downloadable products are different problems.

KAZCODE Universal Storage focuses on WordPress Media Library attachments: originals, generated image sizes, remote verification, restore and migration.

WooCommerce product images are WordPress media

WooCommerce’s current documentation describes three common product-image roles:

  • Single Product Image — the large image on the product page.
  • Catalog Images — images used in shop/category loops, related products, upsells and cross-sells.
  • Product thumbnails — smaller images used in places such as carts, widgets and gallery thumbnails.

WooCommerce recommends high-quality source images and lets WordPress/WooCommerce generate the display sizes required by the theme. See the official WooCommerce product image documentation.

That means an offload system cannot judge success by checking only the original JPEG or WebP. The generated variants are part of the storefront too.

A safe S3 architecture

A typical WooCommerce image-delivery path looks like this:

WooCommerce / WordPress
        |
        v
Media Library attachment + metadata
        |
        v
Original + generated sizes
        |
        v
Amazon S3
        |
        v
CloudFront / custom media domain
        |
        v
Storefront visitors

WordPress should remain the source of truth for the attachment record. The S3 bucket owns the binary objects, while a CDN or custom hostname can provide the public delivery path.

This is the same core model described in the complete WordPress S3 media offload guide.

Why generated sizes matter more in a store

A catalog can use the same product image in several contexts during one shopping session.

For example:

product.jpg
product-150x150.jpg
product-300x300.jpg
product-600x600.jpg
product-768x768.jpg
...

The exact set depends on WordPress, WooCommerce, the active theme and other plugins.

A product page may request a large image while the shop grid uses a catalog size and the cart uses a thumbnail. Responsive markup can also select different files through srcset.

If the original is present in S3 but one generated size is missing, the store can appear healthy in one template and broken in another.

Configure S3 before touching production media

The provider setup should be proven independently before bulk migration.

With Universal Storage:

  1. Create or select the S3 bucket.
  2. Use scoped AWS credentials rather than broad administrator access.
  3. Configure the bucket and Region.
  4. Set a delivery hostname/CDN Base URL if the store uses one.
  5. Run the storage connection test.
  6. Upload one non-critical product image.
  7. Confirm the original and generated variants are tracked remotely.

The current provider-specific steps are in the Amazon S3 documentation.

Use a delivery domain intentionally

Serving directly from an S3 object URL can work, but production stores commonly put a CDN or custom hostname in front of object storage.

The important separation is:

  • storage endpoint: where WordPress uploads, reads and verifies objects
  • delivery hostname: the public URL visitors receive in HTML

Do not hard-code a provider URL into the WordPress attachment metadata if the offload layer can resolve the current delivery profile dynamically. That makes CDN or provider changes easier later.

Migrate an existing WooCommerce catalog in batches

A store that has been running for years may have thousands of product images and many generated variants. Treat historical migration as a controlled operation.

A practical sequence is:

  1. Back up the WordPress database.
  2. Keep local files in place.
  3. Migrate a small batch of older and newer product attachments.
  4. Verify remote objects.
  5. Open real product pages and category pages.
  6. Check gallery thumbnails, related products, cart thumbnails and responsive images.
  7. Review failed items.
  8. Increase batch size only after the path is stable.

Universal Storage Free includes existing Media Library migration, so the historical catalog can be tested without moving to Pro.

See Migrate existing media.

Do not delete local images before verification

For a store, a missing product image is customer-facing immediately.

The cleanup rule should be simple:

Remote state must be verified before local cleanup becomes eligible.

A provider timeout, permission error or temporary network failure is not the same as a confirmed missing object. Cleanup logic should not turn uncertainty into deletion.

Universal Storage exposes verification and cleanup as separate workflows:

Test the storefront, not only wp-admin

After migration, inspect actual customer paths.

At minimum test:

  • the main image on several product pages
  • product galleries
  • shop/category grids
  • related products and upsells
  • cart thumbnails
  • search-result/product blocks used by the theme
  • mobile and desktop responsive images
  • old products and recently uploaded products

Use browser developer tools to inspect the actual image URLs and response status. A cached page can hide an origin problem, so test a few uncached requests as well.

Theme changes and regenerated thumbnails

WooCommerce documents thumbnail regeneration as a normal operation when image settings or themes change. The official guidance points store owners to WooCommerce’s thumbnail regeneration tools when existing image sizes need to be rebuilt.

After a regeneration:

  1. identify newly generated files
  2. make sure the offload inventory includes them
  3. verify the remote objects
  4. test the storefront again
  5. clean local copies only after the regenerated variants are safe remotely

This matters because a previously complete remote attachment can gain new local variants after a theme or image-size change.

S3, CloudFront and cache behavior

An S3 object can be correct while a CDN still serves stale content. Conversely, a cached image can make a missing origin object look healthy temporarily.

After changing image sizes, replacing product media or migrating delivery:

  • verify the object through the storage API
  • inspect the public delivery URL
  • purge relevant CDN entries when needed
  • check HTTP status and cache headers
  • confirm the expected image is returned, not merely a 200 response

Product images are not the same as protected downloads

This distinction is critical.

WooCommerce’s official documentation says downloadable products can use files uploaded through the product editor or external URLs. It also warns that files placed in the normal WordPress Media Library are public by default. WooCommerce has separate download methods and a woocommerce_uploads area for protected download workflows.

See:

Universal Storage is a Media Library storage plugin. Do not treat it as a replacement for WooCommerce’s protected-download authorization or private product-file delivery.

If you sell ZIPs, PDFs, software or other paid downloads, design that security path separately.

What about Cloudflare R2?

Amazon S3 is not the only sensible target for a WooCommerce media library. If public image traffic is high, Cloudflare R2’s current data-transfer model can be relevant.

Read:

If a store starts on S3 and later moves to R2, Universal Storage Pro can keep source and destination profiles separate during a verified provider migration.

WooCommerce S3 checklist

Before removing any local product media:

  1. Back up the database.
  2. Test the S3 connection.
  3. Upload a fresh product image.
  4. Confirm original and generated sizes.
  5. Test product page, catalog and cart contexts.
  6. Migrate a small existing batch.
  7. Verify remote objects.
  8. Review failed items.
  9. Test a restore.
  10. Test CDN/custom-domain delivery.
  11. Regenerate thumbnails only with a plan to re-verify them.
  12. Separate protected downloadable-product files from public Media Library imagery.
  13. Enable local cleanup only after the remote state is proven.

The goal is a reversible store-media setup

Moving WooCommerce product images to S3 should reduce local storage pressure without making the catalog harder to recover.

Keep WooCommerce and WordPress attachment metadata intact, track every generated size, verify S3, preserve restore, and keep protected downloadable products outside the scope of a public Media Library offload workflow.

Start with KAZCODE Universal Storage Free or review the Amazon S3 setup docs.

  • Cloudflare R2 vs Amazon S3 for WordPress Media

    Compare Cloudflare R2 and Amazon S3 for WordPress media offload, including cost model, delivery, compatibility, consistency, migration, and operational tradeoffs.

  • Cloudflare R2 for WooCommerce Product Images

    Use Cloudflare R2 for WooCommerce product images and galleries safely, with generated-size coverage, migration, verification, restore, cache checks, and a clear boundary around protected downloads.

  • WordPress S3 Media Offload: Complete Guide

    A complete technical guide to WordPress S3 media offload: architecture, IAM, generated image sizes, migration, verification, local cleanup, delivery, restore, and failure handling.