The Image SEO Work That Matters After Alt Text

Image SEO advice collapses to "write descriptive alt text" so reliably that many teams believe the work ends there. Alt text matters — for accessibility first, and as one of the signals Google has documented using to understand images. But on most sites, images are also the largest share of page weight and the most common LCP element, which means the consequential image decisions are engineering decisions: format, sizing, loading behavior, and discoverability.

Those decisions affect both how images rank in image search and how the pages carrying them perform everywhere else. Here is the part of the job that starts after the alt attribute is written.

Format selection is a compression decision, not a fashion one

Google has documented support for WebP and AVIF in Google Images alongside the legacy formats. Both generally compress substantially better than JPEG at comparable visual quality, with AVIF typically ahead of WebP but costing more CPU to encode.

The practical pattern is content negotiation rather than a site-wide format migration: serve AVIF or WebP to browsers that advertise support and fall back otherwise, either via the <picture> element or through a CDN that negotiates on the Accept header. Two rules keep this honest:

• Match the format to the content. Photographic content compresses well in AVIF/WebP; simple flat graphics are often smaller as SVG, which also scales without artifacts.
• Do not re-encode from an already-lossy source. Generating AVIF from a compressed JPEG bakes the old artifacts into the new file. Keep a lossless or high-quality master and derive variants from it.

Responsive sizing: stop shipping the desktop image to phones

A 2000-pixel-wide hero rendered into a 360-pixel viewport is pure waste, and it is the default outcome of writing a bare <img src>. The fix is the srcset/sizes pair:

<img src="/img/board-800.avif"
     srcset="/img/board-400.avif 400w,
             /img/board-800.avif 800w,
             /img/board-1600.avif 1600w"
     sizes="(max-width: 600px) 100vw, 50vw"
     width="1600" height="900"
     alt="Cutting board with routed juice groove">

The browser picks the smallest candidate that satisfies the layout — but only if sizes is accurate. A wrong sizes value silently selects oversized files, and nothing errors. Audit it by comparing rendered width to intrinsic width in DevTools.

The width and height attributes belong on every image for a different reason: they let the browser reserve layout space before the file arrives, which is the single cheapest CLS fix that exists.

Lazy loading done correctly, which mostly means not everywhere

Native lazy loading is one attribute:

<img loading="lazy" ...>

Correct use is below-the-fold images only. The common failure is applying it globally — templates and plugins that stamp loading="lazy" on everything, hero included. A lazy-loaded LCP image is deprioritized by the browser at exactly the moment it should be fetched first; web.dev's performance guidance documents this as a measurable LCP regression, and it shows up clearly in field data.

For the LCP image, do the opposite: eager loading plus an explicit priority hint (fetchpriority="high"), and consider a preload if the image is discovered late — for example, when it is a CSS background or injected by JavaScript. Late discovery is the quieter half of the problem: an image that only exists after a framework hydrates cannot be fetched early no matter what attributes it carries. Keep the LCP image in the initial HTML.

One more correctness point: content loaded only on scroll via custom JavaScript observers may never be seen by a crawler that does not scroll. Native loading="lazy" on a normal <img> with a real src does not have this problem; exotic homegrown lazy-loaders sometimes do. If images matter to your acquisition, verify they appear in the rendered HTML Google sees.

Filenames and context are weak signals, but free ones

Google's own image best-practices documentation lists descriptive filenames, alt text, surrounding text, captions, and page context among the inputs it uses to understand an image. walnut-cutting-board.avif over IMG_4032.avif is not going to move a competitive ranking by itself; it is a low-cost disambiguation aid, best enforced once in the upload pipeline rather than retrofitted.

Two cautions. Renaming existing image files changes their URLs, and image URLs accumulate their own indexing history — a bulk renaming project without redirects trades a weak positive signal for a real disruption. And keyword-stuffed filenames read as exactly what they are; describe the image, then stop.

Image sitemaps and the CDN question

Image sitemaps exist to surface images a crawler might not associate with your pages — the documented use case, per Google's sitemap documentation, is making images discoverable and explicitly tying them to the pages they belong to. If your images are plain <img> tags in server-rendered HTML, a sitemap adds little. If they are behind JavaScript, in galleries, or served from a separate CDN hostname, the sitemap is how you make the association explicit.

Serving from a CDN hostname is fine and normal — Google has stated that images on a different domain can rank — but it makes two disciplines matter more: keep image URLs stable, and list them in the sitemap against their host pages so the relationship is declared rather than inferred.

What to do

1. Find your LCP element in field data. If it is an image, confirm it is in the initial HTML, not lazy-loaded, and carries fetchpriority="high".
2. Grep templates for loading="lazy" and remove it from anything that renders above the fold.
3. Add width/height everywhere they are missing.
4. Automate format negotiation and srcset generation in the build or CDN layer — per-image manual work does not survive contact with a CMS.
5. Fix filenames at the pipeline level for new uploads; leave old URLs alone unless you are prepared to redirect.
6. Add an image sitemap only if your images are JavaScript-rendered or on a separate host — then verify indexing in Search Console's coverage reporting.