Skip to content
Home » Articles » Fix Broken Image Links in WordPress WooCommerce Stores

Fix Broken Image Links in WordPress WooCommerce Stores

Introduction

Fixing broken image links in WordPress for WooCommerce stores in 2026 usually means tracing one of four layers: the attachment record in MySQL, the file inside `wp-content/uploads`, the generated thumbnail metadata, or the delivery path through a CDN or proxy. On product-heavy stores, a single break can hit category pages, product galleries, structured data, and conversion rates at the same time.

This guide assumes a live WooCommerce environment where product images, variation thumbnails, or category visuals are returning 404 errors, loading as empty placeholders, or pointing to old domains after a migration. The workflow below is designed for technically competent site owners, developers, and store operators running modern WordPress stacks on PHP 8.2 or 8.3. It also fits stores using image optimization layers such as Media Optimizer, cleanup workflows like Unused Media Cleaner, and broader performance reviews from Web Image Performance In 2026.

Prerequisites

What you need and why: broken image links are rarely fixed safely without verifying versions, file ownership, and backup access first.

  • WordPress 6.8 or later
  • WooCommerce 10.x
  • PHP 8.2 or PHP 8.3
  • MySQL 8.0 or MariaDB 10.6+
  • SSH or terminal access for the web server user
  • WP-CLI 2.10+ installed and available in the site root
  • A current database backup and uploads backup
  • Access to the active CDN, reverse proxy, or image optimization layer if one is in front of WordPress
ComponentRecommended VersionWhy It Matters
WordPress6.8+Attachment handling and image regeneration behavior can differ across major versions
WooCommerce10.xProduct gallery and variation image handling must match current schema
PHP8.2 or 8.3Required for current plugin compatibility and predictable WP-CLI behavior
WP-CLI2.10+Needed for media audits, regeneration, and search-replace checks

Installation And Setup

What you should prepare and why: you want a clean audit path before touching metadata, regenerating thumbnails, or editing URLs.

First, move into the WordPress document root as a non-root deployment user such as `www-data`, `deploy`, or your host account.

pwd
ls -lah
wp core version
wp plugin list --status=active

Expected output should confirm the correct site root and show WooCommerce as active.

6.8.1
+----------------------+--------+-----------+---------+
| name                 | status | update    | version |
| woocommerce          | active | none      | 10.x.x  |
+----------------------+--------+-----------+---------+

Next, inspect a known broken image URL from a product page and compare it against the attachment record.

wp post list --post_type=attachment --fields=ID,post_title,guid --format=table | head -20

If you already know the attachment ID, pull its metadata directly.

wp post meta get 1234 _wp_attached_file
wp post meta get 1234 _wp_attachment_metadata --format=json

On Linux-based WordPress hosting, the expected file location usually maps like this:

ls -lah wp-content/uploads/2026/04/

If your store has had media bloat or accidental cleanup, it is worth reviewing how image files are managed before restoring anything. These two references are useful when the root cause turns out to be optimization or cleanup side effects: 9 Free WordPress Media Optimization Plugins Compared and Unused Media Cleaner.

Configuration

What to verify and why: many broken image links are configuration issues, not missing files.

Start with the core URL settings.

wp option get home
wp option get siteurl

If the domain changed recently, check whether attachments still reference the old hostname.

wp db query "SELECT ID, guid FROM wp_posts WHERE post_type='attachment' AND guid LIKE '%old-domain.com%' LIMIT 20;"

On stores behind Cloudflare, Bunny, a subdomain CDN, or a proxy rewrite, confirm the expected upload base path in WordPress. Broken paths often appear after moving from local uploads to a CDN origin path such as `/wp-content/uploads/` versus `/content/uploads/`.

Check whether custom upload constants are defined.

grep -nE "UPLOADS|WP_CONTENT_URL|WP_HOME|WP_SITEURL" wp-config.php

Typical correct cases:

  • No custom `UPLOADS` constant unless the store deliberately uses a non-standard upload directory
  • `WP_HOME` and `WP_SITEURL` point to the canonical production domain
  • CDN rewrite plugins are configured to rewrite URLs consistently for original files and generated sizes

If permissions are wrong, WordPress may fail to generate derivative images even when the original upload exists.

find wp-content/uploads -type d | head -5 | xargs -I{} stat -c "%a %U:%G %n" {}
find wp-content/uploads -type f | head -5 | xargs -I{} stat -c "%a %U:%G %n" {}

A practical baseline for many Ubuntu and Debian stacks is:

  • Directories: `755`
  • Files: `644`
  • Owner/group aligned with the PHP-FPM or web server process

