Ranking in Google Images

TL;DR — Ranking in Google Images is about getting your pictures to show up in Google’s image search and in Google Lens (the camera/visual search). Before an image can rank, it has to be found and indexed: it can’t be blocked in your robots.txt, it has to be in a normal image format, and it has to be a real <img> on the page — not a CSS background. After that, the things that help it rank (good alt text, a descriptive filename, the words around it) are the same basics I cover in the alt text and filename guides.

What “ranking in Google Images” means

Google Images is Google’s picture-search tab, and Google Lens (and Circle to Search) is the camera version — point your phone at something and Google finds it. Both pull from the same pile of indexed images. “Ranking in Google Images” just means getting your images into that pile and then surfaced when someone searches.

This is a companion to my general image SEO guide — that one is the full optimization checklist (formats, compression, lazy loading). This one is narrower: it’s about the image-search system — what gets an image indexed, what gets it shown, and what earns it a special badge.

Get the basics in place first

An image can’t rank if Google can’t index it. Three things have to be true:

• It’s not blocked in robots.txt. If you disallow the image file (or its folder), Googlebot-Image can’t fetch it, and it will never appear in Google Images. This is the single most common reason images don’t show up.
• It’s in a format Google supports — BMP, GIF, JPEG, PNG, WebP, SVG, or AVIF.
• It’s a real <img> on the page. Google only pulls images out of the src attribute of an <img> tag. An image set as a CSS background-image won’t be indexed.

The one thing most people miss

Google indexes the mobile version of your page. So if your mobile site drops an image, swaps in a smaller one, or loses its alt text, that’s what Google sees — no matter how good your desktop version looks. There’s no separate “mobile-friendly images” rule; it’s just that the mobile version is the one that counts.

What actually helps an image rank

The clues Google uses to understand an image are the ones I cover in the deep dives: good alt text, a descriptive filename, and the text right around the image. One extra tip from Google’s own team: write alt text that adds context, not just a label — “the beach before the chemical spill” beats “a photo of a beach,” because people searching images usually want the information attached to the image, not just any picture.

Want the technical version — image sitemaps, structured data and the Licensable badge, why canonical tags don’t apply to images, and how Google Lens works? Switch to the Advanced tab.

TL;DR — Ranking in Google Images is downstream of general image SEO — it’s about the image-search system, not another optimization checklist. First clear the indexing prerequisites: not blocked by robots.txt → supported format (BMP/GIF/JPEG/PNG/WebP/SVG/AVIF) → extracted from <img src> (never a CSS background). Then the ranking signals (alt text, surrounding text, filename, uniqueness) — covered in the alt text and filename deep dives — do the work. “Mobile-friendliness” isn’t a separate Images rule; it’s a consequence of mobile-first indexing, so the mobile version must carry the same images and alt text. Image sitemaps are a discovery aid, not a ranking lever. Structured data unlocks rich treatment: ImageObject with a license property gates the Licensable badge; Product structured data feeds Google Lens / Shopping Graph. rel=canonical does not apply to images — Google matches visually similar versions automatically. Lens now runs ~20 billion visual searches a month (20% shopping); C2PA content credentials can label AI images via “About this image.”

Where this fits: one indexed corpus, several surfaces

Google Images, the inline image results in web search, and Google Lens / Circle to Search all draw from the same indexed-image corpus. Optimizing for “Google Images” therefore also feeds visual search. This article is the ranking/visibility deep dive that complements my image SEO hub: the hub is the general optimization checklist; this is about the mechanics of the image-search system itself — what gets an image indexed, what gets it surfaced, and what earns it a badge.

The strategic starting point Google’s John Mueller recommends is worth adopting before any of the mechanics: “think about what do you think people would search for in a visual way to come to your website” (Search Off the Record ep. 48). If nobody searches visually for what you publish, image SEO isn’t your highest-leverage work.

The indexing prerequisites (before ranking even applies)

An image can rank only after it’s indexed, and indexing has gates. In order:

