Google Lens and multimodal AI search: optimizing images in WordPress and WooCommerce

The operational paradigm of modern digital search is rapidly pivoting from purely text-centric query parsing to rich multimodal interactions. Mobile shoppers regularly point their smartphone cameras at physical machinery parts, consumer electronics, or textile samples to trigger visual discovery through Google Lens, ChatGPT Vision, or Bing Visual Search. Concurrently, autonomous AI procurement agents analyze commercial website imagery as primary empirical evidence, evaluating dimensional schematics, serial plates, and compliance certifications directly from image pixels.

For software engineers and digital managers maintaining WordPress and WooCommerce deployments, this transformation necessitates a comprehensive overhaul of media ingestion and delivery pipelines. Legacy practices centered on uploading uncompressed JPEG files and adding basic alt text tags are wholly insufficient for maintaining visibility in next-generation multimodal shopping interfaces.

#The expanding role of visual search and multimodal artificial intelligence

The emergence of frontier multimodal architectures such as Google Gemini and OpenAI GPT-4o has revolutionized how automated web crawlers interpret visual assets. Historically, search bots relied almost exclusively on surrounding page copy, file naming conventions, and basic meta tags. Today, visual search engines execute sophisticated pixel-level inference in real time:

• Visual feature embeddings: Machine learning vision models map shapes, contour geometry, and surface finishes into high-dimensional vector spaces, performing sub-second distance searches against billions of registered product references.
• In-image Optical Character Recognition (OCR): Text printed on product nameplates, voltage specifications, ingredient panels, and packaging cartons is extracted automatically and ingested as high-confidence indexing signals.
• Visual-textual consistency: Google’s merchant listing guidelines require that images represent the marked up content, so a photo that contradicts the product data is a policy problem as well as a matching problem.

When an online catalog features industrial components or retail merchandise lacking clear, high-contrast, high-resolution photography, AI shopping agents cannot match the inventory against camera-assisted buyer queries.

#What Google Lens does with a product photo

Google describes Lens as a way to search with your camera, an image or a screenshot when something is hard to put into words (Google Lens). For shopping, the same page says Lens looks up who makes an item, what it costs and where to buy it, and it lists about 35 countries where those shopping results are available. Lens also translates text from the camera in over 100 languages, the same text reading that picks up labels and nameplates in product photos.

In October 2024 Google reported that Lens handles nearly 20 billion visual searches every month and introduced a product results page with reviews, prices from several retailers and places to buy (Google, 3 October 2024). The post says Lens identifies the photographed item with AI models and the Shopping Graph, which covers more than 45 billion products. There is no separate Lens submission for a store: a product reaches that results page through data Google already holds about it, meaning the Merchant Center feed and the product page itself. Google publishes no Lens-specific guide for site owners, so the practical levers are the documented ones: the Google Images guidelines, product structured data and the Merchant Center image requirements covered below.

#How Google reads an image on a WordPress page

Google’s image SEO guide lists the signals it takes from the page (Google Search Central, image SEO best practices). Supported formats are BMP, GIF, JPEG, PNG, WebP, SVG and AVIF, and the file extension should match the file type. Alt text is named the most important attribute for image metadata, with keyword stuffing named as the thing to avoid. Google’s own example moves from no alt, to alt="puppy", to alt="Dalmatian puppy playing fetch". Filenames should be short and descriptive, so my-new-black-kitten.jpg beats IMG00023.JPG, which is worth a rename rule in the upload workflow because camera and supplier files rarely arrive with useful names.

Context counts as much as the file. Google extracts information about an image’s subject from the page content, including captions and image titles, and recommends placing images near relevant text. Images set through CSS are not indexed, which rules out product photos injected as background-image by page builders or slider plugins. With responsive markup Google recommends always keeping a fallback URL in the src attribute next to srcset or <picture>; WordPress already adds srcset and sizes to content images while keeping src (wp_image_add_srcset_and_sizes). Image sitemaps may list <image:loc> URLs on other domains, which matters when the media library is served from a CDN hostname. To state which image represents a page, the guide points to primaryImageOfPage, mainEntityOfPage or the og:image meta tag.

