How to Find and Fix Broken Images on Your Website

A product page loads, but the hero image is a blank rectangle with a tiny broken icon in the corner. The visitor can't see what they're buying. A missing product photo makes the page less useful, but an image returning 404 does not by itself establish that Google will lower the page's rankings.

Broken images are the visual equivalent of broken links. They're easy to miss during development and can accumulate silently. Check image requests directly to find the cause, rather than trying to infer it from traffic or engagement metrics.

What Exactly Is a Broken Image?

A broken image is any <img> element on a page where the browser can't load the referenced file. Instead of the intended photo, illustration, or graphic, the visitor sees a placeholder — typically a small icon with a torn page or an empty box.

The browser tried to fetch the file. The server said no. The reasons vary:

• 404 Not Found — the image file doesn't exist at the specified URL. It was deleted, moved, or the path was never correct.
• 403 Forbidden — the file exists but the server blocks access. Common with hotlinked images where the source server rejects external requests.
• 500 Server Error — the server failed to deliver the file due to an internal problem.
• Wrong file path — a relative path like ../images/photo.jpg that resolved correctly in development but breaks in production due to different directory structures.
• Typo in the filename — hero-bannner.png instead of hero-banner.png. One extra letter, one broken image.
• Deleted source file — someone cleaned up the media library and removed an image that was still referenced in three blog posts.
• Hotlinking failure — you embedded an image from another website. That site changed its URL structure, enabled hotlink protection, or went offline entirely.
• Protocol mismatch — the page loads over HTTPS but the image src uses HTTP. Modern browsers may block mixed content, showing a broken image or nothing at all.

The Difference Between Broken Images and Slow Images

A slow-loading image eventually appears. A broken image never will. This distinction matters because the diagnostic approach is different.

If an image takes 8 seconds to load, you have a performance problem — optimize the file size, use a CDN, or switch to a modern format like WebP or AVIF. If the image never loads at all, you have a broken reference — the file is missing, the path is wrong, or the server rejects the request. Check the HTTP status code in your browser's Network tab to know which problem you're dealing with.

How Broken Images Affect Users and Image SEO

The clearest consequences are missing visual information and images that search engines cannot fetch. Effects on page rankings or engagement need to be measured, not assumed.

Image Fetching and Indexing

An image URL that returns an error cannot supply the image to a crawler. Google's image SEO guidance explains how to make images discoverable and accessible. Fix the image request itself; an inaccessible image and an unindexed HTML page are different problems.

Core Web Vitals Impact

Images without reserved space can cause Cumulative Layout Shift (CLS) when their displayed size changes. A failed image request does not automatically cause a layout shift: the result depends on the page's sizing and fallback behavior.

Set appropriate width and height attributes or reserve space with CSS, then measure the page. Google's CLS guide covers images without dimensions and other causes of layout shifts.

User Trust and Engagement

A missing product photo or unreadable infographic can prevent visitors from getting information they need. Fix these images because they make the page harder to use. Analytics can help measure changes in engagement or conversions, but neither a broken image nor a change in bounce rate proves a ranking effect.

Lost Image Search Traffic

If Google cannot fetch an image, its visibility in image search may be affected. This matters especially for product photos, portfolios, and other visual content. An error does not necessarily remove an existing result immediately; use Search Console's Image search performance data to track actual impressions and clicks.

How to Find Broken Images on Your Site

Finding broken images requires different tools depending on whether you're checking a single page or auditing an entire site.

Method 1: Browser DevTools (Quick Single-Page Check)

Open any page in Chrome, press F12 to open DevTools, and check two places:

Console tab: Broken images generate error messages like:

Failed to load resource: the server responded with a status of 404 ()

Each error shows the exact URL that failed. Filter by "errors" to cut through the noise.

Network tab: Reload the page with DevTools open. Click the "Img" filter to show only image requests. Look at the Status column:

• 200 — image loaded successfully
• 404 — file not found (broken)
• 403 — access denied (hotlink protection or permissions issue)
• 301/302 — image redirects (works but adds latency)

You can also paste this snippet into the Console to list image elements that have finished loading but have no available natural width:

document.querySelectorAll('img').forEach(img => {
  const source = img.currentSrc || img.getAttribute('src');
  if (source && source.trim() && img.complete && img.naturalWidth === 0) {
    console.log('Check image:', source, img.alt);
  }
});

Treat these results as candidates to investigate in the Network tab, not proof of a 404. The snippet skips images that are still loading and elements without a source. Scroll lazy-loaded images into view, wait for their requests to finish, and run it again. It checks <img> elements in the current document, not CSS background images or images inside iframes. See MDN's explanation of complete for why a failed image can still be marked complete.

Best for: Quick checks on individual pages, debugging specific broken images you've been alerted about.

Method 2: Screaming Frog (Full Site Audit)

For an audit across your site, Screaming Frog SEO Spider can crawl image URLs and report their HTTP status. The free version crawls up to 500 URLs; larger crawls require a licence.

To find broken images specifically:

