Image SEO in the AI Era - Google Lens, Visual Search and Graphics Models Cite

Google Lens now processes close to 20 billion visual searches a month - Google announced that scale back in October 2024, and the number has only grown since. Circle to Search, the feature that lets you circle any part of the screen and search it without switching apps, runs on over 580 million Android devices according to Alphabet's CEO remarks from February 2026. This isn't a niche add-on to classic text search anymore - it's a separate, massive search surface with its own ranking rules, its own citation format, and its own mistakes that cost visibility.

Google Lens now processes close to 20 billion visual searches a month, and Circle to Search runs on over 580 million Android devices - images stopped being an afterthought to text and became a search surface of their own, with its own rules. Here's what alt text actually does (and doesn't do), how to wire images into ImageObject structured data, why an infographic built as HTML beats an infographic-as-image for citability, which file format to pick in 2026, and what the EU AI Act says about labeling AI-generated graphics.

The trouble is that most SEO guides still treat images as a side topic: "add alt text, compress the file, done." That was enough a decade ago. Today an image can be a standalone entry point into your brand (Lens, Circle to Search), an element evaluated separately by AI Overviews, a structured-data format with its own schema (ImageObject), and - if it's AI-generated - the subject of legal requirements around labeling synthetic content. Here's the whole picture, broken down.

Visual search is growing faster than text search

The scale isn't an accident - it's three things happening at once: smartphone cameras got good enough, multimodal models (Gemini) learned to recognize objects at near-human accuracy, and Google is actively pushing Lens and Circle to Search into every possible touchpoint (the address bar, the home button, the Google app). The biggest growth driver is product and local-place discovery - someone photographs shoes on a stranger's feet or a restaurant's storefront and wants to know where to buy or eat. A growing share of these queries is also multimodal: a photo plus typed text ("find this in size 39").

The practical takeaway: if you sell anything physical or run a location-based business, a product photo or storefront image is now a standalone discovery channel, independent of whether your page ranks well in classic text search.

