Image seo best practices: six attributes, and the two a search engine reads

Image seo best practices come down to six attributes on one tag, and a search engine reads only two of them. The alt text and the file name are what carry meaning. The other four — srcset, sizes, width/height and loading — decide how fast the picture arrives and whether the page jumps while it does. Both halves matter. They are not the same job, and mixing them is why image audits produce long lists and no result.

Before this page

This chapter deliberately skips how to write the alt text itself, because that is a page of its own: alt text for seo covers what Google reads there and the four cases where you write nothing. Everything below assumes the alt is already handled and asks what else is on the tag.

Image seo best practices split into two jobs, not one list

A search engine has to answer two separate questions about a picture: what is it, and can it be served. The first question is answered by text, because an image itself carries no words. Google's image documentation names the source: "The most important attribute when it comes to providing more metadata for an image is the alt text." Right after it comes the file name, with a rule you can apply in ten seconds: "When possible, use filenames that are short, but descriptive. For example, my-new-black-kitten.jpg is better than IMG00023.JPG."

The second question is answered by delivery attributes, and the same documentation treats them as a user-experience concern rather than a meaning one: "Make sure to apply the latest image optimization and responsive image techniques to provide a high quality and fast user experience." It describes srcset as a delivery mechanism — "The srcset attribute allows specifying different versions of the same image, specifically for different screen sizes" — and then asks for a safety net: "We recommend that you always specify a fallback URL using the src attribute."

Two attributes tell an engine what the picture is. The other four tell a browser how to get it. Auditing them as one list is what makes the list useless.

The six attributes, and who actually reads each one

This is the whole surface. Anything else on an <img> tag is styling or framework bookkeeping.

The row that gets skipped most often is the cheapest one. On a crawl of 26 homepages we ran on 2026-08-27, 811 of 1,664 images carried neither a width nor a height, and a further 51 carried only one of the two, which reserves nothing. Full numbers are in srcset on 1,664 homepage images.

How to audit one page in five minutes

Run these in order on a page you care about. Each step ends with a number you can write down, and a wrong number tells you which fix to make.

1. Count the images: curl -sL --compressed -A 'Mozilla/5.0' https://example.com/ | grep -o '<img[^>]*>' | wc -l. If this is zero and the page clearly has pictures, they are being inserted by script, and nothing that does not run scripts will see them.
2. Count how many carry a real src. Pipe the same output through grep -c 'src='. A gap here means the page uses data-src and a lazy-loading script; those images are invisible to anything that reads the delivered HTML and stops.
3. Count how many declare both dimensions: grep -c 'width=.*height='. Every image below that count is a potential layout shift.
4. Open three image URLs and read the file names. If any of them looks like IMG_4821.jpg or hero-final-v3-2.png, rename at the source, not with a redirect.
5. Check the format against the supported list. Google Search states it supports "BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF" for images referenced in the src attribute of img.

The checklist to keep

Copy this into whatever holds your publishing checklist. It is six lines because there are six attributes, and each line is pass or fail on a single image.

[ ] alt      describes the image, or is empty on purpose (decorative)
[ ] filename short, descriptive, hyphenated, lower case
[ ] src      present and absolute — not only data-src
[ ] width    intrinsic pixel width of the file
[ ] height   intrinsic pixel height of the file
[ ] loading  lazy below the fold, absent or eager for the first image

Two extras that are not per-image and are worth doing once. An image sitemap, which Google describes as a discovery aid — "You can provide the URL of images we might not have otherwise discovered by submitting an image sitemap" — and a decision about format, which is a size question rather than a ranking one.

Three ways this goes wrong

All three are visible in markup, which means you can check for them without opening a performance tool.

1. The image exists only after script runs. The tag ships with data-src and an empty or absent src. Your browser shows the picture; a client that reads the HTML and stops sees an empty element. In the 26-homepage crawl this affected 117 images across four sites.
2. A srcset with width descriptors and no sizes. The browser then assumes the image spans the full viewport and often downloads a file larger than it needs. This is a bytes problem, not a meaning problem, and it is easy to miss because the page still looks right.
3. Dimensions that do not match the file. Width and height are meant to be the intrinsic pixels of the asset, so the browser can compute the aspect ratio before the bytes arrive. Copying the CSS display size in there produces a reserved box of the wrong shape, which is a different jump rather than no jump.

Where this stops helping

Two boundaries, and both are worth saying out loud before you spend an afternoon here.

The first: none of this applies to images set as CSS backgrounds. They have no tag, no alt and no file name in the document, and Google's image documentation is about the img element. If a picture matters for meaning, it belongs in the HTML.

The second: we cannot tell you how much any of this moves a ranking, and neither can anyone else with a number. What is documented is narrower and more useful — alt text is the metadata source, file names give context, and delivery attributes affect speed and layout. Treat the six lines as hygiene you finish once per template, not as a lever you keep pulling.

Common questions

What are the most important image seo best practices?

Descriptive alt text and a descriptive file name, in that order, because those are the two things a search engine reads as meaning. Everything else on the tag changes how fast the file arrives, which matters for people and for Core Web Vitals but does not describe the picture.

Does the image file name really matter for SEO?

Google's documentation asks for short descriptive names and contrasts my-new-black-kitten.jpg with IMG00023.JPG. It is a weak signal next to alt text. It is also free at publish time and expensive to change afterwards, since renaming a live image URL is a redirect.

Should I use WebP or AVIF?

Both are supported. Google lists BMP, GIF, JPEG, PNG, WebP, SVG and AVIF as supported formats for images in the src attribute, so the choice is about file size and your build pipeline, not about being read. Pick whichever your tooling produces reliably and keep a fallback if your audience includes old clients.

Does lazy loading hurt indexing?

Not when it is the loading="lazy" attribute, which is part of HTML and needs no script. It can hurt when lazy loading is implemented by holding the URL in data-src, because then the real URL is not in the document at all. The attribute is safe; the pattern it replaced is not.

How many images should one page have?

There is no documented number and we would not invent one. What is worth watching is total weight rather than count, and whether the first visible image is being deferred — that one costs you a paint. To see what an engine actually receives from your pages before any of this is applied, see how QueryWin works.