• Not blocked by robots.txt. If the image URL or its directory is disallowed, Googlebot-Image can’t fetch it, so it can’t appear in Google Images — full stop. This is the most common self-inflicted cause of “my images don’t show up.”
• Crawlable at a reasonable file size. Image Search’s crawler tolerates far larger files than something like favicon fetching, per Google’s technical requirements, but sensibly compressed, right-sized images still matter for crawl efficiency and page speed.
• A supported format — BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF (AVIF was added in August 2024).
• Extracted from <img src>. Google: “Google can find images in src attribute of <img> element.” It pulls images from the src of an <img> (including <img> inside <picture>) — not from CSS background-image. Google’s docs explicitly clarified this: they “occasionally get questions about” it, and images are only extracted from the src attribute of img tags.

Clear those and the image is eligible. Ranking is a separate question.

The ranking signals (briefly — the mechanics live in the deep dives)

I won’t re-litigate alt text and filenames here because each has its own article. The short version, with the differentiated framing from Google’s own team:

• Alt text — the primary signal, covered in full in my alt text guide. The nuance most guides miss: write alt text for context, not just description. Mueller: “don’t just be like, ‘Oh, this is a photo of a beach.’ But rather like, ‘This is the beach before the chemical spill happened’… when you’re talking about Image Search, it’s not that people want an image, but rather they want information which is attached to that image.”
• Surrounding text, captions, and placement — Google: “Make sure images are placed near relevant text and on pages that are relevant to the image subject matter.” This is the leg of the stool most checklists underweight relative to alt text.
• Filename — a lighter signal, covered in my image filenames guide. Mueller put its weight in perspective: descriptive filenames are good, “but I don’t think you would see a significant change if you already do the other things around images, like the alt texts, the text surrounding the image. Those are really, really strong signals.”
• Uniqueness — a stock photo used decoratively simply won’t rank you for that image’s query, because dozens of other licensed sites use it — but per Mueller it “doesn’t count against” the rest of your page or site.

Mobile-first indexing and image visibility

You’ll see “mobile-friendliness” listed as a Google Images ranking factor. That’s imprecise. The real mechanism is mobile-first indexing: Google indexes the mobile-rendered version of your page — including whatever images and alt text that version actually contains — because mobile-first indexing has landed for essentially the whole web. Google’s mobile-first guidance tells you to make sure the mobile site has the same content (text, images, videos, links) and the same alt text as desktop.

So the practical check isn’t “is my page mobile-friendly?” in the abstract — it’s: does my mobile page actually serve the same image, at the same URL, with the same alt text as desktop? A site that strips images on mobile, or serves lower-res/different images there, is functionally invisible to image search regardless of what desktop shows.

Image sitemaps: what they do (and don’t do)

Image sitemaps are a discovery aid — not a ranking lever and not a way to speed up re-crawling. Google: “Image sitemaps are a way of telling Google about other images on your site, especially those that we might not otherwise find (such as images your site reaches with JavaScript code).” They earn their keep for JS-loaded images and CDN-hosted images.

The short version: <image:image> encloses all information about a single image inside the <url> block, <image:loc> is the image URL, each <url> tag can hold up to 1,000 <image:image> tags, and — unlike a regular sitemap — an image sitemap can point to a different domain (e.g., a CDN), “as long as you verify both domains in Search Console.” On May 6, 2026, Google removed four sub-tags from its documentation — <image:caption>, <image:geo_location>, <image:title>, and <image:license>; the sitemap mechanism itself isn’t deprecated, those four tags just no longer do anything, so don’t let old blog posts talk you into using them. Mueller has also been candid that sitemaps won’t speed up re-crawling of images Google already knows about — on image sitemaps specifically, “Personally, I don’t think this would change much, in our case.” Treat them as a discovery aid for images Google can’t otherwise find, not a re-crawl accelerator. For the full tag reference, the namespace declaration, and file-format mechanics, see my image sitemap guide — this section only covers what a sitemap does for Google Images visibility, not how to build one.

Structured data and rich treatment in Google Images

