Image SEO: The Complete Checklist That Actually Moves Rankings

Key takeaways

The ranking-relevant image work is performance first: right format (AVIF/WebP), right dimensions, compressed, and not lazy-loaded when the image is the LCP element itself.
Alt text exists for screen readers and for machines; keyword-stuffed alt hurts users and does nothing for rankings — describe the image, and when you would not say it aloud, it does not belong.
Filenames are a minor signal, not a lever — descriptive beats keyword-dense exactly as much as 'webp-image1.jpg' beats 'best-blue-widget-reviews-2026.jpg'.
Image sitemaps help when images matter to discovery (galleries, products, portfolios) and are unnecessary for decorative content.
Lazy-load below the fold, eager-load the hero — the single most common accidental LCP killer is lazy-loading the biggest image on the page.

1. Performance: The Half of Image SEO That Is Not Debatable

Page speed is a confirmed ranking consideration (as Core Web Vitals, a tiebreaker at the margin), and images are the slow part of most pages. The measurable chain, in order of size: serve next-gen formats (AVIF/WebP beat JPEG by 30-60% at equal quality), size the file to the actual display dimensions (a 4000 px photo into a 800 px slot wastes ~90% of its bytes), compress with the image compressor (quality 80-85 is visually identical for web photos — the compression guide walks the slider), and set width/height or aspect-ratio on every <img> so the page does not jump while loading (that jump is Cumulative Layout Shift, a CWV metric itself).

The single most damaging image mistake on modern sites is lazy-loading the hero image. The loading="lazy" attribute tells the browser to defer until the image nears the viewport — for the LCP element that defers the very thing being measured, costing hundreds of milliseconds and turning a green CWV page amber. Rule: loading="eager" (or no attribute) plus fetchpriority="high" on the hero; loading="lazy" on everything below it.

2. Alt Text: The Rules That Survive Contact With Users

Alt text's job is to make the page complete when the image cannot be seen — screen-reader users reading the page linearly, sighted users on broken images, and machines that infer content from it. The working standard is the read-aloud test: if the alt phrase would sound bizarre read aloud in the sentence around the image, rewrite it. 'Blue widget mounted on a DIN rail, shown with the included cable gland' is good alt; 'blue widget | best blue widget | widget reviews 2026' is alt text that hurts your conversion-free readers and does literally nothing extra for rankings.

Three mechanical rules: every content image gets alt (descriptive, natural), every decorative image gets empty alt (alt="" — which tells screen readers to skip it; missing-alt is a bug and a11y violation, not an SEO opportunity), and text inside images is invisible to search — if a banner carries a headline that matters, it must exist as real HTML text or an identical alt, because the crawler reading the page does not OCR it reliably and users who cannot see it need it stated.

3. Filenames: A Small Signal, Not a Strategy

The myth: hyphenated keyword filenames are a major ranking lever. The reality: Google's own statements over the years are that filenames are a minor contribution ('blue-widget.jpg' beats 'DSC_0481.jpg' in roughly the way a sensible URL beats a query-string mess) and keyword-stuffing them is ignored at best. So: descriptive, short, hyphen-separated, done — then spend the saved minutes on bytes, which are measured.

One filename practice with a real upside that is not about rankings: unique filenames. 'logo.png' overwritten twelve times makes debugging and cache behaviour a nightmare; versioned or content-named files ('widget-front-45deg.png') keep a site's image inventory intelligible to the humans maintaining it, which is the actual reason to think for ten seconds before upload.

4. Structured Data and Image Sitemaps

When images are the content — product listings, portfolios, recipe galleries, real-estate photos — machine-readable discovery pays: an image sitemap (or the ImageObject in existing product/recipe/Article schema) tells Google which images represent which pages, with captions and titles that can surface in image search with a click back to the source. For a page where images are illustrative only, an image sitemap is optional overhead.

The rich-results angle that matters more in 2026 than the image sitemap itself: if your page type supports structured data (products, recipes, articles), matching the schema image to the on-page hero gives eligibility for layouts that display large image thumbnails in results — the visual real estate that actually moves click-through, and the one image SEO task with a directly measurable payoff.

5. The Checklist, Page by Page