1. Open Screaming Frog and enter your site URL
2. In Configuration → Spider, make sure image crawling is enabled; see the crawler configuration guide
3. Start the crawl
4. In Response Codes, inspect Client Error (4xx) and Server Error (5xx) results for failing image URLs
5. Select a failing image URL and open the lower Inlinks tab to find pages referencing it
6. Check those pages in a browser to confirm the failure before changing their image references

HTTP errors are only part of the check: a URL returning 200 can still contain an invalid image. Lazy-loaded or JavaScript-inserted images may also require rendering or a separate browser check.

Screaming Frog also catches images with missing alt text, oversized files, and other image-related SEO issues — so you can fix everything in one pass.

Best for: Comprehensive site-wide audits, especially for sites with hundreds or thousands of pages.

Method 3: Online Crawlers

Several online tools can check for broken images without installing anything:

• Ahrefs Site Audit — crawls your site and reports broken images under the "Images" category
• Semrush Site Audit — flags "Internal images are broken" as a specific issue

These tools run in the cloud, so they work on any device without local software. The trade-off is that free tiers usually limit the number of pages you can crawl.

Use Search Console to Monitor Image Search

Search Console is useful for measuring image search performance, but its Page Indexing report is not an inventory of failed image requests. In the Performance report, choose the Image search type to track impressions and clicks. Use DevTools or a crawler to locate the actual image failures; a high CLS score alone does not identify broken images.

Check Hyperlinks Separately

A clickable image has two separate destinations: its image source and the link that opens when someone clicks it. The Broken Link Checker Chrome extension checks hyperlinks on the current page, including links wrapped around images. It does not scan image src resources. Use it to check those linked destinations after validating the images with DevTools or a crawler.

How to Fix Broken Images: Step by Step

Once you've found your broken images, here's how to fix each type.

1. Re-upload the Missing File

The simplest fix: the file was deleted from the server. Upload it again to the exact same path.

Broken: /images/products/blue-widget.jpg
Fix: Upload blue-widget.jpg to /images/products/

If you can't find the original file, check:

• Your CMS media library trash/recycle bin
• Local backups or version control history
• The Wayback Machine for cached versions of your page (it often captures images too)
• Google's cached version of the page

2. Fix the File Path

Compare the src attribute in your HTML with the actual file location on the server.

Common path issues:

• Missing leading slash: images/photo.jpg vs /images/photo.jpg — the first is relative to the current page, the second is relative to the root
• Wrong directory: /img/photo.jpg vs /images/photo.jpg
• Case sensitivity: /Images/Photo.JPG vs /images/photo.jpg — Linux servers are case-sensitive, so these are different files
• Encoded characters: spaces in filenames become %20 in URLs — my%20photo.jpg — and some systems handle this inconsistently

A quick server-side check:

# Find the actual file on the server
find /var/www/html -name "photo.jpg" -type f

# Check if a file exists at the expected path
ls -la /var/www/html/images/photo.jpg

3. Replace Hotlinked Images

If you embedded an image from another website and that site changed or blocked the image, you have two options:

Option A: Download the image (if licensing allows) and host it on your own server. This eliminates external dependencies.

Option B: Find a replacement image. If the original was a stock photo, check the source. If it was a screenshot, retake it. If it was someone else's original work, link to their page instead of embedding the image.

Never hotlink images from other sites in production. It's unreliable, it steals their bandwidth, and many servers actively block it. Host your own images.

4. Set Up Proper Alt Text

While fixing broken images, audit your alt attributes too. When an image fails to load, the alt text is what the visitor sees instead. Good alt text turns a broken image from a complete dead end into at least some useful context.

<!-- Bad: visitor sees nothing useful when image breaks -->
<img src="/images/chart.png" alt="" />
<img src="/images/chart.png" alt="image" />

<!-- Good: visitor understands what should be here -->
<img src="/images/chart.png" alt="Monthly revenue growth chart showing 23% increase in Q1 2026" />

Alt text also serves screen readers and contributes to image SEO. Google uses alt text to understand image content for indexing and ranking in image search.

5. Add Width and Height Attributes

Always specify dimensions on your <img> tags. This prevents layout shifts when images load (or fail to load):

<img src="/images/hero.jpg" alt="Product overview" width="1200" height="630" />

Modern CSS frameworks handle this with aspect-ratio, but explicit width and height attributes are the most reliable way to reserve space. They work even when CSS hasn't loaded yet, and they give the browser the information it needs to calculate layout without waiting for the image.

6. Handle Lazy Loading Edge Cases

Lazy loading (loading="lazy") defers image loading until the image approaches the viewport. This is great for performance but can create false positives when testing — images below the fold haven't loaded yet because they haven't been scrolled into view.

When auditing for broken images, always scroll through the entire page or temporarily add loading="eager" to your images during testing. Also make sure images above the fold (hero images, logos) are not lazy-loaded — they should load immediately.

<!-- Above the fold: load immediately -->
<img src="/images/hero.jpg" alt="..." loading="eager" fetchpriority="high" />

<!-- Below the fold: lazy load -->
<img src="/images/diagram.jpg" alt="..." loading="lazy" />

Preventing Broken Images

Fixing broken images is reactive. Prevention is better.

Use Consistent, Predictable Image Paths

