Image SEO in 2026: Alt Text, Modern Formats, Lazy Loading and AI Image Search

🖼️ Image SEO · Updated October 2026 · 12 min read · by Jacob Campbell

Good image SEO in 2026 comes down to three things: describe each image accurately (alt text, filename and the text around it), deliver it fast (modern formats, responsive sizes, explicit dimensions, and lazy loading on everything except the main image), and make it discoverable (a real <img> element, an image sitemap where needed, and structured data). Google’s image guidelines have not changed much, but the stakes have: images now feed Google Images, Discover, Lens and the multimodal search in AI Mode, and slow images are the most common cause of a poor Largest Contentful Paint.

This guide walks through each part with copy-ready HTML, and sticks to what Google, web.dev and the browser makers actually document.

Key facts

• 7 formats — Google Search indexes BMP, GIF, JPEG, PNG, WebP, SVG and AVIF
• Jan 2024 — Edge 121 completed AVIF support across major browsers
• 2.6 s → 1.9 s — Google Flights LCP after fetchpriority="high" (web.dev)
• 1,000 — Maximum image entries per URL in an image sitemap

Start with a real img element that Google can find

Google indexes images referenced in the src of an <img> element (including inside <picture>), and does not index images set as CSS backgrounds.

That one rule from Google’s image SEO best practices catches a lot of modern sites, where hero images, team photos and product shots are painted in with background-image for layout convenience. Those images are invisible to Google Images and Lens. If an image carries meaning, use an element:

<!-- Not indexed as an image -->
<div class="hero" style="background-image:url(/img/clinic.jpg)"></div>

<!-- Indexed, accessible, and still styleable -->
<img src="/img/dental-clinic-entrance.jpg"
     alt="Front entrance of a dental clinic with a blue awning and a wheelchair ramp"
     width="1600" height="900" class="hero-img">

Use object-fit: cover on the image if you need the background-style crop. Google lists the formats it supports in Search as BMP, GIF, JPEG, PNG, WebP, SVG and AVIF. It also recommends keeping the same URL for an image wherever it is reused, so Google can cache it rather than recrawl copies, and image URLs must not be blocked in robots.txt. The crawler that fetches them is Googlebot-Image, which Google says is used for Google Images, Discover and the features in Search where images are shown.

Alt text, filenames and the text around the image

Good alt text describes what the image shows and why it is on the page, in plain words, for someone who cannot see it; that is also exactly what helps search engines.

Google’s own example sets the scale, from bad to best:

<img src="puppy.jpg">                                     <!-- bad: missing -->
<img src="puppy.jpg" alt="puppy dog baby dog pup pups puppies doggies">  <!-- bad: stuffed -->
<img src="puppy.jpg" alt="puppy">                         <!-- better -->
<img src="puppy.jpg" alt="Dalmatian puppy playing fetch"> <!-- best -->

Practical rules that work for both screen readers and search:

• Describe, do not label. “Kitchen with white shaker cabinets and quartz island after remodel” beats “kitchen remodel Boca Raton”. Include the place or product name when it is actually in the picture.
• Say what matters in context. The same photo of a person might be “Jane Smith, lead designer” on a team page and “Designer reviewing a wireframe on a laptop” in an article.
• Keep it short. One sentence is usually enough. Long explanations belong in a caption or the surrounding text.
• Do not start with “image of”. Screen readers already announce it as an image.
• Use empty alt for decoration. alt="" tells assistive technology to skip dividers, background flourishes and icons next to text that already says the same thing. Leaving the attribute out entirely is different, and worse: some screen readers then read the filename.
• Text in images needs to be in the alt. If a graphic says “20% off this week”, the alt should too, and preferably the page text as well.
• SVGs: for an inline <svg>, Google recommends a <title> element inside it; for an SVG in an <img>, use alt as usual.

Accessible images are also easier for AI agents to interpret, which we cover in accessibility is agent-readiness.

Filenames, captions and surrounding text

Google works out what an image is about from the page as well as the image itself, so the filename, caption, nearby text, page title and headings all count.

Google’s guidelines say it extracts information about an image from the page content, “including captions and image titles”, and recommend placing images near relevant text, on pages that are about the image’s subject. In practice:

• Filenames: short and descriptive, such as dalmatian-puppy-fetch.jpg, not IMG00023.JPG. Use hyphens. On translated pages, Google suggests translating filenames too.
• Captions: use <figure> and <figcaption>; people read captions more than body text, and they tie the image to the topic.
• Placement: put the product photo next to the product description, not in a generic gallery three screens away.
• Page title and description: Google uses them when showing image results, so an image on a well-titled page is better presented.

