Image SEO: File Names, Alt Text, Lazy Loading, Next-Gen Formats

Image SEO is the sub-discipline people skip until they realize their competitor is getting 30% of their visual traffic from Google Images. For commercial visual categories — ecommerce, fashion, food, travel, interior design — image search can be a meaningful traffic channel. For everyone else, image SEO is mostly about (a) accessibility, (b) LCP performance, and (c) not actively hurting your page SEO with misconfigured images.

This article covers the fundamentals that matter in 2026 for both image-as-traffic-channel and image-as-page-element contexts.

What image SEO actually covers

Four layers:

1. Discoverability — can Google find and understand your images? File names, alt text, surrounding context, structured data, image sitemaps.
2. Performance — do images load fast enough not to hurt Core Web Vitals? Format choice, sizing, lazy loading, CDN delivery.
3. Accessibility — can screen readers describe images to visually-impaired users? This overlaps almost entirely with SEO best practice.
4. Rich results — do images qualify for product rich results, recipe cards, etc.? Structured data delivers this.

Most "image SEO" advice focuses on layer 1. In 2026, layer 2 is often the bigger lever.

File naming

Old rule: descriptive file names with keywords.

What still matters:

• Descriptive, not generic. pegasus-41-black-side-view.jpg beats IMG_3847.jpg.
• Hyphens as separators, not underscores or spaces.
• Lowercase, no special characters.
• Reasonable length — 3-6 words is typical.

What matters less than people think:

• Exact keyword matches in filenames. Google's image understanding has advanced; pixel-level features and surrounding page context outweigh filename matching by a large margin.

Practical rule: descriptive filenames for your own maintainability and modest SEO benefit. Don't keyword-stuff filenames; they're low-leverage compared to alt text and context.

Alt text: the single most important image signal

Alt text (<img alt="...">) serves two critical purposes:

1. Accessibility — screen readers read alt text to visually-impaired users.
2. Image search — Google uses alt text heavily to understand what an image depicts.

Good alt text is:

• Descriptive of the image content — what's depicted, what the image shows.
• Natural language, not keyword-stuffed.
• Concise — 80-125 characters typical, 125-150 max.
• Context-appropriate — an image of a product in a product page gets different alt text than the same image in a blog post.

Good:

<img src="pegasus-41.jpg" alt="Nike Pegasus 41 running shoe in black colorway, side profile showing the midsole cushioning">

Bad (keyword stuffed):

<img src="pegasus-41.jpg" alt="running shoes best running shoes nike running shoes cheap running shoes 2026">

Bad (useless):

<img src="pegasus-41.jpg" alt="image">

Exception — decorative images: purely decorative images (divider graphics, background patterns, UI chrome) should have empty alt (alt=""), not descriptive alt. Empty alt tells screen readers to skip; missing alt tells them to announce the file name, which is noise.

Image format choices in 2026

Format hierarchy for photographic/complex imagery, in order of quality-per-byte:

1. AVIF — best compression. Supported in all modern browsers since 2022. 50-70% smaller than equivalent JPEG.
2. WebP — very good compression, universal support. 30-50% smaller than JPEG. Safe default.
3. JPEG — legacy, still the fallback for maximum compatibility. Progressive encoding helps perceived load time.

For graphics, logos, icons:

1. SVG — vector, infinitely scalable, tiny file size for geometric content.
2. PNG — raster with transparency. Use for logos and UI chrome that can't be SVG.
3. WebP/AVIF — also support transparency; newer option.

Implementation pattern — the <picture> element with fallbacks:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="descriptive alt text" width="1600" height="900">
</picture>

Browsers pick the first format they support. Modern browsers get AVIF; older get WebP; ancient get JPEG.

Responsive images

Don't serve a 4000px image to a 375px mobile viewport. Use srcset for resolution variants:

<img 
  src="hero-800.webp"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w, hero-3200.webp 3200w"
  sizes="(max-width: 768px) 100vw, 50vw"
  alt="descriptive alt text"
  width="1600" height="900">

Browser picks the appropriate size based on sizes (how the image is used in layout) and device pixel ratio.

Most CDNs offer this automatically (Cloudflare Images, Fastly Image Optimizer, imgix). Manual implementation is viable but tedious for large catalogs.

Lazy loading — but not for LCP

The loading="lazy" attribute defers image loading until the image approaches the viewport:

<img src="below-fold.jpg" alt="..." loading="lazy">

When to use: images below the fold.