#Modern image processing architecture in WordPress: libvips and AVIF

For over a decade, standard WordPress installations relied on the legacy GD (Graphics Draw) extension to generate image sizes. In high-volume WooCommerce catalogs containing tens of thousands of SKUs, GD produces severe memory overhead, lengthy thumbnail generation times, and inferior compression artifacts, compelling merchants to remain on outdated JPEG or PNG formats.

A modern stack integrates libvips via the php-vips binding or Node.js background workers running Sharp. The project describes libvips as a demand-driven, horizontally threaded library that runs quickly and uses little memory compared to similar libraries (libvips), which is what makes bulk AVIF conversion of a large catalog practical:

<?php
/**
 * High-performance streaming image conversion to AVIF using libvips in WordPress
 */
declare(strict_types=1);

namespace WPPoland\MediaArchitecture;

use Jcupitt\Vips\Image;
use WP_Error;

class ModernImageProcessor
{
    private const QUALITY_AVIF = 68; // Balanced fidelity-to-filesize ratio for e-commerce

    public function generateAvifVariant(string $sourcePath, string $destinationPath): bool
    {
        if (!file_exists($sourcePath)) {
            return false;
        }

        try {
            // Stream input pixels sequentially without loading full bitmap into RAM
            $image = Image::newFromFile($sourcePath, ['access' => 'sequential']);

            // Write output AVIF container preserving essential IPTC metadata
            $image->writeToFile($destinationPath, [
                'Q'           => self::QUALITY_AVIF,
                'compression' => 'av1',
                'strip'       => false, // Preserve IPTC copyright and credit fields
            ]);

            return true;
        } catch (\Throwable $e) {
            error_log(sprintf('AVIF generation failed for %s: %s', $sourcePath, $e->getMessage()));
            return false;
        }
    }
}

AVIF usually produces smaller files than JPEG at comparable visual quality, and it keeps hard edges and printed text clean at moderate compression. Measure the saving on your own catalog before committing: product shots on white compress very differently from lifestyle photos, and labels that must stay legible need a higher quality setting than a plain background.

#How WordPress 6.5 handles AVIF uploads

AVIF support arrived in WordPress core in version 6.5, and it depends on the server’s image library: Imagick or GD has to support the format (WordPress core announcement). The announcement points to the Info tab of Site Health, under Media Handling, to check whether AVIF appears among the supported formats. When it does, AVIF files upload and generate sub-sizes like JPEG or PNG. Converting other formats is opt-in through the image_editor_output_format filter; the announcement’s example maps image/jpeg to image/avif.

One limit belongs in every AVIF plan for a shop. Merchant Center’s image attribute accepts JPEG, WebP, PNG, GIF, BMP and TIFF (Merchant Center image link), and AVIF is not on that list. A store that converts every upload to AVIF and deletes the originals has nothing left to put in the feed. Keep a JPEG or WebP master for each product image, or generate one for the feed, and serve AVIF to browsers through <picture>.

To see how large media libraries connect to enterprise planning software, read our technical assessment of woocommerce erp integration.

#Structured ImageObject metadata using Schema.org