Structured data is what unlocks badges and richer display in Google Images. Google: “If you include structured data, Google can display your images in certain rich results, including a prominent badge in Google Images,” and “the image attribute is a required field to be eligible for a badge.” Eligibility is type-specific — Recipe, Product, and Video structured data each unlock different treatments, and you have to follow both the general and the type-specific guidelines or the markup is ineligible. Note the word eligible: valid markup makes a badge or rich treatment possible, it doesn’t guarantee Google will actually show it — the same eligibility-not-guarantee boundary that applies to every other rich result type.

The Licensable badge — the exact gating detail

Most guides oversimplify this to “just add ImageObject schema.” The precise requirements from Google’s image license metadata docs:

• contentUrl is always required — “Google uses contentUrl to determine which image the photo metadata applies to.”
• license specifically is what gates the badge: “If you’re using structured data to specify an image, you must include the license property for your image to be eligible to be shown with the Licensable badge.” The other properties (creator, creditText, copyrightNotice) add detail to the metadata panel but don’t independently unlock the badge.
• acquireLicensePage is recommended — a URL where users can find out how to license the image.

You can supply this via schema.org structured data or embedded IPTC photo metadata (or both); where they conflict, “Google will use the structured data information.” The general ImageObject / structured-data mechanics are also covered in my image SEO hub.

Product structured data → Google Images + Google Lens

For e-commerce, Product structured data is the mechanism that makes a product image eligible for Lens visual-match and shopping surfaces. Google: “When you add structured data to your product pages, your product information can appear in richer ways in Google Search results (including Google Images and Google Lens),” and “Providing both structured data on web pages and a Merchant Center feed maximizes your eligibility.” A Merchant Center feed isn’t strictly required for basic free-listing eligibility, but combining the two is Google’s explicit recommendation. (The full markup mechanics live in my product schema guide.)

Preferred thumbnail: schema.org and og:image

A common practitioner question is “how does Google pick which image to show as my thumbnail?” As of a March 2, 2026 documentation update, Google clarified that it “uses both schema.org markup and the og:image meta tag as sources when determining image thumbnails in Google Search and Discover.” So both are worth setting deliberately. (Note the scoping caveat: the image property in Recipe structured data only controls recipe rich results, not general text-result thumbnails — a type-specific property isn’t a global override.)

No canonical tags for images

This one surprises people and is almost absent from competitor content: rel=canonical does not apply to images. Mueller, directly: “For images, the rel=canonical is essentially irrelevant. It’s really more for web pages. And I don’t think we even support it for images… Our systems try to recognize when the image is the same thing. And having multiple images indexed for one thing is perfectly fine.”

So you don’t need consolidation markup to tell Google that two crops or sizes are “the same” image. Google’s systems “look at the image and try to find visually similar images, and they kind of connect it like that.” Multiple sizes/crops can all be indexed simultaneously as valid, separate results. This is the image-search counterpart to canonicalization for web pages — except here it happens automatically and there’s no tag to set.

A related consequence: the same photo posted to your own site and to social media (Instagram, etc.) may get folded together as duplicates in Image Search, even though the surrounding web pages remain distinct results in regular Web Search. And uploading first does not make your site “the canonical” source — per Mueller, “I don’t think it works that way.” There’s no first-mover canonical mechanism for images.

Individual image landing pages

If you want a specific image to be independently findable, give it its own landing page with unique descriptive text — not just a spot in a 50-image gallery. Mueller’s framing (from Search Off the Record ep. 97, his and Martin Splitt’s photographer episode): a dedicated landing page lets Google understand “This is the primary image of this page, and here is some additional information about this image,” whereas a gallery page with 50 images and a bit of text reads ambiguously — “is this an image landing page that someone might be looking for? Which perhaps not.” JS-fragment galleries that never give each image a real, crawlable URL are a concrete failure mode here.

Two quick myth-busters from the same episode: watermarking is not penalized (Mueller: “No… That’s fine.”), and responsive/high-res images and good Core Web Vitals are good practice but not a ranking shortcut — “just because you’re doing these good practices, you’re not going to rank for underwater photography Switzerland automatically… You have to do more.”