Format: AVIF with WebP fallback via <picture>, or WebP alone (browser support ~97%); never ship a 6 MB 'web optimised' JPEG because the CMS told you to. Size: the largest display width ×2, no bigger. Weight: hero under ~200 KB on mobile-typical pages, other images under 100. Attributes: width/height or aspect-ratio on every img, lazy everywhere except the LCP image, decoding async for below-fold content. Alt: read-aloud test passed on content images, empty on decorative. CDN/cache: long max-age with filename versioning so returning visitors load nothing.

And the one-line test that catches most mistakes without any tooling: open the page on a throttled connection, right-click → inspect the hero, and read its actual delivered dimensions and weight against the slot it fills. A 3 MB 3840 px image in an 800 px frame is visible in the HTML itself — the fix is the compressor and the resizer, and it is the biggest win on the page.

Frequently asked questions

The questions people ask most about image seo: the complete checklist that actually moves rankings, answered directly.

Do images affect SEO rankings?

Mostly through performance: images dominate page weight, and page experience (Core Web Vitals, especially LCP driven by hero images) is a measured consideration. Alt text and filenames contribute at the margin and matter for accessibility and image search; the bytes and milliseconds matter for the rankings of competitive queries.

Is WebP good for SEO?

Yes — same visual quality at 25-35% fewer bytes than JPEG/PNG directly improves LCP and total weight, and support is now near-universal. AVIF goes further (40-60% below JPEG) with a WebP fallback. Format choice is the single biggest image-SEO lever available to most sites.

How do I write good alt text?

Describe what the image shows in the language you would use aloud to someone who cannot see it, within a natural sentence or two of the surrounding content. Keep keyword insertion only where the word is genuinely what the image depicts — and give decorative images empty alt so screen readers skip them.

What image size is best for SEO?

The largest size the image is actually displayed at (×2 for retina). Google's own guidance is the same as the performance guidance: match the delivered pixels to the render box. A 4000 px image shown at 800 px costs 90% extra bytes and buys zero — it only hurts.

Should I lazy-load images for SEO?

Below the fold, yes — it defers weight that would compete with the critical render. For the LCP image (usually the hero), never: loading="lazy" on the main image delays the exact measurement Core Web Vitals scores you on. Use loading="eager" with fetchpriority="high" there, lazy for the rest.

Do filenames matter for image search?

A little: a descriptive, readable filename (blue-widget.jpg) contributes in the way clean URLs do, while gibberish (DSC_0481.jpg) leaves the model with only surrounding context. Keyword-stuffed filenames do nothing beyond the descriptive version. Treat it as hygiene and spend the effort on file size.

Do I need an image sitemap?

When images drive discovery — products, portfolios, galleries, news photos — yes, it helps Google associate images with pages and can lift image-search traffic. For sites where images are decorative or secondary, it is unnecessary maintenance.

Why is my LCP image slow?

The classic four causes: the hero is lazy-loaded (deferring it past the measurement), the file is oversized or unoptimised, the image src is discovered late because it is injected by JavaScript rather than sitting in HTML, or a slow server delays the first byte. The fixes in order: eager-load it, compress it, give it a real <img> in the initial HTML, and cache the delivery.

What is the best image format for websites in 2026?

AVIF with a WebP fallback in a <picture> element for photographs; SVG for icons and logos (rasterised where SVG is rejected); lossless WebP for transparency on a budget; and JPEG only as the last-row fallback. The rule is 'smallest format the browser accepts' — the browser decides, your markup offers.

Do captions and titles on images help?

Visible captions are read and can improve engagement — which is real because humans stay longer, not because the tag itself ranks anything. The title attribute is largely invisible to search and hostile to mobile users; use figcaption semantics for anything meaningful, and structured data for the machine-readable version.

How do I check my images are SEO-optimised?

Run the page through Lighthouse and read the 'properly size images' and 'prioritise LCP element' items — they point at the exact files. Or just inspect each large image's natural width versus its rendered width and its byte weight; the three-column mental model (format, dimensions, loading) finds almost everything.

Does resizing images before uploading actually help?

More than any other single image task on typical sites. A camera or design export is usually far larger than the slot; one pass through a resizer to the real display width, then the compressor, often cuts 80% of the bytes while looking identical — and that byte saving is the part Google measures.