How Google Actually Indexes an Image, Step by Step

Most image SEO advice is a list of things to do. It is much more useful to know what happens to an image after you publish it, because nearly every problem worth diagnosing is really the question which stage did this file stop at.

The pipeline has five stages, and they fail in characteristic ways.

Stage 1: Discovery

Google learns an image exists mostly by reading the HTML of pages it already crawls. The src of an img element is the primary path. Candidates listed in srcset are seen too. URLs listed in an image sitemap are a direct hint.

What is not reliably discovered:

• Images set as CSS background-image. These are decorative from the parser's point of view and routinely never enter image search, which surprises people whose hero is a background div.
• Images injected by client-side JavaScript that never produces a real img in the rendered markup.
• Images behind a query-string API, a signed URL, or an interaction like a click-to-load gallery.

The failure signature at this stage is total absence: the file is nowhere, not even as a stale result. If an image matters for search, it needs to exist as an img element in the served or rendered HTML, with a real src.

Stage 2: Fetch

Discovery only produces a URL. Fetching is a second, separate act, performed by Googlebot Image — a distinct user agent with its own crawl budget.

That separateness is responsible for a large share of quiet failures:

• A robots.txt rule that disallows an images directory, or a CDN hostname serving its own restrictive robots.txt that nobody has ever read.
• A firewall or bot-management rule that lets the main Googlebot through but rate-limits or blocks the image crawler.
• Hotlink protection that returns 403 to requests without a referrer.
• An X-Robots-Tag: noindex header applied at the asset level, often inherited from a directory-wide rule.

Where the files physically live changes the risk profile here, because a second hostname means a second set of rules to get wrong. That is the whole subject of choosing between same-origin, a CDN and a third-party image host, and the robots.txt on the image hostname is the single check most worth doing today.

It also explains the most common false alarm: images are crawled much less aggressively than pages, so a new image not appearing after a fortnight means almost nothing.

Stage 3: Deduplication

Once fetched, an image is compared against what is already known. Near-identical files are grouped, and one is treated as the representative.

Two consequences follow, and they are both frequently misunderstood.

Within a site, uploading the same photograph five times under five filenames does not create five opportunities. It creates one entry and four confusing duplicates. Across sites, a stock photograph licensed by hundreds of businesses is one grouped cluster, and the version that surfaces belongs to whichever page provides the strongest context. This is the mechanical reason a widely-licensed stock image almost never earns image traffic for a small site, and the mechanical case for generating original imagery instead of licensing the same file as your competitors.

It is also why the reusing-the-same-photo question has a calmer answer than people expect. Reuse is not a penalty. It just collapses into a single entry, which is fine when that was never the point of the image.

Stage 4: Understanding

Google then decides what the image is and what it is about. Those are different questions.

Content recognition is handled by machine vision and it is genuinely good. It knows a van, a door lock, a plate of food. It does not need alt text to identify subjects.

Contextual meaning is a different matter, and this is where your inputs land. The recognised signals are all textual and all on the page:

Signal	Weight	Notes
Alt text	High	The single clearest statement of what the image depicts
Surrounding text	High	Copy immediately before and after, and captions
Page title and headings	Medium	Establishes the topic the image is serving
Filename	Medium	Documented, modest, easy to get right
Structured data	Medium	Explicit, and required for some result types
Anchor text of links to the page	Low	Indirect
EXIF metadata	Low for ranking	Read for some purposes, not a ranking substitute

Two nuances matter more than the ordering.

First, machine vision identifying a subject is not the same as Google knowing the image is yours, taken there, showing your work. That claim lives in the surrounding text and in explicit markup, not in the pixels.

Second, some result formats require explicit markup rather than inferring it. Licence badges and the image-licence surfaces in particular need ImageObject markup with the licence fields populated — Google does not guess a licence, so if the metadata is not stated, the surface does not appear.

Stage 5: Serving

Finally, the indexed image becomes eligible to appear, and where it can appear has multiplied.