Google Lens and visual search

Google Lens layers visual matching (finding visually similar images/products across the web) and multisearch (image + text together) on top of the same indexed-image corpus. The scale is real: per Google’s October 2024 announcement (Lilian Rincon, VP of Product Management), Lens handles nearly 20 billion visual searches monthly, 20% of Lens searches are shopping-related, and Lens “merges the power of Google’s AI and more than 45 billion products in the Shopping Graph to help you discover visual matches.”

A note on numbers: various 2025–2026 SEO posts cite larger or fresher figures (“20+ billion,” “43% increase”) that I couldn’t trace to a primary Google source — treat those as industry-repeated. The Oct 2024 Google figures above are the solid anchor.

For getting a product image into Lens shopping results, the mechanism is the Product structured data covered above, ideally combined with a Merchant Center feed. There’s no separate “Lens SEO” surface to optimize — you optimize the indexed image and its structured data, and Lens draws from that.

AI-image labeling: C2PA and “About this image”

Publishers using AI-generated imagery ask whether it hurts visibility. As of current guidance: not directly. Google reads C2PA content-credential metadata and can label AI-generated or AI-edited images via the “About this image” panel, which — per Google’s September 2024 announcement (Laurie Richardson, VP, Trust & Safety) — “is accessible in Google Images, Lens and Circle to Search.” Google Search added support for this metadata in the “About this image” feature. This is a transparency/labeling layer, not a documented ranking penalty — worth knowing because it can label your AI imagery as such in the same surfaces you’re optimizing for.

Bing image search (brief)

There’s no dedicated official Bing/Microsoft documentation on image-search SEO — Bing’s general webmaster guidelines and standard crawlability/alt-text/structured-data practices are the closest thing. Bing is actively investing here: it shipped a redesigned, AI-organized Image Search experience in May 2026 that groups results into labeled sections with summaries, though that announcement is a product/UX update with no accompanying optimization guidance for site owners. Optimize with the same fundamentals you’d use for Google.

Where to go next

This is the ranking/visibility deep dive in the image-SEO cluster. Its siblings:

• Image SEO — the hub: the general optimization checklist (formats, compression, lazy loading, Core Web Vitals) this article complements.
• Alt text — the primary ranking signal, in full: writing rules, decorative images, and auditing at scale.
• Image filenames — the filename signal, including why you shouldn’t bulk-rename already-indexed images.

AI summary

A condensed take on the Advanced version:

• This is the image-search system, not another optimization checklist. Google Images, inline image results, and Google Lens / Circle to Search all draw from one indexed-image corpus. It complements the general image SEO hub (which covers formats, compression, loading).
• Indexing prerequisites, in order: not blocked by robots.txt → crawlable/reasonable file size → supported format (BMP/GIF/JPEG/PNG/WebP/SVG/AVIF) → extracted from <img src> (never a CSS background-image).
• Ranking signals (covered in the alt text and filename deep dives): alt text — write for context, not just description; surrounding text/captions/placement; filename (a lighter signal); uniqueness (stock won’t rank you but doesn’t hurt you).
• Mobile-first indexing, not a “mobile-friendly” rule: Google indexes the mobile version, so the mobile page must carry the same images and alt text as desktop.
• Image sitemaps are a discovery aid (JS-loaded, CDN-hosted images), not a ranking or re-crawl lever. Cross-domain URLs allowed if both domains are verified; 1,000 <image:image> per <url>. Four sub-tags (caption, geo_location, title, license) were dropped from the docs May 6, 2026 — don’t use them.
• Structured data → rich treatment: ImageObject needs contentUrl always, and license specifically to gate the Licensable badge; Product structured data feeds Google Images + Lens / Shopping Graph (pair with Merchant Center for max eligibility). Thumbnails: Google uses both schema.org and og:image (March 2026 clarification).
• No canonical for images: rel=canonical doesn’t apply; Google auto-matches visually similar versions, so multiple crops/sizes can all be indexed. Same photo on your site + social may fold as duplicates in Image Search; uploading first doesn’t make you canonical.
• Individual image landing pages beat a 50-image gallery for making one image findable. Watermarking isn’t penalized.
• Google Lens: ~20B visual searches/month, 20% shopping (Google, Oct 2024); 45B+ products in the Shopping Graph. C2PA / “About this image” labels AI-generated images across Images, Lens, and Circle to Search — a transparency layer, not a ranking penalty.