<figure>
  <img src="/img/pool-deck-resurfacing-before-after.jpg"
       alt="Pool deck before and after resurfacing, cracked grey concrete next to smooth sand-coloured pavers"
       width="1200" height="800" loading="lazy" decoding="async">
  <figcaption>Pool deck resurfacing in Delray Beach: two days, same footprint.</figcaption>
</figure>

The title attribute on an <img> is not a substitute for alt; it shows as a hover tooltip, is not reliably read by assistive technology, and is unnecessary for most images.

Modern formats: AVIF, WebP and a safe fallback

AVIF and WebP are supported by every current major browser and usually produce much smaller files than JPEG or PNG at similar visual quality, so serve one of them by default with a JPEG or PNG fallback in src.

Support milestones: WebP has been supported in Chrome since 2012, Firefox since version 65 (January 2019) and Safari since version 14 (September 2020). AVIF arrived in Chrome 85 (August 2020), Firefox 93 (October 2021) and Safari 16 (September 2022), and Microsoft Edge was the last major browser to add it, in version 121 in January 2024. Older devices that cannot update past those versions will use the fallback.

The <picture> element lets the browser pick the first format it supports, and Google recommends always keeping a fallback in the <img> src:

<picture>
  <source type="image/avif" srcset="/img/team-800.avif 800w, /img/team-1600.avif 1600w" sizes="(min-width: 960px) 800px, 100vw">
  <source type="image/webp" srcset="/img/team-800.webp 800w, /img/team-1600.webp 1600w" sizes="(min-width: 960px) 800px, 100vw">
  <img src="/img/team-800.jpg"
       srcset="/img/team-800.jpg 800w, /img/team-1600.jpg 1600w"
       sizes="(min-width: 960px) 800px, 100vw"
       alt="Three designers planning a site map on a whiteboard"
       width="800" height="533" loading="lazy" decoding="async">
</picture>

Which to choose: AVIF generally compresses better, and WebP encodes faster and is very widely supported, so many sites ship both as above. Keep PNG or SVG for logos, icons and diagrams with flat colours and sharp edges; SVG is best where the artwork is vector. To generate the files, tools such as cwebp, avifenc, Squoosh, or an image CDN that converts on the fly all work. Check the result at 100% zoom: aggressive AVIF settings can smear fine text and skin tones.

Do not rely on file extension alone: the server must send the right Content-Type (image/avif, image/webp). Some older Apache setups lack the AVIF type; add AddType image/avif .avif to .htaccess if your files download instead of displaying.

Responsive sizes and width/height: stop layout shift and oversized downloads

Always set width and height on images so the browser can reserve space before the file loads, and use srcset with sizes so phones do not download desktop-sized files.

When an image has no dimensions, the browser does not know how tall it will be, and everything below it jumps when it arrives. That jump is counted by Cumulative Layout Shift (CLS), one of the three Core Web Vitals. Modern browsers use the width and height attributes to compute the aspect ratio, so the image can still be fluid in CSS:

<img src="/img/storefront-1200.jpg" width="1200" height="800" alt="...">

/* CSS */
img { max-width: 100%; height: auto; }

The attributes should match the intrinsic aspect ratio of the file; the CSS controls the displayed size. For images whose ratio changes by breakpoint, set the attributes for the default and use the CSS aspect-ratio property in a media query.

srcset lists the available widths, and sizes tells the browser how wide the image will be displayed, so it can pick the smallest file that looks sharp on that screen:

<img src="/img/menu-800.jpg"
     srcset="/img/menu-400.jpg 400w, /img/menu-800.jpg 800w, /img/menu-1600.jpg 1600w"
     sizes="(min-width: 1024px) 50vw, 100vw"
     width="800" height="600" alt="Seasonal brunch menu laid out on a marble table">

Without sizes, the browser assumes the image is full viewport width and often downloads a larger file than needed. A sensible set of widths for most content images is 400, 800, 1200 and 1600 pixels.

Lazy loading and fetchpriority: fast below the fold, faster above it

Add loading="lazy" to images below the fold, never to the Largest Contentful Paint (LCP) image, and mark that LCP image with fetchpriority="high".

Native lazy loading is supported in Chrome 77+, Edge 79+, Firefox 75+ and Safari 15.4+, and browsers that do not support it simply ignore the attribute. web.dev’s guide to browser-level lazy loading is direct: “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images.” A lazy hero image waits until layout is known before it starts downloading, which delays LCP. The same guide notes lazy images should have width and height; without them they start as 0×0 and the browser may load too many at once.

