Image SEO is the practice of preparing the images on your website so they load fast and get understood by search engines: right format, real compression, responsive sizes, descriptive file names, honest alt text, and lazy loading in the right places. The work pays twice. Images are roughly half the weight of a typical page, so they decide much of your loading speed and your Core Web Vitals. And every image is a page that can rank, in Google Images, in the image packs inside normal results, and now in AI answers that pull visuals. Most sites upload camera-resolution files with names like IMG_4032.jpg and do none of this, which is exactly the opportunity.
The short version
- Serve AVIF or WebP, compressed, at the size the layout actually displays.
- Use srcset so phones stop downloading desktop-sized files.
- Lazy load below the fold only, and never the hero image.
- Name files for what they show and write alt text for every informational image.
- AI systems read pixels now, but text signals still decide which images get retrieved.
One fully prepared image
<picture>
<source type="image/avif"
srcset="/img/red-nike-air-max-90-400.avif 400w,
/img/red-nike-air-max-90-800.avif 800w,
/img/red-nike-air-max-90-1200.avif 1200w"
sizes="(max-width: 700px) 100vw, 800px">
<img src="/img/red-nike-air-max-90-800.webp"
srcset="/img/red-nike-air-max-90-400.webp 400w,
/img/red-nike-air-max-90-800.webp 800w,
/img/red-nike-air-max-90-1200.webp 1200w"
sizes="(max-width: 700px) 100vw, 800px"
alt="Red Nike Air Max 90 running shoes on a white background"
width="1200" height="900" loading="lazy" decoding="async">
</picture>Every attribute is doing a job. The AVIF source keeps the file small where the browser supports it, and the WebP fallback covers the rest. The srcset variants let a phone pick the 400-pixel file instead of the 1200. The file name and the alt text tell machines what the picture shows. The width and height let the browser reserve the space before the file arrives, which prevents the layout jumps that Cumulative Layout Shift measures. And lazy loading keeps this image, which sits below the fold, from competing with the content the visitor sees first.
Pick the format by the job it does
Format choice used to involve compatibility gambling. It no longer does: every major browser supports both WebP and AVIF, so the modern formats are the default and the old ones are the fallback. Google's own published comparisons put WebP files roughly 25 to 35 percent smaller than JPEGs of equivalent quality, and AVIF compresses harder still, especially at the aggressive quality settings hero images tolerate well.
| Format | Best for | Worth knowing |
|---|---|---|
| AVIF | Photos and hero images where every kilobyte counts | Smallest files of the group; encoding is slower, so convert at build time, not on the fly |
| WebP | The safe default for everything photographic | Universally supported, fast to encode, handles transparency |
| JPEG | Fallback for legacy needs, email, and older systems that cannot read newer formats | Never the primary format on a modern site |
| PNG | Screenshots and graphics that must stay lossless | Huge for photos; if a photo is a PNG, that is a bug |
| SVG | Logos, icons, and diagrams | Scales to any size at tiny weight; text inside it stays readable to crawlers |
Compress before you do anything clever
Compression is the highest-return step because most originals are dramatically oversized, and cutting half or more of the file weight with no visible change is routine on unaudited sites. For a handful of images, Squoosh gives you a live before-and-after slider per file. For a pipeline, Sharp does the resizing and conversion at build time, and static frameworks wrap it: Astro, which this site runs on, generates the AVIF and WebP variants with dimensions automatically. For a CMS, plugins like ShortPixel or an image CDN handle it on upload. The target is not a number but a habit: no image ships at a higher resolution than the largest size any layout displays it, and photographic images always ship lossy, because nobody can see the difference and the savings are large.
Serve the right size to every screen
A phone displaying an image at 400 pixels wide should not download the 1600-pixel desktop version, and srcset is how it avoids that. You list the same image at several widths, and the sizes attribute tells the browser how wide the image will render at each viewport, so it can pick the smallest file that will still look sharp, including on high-density screens that want double the pixels. The mistake that quietly cancels the whole feature is a missing or wrong sizes attribute: the browser then assumes full viewport width and downloads files far larger than the layout uses. If you check one thing in DevTools, check which variant a phone actually fetched.
Lazy load below the fold and never above it
The loading attribute set to lazy tells the browser to defer an image until the visitor scrolls near it, which is free speed for everything far down the page, and Google indexes these images normally. The rule has one edge that matters more than the rest of it combined: the biggest image at the top of the page is usually your Largest Contentful Paint element, and lazy loading it tells the browser to deprioritize the one file it needed first. Hero images get fetchpriority high and no lazy loading. Everything below the first screen gets loading lazy. Set width and height on all of them so the page never jumps as files arrive.
Help machines understand what the picture shows
Ranking an image takes more than serving it fast. Search engines read a cluster of text signals around every image, and the sites that win image traffic feed all of them consistently. The file name describes the subject in hyphenated words, set before upload because renaming afterward rarely propagates cleanly through a CMS. Alt text describes the image for screen reader users first and search engines second, specific and honest, with no keyword stuffing. The heading and paragraph the image sits next to tell Google what page context the image belongs to, which is why the same photo can rank from a relevant article and go nowhere from a generic gallery. Captions get read at high rates, so where a caption genuinely helps the reader, it also reinforces the subject. And product structured data connects a product image to its price and availability, which is what makes shopping surfaces and rich results eligible to show it.
What AI and visual search change
The newest readers of your images are not crawlers matching file names. Google Lens answers visual queries at enormous scale, and the multimodal models behind Gemini, ChatGPT, and AI Overviews read the pixels themselves, identifying objects, printed text, and scenes with no caption required. It is fair to ask whether the text work still matters. It does, because understanding an image and choosing to retrieve it are different steps. When an AI system decides which images to surface or cite in an answer, it leans on the same text signals search always used: alt text, file names, surrounding copy, and structured data are what connect a picture to a query. The practical shifts are smaller and concrete. Original photography wins over stock more decisively, because models recognize the ten-thousandth reuse of a stock photo. Product images with a clear subject and clean background parse better in visual search. And accurate alt text now feeds systems that can check it against the pixels, so honest description beats keyword decoration by a wider margin than before.
Our audit shorthand for image work: fix the hero first. One oversized, lazy-loaded, or late-discovered hero image does more damage than fifty unoptimized thumbnails, because it is the LCP element on most templates. Right size, modern format, preloaded, never lazy. Then work down the page in order of rendered size.
What an image CDN really does for you
An image CDN like Cloudinary, imgix, or Cloudflare Images sits between your originals and your visitors, resizing, compressing, and converting per request, then caching the results near each visitor. For teams without a build pipeline it is the fastest route to modern formats, because the CDN reads what each browser accepts and serves AVIF or WebP from the same URL with no markup changes. Two realities to plan around. First, every transformed variant lives at its own URL: a hundred sizes of one image reachable at a hundred addresses can leak into the index if pages link them directly, so keep one canonical display URL per image in your markup. Second, Google Images treats an image URL as the image's identity and recrawls images slowly, so changing image URLs in bulk, as CDN migrations tend to do, resets image rankings the way moving pages without redirects resets page rankings. Keep image URLs stable, and when you must move them, keep the old paths redirecting.
When an image sitemap earns its place
Images referenced in ordinary img tags on indexed pages get discovered without help, so most sites never need an image sitemap. It earns its place in two situations: when images load through JavaScript galleries or interfaces crawlers handle badly, and when image search is genuine business traffic, as it is for products, recipes, portfolios, and photography. The format is an extension of your regular XML sitemap, each page entry listing the images that appear on it, and the referenced files may live on a CDN or a different domain. If your images already get indexed reliably, adding one changes little, and that is a fine reason to skip it.
Where image SEO fits in the bigger job
Image work compounds quietly. Every fix speeds up the page it sits on, page speed feeds Core Web Vitals for every keyword the page targets, and the understanding signals open a second door into image and visual search that most competitors leave shut. Egochi handles image weight, formats, and the signal cleanup as part of technical SEO audits, where the heaviest templates get fixed first because that is where the traffic is. If your site leans on photography, products, or portfolio work, treat this checklist as maintenance rather than a one-time project, because every new upload either follows the habits or starts the debt again.
Questions people ask about image SEO
What is image SEO?
Image SEO is the work of making the images on your site fast to load and easy for search engines and AI systems to understand: modern formats like WebP and AVIF, compression, responsive sizes, descriptive file names, honest alt text, set dimensions, and lazy loading below the fold.
Which image format should I use in 2026?
AVIF where your pipeline supports it, WebP as the reliable default, and both are supported by every major browser. Serve AVIF with a WebP or JPEG fallback through the picture element. Keep SVG for logos and icons, and PNG only where you need lossless screenshots.
Do image file names matter for SEO?
Yes, as one signal among several. Name the file for what it shows, with hyphens between words, before you upload it, because renaming after upload rarely propagates cleanly. The file name works together with alt text and the text around the image, not instead of them.
Does lazy loading hurt SEO?
Not when it is applied below the fold. Google indexes lazy-loaded images that use the standard loading attribute. The one damaging mistake is lazy loading the main image at the top of the page, which delays Largest Contentful Paint instead of helping it.
How do AI search engines read images?
Modern multimodal models read the pixels themselves and can identify objects, text, and scenes without any caption. Retrieval still leans on text: file names, alt text, surrounding copy, and structured data decide which images get found and cited, so the writing work keeps its value.
Do I need an image sitemap?
Only if your images load in ways crawlers struggle with, like JavaScript galleries, or if image search is real traffic for your business. Images referenced in normal img tags on indexed pages get found without one. When you do add one, it can reference images hosted on a CDN or another domain.
