An embedded image or media file needs attention

Why it matters

A browser requests embedded images and media from the declared address. When that address does not serve the file, the page can show an empty space or a player that cannot start.

What to do

1. Read the recorded file address, response and pages that reference it. A request may have one attempt or an actual retry; the report preserves what was read.
2. For a missing or gone file, restore it at that address or update every declaring page to a working address. Check each srcset and picture alternative: every declared address is checked separately.
3. For HTTP 401, 403 or 451, review authentication, CDN, firewall and regional rules first. For a repeated server error, check the server or storage that serves the file.

When to leave it as it is: A file that is deliberately limited to signed-in visitors or to a region can answer 401, 403 or 451 to the audit crawler. Keep the restriction if it is intended.

What we read

We read the original page HTML for img src and srcset, source src and srcset inside picture, video or audio, video src and poster, and audio src. Content inside head, script, style, template and noscript is not included. CSS images, files added by JavaScript and ordinary links are outside this check.

The shared resource collection requests each selected address within its existing request and byte limits. A verdict needs an actual GET response and a complete check of every attempt for known challenge-page markers.

Pages that declare the same normalized address form one group. The originally declared address is the identity of the item; a redirect of the file or a change in the list of pages does not create a new one.

Example & evidence

Illustrative example — one embedded image and its recorded response, not a live audit.

<picture>
  <source srcset="https://bakery.example/images/cake-wide.webp" type="image/webp">
  <img src="https://bakery.example/images/cake.png" alt="Layered cake">
</picture>

If the recorded GET request for https://bakery.example/images/cake.png answers HTTP 404 and no challenge marker is present, the report groups every known page that declares that address under it. The WebP alternative is a separate address with its own result.

A possible correction: restore this address or update each page that references it. A complete HTTP 200 response with a complete clear challenge check can pass the availability check; it does not establish that an image displays correctly.

Confirm & check again

Check for yourself: Open the reported address directly. View the source of the listed pages and find each reference to it, including srcset alternatives and poster attributes. For a restricted response, compare the result when signed out.

Check again: Full audit — Run a new full audit after the change is live. Closing the problem requires a complete clean comparison for the original asset and every page previously recorded as referencing it. A qualified HTTP 200 response, or completely read pages that no longer reference that asset, can close it. Missing pages, partial sources, unresolved challenges or an incomplete original page list cannot prove a fix.

Limits & sources

We check availability from the recorded response and complete challenge-marker evidence. We do not validate the media format, render the page or play the file; a successful response does not establish correct display.

HTTP 408, 425, 429 and other 4xx statuses, a single or inconsistent server error, a timeout, a challenge or bot-check page, a HEAD-only response, a partially retained response and an address the audit crawler was not permitted to request remain unconfirmed. They are not reported as broken and do not prove a fix.

Lazy-loading attributes such as data-src, references created by JavaScript, CSS images and content inside svg or math are not assessed. A page whose HTML inventory is incomplete or exceeds the audit's reading limits stays unconfirmed.

The response is the one the audit crawler received; a CDN, firewall or regional rule can answer a visitor differently. If an earlier audit could not record every declaring page, a later partial list cannot close the item.

Confidence: High Issue verdicts use exact recorded GET responses with complete challenge-marker checks. An access restriction has low confidence because it describes the audit crawler's access only.

Sources

• Google Crawling Infrastructure, How HTTP status codes affect Google's crawlers — Explains how Google handles HTTP client and server errors. The audit uses the narrower recorded-response conditions described here; this reference does not prove what a browser or Google received. Checked 11 October 2026.

Editorial review: 2 November 2026