To ensure that Googlebot and visual AI agents link specific photographs to exact catalog items, web pages must declare structured metadata in JSON-LD format. Instead of merely exposing an array of image URL strings within the Product entity, engineers should define granular ImageObject records:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Product",
      "@id": "https://industrial-store.example/products/stainless-ball-valve-dn50/#product",
      "name": "Stainless Steel Ball Valve DN50 PN40",
      "sku": "VALV-SS-DN50",
      "image": [
        {
          "@type": "ImageObject",
          "@id": "https://industrial-store.example/media/ball-valve-dn50-primary.avif",
          "contentUrl": "https://industrial-store.example/media/ball-valve-dn50-primary.avif",
          "url": "https://industrial-store.example/media/ball-valve-dn50-primary.avif",
          "width": "2400",
          "height": "2400",
          "encodingFormat": "image/avif",
          "caption": "Industrial stainless steel ball valve DN50 lateral elevation showing lever mechanism",
          "representativeOfPage": true,
          "creditText": "WPPoland Product Testing Laboratory",
          "copyrightNotice": "All rights reserved 2026",
          "license": "https://industrial-store.example/terms/image-license"
        },
        {
          "@type": "ImageObject",
          "@id": "https://industrial-store.example/media/ball-valve-dn50-specification-plate.avif",
          "contentUrl": "https://industrial-store.example/media/ball-valve-dn50-specification-plate.avif",
          "url": "https://industrial-store.example/media/ball-valve-dn50-specification-plate.avif",
          "width": "2000",
          "height": "1500",
          "encodingFormat": "image/avif",
          "caption": "Close-up of manufacturer certification plate showing pressure ratings and serial identifier",
          "representativeOfPage": false
        }
      ]
    }
  ]
}

representativeOfPage is a schema.org property that marks the main image of the product. Google’s image guide names primaryImageOfPage, mainEntityOfPage and og:image as the ways to state a preferred image, and for merchant listings it requires image and recommends several high-resolution files (at least 50,000 pixels, width times height) in 16x9, 4x3 and 1x1 ratios (Google Search Central, merchant listing). Google does not document Lens giving extra weight to any of these properties, so treat them as clear labelling. Detail shots of serial number plates with an explicit caption give both readers and text-reading systems the specification in plain text next to the image.

To check that media endpoints and upload channels are protected against script injection, run a wordpress security audit.

#Responsive picture elements and Core Web Vitals LCP optimization

The fundamental challenge in e-commerce performance engineering is balancing high-fidelity zoomable photography (essential for Google Lens inspection) against stringent Google Core Web Vitals thresholds (Largest Contentful Paint beneath 2.5 seconds).

A resilient frontend architecture implements semantic <picture> elements featuring format negotiation, progressive srcset breakpoints, and calibrated sizes attributes:

<!-- High-performance responsive picture tag for main product hero -->
<picture class="woocommerce-product-hero-picture">
  <!-- Priority next-generation AVIF stream -->
  <source
    type="image/avif"
    srcset="/media/valve-dn50-600.avif 600w,
            /media/valve-dn50-1200.avif 1200w,
            /media/valve-dn50-2400.avif 2400w"
    sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 600px"
  />
  <!-- Secondary WebP fallback stream -->
  <source
    type="image/webp"
    srcset="/media/valve-dn50-600.webp 600w,
            /media/valve-dn50-1200.webp 1200w,
            /media/valve-dn50-2400.webp 2400w"
    sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 600px"
  />
  <!-- Baseline JPEG fallback for older clients -->
  <img
    src="/media/valve-dn50-1200.jpg"
    alt="Stainless steel ball valve DN50 lateral elevation"
    width="1200"
    height="1200"
    loading="eager"
    fetchpriority="high"
    decoding="async"
    class="object-cover w-full h-auto"
  />
</picture>

Key engineering requirements include:

1. fetchpriority="high" and loading="eager" attributes on the primary product image: This prioritizes network bandwidth allocation before secondary JavaScript bundles execute.
2. Responsive document <head> preloading: Injecting <link rel="preload" as="image" type="image/avif" href="..." imagesrcset="..." imagesizes="..."> lets the browser request the hero image before it parses the stylesheets.
3. Explicit width and height dimensional declarations: Defining aspect ratios prevents Cumulative Layout Shift (CLS) as high-resolution assets render asynchronously.

#IPTC metadata preservation vs security sanitation

Many WordPress optimization plugins strip all header metadata from media uploads to save a few kilobytes. That removes the creator and copyright fields together with the private data.

A secure metadata policy distinguishes between two data classes:

• Stripped metadata (Privacy and security risk): Geographic GPS coordinates, camera hardware serial numbers, and editing software version fingerprints must be purged upon upload.
• Preserved metadata (attribution and copyright): Standard IPTC fields including By-line (photographer or lab), Copyright Notice (legal entity), Headline (subject matter), and Object Name (SKU or model identifier).

Google Images can display the creator, credit and license details from these fields, as described in the next section. Google does not state that IPTC data affects rankings, so the case for keeping it is attribution and rights, not visibility.

#Which image license fields Google Images reads

Google documents two ways to attach rights information to an image: IPTC photo metadata embedded in the file, or ImageObject structured data on the page (Google Search Central, image license metadata). In the file, Google reads Web Statement of Rights, Licensor URL, Creator, Credit Line and Copyright Notice. Web Statement of Rights is required for the Licensable badge in Google Images, and the other four are recommended.

In structured data, contentUrl is required because Google uses it to decide which image the metadata belongs to. Next to it, at least one of creator, creditText, copyrightNotice or license must be present, and once one is set the Rich Results Test recommends the other three. license is needed for the Licensable badge, and acquireLicensePage points to a page that explains how to license the image. Google adds that it does not guarantee this metadata will show in search results, and the page says nothing about rankings. Fill these fields for original product photography as a rights and attribution measure. In the older IIM encoding, Credit Line is field 2:110 and Copyright Notice 2:116.

#What WordPress core does with IPTC and EXIF on upload