• Google Images. The classic surface. The result links to the containing page, which is why the page's own quality and indexability constrain the image entirely.
• Image blocks inside web results. Thumbnails shown alongside ordinary blue links, generally on visual queries.
• Google Lens and visual search. A camera-first entry point matching against the same index. The selection logic rewards clear subjects and unambiguous product identification, which is a meaningfully different optimisation target from text queries.
• Discover. Feed placement, heavily influenced by having a large, high-quality image available.
• AI answers and overviews. The newest surface and the least documented. What can be said is that images shown there are drawn from the same index, so being indexed remains the entry condition, and the rest is more guesswork than most write-ups admit.

The important structural point: all of these draw on one index. There is no separate Lens index to optimise for. Being crawled, fetched, deduplicated and understood is the shared prerequisite, and surface-specific work only matters after that.

Why a large library behaves differently

Everything above describes one image. A site with forty thousand of them experiences the same pipeline as a queue, and the queue behaves in ways that look like bugs.

Image crawl capacity is finite and shared across the site. Publish two thousand new images in a week and they will not be fetched in a week. They enter a backlog, processed at whatever rate the site's crawl allocation permits, and it is entirely normal for some to still be unfetched months later while others from the same batch were picked up in days. The ordering is not the order you published them, which is why partial indexing of a batch is expected rather than diagnostic.

Refresh is slower still. An image replaced in place at the same URL may serve its old version in search results for a long time, because recrawling an already-known asset is a lower priority than fetching an unknown one. This is the mechanism behind the recurring complaint that an updated logo or a corrected photograph is still showing the old version weeks later, and there is no lever to accelerate it.

Two practical consequences follow. First, publishing volume should be steady rather than bursty where you have the choice, because a steady stream is processed more predictably than a single dump. Second, if an image genuinely must change and must be seen to have changed, change the URL rather than the bytes — a new URL is a new discovery rather than a low-priority refresh, though it costs you whatever history the old URL had accumulated.

Both are arguments for getting the file right the first time rather than planning to revise, since revision is the slow path in every direction.

Diagnosing by stage

The pipeline turns a vague complaint into a short decision tree.

Not in image search at all. Check discovery and fetch. Is it a real img in the HTML? Does curl -I on the exact public URL return 200 with no noindex header? Does the image hostname's robots.txt allow it? Is the containing page itself indexed?

Indexed but never shown for relevant queries. Understanding. The file is known; the context is thin. Alt text, caption, and the paragraph around it are the levers.

A different image is chosen for the page. Also understanding, but relative. Whichever image has the clearest supporting text wins, and it is frequently a sidebar or author photo because those sit next to descriptive copy while the hero sits alone under a heading.

Was ranking, then disappeared. Something changed at fetch. A migration, a CDN swap, a plugin regenerating files at new URLs, a new firewall rule. Compare the current live URL against the one in your sitemap.

Everything looks correct and nothing has happened. Wait longer. Eight weeks is not a long time for image indexing, and impatience causes more damage here than neglect. A structured walkthrough of the full not-showing-in-Google-Images diagnosis covers the checks in order when the quick pass does not settle it.

What this changes about the work

Knowing the pipeline reorders the priorities most checklists get wrong.

Crawlability outranks everything, because stages two through five simply do not run without it, and it is the cheapest thing to verify. Page quality outranks image quality, because an image result is a link to a page and cannot outperform its destination. Context outranks the file, because machine vision already knows what the object is and what it needs from you is meaning. And patience outranks intervention, because the most common reason an image is not indexed is that not enough time has passed.

Where a sitemap fits is narrower than its reputation suggests: it is a discovery accelerator, not an indexing guarantee, and it pays off on large sites, cross-hostname setups and post-migration recovery. The honest account of when an image sitemap is actually worth building is worth reading before adding one out of obligation.

Everything else is ordinary craft. A descriptive filename helps at stage four and costs nothing. So does writing one honest sentence of alt text. The pipeline just tells you when that craft is the bottleneck and when something upstream is quietly discarding the file before any of it is read.