Official documentation

Primary-source documentation from Google.

Google — image search and structured data

• Image SEO best practices — the core reference: discovery via <img src>, supported formats, filenames, alt text, surrounding text, image quality, structured data, and preferred-image selection.
• Image sitemaps — <image:image> / <image:loc>, the 1,000-per-URL limit, and cross-domain (CDN) URLs.
• Image license metadata — ImageObject, contentUrl, the badge-gating license property, and acquireLicensePage.
• Product structured data — how product markup feeds Google Images and Google Lens, and why pairing with a Merchant Center feed maximizes eligibility.

Google — indexing pipeline and freshness

• Mobile-first indexing best practices — matching images and alt text across mobile and desktop.
• Mobile-first indexing has landed — mobile-first indexing is complete for essentially the whole web.
• Technical requirements — crawler fetch thresholds, which vary widely by product (Image Search tolerates larger files).
• Latest documentation updates (changelog) — the AVIF format addition (Aug 2024), the <img src>-only clarification, the May 2026 image-sitemap sub-tag removals, the March 2026 preferred-image (og:image + schema.org) clarification, and the C2PA “About this image” support entry.

Google — Lens and AI-image transparency (The Keyword)

• Lens gets more helpful with visual matches and shopping features (Oct 2024) — ~20B visual searches/month, 20% shopping, 45B+ Shopping Graph products.
• How Google and the C2PA are increasing transparency for gen AI content (Sept 2024) — “About this image” across Google Images, Lens, and Circle to Search.

Quotes from the source

On-the-record statements from Google. Where a page exposes the text, the link is a deep link that jumps to the quoted passage.

Google docs — indexing and surrounding text

• “Google can find images in src attribute of <img> element.” — Google Search Central docs. Jump to quote
• “Make sure images are placed near relevant text and on pages that are relevant to the image subject matter.” Jump to quote
• “If you include structured data, Google can display your images in certain rich results, including a prominent badge in Google Images.” Jump to quote

Google docs — image sitemaps

• “Image sitemaps are a way of telling Google about other images on your site, especially those that we might not otherwise find (such as images your site reaches with JavaScript code).” Jump to quote

Google docs — the Licensable badge (the gating detail)

• “You must include the license property for your image to be eligible to be shown with the Licensable badge.” Jump to quote
• “Google uses contentUrl to determine which image the photo metadata applies to.” Jump to quote

Google docs — Product structured data → Images and Lens

• “When you add structured data to your product pages, your product information can appear in richer ways in Google Search results (including Google Images and Google Lens).” Jump to quote

Lilian Rincon, Google (The Keyword, Oct 2024) — Lens

• “Lens merges the power of Google’s AI and more than 45 billion products in the Shopping Graph to help you discover visual matches.” Read the announcement

Laurie Richardson, Google (The Keyword, Sept 2024) — AI-image labeling

• “‘About this image’ helps provide people with context about the images they see online and is accessible in Google Images, Lens and Circle to Search.” Read the announcement

John Mueller, Google — Search Off the Record ep. 48 (Oct 2022)

• On context in alt text: “don’t just be like, ‘Oh, this is a photo of a beach.’ But rather like, ‘This is the beach before the chemical spill happened.’… when you’re talking about Image Search, it’s not that people want an image, but rather they want information which is attached to that image.”
• On filenames vs. stronger signals: “having descriptive filenames is good, but I don’t think you would see a significant change if you already do the other things around images, like the alt texts, the text surrounding the image. Those are really, really strong signals.”
• On rel=canonical for images: “For images, the rel=canonical is essentially irrelevant. It’s really more for web pages. And I don’t think we even support it for images.”
• On image sitemaps and re-crawl speed: “There’s also image sitemap files, which people sometimes use for that. Personally, I don’t think this would change much, in our case.” Episode transcript