Adopt a convention and stick with it:

/images/blog/[post-slug]-[descriptor].png
/images/products/[product-id]-[view].jpg
/images/team/[name]-headshot.jpg

Consistent paths make it easy to verify that files exist and reduce the chance of typos. Never use spaces in filenames. Use lowercase only. Separate words with hyphens.

Use Relative Paths from Root

Always reference images from the site root with a leading slash:

<!-- Do this -->
<img src="/images/blog/my-photo.jpg" />

<!-- Not this -->
<img src="../images/blog/my-photo.jpg" />
<img src="https://www.example.com/images/blog/my-photo.jpg" />

Root-relative paths work from any page regardless of its depth in the URL hierarchy. Relative paths (../) break when pages move. Absolute URLs with the domain break when you switch between staging and production, or between www and non-www.

Set Up an Image CDN

An image CDN like Cloudflare Images, Cloudinary, or imgix centralizes your image storage and delivery. Benefits beyond performance:

• Single source of truth — images live in one place, not scattered across your server filesystem
• Automatic format conversion — serves WebP or AVIF to supported browsers, JPEG as fallback
• Resize on the fly — request any dimension via URL parameters instead of storing multiple sizes
• Global distribution — serves images from the nearest edge server, reducing load times
• Redundancy — CDN providers handle replication and backups, reducing the risk of accidental deletion

The practical difference compared to a regular CDN: an image CDN converts the source file to WebP or AVIF on the fly, resizes it to the requested dimensions, and caches the result — so the browser gets a file sized for the visitor's device instead of the full-resolution original.

Automate Monitoring

Don't wait for visitors to report broken images. Set up automated checks:

• Weekly crawls with Screaming Frog or a similar tool, checking for 4xx responses on image URLs
• A browser image check after every content update — use DevTools on the edited page, including images that load as you scroll
• CI/CD integration — add a link and image check to your deployment pipeline so broken references never reach production
• Uptime monitoring — tools like UptimeRobot or Pingdom can monitor specific image URLs if they're critical to your business (product photos, hero images)

The goal isn't zero broken images forever — link rot affects images just as it affects links. The goal is catching breaks within hours, not months.

WordPress-Specific Tips

WordPress sites have unique broken image challenges because of how the CMS handles media.

The Media Library Problem

WordPress stores uploaded images in /wp-content/uploads/YYYY/MM/ directories organized by upload date. When you delete an image from the Media Library, WordPress removes the file — but doesn't scan your posts and pages for references to it. Every <img> tag pointing to that file is now broken.

Prevention: Before deleting any image from the Media Library, use the "Attached to" column to check if it's used anywhere. If you don't see this column, click "Screen Options" at the top of the Media Library page and enable it.

Plugin and Theme Images

Some WordPress themes and plugins bundle their own images. When you switch themes or deactivate a plugin, those images may become inaccessible — even if your content still references them.

After any theme or plugin change, check image requests with DevTools or an image crawler. Separately, run a broken link check on your WordPress site to find hyperlinks pointing to unavailable pages.

Image Regeneration

WordPress creates multiple sizes of each uploaded image (thumbnail, medium, large, full). If you change your theme's image size settings or install a new theme with different registered sizes, old images won't have the new sizes generated. This doesn't break them immediately, but it can cause issues if your theme requests a size that doesn't exist.

Use the Regenerate Thumbnails plugin to recreate all image sizes after a theme change.

wp-config.php Image Path Issues

If you've migrated a WordPress site to a new domain or directory, image paths stored in the database may still reference the old location. Use a search-and-replace tool like Better Search Replace to update all image URLs in the database at once.

Old: https://old-domain.com/wp-content/uploads/
New: https://new-domain.com/wp-content/uploads/

Always back up your database before running search-and-replace operations.

FAQ

Do broken images affect Google rankings directly?

A failed image request is not evidence of a ranking penalty for the page. It can make content less useful and prevent Google from fetching the image for image search. Layout shifts are also possible when image space is not reserved, but they need to be measured rather than assumed.

How often should I check for broken images?

At minimum, after every content update, theme change, or plugin update. For larger sites, run a weekly automated crawl. E-commerce sites with hundreds of product images should check daily — a broken product photo directly impacts conversion rates.

Can broken images cause my page to be deindexed?

A broken image URL does not by itself mean that the containing HTML page will be deindexed. If the page disappears from search, inspect the page URL in Search Console and investigate the reported indexing reason separately from image request failures.

What's the best image format to prevent loading issues?

The format doesn't affect whether an image breaks — that's about the file path and server availability. But modern formats like WebP and AVIF are smaller, which means faster loading and less chance of timeouts. Use WebP as your default with JPEG fallback. Most browsers support WebP natively as of 2026, and Next.js, WordPress, and most CDNs can serve WebP automatically.

Should I use absolute or relative URLs for images?

Use root-relative paths (starting with /) for images on your own site. They work from any page depth and survive URL structure changes. Avoid protocol-relative URLs (//example.com/image.jpg) — they're outdated. And avoid fully absolute URLs (https://example.com/image.jpg) for internal images because they break when switching between environments (staging, production, different domains).