Image SEO and speed: file names, alt text and sizes

What image SEO covers

The 2025 Web Almanac calls the alt attribute central to accessibility and says it also supports image indexing in search. Most of what helps an image in search also helps a visitor, and the same is true for speed. So treat the work as three jobs:

1. Be understood. A name, alt text and nearby words say what the image is for.
2. Be found. A real img element in the page source gives crawlers and assistive tools something to read.
3. Be light. The right size, format and loading keep the image from slowing the page. The other guides in this topic cover that part in depth.

This guide does not claim that any one of these changes moves a ranking. It sticks to what the documentation says the attributes are for.

File names

web.dev's accessibility course says to name images as consistently and accurately as you can, because image names are a fallback when the alt text is missing or ignored. MDN agrees on the risk: when an image has no alt attribute, some screen readers announce the file name, which confuses people if the name tells them nothing.

web.dev also advises dashes between words rather than underscores, and no symbols or other non-letter characters. In practice:

Three habits around names cost nothing:

• Pick the name before you publish. Renaming a live image breaks every page that points to it. If you must, redirect the old address. See redirects and status codes.
• Version by name. When you replace an image, give the new file a new name, so caches fetch it. See caching explained.
• Keep one copy. The same picture under three names is three downloads.

Alt text

MDN says the alt attribute defines text that can replace the image. Browsers do not always display images: people use non-visual browsers, switch images off to save bandwidth, or meet a file that is broken or in an unsupported format. In those cases the alt text stands in.

web.dev's accessibility course sorts images by purpose, and each kind needs something different:

MDN explains the empty case. alt="" tells browsers the image is not a key part of the content, so non-visual browsers may leave it out. A missing alt is different: some screen readers read out the file name instead. Always write the attribute, even when it is empty.

Writing it well

• Describe the content or the job, briefly. web.dev says it is usually advised to keep alt text to 150 characters or less, to avoid reader fatigue. Longer explanations go in a caption or the page text.
• Skip "image of" and "photo of". Screen readers already announce that it is an image. MDN's own example of what not to do is alt="image".
• Write like a person. Use normal punctuation. web.dev warns that keyword stuffing does not benefit anyone: screen reader users are annoyed, and it says search engine algorithms will penalize it.
• Read it in context. MDN's test is to read the alt text together with the text before it, and see whether it says what the image says.
• Do not repeat the alt in a `title` attribute. MDN says title is not a substitute for alt, and that repeating it can make some screen readers say it twice. For a caption, MDN says to use figure and figcaption.

For an inline SVG icon, alt does not exist. Give an informative one role="img" and a title. See SVG for speed.

How common it is

In the 2025 Web Almanac, the median mobile page had alt attributes on 60% of its images, up from 58% in 2024. Blank values were on 15% of images on the median mobile page, up from 14%. The Almanac points out that a blank value is better than none but is no help to a screen reader or a search engine when the image is not decorative.

Real images, not backgrounds

An img element carries an alt. A CSS background image does not. web.dev's course notes that a screen reader will not detect an image added as a CSS background, so use backgrounds only for decoration. A product photo, a team picture or a diagram belongs in an img.

Keep the image address in the HTML too. Some lazy loaders put the real address in a data-src attribute and fill in src after a script runs, so the page source shows no image until then. The native loading="lazy" attribute keeps the src in the markup. See how to fix a slow LCP and lazy loading.

If crawlers are blocked from the folder that holds your images, they cannot fetch the files. See robots.txt and noindex.

The speed side

The same images have to be light. Four things matter most, and each has its own guide:

• The right dimensions. An image far bigger than its slot wastes bytes. See responsive images.
• A modern format and good compression. See WebP and AVIF.
• A reserved space. Set width and height so the page does not jump. See image width and height.
• The right loading. Lazy-load images below the first screen, never the main one at the top. See image optimization.

Lighthouse 13.5 has two Best Practices checks on images as well. One flags images shown in a different shape from their real one, and one flags images whose own size is too small for the display size and pixel ratio.

Captions and nearby words

MDN says that an image which needs a caption should be wrapped in figure with a figcaption. A caption is visible text, so everyone gets it, and it ties the words to the picture. Put the picture near the text that explains it. web.dev's tip for deciding whether an image is decorative is a good test for this too: hide the images on your page and ask whether you still understand the content that remains. If not, the words should say more.

How to check

1. Run Lighthouse or PageSpeed Insights and open the accessibility results. In Lighthouse 13.5 the image-alt audit counts in two categories: accessibility, where its weight of 10 is the top tier, and SEO, where its weight is 1. On a test page, I ran Lighthouse 13.5. The image-alt audit failed for the one image that had no alt attribute, and it passed the image with alt="" and the one with a description. Its svg-img-alt audit failed for an svg with role="img" and no title, and passed one with a title.
2. Read the performance insights for oversized and old-format files. See how to read a speed report.
3. Scan the page source for <img tags with no alt. In the Network panel, the Img filter lists the file names. See the Network panel.
4. Hide the images and read the page. Does it still make sense?
5. Listen once with a screen reader on your most important page. Ten minutes shows more than any audit.

Mistakes to avoid

• Camera file names such as IMG_4821.jpg on important images.
• No `alt` attribute instead of an empty one.
• `alt="image"`, or the file name as alt text.
• The same alt text on every image.
• Keyword stuffing.
• Long alt text on decoration, which makes screen readers read noise.
• Content images as CSS backgrounds.
• Words inside pictures with no text version.
• Renaming live files with no redirect.
• A lazy-loaded main image at the top of the page.

Check your own page

Run the free audit and read the accessibility results for images. Then open your home page, hide the images, and read what is left. Fix the alt text on the images that matter, and rename the ones that still carry camera names.

Sources

• Images in the web.dev accessibility course: kinds of images, empty and missing alt text, best practices and file names.
• MDN: the img element, with its notes on alt, file names and title.
• SEO chapter, Web Almanac 2025: alt attributes, blank values and the role of alt in indexing.
• The Lighthouse 13.5 audit texts for image-alt, image-redundant-alt and svg-img-alt, and a test run of those audits.