John Mueller, Google — Search Off the Record ep. 97 (Aug 2025)

• On individual image landing pages: “if you’re interested in having your images individually findable, definitely make individual landing pages.”
• On watermarking: “No… That’s fine.”
• On Core Web Vitals not being a shortcut: “just because you’re doing these good practices, you’re not going to rank for underwater photography Switzerland automatically… You have to do more.” Episode transcript

”Why isn’t my image ranking in Google Images?” — a decision tree

Work top to bottom; the first “no” is usually your problem.

1. Is the image blocked in robots.txt? → If the image URL or its directory is disallowed, Googlebot-Image can’t fetch it. Unblock it. This is the most common cause. If it’s allowed, continue.

2. Is it a real <img> with a src — not a CSS background? → Google only extracts images from the src of an <img> element (including inside <picture>). A CSS background-image is invisible to image search. Move it into an <img>. If it’s already an <img>, continue.

3. Is it in a supported format? → BMP, GIF, JPEG, PNG, WebP, SVG, or AVIF. If it’s something exotic, convert it. If it’s fine, continue.

4. Does your mobile page actually include this image (same URL, same alt text)? → Google indexes the mobile version. If mobile drops the image, swaps a different/lower-res one, or loses the alt text, that’s what Google sees. Achieve mobile/desktop parity. If parity is fine, continue.

5. Is Google discovering the image at all? → If it’s loaded via JavaScript or hosted on a separate CDN domain, add an image sitemap (verify the CDN domain in Search Console). Confirm discovery in the URL Inspection tool. If it’s discovered, continue.

6. Does it have real ranking signals — descriptive alt text, relevant surrounding text, a good filename — and is it unique? → If the image is a widely used stock photo, you won’t rank for its query no matter what (many licensed sites have the same file). Otherwise, strengthen alt text and page context (see the alt text and filename guides).

Want a badge or Lens shopping visibility instead of plain ranking?

• Licensable badge: add ImageObject with contentUrl and the license property (acquireLicensePage recommended).
• Google Lens / shopping: add Product structured data; pair with a Merchant Center feed for maximum eligibility.

Ranking in Google Images — cheat sheet

Indexing prerequisites (all must be true)

Ranking signals (covered in the deep dives)

Rich treatment

Fast facts

• No rel=canonical for images — Google auto-matches visually similar versions; multiple crops/sizes can all be indexed.
• Image sitemaps = discovery aid (JS/CDN images), not a ranking or re-crawl lever; 1,000 <image:image> per <url>; cross-domain OK.
• Deprecated May 2026: <image:caption>, <image:geo_location>, <image:title>, <image:license> — dropped from docs; don’t use.
• Google Lens: ~20B visual searches/month, 20% shopping (Google, Oct 2024).
• C2PA / “About this image” labels AI-generated images — transparency layer, not a ranking penalty.
• Watermarking is not penalized (Mueller).

Google Images visibility — checklist

A pass to confirm an image can be indexed, surfaced, and (optionally) badged:

• The image is not blocked in robots.txt and has no X-Robots-Tag: noindex.
• It’s a real <img> with a src (or <img> inside <picture>), not a CSS background-image.
• It’s in a supported format (BMP/GIF/JPEG/PNG/WebP/SVG/AVIF).
• The mobile version serves the same image, at the same URL, with the same alt text as desktop.
• The image has descriptive alt text written for context (see the alt text guide).
• There’s relevant surrounding text / a caption, and the page is on-topic for the image.
• The image is reasonably compressed and right-sized for its display dimensions.
• For JS-loaded or CDN-hosted images, an image sitemap is submitted (both domains verified in Search Console); no deprecated sub-tags (caption/geo_location/title/license).
• If a Licensable badge is wanted: ImageObject with contentUrl and license (acquireLicensePage recommended).
• If Lens / shopping visibility is wanted: Product structured data (ideally with a Merchant Center feed).
• Thumbnail control set via og:image and/or schema.org markup.
• Images you want individually findable have their own landing pages with unique text — not just a gallery slot.
• Checked in URL Inspection that Google actually discovered and indexed the image.