WordPress reads IPTC fields itself when an image is uploaded. wp_read_image_metadata() takes the credit from IPTC Credit (2#110) with Creator (2#080) as a fallback, the copyright from 2#116, the caption from Description (2#120), the title from Headline (2#105) or Title (2#005), and the creation time from 2#055 and 2#060 (WordPress developer reference). Since 4.4 the wp_read_image_metadata filter receives the raw IPTC array, and since 5.0 the EXIF array too, so a plugin can map an extra field such as a manufacturer part number without parsing the file again.

What survives in the generated sizes depends on the image editor. With Imagick, thumbnail_image() calls strip_meta(), which removes every profile except icc, icm, iptc, exif and xmp (WP_Image_Editor_Imagick::strip_meta). EXIF is on that protected list, so GPS coordinates from a phone photo can remain in resized copies. If location data must go, strip it before upload or in a dedicated step, then check a generated sub-size with exiftool instead of trusting a plugin checkbox.

#High-resolution Merchant Center feeds for Google Shopping

Google Merchant Center takes the main product image from image_link and up to 10 further views from additional_image_link (Merchant Center image link, additional image link). The documented requirements:

1. Size: Google recommends images of about 1500 x 1500 pixels or more and has announced a minimum of 500 x 500 pixels for all products from 31 January 2027. Files may not exceed 16 MB or 64 megapixels.
2. Formats: JPEG, WebP, PNG, GIF, BMP and TIFF, with a file extension that matches the format. AVIF is not on the list.
3. Composition: the product should take up no less than 75% and no more than 90% of the image, with no borders, promotional overlays, watermarks or superimposed logos.
4. Generated images: images created with generative AI must carry metadata saying so, and embedded tags such as IPTC DigitalSourceType must not be removed.
5. Access: robots.txt must allow both Googlebot and Googlebot-Image, and image URLs should not carry parameters that change on every feed submission.

Additional image links are the place for alternative angles and in-use photos that show the product’s scale.

Serving high-resolution files from a cache-optimized media hostname keeps crawler requests for large catalogs away from the PHP origin.

#Edge media transformations and headless WordPress architectures

On busy e-commerce platforms, dynamic image resizing on the origin WordPress server competes with checkout requests for CPU. A common pattern delegates media handling to edge compute workers utilizing Cloudflare Images, Fastly Image Optimization, or a dedicated Bun/Sharp microservice.

Benefits of edge media decoupling in headless architectures:

• On-the-fly format synthesis: High-resolution master assets reside in secure object storage (such as AWS S3 or Cloudflare R2), while edge nodes deliver optimized AVIF variants dynamically based on client Accept headers.
• Origin server protection: Crawler requests for media are answered from the edge cache, so static images never start a PHP process.
• Metadata caveat: Cloudflare’s metadata option applies only to JPEG output. copyright (the default) keeps only the EXIF copyright tag, keep preserves most EXIF including GPS location, and for every other output format, WebP and PNG included, all metadata is discarded (Cloudflare Images). An AVIF variant from the edge carries no IPTC credit, so license data must also live in the page’s structured data.
• Full compatibility with headless frontends: Modern decoupled architectures built on Astro or Next.js render optimized markup with sub-second TTFB while querying media directly from the edge CDN.

Discover how our team architects high-availability e-commerce platforms by exploring our specialized services in headless wordpress.

#Automated quality control and color profile management

Color profiles (ICC profiles) are an often ignored part of e-commerce image handling. If a supplier uploads photos in Adobe RGB or ProPhoto RGB and the server discards the profile without remapping the color values, colors render dull or shifted in the browser and no longer match the physical product.

To avoid that, normalize the whole catalog to standard sRGB. A continuous integration pipeline can also run automated checks on background contrast and object sharpness before images are published to production.

<?php
/**
 * Mandatory sRGB normalisation on media upload
 */
declare(strict_types=1);

namespace WPPoland\ColorGovernance;

final class ProfileNormalizationFilter
{
    public function ensureStandardSrgbProfile(string $imagePath): void
    {
        if (!extension_loaded('imagick')) {
            return;
        }

        try {
            $imagick = new \Imagick($imagePath);
            $colorspace = $imagick->getImageColorspace();

            if ($colorspace === \Imagick::COLORSPACE_CMYK) {
                // Convert print CMYK files to digital RGB
                $srgbProfile = file_get_contents(__DIR__ . '/profiles/sRGB.icc');
                $imagick->profileImage('icc', $srgbProfile);
                $imagick->transformImageColorspace(\Imagick::COLORSPACE_SRGB);
            } elseif ($colorspace !== \Imagick::COLORSPACE_SRGB) {
                $imagick->transformImageColorspace(\Imagick::COLORSPACE_SRGB);
            }

            $imagick->writeImage($imagePath);
            $imagick->clear();
        } catch (\Throwable $e) {
            error_log('[Color Governance] Color profile normalisation failed: ' . $e->getMessage());
        }
    }
}

#Technical checklist for a Google Lens and visual AI audit

Before launching visual optimization initiatives across WooCommerce catalogs, engineers should verify the following technical benchmarks:

1. AVIF mime type negotiation: Confirm that your web server transmits AVIF files with the correct Content-Type: image/avif header.
2. Picture element fallback verification: Validate that fallback JPEG or WebP sources display correctly when user agents do not support AVIF.
3. LCP priority configuration: Ensure that hero catalog imagery includes fetchpriority="high" and excludes loading="lazy" attributes above the fold.
4. Schema.org ImageObject validation: Verify with the Google Rich Results Test that Product entities carry image, and that ImageObject nodes with license data include contentUrl.
5. IPTC metadata retention: Confirm that compression routines preserve copyright notices and product identifiers in output files.
6. Feed image audit: Verify that feed images are JPEG, WebP or PNG, around 1500 x 1500 pixels, and at least 500 x 500 pixels ahead of the 31 January 2027 requirement.
7. Label legibility testing: Check that technical specification plates and packaging labels remain readable after lossy compression.
8. Edge caching headers: Set immutable cache headers (Cache-Control: public, max-age=31536000, immutable) on all static media assets.
9. Media directory security: Disable direct PHP execution inside the /wp-content/uploads/ directory to prevent malicious script execution.

Visual search rewards the same groundwork as image SEO: crawlable files in supported formats, clear markup and a clean feed. To plan this work for your store, reach our engineering team via the contact page.