If your store uses image automation or alt-text workflows that create or rewrite media assets, keep those plugin paths consistent with the current domain and uploads structure. Related product pages and tools on Flux Plugins include AI Media Alt Creator and Alt Text Checker.

Usage And Execution

What to do and why: the safest repair flow is to prove whether the problem is a missing file, bad metadata, or a bad URL, then fix only that layer.

Audit The Broken Attachment

Look up one broken image from the browser, then inspect its attachment path.

wp db query "SELECT ID, post_title, guid FROM wp_posts WHERE guid LIKE '%broken-filename%' OR post_title LIKE '%broken-filename%' LIMIT 10;"

Then verify the stored relative file path.

wp post meta get 1234 _wp_attached_file

You should see something like:

2026/04/product-photo.webp

Now confirm whether that file exists on disk.

test -f wp-content/uploads/2026/04/product-photo.webp && echo "exists" || echo "missing"

Restore Or Repoint Missing Files

If the file is missing, restore it from backup or copy it from the old server before regenerating thumbnails.

rsync -avz oldhost:/var/www/example.com/public_html/wp-content/uploads/2026/04/product-photo.webp wp-content/uploads/2026/04/

If the file exists under a different name after migration, update the attachment path carefully.

wp post meta update 1234 _wp_attached_file '2026/04/product-photo-restored.webp'

Regenerate Thumbnails

If the original file exists but product thumbnails are broken, regenerate metadata and derivative sizes.

wp media regenerate 1234 --yes

For a broader repair on a medium-sized catalog:

wp media regenerate --only-missing --yes

Expected output:

Found 1 image to regenerate.
Success: Regenerated 1 of 1 images.

Fix Old Domain Or Mixed Upload URLs

If product pages still point to a retired domain or staging hostname, run a dry check first.

wp search-replace 'https://staging.example.com' 'https://store.example.com' --skip-columns=guid --dry-run

If the preview looks correct, run it for real.

wp search-replace 'https://staging.example.com' 'https://store.example.com' --skip-columns=guid
wp cache flush

Use caution with `guid`. In most cases, do not bulk rewrite attachment `guid` unless you have a specific migration reason and understand the downstream effects.

Verify WooCommerce Product Associations

Sometimes the image exists, but the product is linked to a deleted attachment ID. Check the product thumbnail and gallery values.

wp post meta get 5678 _thumbnail_id
wp post meta get 5678 _product_image_gallery

If the product references a dead attachment ID, replace it with a valid one.

wp post meta update 5678 _thumbnail_id 1234

Recheck Frontend Delivery

After repairs, test the image URL directly and from a product page.

curl -I https://store.example.com/wp-content/uploads/2026/04/product-photo.webp

A healthy response usually returns `200 OK` and an image content type.

HTTP/2 200
content-type: image/webp

Troubleshooting

What to inspect and why: when the normal repair flow fails, the remaining issues are usually cache, metadata corruption, or offloaded-media rules.

404 From CDN But 200 From Origin

If the origin file loads but the CDN URL fails, the edge layer is serving a stale path or missing asset.

Check these points:

  • Purge the single broken URL and then the image path prefix if needed
  • Confirm the CDN origin still maps to the live `wp-content/uploads` directory
  • Verify any WebP or AVIF rewrite rules still point to real files
  • Rebuild transformed variants if your optimization plugin generates alternate formats

A common 2026 quirk is that CDN rules may cache now-deleted derivative filenames even after the original file is restored.

Image Exists But Thumbnails Stay Broken

This usually means `_wp_attachment_metadata` is incomplete, corrupted, or built against an older editor stack.

Inspect the metadata payload.

wp post meta get 1234 _wp_attachment_metadata --format=json

If the `sizes` array is empty or references nonexistent filenames, regenerate the image again after confirming write permissions in the target uploads folder.

Product Points To Deleted Attachment ID

WooCommerce can keep `_thumbnail_id` or gallery references after aggressive media cleanup, import rollbacks, or partial database restores.

Verify the attachment post still exists.

wp post get 1234 --field=post_type

If no attachment post is returned, assign a valid attachment ID to the product and resave the product page or update it through WP-CLI.

Conclusion

Fixing broken image links in WordPress for WooCommerce stores is mostly a matter of isolating the failing layer instead of blindly regenerating everything. In practice, you want to verify the attachment record, confirm the physical file, rebuild derivative sizes, and then clear any CDN or cache path still serving stale URLs. That sequence prevents unnecessary database edits and reduces the chance of breaking healthy media entries.

For stores with lots of imported products or automated image workflows, build verification into your routine: test direct image URLs, spot-check category thumbnails, and review uploads after migrations or cleanup jobs. If you also manage optimization, alt-text, or media lifecycle tooling, the related Flux resources linked above can help prevent the same class of image breakage from returning.