Google Images mistakes

• Using important images only as CSS backgrounds. Put indexable content images in <img src> or appropriate responsive image markup.
• Blocking image files or delivery hosts. Test robots rules and access controls for every image hostname used on mobile and desktop.
• Treating image sitemaps as a ranking boost. They aid discovery; relevance, page context, quality, and accessibility still matter.
• Applying rel=canonical to image files. Canonical is a page signal, not an image-deduplication control. Keep intentional variants and consistent references.
• Removing images from mobile output. Mobile-first indexing means the mobile page must carry the images, alt text, and surrounding context you want evaluated.

An image never appears in Google Images

Likely causes: blocked file/host, unsupported delivery, CSS background use, missing discovery, or an unindexed host page. Fix: verify a public 200 image response, normal <img> markup, crawlable host page, and sitemap discovery where useful. Confirm: logs show crawler access and Search Console no longer reports the relevant page-level blocker.

Desktop images are present but mobile images are missing

Likely cause: responsive templates remove or replace them with inaccessible lazy-loading markup. Fix: preserve equivalent image content and alt text in mobile HTML and use standard src/srcset. Confirm: mobile raw/rendered output contains working image URLs.

The wrong image ranks for the page

Likely causes: stronger surrounding context, repeated boilerplate images, weak filenames/alt text, or inconsistent primary-image signals. Fix: make the intended image prominent, unique, well-described, and close to relevant text. Confirm: crawl extraction shows consistent markup; ranking selection still remains Google’s choice.

Licensable treatment does not appear

Likely causes: incomplete or mismatched licensing metadata, invalid structured data, or lack of eligibility/display selection. Fix: align visible license information and ImageObject properties, then validate. Confirm: markup passes and matches the page; validation cannot guarantee display.

Tools for Google Images SEO

• Image SEO Checker audits raw-HTML image signals, alt attributes, loading hints, formats, and ImageObject markup.
• Render Gap shows whether images and alt text exist before and after JavaScript rendering.
• robots.txt Tester checks access to image URLs and image-delivery paths.
• Schema Markup Validator validates ImageObject, licensing, and related product markup vocabulary.
• Search Console performance data can be filtered to Image search to measure impressions and clicks for the page cohort.

Prove an image SEO change

Source-discovery test

Test to run: inspect raw mobile and desktop HTML for the intended <img> and request its resolved src/srcset URL. Expected result: the image is present and returns a supported image with 200. Failure interpretation: discovery depends on CSS, JavaScript, or a broken variant. Monitoring window: immediate after deployment. Rollback trigger: primary images disappear or return errors on a key template.

Crawl-access test

Test to run: test page and image URLs against robots.txt and edge/security rules. Expected result: intended crawlers can fetch both. Failure interpretation: a host-level rule or CDN policy blocks image crawling. Monitoring window: every robots, CDN, or media-domain change. Rollback trigger: the fix exposes private media or blocks public pages.

Structured-data test

Test to run: validate pages using ImageObject, Product, or licensing properties and compare values with visible content. Expected result: markup is valid and describes the displayed image. Failure interpretation: the graph is incomplete or mismatched. Monitoring window: every schema-template release. Rollback trigger: misleading licensing or product data is published.

Metrics for image-search health

Image Search impressions and clicks

Metric: Search Console performance filtered to Image search. What it tells you: observed visibility and traffic from Google Images. How to pull it: segment pages, queries, countries, and devices for the affected cohort. Benchmark / realistic range: compare with the site’s own pre-change and seasonal baseline; no universal CTR target fits every image intent. Cadence: monthly. Before attributing a change to a specific fix: pull the page/query/device rows and check image fetch diagnostics first — Search Console segmentation tells you what moved, not why, so don’t credit one optimization (say, adding ImageObject) for a swing without ruling out seasonality, a template-wide change, or a crawl issue on the same date.

Crawlable primary-image coverage

