How to Do Image SEO

Image SEO serves two goals at once, and treating them as one is where most teams go wrong. The first goal is ranking in image results so the picture itself earns visibility. The second is page performance for ordinary web search, because images are usually the heaviest thing on a page and the most common cause of a slow Largest Contentful Paint. The highest-leverage on-page factors are the same handful every time: alt text that describes the image accurately instead of stuffing keywords, descriptive filenames set before upload, modern-format compression that fixes Core Web Vitals, and image sitemaps so Google can discover images it otherwise would not.

The single most wasted asset in this whole discipline is unique original photography shipped as an oversized file with empty alt text, which throws away both a ranking signal and page speed at the same time.

Alt text and filenames, done correctly

Alt text exists first for accessibility and second for search, and the two reinforce each other: text that genuinely describes the image for a screen reader is also exactly what helps Google understand it. Describe what the image shows, accurately and concisely. Relevant terms appear naturally because they describe the picture, not because you forced them in. A rough working convention is around ten to fifteen words, but Google publishes no alt-text word count, so hold that as a loose guideline rather than a rule and let the image dictate the length.

Two patterns are clear failures. Empty or SKU-style alt text on a content image (“IMG-4521”, “product-A”) tells Google nothing and abandons the signal. Keyword-stuffed alt text is the opposite mistake and is the wrong pattern: “running shoes best running shoes buy running shoes cheap running shoes” describes nothing and reads as manipulation. The correct version of that is simply “blue trail running shoe on a rock”. The exception is decorative images, dividers, background flourishes, icons that carry no information, which should get an empty alt=”” so assistive technology skips them rather than reading noise.

Filenames matter for the same reason and are cheapest to fix before upload. “blue-running-shoes.jpg” carries meaning; “IMG_4532.jpg” carries none. Rename files before they go live, because renaming after the fact can break image URLs and any links to them, so prioritize getting new uploads right rather than mass-renaming an existing library.

Format and compression, the free Core Web Vitals win

Format choice is where the performance gains hide. Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF, and in 2026 WebP is the practical baseline because every current browser renders it and it runs meaningfully smaller than JPEG at equivalent quality. AVIF goes further still, often roughly half the size of a comparable JPEG, at the cost of slightly more encoding effort and the need for a fallback on older clients.

Serve modern formats through the picture element with a WebP and JPEG fallback so newer browsers get AVIF while everyone else gets something they can render. Reserve PNG for images that need transparency and SVG for icons, logos, and line art that must stay crisp at any size.

Compression is the part teams resist and should not. The fear is that compressing a professional photo degrades it; the reality is that a 2.4 MB original and a properly compressed version a fraction of that size are visually identical at the dimensions a browser actually displays them. The “but we paid for professional photography” objection is exactly backward, because the oversized original delivers no visible benefit at web display size and only slows the page. Compress aggressively, and the LCP improvement is essentially free.

Responsive delivery and CDNs

A single large image served to every device wastes bandwidth on phones and hurts CWV. Responsive images with srcset (and sizes) let the browser pick an appropriately sized file for the viewport, so a small screen downloads a small image instead of the desktop-resolution original. The sizes attribute tells the browser how much layout space the image will occupy before the layout is computed, which is what lets it choose the right candidate early rather than after a reflow.

Image CDNs take this further by automatically converting format, resizing, and compressing on the fly, which is often the lowest-effort way to get correct, modern, right-sized images without rebuilding a pipeline by hand: you upload one high-quality source and the CDN derives the variants and negotiates format per browser.

Lazy loading is where teams most often hurt the metric they meant to help. Lazy-load below-the-fold images so they do not block the initial render and do not compete for bandwidth with content the user can actually see. But never lazy-load the LCP image itself, because deferring the largest visible element is the one place lazy loading actively delays the metric you are trying to improve. The same logic covers explicit width and height attributes (or a CSS aspect-ratio): set them on every image so the browser reserves space and the page does not shift as images arrive, which protects Cumulative Layout Shift.

The Core Web Vitals targets these feed into are an LCP at or under 2.5 seconds, an INP at or under 200 milliseconds (INP replaced FID as the responsiveness metric in March 2024), and a CLS at or under 0.1, all measured at the 75th percentile of field data, and oversized or unsized images degrade the first and the third directly.

Structured data, sitemaps, and context

Schema has a place but a narrow one. ImageObject markup matters where attribution, licensing, or creator metadata is relevant, and images belong inside the structured data you already use, Product, Article, Recipe, where Google’s guidance asks for them. Image sitemaps earn their keep on large libraries and on sites where images load via JavaScript or lazy loading and might not be discovered through normal crawling; usefully, an image sitemap can list image URLs on other domains, which is how you keep CDN-hosted images discoverable.

Finally, context ranks images as much as the image attributes do. An image is partly evaluated on the page it sits on and the text around it, so a relevant image on a topically relevant page with a descriptive caption and nearby copy is stronger than the same image dropped onto an unrelated page.

Original images also outperform ubiquitous stock photography, because the same stock shot appearing on thousands of sites gives Google no reason to prefer your instance. That is the throughline of image SEO: the unique photo you already own is the asset, and the job is to stop wasting it on bad filenames, empty alt text, and bloated files.

Frequently Asked Questions

How long should alt text be?

Long enough to describe the image accurately and no longer. A common working convention is roughly ten to fifteen words, but that is a practitioner guideline, not a Google-published limit, so let the content of the image decide. Avoid the two failure modes: empty or SKU-style alt that says nothing, and keyword-stuffed alt that describes nothing.

Which image format should I use in 2026?

Default to WebP for broad support and strong compression, and serve AVIF through the picture element with a WebP or JPEG fallback for the best size when the browser supports it. Use PNG only when you need transparency and SVG for icons, logos, and line art. Google Search supports JPEG, PNG, WebP, AVIF, SVG, GIF, and BMP.

Will compressing images hurt their quality?

At the dimensions a browser actually displays, no. A multi-megabyte original and a properly compressed version look identical at web display size, while the oversized file only slows the page and worsens Largest Contentful Paint. Compress aggressively; the performance gain is real and the visible quality loss is not.

Sources

• Google Search Central: Image SEO best practices. https://developers.google.com/search/docs/appearance/google-images
• web.dev: Core Web Vitals (LCP, INP, CLS thresholds). https://web.dev/articles/vitals