This issue checks whether every image referenced by the page actually loads.

This issue checks whether every image referenced by the page actually loads.

An image is broken when requesting its URL does not return a successful response — the file has been deleted or renamed, the path is wrong, the host is unreachable, or the server refuses the request.

There is deliberately no distinction between images hosted on your own domain and images hosted elsewhere. Both render as the same empty box to a visitor, both are fixed by the same edit to the same <img> tag, and splitting them into two issues described where the file lives rather than what is wrong. This is one issue.

For this check to pass:

• Every image URL on the page must return a successful HTTP response

Example: <img src="/images/hero-banner.jpg"> where that file was renamed to hero-banner-2026.jpg during a redesign returns 404, and the page shows a broken image placeholder where the hero was.

Broken images affect:

• User experience: A broken image is the most visible kind of defect on a page. On a product or article page it reads as abandonment, and it costs conversions immediately.
• Crawlability: Every broken image is a wasted request against your crawl budget, repeated on every page that references it. Templates multiply one bad path across thousands of URLs.
• Rankings: Broken images cannot be indexed in image search, so any traffic that image would have earned is lost. Page experience signals are also affected, since a failed request still costs load time.
• AI Search / AEO: Answer engines that reference visual content skip images they cannot fetch, reducing the ways your page can be surfaced.

Fixing this improves your SEO health score. It is scored as critical because it is both highly visible to visitors and usually cheap to fix — a broken image is almost always a stale path rather than a design problem.

1. Start with the images referenced by templates. One wrong path in a header, footer or product card appears on every page that uses it, so a single fix clears the largest share of the findings.

2. Correct the path or restore the file. Most broken images are a file that was renamed, moved into a different folder, or deleted during a migration.

3. Check case and encoding. Hero-Banner.JPG and hero-banner.jpg are different files on most servers, and spaces in filenames must be percent-encoded.

4. Fix protocol mismatches. An http:// image URL on an https:// page is commonly blocked outright by the browser.

5. Host critical images yourself. An image loaded from a third party disappears when they reorganise their site, with no warning. Anything essential to the page — logos, product photography — belongs on infrastructure you control.

6. Remove references you no longer need rather than leaving a tag pointing at nothing.

7. Add a redirect when images have moved in bulk and other sites link to the old paths.

1. File renamed during a redesign

Problem — the file is now hero-banner-2026.jpg, so this returns 404:

<img src="/images/hero-banner.jpg" alt="Studio headphones on a mixing desk" />

Fixed:

<img src="/images/hero-banner-2026.jpg" alt="Studio headphones on a mixing desk" />

2. Third-party image that disappeared

Problem — the external host reorganised and the path no longer exists. Nothing on your site changed, and nothing warned you:

<img src="https://cdn.partner-example.com/assets/v2/logo.png" alt="Partner logo" />

Fixed — the asset is copied onto infrastructure you control:

<img src="/images/partners/partner-example-logo.png" alt="Partner logo" />

3. Protocol mismatch

Problem — an insecure image on a secure page. The browser blocks it, so the image never renders even though the file exists:

<img src="http://example.com/images/product.jpg" alt="Acme AC-700 headphones" />

Fixed:

<img src="https://example.com/images/product.jpg" alt="Acme AC-700 headphones" />

1. Collects the image references. Every image URL found on the page is gathered and resolved to an absolute address.

2. Deduplicates them. The same image referenced by fifty pages is checked once, not fifty times — this keeps the check within your plan's request budget.

3. Requests each image. PixyScan asks the server for the image and reads the response status. Where possible it requests only the headers, so no image data is downloaded.

4. Decides. An image is marked broken when the request returns an error status or fails to connect at all. Where the image is hosted makes no difference to the result.

5. Reports per page. Each page referencing a broken image is reported, so the finding shows you every location that needs the edit rather than just the file.

Images are only checked when your plan includes the image and link verification feature and the request budget for the period has not been exhausted. Images that could not be checked are recorded as unchecked rather than assumed broken.