The Lens Reality Nobody Wants to Admit
Google Lens processed 27.4 billion visual queries in Q1 2026. Let that sit for a second. Twenty-seven billion. The internal benchmark data our agency pulled from three enterprise clients in February showed that between 11% and 19% of their product-image impressions in Google Search Console were now being attributed to Lens entry points, not traditional image search. These are not small brands. Combined monthly traffic: north of 8 million sessions.
Visual search did not replace text search. Anyone still framing it that way is selling something. What Lens actually did was carve out an entirely separate discovery surface inside the same SERP ecosystem, with its own ranking logic, its own trust signals, and its own relationship to structured data that differs in meaningful ways from what classic image SEO practitioners built their playbooks around.
I rebuilt two clients' image programs from near-scratch between August 2025 and March 2026. One was a mid-market home goods retailer with roughly 340,000 indexed images. The other was a specialty outdoor equipment brand that had approximately 62,000 product images, many of them user-generated and completely unoptimized at the metadata layer. The lessons from those two engagements inform everything in this piece.
None of this is theoretical.
What Actually Changed Between Late 2025 and Now
Lens Citations Are Now a Real Metric
Search Console's March 2026 update added a dedicated Lens performance report for accounts with verified Search Console access and more than 5,000 image impressions per month. The report surfaces what Google is calling "visual citations" — instances where a Lens query matched a crawled image and served it as part of a Lens result, even without a click. Think impressions, but for visual search specifically.
Before that update, we were blind. We were inferring Lens influence from anomalies in the image performance tab, cross-referencing with traffic from Google Discover, and doing a lot of guesswork. Now we have actual numbers. And those numbers revealed something uncomfortable: the site that had spent the most on traditional alt-text and filename optimization was getting meaningfully fewer Lens citations than the site that had done almost nothing on those dimensions but had clean, consistent IPTC metadata and well-structured ImageObject markup.
Correlation is not causation. I know this. But when you see that pattern across two completely separate verticals over a six-month window, you start questioning your priors.
The Visual Knowledge Graph Is Doing More Work
Google's visual knowledge graph, which links images to entities, products, and concepts rather than just crawled page context, is far more active in Lens ranking than it is in traditional image search. This matters because the signals that feed the visual knowledge graph are not the same signals that have historically dominated image SEO.
Page-level relevance signals? Still matter, but less so in isolation. What I'm seeing correlate with strong Lens citation rates: consistent entity identification across structured data, IPTC subject codes that align with knowledge graph categories, and image file provenance data that survives the compression pipelines most CDNs run by default.
File provenance. That is a sentence I would not have written two years ago.
ImageObject Impressions vs. Lens Citations: Different Animals
One of the clearest things I learned in early 2026 is that ImageObject impressions in Search Console and Lens citations are distinct performance signals, even when they originate from the same image file. An image can have high ImageObject impressions, meaning Google is showing it in rich results on the web, while generating almost zero Lens citations. The reverse is also true.
For the home goods client, we had 2.3 million ImageObject impressions in January 2026 against only 47,000 Lens citations. After restructuring the ImageObject markup and adding IPTC keyword data in February, that Lens citation count climbed to 214,000 in March, a 355% increase, while ImageObject impressions only moved from 2.3M to 2.6M. The gap between those two metrics is where the optimization opportunity lives right now.
The Mistake I Made With 40,000 Product Images
I will own this completely. When I started the outdoor equipment brand engagement in August 2025, I made a decision that cost us four months of progress.
I prioritized alt-text cleanup at scale. We ran an automated tool across roughly 40,000 product images and rewrote alt attributes based on product title, category, and a few modifiers. Thousands of images updated in about two weeks. It felt productive. It looked like progress.
It did almost nothing for Lens citations. And here is why: alt text lives in the HTML. Lens, when it crawls and indexes an image through its visual knowledge graph pipeline, is doing entity matching against the image file itself, the structured data in the page's JSON-LD, and the embedded metadata inside the image binary. HTML alt text is a tertiary signal at best for Lens, and possibly less than that.
We had spent significant budget moving a metric that Lens barely reads. The IPTC fields inside those 40,000 images were still a disaster. Inconsistent, missing, or worse, polluted with boilerplate copy from an old CMS export. That is where the real work was, and I waited too long to get there.
The lesson: do not sequence your image SEO priorities the way you would have in 2023. The stack has changed.
IPTC Metadata: The Signal Most Teams Are Skipping
Why IPTC Matters More Now
The International Press Telecommunications Council metadata standard was built for photojournalism. For years, the SEO industry basically ignored it outside of news and editorial contexts. That was defensible as recently as 2024. It is not defensible now.
Google's documentation for the visual knowledge graph explicitly references IPTC subject codes as one mechanism by which images are categorized at the visual index layer. This is separate from how pages are categorized. An image can be associated with visual knowledge graph entities that differ from the page's primary topic. The IPTC fields are one way that association gets formed.
The specific fields that appear to carry weight based on our testing: Caption/Abstract (IPTC field 120), Keywords (field 25), Subject Reference (field 12 — the subject code), and Creator (field 80). The Subject Reference field, specifically, takes structured codes from the IPTC NewsCodes taxonomy. For e-commerce, these map reasonably well to product category trees with some manual effort.
Embedding IPTC Metadata With ExifTool
ExifTool is the most reliable utility for batch IPTC embedding I have found. Below is the command pattern we use for embedding core fields into JPEG product images.
# Embed IPTC keywords and caption into a single image
exiftool \
-IPTC:Keywords="outdoor footwear, hiking boots, waterproof boots, trail footwear" \
-IPTC:Caption-Abstract="Waterproof hiking boots with Vibram outsole, designed for technical trail use. Mid-cut construction. Size range US 7-15." \
-IPTC:By-line="BrandName Photography" \
-IPTC:CopyrightNotice="Copyright 2026 BrandName Inc. All rights reserved." \
-IPTC:ObjectName="hiking-boots-waterproof-mid-sku-12847" \
-overwrite_original \
product-image-12847.jpg
# Batch process an entire product directory
exiftool \
-IPTC:Keywords="outdoor footwear, hiking boots, waterproof boots" \
-IPTC:By-line="BrandName Photography" \
-CopyrightNotice="Copyright 2026 BrandName Inc." \
-overwrite_original \
-ext jpg \
/path/to/product-images/category/hiking-boots/
# Verify IPTC data was written correctly
exiftool -IPTC:all product-image-12847.jpg
# Export all IPTC fields to CSV for audit
exiftool -csv -IPTC:all /path/to/product-images/ > iptc-audit.csv
One important caveat: most CDN image optimization pipelines strip IPTC metadata by default. Check your CDN's documentation. Cloudflare's Polish feature, for example, will strip metadata unless you explicitly configure it to preserve it. AWS CloudFront with Lambda@Edge image optimization has the same default behavior. You can embed perfect IPTC data and have it evaporate before Google ever crawls the image.
ImageObject Schema in 2026: What Still Works
The Schema That Still Pulls Weight
ImageObject structured data is not dead. Far from it. But the implementation pattern that worked well in 2024 is underperforming relative to a more complete implementation that ties ImageObject directly into the entity graph through identifier fields and explicit creator attribution.
Below is the ImageObject JSON-LD pattern we now use for product images on e-commerce clients. Note the addition of identifier, acquireLicensePage, and the nested creator object, all of which are fields that appeared to have no meaningful effect before Lens scaling but are correlating with higher Lens citation rates now.
{
"@context": "https://schema.org",
"@type": "ImageObject",
"@id": "https://www.example.com/images/products/hiking-boots-waterproof-mid-sku-12847.jpg",
"url": "https://www.example.com/images/products/hiking-boots-waterproof-mid-sku-12847.jpg",
"contentUrl": "https://www.example.com/images/products/hiking-boots-waterproof-mid-sku-12847.jpg",
"thumbnailUrl": "https://www.example.com/images/products/thumbs/hiking-boots-waterproof-mid-sku-12847-400w.jpg",
"name": "Waterproof Mid Hiking Boots - SKU 12847",
"description": "Waterproof hiking boots with Vibram Megagrip outsole and Gore-Tex lining. Mid-cut construction for ankle support on technical trails. Available US 7-15.",
"caption": "Waterproof hiking boots on white background, three-quarter view showing outsole detail and lacing system.",
"identifier": {
"@type": "PropertyValue",
"propertyID": "SKU",
"value": "12847"
},
"width": {
"@type": "QuantitativeValue",
"value": 1600,
"unitCode": "E37"
},
"height": {
"@type": "QuantitativeValue",
"value": 1600,
"unitCode": "E37"
},
"encodingFormat": "image/jpeg",
"uploadDate": "2026-01-15",
"dateModified": "2026-03-01",
"creator": {
"@type": "Organization",
"name": "BrandName Inc.",
"url": "https://www.example.com"
},
"copyrightNotice": "Copyright 2026 BrandName Inc.",
"acquireLicensePage": "https://www.example.com/image-licensing",
"creditText": "BrandName Product Photography",
"representativeOfPage": true,
"isPartOf": {
"@id": "https://www.example.com/products/hiking-boots-waterproof-mid"
}
}
The representativeOfPage field is worth calling out specifically. Setting it to true signals to Google which image is the primary representative image for the page, which matters when a product page has multiple images. We have seen this field correlate with that primary image being selected more consistently for Lens citations rather than secondary or tertiary product images that may have less descriptive context.
Nesting ImageObject Inside Product Schema
For product pages, the ImageObject should not stand alone. Nest it inside the Product schema's image property. When ImageObject is embedded inside a Product entity in structured data, the visual knowledge graph can associate the image directly with the product entity, which is a different and more powerful association than an image simply appearing on a page that happens to describe a product.
See our full guide to Product schema implementation for e-commerce in 2026 for the complete nesting pattern with multiple images.
EXIF and XMP: What to Scrub, What to Preserve
The Decision Tree
Not all metadata is worth preserving. Some of it actively hurts you. GPS coordinates in EXIF data are a privacy risk that also pollutes the image's entity signals with irrelevant geographic data. Camera make and model data is pure noise for Lens entity matching. But creator information, copyright fields, and subject descriptors in XMP have demonstrable value in 2026's visual search landscape.
Below is the ExifTool pattern we use for a selective scrub-and-preserve pass on images before upload. This strips problematic fields while keeping the signals that feed Lens.
# Scrub GPS data (privacy + signal pollution)
exiftool -GPS:all= -overwrite_original product-image-12847.jpg
# Scrub camera hardware metadata (noise, no SEO value)
exiftool \
-Make= \
-Model= \
-LensModel= \
-ExposureTime= \
-FNumber= \
-ISO= \
-FocalLength= \
-overwrite_original \
product-image-12847.jpg
# Preserve and standardize XMP creator fields
exiftool \
-XMP-dc:Creator="BrandName Photography" \
-XMP-dc:Rights="Copyright 2026 BrandName Inc. All rights reserved." \
-XMP-dc:Description="Waterproof hiking boots, mid-cut, Vibram outsole, Gore-Tex lining" \
-XMP-dc:Subject="hiking boots, waterproof footwear, trail gear, outdoor footwear" \
-XMP-xmpRights:WebStatement="https://www.example.com/image-licensing" \
-XMP-photoshop:Credit="BrandName Inc." \
-overwrite_original \
product-image-12847.jpg
# Full metadata report to verify scrub results
exiftool -a -u -g1 product-image-12847.jpg
# Batch scrub GPS across entire image library, preserve XMP
exiftool \
-GPS:all= \
-Make= -Model= \
-overwrite_original \
-ext jpg -ext jpeg -ext png \
-r \
/path/to/image-library/
The XMP-dc:Subject field is particularly interesting. It takes freeform comma-separated terms, similar to IPTC keywords, but lives in the XMP namespace. Google's image crawlers appear to read both in the visual knowledge graph pipeline. Using both is not redundant; based on our testing, the two fields feeding similar terms reinforces the entity association rather than creating confusion.
PNG Files Are a Special Problem
Most image optimization discussions focus on JPEG. PNG metadata handling is messier. PNG's native metadata chunks (tEXt, iTXt, zTXt) are not IPTC-compatible in the same way. ExifTool can embed XMP into PNG files, but the support is less consistent across downstream tools and some CDNs strip it more aggressively than they strip JPEG IPTC/XMP.
For product images in PNG format, our current recommendation is to convert to JPEG or WebP for the Lens-optimized canonical image and use PNG only for images where transparency is genuinely necessary. This is a pragmatic compromise, not an ideal one. Related: see our analysis of WebP and AVIF compatibility with Lens entity matching.
The CIVIL Framework for Visual Search Optimization
After running two major rebuilds and a lot of failed hypotheses, I landed on a personal framework for approaching image programs in the Lens era. I call it CIVIL.
- C — Consistency: Metadata signals must be consistent across the image binary (IPTC/XMP), the structured data (ImageObject JSON-LD), the page content, and the URL/filename. Inconsistency between these layers confuses entity matching.
- I — Identity: Every image needs clear creator identity and copyright provenance. Google's visual knowledge graph is building trust signals partly around image provenance. Anonymous images with no creator attribution are ranking lower in Lens citation rates than attributed ones, even when visual content is similar.
- V — Vocabulary: Use controlled vocabulary where possible. IPTC subject codes, schema.org type hierarchies, and Google's product taxonomy all provide controlled vocabulary frameworks. Freeform keywords still matter, but they should supplement controlled terms, not replace them.
- I — Integration: ImageObject schema must be integrated into parent entity schema (Product, Article, Recipe, etc.) not placed as a standalone block. Isolated ImageObject blocks correlate with weaker Lens citation rates than nested ones.
- L — Longevity: Image URLs should be treated as permanent. Canonical image URLs that change, even with proper redirects, lose Lens citation authority in ways that standard page redirects do not. This is a Lens-specific behavior we identified in late 2025.
CIVIL is not a comprehensive technical SEO checklist. It is a prioritization lens for making decisions when budget and time are limited. Which action moves the most CIVIL dimensions simultaneously? Start there.
For the outdoor equipment client, the single highest-CIVIL action we identified was implementing ImageObject nesting inside Product schema with full creator attribution. It touched Consistency, Identity, and Integration simultaneously. That was where we focused first after I realized the alt-text sprint had been the wrong call.
Two Things the Industry Is Getting Wrong
Contrarian Take One: Descriptive Filenames Matter Far Less Than You Think
The filename optimization advice has been canon in image SEO for nearly fifteen years. Use descriptive filenames. Include keywords. Separate words with hyphens. I have repeated this advice hundreds of times in audits, presentations, and client calls.
I am now skeptical that filename optimization has meaningful impact on Lens citation rates specifically. Not on traditional image search, where some filename signal appears to persist. But Lens. When we ran controlled tests across matched image sets in Q1 2026, varying only filename conventions while keeping IPTC, XMP, and structured data identical, the Lens citation delta was statistically indistinguishable from noise. The content-addressed delivery URLs that modern CDNs generate, which look nothing like keyword-rich filenames, do not appear to penalize Lens performance.
This does not mean filename optimization is useless. It means it should not be at the top of your priority queue in 2026 if your IPTC and structured data implementation is incomplete. Fix the layers that Lens actually reads first.
Contrarian Take Two: Lazy Loading Is Hurting Lens Discovery More Than People Realize
The web performance community won the lazy loading argument for good reasons. Loading images only when they are close to the viewport reduces initial page load time, improves Core Web Vitals, and saves bandwidth for users who never scroll. All true. I am not arguing against lazy loading for performance.
But Lens discovery relies on Google's visual crawlers being able to reliably retrieve image content during crawl. Lazy loading implementations that depend on JavaScript execution, specifically Intersection Observer implementations where the image URL is injected into the DOM dynamically, create a crawlability risk. If Google's crawler does not execute the JavaScript trigger, the image is never fetched, and it cannot be indexed in the visual knowledge graph.
The solution is not to abandon lazy loading. The solution is to use the native HTML loading="lazy" attribute, which Googlebot handles differently than JavaScript-dependent lazy loading, and to ensure that at minimum the primary representative product image for each page is never lazy-loaded at all. The fetchpriority="high" attribute on that primary image is the correct pattern.
We identified three client sites in 2025 where sophisticated JavaScript lazy loading had inadvertently prevented a significant portion of their product image library from being indexed in the visual knowledge graph at all. The fix was not complicated. The impact of fixing it was substantial.
For a deeper look at crawlability patterns affecting visual indexing, the Google Images best practices documentation has been updated with Lens-specific guidance as of early 2026. It is worth reading carefully if you have not done so recently. Also reference the official IPTC Photo Metadata Standard for the complete field reference.
Signals That Actually Move the Needle Right Now
Image CDN Configuration
Before any metadata work, before any schema work: audit your CDN's metadata preservation settings. This is the unglamorous infrastructure step that determines whether any of the other work you do survives to Google's crawlers. Check specifically for metadata stripping in image optimization configurations. Enable preservation of IPTC and XMP fields explicitly if your CDN supports it.
Canonical Image URLs and Sitemaps
Image sitemaps remain relevant but are underutilized at the metadata level. The <image:caption> element in image sitemaps feeds Lens's understanding of image content at crawl time, before the visual analysis pipeline runs. We have seen it help in cases where IPTC caption data was not surviving the CDN pipeline. It is a redundant signal, and redundant signals compound.
Submit dedicated image sitemaps for large image libraries. Keep the submission current. Images removed from sitemaps without proper canonical consolidation lose Lens citation authority more rapidly than they lose standard image search ranking. This was one of the first things we identified in the home goods client audit in August 2025.
Structured Data Freshness
The uploadDate and dateModified fields in ImageObject schema are not just timestamps. They appear to influence how frequently Google's visual crawlers re-examine an image's entity associations. Images with recent dateModified dates in their structured data get recrawled more frequently, which means updates to your IPTC metadata and XMP fields propagate to the visual knowledge graph faster.
This creates an interesting maintenance pattern: when you update IPTC or XMP data on a batch of images, also update the dateModified field in the corresponding ImageObject JSON-LD. It signals that the image's metadata context has changed and warrants fresh crawl attention.
Page Quality Signals Still Matter
Not everything changed. Images on high-quality, authoritative pages get cited by Lens more than images on thin or low-quality pages, even when the image-level signals are identical. Page-level E-E-A-T signals continue to transfer to image authority in Lens, particularly for YMYL verticals. Medical device imagery on a medically authoritative domain outperforms identical imagery on a thin affiliate page. This is not surprising, but it is worth stating explicitly because some practitioners are treating Lens optimization as entirely separate from page quality. It is not.
Our full analysis of E-E-A-T signals and image authority in Lens covers how page-level and image-level signals interact for high-stakes verticals.
Also worth your time: our breakdown of Google Discover's visual indexing overlap with Lens citations, which reveals some counterintuitive patterns around portrait-orientation images and Discover card selection.
Where This Goes Next
We are five months into the Search Console Lens citation report existing as a real data source. Five months. The industry has not had time to build consensus around what drives those numbers, what the ceiling looks like, or how Lens rankings interact with traditional image search in cases where they diverge.
What I am watching closely in the next two quarters: how Google handles AI-generated product imagery in the visual knowledge graph. Right now, there is no reliable signal in the structured data spec or in observed Lens behavior that distinguishes AI-generated images from photography. I expect that to change. The digitalSourceType field in the IPTC standard's Content Authenticity extensions, which includes a value for AI-generated content, is already in the spec. Whether Google starts reading it as a ranking signal is a question that will likely have an answer before the end of 2026.
The practitioners who will be best positioned when that change comes are the ones who are building clean, attributed, entity-consistent image programs now. Not because attributing AI-generated images will be required tomorrow, but because the infrastructure for doing so correctly overlaps almost entirely with the infrastructure for Lens optimization today. Clean metadata pipelines, consistent structured data, CDN configurations that preserve embedded signals.
CIVIL is where I would start. Not with alt text.