Metric: intended pages whose primary images are present in raw mobile HTML, return 200, and are not blocked. What it tells you: whether indexing prerequisites hold across templates. How to pull it: crawl HTML, resolve image URLs, and test robots/status. Benchmark / realistic range: every intended primary image should pass, with documented exceptions. Cadence: every release and monthly.

Image fetch error rate

Metric: 4xx/5xx and access-denied responses for search-crawler image requests. What it tells you: whether delivery failures prevent discovery or refresh. How to pull it: CDN/origin logs grouped by image path and verified bot. Benchmark / realistic range: trend against the site’s normal baseline and investigate sustained regressions. Cadence: weekly for image-heavy sites.

Resources worth your time

My related writing

• Image SEO: 12 Actionable Tips for More Organic Traffic — Ahrefs’ general image SEO guide (filenames, alt text, formats, compression, sitemaps, responsive images, schema, lazy loading). Authored by my colleague Joshua Hardwick.
• The Beginner’s Guide to Technical SEO — where image search fits into the broader technical picture.

My speaking

• “Image SEO” (Visme webinar, 2021) — my dedicated talk on optimizing images for search.

Official

• Google’s Image SEO best practices — the canonical reference for everything on this page.
• Google’s Image license metadata — the exact Licensable badge requirements.
• Google’s Product structured data — the Google Images + Google Lens eligibility mechanism.

From around the industry

• Let’s Talk Image SEO (Search Off the Record ep. 48, Google, Oct 2022) — the primary transcript behind the alt-text-context, filename-weight, rel=canonical-doesn’t-apply, and image-sitemap points on this page.
• SEO for photographers (Search Off the Record ep. 97, Google, Aug 2025) — Martin Splitt’s own site as a live case study, with Mueller on individual image landing pages, watermarking, and Core Web Vitals.
• Lens gets more helpful with visual matches and shopping features (Google, The Keyword, Oct 2024) — the anchor stats for Google Lens scale and shopping intent.
• How Google and the C2PA are increasing transparency for gen AI content (Google, The Keyword, Sept 2024) — “About this image” AI-labeling across Google Images, Lens, and Circle to Search.

Test yourself: Ranking in Google Images

Five quick questions on how images get indexed, surfaced, and badged in Google Images and Lens. Pick an answer for each, then check.

Google Images SEO

Google Images SEO is the set of practices that get an image indexed and surfaced in Google Images and Google Lens / Circle to Search. It sits downstream of general image SEO and covers the image-search system itself: crawlability requirements (not blocked by robots.txt, supported format, extracted from an <img> src), discovery aids (image sitemaps), and eligibility for rich treatment (ImageObject / Product structured data, the Licensable badge).

Related: Image SEO, Alt Text, Image sitemap, ImageObject schema

Google Images SEO

Google Images SEO — often phrased as “ranking in Google Images” — is the set of practices that determine whether an image gets indexed and surfaced in Google Images (Google’s dedicated image-search vertical) and in Google Lens / Circle to Search, its camera-based visual-search surfaces. It sits downstream of general image SEO (alt text, filenames, page context) and focuses on the mechanics specific to the image-search system.

Those mechanics break into two layers. First are the indexing prerequisites that decide whether an image can appear at all: it must not be blocked by robots.txt, it must be in a supported format (BMP, GIF, JPEG, PNG, WebP, SVG, or AVIF), and it must be extracted from the src attribute of an <img> element — Google does not index CSS background-image. Because Google indexes the mobile-rendered version of a page (mobile-first indexing), the image and its alt text must be present on that mobile version.

Second are the eligibility and discovery aids that shape how an indexed image is surfaced: image sitemaps help Google discover images it might not otherwise find (JavaScript-loaded or CDN-hosted); ImageObject structured data with a license property unlocks the Licensable badge; and Product structured data feeds a product image into Google Lens visual-match and Shopping Graph surfaces. Google’s systems detect visually similar and duplicate images automatically, so — unlike web pages — rel=canonical does not apply to images.

Related: Image SEO, Alt Text, Image sitemap, ImageObject schema

Changelog