For the hero image, do the opposite and raise its priority. According to web.dev’s Fetch Priority article, the fetchpriority attribute is supported in Chrome and Edge 102+, Firefox 132+ and Safari 17.2+, and setting it on the hero image on Google Flights improved LCP from 2.6 s to 1.9 s.

<!-- The LCP image: eager (default) and high priority -->
<img src="/img/hero-1600.avif" width="1600" height="900"
     fetchpriority="high" alt="Custom website shown on a laptop and phone">

<!-- Everything further down -->
<img src="/img/case-study-1.webp" width="800" height="600"
     loading="lazy" decoding="async" alt="...">

Use fetchpriority="high" on one image, perhaps two; it is a hint, and marking everything high makes nothing high. If the hero is a CSS background or is chosen by JavaScript, the browser cannot discover it early; a <link rel="preload" as="image" fetchpriority="high"> in the head helps, but a plain <img> in the HTML is better.

Search is not affected by native lazy loading: Google’s lazy-loading guidance lists browser built-in lazy loading and IntersectionObserver as supported. What breaks indexing is custom scripts that only load images on scroll or click, because Google does not interact with the page. More on LCP in Core Web Vitals and TTFB and hosting speed.

Image sitemaps, structured data and licence metadata

An image sitemap helps Google discover images it might otherwise miss, structured data tells Google which image represents a page or product, and licence metadata tells Google Images who owns an image and how to license it.

Google’s image sitemap reference uses just two tags, and allows up to 1,000 images per page URL:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:image="http://www.google.com/schemas/sitemap-image/1.1">
  <url>
    <loc>https://www.example.com/portfolio/restaurant-site/</loc>
    <image:image>
      <image:loc>https://www.example.com/img/restaurant-home.webp</image:loc>
    </image:image>
  </url>
</urlset>

The old image:caption, image:title, image:geo_location and image:license tags were removed in 2022, so do not bother generating them. Images on a CDN host are fine, as long as you verify both domains in Search Console. You only need an image sitemap when images are loaded in ways Google may not find; images in plain <img> tags on crawlable pages are found anyway.

For structured data, the image property matters most on Article, Product, Recipe and LocalBusiness markup. Google’s Article documentation recommends multiple high-resolution images with at least 50,000 pixels (width multiplied by height) in 16x9, 4x3 and 1x1 ratios:

"image": [
  "https://www.example.com/img/guide-1x1.jpg",
  "https://www.example.com/img/guide-4x3.jpg",
  "https://www.example.com/img/guide-16x9.jpg"
]

To influence which image Google shows for a page, Google points to primaryImageOfPage in schema.org markup or the og:image meta tag. For Discover, it asks for images at least 1200 px wide, enabled with the max-image-preview:large robots setting, and warns against using a generic image such as your logo. Which schema types still earn rich results is covered in schema that still matters in 2026, and product images in product schema for merchant listings.

Licensing metadata: IPTC and the Licensable badge

If you license or want credit for your images, add licence metadata, either embedded IPTC fields or schema.org structured data, so Google Images can show a “Licensable” badge with a link to the licence.

Google’s image metadata documentation requires contentUrl plus at least one of creator, creditText, copyrightNotice or license, and recommends license and acquireLicensePage for the badge:

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "ImageObject",
  "contentUrl": "https://www.example.com/img/boca-raton-skyline.jpg",
  "license": "https://www.example.com/image-license/",
  "acquireLicensePage": "https://www.example.com/contact/",
  "creditText": "Example Studio",
  "creator": { "@type": "Organization", "name": "Example Studio" },
  "copyrightNotice": "Example Studio"
}
</script>

The embedded alternative uses IPTC photo metadata, which Google maps as follows: Web Statement of Rights to license, Licensor URL to acquireLicensePage, Credit Line to creditText, Creator to creator, and Copyright Notice to copyrightNotice. Lightroom, Photoshop and ExifTool can write these fields. If the two sources disagree, Google uses the structured data. One practical warning: many image optimizers and CMS upload pipelines strip metadata to save bytes, so check that the IPTC fields survive your compression step, or rely on structured data.

Google Lens, AI Mode and multimodal search: what is documented

Google has not published separate optimization rules for Lens or for images in AI Mode; the documented path into both is the same as for Google Images: an indexable image on a relevant, indexed page.

What Google has said: in April 2025 it brought multimodal search to AI Mode, letting people snap or upload a photo and ask a question about it. According to that announcement, AI Mode can understand the whole scene, including how objects relate to each other and their materials, colours, shapes and arrangement, and then issues multiple queries about the image and the objects in it, returning an answer with links. Google’s AI features documentation says there are no additional technical requirements to appear in AI Overviews or AI Mode beyond being indexed and eligible to be shown with a snippet.