What alt text actually does (and doesn't do)

This is one of the most repeated myths in SEO: that alt text boosts a page's position in Google's text results. It doesn't. Google has confirmed directly (John Mueller, Google Search Central) that alt text is a ranking factor only for Google Image Search - in classic text search it's treated like regular on-page text, with no extra weight. That doesn't mean it's not worth writing - it means you have to write it for the right reason: accessibility for screen readers and visibility in image search and Lens, not as a way to stuff extra keywords under a text page.

Three layers actually matter, but each in a different place: alt text (descriptive, matching the surrounding paragraph's context, no keyword stuffing) for accessibility and image search; the filename (descriptive-red-shoe-product.jpg instead of IMG_4821.jpg) as an additional context signal readable by both the search engine and models processing the page; and textual proximity - an image placed next to the paragraph that actually describes it reinforces both signals at once, because the search engine and the model both see the match between what the image shows and what the page claims.

ImageObject structured data - connecting the image to the rest of the page

Schema.org defines ImageObject as a distinct type with properties that describe the image directly: contentUrl (the file address), caption, creator, license, and representativeOfPage (whether it's the main image representing the whole page). In practice you rarely add it standalone - more often as an array in the image field inside Article or Product schema - which tells the search engine directly which image is primary and which are supporting, and lets it pick the right crop for image results or Google Discover.

Infographics models actually cite - a case from this blog

Here's something most guides skip: vision-capable models (including the ones behind AI Overviews) can now "read" the data inside an infographic image and cross-reference it against the page's surrounding text - and the closer the semantic match between what the graphic shows and what the surrounding text says, the higher the odds of citation. The catch: that's still a visual read, effectively OCR and shape recognition on a raster image - with room for error, extra compute cost on the model's side, and dependence on render quality (compression, resolution, text-to-background contrast).

The infographics on this blog - the same stat blocks and numbered-step lists you see in this and every other post - are deliberately built differently: they're not images, they're server-rendered HTML/CSS components. The numbers, labels and descriptions exist as plain text in the page's DOM, not as pixels to be recognized. The result: zero dependency on OCR, zero quality loss from compression, and the data is 100% available to any crawler or model with no image-recognition step - while the same data point also appears in a plain sentence right next to it, so even a system that ignores the page's visual layer still gets the information. If your site relies mainly on infographics-as-images, it's worth weighing exactly this trade-off: an image is more "designed" and visually universal, but an HTML component is cheaper to generate, lighter, and more reliably citable.

File formats and performance - the bridge to Core Web Vitals

Image format choice isn't a direct ranking factor, but it feeds into Core Web Vitals - and those are, especially Largest Contentful Paint (LCP), which I cover separately in the Core Web Vitals guide. AVIF produces files roughly 20-30% smaller than WebP at equivalent visual quality, and up to 50% smaller than JPEG, but it encodes more slowly - a compression pass that takes under a second in WebP can take 10-40 seconds in AVIF, which matters when generating thousands of files in a pipeline. WebP, in turn, decodes faster and cheaper on the device side, which matters on weaker phones. The practical recommendation for 2026, matching Google's own guidance: serve AVIF as the first choice, WebP as the fallback for browsers without AVIF support, JPEG as the last safety net - most modern CDNs and frameworks (Next.js included) handle this automatically via the picture element or a built-in image loader.

AI-generated images and the duty to label them

Since August 2, 2026, Article 50 of the EU AI Act requires providers of systems that generate synthetic content to mark it in a way that's machine-readable and automatically detectable - with a transition period until December 2, 2026 for systems already on the market before August. In practice this most often means C2PA (Coalition for Content Provenance and Authenticity) metadata - a kind of digital passport for the file showing what generated it and what edits it went through - often paired with an invisible pixel-level watermark such as Google DeepMind's SynthID, which survives compression and cropping, unlike metadata alone, which can be stripped by saving in a different format. OpenAI announced in May 2026 that it joined C2PA as a "Conforming Generator" and built SynthID into every image generated through ChatGPT, its API, and Codex - a dual-layer approach where the metadata and the watermark complement rather than replace each other.

For a site owner publishing AI-generated graphics (covers, illustrations, product imagery), the practical takeaway is simple: if the tool you use already embeds C2PA and SynthID (as ChatGPT has since May 2026), your job is just not to strip that metadata during further file processing - not to add it manually. If you generate graphics procedurally instead (charts or illustrations produced by code rather than a diffusion model) - like the infographics and covers on this blog - you fall outside the scope of the regulation covering AI-model-generated synthetic content, but it's worth understanding the distinction before someone asks.

How to choose - four scenarios

1. 1.A store or local business → prioritize high-quality product/storefront photos, descriptive filenames and alt text, ImageObject inside Product schema - this is a direct channel from Lens and Circle to Search.
2. 2.A blog or content marketing site with data → consider infographics as HTML components instead of images wherever possible - cheaper to generate, more reliably citable.
3. 3.A large image catalog, performance-focused → roll out an AVIF → WebP → JPEG cascade and measure the effect on LCP before and after.
4. 4.You publish AI-generated graphics → check whether the tool already embeds C2PA/SynthID; if it does, just make sure further file processing doesn't strip that metadata.

A step-by-step implementation plan

1. 1.Audit images on key pages: missing alt text, IMG_XXXX-style filenames, no ImageObject in the schema.
2. 2.Fix alt text and filenames where they matter most for image search and Lens - start with product and local-business pages.
3. 3.Add ImageObject (or an image array) to existing Article/Product schema instead of building a separate, disconnected structured-data block.
4. 4.Wherever you publish numeric data, consider an HTML component instead of an infographic-as-image - measure the difference in generation time and page weight.
5. 5.Roll out modern file formats in a cascade (AVIF/WebP/JPEG) and measure the effect on LCP under real conditions, not just in a lab.
6. 6.If you publish AI-generated graphics, check the tool's policy on C2PA/SynthID and make sure your publishing pipeline doesn't strip that metadata.
7. 7.Measure the effect after a quarter in Google Search Console's Images tab, and in Lens traffic data if you collect it.

---

I audit and optimize the image layer for visibility in Google Image Search, Lens and AI Overviews - from alt text and structured data, through format choice, to the image-versus-HTML-component decision for data-driven content. I do this as part of technical SEO and content marketing SEO. I teach it in the SEO & GEO course. Get in touch - I'll start with an image audit of your most important pages.

Worth reading next:

• Core Web Vitals - How to Improve LCP, INP and CLS
• Schema.org Structured Data - The Complete Guide
• Google AI Overviews & AI Mode - How to Optimize Your Site
• How to Write Content AI Cites