Google Image SEO: Discovery, Indexing, Context, and Performance Checks

Direct answer: A step-by-step audit that traces each image through HTML discovery, URL fetchability, hosting-page indexability, context, responsive markup, sitemap coverage, and CDN delivery, ending with a per-image acceptance record that separates discovery, indexing, context, and performance status.

Separate image indexing from page indexing

The central question this tutorial answers is narrow and practical: why do some images appear in Google Images while others on the same site do not, and how can each image be checked and fixed?

The answer is that image visibility depends on a chain of conditions — discovery in HTML, a fetchable image URL, an indexable hosting page, meaningful context, and acceptable delivery. Optimizing alt text alone addresses one link in that chain.

Start by accepting a distinction that most image SEO advice blurs. Image indexing is a separate state from page indexing.

Google’s image documentation describes how images are discovered and surfaced, and the Google Images help page frames owner actions as things that help images appear rather than guarantees that they will.

An indexable hosting page is a prerequisite for an image to be considered, not a promise that it will be indexed. That means a page can be fully indexed while several of its images are not, and you cannot detect that by checking the page alone.

Before touching any markup, write down the two statuses separately for one representative image: the hosting page’s index status and the image’s own index status.

If you have never checked the second one, that gap is the reason your audit has been inconclusive. The rest of this tutorial walks the chain in order, because a failure at any link makes every later check meaningless.

Trace HTML image discovery and src fallback

Discovery begins in the page markup. The `img` element’s `src` attribute is the primary path by which a crawler learns an image URL exists.

When you use `srcset`, you declare additional candidate sources at different widths or densities, and when you use the `picture` element, you declare sources that may be selected under different conditions.

Each of those is a discovery candidate, and each needs to be checked rather than assumed.

The failure route here is quiet. An `img` with a missing, empty, or placeholder `src` exposes no discoverable image URL at all, even though the rendered page may look correct because a script or a CSS background supplies the visual.

Likewise, an image injected only after user interaction may never be present in the HTML a crawler receives. When you audit, view the raw HTML response rather than the rendered DOM, and list every image URL the markup actually contains.

For each image, record which mechanism exposed it: `img src`, a `srcset` candidate, a `picture` source, or none.

That record becomes the discovery source field in your acceptance record, and it tells you where to look when an image is missing later in the chain.

If the discovery source is empty, stop here and fix the markup before continuing — no downstream check can compensate for an image URL that was never exposed.

Check image URL status and fetchability

Once you have a list of discovered image URLs, verify that each one returns a successful response when fetched directly. A URL that returns an error, or that redirects through a chain that terminates badly, cannot be retrieved as an image.

Fetch each URL the way a crawler would, without your browser session, cookies, or referrer, and record the status code.

Fetchability also depends on access rules. Robots directives can block image fetching, and a rule that blocks an image path will prevent retrieval even when the hosting page is allowed.

Check the rules that apply to your image directory separately from the rules that apply to your pages, because they are frequently configured by different people and drift apart over time.

Build a small per-image table at this stage with three columns: the image URL, the observed status code, and whether fetching was allowed or blocked. Mark each row as fetchable or blocked.

Only fetchable images proceed to the next check; blocked or failing images get a fix and a re-check, and you should note the fix in the record rather than silently overwriting the failure.

Confirm the hosting page is indexable

An image is considered in the context of the page that hosts it, so a hosting page that cannot be indexed removes the image from consideration regardless of how well the image itself is configured.

Check the hosting page for indexing blocks: a `noindex` directive, a robots rule that disallows the page path, or a canonical that points elsewhere and consolidates the page out of the index.

This check is where the separation from the first section pays off. You are not asking whether the page ranks; you are asking whether it is eligible to be indexed at all.

A page that is eligible but not yet indexed is a different problem from a page that is actively excluded, and the two require different responses. Record the hosting page’s indexability as a distinct field so you never confuse it with the image’s own status.

If the hosting page is excluded, the correct action is to resolve the exclusion or to move the image to a page that is eligible.

Do not attempt to fix image indexing while the hosting page is blocked, because the image cannot be evaluated independently of its page context. Once the page is eligible, return to the image and continue the chain.

Evaluate surrounding context and alt text

Context is how the image is described. Alt text is the primary machine-readable description, and the alt attribute reference frames it as the textual alternative for an image.

Page text, captions, and headings around the image contribute additional context that helps describe what the image depicts.

Google’s image guidance treats context and alt text as part of how images are understood, and vendor guides such as the Yoast image SEO page and the Ahrefs image SEO guide both emphasize context, captions, and descriptive alt text over keyword insertion.

The failure route is keyword stuffing. Alt text that repeats a target phrase instead of describing the image reduces clarity for users and provides a poor description of the image’s content.

Rewrite alt text so that it describes what is visible: the subject, the action, and any distinguishing detail that a reader would need if the image failed to load.

Then check the surrounding text — does the paragraph, caption, or heading actually relate to the image, or is the image decorative filler on an unrelated page?

Produce a before-and-after rewrite for one image as your worked example. Keep the before version in your notes so you can see what changed and why.