When NOT to use: the LCP element, or anything above the fold. Lazy-loading the hero image is a classic LCP killer.

Safe defaults:

• First 1-2 images on the page: loading="eager" (or omit; eager is the default).
• Everything else: loading="lazy".
• Critical preload for the hero: <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> in <head>.

Width and height attributes

Always specify width and height on <img> tags. Even with CSS sizing, these attributes let the browser reserve space before the image loads, preventing CLS.

<img src="photo.jpg" alt="..." width="800" height="600">

Or use CSS aspect-ratio:

img.product-photo {
  aspect-ratio: 4 / 3;
  width: 100%;
  height: auto;
}

Either works. The goal is for the browser to know the aspect ratio before the image file loads.

Image sitemaps

For sites that want images indexed in Google Images, extend your XML sitemap:

<url>
  <loc>https://example.com/product/sneakers</loc>
  <image:image>
    <image:loc>https://example.com/images/sneakers-side.jpg</image:loc>
    <image:caption>Nike Pegasus 41 running shoes, side view showing midsole</image:caption>
  </image:image>
  <image:image>
    <image:loc>https://example.com/images/sneakers-top.jpg</image:loc>
    <image:caption>Top-down view of Nike Pegasus 41</image:caption>
  </image:image>
</url>

Most useful for ecommerce and visual content sites. Not essential for text-heavy blogs.

Structured data for images

Beyond sitemap, structured data helps specific image rich results:

• Product pages: Product schema with image array (3 images minimum — 1:1, 4:3, 16:9 aspect ratios) enables product image carousels in SERPs.
• Recipe pages: Recipe schema with recipe imagery enables recipe cards.
• Article pages: Article schema with images enables image thumbnails in article results.

Detailed in the schema markup guide.

CDN delivery and caching

Images benefit more than any other asset type from CDN delivery. Best practice:

• Long cache TTL — 1 year (Cache-Control: public, max-age=31536000, immutable) for versioned image URLs (hero-v2.webp, hero-abc123.webp).
• Edge format conversion — Cloudflare, Fastly, and similar CDNs can serve AVIF/WebP automatically based on browser support, from a single source JPEG.
• Responsive variant generation at edge — several CDNs generate multiple sizes on-demand from one source, caching each variant.

This reduces origin bandwidth, origin CPU, and developer time managing image variants.

Common mistakes

Missing alt attribute entirely. Not the same as empty alt. Missing → screen readers announce filename; empty → screen readers skip. Always include the attribute, even if empty for decorative images.

Alt text that repeats the visible caption. Alt is for when the image isn't visible (screen reader, image failed to load). Repeating the visible caption wastes the accessibility affordance.

Keyword-stuffing alt text. "Running shoes best running shoes buy running shoes" — Google's systems recognize and discount this. Hurts both accessibility and SEO.

Lazy-loading the LCP image. Most common image SEO mistake in 2026. Kills LCP field score.

Not compressing images. A 4MB hero image on a product page blows crawl budget, user patience, and LCP simultaneously. Compress to under 200KB for hero images, under 50KB for below-fold.

Using PNG for photos. PNG is for graphics with flat colors and transparency. Photos in PNG are 3-5x larger than WebP/AVIF equivalents.

Inline base64-encoded images. Adds to HTML size without cacheability benefit. Use only for critical above-the-fold tiny graphics.

Frequently asked questions

Does alt text help page rankings, not just image search?

Modestly yes. Google uses alt text as a signal about what the page is about (alongside body text, headings, etc.). Not a major ranking factor, but contributes to relevance signals.

Should I include my primary keyword in alt text?

If it's accurate to the image, naturally yes — alt text of an image of a Nike Pegasus shoe should include "Nike Pegasus" because that's what it is. Don't force unrelated keywords.

What's the alt text for a decorative background image?

If it's purely decorative (visual polish, no information conveyed), use alt="" (empty string). Screen readers skip. For CSS background images, there's no alt attribute — if the image conveys information, move it to an <img> tag.

How many characters for alt text?

80-125 is the sweet spot. Under 80 risks being too generic; over 125 gets truncated by screen readers. Up to 150 is acceptable for complex imagery.

Should I use image CDNs like Cloudinary?

For sites past 50 images or with dynamic image needs, yes. For a small blog with 20 static images, manual optimization + a regular CDN works fine.

What to read next

• On-Page SEO Checklist 2026 — images in the broader on-page optimization picture.
• Core Web Vitals in 2026 — the LCP implications of image optimization.
• Structured data that moves rankings — image-related schema types.