What that implies for a business, without overclaiming:

• Use your own photographs. If someone photographs your product, building or dish, a matching original image on your site is a plausible source to link. A stock photo used by hundreds of sites is not.
• Make the page explain the image. Product name, model, materials, price and location in text near the image, plus Product or LocalBusiness structured data, give a multimodal system something to connect the picture to.
• Do not block Googlebot-Image or set noimageindex on pages whose images you want found.
• Remember the controls. max-image-preview limits how large Google shows your images, and noimageindex removes them from Google Images. See noindex vs robots.txt for how these rules interact with crawling.

An image SEO checklist, and its limits

Most image SEO gains come from a short list of fixes applied consistently across templates.

1. Meaningful images are <img> elements, not CSS backgrounds, and are not blocked in robots.txt.
2. Every meaningful image has descriptive alt text; decorative ones have alt="".
3. Filenames are short and descriptive; images sit next to related text, with captions where useful.
4. AVIF or WebP is served through <picture> with a JPEG or PNG fallback in src.
5. srcset and sizes are set; width and height are on every image.
6. The LCP image has fetchpriority="high" and no loading="lazy"; everything below the fold is lazy.
7. Article, Product and LocalBusiness markup includes an image; important pages have a representative og:image.
8. An image sitemap exists if images are loaded in ways Google may not discover.
9. Licensed images carry IPTC or ImageObject licence data.

Limits. None of this makes a weak page rank; images support the page, not the reverse. Alt text is for people first, and stuffing it with keywords is something Google explicitly calls out as a poor experience. Format conversion has diminishing returns once images are correctly sized. And with AI image search in particular, Google documents eligibility, not ranking factors, so be wary of anyone selling a special “Lens optimization”. Our AI SEO myths article covers more of those claims.

Product facts: the AI Indexing Pack

Image SEO lives in your templates; the AI Indexing Pack covers the agent-facing layer of the same site. Stated plainly, so it can be checked against the product page:

• What it is: the AI Indexing Pack is a set of files you upload to your own website. It is sold by Built2WinWeb as a one-time purchase, with no subscription.
• What it ships: (1) a working MCP server using the Streamable HTTP transport, with typed output schemas and tool annotations; (2) Markdown content negotiation, so agents can request a clean text version of each page; (3) llms.txt, agents.txt and agent cards; (4) the full /.well-known/ discovery tree; (5) OAuth protected-resource metadata; (6) bot access control that verifies crawler identity; (7) a README with a verification checklist.
• Requirements: PHP 7.4 or newer, Apache or LiteSpeed with .htaccess support, FTP access, and a domain you control. Installation takes about 30 minutes.
• What it is not: it is not a WordPress plugin (that is the separate WordPress edition, which needs WordPress 6.0+ and PHP 8.0+), it does not write content for you, it does not guarantee rankings or citations, and it is not a managed service.
• Free routes in: sites built on AIWebBuilding get the core built in, and a 50-day streak on FreeAIBoost unlocks the pack for one domain. Current prices are on the product pages.

Related reading

• Core Web Vitals explained — LCP, INP and CLS, and what images have to do with each.
• What makes a website load fast? — A plain-English guide to the parts of page speed you control.
• Schema that still matters in 2026 — Rich results that survived and ones that did not.
• Accessibility is agent-readiness — Why accessible markup, alt text included, works better for AI agents.
• Product schema and merchant listings — Product images, prices and availability in Google Shopping surfaces.
• Show up in AI Overviews and AI Mode — What Google actually says about eligibility.
• AI Indexing Pack — The file-drop kit: MCP server, Markdown pages, llms.txt, discovery files and bot access control for any PHP site.

Frequently asked questions

Does alt text still matter for SEO in 2026?

Yes. Google uses alt text, along with the page content and filename, to understand images, and it is essential for screen reader users. Write a short, accurate description, not a list of keywords.

Should I use AVIF or WebP?

Both are supported by all current major browsers and indexed by Google. AVIF usually compresses better and WebP encodes faster; many sites serve AVIF first and WebP second through a picture element, with a JPEG or PNG fallback.

Should I lazy-load every image?

No. Lazy-load images below the fold, but never the Largest Contentful Paint image or anything visible on load. Give the main image fetchpriority="high" instead.

Can Google index CSS background images?

No. Google’s image guidelines say it does not index images set with CSS; use an img element (or picture) with a src attribute for any image you want found.

How do I get the Licensable badge in Google Images?

Add licence metadata, either as ImageObject structured data with license and acquireLicensePage, or as IPTC fields such as Web Statement of Rights and Licensor URL embedded in the image file.