Record the final alt text and a short surrounding-context note in the acceptance record; those two fields are what let a later reviewer understand the image without reopening the page.

Verify dimensions, formats, and responsive markup

Responsive delivery is a common place where images become undiscoverable.

The responsive images reference explains that `srcset` and `sizes` let the browser choose an appropriate source, and that practice is sound — but the markup must still retain a discoverable source.

If your responsive implementation relies entirely on sources that are conditionally selected, confirm that at least one candidate remains exposed in the HTML and that the candidate URLs are the ones you verified earlier.

Dimensions and format affect whether the image renders and how it is delivered. An asset that is far larger than its display size wastes delivery budget, and a format that the requesting client cannot render may fail to display.

Check that the declared dimensions match the rendered dimensions closely enough to avoid layout shift, and that the format you serve is one the target clients support.

These are delivery decisions, not indexing decisions, but a broken render can undermine the image’s usefulness even when discovery and indexing are correct.

Use a short review checklist for each image: does the markup retain a discoverable source, do the declared dimensions match the rendered size, and is the format appropriate for the audience? Record dimensions and format in the acceptance record.

If responsive markup hides every source from the initial HTML, treat that as a discovery failure and return to the second section rather than patching it here.

Confirm image sitemap coverage

Image sitemaps are a supplementary discovery path.

Google’s image sitemap documentation describes how to declare image URLs alongside the pages that host them, which is useful for images that HTML discovery may miss — for example, images loaded by script or images whose markup is difficult to parse.

A sitemap does not replace HTML discovery; it adds a second route.

The failure route is drift. Sitemap entries that point to URLs that no longer exist, or that omit images you have since added, reduce coverage and can send crawlers to dead ends.

Validate that every image URL in the sitemap matches a live image URL you already verified, and that each entry names the hosting page correctly.

If an image appears only in the sitemap and not in the HTML, note that in the discovery source field so you know which path is carrying it.

Add or correct entries for images that HTML discovery missed, then re-check the sitemap against your verified URL list.

This step closes the discovery gap for images that would otherwise be invisible, and it gives you a second confirmation that your URL list is complete.

Check CDN ownership and delivery performance

If a content delivery network serves your images, its configuration is part of the chain. CDN settings can allow or block crawler access, and caching behavior affects how images are delivered.

Because image delivery is often owned by a different team than the one writing markup, access rules and cache policies can diverge from what the page-level configuration assumes.

Review the CDN configuration for the image host: confirm that crawler requests are not blocked, that cached responses serve the current asset, and that any performance optimization — such as lazy loading or deferred loading — does not prevent the image from being fetched.

Performance guidance for prominent images, such as the Largest Contentful Paint material, is about delivery speed; it is not indexing guidance, and a performance change that hides an image from crawlers trades one problem for a worse one.

Record CDN ownership and the access result in the acceptance record.

If the CDN blocks crawler access, that is a fetchability failure and you should return to the third section, because the image URL is effectively unreachable regardless of what the page markup says.

Record per-image acceptance status

You now have every input needed for the acceptance record. Use the embedded table below as the working artifact, one row per image, and fill it from your verified observations rather than from memory.

The record separates discovery, indexing, context, and performance so that a failure in one column does not get mistaken for a failure in another.

| Image URL | Hosting page URL | Discovery source (img, srcset, picture, sitemap) | Image URL status code | Hosting page indexability | Alt text | Surrounding context note | Dimensions and format | CDN ownership | Acceptance status | Unresolved gap | |—|—|—|—|—|—|—|—|—|—|—| | | | | | | | | | | | |

Fill one row per image.

Set acceptance status to accepted only when the image URL is fetchable, the hosting page is indexable, alt text and surrounding context describe the image, responsive markup retains a discoverable source, and CDN delivery does not block fetching.

If any column fails, leave the status as not accepted and write the specific gap in the final column — for example, a blocked image path, a noindexed hosting page, or a sitemap entry pointing to a missing URL.

Work through the chain in order for each image, because the columns are dependent: a discovery failure makes the status code column irrelevant, and a hosting-page exclusion makes context work premature.

When you finish a row, the unresolved gap column should either be empty or contain a single actionable item. If it contains several, split the work and re-audit rather than marking the image accepted on partial evidence.

Two boundaries apply to this record.

First, it documents eligibility and configuration, not ranking or appearance; Google states that standard SEO foundations apply to its features and that eligibility does not guarantee appearance, so an accepted row means the image is correctly configured, not that it will surface.

Second, the record is a snapshot. Markup, sitemaps, and CDN rules change, so re-run the audit after significant template, deployment, or infrastructure changes rather than treating a past acceptance as permanent.

With the record complete for one representative image, you have a repeatable procedure: trace discovery, verify fetchability, confirm page eligibility, describe the image, check responsive delivery, confirm sitemap coverage, review CDN access, and record the outcome.

The same sequence applies to every remaining image on the site, and the record is what turns a one-time fix into an auditable process.

Verified reference：[Google: Creating helpful, reliable, people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content)。

Next step

Apply the per-image acceptance record to one representative image now, then extend the same audit to the remaining images on the site.